Re: Any suggestions to lower drop rates on this setup?

[Chris Green <cmg () uab edu>]

I slept on this one for a bit because I wanted to see if anyone had
magic BPF tuning technique.

Speaking of BPF tuning, does anyone have a good platform benchmark
test of BPFs ( aside from the winpcap folks paper on it ).

"Crow, Owen" <Owen_Crow () bmc com> writes:

> I'm having high drop-rates on the following setup and would like some
> suggestions:
> OS: FreeBSD-4-STABLE
> System: HP Kayak XA, Intel PII, 300MHz, 48MB RAM

I don't know what other people are doing but I'd see if you could find
a faster CPU if you are really intending to move up past 100mbit.  At
the current rates you're looking at, I think you are cpu bound.

> I'd like to get that drop percentage down.  Does anyone have hardware or
> software suggestions?  

Fastest CPU you can find.

> I'm trying to drink from a fire hose here and need all the help I
> can get.  So far I've throttled the GigE traffic down to 100Mbit via
> a switch, but I'd eventually like to go GigE.  It looks like this
> hardware is completely inadequate for even 100Mbit traffic. 
> I've also tuned the kernel according to hints found at
> http://www.daemonnews.org/200108/benchmark.html.  The tuning has had
> no visible effect (drop levels are still 40-50% over the course of
> 24 hours).

> From earlier:
> 885 Snort rules read...
> 885 Option Chains linked into 108 Chain Headers

To stick with your current hardware, start chopping your ruleset
down.  Start with the things you don't know. When drinking from the
firehose, start with things you can investigate and then add the
datamining type rules on later.

try:

grep -e 'alert [^-]*any[^\(]*any' *.rules \
     | grep -v -e 'icmp\|:#.*alert\|virus.rules'

To find the rules that cause snort to have to look at packets destined
to ANY port. This can cause tons of data be sent through your CPU and
we've established that you don't have much CPU to give.

The next thing to do is to focus on a smaller set of web rules.  You
can end up with a long chain and that makes more things that have to
be checked for every single packet that someone sends to or from a
webpage.

It's my understanding that the rules get built into chains that
start

has_string("cmd.exe") ?
has_string("default.ida") ?
has_string(...)

so pretty soon you can build up some long searches that take longer
than the buffer length of your BPF.

http://www.cs.unc.edu/~jeffay/dirt/FAQ/bpf_bufsize.html  might also
help.

I'm not sure if thats still applicapable or not ( not a FreeBSD user )

Please let us know how your tuning ends up and what steps you take to
help allieviate your packet loss.
-- 
Chris Green <cmg () uab edu>
 "Not everyone holds these truths to be self-evident, so we've worked
                  up a proof of them as Appendix A." --  Paul Prescod

_______________________________________________
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