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.

  • So I Hex-encoded the '-' in 'Set-Cookie'... 'Set|2D|Cookie'... I'll test and report back. – user1801810 Mar 6 '14 at 23:19
  • Hex-encoding did not work. Experimenting..... – user1801810 Mar 7 '14 at 5:14

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?



  • I had a pcap, which is what I used to verify that the alert was a false-positive. I since deleted it and disabled (until I have time to figure this out) the rule. I will re-enable and collect another pcap soon... it fires somewhat regularly. – user1801810 Jun 17 '14 at 4:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.