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. Mar 6, 2014 at 23:19
  • Hex-encoding did not work. Experimenting..... Mar 7, 2014 at 5:14

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



  • 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. Jun 17, 2014 at 4:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .