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

Josh Rosenbaum (jrosenba) jrosenba at ...3461...
Tue Dec 9 17:37:17 EST 2014


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 at ...2499...<mailto:mike.cox52 at ...2499...>>
Date: Tuesday, December 2, 2014 at 10:53 AM
To: "Steve Sturges (ststurge)" <ststurge at ...3461...<mailto:ststurge at ...3484......>>
Cc: "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: 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 at ...2499...<mailto:mike.cox52 at ...2499...>> 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 at ...3484......<mailto:ststurge at ...3461...>> wrote:
Legacy, kinda.  But more efficient performance wise.  :)

> On Oct 22, 2014, at 9:18 PM, "Joshua Kinard" <kumba at ...2185...<mailto: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...><mailto: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://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 at lists.sourceforge.net<mailto:Snort-devel at ...2764...t>
> 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<mailto: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/20141209/a3bb3ed0/attachment.html>


More information about the Snort-devel mailing list