Re: Intrusion Detection

["Marcus J. Ranum" <mjr () nfr net>]

Adam Shostack writes:
>       I believe intrusion detection to be a misnomer, and that the
> really useful class of software is attack detection.  Attacks (land,
> teardrop, phf, password file sucking) are relatively easy to detect
> with network sniffing software. 

Adam,

        To me the big open question in ID is "why?" not "what?"

        If you have a network you believe to be vulnerable to the attacks
listed above - FIX THEM. If you've fixed them, then why do you care if
someone uses them against you? Are you actually going to backtrack and
try to prosecute? Good luck!

        Back when I was a firewall vendor (yes, none of this stuff is new!)
I built a firewall that alerted the system manager whenever certain
classes of weirdness occurred. That was always Very Cool and it was the
first thing they turned off after it began pestering them constantly.
As the vendor, I wished I'd never put it in because I kept getting
calls that went something like:
C: "Hi - my firewall is saying it's getting spoofed packets! Help!"
V: "What am I supposed to do about it?"
C: "Well, can you make it stop? Can I call the police?"
V: "No, and No. It's just informational, really."
C: "Does this indicate that someone's likely to break through the firewall?"
V: "No, it indicates that we thought ahead, blocked that avenue of attack,
        and it doesn't represent a problem at all. I guess you now know that
        your firewall works, or something."
C: "Uh, uh, uh..."

        The whole problem with ID (*ESPECIALLY* what Adam calls "attack
detection") is that it detects something basically useless. So you're
under attack. Big deal. Your defenses can either handle it, or they
can't. If they can, then relax, have a homebrew, and don't get pestered
about land, teardrop, etc. If they can't, you'll know right away anyhow
when your system slags.

        There are really only 2 good reasons I can think of for ID systems:
1) To develop a threat level model as to how often you are attacked
2) To detect clueless people inside your organization who are attacking
        outside sites

        The first one is kind of silly but I suppose it makes people
happy to know that they were SATAN scanned 2,102 times last year and
that their firewall blocked 1292 clueless twinks who tried using the
"same old stuff" as the previous 1291 clueless twinks. The second one
is valuable if you actually are going to do something about clueless
twinks inside your network. I suspect this must put university
network managers in a real quandary.

        In short, my views are exactly, precisely 180 degrees the
opposite of Adam's. I don't have TIME to be notified about the
clueless twinks. What I want is fallback defenses that will detect
when my first line has failed. This is what I am calling "policy
based intrusion detection" and I'll probably wind up explaining
it here in a white paper or long posting some night. :) It's the
"SOMETHING HAS GONE TERRIBLY WRONG. WARNING WILL ROBINSON!"
mechanism. I care a lot about that, and the "why?" for such a
system is obvious. The second part is, of course, what NFRs are
for. Once you've found that something's happened, then how do you
figure out what it was?

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr