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