[Snort-users] pcre high cpu usage

Alex Kirk akirk at ...1935...
Mon Oct 18 19:13:44 EDT 2010

On Mon, Oct 18, 2010 at 6:57 PM, Tomas Heredia
<tomas.heredia at ...12297...>wrote:

>  El 18/10/2010 07:27 p.m., Joel Esler escribió:
> > On Oct 18, 2010, at 5:51 PM, Tomas Heredia wrote:
> >> Hi all!
> >>
> >> Lately, new rules applied to our sensor started to consume too much CPU
> >> (not too much, but causing host load to go to 0.4 permanent). I folowed
> >> the problem and found it was PCRE causing it. The problem is that this
> >> is causing some TREMENDOUS delays in packets... from 50 to 1000 ms, in
> >> some packets (doing a ping, 1 every 30 or so packets gets delayed).
> >>
> >> So, How do yo think "config pcre_match_limit 100" and "config
> >> pcre_match_limit_recursion 100" would affect detection? (as false
> >> negatives).
> >>
> >> Do you have any other sugestion (aside from not using pcre rules :-)) to
> >> get beter PCRE performance?
> > Are you running in inline mode, or IDS mode?  Are you dropping packets?
> Excuse me :-)
> Inline mode. Snort (Ok, planning upgrade anyway). No packets get
> droped. Just huge delays in some packets. Delay goes off if I put
> config pcre_match_limit 25
> onfigpcre_match_limit_recursion 25
> But I don't think it's a good idea. Is it?

No, that's a terrible idea. You might as well just disable all the rules
that use PCRE if you set a limit that low.

Chances are high, based on the collective experience of the group, that
you've got a small number of rules hogging a large amount of processing
power, and if you can identify them and either tune or disable them, you'll
be in way better shape. To ID them, you'll want to enable:

config profile_rules: print 50, sort avg_ticks

This will print the top 50 worst offending rules, in order of the average
number of CPU "ticks" it takes to run them, on exit. See the
README.PerfProfiling file and the list archives for more information if you
need it.

Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
alex.kirk at ...1935...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20101018/9c72df02/attachment.html>

More information about the Snort-users mailing list