Re: http_inspect preprocessor and Snort sensor performance

[Todd Wease <twease () sourcefire com>]

The flow_depth in http_inspect tells the detection engine how much of 
the server packet payload to inspect.  I suspect the degradation in 
performance is Snort spending alot of time inspecting the entire server 
payload.  The flow_depth option was specifically put into http_inspect 
to improve performance.

Humes, David G. wrote:
> I have been running the perfmon preprocessor for a few years now and
> graphing the results using the pmgraph.pl script.  So, when I make any
> changes it's easy to see if they have a negative overall impact on the
> sensor by monitoring the drop rate, cpu stats, etc.  I noticed that sensor's
> drop rate increases significantly if the http_inspect preprocessor is NOT
> running.  If I comment out all of the http_inspect lines in snort.conf and
> restart snort, the drop rate jumps up to around 30%.  When I enable
> http_inspect, the drop rate hovers around 1-2%, more than I would like, but
> that's a problem for another day.  This result is somewhat
> counter-intuitive.  It would seem that snort has to do more work to inspect
> HTTP traffic, which could result in an increased drop rate in a sensor that
> is near it's maximum capability.  
>  
> I tried adjusting the flow_depth setting for http_inspect since I know it
> can have a significant impact on performance.  If I set flow_depth to 0
> (Inspect all server-side traffic), then I get the same result as disabling
> http_inspect, i.e. the drop rate goes way up.  If I set it to -1 (Ignore all
> server-side traffic), then the drop rate remains at a favorable level.
> Setting it to 300 (the default) also results in favorable performance.  So,
> from this one might conclude that disabling http_inspect by commenting out
> all of it's configuration lines in snort.conf does not really disable it,
> but only invokes some default, suboptimal configuration.  Or, maybe the
> extra work done by http_inspect is offset by a diminished workload in the
> rules engine.  Hopefully someone who knows a lot more about snort than me
> can explain this behavior.  We are running snort 2.8.0.2.  But, I have seen
> this behavior as far back as 2.4.  
>  
> Dave Humes 
> Johns Hopkins University Applied Physics Laboratory 
> Telecommunications Group (ITC) 
> david.humes () jhuapl edu 
> 443-778-6651 
>
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users