Firewall, IPS, WAF or DDoS Appliance: Which Control Owns Which Failure

Most arguments about whether a firewall can “do DDoS” are really arguments about which resource an attack consumes, and they resolve immediately once that question is asked explicitly. Denial of service is resource exhaustion RFC 4732, and each control in the path holds a different resource. The control that owns the resource under attack is the one that fails.

The boundary in one table

Appliance	Holds per-session state	Answers volumetric floods	Answers state exhaustion	Answers application-layer floods
Router or upstream filtering	No	Yes, before your circuit	Partly, bluntly	No
Firewall	Yes — this is the target	No	No — it is what fails	Partly, if it proxies
IPS	Yes	No	No	Only known signatures
WAF	Yes, after termination	No	No	Yes, for accepted requests
Dedicated DDoS mitigation	Deliberately minimal	Up to its own capacity	Yes — the design centre	Depends on the product

Read the second column downward: only one row answers saturation, and it is the one that is not in your building. That is the constraint no purchase removes.

Why a firewall becomes the target

A stateful firewall exists to remember. For every session it permits it holds an entry — addresses, ports, sequence state, timers — and that table is finite. It is also the thing a state-exhaustion attack is designed to fill.

This is why the capacity numbers mislead so reliably. A firewall rated for tens of gigabits of throughput can be taken out by a few hundred megabits of well-chosen packets, because the constraint being attacked is not bandwidth. Half-open connections consume slots without ever completing; ACK floods make the device look up sessions that do not exist; fragmentation fills reassembly buffers. None of these need volume.

The firewall’s flood defences are real and worth enabling: SYN cookies avoid allocating an entry until the client proves it is there, aggressive session ageing recovers slots faster, per-source connection limits bound one source’s share. What none of them change is that the defence and the target are the same device, and that under sufficient pressure the device stops forwarding legitimate traffic as well.

A dedicated mitigation layer differs on exactly this axis: it is built to decide about traffic without first committing per-session state to it. That is the whole architectural argument, and it is checkable rather than rhetorical.

What an IPS is and is not for

An intrusion prevention system inspects traffic for known malicious patterns. It addresses exploitation — someone trying to break in — rather than availability, and it holds state to do it, which means it shares the firewall’s exposure to exhaustion.

It belongs in the estate. It does not belong in this conversation except as one more stateful device that needs something in front of it.

What a WAF genuinely overlaps with

The overlap between a web application firewall and application-layer DDoS defence is real and frequently understated by both camps.

A WAF sits after the TCP handshake and after TLS termination, examining complete requests. That position lets it do things no network-layer device can: recognise an expensive endpoint being hammered, apply per-client rate limits with application context, challenge a suspicious client, distinguish a scraper from a browser.

The same position is why it is irrelevant to a SYN flood. A request that never completes a handshake never becomes a request, and a WAF only ever sees requests. Traffic that exhausts the connection table upstream of it has already produced the outage before the WAF had an opinion.

The honest summary is that a WAF and a dedicated mitigation layer overlap at Layer 7 and do not overlap at all below it, and that in a large estate both frequently exist for exactly that reason.

The router and the upstream

The controls furthest from your servers are the only ones that address the failure closest to physics.

Ingress filtering at network borders RFC 2827 limits the spoofed sources that make reflection possible — it protects others from your network rather than your network from others, which is why it remains unevenly deployed and why it is a shared obligation rather than a product feature.

Blunt upstream instruments — remotely triggered black hole filtering RFC 5635, FlowSpec rules — stop saturation reaching your circuit at the cost of dropping some or all traffic to a destination. They are the tools of last resort, and having rehearsed them matters more than having documented them.

Nothing you install in your own rack substitutes for either.

When a flood-protection feature is enough

There is a real answer here and it is not always “buy the appliance”.

A feature on an existing device is enough when your exposure is moderate rather than targeted, when the attacks you actually see are volumetric and your upstream handles them, when your application layer is behind a CDN with the origin concealed, or when your circuit is small enough that anything serious saturates it regardless of what sits behind.

It stops being enough when the attacks are shaped rather than large — state exhaustion, low-and-slow, application-layer requests that are individually valid — because those are aimed at the resource the feature’s host is running on.

When a dedicated appliance is the wrong purchase

Worth saying plainly, because the category rarely does.

For an estate that lives entirely inside one hyperscaler, native controls see the traffic and an appliance mostly does not; buying one is frequently a way to spend capital on a layer that never gets to make a decision.

For a small organisation whose whole exposure sits behind a CDN, with a properly concealed origin, the CDN is the mitigation and a second layer adds operational burden without adding coverage.

For an organisation with no capacity to operate it, an appliance in default configuration is a device that will be blamed after the incident rather than one that prevents it.

The appliance conversation becomes right when traffic reaches infrastructure you operate, when you need the decision made locally, when you have to hold the evidence, or when the application layer is your actual exposure.

Layering, in the order the failures arrive

1. Upstream capacity answers saturation. Nothing else does.
2. Dedicated mitigation answers state exhaustion and, depending on the product, the application layer.
3. The WAF answers application-layer abuse among requests that were accepted.
4. The firewall and IPS do their own jobs, protected by the layers above rather than defending against this class.
5. Host and platform tuning raises the floor under all of it — the layer covered in the hardening section, and the cheapest thing on this list.

A design that skips level one and buys level two has bought a device that will make correct decisions until the circuit fills. A design that has level one and nothing else will absorb volume and lose to a hundred megabits of well-shaped packets.

What to establish before deciding

Which attack classes have actually reached you, and which resource each one consumed. What your smallest circuit in the path is. Whether your firewall’s session table has ever been the constraint. Whether your application layer is exposed directly or behind something. And who would operate a new layer, at 3am, in the second year.

The proof-of-concept methodology turns those into measurements. The cloud, on-premises and hybrid comparison turns the measurements into a shape.

Sources