[Snort-users] Handling of a 1 or 2 GB pipe?
erek at ...950...
Fri Jan 31 06:08:03 EST 2003
On Thu, 30 Jan 2003, Travis S. wrote:
> I am considering using Snort to monitor traffic on a 1 Gbps internet
> link, so the combined throughput of the monitored traffic would be 2
> Gbps. The average load is 1 Gbps (combined) and it wouldn't be
> surprising to see constant levels of above 1.5 Gbps. The most likely
> implementation will involve mirroring a switch port to receive the data.
> The network is over 60 subnets, with 50,000+ hosts.
> How well would Snort handle reviewing packets of such a link? I
> basically want to pick apart packets and examine a few key bytes to
> determine the application that is used to send the data. I'm not sure
> if it's possible to do this on-the-fly, or if it would be better to log
> the data and analyze from disk.
> Has anyone done similar things? Any comments on hardware requirements?
> Comments overall about the concept? Operating system suggestions (and
Well now! Can we say "Big Honkin' Pipes!"? :)
You can't deal with this in realtime, no matter what you might want. :)
With that said, here's a few things:
* I/O and I/O Bandwidth: You'll need _really_ zippy disks and
controllers. If you can throw money at it, go with a solid state disks.
If you can't get a multi-pathed, multi-controller array (SCSI of course!)
to hold the data. Sun Storedge 9980/9970 come to mind. Don't go crazy
with RAID. If you are pulling the data off and post processing, you'll
want a balance of speed vs. stability. I'd go with RAID 1+0. Use VxFS
and VxVM (Veritas products) if you can.
* NICs: Gotta have Gig. Use fiber if you can. Use multiple
* CPU: At least 2, as fast as you can. If you decide to run
Solaris, bind Snort to one of the processors. You'll see the best results
from doing that if you have more than 3 processors on a Solaris box.
Other OS's might support process -> processor binding, but I'm not
certain. If you run multiple instances, move them onto other processors.
* Memory: Throw a couple of gigs at it as a minimum.
spp_conversation and spp_stream4 eat memory like a kid does chocolate.
It'll use large amounts if you let it... But that's configureable.
* libpcap: This one will get you no matter what. The best thing
that I know of is Phil Wood's patches for Linux . Phil also put
together a nice little instruction set  for using them.
* tcp/ip stack: You'll need an OS with a fast stack. FreeBSD
has always had a pretty zippy sttack. If using Solaris, check Sunsolve
for TCP/IP stack tuning, and also the blueprints site for quite a bit of
useful tuning info. The Solaris stack is pretty "slow" out of the box.
Now, the other two: Hardware and OS. You could banter this about all
day with 10 different people and you'd get 10 different answers. :) I
can tell you what I would do, but keep in mind, it's not "Gospel" or even
the "World According to Garp." It's just my thoughts. With that warning
in place: I'd use Sun hardware. Sunfire 3800-6800 would be sweet. In a
way that kind of limits you to Solaris, but NetBSD has just released 1.6
with SMP support for Sparc. Sadly, it's won't run on those boxes. You
could also throw Linux at it, but I'd be cautious about that. In times
gone by the Linux SMP kernel made Microsoft products look stable and
secure! ;-) I'm sure that's changed, but I've not had a chance to check
You've got another option, and one that would involve a _lot_ less hair
pulling for you.
Hope that helps in some way!
"When things get weird, the weird turn pro." H.S. Thompson
More information about the Snort-users