[Snort-devel] Rules Engine
roesch at ...48...
Tue Apr 17 12:44:47 EDT 2001
Good idea. I outlined this approach a week or two ago on this list in
response to another thread and it's a good thing to implement. OTOH,
I've been doing some performance testing over the last couple days and
I'm realizing that the decoder and detection engine is fast as hell and
almost all of our performance problems lie in the output stage. While
this would save us more clock cycles in the short term to do output
things with, I'd put it at a lower priority than some other things we
can be working on (i.e. faster output).
Implementing a system like this would require some
rethinking/reimplementation of the rules engine because it's not setup
to be tree'd like this at all. We can discuss it more once the 1.8
system has been released.
Jason Larsen wrote:
> I'm trying to optimize the rules engine a little bit, but some of the code
> takes a little to understand. I'm thinking of arranging the rules in a
> You don't have to apply the modifiers of all the rules to all the packets.
> For instance. A packet that has "flags:A" and "flags:S" are mutually
> exclusive. You could arrange the rules in a tree cutting out a bunch
> of them at each branching.
> For instance:
> ALL Rules
> | | | |
> S A P No flags flags
> If a packet had only the SYN flag set, you could immediately eliminate the
> branches for ACK and PUSH. You could similarly eliminate branches based
> on source/destination port/ip.
> Each test would then eliminate more branches starting with the operations
> that are
> least CPU intensive and ending with the operations that are most CPU
> intensive (content).
> The fewer contents we have to actually execute the faster snort will run.
> Just a thought. What do you guys think?
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
roesch at ...48...
More information about the Snort-devel