[Snort-users] [Emerging-Sigs] weirdness

Steven Sturges steve.sturges at ...1935...
Mon Aug 16 23:52:32 EDT 2010


Correct... the pattern group will be selected based on the ports.
Through our many years of research, we've found that qualifying
rules based on pattern, then individual rule options, then by
IP addrs & UDP/TCP hdr ports is most efficient in terms of speed
and memory efficiency.

You could create the pattern groups based on IP & Port, but
the memory space for that many pattern match instances would be
pretty significant.

And, typically, you won't see traffic on your link unless its very
closely related to your IP or subnet.  Otherwise, you could snoop
everyone's in & outbound traffic across the entire ISP, etc.

This almost sounds like a matter of tuning the ruleset for where Snort
is deployed....

Cheers.
-steve

On 8/16/2010 9:21 PM, Will Metcalf wrote:
> Steve,
> 
> Thanks for the response.  So just to make sure I understand pattern
> groups are built based on port but without taking into account src/dst
> ip addys correct?
> So say we have a rule that is something like
> 
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"foo";
> uricontent:"source="; pcre:"/source=[0-9a-zA-Z]{300,}/"; sid:777;)
> 
> Let's say this is watching the public ip space of a company.  This
> means that before anything else is checked in this sig will be checked
> for a uricontent of "source=" on $HTTP_PORTS.  So while this may be
> fairly unique for say a server in the DMZ for this company it will
> partially match on every google search result for clients sharing the
> same public space right?
> 
> Regards,
> 
> Will
> 
> On Mon, Aug 16, 2010 at 6:37 PM, Steven Sturges
> <steve.sturges at ...1935...> wrote:
>> 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 at ...14012...>
>>> 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 at ...11827...> 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 at ...3425...:~/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 at ...3425...:~/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;)
>>
> 




More information about the Snort-users mailing list