- 5.1 What Firewalls Don't Do
- 5.2 A Theory of Firewalls
- 5.3 Intrusion Detection Systems
- 5.4 Intrusion Prevention Systems
- 5.5 Extrusion Detection
- 5.6 Analysis
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.3 Intrusion Detection Systems
- “Do you mean to admit that you may have been invaded and searched—tracelessly?” Alcon fairly shrieked the thought.
- “Certainly,” the psychologist replied, coldly. “While I do not believe that it has been done, the possibility must be conceded. What we could do, we have done; but what science can do, science can circumvent.”
Second Stage Lensman
—E. E. “DOC” SMITH
An intrusion detection system (IDS) is a backup security mechanism. It assumes that your other defenses—firewalls, hardened hosts, goat entrails (tofu entrails for vegetarian security professionals) offered up in the dark of the moon—have failed. The task then is to notice the successful attack as soon as possible, which permits minimization of the damage, either via automated systems or their backup humans.
Most of what I’ve said about antivirus technology is true of IDSs as well. An IDS can be signature or anomaly based; the same advantages and disadvantages apply. The key difference is deployment scenarios and hence inputs; antivirus programs operate on files, whereas IDSs are more multifarious.
IDSs are generally classified as network or host intrusion detection systems; for the latter, they can operate on network or host behavior or content. Each of these approaches has benefits and limitations.
The big attraction of anything network based is the same as the big attraction of a firewall: it’s scalable, in that there are typically many fewer networks to instrument than hosts. In fact, the firewall is one very common location to install a network IDS, since by definition all traffic from the outside is supposed to pass through that chokepoint.
Doing intrusion detection in the network, by grabbing packets in flight, is difficult. The obvious problem is dealing with encrypted traffic; more seriously, it’s all too easy to miss packets. There are also theoretical issues with enemies who try to exploit odd corner cases in the network protocol specs [Handley, Kreibich, and Paxson 2001], though such behavior seems to be rare or unknown in the wild. (If the Andromedans are doing this, perhaps they haven’t yet been caught at it?)
The simplest form of network IDS relies on IP addresses and port numbers: if the packets are going to destinations that some parties shouldn’t try to reach, you know there’s a problem. The technique is analogous to the “network telescope” concept [Cheswick 2010; C. Shannon and Moore 2004]: if some IP addresses are deliberately left empty, packets sent to them (or from them!) are a priori suspicious. The same can be true of certain ports on sensitive hosts, especially if you have good information on just who can legitimately send to them.
If that’s all you want to do, though, don’t bother trying to look at packets. Your routers are already doing that; some places have built IDSs based on routers’ NetFlow data.1
More sophisticated network monitoring can be done as well. There are comparatively simple systems that look for simple patterns of data, such as Bro [Paxson 1998; Paxson 1999] or Snort [Roesch 1999]. DPI systems [N. Anderson 2007] are more sophisticated; they look at higher layers of the stack and are often used for various sorts of governmental monitoring [Poe 2006].
The fundamental problem with any form of network IDS is that it lacks context. Yes, DPI and other forms of network monitoring can detect suspicious packets, but it’s difficult for even the best network scanners to reassemble every file in transit and then scan it for malware. That sort of thing is much easier to do on hosts. Hosts can also look at log files; more importantly—and all but impossible to do on the wire—they can scan their own file systems for unexpected changes [G. Kim and Spafford 1994a; G. Kim and Spafford 1994b; G. Kim and Spafford 1994c]. Finally, host based IDSs are network independent; they can detect problems no matter how they arrive, whether via the Internet or carried in on an infected USB flash disk.
Host-based IDSs can do one more thing more easily than their network partners: they can emulate network protocols, above the level of any encryption. Depending on their purpose, they can be part of or intermediaries for the real network daemons; alternatively, they can be pure fakes, doing nothing but detecting things that you hope will never happen. This is an ancient technique [Bellovin 1992], but it is useful nevertheless.