Re: [Emerging-Sigs] weirdness

[Steven Sturges <steve.sturges () sourcefire com>]

Patterns are checked first as the performance optimization in the
fast pattern matcher & detection process.  That's been the case since
like 2.8.2 or so.  The pattern group is selected based on ports.
Correctly specifying the src/dst ports would cause the pattern to
only be included in the appropriate pattern group and searched
accordingly.

Having unique patterns that are used for fast pattern searches will
increase the benefit.  Default is to use the longest pattern, but if
there is a shorter pattern that is more unique, use the fast_pattern
modifier to content.

Sounds like the rules may need to be updated to work better with the
current technology.

Cheers.
-steve

On 8/16/2010 2:57 PM, Will Metcalf wrote:

> ya sure... also UPDATE or whatever should be added to fast_pattern as
> by default it will try to use index.php, but my question was more as
> to why they tried to match in the first place. If the pm  is invoked
> before checking flow/traffic dir then changes need to made to some
> rules.  For example if the fast_patten matcher is invoked before
> dir/flow_check then sigs that contain things like "index.php" in the
> uricontent, and this match is the longest match will be partially
> checked for traffic in all directions. this would include ohh say your
> clients browsing the internet.  This is ok I guess, just looking for
> some clarification... SF?
>
> Regards,
>
> Will
>
> On Mon, Aug 16, 2010 at 1:28 PM, Kevin Ross <kevross33 () googlemail com>
> wrote:
> > > On the ones that aren't my PCRE nightmare rule ( :D ) why is there a .+
> > > before the first content match in the PCRE?
> > >
> > > On 16/08/2010, Will Metcalf <william.metcalf () gmail com> wrote:
> > > > > So I was doing some perf profiling of ET sigs and I'm seeing
something
> > > > > sort of odd working with snort-2.8.6.1 that perhaps someone form SF
> > > > > can explain to me.  I have a pcap that has all public traffic in
it, I
> > > > > forgot to modify $HOME_NET to be the proper public address space and
> > > > > instead left it as rfc1918 addys. I have perf stats turned on and it
> > > > > seems that the worst performing rules are rules which try to match on
> > > > > something like...
> > > > >
> > > > > alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"some msg";
> > > > > flow:established,to_server; uricontent:"common match";
> > > > > uricontent:"short match";
> > > > >
> > > > > My question is... why is this?  shouldn't flow direction, state, and
> > > > > direction of the traffic prevent the pm from being invoked in the
> > > > > first place?  Just to verify I didn't have any internal traffic
> > > > > floating around the pcap, I made a new pcap from the original
> > > > > excluding everything that should be in my $HOME_NET
> > > > >
> > > > > #generate new pcap
> > > > > tcpdump -w norfc1918.pcap -r /pcaps/nofuzz/publictraffic.pcap not net
> > > > > \(10.0.0.0/8 or 192.168.0.0/16 or
172.16.0.0/12\<http://172.16.0.0/12%5C>
> )
> > > > > #validate there is no internal traffic in the pcap
> > > > > wmetcalf@blah:~/idstoolout$ tcpdump -n -r norfc1918.pcap net
> > > > > \(10.0.0.0/8 or 192.168.0.0/16 or
172.16.0.0/12\<http://172.16.0.0/12%5C>
> )
> > > > > reading from file norfc1918.pcap, link-type EN10MB (Ethernet)
> > > > > wmetcalf@blah:~/idstoolout$
> > > > >
> > > > > #relevant bits of the snort.conf
> > > > > var HOME_NET [10.0.0.0/8,192.168.0.0/16,172.16.0.0/12]
> > > > > # Set up the external network addresses.  A good start may be "any"
> > > > > var EXTERNAL_NET any
> > > > >
> > > > > # List of DNS servers on your network
> > > > > var DNS_SERVERS $HOME_NET
> > > > >
> > > > > # List of SMTP servers on your network
> > > > > var SMTP_SERVERS $HOME_NET
> > > > >
> > > > > # List of web servers on your network
> > > > > var HTTP_SERVERS $HOME_NET
> > > > >
> > > > > # List of sql servers on your network
> > > > > var SQL_SERVERS $HOME_NET
> > > > >
> > > > > # List of telnet servers on your network
> > > > > var TELNET_SERVERS $HOME_NET
> > > > >
> > > > > # List of ports you run web servers on
> > > > > portvar
> > > > > HTTP_PORTS
[80,2301,3128,7777,7779,8000,8008,8028,8080,8180,8888,9999]
> > > > > #cli for running the pcap through snort-2.8.6.1
> > > > > /opt/snort2861/bin/snort -c /opt/snort2861/etc/snort.conf -l ./ -A
> > > > > console -k none -q -r norfc1918.pcap
> > > > >
> > > > > #top three lines of per stats
> > > > > Rule Profile Statistics (worst 50 rules)
> > > > > ==========================================================
> > > > >   Num      SID GID Rev     Checks   Matches    Alerts
> > > > > Microsecs  Avg/Check  Avg/Match Avg/Nonmatch
> > > > >   ===      === === ===     ======   =======    ======
> > > > > =========  =========  ========= ============
> > > > >     1  2006614   1   5      12511         0         0
> > > > > 297276       23.8        0.0         23.8
> > > > >     2  2011189   1   2         15         0         0
> > > > > 323       21.6        0.0         21.6
> > > > >     3  2003794   1   6         20         0         0
> > > > > 376       18.8        0.0         18.8
> > > > >
> > > > > #Top three worst performing rules.. Why? shouldn't flow and traffic
> > > > > dir prevent these from being checked.
> > > > >
> > > > > alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET
> > > > > WEB_SPECIFIC_APPS iWare Professional SQL Injection Attempt --
> > > > > index.php D UPDATE"; flow:established,to_server;
> > > > > uricontent:"/index.php?"; nocase; uricontent:"D="; nocase;
> > > > > uricontent:"UPDATE"; nocase; pcre:"/.+UPDATE.+SET/Ui";
> > > > > classtype:web-application-attack; reference:cve,CVE-2006-6446;
> > > > > reference:url,www.securityfocus.com/bid/21467;
> > > > > reference:url,doc.emergingthreats.net/2006614;
> > > > >
> > > > > reference:url,
www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_iWare_Pro
> ;
> > > > > sid:2006614; rev:5;)
> > > > >
> > > > > alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET
> > > > > WEB_SPECIFIC_APPS Possible Cisco IOS HTTP Server Cross Site Scripting
> > > > > Attempt"; flow:established,to_server; content:"GET "; depth:4;
> > > > > uricontent:"/ping?"; nocase;
pcre:"/ping.+(script|alert|onmouse[a-z]+|onkey[a-z]+|onload|onunload|ondragdrop|onblur|onfocus|onclick|ondblclick|onsubmit|onreset|onselect|onchange)/Ui";
> > > > > classtype:web-application-attack;
reference:url,tools.cisco.com/security/center/viewAlert.x?alertId=17364;
> > > > > reference:url,
www.cisco.com/en/US/products/products_security_response09186a0080a5c501.html
> ;
> > > > > reference:cve,2008-3821;
> > > > > reference:url,doc.emergingthreats.net/2011189;
> > > > >
> > > > > reference:url,
www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_Cisco;
> > > > > sid:2011189; rev:2;)
> > > > >
> > > > > alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET
> > > > > WEB_SPECIFIC_APPS CMS Made Simple SQL Injection Attempt --
> > > > > stylesheet.php templateid SELECT"; flow:established,to_server;
> > > > > uricontent:"/stylesheet.php?"; nocase; uricontent:"templateid=";
> > > > > nocase; pcre:"/.+SELECT.+FROM/Ui"; classtype:web-application-attack;
> > > > > reference:cve,CVE-2007-2473;
> > > > > reference:url,www.securityfocus.com/bid/23753;
> > > > > reference:url,doc.emergingthreats.net/2003794;
> > > > >
> > > > > reference:url,
www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_CMS_Made_Simple
> ;
> > > > > sid:2003794; rev:6;)

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
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