RES: Handling of a 1 or 2 GB pipe? [Snort-users]

["Romulo M. Cholewa" <rmc () rmc eti br>]

Agreed with everything you mentioned, but I have a doubt: since snort is capturing the frames down from the datalink 
layer, does a fast tcpip stack have any impact ?


Romulo M. Cholewa
Home : http://www.rmc.eti.br
Forum: http://zeus.rmc.eti.br/forum
PGP Keys Available @ website.

"The smallest distance between two points ? A turbocharged car."
                                                                 
                                                                 


]-----Mensagem original-----
]De: Erek Adams [mailto:erek () snort org] 
]Enviada em: sexta-feira, 31 de janeiro de 2003 11:00
]Para: Travis S.
]Cc: snort-users () lists sourceforge net
]Assunto: Re: Handling of a 1 or 2 GB pipe?
]
]
]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 version?)?
]
]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 cards.
]       *  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 
][0].  Phil also put together a nice little instruction set [1] 
]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 it out.
]
]You've got another option, and one that would involve a _lot_ 
]less hair pulling for you.
]
]       NS3000:  http://www.sourcefire.com/products/products.htm
]
]Hope that helps in some way!
]
]Cheers!
]
]-----
]Erek Adams
]
]   "When things get weird, the weird turn pro."   H.S. Thompson
]
]
][0]    http://public.lanl.gov/cpw/
][1]    
]http://marc.theaimsgroup.com/?l=snort-users&m=103833873414252&w
=2


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com 
_______________________________________________
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


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
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