IDS vs IPS: Detection vs Prevention, With Real Examples

IDS vs IPS comes down to one verb. An intrusion detection system (IDS) watches a copy of the traffic and raises an alert. An intrusion prevention system (IPS) sits inline, in the path of the traffic, and drops the bad packet before it arrives. Same engines, same signatures. Different placement, different action.

That’s the short version. The rest of this post shows it with real rules, then runs one SSH brute force through three setups so you can see what each one actually stops. The answer isn’t the one most people expect.

	IDS	IPS
Full name	Intrusion detection system	Intrusion prevention system
Placement	Out of band, on a SPAN port or network TAP	Inline, between two network segments
Sees	A copy of the traffic	The real traffic
Default action	Alert and log	Drop, reject or block, plus alert
If it crashes	Traffic keeps flowing, you go blind	Traffic stops (fail-closed) or flows uninspected (fail-open)
False positive costs you	An alert someone has to read	A blocked legitimate connection
Adds latency	No	Some, every packet waits for inspection
Typical tools	Suricata or Snort in passive mode, Wazuh alerts	Suricata or Snort inline, NGFW IPS engines
Exam term (Security+)	Passive, tap/monitor	Active, inline

IDS vs IPS: What’s the Difference?

The difference between IDS and IPS is where the box sits and what it’s allowed to do. Both inspect packets against signatures and both can flag unusual behaviour. Only the IPS is in a position to stop anything.

Think of it like a security camera versus a security guard at the door. The camera records everything and someone reviews the footage. The guard can turn people away, but if the guard gets it wrong, an innocent person doesn’t get in. And if the guard walks off, someone has to decide whether the door stays locked or wide open.

You’ll also see the combined term intrusion detection and prevention system (IDPS). Most modern engines are both. Suricata and Snort run as an IDS or an IPS depending on how you start them, which is exactly why the “intrusion detection system vs intrusion prevention system” question is really about deployment, not product.

One common mix-up worth clearing up: anomaly detection isn’t an IPS-only feature. Both use signature-based and behaviour-based detection. The engine is the same. The verb is different.

How Does an Intrusion Prevention System Work?

An intrusion prevention system works by forcing every packet through itself before it’s forwarded. The IPS holds the packet, checks it against the rule set, then either passes it on or throws it away. Nothing reaches the other side without its say-so.

On Linux you’ll see two common ways to put Suricata in that path:

• NFQUEUE. iptables hands packets to Suricata, which returns a verdict. Suricata’s docs start it with sudo suricata -c /etc/suricata/suricata.yaml -q 0 and send traffic to the queue with sudo iptables -I FORWARD -j NFQUEUE on a gateway, or the INPUT and OUTPUT chains on a single host.
• AF_PACKET in IPS mode. Suricata bridges two interfaces itself. Each interface gets copy-mode: ips and points copy-iface at the other one. In ips mode, matching packets with a drop rule really are dropped. In tap mode no drop occurs.

Snort 3 works the same way. Passive mode can only observe. Inline mode needs the -Q flag and a DAQ that supports it, like snort -Q --daq afpacket -i "eth0:eth1".

So what does an intrusion prevention system do with a match? It depends on the action. Suricata rules support alert, pass, drop and reject. Snort 3 adds block, which drops “the current packet and all the subsequent packets in this flow.”

What Happens When the IPS Fails?

This is the part exam questions love. An inline device has to choose a failure mode:

• Fail-closed: the IPS dies, traffic stops. Secure, but you’ve just built an outage machine.
• Fail-open: the IPS dies, traffic passes without inspection. The network stays up, but nobody’s checking.

Suricata’s own docs warn about the first case: with NFQUEUE, if you stop Suricata, “the traffic will not come through.” The fix is the bypass option on the queue rule, which makes it act like ACCEPT when nothing is listening. You keep the link up and lose the blocking. That’s fail-open, chosen on purpose.

Security+ SY0-701 lists both terms by name under objective 3.2. Don’t memorise one as “correct.” The right answer depends on whether the business would rather lose security or lose connectivity.

Fail-open keeps the link up and stops inspecting. Fail-closed stops the link until the IPS comes back. On Suricata with NFQUEUE, the bypass option is what turns the second into the first.

How Does an IDS See Traffic It Doesn’t Touch?

An IDS gets a copy. The two usual sources are a SPAN port (the switch mirrors traffic from other ports to the IDS port) and a network TAP (a small device that splits the signal on a cable). Either way, the original packet keeps going and the IDS works on the duplicate.

Cisco’s Secure Firewall docs describe the same split. A passive deployment sits “out-of-band from the flow of network traffic.” An inline deployment binds two interfaces together on the segment. There’s also a tap mode, where the firewall copies each packet and drop rules still log an event saying the packet “would have dropped in an inline deployment.” That’s a great way to test a rule set before you trust it.

The IPS sits on the path, so every packet from the firewall passes through it. The IDS hangs off a SPAN port on the switch and only ever sees a copy.

The trade-off is simple. An IDS can never break your network. It also can never stop the attack it’s watching.

What Does the Same Rule Look Like in IDS vs IPS Mode?

Here’s the cleanest way to see IDS vs IPS. This representative Suricata rule, written from the documented syntax rather than copied from a public rule set, flags any source that opens more than five new SSH connections in 60 seconds. As an IDS rule it uses alert:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"SSH brute force: over 5 new connections in 60s"; flow:to_server; flags:S; detection_filter:track by_src, count 5, seconds 60; classtype:attempted-admin; sid:1000001; rev:1;)

The IPS version changes exactly one word:

drop tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"SSH brute force: over 5 new connections in 60s"; flow:to_server; flags:S; detection_filter:track by_src, count 5, seconds 60; classtype:attempted-admin; sid:1000001; rev:1;)

That’s it. Same match, same counter, same message. The drop only does anything when Suricata is actually inline (NFQUEUE, or AF_PACKET with copy-mode: ips). Load it on a passive sensor and nothing gets blocked.

A detail most guides skip: detection_filter isn’t the same as threshold. Suricata’s docs say detection_filter applies the action “on every match after” the count, while threshold fires on the Cth match and then resets. The source code confirms the edge case. The first five matches pass. The sixth one inside the window gets the action. When the 60-second window runs out, the count restarts at one.

Port 22 is the obvious target here. If you’re shaky on which services live where, keep the common ports cheat sheet open while you write rules.

Same rule, same match. The only change is the action: alert lets the connection through and logs it, drop stops it, but only on a sensor that’s actually inline.

IDS vs IPS, a Real Example: One SSH Brute Force, Three Outcomes

Numbers make this concrete. Here’s the setup. Every figure below comes from the documented rule logic, worked out step by step. It’s a calculation, not a lab capture.

• An attacker at 203.0.113.50 (a documentation address) guesses one SSH password every 3 seconds.
• Each guess is a new connection and writes one “Failed password” line to the server’s log.
• The attack runs for 15 minutes. That’s 301 guesses, from second 0 to second 900.
• Blocks take effect instantly, and TCP retransmits are ignored.

Setup 1: IDS only. Wazuh’s built-in rule 5763 watches for failed SSH logins. In the v4.14.8 ruleset it’s defined like this:

<rule id="5763" level="10" frequency="8" timeframe="120" ignore="60">
  <if_matched_sid>5760</if_matched_sid>
  <same_source_ip/>
  <description>sshd: brute force trying to get access to the system. Authentication failed.</description>
</rule>

That’s trimmed to the matching logic (the MITRE and compliance tags are cut). Eight failures from the same IP inside 120 seconds trigger a level 10 alert. The 8th guess lands at second 21, so the alert fires at second 21. Good detection. But nothing stops the attacker, so all 301 guesses reach the server unless a human steps in.

Setup 2: host-based response. Same rule, plus Wazuh active response. Wazuh’s own brute-force guide uses this block:

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>180</timeout>
</active-response>

When rule 5763 fires, the agent adds an iptables drop for the attacker’s IP for 180 seconds, and you get a rule 651 “Host Blocked by firewall-drop” alert. The attacker gets 8 guesses in, sits blocked for 3 minutes, comes back, gets 8 more. Blocks land at seconds 21, 222, 423, 624 and 825. Total: 40 guesses reach the server.

Setup 3: inline network IPS. Suricata in IPS mode with the drop rule from the last section. Five connections pass, the sixth gets dropped, and the window resets about a minute later. That’s 5 guesses through per 63-second cycle. Total: 75 guesses reach the server and 226 get dropped.

Setup	Where it acts	First action	Guesses that reach the server (15 min)
IDS only (Wazuh rule 5763)	Nowhere, alert only	Alert at 21 s	301
Host response (Wazuh active response, 180 s block)	On the target server	Block at 21 s	40
Inline NIPS (Suricata drop, 5 per 60 s)	On the wire	Drop at 15 s	75

Of 301 guesses in 15 minutes, an alert-only IDS lets all 301 reach the server. Wazuh active response (180-second block) lets 40 through, and an inline Suricata drop rule (5 per 60 seconds) lets 75 through.

Why Did the Host Block Beat the Inline IPS?

Because of tuning, not placement. The inline rule forgets the attacker after 60 seconds. The active response holds the block for 180. Raise the Suricata window, or switch the action to Snort-style block for the whole flow, and the numbers change.

Here’s the thing. “IPS is better than IDS” is too simple. An inline IPS is only as good as the rule you give it, and a well-tuned host response can outperform it. The two also combine nicely. Wazuh can read Suricata’s eve.json log as an input, so network alerts and host blocks end up on the same dashboard.

If you want to build exactly this, the Wazuh SIEM home lab with Docker gets the manager running in an afternoon.

What Happens When the Attacker Slows Down?

Run the same maths at one guess every 18 seconds. Over 15 minutes that’s 51 guesses.

Wazuh needs 8 failures inside 120 seconds. At an 18-second gap, 8 guesses take 126 seconds. Never fires. Suricata needs 6 connections inside 60 seconds. At that pace you’d need gaps of 12 seconds or less. Never drops.

So all 51 guesses get through, with zero alerts and zero drops. Both detection and prevention missed it completely. That’s a low-and-slow attack, and it’s exactly why rate rules alone aren’t enough. You need account lockout, key-only SSH, and a SIEM that correlates over hours instead of seconds.

At one guess every 18 seconds, 51 guesses in 15 minutes trigger neither Wazuh rule 5763 (8 failures in 120 seconds) nor the Suricata rule (more than 5 connections in 60 seconds).

What Are the Types of IDS and IPS?

There are three types you’ll meet in practice, split by what they watch:

• Network-based (NIDS / NIPS). Watches traffic on a segment. A network intrusion prevention system sits inline at a choke point like the internet edge or between VLANs. Suricata and Snort are the classic examples.
• Host-based (HIDS / HIPS). Runs as an agent on one machine and watches its logs, files and processes. Wazuh is the open source example most people meet first. Its config still lives under /var/ossec, a leftover from the OSSEC HIDS it grew out of. Security+ lists HIPS under mitigation techniques in objective 2.5.
• Wireless (WIDS / WIPS). Watches the radio side instead of the cable.

What Is a Wireless Intrusion Prevention System (WIPS)?

A wireless intrusion prevention system monitors the air for threats a wired sensor can’t see: rogue access points plugged into your network, evil-twin APs copying your SSID, and floods of deauthentication frames. A WIPS can contain a rogue AP, not just report it. On Cisco networks the feature is called aWIPS and runs with Catalyst 9800 wireless controllers.

What Are Some Intrusion Prevention System Examples?

Real intrusion prevention system examples, from free to enterprise:

• Suricata. Open source, multi-threaded, IDS or IPS. Version 8.0.7 shipped on 2026-09-15.
• Snort 3. The open source engine behind Cisco’s IPS. Worth knowing even if you never touch it directly, because Cisco Secure Firewall runs Snort 3 under the hood.
• Wazuh. Host-based detection with active response. Not an inline IPS, but as the example above shows, it can block. Latest release is 4.14.8 (2026-09-25).
• Next-generation firewalls. Cisco Secure Firewall, FortiGate and Palo Alto all ship an IPS engine inside the firewall. On Palo Alto it’s sold as the Threat Prevention and Advanced Threat Prevention subscriptions. If you’re new to Fortinet’s version, start with what a FortiGate firewall actually does.

Which IDS/IPS Tools Work for Home Use?

For a home lab, Suricata plus Wazuh is the easiest open source pair. Run Suricata in IDS mode on a mirrored port first, feed eve.json into Wazuh, and only flip rules to drop once you trust them. A spare mini PC or a VM is plenty. Our home lab guide covers the hardware side.

IDS vs IPS vs Firewall: What’s the Difference?

A firewall decides who’s allowed to talk. An IPS decides whether what they’re saying is an attack. An IDS just tells you about it.

A classic firewall allows or denies traffic by address, port and protocol. Port 443 to the web server? Allowed. Doesn’t matter if the HTTPS request inside carries an exploit. That’s the IPS’s job: it looks inside the allowed traffic for known attack patterns. The usual order is firewall first, then IPS behind it, so the IPS only inspects traffic that was going to be allowed anyway.

The lines blur on a next-generation firewall, which does both jobs in one box. Cisco’s older ASA line is a good example of the shift. Its replacement, Secure Firewall, puts Snort 3 inside the firewall, and the Cisco ASA end-of-life post covers what that migration looks like. If you’re heading toward Cisco security at expert level, the CCIE Security workbook covers firewall and IPS policy in depth.

Where Do SIEM, EDR and a WAF Fit?

These get lumped in with IDS vs IPS, but they solve different problems:

Tool	What it does	Relationship to IDS/IPS
SIEM	Collects logs from everything, correlates them, alerts on patterns over time	Consumes IDS/IPS alerts. Catches the low-and-slow attack above
EDR	Agent on each endpoint, watches processes and behaviour, can isolate a host	Overlaps with HIPS, goes deeper on the endpoint
WAF	Inspects HTTP/HTTPS for web attacks like SQL injection	A separate layer 7 control, not a type of IPS

So IDS vs IPS vs SIEM isn’t really a contest. The IDS or IPS produces events. The SIEM is where those events meet your firewall logs, authentication logs and endpoint data. If you’re aiming for a SOC analyst role, the CySA+ certification guide shows where that path goes next.

When Should You Pick IDS Over IPS?

Pick IDS (or an IPS in detect-only mode) when:

• Downtime is worse than a breach attempt. OT networks, medical devices, trading systems. A false-positive drop there is an incident.
• You’re tuning a new rule set. Run it as alert for a week, read what it would have blocked, then promote the clean rules to drop.
• You only have a SPAN port. No inline position, no prevention. Simple as that.

Pick IPS when:

• It’s the internet edge and the signature is precise. A rule for a specific exploit against something you haven’t patched yet is the perfect drop rule.
• Someone owns the tuning. An IPS nobody maintains will either block real users or get switched to fail-open and forgotten.

Most real networks run both. Inline at the edge with a short, trusted drop list. Everything else as alerts, all of it feeding a SIEM.

Where Do IDS and IPS Show Up on Security+ and CCNA?

CompTIA Security+ (SY0-701) covers it in four places, according to the official exam objectives:

• 2.5 Mitigation techniques: host-based intrusion prevention system (HIPS).
• 3.2 Secure enterprise infrastructure: failure modes (fail-open, fail-closed), device attributes (active vs passive, inline vs tap/monitor), and IPS/IDS as a network appliance.
• 4.5 Enhance security: IDS/IPS trends and signatures.
• 4.9 Investigation data sources: IPS/IDS logs.

That 3.2 bullet list is basically the comparison table at the top of this post. Expect scenario questions like “the sensor is on a SPAN port, can it block?” (no). CompTIA hasn’t published an official date for the next version yet, so SY0-701 is the one to study. Test yourself with our 80 Security+ practice questions.

Cisco CCNA is changing. The current CCNA v1.1 exam topics list “1.1.c Next-generation firewalls and IPS” under network components. The CCNA v2.0 exam topics, scheduled to replace it on 2027-02-03, don’t mention IPS or firewalls at all. If you sit CCNA before then, know the IPS-vs-firewall basics. After that date, IPS is no longer a listed CCNA topic.

Frequently Asked Questions

Bottom Line

IDS vs IPS is placement plus one verb.

• IDS: off to the side, sees a copy, alerts. Can’t break anything, can’t stop anything.
• IPS: inline, sees the real traffic, drops. Stops attacks, and stops legitimate traffic when it’s wrong.
• Either one misses an attacker who stays under its thresholds. That’s what correlation in a SIEM is for.

The fastest way to make this stick is to break it yourself. Fire a brute force at a lab box, watch rule 5763 fire, then turn on active response and watch the block land. The Wazuh SIEM Workbook has a free 25-page sample you can grab today, and its Active Response chapter picks up right where this post stops.

Sources

• Cisco, CCNA Exam v1.1 (200-301) Exam Topics (PDF), accessed 2026-10-13
• Cisco, Implementing and Administering Cisco Solutions (200-301 CCNA) v2.0 Exam Topics (PDF), accessed 2026-10-13
• Cisco, Secure Firewall: IPS Interface Types and Inline Sets, accessed 2026-10-13
• CompTIA, Security+ certification and SY0-701 Exam Objectives v5.0, accessed 2026-10-13
• Suricata documentation (docs.suricata.io): Rules Introduction, Thresholding, Setting up IPS/inline for Linux (8.0), and source file src/detect-engine-threshold.c at tag suricata-8.0.7, accessed 2026-10-13
• Snort 3 documentation (docs.snort.org): Reading Traffic, Rule Actions, accessed 2026-10-13
• Wazuh documentation (documentation.wazuh.com): Rules syntax, Blocking SSH brute-force attack with Active Response, Network IDS integration with Suricata; ruleset file 0095-sshd_rules.xml at tag v4.14.8, accessed 2026-10-13