Re: Rule based vs. Signature based detection engine

["Keith W. McCammon" <mccammon () gmail com>]

See revision to 3.  I forgot to end the next-to-final sentence (used
to end in "may start")...

On Wed, 21 Jul 2004 10:12:45 -0400, Keith W. McCammon
<mccammon () gmail com> wrote:
> > Can you explain "multi-conditioned, and can have data-dependant byte jumps,
> > etc."
>
> See the manual section on writing rules.  Snort rules do more than
> just look for a single condition in a packet payload.  The very robust
> nature of the rules language allows you to write representations of
> junk like this:
>
> 1) Start search by looking for some tell-tale data within the payload
> that indicates the nature of the communication [content].  For
> example, we might look for a fixed-length header, which we know occurs
> within the first X bytes of the payload. [depth]
>
> 2) Now that we know that this is the right type of traffic (because we
> found the tell using the first content match) let's find another match
> that indicates the end of the protocol header. [content]  By the way,
> we know that what we're looking for occurs within X bytes of the end
> of the previous content match. [distance]
>
> 3) Once we find the end of the header, read in four bytes of the
> payload (which we know, based on the protocol specs, represents a
> numeric value N).  Now jump ahead N bytes. [byte_jump]  This is very
> important when dealing with communications that use variable-length
> fields, because the start of the next data field (the one that really
> interests us) simply starts where the last field left off.  Without reading in the length of the previous field, we 
> have no way of knowing where to start looking for our next match--we'd have to look for it throughout, which takes 
> more time, and is more likely to generate a false-positive.  So, now we're 4+N bytes past the end of the
> protocol header.
>
> 4) From here, start looking for another content match.  Let's say
> we're looking for the word "123". [content]  And if we find the word
> "123", then we want to start looking for another match on "abc".
> [content].  But, we only want to alert if "123" and "abc" appear near
> one another. [distance and/or within]  We want to make sure they're
> close, because we know that both strings may well appear, for whatever
> reason, during normal communications.  However, we know that if
> they're within a few bytes of one another, some specific action has
> taken place.  Maybe a root compromise returns 123 followed by some
> fixed-length variable string, and then abc.
>
> This is a crude example, but you get the point.  Provided that you
> have the means the understanding of the protocols involved, you can
> craft very specific, very efficient rules, based on a pretty
> ridiculous number of options.
>
> And regarding the "definition of an attack" reference (from the OP),
> he's likely referring to the ability of the rules language
> (specifically some of these more advanced, context-sensitive options)
> to facilitate the coding of rules to detect undesirable conditions, as
> opposed to individual exploits.
>
> For example, if we coded the rule described above to simply look for
> "123xxxabc" because this is what a successful execution of a given
> exploit happens to return, then we'd only catch that specific variant
> of the exploit.  If the exploit is changed, and it now returns
> "123yyyabc" then our rule won't fire, even though the box is still
> compromised.
>
> However, by writing our rule as described, using these advanced
> options, we'll not only catch this original exploit, but we'd catch
> (in theory) any exploit that returns root.  We know this because we're
> looking for a much broader pattern that is indicative of root access
> (123 within a given distance of abc), as opposed to looking for a
> pattern that is indicative of a specific exploit (123xxxabc).
>
> Hope this helps.
>
> Keith


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
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