IDS vs IPS: what's the difference between detecting and blocking?

An IDS (intrusion detection system) inspects traffic and raises alerts. An IPS (intrusion prevention system) does everything an IDS does and can also try to stop the attack. The difference you can see on a network diagram is placement: an IDS usually sits passively and receives a copy of the traffic, while an IPS sits inline, so the traffic has to pass through it and it can drop packets.

This is a question-and-answer post. The main reference is NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS), published February 2007. It is still the current final version: a 2012 draft Revision 1 never became final and has been retired. The commands come from the Suricata and Snort documentation.

IDS   passive: gets a copy                                      
                                                                
┌───────┐                                             ┌────────┐
│client │[bad]─────────[sw] ──────────────────────────│ server │
└───────┘                ┆ SPAN                       └────────┘
                   ┌────────────┐                               
                   │ IDS sensor●│                               
                   └────────────┘                               
                                                                
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
IPS   inline: traffic goes through it                           
                                                                
┌───────┐                 ┌──────────┐                ┌────────┐
│client │─────────────────│    IPS  ●│────────────────│ server │
└───────┘                 └──────────┘                └────────┘
                                                                
                                                                
IDS sees a copy, so it can only alert. IPS is in the path.      

What is the difference between an IDS and an IPS?

An IPS is an IDS that can also block. NIST defines an IDS as software that automates intrusion detection, and an IPS as software that has all the capabilities of an intrusion detection system and can also attempt to stop possible incidents (section 2). It adds that administrators can usually disable prevention features in IPS products, causing them to function as IDSs, which is why the document calls both IDPS.

Based on NIST SP 800-94, sections 4.2 and 4.3.4.

Where does an IDS get traffic if it is not in the path?

From a copy. NIST defines a passive sensor as one that monitors a copy of the actual network traffic; no traffic actually passes through the sensor. There are three ways to get that copy:

• SPAN port. A switch port that sees traffic passing through the switch. If the switch is configured wrongly it misses traffic, and when a switch is under heavy loads, its spanning port might not be able to see all traffic.
• Network tap. A direct connection to the cable, such as a fibre link. It sees everything, but installing a tap generally involves some network downtime.
• IDS load balancer. Collects copies from several points and hands them to several sensors. Splitting traffic this way has a cost: if each step is considered benign on its own and different sensors see different steps, the attack may not be recognised.

Firewalls can run this way too. A PAN-OS interface in Tap mode, cabled to a SPAN port, shows the applications and threats on the network, but because the traffic is not running through the firewall when in tap mode, it cannot take any action on the traffic. The guide tells you to set Security Profile actions to alert.

How does an IPS stop an attack?

It sits inline: the network traffic it is monitoring must pass through it, usually at the boundary between networks, the same place a firewall goes. When a packet matches a blocking rule, the IPS does not forward it. NIST lists three inline-only capabilities: performing inline firewalling, throttling bandwidth usage, and altering malicious content. A passive sensor can only send TCP resets to both ends, and NIST notes that in many cases the reset packets are not received in time; resets also don't work for UDP or ICMP.

NIST's advice fits in one line: deploy sensors inline if prevention methods will be used and passive if they will not.

Suricata

On Linux, one way to run Suricata as an IPS is to have netfilter queue packets to NFQUEUE and let Suricata decide whether each one passes (Suricata 7.0: IPS/inline for Linux):

sudo iptables -I FORWARD -j NFQUEUE
sudo suricata -c /etc/suricata/suricata.yaml -q 0

Another is AF_PACKET with two interfaces, where copy-mode: ips honours the drop keyword and copy-mode: tap drops nothing.

Each rule starts with an action such as alert, pass, drop or reject; drop means drop the packet and generate an alert. A rule written to the documented format:

drop http $EXTERNAL_NET any -> $HOME_NET any (msg:"URI contains /etc/passwd"; flow:established,to_server; http.uri; content:"/etc/passwd"; sid:1000001; rev:1;)

Run as an IDS, the same rule only alerts. In Suricata's EVE log, an alert's action field is "allowed" unless a rule used the "drop" action and Suricata is in IPS mode, in which case it is "blocked". Check that field before you tell anyone a packet was blocked.

Snort 3

Snort 3 picks its mode from the command line. Reading a pcap with -r or listening with -i runs passive mode by default; if the DAQ supports inline, -Q runs Snort inline:

snort -Q --daq afpacket -i "eth0:eth1"

Which detection methods do IDS and IPS use?

NIST describes three, and most products combine them (SP 800-94, section 2.3).

Signature-based

Compare what you see with patterns of known threats, such as a telnet login as root, or an email with an attachment named freepics.exe. This is very effective at detecting known threats but largely ineffective at detecting previously unknown threats or ones disguised with evasion. NIST's own example: rename the file to freepics2.exe and the signature looking for freepics.exe no longer matches.

Anomaly-based

Build a profile of normal behaviour, then flag large deviations: the share of bandwidth used by web traffic, say, or the number of failed logins on a host. The benefit is that it can be very effective at detecting previously unknown threats. The cost is false positives. NIST's example is a monthly maintenance job that moves large files: if it didn't happen during the training period, then when it runs it is likely to be considered a significant deviation from the profile and trigger an alert.

Stateful protocol analysis

Track each protocol's state and check what is allowed in it. An FTP session that hasn't logged in should only use a few commands; most others are suspicious in that state. It also checks argument lengths: if usernames are at most 20 characters, an argument with a length of 1000 characters is suspicious. The main drawback is that these methods are very resource-intensive. A footnote adds that some vendors call this deep packet inspection.

Why is a wrong detection worse on an IPS than on an IDS?

Because an IDS false positive costs an analyst some time, while an IPS false positive blocks real traffic.

NIST defines a false positive as incorrectly identifying benign activity as malicious and a false negative as missing malicious activity. It is not possible to eliminate all false positives and negatives, and reducing one usually increases the other. A new deployment is also likely to generate a large number of false positives until fully tuned.

So my preferred order: turn a new rule on as alert, read what it matches for a while, then switch to drop only the rules that don't catch normal traffic.

If the IPS fails or is overloaded, does traffic pass or get blocked?

It depends on the setting. Fail-open lets traffic through uninspected; fail-closed blocks it. You are choosing what to lose when something breaks: inspection or availability.

NIST notes that for inline sensors, dropping packets under high loads causes disruptions in network availability, and recommends sensors that recognise high load and either pass some traffic with partial analysis or drop low-priority traffic.

Defaults differ:

• Suricata 7.0 has exception policies for conditions such as hitting a memcap. With auto, in IPS mode the default behavior for most of the exception policies is to fail close, dropping the flow or the packet. In IDS mode, auto means the policies are ignored.
• Suricata with NFQUEUE: if no program is listening on the queue, all packets that are to be queued are dropped. The bypass option makes the rule behave like ACCEPT instead, which avoids link downtime when Suricata is not running, but this also means that the blocking feature will not be present.
• FortiGate (FortiOS 7.2): config ips global has set fail-open, and the default is disable and IPS traffic is blocked when the IPS buffer is full.

config ips global
    set fail-open enable
end

Whichever you pick, agree it with the system owner and write it into the design. It shouldn't be a default nobody knows about.

Should you start with an IDS or an IPS?

If you don't yet know what normal traffic on your network looks like, I'd start with an IDS, or an IPS with its rules set to alert. Once most alerts mean something, enable drop one group of rules at a time. Before you turn blocking on:

1. The sensor is where traffic really has to pass through it, not on a SPAN port.
2. You know whether it fails open or closed, and the system owner has accepted that.
3. Every rule you will set to drop has run as alert first, and you have seen what it matches.
4. The sensor can handle peak load with your real protocol mix, not just the datasheet number; NIST notes that actual capacity depends on the protocols in use, the longevity of connections and the number of simultaneous connections.
5. The team knows how to read which packets were actually blocked, such as Suricata's action field.

Sources

• NIST SP 800-94: Guide to Intrusion Detection and Prevention Systems (IDPS), CSRC page
• NIST SP 800-94 (PDF, February 2007)
• Suricata 7.0.0: Setting up IPS/inline for Linux
• Suricata 7.0.0: Rules format
• Suricata 7.0.0: Exception policies
• Suricata 7.0.0: EVE JSON format
• Snort 3: Reading traffic
• FortiOS 7.2.0 CLI reference: config ips global
• PAN-OS: Tap interfaces