Re: Sizing of a box requiring 2x10Gbps

[Mike Lococo <mikelococo () gmail com>]

On 07/08/2010 04:49 PM, Eoin Miller wrote:
> Well, not really. Just use generic servers quadcore quadprocessor 
> servers and a napatech stream capable card (which is overkill for 
> 4Gbit). Recombining all the alerting from multiple instances of Snort
> is the only pain you really run into. You can just set the output
> logging to unified2 and 1mb in size and have another process monitor
> the output directory and process it with barnyard2 file by file into
> a database then point your front end tools towards that.
>
> Card: http://www.napatech.com/products/network_adapters.html (He will
> want the 2x10G PCIe one).
>
> Definitely requires some care, feeding and development this route. A 
> commercial offering should be much more plug and play.

I can confirm that this approach scales at least to 1.5gigabits/sec.
Endace and Napatech both offer multi-gigabit capture-cards that allow
you to run multiple snort processes on a single phsycial box.  I have a
4-way Endace card that I use to monitor a 1.0-1.5 gigabit link and drop
only a fraction of a percent of packets intermittently.  Each CPU can
handle 250-350 megabits per second using a large ruleset (most of the
truly malicious stuff in both ET and VRT, but not most of the policy
stuff).  With a smaller ruleset they can probably go faster.

To do 4 gigabits with a large ruleset, you'd probably want a 16-cpu
system, but as to whether you could really pull that off with a single
box... I don't know.  At some point you may begin to run into
bus-bandwidth limitations, but I don't know when/if that becomes an
issue.  You could certainly pull it off with a pair of boxes, I've
tested very close to those speeds myself.

Recombining the alert output from the multiple snort processes is very
straightforward.  It is like managing 16 separate snort sensors, they
all just happen to reside on the same physical hardware.  All of the
snort interfaces I've used (base, placid, sguil, arcsight) can accept
output from multiple sensors without a problem.  You may need some beefy
disks on your DB to handle the alert rate, but that depends heavily on
your alert-rate, your db-software, and how your setup is tuned.  I
wouldn't expect disk usage on the sensor itself to be an issue since
unified/unified2 output is pretty efficient to write.  The 3 disk raid5
in my 4-cpu sensor is almost completely idle all the time.

I can also confirm that this kind of setup takes some care and feeding.
 You'll be tweaking your own init scripts to handle startup/shutdown of
the multiple snort/barnyard processes and will need to be able to
troubleshoot performance bottlenecks yourself.

Finally, it's worth noting that you won't save *that* much money.  The
NapaTech/Endace capture cards cost 5-figures, and I very much doubt that
you could pull off multi-gigabit monitoring with software-only hacks (if
there are recent benchmarks to the contrary, I'd be interested in seeing
them).  The premium you pay for a SourceFire box will likely save you
quite a bit of hassle.

Cheers,
Mike Lococo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
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