RE: Snort Performance

["Jim Hendrick" <jrhendri () maine rr com>]

Disclaimer: I do not run anywhere near such volumes, so my "advice" should
be taken as second hand...
 
You can do port mirroring on the 2950
    - advantage = existing equipment (cheap), you will see all the traffic
that the switch sees
    - disadvantage = possible performance loss at high utilization
 
You can insert a "tap" upstream of the switch
    - advantage = less performance issues, easily possible to monitor near
wire speeds (i.e. not much increased latency)
    - disadvantage = cost (these are ~$1K each), no visibility into traffic
that stays within the switch.
 
If you really want to monitor 8 ports within the switch, you may be limited
to the first option (unless you buy 8 taps). This may not be a real problem,
but you are adding additional load to the switch.
 
In any case, the snort box should have multiple interfaces. I would
recommend one for separate communication to the box, and one for (each)
sensor interface configured as "passive" as possible (ifconfig up, but no
address ==> it should never transmit anything)
 
On the system side, you should consider the NICs ability to keep up with the
traffic it will be listening to (i.e. if you are spanning 8 ports on the
switch, you have a potential for 800Mb/s to be trying to fly by your sensor.
This is a very rough and inaccurate estimate, but you should see my point).
This is probably the key decision point for you; i.e. what should the sensor
topology look like connecting to the monitored port(s). I'm not sure if the
2950 has a Gig module option, but you might consider installing one if it
could be used as the mirrored port (with a matching Gig NIC on your sensor)
 
The CPU(s) RAM, etc. are secondary and pretty easy to deal with. I would
suggest at least a 2-CPU box with SCSI drives for I/O performance and as
much RAM as you can afford.
 
The Linux install should be considered as well. Minimalist is best here (no
packages you don't need) You should consider a second similar box where you
would compile all your tools and have the main sensor not even have a
development package (no compilers ==> harder for an attacker to build tools
on your box if they get a toehold). Limit access to it for the MySQL and
Apache servers as much as possible (firewall (iptables) & config settings,
etc.) Limit other access to either console only or at most ssh for remote
access. You will be storing information on the box about potential attacks
and vulnerabilities, lots of info about your network configuration, plus the
ability to listen to all your traffic. This wants to be a very well
hardened/monitored system. Once you get it configured, please take a
Tripwire or AIDE snapshot or at *very* least run a shell script to md5sum
your critical files in /etc,  /bin,  /sbin,  /usr/sbin,  /usr/bin, etc. etc.
and burn this to CD. Then if you ever suspect a compromise, you have a
baseline you can compare against (remember to update this baseline each time
you change something intentionally).
 
Have fun!
 
Jim
 

-----Original Message-----
From: snort-users-admin () lists sourceforge net
[mailto:snort-users-admin () lists sourceforge net]On Behalf Of Laura
Sent: Friday, March 26, 2004 8:30 AM
To: snort-users () lists sourceforge net
Subject: [Snort-users] Snort Performance


I'm thinking about placing an NIDS (linux box running red hat 8 with snort v
2.0.2 + acid 0.9.6) on a 2950 sw where not only all the traffic from all the
companies goes by but also where the carriers connections ends.
 
Monitoring about 8 interfaces, the amount of traffic that it will see is
going to be really big.
 
Does anyone have any experience using snort in a critical point of the
network, loading lots of traffic. I'm interested in information about
performance, hardware of the machine used (type of card, amount of memory,
processor, etc) and comments tips or best practices in order to minimize the
possible problems of any kind.
 
TIA
 
Laura