Re: Context: Malware Blog Post on Dark Comet RAT with Snort Signatures

[Martin Holste <mcholste () gmail com>]

Mike: The intel is always welcome, and I'll even tolerate a little
pseudo-advertising if the content is worth it.  The intel on decoding
the encrypted traffic is good, but as has been said, more diligence on
the sigs is needed.

That said, I think we have a great "teachable moment" here on covering
why it's so important to have a content match in a rule.  The basic
concept is that in Snort, along with many other security products,
pattern matching is efficiently done by using patterns that are
compiled into a data structure at start-up time.  PCRE and other
regular expressions do not pre-compile themselves in the same way and
are therefore orders of magnitude less efficient.  So, the Snort
engine will first apply the pattern matching engine to traffic as it
comes through, and then it will apply PCRE matches on any hits.  By
default, Snort will use the longest string in the content matches and
if that hits, it will apply the other content matches and PCRE.  (The
fast_pattern modifier will override the longest string default in case
a shorter string is known to be less rare.)

I find in general that you can think of it like a database query, with
the analogy being that the content match is like a query using an
index and then filtering found results based on the rule's other
checks.  If you've ever played with a database table with a million or
more rows, you know how important it is to have an efficient index,
and if you search for a common term in the index, the database will
spend all of its time filtering out rows because the index returned a
lot of matches.  In the same way, you want your content matches in
Snort to search for rare terms so that all of the other checks,
including PCRE, are invoked less often.

Here's an example.  Suppose you write a rule like this:
alert tcp $HOME_NET any -> $EXERNAL_NET $HTTP_PORTS (msg:"saw a GET";
content:"GET"; pcre:"/some rare term/";)
Even though you have a content match to "protect" your PCRE match from
being invoked, it won't do any good because "GET" is so common.  A
better rule would focus on some rare term, like a unique user agent,
or unique host:
alert tcp $HOME_NET any -> $EXERNAL_NET $HTTP_PORTS (msg:"saw a
request with bad user agent"; content:"bad_user_agent"; http_header;
pcre:"/some rare term/";)
Now your expensive PCRE check is protected by the "bad_user_agent" string.

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org


Please visit http://blog.snort.org for the latest news about Snort!