Snort Rule Writing (Alert Fires But Traffic Does Not Match *Intended* Rule)

Question

I have the following rule:

alert tcp $HOME_NET any > $EXTERNAL_NET any (msg:"This should not happen"; flow:established,to_server; content:"GET "; depth:4; content:"Set-Cookie:"; http_header; within:100; classtype:trojan-activity; sid:1000001; rev:1;)

The header and general options are not the issue - it's the payload and non-payload options that are throwing me off. My understanding is that this rule should only fire under the following conditions:

1. There is an established session (flow:established)
2. Trigger on client requests from $HOME_NET to $EXTERNAL_NET (to_server)
3. Content includes 'GET'
4. 'GET' within 4 bytes of the beginning of the payload
5. Content includes 'Set-Cookie:' within HTTP headers
6. 'GET' and 'Set-Cookie' are within 100 bytes of each other

This is version 2.9.1.x. The http_inspect preprocessor has been modified from default but I don't think this is the problem. So, I'm wondering how this rule fires on traffic that doesn't have 'Set-Cookie' coming from the client (Set-Cookie should only come in a server response whereas Cookie should only come in a client request). Maybe I'm going down the wrong path my research revealed that Snort uses Boyer–Moore string search algorithm (http://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_search_algorithm) which matches "...on the tail of the pattern rather than the head...". So in my case, is the rule firing on client traffic that includes a cookie since it would see 'Cookie' (which is a part of 'Set-Cookie')??

I didn't write the rule and the person who did is unavailable. I need to understand why this is firing on traffic that in my eyes does not match what the rule is looking for. Is the rule written incorrectly to capture $HOME_NET (client) traffic to $EXTERNAL_NET (server) that has 'Set-Cookie' HTTP header set?

Thanks for your time and feedback.

Answer 1

Boyer-Moore isn't the problem. Snort should match the entire string, always. It doesn't make sense to have the "within:100" in the second content match because http_header is a completely different buffer. That should be removed. But that doesn't explain why this would alert if the content wasn't in the original packet.

Do you have a pcap of traffic that trips this?

Thanks,

~Patrick