Snort mailing list archives
Re: fast_pattern not always longest content string by default?
From: Joshua Kinard <kumba () gentoo org>
Date: Wed, 22 Oct 2014 21:02:07 -0400
I'll wager that this is a relic of Snort's early days as primarily an HTTP traffic sniffer, before it became a more generic deep-packet inspection tool. Something like this should get a mention in the Snort manual, though there are several places where it states that the longest content match is the default, yet doesn't differentiate between a normal content match and a content match modified by an HTTP keyword. So, not a quick fix w/o refactoring the lingo in a few spots. --J On 10/22/2014 16:30, Josh Rosenbaum (jrosenba) wrote:
Hi Mike, 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. Josh From: Mike Cox <mike.cox52 () gmail com<mailto:mike.cox52 () gmail com>> Date: Wednesday, October 22, 2014 at 8:16 AM Subject: [Snort-devel] fast_pattern not always longest content string by default? Hi All, 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.... :( Thanks! -Mike Cox
------------------------------------------------------------------------------ _______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- fast_pattern not always longest content string by default? Mike Cox (Oct 22)
- Re: fast_pattern not always longest content string by default? Josh Rosenbaum (jrosenba) (Oct 22)
- Re: fast_pattern not always longest content string by default? Joshua Kinard (Oct 22)
- Re: fast_pattern not always longest content string by default? Steve Sturges (ststurge) (Oct 22)
- Re: fast_pattern not always longest content string by default? Mike Cox (Oct 23)
- Re: fast_pattern not always longest content string by default? Joel Esler (jesler) (Oct 23)
- Re: fast_pattern not always longest content string by default? Mike Cox (Nov 12)
- Re: fast_pattern not always longest content string by default? Mike Cox (Dec 02)
- Re: fast_pattern not always longest content string by default? Josh Rosenbaum (jrosenba) (Dec 09)
- Re: fast_pattern not always longest content string by default? Joshua Kinard (Oct 22)
- Re: fast_pattern not always longest content string by default? Josh Rosenbaum (jrosenba) (Oct 22)