Re: fast_pattern not always longest content string by default?

["Josh Rosenbaum (jrosenba)" <jrosenba () cisco com>]

Mike,

To close the loop on our end, I have created a bug to ensure this information is added to the documentation.  Also, the 
snort manual has already been updated with the answer to your original question.

Josh


From: Mike Cox <mike.cox52 () gmail com<mailto:mike.cox52 () gmail com>>
Date: Tuesday, December 2, 2014 at 10:53 AM
To: "Steve Sturges (ststurge)" <ststurge () cisco com<mailto:ststurge () cisco com>>
Cc: "snort-devel () lists sourceforge net<mailto:snort-devel () lists sourceforge net>" <snort-devel () lists 
sourceforge net<mailto:snort-devel () lists sourceforge net>>
Subject: Re: [Snort-devel] fast_pattern not always longest content string by default?

Just to close the loop here and to document this on the Internet somewhere in case I forget, it looks like fast pattern 
checks in HTTP Inspect buffers are case insensitive as well (checked on Snort 2.9).

Thanks!

-Mike Cox

On Wed, Nov 12, 2014 at 10:29 AM, Mike Cox <mike.cox52 () gmail com<mailto:mike.cox52 () gmail com>> wrote:
There is a long-held belief that the fast pattern matcher is case insensitive.  Is that true as well for fast pattern 
matches in HTTP Inspect buffers?  If not, has that always been the case?

Thanks!

-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.
>
> --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><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_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>".
> >
> > 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
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit 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
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

_______________________________________________
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!