[Snort-sigs] Overhead caused by PCRE?
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