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

Josh Rosenbaum (jrosenba) jrosenba at ...3461...
Wed Oct 22 16:30:02 EDT 2014


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
To: "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: [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20141022/f67ca742/attachment.html>


More information about the Snort-devel mailing list