Snort mailing list archives
Re: fast_pattern not always longest content string by default?
From: "Joel Esler (jesler)" <jesler () cisco com>
Date: Thu, 23 Oct 2014 17:51:22 +0000
Thanks Mike, we’ll open a doc bug for this. Joel Esler jesler () cisco com
On Oct 23, 2014, at 10:23 AM, Mike Cox <mike.cox52 () gmail com> wrote: Thanks for the replies. I don't disagree with this behavior but I do think the Snort manual should make this clear because I've been using Snort for many years and this is the first I've heard of it. -Mike Cox On Wed, Oct 22, 2014 at 9:34 PM, Steve Sturges (ststurge) <ststurge () cisco com <mailto:ststurge () cisco com>> wrote: Legacy, kinda. But more efficient performance wise. :)On Oct 22, 2014, at 9:18 PM, "Joshua Kinard" <kumba () gentoo org <mailto:kumba () gentoo org>> wrote: 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. --JOn 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><mailto: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://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/><http://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 <mailto:Snort-devel () lists sourceforge net> https://lists.sourceforge.net/lists/listinfo/snort-devel <https://lists.sourceforge.net/lists/listinfo/snort-devel> Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel <http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel> Please visit http://blog.snort.org <http://blog.snort.org/> for the latest news about Snort!------------------------------------------------------------------------------ _______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net <mailto:Snort-devel () lists sourceforge net> https://lists.sourceforge.net/lists/listinfo/snort-devel <https://lists.sourceforge.net/lists/listinfo/snort-devel> Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel <http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel> Please visit http://blog.snort.org <http://blog.snort.org/> for the latest news about Snort! ------------------------------------------------------------------------------ _______________________________________________ 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!
Attachment:
smime.p7s
Description:
------------------------------------------------------------------------------
_______________________________________________ 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)