No subject


Thu Nov 23 16:36:19 EST 2017


> 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 at ...671...>
 "Not everyone holds these truths to be self-evident, so we've worked
                  up a proof of them as Appendix A." --  Paul Prescod




More information about the Snort-users mailing list