[Emerging-Sigs] Bad Performing Rules

Matthew Jonkman jonkman at emergingthreatspro.com
Tue Oct 11 06:31:47 EDT 2011


On Oct 7, 2011, at 4:13 PM, Nathan wrote:

> I'm building up some new ET gear in a very high volume area and I'm
> performance profiling.  I've found a few bad performing rules, some a little
> horrific (as in PCRE only).
> 
> #Strange that flow-bit check only rule is so bad at performing, is it because
> it's instanced for every packet to check the state of a flowbit because there
> is no content match on it?
> emerging-policy.rules:alert tcp any !$SSH_PORTS -> any !$SSH_PORTS (msg:"ET
> POLICY SSH session in progress on Unusual Port"; flowbits: isset,is_proto_ssh;
> threshold: type both, track by_src, count 2, seconds 300;
> classtype:misc-activity; reference:url,doc.emergingthreats.net/2001984;
> sid:2001984; rev:7;)

Yes. This is the only way we have to do this, which is why we've made suricata do things differently. This won't be a high load sig there. Can you go suricata?

> 
> #PCRE only pretty much, needs http_uri and a split into two rules
> emerging-web_specific_apps.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
> $HTTP_PORTS (msg:"ET WEB_SPECIFIC_APPS Cacti Input Validation Attack";
> flow:established,to_server; content:"GET"; http_method; nocase;
> pcre:"/(config_settings|top_graph_header)\.php\?.*=(http|https)\:\//Ui";
> classtype:web-application-activity; reference:url,www.cacti.net;
> reference:url,www.idefense.com/application/poi/display?id=265&type=vulnerabilities;
> reference:url,www.idefense.com/application/poi/display?id=266&type=vulnerabilities;
> reference:url,doc.emergingthreats.net/2002129; sid:2002129; rev:11;)

Good catch. We'l get that fixed up!  (Pedro, can you get that one split up?)

> 
> #Not sure anything can be done here...
> emerging-malware.rules:alert udp $EXTERNAL_NET 32768:61000 -> $HOME_NET
> 1024:65535 (msg:"ET MALWARE SOCKSv5 UDP Proxy Inbound Connect Request (Linux
> Source)"; content:"|00 00|"; depth:2; content:"|01|"; offset:3; depth:1;
> threshold:type both, track by_dst, count 1, seconds 900;
> classtype:protocol-command-decode;
> reference:url,handlers.sans.org/wsalusky/rants/;
> reference:url,en.wikipedia.org/wiki/SOCKS;
> reference:url,ss5.sourceforge.net/socks4.protocol.txt;
> reference:url,ss5.sourceforge.net/socks4A.protocol.txt;
> reference:url,www.ietf.org/rfc/rfc1928.txt;
> reference:url,www.ietf.org/rfc/rfc1929.txt;
> reference:url,www.ietf.org/rfc/rfc1961.txt;
> reference:url,www.ietf.org/rfc/rfc3089.txt;
> reference:url,doc.emergingthreats.net/bin/view/Main/2003287; sid:2003287;
> rev:6;)

Ya, this is a valuable sig, but the short matches are painful. I'd recommend only running if needed.



> 
> #Or hereemerging-malware.rules:alert udp $EXTERNAL_NET 1024:5000 -> $HOME_NET
> 1024:65535 (msg:"ET MALWARE SOCKSv5 UDP Proxy Inbound Connect Request (Windows
> Source)"; content:"|00 00|"; depth:2; content:"|01|"; offset:3; depth:1;
> threshold:type both, track by_dst, count 1, seconds 900;
> classtype:protocol-command-decode;
> reference:url,handlers.sans.org/wsalusky/rants/;
> reference:url,en.wikipedia.org/wiki/SOCKS;
> reference:url,ss5.sourceforge.net/socks4.protocol.txt;
> reference:url,ss5.sourceforge.net/socks4A.protocol.txt;
> reference:url,www.ietf.org/rfc/rfc1928.txt;
> reference:url,www.ietf.org/rfc/rfc1929.txt;
> reference:url,www.ietf.org/rfc/rfc1961.txt;
> reference:url,www.ietf.org/rfc/rfc3089.txt;
> reference:url,doc.emergingthreats.net/bin/view/Main/2003286; sid:2003286;
> rev:7;)

Same. Useful but expensive.

> 
> #Meh?
> emerging-web_client.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
> (msg:"ET WEB_CLIENT PROPFIND Flowbit Set"; flow:established,to_server;
> content:"PROPFIND"; http_method; nocase; flowbits:set,ET_PROPFIND;
> flowbits:noalert; classtype:misc-activity; sid:2011456; rev:3;)

Useful for other sigs. But, perhaps we can integrate the propfind in to the target sig. Pedro, can you look at the igs that check the ET_PROPFIND flowbit and see if we can just go prop find and http_method?

> 
> #Guilty, I wrote this one.  Perhaps http_raw_uri is bad for performance
> afterall.  What if we just drop it down to
> content:"/pdf_err__Error__Unspecified"; http_uri;
> emerging-current_events.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET
> $HTTP_PORTS (msg:"ET CURRENT_EVENTS Unknown Exploit Kit request for
> pdf_err__Error__Unspecified"; flow:established,to_server;
> content:"/pdf_err__Error__Unspecified%20error..gif"; http_raw_uri;
> classtype:trojan-activity; sid:2013693; rev:2;)

I think that's a good way to go. Shorten the forst uri and remove the http_raw_uri match. 

> 
> #May be worth keeping, how often do we see it fire? I think I wrote these...
> emerging-scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS
> (msg:"ET SCAN HTTP OPTIONS invalid method case"; flow:established,to_server;
> content:"options"; http_method; nocase; content:!"OPTIONS"; http_method;
> classtype:bad-unknown;
> reference:url,www.w3.org/Protocols/rfc2616/rfc2616-sec9.html;
> reference:url,doc.emergingthreats.net/2011034; sid:2011034; rev:4;)

Can we anchor that to the start of the packet?


> 
> #Work keeping I believe, I think I wrote these...
> emerging-scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS
> (msg:"ET SCAN HTTP POST invalid method case"; flow:established,to_server;
> content:"post"; http_method; nocase; content:!"POST"; http_method;
> classtype:bad-unknown;
> reference:url,www.w3.org/Protocols/rfc2616/rfc2616-sec9.html;
> reference:url,doc.emergingthreats.net/2011032; sid:2011032; rev:4;)
> 

Yes, very valuable. but we didn't anchor. We ought to be able to, no?


> #Worth keeping?  I think I wrote these...
> emerging-scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS
> (msg:"ET SCAN HTTP HEAD invalid method case"; flow:established,to_server;
> content:"head"; http_method; nocase; content:!"HEAD"; http_method;
> classtype:bad-unknown;
> reference:url,www.w3.org/Protocols/rfc2616/rfc2616-sec9.html;
> reference:url,doc.emergingthreats.net/2011033; sid:2011033; rev:7;)
> 

Same as above. Lets anchor.

> #Another flowbit check, should we add content:"Java/"; http_header; ?  Why are
> flowbit-only checks so performance degrading?  Instanced every packet?
> emerging-trojan.rules:alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
> (msg:"ET TROJAN Java EXE Download by Vulnerable Version - Likely Driveby";
> flowbits:isset,ET.http.binary; flowbits:isset,ET.http.javaclient.vulnerable;
> flow:established,to_client; threshold:type limit,track by_src,count 1,seconds
> 3; classtype:trojan-activity; sid:2013036; rev:1;)

I don't know why they're so bad in snort, but we have no option here to fix afaik. Other than to go suricata. :)

> 
> #same, flowbit only
> emerging-policy.rules:alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
> (msg:"ET POLICY Java EXE Download"; flowbits:isset,ET.http.binary;
> flowbits:isset,ET.http.javaclient; flow:established,to_client; threshold:type
> limit,track by_src,count 1,seconds 3; classtype:trojan-activity; sid:2013037;
> rev:1;)

Same as above. But these are very very valuable sigs. Very!

> 
> #Probably worth keeping but this one is just SYN port based.
> emerging-scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg:"ET SCAN
> Rapid IMAP Connections - Possible Brute Force Attack"; flags: S,12; threshold:
> type both, track by_src, count 30, seconds 60; classtype: misc-activity;
> reference:url,doc.emergingthreats.net/2002994; sid:2002994; rev:6;)
> 

You're getting load issues on that sig?


> I think that's really the heavy heavy checks/msecs.  2001984 is by far the
> worse of all by a huge margin probably because any protocol not in $SSH_PORTS
> is inspected and it's a flowbits only rule.  Consider HTTP/etc.
> 
> Hope this helps better the ruleset.  If this kind of data is helpful I can
> continue to submit my findings for improvements.  The flowbit-only checks are
> at least something to really think about.
> 

Thanks Nathan! Really appreciate it. Helps us a lot to see which sigs are high load on different nets and traffic patterns.

And by the way, the reason I'm pitching all the changes over for pedro to fix is that I'm out for a short vacation. :)  

Matt

> Snort 2.9 ruleset, no gpl.
> 
> Thanks,
> Nathan
> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> 
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!


----------------------------------------------------
Matt Jonkman
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 866-504-2523 x110
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4364 bytes
Desc: not available
Url : http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20111011/933f258d/smime-0001.bin


More information about the Emerging-sigs mailing list