[Snort-users] Performance again
Lawrence.Reed at ...1444...
Tue Dec 23 10:26:04 EST 2003
> Certainly much more of a factor than the number of sessions or the
> size of packets is going to be what RTNs (rule tree nodes) the packets
> need to be processed against.
> Snort does a "first pass" elimination of rules to run against a packet
> based on the sourceIP, dest IP, protocol, source port and dest port
> specified in the rules. This "first pass" is very much faster than the
> content searching.
> A packet that winds up matching a combination of RTNs that has a long
> list of rules with lots of content searches is going to be a heavy hit
> in processing time. On the other hand a packet which winds up matching
> none of the combinations is going to have very little processing time.
> Thus really the type of packets matters quite a lot, and which packet
> types are 'bad' depends a lot on how your ruleset is constructed.. if
> every packet to a http server has to be evaluated against 800 content
> rules, that hurts. If HTTP_SERVERS is set to "any" and EXTERNAL_NET is
> set to "any" that hurts even more.
Has anyone done any work to try and quantify this? Or developed
hooks/patches to try and measure this? I have a scenario that I cannot
explain. I have the following perf output:
Notice the packet drop rate is 0.000 most of the time with occasional
spikes to a very high numbers. I have not been able to track this down
to a particular packet/session/time/mem limit/traffic rate.
You might also notice the my max-sessions is very high ( 100185 ). I
have increased the timeout and memcap parameters as follows:
preprocessor stream4: disable_evasion_alerts, keepstats binary, timeout
3600, memcap 178000000
Initially this caused packet loss problems when the memcap was reached
and a stream4 fault occurred. The fault logic only deleted 5 streams,
obviously that is not enough when I have 100,000 streams in memory. I
changed the code to delete 10% of max-streams and this packet loss has
I understand that is problem is easily solved with a faster CPU, but
thought the research would be interesting and fun. I am currently
running on a 1.2Ghz P III with 512Mb memory, snort 2.0.5 ( some stream4
patches ), Phil Wood's pcap with max ring buffer size, and a 100mb fast
ethernet sniffing interface.
The ruleset I am using is based on the current snort.org rules with many
modifications. Most of the mods are to increase the packets logged by
adding tag options.
>> I am simply trying to understand how is everything working together
>> as one complex system.
> Understood, and I'm just trying to explain the parts I understand.
> Your post had the conception that when a new packet arrived, the one
> that was being processed got dropped in the middle of some part of
> snort processing it.. it doesn't. The actual mechanism of drop winds
> up dropping the oldest packet in the queue that snort hasn't started
> processing yet.
Larry Reed Lawrence.Reed at ...1444...
NOAA IT Security Office
PGP Public Key: http://search.keyserver.net:11371/pks/lookup?op=get&search=0x7A998772
More information about the Snort-users