[Snort-sigs] Re: pcre (was:To build a logical AND expression)
Daniel J. Roelker
droelker at ...435...
Mon Dec 15 12:38:02 EST 2003
On Mon, 2003-12-15 at 11:04, Martin Olsson wrote:
> Yes, pcre will probably solve a lot of issues nicely.
> I'm just wondering what the performance impact will be... I fear that the
> pcre engine will punish snort CPU and memory performance.
The snort 2.* detection engine is designed to act like a high-level
filter with content keywords, so that we don't process the more
intensive detection plugins (like pcre) on packets and streams that
don't need or require it.
As long as you use a content keyword to help filter out packets that
don't match (even if that content is contained in the pcre keyword), you
shouldn't have a serious performance hit at all.
But . . . (see next comment)
> The human nature is to be lazy and do things the easy way, so I'm afraid
> that people will create simple pcre-rules for everything instead of
> handcrafting an optimized rule that use as little recourses as possible.
I agree with you completely. We have yet to see how users will [ab]use
this keyword, and I may have to take back my previous statement about no
performance impact. :)
Depending on how users feel about this plugin (if it's a great addition
to the rule language or just "helpful") we may implement a smaller
subset of pcre usage so we can optimize the heck out of it. But most of
this depends on how much it's used and if there is a performance impact
even when there are lots of pcre rules..
For the record, pcre should really be seen as a last resort to detect
intrusion attempts and hard analysis is still required to write a
What's that? Did I hear someone say obfuscated snort rule competition?
More information about the Snort-sigs