Snort ID's

SephStorm

Can someone explain how traffic is matched to Snort ID's? i've seen some confiker alerts and by my understanding, they are being alerted based on the SID, but its not clear what exactly in the traffic they are alerting on. As you can see: Snort :: they have a tendancy for FP. Based on the URLs visited I am leaning that way on my analysis as I dont see anything malicious in the traffic, I want to make sure I am not missing anything.

MrAgent

I've always thought it was based on signatures, which is matched based on the payload.

I haven't really done a whole lot with snort, so my knowledge is limited to what I remember from my grad classes and a little bit of practice in the labs.

I'd like to know the answer as well.

chaser7783

bleh gen id 3 rules, sadly you can't see the content of these rules because they are compiled at source.( alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"EXPLOIT possible Conficker.C HTTP traffic 1"; sid:15451; gid:3; rev:5; classtype:trojan-activity; reference:url,mtc.sri.com/Conficker/; metadata: engine shared, soid 3|15451;) ).

You are better of disabling rules like this and making your own rule for conficker, or using the ET rules like this:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Conficker/MS08-067 Worm Traffic Outbound"; flowbits:isset,ET.ms08067_header; flow:established,to_server; content:"If-None-Match|3A| |22|60794|2D|12b3|2D|e4169440|22|"; nocase; reference:url,doc.emergingthreats.net/bin/view/Main/2008739; classtype:trojan-activity; sid:2008739; rev:6;)

Normally I disable all GID 3 rules, what good is a rule firing when you can't see the content of the rule.

SephStorm

tend to agree now that i've seen one. In your expample, what does "If-None-Match" mean?

chaser7783

It's a content match so it is looking for those values in the http header. Values within | | are looking for hex values.

SephStorm

I get the hex value. Wouldn't this trigger on any traffic that didn't have those hex values in the header?

chaser7783

No b/c it is looking for any traffic originating from $home_net going to $external_net $https ports with the content string of "If-None-Match|3A| |22|60794|2D|12b3|2D|e4169440|22|"; and case insensitive.

docrice

How did I miss this topic? My eyes must be getting old.

GID 3 alerts refer to shared-object rules, meaning they're compiled rules and Sourcefire is under obligation with another entity (such as Microsoft) to not disclose the rule contents, so unfortunately they're not readable like normal text rules.

The reasoning here is that if there's an 0-day and Microsoft wants to allow the good guys to detect it but also reduce the possibility of malicious parties reverse engineering it quickly, this is a balanced approach. We can probably argue that until the cows come home. These binary rules also allow for specific edge cases which text rules cannot cover from a functional perspective (perhaps a capability at a programmatic level).

Emerging Threat rules tend to be noisy in my experience, but like anything you really just have to tune/adapt your sensor to your particular environment. I wouldn't disable shared object rules right off the bat as I'd prefer to have full packet capture running as a additional validation point (or a compensating control for binary rules, if you will). But yes, not being able to see what the detection engine is basing its decision-making on makes the alert feel less trustworthy.

SephStorm

Thanks Doc.