<br><br><div class="gmail_quote">On Mon, Oct 18, 2010 at 6:57 PM, Tomas Heredia <span dir="ltr"><<a href="mailto:tomas.heredia@...12297...">tomas.heredia@...12297...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 El 18/10/2010 07:27 p.m., Joel Esler escribió:<br>
<div class="im">> On Oct 18, 2010, at 5:51 PM, Tomas Heredia wrote:<br>
>> Hi all!<br>
>><br>
>> Lately, new rules applied to our sensor started to consume too much CPU<br>
>> (not too much, but causing host load to go to 0.4 permanent). I folowed<br>
>> the problem and found it was PCRE causing it. The problem is that this<br>
>> is causing some TREMENDOUS delays in packets... from 50 to 1000 ms, in<br>
>> some packets (doing a ping, 1 every 30 or so packets gets delayed).<br>
>><br>
>> So, How do yo think "config pcre_match_limit 100" and "config<br>
>> pcre_match_limit_recursion 100" would affect detection? (as false<br>
>> negatives).<br>
>><br>
>> Do you have any other sugestion (aside from not using pcre rules :-)) to<br>
>> get beter PCRE performance?<br>
> Are you running in inline mode, or IDS mode?  Are you dropping packets?<br>
</div>Excuse me :-)<br>
Inline mode. Snort 2.8.6.0 (Ok, planning upgrade anyway). No packets get<br>
droped. Just huge delays in some packets. Delay goes off if I put<br>
<br>
config pcre_match_limit 25<br>
onfigpcre_match_limit_recursion 25<br>
<br>
But I don't think it's a good idea. Is it?<br>
</blockquote><div> </div><div>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.</div><div><br></div><div>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:</div>
<div><br></div><div>config profile_rules: print 50, sort avg_ticks</div><div><br></div><div>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.</div>
</div><br clear="all"><br>-- <br>Alex Kirk<br>AEGIS Program Lead<br>Sourcefire Vulnerability Research Team<br>+1-410-423-1937<br><a href="mailto:alex.kirk@...1935...">alex.kirk@...1935...</a><br>