[Snort-users] order of matching rules
mkettler at ...4108...
Wed Oct 16 17:29:03 EDT 2002
No, the rules are not applied (strictly) in the order the exist in the
files, they are applied in the order that they exist in the RTN/OTN structures.
See the snort FAQ for a more detailed explanation:
I'm pretty sure that snort 1.9 still does at most one alert per packet.
Some parts of the ruleset are designed to expect this behavior.
As for snort-ng I'll admit I've not examined their software or site to any
great degree, but I'd be very cautious of accepting that it's an
improvement in the general case. I'll also admit upfront I'm an engineer
and I'm skeptical of test results which don't include any realistic
scenarios. I know full well how to create bogus test scenarios which make
either side of a comparison look good, and I know that a good "realistic"
test is extremely difficult to create.
I remember a couple years ago a paper was written on a means of "greatly
improving snort performance" by changing the string matching code. But the
method used substantially more memory, and was only an improvement when you
had a large number of repeated characters in a rule. The test cases used in
that paper to demonstrate the improvement were unrealistic scenarios which
would magnify the problems in snort they were improving. I've never seen
any data testing the performance of this method on a realistic ruleset and
The graphs in the snort-ng site compare a percentage of matches as the
"number of rules" increases, a reasonable evaluation, but no data is
provided as to what rules were used. Obviously I can sit down and create my
own set of rules which penalizes the existing structure of snort heavily,
and then come up with an "optimization" which improves this case but does
not improve a realistic setup.
I'm not trying to accuse snort-ng of "rigging the test" but given the data
present on the snort-ng site and in their whitepaper, it's hard to decide
if their improvements are realistic, or if their test is somehow biased to
show an improvement when one does not exist. There's just not quite enough
information about the test setup. I *assume* they used the default ruleset
and trimmed it down sequentially, but there's no detail stating exactly
what ruleset was used and how the ruleset was shortened in the
"experimental data" section of the paper.
I'm also skeptical of the stability of this code given that the original
code did not handle ip fragments without a segfault. They've fixed that
since, but does the additional check degrade the performance? what other
sanity and stability checks have been skipped to get more impressive graphs?
I'd also like to see how much impact this has when logging and
preprocessors are enabled. All of the tests were done with logging and
preprocessors off to focus strictly on the performance of the rule matching
code which is a reasonable test case, but I'd also like to see it compared
in a "real world" setup where logging is enabled as well. I'm concerned
that if most of snort's bottleneck is in the logging side, improving the
performance of the rule processing is helpful but has limited returns. I'd
also love to see some memory consumption comparisons. If the new rule
processor consumes significantly more memory in some scenarios this may
wind up reducing the amount of memory available for disk buffering, causing
a detriment to the logging end and possibly degrading the total performance
of the system to be worse than the original.
I'd also susupect that the added log output of matching every packet
against every rule will generate a considerably greater amount of log
output, resulting in dramatically worse performance when using the default
snort ruleset, negating the all the performance gain of the faster matching
code until a new ruleset which is oriented towards the new snort-ng is written.
Overall snort-ng looks interesting, but their current test data isn't
sufficient to be convincing that this actually helps realistic snort
configurations. It certainly is convincing that in the lab environment of a
snort sensor that doesn't log it's alerts they've created a substantial
improvement to the rule processing speed of snort.
At 03:47 PM 10/16/2002 -0700, archana rao wrote:
>mentions that "For some strange reason, Snort stops
>the detection process for a packet after the first
>rule - maybe to improve performance" while talking
>about snort-ng. Is this the way it works in
>Snort-1.9.0 too?In what order are the rules matched
>against the incoming packets?Is it the order in which
>they are listed in the *.rules file?
More information about the Snort-users