[Snort-devel] fast_pattern not always longest content string by default?

Mike Cox mike.cox52 at ...2499...
Wed Nov 12 10:29:22 EST 2014


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 at ...3461...> wrote:

> Legacy, kinda.  But more efficient performance wise.  :)
>
> > On Oct 22, 2014, at 9:18 PM, "Joshua Kinard" <kumba at ...2185...> 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 at ...2499...<mailto:mike.cox52 at ...2499...>>
> >> 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 at 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 at 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20141112/d60da0cd/attachment.html>


More information about the Snort-devel mailing list