All DDoS Definitions
DDoS Testing Definition

Stateful Firewall

A stateful firewall is a network-layer defensive control, one of the enforcement points a DDoS test drives traffic through to find where connection state runs out. Unlike a stateless ACL that judges each packet in isolation on its headers, a stateful firewall remembers connections. It tracks every flow through its lifecycle, records the state in a table, and uses that memory to allow return traffic and drop packets that do not belong to any connection it is watching.

Stateful firewall: connection state is a finite resource incoming packets established flow out-of-state packet SYN flood (spoofed) Stateful firewall connection state table (finite slots) 10.0.0.4:443 established 10.0.0.7:443 established 10.0.0.9:443 established half-open SYN entries piling up table full: no free slot one slot per connection; out-of-state is dropped table full: new legitimate SYNs dropped too origin reachable in-state traffic forwarded state table exhausted the firewall is the layer of first failure The table is a hard ceiling: a connection flood spends slots faster than they free, and the device falls over. A test finds the offered rate that fills the table, and whether the device fails open or fails closed. BlackNeuron
Diagram: a stateful firewall tracking connections in a finite state table, forwarding established flows to the origin while dropping out-of-state packets, and failing when a flood fills the table

How state tracking works

For every connection, the firewall stores an entry keyed on the 5-tuple: source and destination IP, source and destination port, and protocol. The entry records where the connection sits in its lifecycle (a new SYN, an established session, a half-closed teardown), and the firewall consults this table on every packet. A packet that matches an established entry passes without re-evaluation; a packet that matches nothing, an ACK for a session that was never opened or a spoofed out-of-state segment, is dropped.

That memory is what makes the firewall useful and what makes it fragile. State lives in a finite table, and each tracked connection consumes a slot. On Linux the table is conntrack; on commercial firewalls it is a session table with a hard vendor limit. The number is large but bounded, and a bounded resource is one an attacker can try to exhaust.

Stateless where it counts, stateful where it helps

The lesson most resilient architectures encode is that state should be committed as late and as cheaply as possible. A stateless filter at the edge can drop obviously malformed or spoofed traffic without ever allocating a table entry, because it decides per packet on headers alone. Only traffic that survives that cheap first pass should be allowed to consume a state slot deeper in the path.

Where a stateful device is unavoidable, its table is a tunable resource rather than a fixed one. On Linux, nf_conntrack_max sets the ceiling and the various timeout values decide how long a half-open or idle entry squats on a slot; shortening the SYN-received timeout frees slots faster under a flood, at the cost of dropping genuinely slow clients sooner. Those numbers are the difference between a firewall that absorbs a connection flood and one that becomes its first casualty, and they are exactly what a test exercises.

Why it becomes the layer of first failure

A SYN flood is not fundamentally an attack on bandwidth. It is an attack on this table. Each spoofed SYN opens a half-formed entry that sits consuming a slot until it times out. Enough of them and the table fills, and once it is full the firewall has no room to record a new connection, so it drops the next legitimate SYN alongside the attack.

The device meant to protect the origin becomes the layer of first failure, and it fails before the origin ever sees load. This is why a stateful firewall placed directly in an attack path is often the wrong tool for volumetric defense, and why upstream controls that validate a handshake before committing state, such as SYN cookies, exist at all. The firewall's state is precisely the thing a connection flood is trying to spend.

Stateful firewall: in-state flows are forwarded, out-of-state packets absorbed incoming packets Stateful firewall tracks connection state Origin established flows in-state, forwarded out-of-state, dropped BlackNeuron
Animated stateful firewall tracking connections: established flows are forwarded to the origin while out-of-state and spoofed packets are absorbed before they reach it

What a DDoS test measures

A test finds the number. It drives connections at a rising rate and measures the offered rate at which the state table saturates and new sessions start failing: the practical capacity of the device under a connection flood, rather than its datasheet throughput. Those two figures are rarely the same.

It also observes the failure mode. A firewall that fails closed drops everything when its table is full, taking the service down cleanly; one that fails open stops inspecting and passes everything, exposing the origin. Neither is a state you want to discover for the first time during a real incident.

2026-08-14T06:10:28.243643 image/svg+xml Matplotlib v3.5.1, https://matplotlib.org/ 0 50 100 150 200 250 Time (seconds) 0 2000 4000 6000 8000 10000 Concurrent connections tracked state table capacity 1x Simulated shape, not measured data Stateful firewall: connections tracked climb into the state-table ceiling Observed request rate Clean baseline BlackNeuron
Connections tracked as an attack ramps: the firewall's state table fills toward its capacity line, and once it saturates, new legitimate connections are dropped alongside the flood

The state table is the quiet ceiling in most architectures: invisible at rest, decisive under load, and impossible to size correctly from a spec sheet. Finding where it sits is the kind of measurement that has to happen against real infrastructure without taking it down, a discipline of its own. See DDoS testing without disrupting production.