[Snort-devel] fast_pattern not always longest content string by default?
Josh Rosenbaum (jrosenba)
jrosenba at ...3461...
Wed Oct 22 16:30:02 EDT 2014
Sorry for this unfortunate news, but it looks like you will need tweak those sigs. I can confirm that if a fast_pattern keyword is not specified for a given rule, the default fast pattern is the longest HTTP buffer content. If no HTTP buffer content is present, then the fast pattern is the longest content.
From: Mike Cox <mike.cox52 at ...2499...<mailto:mike.cox52 at ...2499...>>
Date: Wednesday, October 22, 2014 at 8:16 AM
To: "snort-devel at lists.sourceforge.net<mailto:snort-devel at ...362....net>" <snort-devel at lists.sourceforge.net<mailto:snort-devel at ...2763...rge.net>>
Subject: [Snort-devel] fast_pattern not always longest content string by default?
I was looking thru some of my sigs with 'debug-print-fast-pattern' turned on and noticed that the fast pattern string was not always the longest content match by default. Specifically, it appears that content matches in (valid for fast_pattern) HTTP Inspect buffers (e.g. http_header, http_uri, etc.) are taking priority. For example, consider this sig:
alert tcp any any -> any $HTTP_PORTS (msg:"FP Test"; flow:established,to_server; content:"twitter.com<http://twitter.com>"; http_header; content:"hellow Twitter tweet"; sid:1234567;)
The longest content match is "hellow Twitter tweet" but when I look at the fast pattern debug output, the fast pattern used is "twitter.com<http://twitter.com>".
Having the HTTP Inspect buffers take priority makes sense because they will be smaller than the entire packet and thus more efficient. However, I do not see this behavior documented in the manual which says, "the default behavior of fast pattern determination is to use the longest content in the rule..."
Can someone comment/confirm this? It is looking like I may have to review/tweak a plethora of sigs.... :(
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel