[Snort-devel] New feature wanted: Rule matching stats
marc.norton at ...402...
Mon Jul 7 06:30:27 EDT 2003
Sorry for jumping in the middle, but Snort 2.0 behaves quite differently
from the 1.x series. At least in terms of pattern matching things are
Briefly, we try to build groups of rules to apply to packets based on
their protocols. We do a single high speed multi-content search pass.
If any rules in the rule group we've selected to apply to a packet have
content matching content in the packet we do a complete inspection of
the packet for that rule using the standard snort rule inspection code.
We also mark the rule as tested against the packet so we won't do it
again for the same packet, in case the pattern repeats. In 1.xx series
of snort content was matched last, now it is used 1st in a higher speed
multi-pattern matching pass. We really have a 2 stage process for
pattern matching. This turns out to be a very efficient method for
eliminating traffic from detailed pattern matching. Anyways, while
further optimizations are possible, they will probably be systemic
optimizations that affect the whole data flow of traffic through the
inspection process. But have at it, ideas are the future and are
From: snort-devel-admin at lists.sourceforge.net
[mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of Gianni
Sent: Monday, July 07, 2003 8:38 AM
To: Martin Olsson
Cc: snort-devel mailinglist
Subject: Re: [Snort-devel] New feature wanted: Rule matching stats
On Mon, 2003-07-07 at 13:21, Martin Olsson wrote:
> > This is a cool idea and one I have ruminated on for a while. I think
> > best solution would be dynamically updated.
> I don't know if that is possible, that's why I only asked for the
> to dump statistics, and then manually optimize the rules.
> Isn't the _order_ of rules loaded important? If I have a rule matching
> "C:\WINNT\SYSTEM32" and another one matching only "C:\", I don't want
> latter to be moved in front of the first by an optimizing routine...
Not sure, I think snort2.0 does some more complex stuff whereby it scans
all rules for which a pattern matched; that would kind of demolish the
"move the most matched rules to the front of the list thing" if they are
all going to be matched anyway...
I think our real case for optimisation is probably by moving the OTNs
most likely to cause a mis-match to the head of the list, eg if you
ttl<100; seq: 666;
then seq is prolly gonna mismatch more than the ttl, making it wise to
put seq to the head of the list, so you can skip that rule quicker.
Obviously by recording hit/miss count, you can know which is really most
likely. Most of the rules seem optimised for this kind of thing anyway,
so it's probably not much of a win...
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
More information about the Snort-devel