IDS

IDS

Sorted By Creation Time

snort event correlation thoughts

Home: www.packetnexus.com

[myoss] Snorting/Honeypotting

----------------------------------------------------------------------------
----

To: [email protected]
Subject: [myoss] Snorting/Honeypotting
From: [email protected] (spoonfork)
Date: Tue, 28 Aug 2001 10:30:44 +0800
Reply-To: [email protected]
Sender: [email protected]

----------------------------------------------------------------------------
----

Morning.

Here's some more stuff to chew on.

--sfork
Illegitimi Non Carborundum
http://www.ini2.net/mel

snort sensors
-------------
snort with/without mysql support

to reduce the load of the central console, data will be pushed from the
sensors via cron (scp or whatever via OpenSSH). during this operation
the following might occurs:

snort is stopped
i.   if logging are done to a file*, the log files are tarred and zipped
ii.  the log files are scped to console
iii. the log directory is emptied
iv.  a local copy is kept (just in case scp failed, or network error occurs)
v.   snort is restarted

*if sensor admins chose to enable database logging, the snort database
is dumped to a file and zipped, and scped to central console. the database
is then cleared.

central console
---------------
data crunching will be done here. this might include:
there will no snort running on the central console.

i.   verifying the log files received from sensors
ii.  processing log files received from sensors
iii. inserting the data into into database
iv.  processing the data and statistical analysis
v.   report generation

all this will be done once a day.

+snorticus can be used to do file transfer.
+OpenSSH need to be configured to connect the sensors to the central server
w/o
 password
+DEMARC, or a heavily modified version of it will run on the central server

issues
------
i.   data correlation

     with two or three sensor and an average of 100 alerts per day (assuming
no
	 major worm infections) per sensor, i don't think data processing will
	 be much of an issue. the trick here is being able to correlate intrusion
	 events between the sensors. e.g i see an unknown signature on sensor
	 B coming from IP 202.xxx.xx.xxx, did i see the same on sensor B? are the
	 alerts triggered at the same/subsequent time on sensors A and B? if they
	 do, does this mean a coordinated attack on IP range 202.xxx.xxx.1 -
	 202.xxx.xxx.10? (assuming both A and B sit on the same IP block)

ii.  honeypot

     again, data correlation. detecting an intrusion and recognizing the
	 exploit is of outmost importance. we want to know which intrusion events
	 lead to compromises on the honeypots. e.g i saw scanning on sensor A,
	 but no compromise, i saw the same scanning (from the same IP) on sensor B,
	 but B's honeypot is compromised. does this mean an automated vulnerability
	 scanner is roaming the web? why no compromise on A's honeypot? different
	 software versions?

	 the number of intrusion attempts before compromise may also indicate the
	 style, tools and sophistication employed of the attacker.

	 or, i saw a lot of scanning for a known vulnerability, but no attack
	 follows... why? is the attacker(s) on a scouting journey?

iii. honeypotting

     how long do you want the attacker to play on the honeypots? 1 day? 1
	 week? or until there's no more to be learned (well, gotta define
	 "there's no more to be learned")

	 personally, i've seen three types of attackers (that's a total of 4
	 compromised servers - i was such a lazy sysad) that i've let "roam" on
	 my servers