Re: [Snort-users] Rule based vs. Signature based detection engine

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/...fo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.p...st=snort-users