IDS mailing list archives
Re: Protocol Anomaly Detection IDS
From: Robert Graham <robert_david_graham () yahoo com>
Date: Wed, 19 Feb 2003 15:25:41 -0800 (PST)
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
Current thread:
- Protocol Anomaly Detection IDS Michael L. Artz (Feb 05)
- Re: Protocol Anomaly Detection IDS Martin Roesch (Feb 11)
- Re: Protocol Anomaly Detection IDS Frank Knobbe (Feb 11)
- RE: Protocol Anomaly Detection IDS Sonit Jain (Feb 12)
- Re: Protocol Anomaly Detection IDS Frank Knobbe (Feb 11)
- Re: Protocol Anomaly Detection IDS Yaakov Yehudi (Feb 11)
- <Possible follow-ups>
- RE: Protocol Anomaly Detection IDS Graham, Robert (ISS Atlanta) (Feb 06)
- RE: Protocol Anomaly Detection IDS Adam Powers (Feb 06)
- Re: Protocol Anomaly Detection IDS Jordan K Wiens (Feb 06)
- RE: Protocol Anomaly Detection IDS Andrew Plato (Feb 10)
- Re: Protocol Anomaly Detection IDS Martin Roesch (Feb 18)
- Re: Protocol Anomaly Detection IDS Robert Graham (Feb 20)
- Re: Protocol Anomaly Detection IDS - Honeypots Lance Spitzner (Feb 20)
- Re: Protocol Anomaly Detection IDS - Honeypots dreamwvr () dreamwvr com (Feb 20)
- RE: Protocol Anomaly Detection IDS - Honeypots Rob Shein (Feb 20)
- Re: Protocol Anomaly Detection IDS - Honeypots dreamwvr () dreamwvr com (Feb 21)
- Re: Protocol Anomaly Detection IDS - Honeypots Gene Yoo (Feb 25)
- Re: Protocol Anomaly Detection IDS Robert Graham (Feb 20)
- Message not available
- Re: Protocol Anomaly Detection IDS - Honeypots Bob Radvanovsky (Feb 20)
- Re: Protocol Anomaly Detection IDS Martin Roesch (Feb 11)