[Emerging-Sigs] Bad Performing Rules

Nathan nathan at packetmail.net
Tue Oct 11 09:41:02 EDT 2011


On 10/11/11 05:31, Matthew Jonkman wrote:

>> #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?

At this time I can't go Suricata in this specific build-out but I do sing it's
praises.  Victor is a rock star for getting changes/patches hammered out even
for my odd use-cases.  Now, for what it's worth, I understand this signature to
also be a heavy-hitter on Suricata as well.  In Snort this one is the worst
performer by a huge margin even when I sling 443 into SSH_PORTS.  Logically, I
assume it's because it's checking the flowbit status for each and every packet
not in $SSH_PORTS.

Would it make sense to add a flow:established,to_server here?  So at least we're
looking at flows and not individual packets?

>> #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?

I think at one point we had originally written these with depth and then
optimized for the 2.x Snort versions with the normalized buffers.  Not really
sure how to write these style rules very well (POST, GET, OPTION, with invalid
case)...

>> #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. :)

Can we add flow:established,from_server here, so we're not checking flowbit
state for all traffic egress to ingress?  Not sure if this is the way to
optimize these, flowbits + flow?

>> #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?

Oddly enough, yeah.  I can get the msec/checks for these.  Probably should've
included them in this E-mail.  Note I don't see a lot of TCP 143 IMAP.

> 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. :)  

Have fun, you've earned it!

Thanks,
Nathan


More information about the Emerging-sigs mailing list