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

> 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) may start. 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