Re: Poor performance using snort 2.8.x in inline mode

[Matt Watchinski <mwatchinski () sourcefire com>]

Some thoughts:

Are you using a Guest OS that supports vmware-tools ?  If so are they
installed ?

Do all the images running under ESXi have vmware-tools installed ?

Disable sfportscan
Disable perf_ profiling

Remove these compile options, they don't do anything for you.
--enable-inline-init-failopen - you don't have a failopen capable card
--enable-memory-cleanup - This wouldn't help with performance
--enable-pthread - this is used with init-failopen

Cheers,
-matt

On Wed, Jan 21, 2009 at 10:07 AM, carlopmart <carlopmart () gmail com> wrote:

> Ok I have disabled all rules with "alert ip" and throughput is 9.6MB/s ...
> But I
> need to use this type of rules ... How can I resolve this??
>
> And do I need to reconfigure any kernel param to increase throughput ??
>
> Joel Esler wrote:
> > Can you turn off some rules?  Try turning off your ip based rules first
> > (the ones that start with "alert ip".  There aren't very many of them in
> > the snort.org ruleset, not sure if you are running any custom rules.
> >
> > Joel
> >
> > On Jan 21, 2009, at 7:28 AM, carlopmart allegedly wrote:
> >
> > > Thanks Leon for your comments. First, I don't expect to reach real
> > > performance
> > > using snort inline as a vm guests that if it is a real machine. I have
> > > clear
> > > this point.
> > >
> > > But I need to setup this sensor to sniff DMZ traffic and block certain
> > > type of
> > > traffic. And another thing: this ESXi server is dedicated for a public
> > > DMZ, an
> > > only have four virtual machines, snort inline included ...
> > >
> > > Ok. I have recompiled snort binary another time with these options:
> > >
> > > --enable-inline --enable-inline-init-failopen  --enable-memory-cleanup
> > > --enable-pthread.
> > >
> > > And I have modified stream5 options:
> > >
> > > preprocessor stream5_global: max_tcp 4096, track_tcp yes, track_udp yes
> > > preprocessor stream5_tcp: policy first, use_static_footprint_sizes
> > > preprocessor stream5_udp: ignore_any_rules
> > >
> > > And results are (copying a 100MB file over ssh):
> > >
> > > a) With rules: 6.4MB/s
> > > b) Without rules: 12.0MB/s
> > >
> > > As you can seen, results are best in front of previous 940 Kb/s. I
> > > suspect that
> > > I need to do more tunning, but how can I increase this performance???
> > >
> > > Leon Ward wrote:
> > > > Hi.
> > > > I wouldn't /expect/ high performance out of an inline instance in
> > > > VMware, but with that said I have only used vmware inline instances of
> > > > Snort for test-labs where speed has never been an concern or
> > > > requirement. I haven't attempted to extract any real-world performance
> > > > requirements out of them.
> > > >
> > > > On top of the obvious device interrupt / poling at both hypervisor and
> > > > guest OS levels, how is your Snort configuration performing?
> > > >
> > > > Seeing this [1] in your .conf alone makes me think that some tuning may
> > > > be in order.
> > > > Take a look at README.PerfProfiling in /doc of the Snort tarball.
> > > >
> > > > Also run a test of inline with no rules enabled (just comment out all
> of
> > > > your rule include lines).
> > > >
> > > > -Leon
> > > >
> > > > [1]
> > > > # EmergingThreats Rules
> > > > include $RULE_PATH/emerging-attack_response.rules
> > > > include $RULE_PATH/emerging-botcc.rules
> > > > include $RULE_PATH/emerging-compromised.rules
> > > > include $RULE_PATH/emerging-dos.rules
> > > > include $RULE_PATH/emerging-exploit.rules
> > > > include $RULE_PATH/emerging-inappropriate.rules
> > > > include $RULE_PATH/emerging-malware.rules
> > > > include $RULE_PATH/emerging-p2p.rules
> > > > include $RULE_PATH/emerging-policy.rules
> > > > include $RULE_PATH/emerging-rbn.rules
> > > > include $RULE_PATH/emerging-tor.rules
> > > > include $RULE_PATH/emerging-virus.rules
> > > > include $RULE_PATH/emerging-web.rules
> > > > include $RULE_PATH/emerging.rules
> > > --
> > > CL Martinez
> > > carlopmart {at} gmail {d0t} com
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > SourcForge Community
> > > SourceForge wants to tell your story.
> > > http://p.sf.net/sfu/sf-spreadtheword
> > > _______________________________________________
> > > 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
> >
> >
> > --
> > Joel Esler
> >   http://www.joelesler.net
> >   http://www.twitter.com/joelesler
> > [m]
>
>
> --
> CL Martinez
> carlopmart {at} gmail {d0t} com
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> 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<https://lists.sourceforge.net/lists/listinfo/snort-usersSnort-users>list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users



-- 
Matthew Watchinski
Sr. Director Vulnerability Research Team (VRT)
Sourcefire, Inc.
Office: 410-423-1928

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

_______________________________________________
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