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.
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
It's my understanding that the rules get built into chains that
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
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