Re: http_inspect preprocessor and Snort sensor performance

[Jason <security () brvenik com>]

By disabling the preprocessor you are in essence telling the engine to 
inspect all of the server response data. The sub optimal part is that 
you have no optimization of inspection happening for http with the 
preprocessor disabled. You also lose normalization of data and reliable 
inspection of attacks destined to servers.

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