Re: order of matching rules

[Matt Kettler <mkettler () evi-inc com>]

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:
http://www.snort.org/docs/faq.html#3.13

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 
configuration.

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:
> The site
> http://www.infosys.tuwien.ac.at/snort-ng/
> mentions that "For some strange reason, Snort stops
> the detection process for a packet after the first
> matching
> 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?
> Archana



-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
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