[Snort-sigs] Overhead caused by PCRE?

Brian bmc at ...95...
Wed Mar 2 08:17:20 EST 2005

On Mon, Feb 28, 2005 at 05:22:43PM -0800, Jeff McCarthy wrote:
> I have a question regarding using PCRE in Snort rules.  If I write
> 100 rules using content: and 100 using PCRE, will there be a
> noticable difference in processing time or CPU utilization?

Yes & No.  I'll try to explain with the 4 different cases I come
across on a regular basis.

1) single rule, single string match

   In the single rule string match case, both PCRE & content use
   boyer-moore.  However, pcre has a small amount of additional
   function call overhead, giving content a slight win.  However, in
   most cases the additional overhead is negligible.

2) multiple single string match

   If all the rules are doing is a simple string match, pcre will win
   by a long shot if implemented as a single combined pcre statement.  
   While the multi-pattern match engine in Snort can be faster, the
   additional function call overhead of evaluating multiple rules
   makes pcre the clear winner.

   This implementation has the drawback of Snort only generating a
   single message for all of the patterns that make up the pcre.  This
   method should only be used when this drawback is acceptable.
   See virus.rules for an example for an example of a "optomized"
   combined pcre statement.
3) multiple rules, single string match and other detection plugins

   content wins here, same as in the single rule single content.
   Multiple pcre statements are slower than multiple contents.

4) multiple rules, complex pattern match

   If the string match is more complicated than what can be
   implemented with "strcmp", then pcre is the only way to go.
   content can't do complicated pattern matching, so pcre is the only
   method available.  As such pcre wins.


More information about the Snort-sigs mailing list