[Snort-users] Rule efficiency

Alex Kirk akirk at ...1935...
Fri Jul 23 15:01:11 EDT 2010

For what it's worth, the use of the fast_pattern keyword when there's a
single content clause is actually unnecessary. The fast pattern matcher by
default chooses the longest string available out of a rule, and if you've
only got one string, well, it'll choose that every time.

Good luck with your management quandary.

On Fri, Jul 23, 2010 at 2:33 PM, Isherwood, Jeffrey - IS <
Jeffrey.Isherwood at ...14632...> wrote:

>  Thanks for the reply Alex…  For reasons that I can’t go into, I am not
> able to check the DNS queries (alas, that was my original thought as well).
> I have to check on the http_header part, I was told to watch for “Any
> Traffic” but often management hands down directives that include the words
> “any” or “all” when they could be more precise.  If it turns out that they
> are only interested in web traffic then using adding “fast_pattern” and
> “http_header” look like they might help out thanks…
> If they turn around and insist on any/all traffic – I can’t see any other
> way to tighten those rules up, other than maybe using the “fast_pattern”
> unless the domain names are in the tcp packet headers and I am able to craft
> the rule to search more narrow…
> *From:* Alex Kirk [mailto:akirk at ...1935...]
> *Sent:* Friday, July 23, 2010 1:57 PM
> *To:* Isherwood, Jeffrey - IS
> *Cc:* snort-users at lists.sourceforge.net
> *Subject:* Re: [Snort-users] Rule efficiency
> Multiple rules should be faster, due to the way Snort works. Snort's first
> step for any packet is to use the fast pattern matcher to find appropriate
> packets to operate on; the patterns used are based on the port used in the
> rule, and either the longest static string specified in a content clause, or
> the content clause specifically declared to be used by the "fast_pattern"
> keyword. If the fast pattern matcher finds something, the rest of the rule
> options are evaluated in order.
> For cases where you've got a really small pattern, you're going to get a
> lot more matches out of the fast pattern matcher, and thus force Snort to do
> more work. Since the fast pattern matcher is, well, fast (so much so that
> the dev team has called additional fast pattern checks "nearly free"), it
> makes clear sense to get it to do as much sorting as possible for you before
> you dig into the rules themselves.
> Meanwhile, let me give you some thoughts on these rules in particular. If
> you're looking for HTTP access, as I would guess based on your fictional
> names, you'll need to specify the http_header keyword to go along with those
> contents for Snort 2.8.6 and beyond - since hostnames appear in HTTP
> headers, and you need that keyword to make Snort look there. Additionally,
> you might consider switching these over to be rules that look for DNS
> queries to the domains in question (assuming you're confident this is not
> bot-generated traffic that's going off of an internal hosts file) - such
> rules are almost as easy to write, and there's *way* less UDP traffic to
> inspect than HTTP, which will help improve your overall performance pretty
> dramatically.
> ------------------------------
> This e-mail and any files transmitted with it may be proprietary and are
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this e-mail in error please notify the
> sender.
> Please note that any views or opinions presented in this e-mail are solely
> those of the author and do not necessarily represent those of ITT
> Corporation. The recipient should check this e-mail and any attachments for
> the presence of viruses. ITT accepts no liability for any damage caused by
> any virus transmitted by this e-mail.

Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
alex.kirk at ...1935...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20100723/91cfd2bf/attachment.html>

More information about the Snort-users mailing list