RE: Snort and network taps

["Wirth, Jeff" <WirthJe () DNB com>]

counter.spy () gmx de:
> But now comes the real question:
>
> Wouldn't I lose the stateful inspection capability of snort when
> using the third method?
> Each snort process only sees one direction of each connection,
> so it cannot know if a connection has been properly established or
> not.
> It seems to me that this is a problem that most NIDS should encounter
> when running on tap ports, right?
>
> What would you recommend me to do, in order not to loose stateful
> analysis capabilities?
>
> Thanks for any pointers, hints and suggestions.

About a year ago I inherited an NIDS architecture that included 15 passive
taps, monitoring various router/firewall points.  The original configuration
had all the taps terminated to a Cisco switch which was configured to
forward traffic to one port which lead to an NIDS sensor (Not Snort..).  The
first thing I noticed was that some of the ports where constantly blocking,
due a Cisco traffic management feature ("spanning tree" I believe, I am by
no means a Cisco expert!)  But no matter what our LAN/WAN guys did we still
lost packets! (Side Note:  Apparently the first architecture included a
10/100 auto sensing hub instead of a switch, which was recommend by the NIDS
vendor. And from what I have be told, you could have painted the collision
indicator amber because it was always on...;-)

After some thought I came up with the following solution....

First off if you're looking for *real-time* alerting, you can stop reading
now.  This is the one thing I gave up in order to keep things like stateful
analysis.  

(1) Each sensor has a minimum of 3 NICS.  One for each tap feed and one to
connect to an out-of-band management segment.  Note: Some of our sensors
handle more then 1 tap.
(2) Each hour a tcpdump file is created for each feed (using Shadow's sensor
perl script).
(3) Once the hour file has been created and the sensor has moved on to the
next hour, a script runs to merge the two dump files.  We use "mergecap"
(Ethereal) for this, tcpslice was an option but Shadow compress it's dump
files with gzip, and mergecap can read dump files in compressed formats.
(4) Once the merge is complete, Snort runs on the new file and reports to an
analyst station running MySQL/ACID.
(5) Since we archive our tcpdump files, we also run Shadow filters and some
custom perl scripts on the data as well.

Hope this helps...

- Jeff
 

 

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users