Re: Gigabit NIC's and snort hardware required??

[Bennett Todd <bet () rahul net>]

2003-06-05T03:58:24 Zach Forsyth:
> Actually I wanted to ask what hardware I need to successfully run snort
> 2.x on a Cisco 3508 fibre gigabit switch.

Sounds like you already successfully ran it. As far as I know, if
you could cram enough memory in, and if you could find the required
interface hardware, you could run snort on a 386SX-16 against any
NIC. Problem is, it might not keep up. Could of course, it doesn't
take a fast pig to keep up with an idle net.

> Just using the command :> snort -vi2 from the dos command prompt I am
> losing between 30%-50% of all packets.
>
> Does this sound right?

Yup, it does indeed, given what you said below (100Mbps likely).
Untuned snort works pretty well on modern PCs up to c. 50Mbps, then
it starts getting important to tune.

> Should I be swapping to linux? No dramas to do that just had a win2k box
> handy for this afternoon.

I can't comment on the Linux <-vs-> Windows performance question, I
don't know, I've never tried snort on Windows. I believe some people
have claimed particularly good results running on Linux built with
the ring-buffering libpcap.

> Any ideas on what is really needed for snort to cap GB traffic?

For snort to really reliably handle 1Gbps of actual traffic, you
need different hardware. You need either a machine with a bus
architecture capable of delivering that much bandwidth to memory
from a NIC (plus a fairly hot CPU and a load of memory), or else you
need to schmear the load out over multiple systems. A toplayer
switch can do the latter. A standard PCI bus can track up to 300Mbps
with sufficient tuning; PCIx can pump that up around 600Mbps. Faster
than that needs something newer and quicker, or else multiple
somethings dispatched from a toplayer.

> Just ballpark for say between 100-200mb/s - I am sure it is not more
> than this, but could be proved wrong.

Ok, now that you can do.

For seriously highest-performance snort, 512MB may be adequate, but
1GB might be more comfortable. Think about throwing more memory at
this problem, memory is cheap. Use snort version 2, it's faster than
1.x, but more memory hungry (the extra memory is directly being used
to make it faster). Then tune snort.

(1) Do basic tuning. Set the *_NET and *_PORTS vars in snort.conf
    appropriately for your network. Make sure you're running snort
    either with -A fast or else with syslog to another machine,
    don't log -A full.  Packet dump with "-b", for libpcap binary
    format. Or, if you're going to be using barnyard, ditch all the
    regular logs and have snort write only the unified binary format
    that barnyard reads.

(2) Do intermediate tuning. Read all of snort.conf, look for things
    you purely don't care about at all. There are a lot of rules
    files that get included, #-out those related to protocols you
    don't use, for which you have no servers that could possibly be
    attacked. If you can spend the time, skim the rules files,
    looking for sigs you really aren't interested in, and # them
    out.

(3) See how many alerts are being generated. Tune to eliminate
    alerts. If snort is generating hundreds or thousands of alerts
    per second, it'll never perform, and the alerts will be useless.
    If you really want a hot little piggie, see if you can get the
    alerts well down below 1/second. Less than 1/minute is even
    better. Some alerts you eliminate by fixing the buggy network
    env that triggered 'em, others you deem "false positives"
    for your environment and disable in the snort config, either
    disabling preprocessor features or #-ing out rules, depending
    on what triggered the alert. In extreme cases you can fine-tune
    using pass rules or using bpf filters.

At this point, with a decent NIC, a hot CPU, and plenty of RAM, your
snort should be happily keeping up with satisfactorily low drop
rates at 200Mbps or better.

-Bennett

Attachment: _bin
Description: