Network intrusion detection (NIDS/NIPS)

A network IDS watches a copy of the traffic and raises alerts on matches to known-bad signatures or unusual patterns; a network IPS sits inline and can drop the offending packets, trading the risk of blocking good traffic for active prevention. It automates, in real time, the kind of reading you do by hand over a capture — the same conversations, requests and beacons, matched against rules as they fly past.

How an IDS and an IPS work, step by step

A firewall decides by addresses and ports. An attack that rides an allowed connection, such as a web request for ../../../etc/passwd, passes every port rule. Catching it means reading the traffic's content. A network intrusion detection system (IDS) does that on a copy of the traffic; an intrusion prevention system (IPS) does it inline, and can drop what matches. Suricata and Snort are the common open-source engines, and the steps are the same:

1. Capture. An IDS gets a copy of the frames from a switch's mirror port (SPAN on Cisco) or a network tap. An IPS sits in the path: on Linux, the kernel hands each packet to the engine through NFQUEUE and waits for a verdict.
2. Decode and reassemble. The engine decodes Ethernet, IP and TCP, puts TCP segments back in order, and parses the application protocol: HTTP, DNS, TLS. Rules can then match on fields such as an HTTP URI or a TLS server name, not just raw bytes.
3. Match. Each flow is compared with the signatures: patterns of known attacks, often tens of thousands of them from feeds such as Emerging Threats. Some engines also flag anomalies, traffic unusual for this network.
4. Act. An IDS writes an alert. An IPS can also drop the packet, or reject it with a TCP reset, so the attack never reaches the server.
5. Report. Alerts go to a log and, in practice, to a SIEM, where people triage them.

The trade-off is placement. An IDS cannot stop anything, but if it fails, traffic flows on. An IPS stops attacks, adds delay to every packet, and when it fails it either lets everything through (fail open) or nothing (fail closed).

What it looks like on a Linux machine

In the IDS and IPS lab a sensor runs Suricata on a mirror port with one signature:

alert http any any -> any any (msg:"NETLAB passwd file request"; flow:to_server,established; http.uri; content:"passwd"; nocase; classtype:attempted-recon; sid:1000001; rev:1;)

Read it as a sentence: alert on HTTP from anywhere to anywhere, on requests within an established connection, when the URI contains passwd in any case. sid numbers the rule (1000000 and up are for your own), rev is its revision. The attacker's request still gets its answer, because the sensor only had a copy, and Suricata writes one line to fast.log:

10/10/2026-12:00:01.123456  [**] [1:1000001:1] NETLAB passwd file request [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.0.1.13:51234 -> 10.0.2.10:80

and a JSON event to eve.json with the HTTP host and URL, which jq filters. Inline on the gateway, the same rule with drop instead of alert, and one iptables rule queueing forwarded packets to it:

iptables -I FORWARD 1 -j NFQUEUE --queue-num 0 --queue-bypass

The attack's request never reaches the server, the attacker's curl times out with exit code 28, and the log line starts with [Drop].

What goes wrong, and how you see it

False positives. The rule above also fires on /reset-passwd, an ordinary page. Too many such alerts and people stop reading them. Tuning makes the signature specific: match /etc/passwd, bump rev, and reload the rules with suricatasc -c reload-rules without stopping the engine. suppress and threshold silence an alert for one address or limit how often it fires.

False negatives. An attack no signature matches raises nothing, and nobody knows. Encryption is the biggest cause: the engine sees TLS, not the URL inside, unless traffic is decrypted at a proxy or inspected on the host.

A sensor that sees half. A mirror of one direction, or of the wrong port, gives the engine half of each conversation. Rules that need the established flow do not fire.

Dropped packets at the sensor. A mirror carries more than the sensor can process, and its capture statistics show drops. What was dropped was never inspected.

The IPS that failed. With --queue-bypass a stopped Suricata lets everything through, attacks included. Without it, the office loses the servers. Choosing between them is a policy decision.

Questions people ask

What is the difference between an IDS and an IPS? The same engine and rules. An IDS watches a copy and alerts; an IPS is in the path and can block.

Is an IPS the same as a firewall? No. A firewall decides by addresses, ports and connection state. An IPS reads content against signatures. Next-generation firewalls bundle both.

What is the difference between a network IDS and a host IDS? A NIDS watches traffic on the wire. A HIDS runs on one machine and watches its files, logs and processes, where encrypted traffic is already decrypted.

See it on real machines