[Emerging-Sigs] Bad Performing Rules

Nathan nathan at packetmail.net
Fri Oct 7 16:13:33 EDT 2011


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;)

#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;)

#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;)

#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;)

#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;)

#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;)

#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;)

#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;)

#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;)

#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;)

#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;)

#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;)

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.

Snort 2.9 ruleset, no gpl.

Thanks,
Nathan



More information about the Emerging-sigs mailing list