Snort mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: carlopmart <carlopmart () gmail com>
Date: Fri, 23 Jan 2009 15:56:44 +0100
Ok, I can reach an acceptable throughput finally. I have recompiled snort using 
only inline and duynamicplugins params. After this I have increased ip_queue to 
8192 and stream5_global max_tcp to 8192 also ... and throughput is between 9,8 
MB/s and 10.2 MB/s ...

For me it is ok now.

Many thanks to all for your help.

Matt Watchinski wrote:

Just out of curiosity, what number does your gut tell you, you can reach 
throughput wise?

Some other things to try.

send the output of the rule and preprocessor profiling to this list.
take cpu stats with top every second during the throughput testing and 
send it in.
remove snort from the equation and see how fast ip_queue is in simple 
bridge mode.  Do like 10 tests and take the average, send it in.
run vmstat -i during the test every second or so, so we can see the 
interrupt rate

on the host os if it has a /proc/interrupts tail that during the test 
and post.
probably do this on the guest vm also.

shut down all the other hosts on the ESXi and see if performance improves.

Also when I mentioned perf profiling i mean these lines in your snort.conf

config profile_rules: print all, sort total_ticks
config profile_preprocs: print all, sort checks

Just incase you thought i meant perfmon.


On Wed, Jan 21, 2009 at 12:21 PM, carlopmart <carlopmart () gmail com 
<mailto:carlopmart () gmail com>> wrote:

    I have disabled sfportscan and results are the same ... I don't use
    perf profiling and all guests are supported OS (rhel5.x) and all
    they have vmware tools installed ...

    Matt Watchinski wrote:

        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 <mailto:carlopmart () gmail com>
        <mailto:carlopmart () gmail com <mailto: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 <http://snort.org> <http://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
        <mailto:Snort-users () lists sourceforge net>
           <mailto:Snort-users () lists sourceforge net
        <mailto: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
        <mailto:Snort-users () lists sourceforge net>
           <mailto:Snort-users () lists sourceforge net
        <mailto: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



    -- 
    CL Martinez
    carlopmart {at} gmail {d0t} com




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



-- 
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
Previous By Date Next
Previous By Thread Next

Current thread: