§8.9.2Intrusion Detection Systems

Cross-layer Kurose & Ross pp. 675–678 · ~11 min read

  • intrusion detection system

Where you are

  • Application layer you are here
  • Transport layer you are here
  • Network layer you are here
  • Link layer you are here
  • Physical layer you are here

A firewall decides from the headers. This device reads the payload too — and the two ways it can decide what is suspicious have opposite strengths and opposite failures.

Words you will meet

  • Deep packet inspection — looking past the headers, into the application data the packet carries.

  • Intrusion detection system — raises an alert on suspicious traffic.

  • Intrusion prevention system — the same detection, but it drops the traffic instead.

  • Signature — a set of rules describing one known intrusion.

  • DMZ (demilitarized zone) — the region holding servers that must talk to the outside world.

  • Snort — the public-domain, open-source detection system the book uses as its example.

Why this matters

Section 8.9.1 ended with a gap. A packet filter reads headers. An application gateway reads application data — but only for one specific application.

Detecting network mapping, port scans, worms, viruses, or attacks on an operating system’s vulnerabilities needs the payload of any packet examined, whatever application it belongs to. That is the niche this device fills.

The interesting question is not what it does with what it finds. It is how it decides that something is suspicious at all, and there are only two answers.

Detection and prevention are the same problem

A device that generates alerts when it observes potentially malicious traffic is an intrusion detection system. A device that filters out that traffic is an intrusion prevention system.

The book studies them together and says why: the interesting technical question is how suspicious traffic is detected, not whether the device then sends an alert or drops a packet. This page follows that, and uses “detection system” for both.

In plain words

The hard part is knowing. Acting on what you know is a configuration choice.

Look at the Snort signature further down this page: the very first word is alert. Change it to drop and the identical rule turns a detection system into a prevention system. Nothing else about it changes.

Where the sensors go, and why there are several

Figure 8.37 — a filter, an application gateway, and three sensors
2 hops: the Internet → packet filter → public web server
demilitarized zone — protected by the filter onlyhigh-security region — filter AND application gatewaysensor 1 — everything arrivingsensor 2 — DMZ trafficsensor 3 — high-security trafficthe Internetpacket filterpublic web serverFTP serverauthoritative DNS serverapplication gatewayinternal hosts

Drag any device to rearrange the picture. Hover a link to see its rate, delay and length.

The servers that must talk to the outside world live in the demilitarized zone, behind the filter but not behind the gateway. Each sensor sees only a fraction of the traffic, which is the point.

Read this diagram as text
  • the Internet wired link packet filter
  • packet filter wired link public web server
  • packet filter wired link application gateway
  • application gateway wired link internal hosts
  • packet filter wired link FTP server
  • packet filter wired link authoritative DNS server

The organisation in Figure 8.37 has split its network in two.

The high-security region is protected by a packet filter and an application gateway. The demilitarized zone is protected by the filter only. It holds the servers that must communicate with the outside world: the public web server, the FTP (File Transfer Protocol) server, the authoritative DNS (Domain Name System) server.

Both regions are monitored by sensors, and when several are deployed they work together, sending information to a central processor that integrates it and raises alarms.

Why not one sensor at the front door?

It is the obvious design, and the reason against it is arithmetic.

A detection system must do deep packet inspection and compare every passing packet against tens of thousands of signatures. For an organisation receiving gigabits per second from the Internet, that is a great deal of processing.

Placing sensors further downstream means each one sees only a fraction of the traffic and can keep up.

The book is honest that this is a performance argument rather than a security one. High-performance systems exist today, and many organisations get by with a single sensor near the access router.

Two ways to recognise an attack

Signature-based against anomaly-based detection
Signature-baseda database of known attacksAnomaly-baseda profile of normal traffic
How it decides
Can it catch an attack nobody has seen?
What produces a false alarm
The hard part
How much is deployed

Cells marked ⓘ have a reason behind them — click to read it.

One knows what attacks look like. The other knows what normal looks like. Both descriptions are exactly as fragile as they sound. Click any cell.

A signature-based system holds a database of attack signatures and compares every sniffed packet against it. A match produces an alert — by e-mail, to the network management system, or simply logged.

An anomaly-based system builds a profile of traffic in normal operation, then looks for streams that are statistically unusual.

Read the trade honestly

A signature-based system requires previous knowledge of the attack. It is completely blind to anything not yet recorded — which is a serious property, not a footnote, because new attacks are exactly the ones that work.

An anomaly-based system needs no such knowledge and can potentially detect new, undocumented attacks. But telling normal traffic from statistically unusual traffic is, in the book’s words, an extremely challenging problem.

And so: most deployments today are primarily signature-based, with some anomaly-based features. The approach that can only catch yesterday’s attacks is the one that works well enough to run.

A third failure, easy to miss

Signature-based systems have a limitation that is neither about blindness nor about false alarms.

Every packet must be compared against an extensive collection of signatures. If that processing cannot keep up, the system fails to detect many malicious packets — not because it does not know them, but because it never got to them.

A detector that falls behind is a detector that misses things, and it misses them silently.

Snort, and one signature

Snort is a public-domain, open-source system with hundreds of thousands of deployments, running on Linux, UNIX and Windows. It uses libpcap, the same generic sniffing interface Wireshark uses. It handles 100 Mbps comfortably; gigabit installations may need several sensors.

One Snort signature, field by field

Click any box to read what that part of the message is for.

Every field, as text

    alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING NMAP"; dsize: 0; itype: 8;) — click any part.

    That signature matches any ICMP (Internet Control Message Protocol) packet entering the organisation from outside, of type 8 — an echo request — with an empty payload. Those are exactly the characteristics of the ping packets nmap generates, so the signature exists to detect nmap ping sweeps. Section 1.6 introduced nmap as a mapping tool; this is the other side of that.

    Notice which condition needs deep packet inspection: dsize: 0. Protocol, direction and ICMP type are all header fields a firewall could read. The size of the payload is not.

    What makes Snort work is not the software

    The book’s judgement is that the most impressive thing about Snort is its community.

    Typically within a few hours of a new attack, the Snort community writes and releases a signature. It is then downloaded by hundreds of thousands of deployments around the world. Administrators can also modify signatures or write their own using the same syntax.

    Worth noticing. A signature-based system is blind to new attacks, and this is what shortens the time it stays blind. Not a better algorithm, but a distributed group of people writing rules faster than attacks spread. The technical limitation was addressed socially.

    The mental model

    Everything in section 8.9 reads traffic and decides. What separates the devices is how much they read and what they compare it against.

    A packet filter reads headers and compares them with rules. A stateful filter adds a memory of connections. An application gateway reads the data, for one application. A detection system reads the data for every application, and compares it with either a library of known attacks or a picture of normal life.

    And the last comparison is the only one in this chapter that can be wrong in both directions at once. It can miss what it has never seen, and shout about what was never an attack.

    Check yourself

    Check yourself

    0 of 7 answered
    1. 1.An application gateway already performs deep packet inspection. Why is another device needed?

    2. 2.What is the difference between an intrusion detection system and an intrusion prevention system?

    3. 3.Why deploy several sensors rather than one just behind the packet filter?

    4. 4.predictA completely new attack, never seen or documented, arrives at a signature-based system. What happens?

    5. 5.Anomaly-based detection can catch new attacks. Why is almost everything deployed signature-based anyway?

    6. 6.In the Snort signature for nmap ping sweeps, which condition requires deep packet inspection?

    7. 7.The book calls Snort's community its most impressive feature. Why does that matter technically?

    What to remember

    • Detection and prevention differ by one word in a rule. The interesting question is how suspicious traffic is recognised; whether the device then alerts or drops is a configuration choice.

    • Signature-based detection is completely blind to attacks nobody has recorded yet — and it is still what almost everyone deploys, because the alternative must distinguish unusual traffic from wrong traffic, which nobody has solved.

    • A detector that cannot keep up misses packets silently. Comparing every packet against tens of thousands of signatures is why sensors are placed downstream, where each sees only a fraction of the traffic.