People have been hoping that there is some sort of magic-pill technology that
solves the problem of IDS. "Protocol-anomaly detection" is one of those
buzzwords that promises a magic pill.

Snort does it. Moreover, if Marty wanted to do more of it, he could simply add
more protocol parsers. To pretend you have some sort of magic pill technology
that Snort can't have is a marketing lie.

On the other hand, Snort has in practice fewer protocol-anomaly signatures than
most other products. This is neither good nor bad: there are many ways to skin
the cat.

Personally, I hate buzzwords, because the intense handwaving gets in the way of
understanding what's really going on. I personally wrote a hefty percentage of
the signatures in RealSecure, and I can tell that they work on different
principles than Snort signatures -- whatever buzzwords you choose to describe
the difference shouldn't mask that there is indeed a difference. Again, its not
a question of "better", but "different": the original question was about
alternate viewpoints. Running both Snort and RealSecure together would give two
wildly different viewpoint on signatures.

Take for example the following Snort-like signature that appeared after SQL
Slammer hit:
alert udp $EXTERNAL_NET any -> $HOME_NET 1434 ( \
        msg:"W32.SQLEXP.Worm propagation"; \
        content:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|"; \
        content:"|04|"; offset:0; depth:1;)

Compare this to the RealSecure logic:
SQL_SSRP_StackBo is (
        udp.dst == 1434
        ssrp.type == 4
        ssrp.name.length > 97)
where ssrp.type is first-byte of packet
where ssrp.name is nul-terminated string starting at second byte

Both start their checks by looking for port 1434 and the first byte equal to 4.
However, after that, the pattern-match signature looks for a pattern unique to
the worm, whereas the protocol-anomaly signature tests a condition, namely for
a nul-terminated string starting at the second byte.

The good thing about protocol-anomaly signatures is that they tend to identify
the vulnerability rather than the exploit, which means they can do a better job
of detecting things before exploits are published. The above signature was
added to RealSecure after the vuln was published but before exploits were
published. In contrast, Snort was updated only after SQL Slammer appeared, but
it does a better job distinguishing which exploit in particular is being used.

The upshot of "protocol-anomaly" detection is that they still test things, but
these things tend not to be "patterns" so much as things that fall out of a
protocol-decode (such as length of nul-terminated strings).

Note that some vendors refer to "protocol-validation" as "protocol-anomaly"
detection. These are actually quite different things. For example, SQL Slammer
was a perfectly legal SQL locator request as far as the protocol was concerned,
but it was still "anomalous". In the grander scheme of things, I suppose you
could call "anomaly" detection a superset that includes "validation" (an
invalid operation is certainly anomalous), but I prefer to seperate them
because they have very different characteristics. I.e. protocol validation can
often alert you to attacks even before the vuln is known, but at the same time,
it has more false-positives because must vendors have bugs in their protocol
implementations.

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-----------------------------------------------------------
Does your IDS have Intelligent Attack Profiling?
If not, see what you're missing.
Download a free 15-day trial of StillSecure Border Guard.
http://www.securityfocus.com/stillsecure

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]