[Intrusions] Assessing Your Malware Exposure with Snort

[Brian]

On Thu, Mar 10, 2005 at 03:39:10PM -0600, Cory.Bys at fbol.com wrote:
> <snip>
> My tweaked "for speed" meat of the rule version is:
> 
>     flow:established,to_server; content:"whenyousearch.com"; nocase;
>     pcre:"/^Host\x3a\s*[a-z0-0\.-]+\.whenyousearch.com/smi";
> </snip>

note, I see one error in my ways...

     flow:established,to_server; content:"whenyousearch.com"; nocase;
     pcre:"/^Host\x3a\s*[a-z\d\.-]+\.whenyousearch.com$/smi";

\w+ would be be faster, but _ isn't valid in hostnames IIRC.

more on $ later in response to one of your questions.

> - I had assumed that making the expression do all of the work would be more
> efficient than using the "smi" modifiers. I could be wrong.

well, to reduce false positives, smi is important.

Posting the string "I wrote a rule that looks for Host: evil.com and
it works well" to some random web forum would cause your rule to go
off.  Sure, if it happened to land on a newline mine will go off for
the same content, but its one less potential false positive.

> - The Snort manual states the content option is "rather computationally
> expensive". Since I am only concerned with communications with a given host
> and don't care about the data portion of the packet I don't understand how
> adding the option improves performance.

In this context, you need content.  content will speed up your rule
set.

> - Is there really a performance difference between \x3a and (:) and \d ?

I rewrite \: to be \x3a due to oddities in the snort parser.  More of
a stylistic change.  snort handles : and ; badly.  per \d, see above.

> - What is the significance of allowing multiple whitespace with \s*?
> I have never seen a real-world example where "Host:" was not
> followed by only one space.

When I write rules, I try and remove as many potential false negatives
as possible.  0 or more whitespace characters are allowed.  Some day,
some where, a web browser might remove whitespace to save in bandwidth
and your rule would then be broken.

> - By dropping the grouping and removing \r\n you are significantly
> increasing the chance of false positives. \r\n follows every Host option so
> it is a fairly reliable indicator of "end of line". At first glance it
> appears as though your version of rule would hit on the following:
> 
> Host: www.whenyousearch.communist.com

True.  add a $ though, thanks to the use of 'smi' options.  \r\n isn't
required.  \n will work.  again, removing false negatives.  but... I
introduced a false positive, so add the $.

In the example I commented on above, I added $.

> - I didn't add "to_server" because I assumed it would increase
> overhead.  Since I don't host whenyousearch.com I don't expect to
> ever see an established HTTP connection with the given Host string
> going the other way, so I thought the additional scrutiny didn't
> make sense.

Well, Here is my thoughts on the subject.  You are already checking
flow, adding to_server is a simple bit check with very little
additional function overhead to get there.  Without it, the rule isn't
quite "right".

Brian