[Snort-users] snort behavior in very high-load environment, B SD vs. linux
WilliamsJon at ...2134...
Wed Jul 31 08:14:07 EDT 2002
While I haven't got nearly the load you've got, I'll share what I've found
in my testing.
First, I don't remember if it was Linux or another OS (Solaris?), but
there's at least one Unix out there that lies about its packet drop rate, as
it its hard coded to 0 in the kernel. In my testing of Slowaris vs.
FreeBSD, this appears to be the case.
Second, the single threading problem can be minimized if you use BSD and can
segment your snort processes using command line BPF. For example, if you've
got three /24 subnets, 10.0.1.0, 10.0.2.0, and 10.0.3.0, run one snort
process for each with the BPF on the command line of "net 10.0.1.0" or
whatever. By doing that, you can gain some of the benefits of having
multiple processors (if your kernel is built for it) even with a
single-threaded snort. As a side note, I've also found it worth running an
N+1 process with a BPF of "not net 10.0.1.0 and not net 10.0.2.0 and not net
10.0.3.0" and alerting on any packet I see. This has been one of the most
useful rules I've put together, since it shows me things that theoretically
shouldn't be on my network. <grin>
Next, depending on the traffic loads, you can run into performance issues
based on the capabilities of your system. At really high speeds, things
like your PCI bus width and disk write speeds are always an issue, but your
memory bandwidth can also become an issue.
As for rules, I'm actually getting to the point where I think I've got some
of my networks profiled fairly well. I know basically what types of network
traffic are allowed, what applications run there, things like that. Once
you have that information, I believe that it is more useful to look for
violations to normal than to spend time looking for what unknown "experts
out there" say you should look for. For example, if I know that only TCP
traffic is allowed on a WAN link, then create a rule that alerts when the
protocol field is not TCP. Not only will you run fewer rules, I believe
that this will give a better chance at detecting new viruses, as well.
Finally, if you do use external rules, such as from snort.org, take a hard
look at what rules you run. Get rid of as many as you can, try very hard
not to use the address list construct (i.e. [184.108.40.206,220.127.116.11,18.104.22.168]), and
try to optimize the order of the rules such that the most specific rules
(specific addresses and ports) that don't have content: options are at the
top and the least specific ones (any any -> any any) that use content:
options are at the bottom. This helps break out of the critical path
faster, so you waste less time looking at most packets.
I hope this helps. Please let us know what your results are, since this
information is very useful to many of us :-)
From: Adam D'Amico [mailto:adamico at ...1936...]
Sent: Tuesday, July 30, 2002 5:43 PM
To: snort-users at lists.sourceforge.net
Subject: [Snort-users] snort behavior in very high-load environment, BSD
I've been working with snort for a while now in an environment that
seems to be on the bleeding edge of what should be snortable. I've
gotten predictable results in some spots and weirdness in others.
I thought I would share my results with everyone here, in the hope
that someone might get use out of them, and maybe even have decent
explanations for the weirdness. I've read through a lot of the
previous threads having to do with packet loss and system tuning,
but not much of it was applicable, given the network environment
I'm running in.
More information about the Snort-users