[Snort-sigs] [Emerging-Sigs] No real performance penalty?

elof at ...1288... elof at ...1288...
Wed Jan 18 09:30:41 EST 2012

Thanks Joel!
Just as I suspected then. Great!

Same question, different scenario:

If I have a rule that look for the evil pattern 'foobar' in all HTTP 
traffic like this:

(...; flow:established,to_server; content:"foobar"; depth:300; nocase; 
fast_pattern; ...)

My thoughts goes like this:
I want to detect 'foobar' in all web-traffic from a client to a server.

I don't want to optimize the rule using 'http_uri' or simillar keywords, I 
want to look for 'foobar' anywhere in the packet.

I add "depth:300;" anyhow, as an optimization so snort won't have to look 
through the *entire* packet.

Now, correct me if I'm wrong, but I think that the Fast Pattern Matcher 
look for my fast pattern 'foobar' throughout the *entire* packet *anyhow* 
(and if 'foobar' is found, the rule is marked for full evaluation).

When evaluated, snort will look for 'foobar' again, but this time only in 
the first 300 bytes.

So, I added the "depth:300;" just for optimization, but in reality I would
really prefer to have an alert if 'foobar' exist anywhere, even at the end 
of a 1500 byte packet...
Will there be any performance impact if I remove the depth keyword and 
replace it (and the "nocase") with "fast_pattern:only;"? Like this:

(...; flow:established,to_server; content:"foobar"; fast_pattern:only; ...)

I believe that this new rule work like this:
The Fast Pattern Matcher look for 'foobar' throughout the entire packet 
(case insensitive), and that's pretty much it. The rule is marked for 
evaluation but the only thest there is the flow check.

So in reality, the second rule syntax, which lack the depth constraint, is 
actually the more optimized one?

Am I thinking correctly? 
Anything else to be aware of?


On Wed, 11 Jan 2012, Joel Esler wrote:

> On Jan 11, 2012, at 6:30 AM, elof at ...1288... wrote:
>> Now, the main workload here is the Fast Pattern matching.
>> The test to see if the packet is actually coming from src port 23 is only
>> matched on the very few tcp packets that actually contain the pattern
>> "login incorrect".
> Right.
>> Have I got it right, or is there a major reason why I should not choose to
>> turn the telnet only rule into a general rule?
> False positives and alert generation.
> You'd be dealing with a ton of alerts instead of only ones on port 23.
> --
> Joel Esler
> Senior Research Engineer, VRT
> OpenSource Community Manager
> Sourcefire

More information about the Snort-sigs mailing list