IDS vs IPS vs Firewall: Which One Actually Stops the Attack?

A healthcare organization gets breached. The post-incident report reveals the attacker moved laterally through their network for 23 days before exfiltrating patient records. The organization had a firewall. It had an IDS. The IDS generated 847 alerts over those 23 days.

Nobody acted on them.

This scenario plays out in breach reports constantly — not because organizations lack security tools, but because they misunderstand what each tool does, how the tools interact, and most critically, what each one is actually capable of stopping versus what it can only observe.

The firewall didn't fail. The IDS didn't fail. The architecture failed — specifically, the assumption that detection is the same as prevention, and that a tool generating alerts is the same as a tool stopping attacks.

Network security and firewall

The Foundational Confusion That Leads to Misconfigured Security

The most damaging misunderstanding in network security architecture is treating these three tools as equivalent alternatives rather than as components with distinct functions in a layered defense.

The wrong mental model: Firewall blocks things. IDS detects things. IPS prevents things. Pick what you need and deploy it.

The correct mental model: These tools operate at different points in the attack chain, on different traffic characteristics, with different response capabilities, and with different failure modes. A gap in understanding any one of them creates an exploitable gap in the architecture.

The questions that actually define what each tool does:

Does it operate on allowed traffic or denied traffic?
Does it act before damage occurs or after?
Does it have automated blocking capability?
Does it understand application-layer content?
Where in the network path does it sit?

The answers to these questions separate the tools more clearly than any definition.

Firewalls: What They Actually Block and What Gets Through

A firewall's decision is made on traffic metadata — addressing, protocol, and connection state. It does not read the payload. A packet from any IP on port 443 destined for your web server will pass through a firewall configured to allow inbound HTTPS, regardless of what that packet contains.

This is the fundamental limitation practitioners must internalize: firewalls enforce access policy, not content policy.

What firewalls actually stop:

Traffic from explicitly denied IP addresses or ranges
Traffic on ports that are closed
Traffic that doesn't match expected connection states (stateful firewalls reject packets that don't belong to an established TCP session)
Traffic from geographic regions if geo-blocking rules are configured

What gets through firewalls that operators often assume is blocked:

Malware in allowed traffic: A malicious payload delivered via a phishing link over HTTPS is encrypted traffic on port 443. The firewall sees a valid HTTPS connection and allows it. The malware has entered.

Command and control (C2) over allowed ports: Once malware is on an endpoint, it typically communicates outbound on port 443 or 80 — which every firewall allows for normal browsing. The C2 traffic is indistinguishable from legitimate HTTPS traffic to a standard firewall.

SQL injection in HTTP requests: A web application firewall (WAF) inspects HTTP content. A standard network firewall does not. SQL injection arrives as allowed HTTP traffic — it sails through a standard firewall without examination.

Lateral movement on internal networks: After initial compromise, attackers move between internal systems using protocols like SMB, RDP, or WMI. If your internal firewall rules allow these protocols between workstations (which many organizations do), lateral movement is unrestricted.

Practical pros of firewalls:

Stops a substantial class of attacks before they reach the network
Stateful inspection catches spoofing and fragmentation attacks
Very low latency impact
Mature technology with well-understood failure modes

Honest cons:

Completely blind to payload content
Cannot stop attacks that arrive on allowed ports
Rule sets become complex and often degrade over time as exceptions accumulate
East-west traffic is often insufficiently filtered

IDS: Detection Without Action — The Tool That Creates a False Sense of Security

An Intrusion Detection System operates out-of-band — it receives a copy of network traffic (via a SPAN port or network tap) and analyzes it for malicious patterns. It does not sit in the traffic path. It cannot block anything.

This is not a design flaw. Out-of-band placement means the IDS has zero impact on network performance and zero risk of dropping legitimate traffic through false positives. But it also means that every alert the IDS generates represents a threat that has already passed through the network.

What IDS actually does:

An IDS applies detection logic to the traffic copy — signature matching (known attack patterns), anomaly detection (statistical deviation from baseline), and behavioral analysis (protocol violations, unusual data volumes). When a match occurs, the IDS logs the event and sends an alert.

The alert is sent to a SIEM, a dashboard, an email inbox, or a ticketing system. Then it waits for a human.

The problem in production environments:

IDS systems in real organizations generate enormous alert volumes. Misconfigured IDS deployments with aggressive signatures can produce thousands of alerts per day. Security teams engaged in alert triage — manually reviewing whether each alert represents a real threat — face a situation where the signal-to-noise ratio becomes so poor that critical alerts are buried.

This is the mechanism behind the 23-day breach described in the introduction. The IDS was detecting the lateral movement. The alerts were real. They were lost in a flood of lower-severity events.

What IDS is genuinely good for:

Forensic investigation: After a breach, the IDS logs provide a timeline of what happened, which systems communicated with which attacker infrastructure, and what attack techniques were used.

Threat hunting: Security analysts actively searching for attacker presence use IDS data to build hypotheses and trace activity patterns across the network.

Compliance evidence: Many regulatory frameworks require detection capabilities and logging. IDS provides auditable evidence of monitoring.

The honest assessment: If your goal is stopping attacks, an IDS alone does not accomplish that goal. It tells you what's happening. It does not change what's happening. Organizations that invest in detection tooling without the analyst capacity to act on alerts within minutes — not hours, not days — have created expensive logging infrastructure that documents breaches rather than preventing them.

IPS: Inline Prevention With Real Consequences for Getting It Wrong

An IPS sits in the active traffic path — not on a copy. Every packet traverses the IPS sensor, is analyzed, and is either passed or dropped. If the IPS identifies a packet as malicious, it drops the packet before it reaches its destination.

This is prevention, not detection. The attack packet never arrives.

What this placement means operationally:

The IPS is a bottleneck by design. All traffic passes through it, so:

Latency impact is real: Deep packet inspection takes time. IPS appliances add 1-5ms of latency per packet.
False positives have direct user impact: When an IDS false-positives, an analyst reviews an alert and dismisses it. When an IPS false-positives, legitimate traffic is dropped. Users can't reach websites. Application transactions fail. Business operations halt.
Throughput must scale with traffic volume: A 10Gbps network needs an IPS capable of line-rate inspection at 10Gbps.

What IPS stops that firewalls miss:

Application layer attacks: SQL injection, cross-site scripting, command injection — these travel on allowed ports in the payload of HTTP/HTTPS requests. An IPS with web application inspection signatures recognizes these patterns and drops the malicious request before it reaches the web server.

Exploit traffic on allowed protocols: A buffer overflow exploit sent over an allowed port contains specific shellcode patterns that IPS signatures recognize, even if the port itself is permitted.

Known malware communication patterns: C2 beacons, malware download requests, and botnet communication often use distinctive patterns that IPS signatures identify in the payload of otherwise-allowed traffic.

The IPS failure modes:

Evasion techniques: Fragmented packets, polymorphic shellcode, encrypted payloads are specifically designed to evade IPS signatures
Zero-days: IPS signature-based detection requires a known attack pattern. A previously unknown exploit has no signature.
Encrypted traffic: Without SSL/TLS inspection, an IPS is blind to attacks in HTTPS traffic

Practical pros:

Blocks known attacks in real time before they reach targets
Inline placement means no analyst action required for blocking
Current signatures cover an enormous range of known exploits

Honest cons:

False positives block legitimate traffic — tuning is ongoing operational work
Blind to encrypted traffic without SSL inspection
Signature-dependent — zero-days and novel techniques evade detection
Adds latency and requires correctly-sized hardware

Security operations monitoring

How Attackers Exploit the Gaps Between All Three

Understanding what each tool does individually is less important than understanding the gaps between them — because attackers exploit gaps, not tools.

Gap 1: The firewall-to-IPS gap (lateral movement)

Most organizations deploy IPS at the network perimeter, inspecting traffic entering from the internet. Traffic between internal segments — workstation to workstation, workstation to server — often passes through no inspection at all.

Once an attacker achieves initial compromise via a phishing email (which the firewall allowed because it's inbound HTTPS), they move laterally using SMB, RDP, or WMI on internal networks. No perimeter IPS sees this traffic. No firewall blocks it.

The fix: Internal network segmentation with firewall rules between segments, and IPS coverage on east-west traffic, not just north-south.

Gap 2: Encrypted traffic blindness

Approximately 90% of current malware C2 communication uses HTTPS. Standard IPS without SSL inspection is completely blind to this traffic. The malware beaconing to its command and control server over port 443 generates no IPS alert because the payload is encrypted.

Gap 3: The detection-without-response problem

An IDS alert that triggers a response in 23 days is documentation, not prevention. Organizations that invest in detection tooling without investing proportionally in the analyst capacity and playbooks to respond have created an expensive paper trail rather than a functioning security program.

Gap 4: Signature lag on novel techniques

The time between a new attack technique being used in the wild and a reliable signature being published and deployed ranges from days to weeks. During this window, the attack is transparent to signature-based systems.

Next Generation Firewalls: Where the Lines Blur

The core idea of NGFWs is sound: traditional firewalls are limited to network-layer inspection, and NGFWs add application-layer awareness.

What NGFWs add that traditional firewalls lack:

Deep packet inspection (DPI): NGFWs examine packet payloads, not just headers
Application identification: An NGFW can identify that a connection on port 443 is Dropbox, not generic HTTPS
Integrated IPS functionality: Many NGFWs include IPS signature engines
SSL/TLS inspection: NGFWs with SSL inspection capabilities can decrypt, inspect, and re-encrypt HTTPS traffic
User identity awareness: Integration with Active Directory allows policy based on user identity

What NGFWs don't solve:

The addition of IPS capabilities to a firewall does not solve the east-west traffic problem. If the NGFW is deployed only at the perimeter, lateral movement between internal segments is still invisible.

Building the Layered Architecture That Actually Stops Attacks

The correct architecture isn't "deploy all three and assume you're protected." It's deploying each tool where its capabilities are strongest, ensuring the gaps between them are explicitly addressed, and connecting detection to response with sufficient speed to matter.

The architecture that addresses the major gaps:

Layer 1 — Perimeter firewall (NGFW):

Block inbound traffic by default, allow only required services
Apply geo-blocking for regions with no business users
Enable IPS signatures on internet-facing traffic
Enable SSL inspection for outbound traffic

Layer 2 — Internal segmentation firewall:

Segment the network into zones: user workstations, servers, privileged infrastructure, DMZ
Restrict east-west traffic between zones to only required protocols and ports
Workstations should not be able to reach other workstations via SMB

Layer 3 — IDS/SIEM with analyst coverage:

Deploy IDS out-of-band across key internal segments, not just the perimeter
Alert fatigue is an architecture problem — tune signatures aggressively
Require SOC response SLAs: critical alerts acknowledged in 15 minutes, investigated in 1 hour

Layer 4 — Endpoint detection (critical to this conversation):

Endpoint Detection and Response (EDR) catches attacker behavior on compromised hosts — the lateral movement, credential dumping, and persistence mechanisms that network tools can't see

The practical question — what to deploy first:

Phase 1 (must have): NGFW at perimeter with default-deny inbound, IPS signatures enabled + EDR on all endpoints

Phase 2 (significant impact): Internal segmentation firewall + IDS/SIEM with defined alert triage processes or managed SOC

Phase 3 (closes remaining major gaps): SSL/TLS inspection + DNS security + Deception technology

The organizations that get breached most often are not those without security tools — they're those with Phase 1 configurations while attacker techniques have evolved to exploit Phase 2 and Phase 3 gaps.

Closing

Understanding the distinction between IDS, IPS, and firewalls — what each prevents, what each only detects, and where the gaps between them live — is foundational security architecture knowledge. But it's the starting point of a discipline that goes significantly deeper.

Detection without response is documentation. Prevention without detection is blindness. The architecture that works combines both.