Suricata

Overview¶

Multibuffer allows for great detection methods when multiple entries of a single "type" is observed.

I think it'd be worth considering supporting multi-buffer matching for HTTP cookies.

Current Behavior¶

Consider the attached pcap which contains two "Set-Cookie" headers within the HTTP response.

This traffic matches the following rule currently in the ET Open ruleset which currently contains an unbuffered content match for an HTTP cookie.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT_KIT Evil Redirector Leading to EK Oct 26 2015"; flow:established,to_client; content:"|0d 0a|Set-Cookie|3a 20|qtaho="; classtype:exploit-kit; sid:2022001; rev:3;)

My intention was to convert this rule to http.cookie. realized that depending on the ordering of and presence of other Set-Cookie headers, the qtaho= might appear at the start of the buffer or it could appear as ` ,qtaho=`.

While this behavior of concatenating cookies (and other anytime multiple values for the same header name) is documented well enough, it results in writing signatures that are less than exact or require the use of PCRE to ensure the signature matches on both possibilities as seen below.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT_KIT Evil Redirector Leading to EK Oct 26 2015"; flow:established,to_client; http.cookie; content:"qtaho="; pcre:"/(?:^|,\x20)qtaho=/"; classtype:exploit-kit; sid:2022001; rev:3;)

Proposed Solution¶

By supporting multi-buffer matching we can eliminate the need for pcre, thus resulting in a more performant rule.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT_KIT Evil Redirector Leading to EK Oct 26 2015"; flow:established,to_client; http.cookie; content:"qtaho="; startswith; classtype:exploit-kit; sid:2022001; rev:3;)

Considerations¶

In the proposed solution, http.cookie was used, however any behavior change in this keyword would be a "breaking" change needing careful testing. It might be worth considering using a new keyword (similar to http.request_header/http.response_header) that would make use of the multi-buffer support.

While considering this feature of HTTP cookies, I wonder if it'd be worth considering this behavior for any HTTP header. The impacts of multi-buffer on #5775 would be very interesting as well, perhaps it's worth supporting them natively . (I'll make a note over on that feature request as well)