Re: Rule efficiency

["Isherwood, Jeffrey - IS" <Jeffrey.Isherwood () itt com>]

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 () sourcefire com]
Sent: Friday, July 23, 2010 1:57 PM
To: Isherwood, Jeffrey - IS
Cc: snort-users () 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users