What is a stateful firewall?
A stateful firewall tracks sessions and knows whether a packet belongs to an established connection, so it drops DDoS traffic without a rule per vector.
Last updated:
A stateful firewall is a filter that remembers context. Rather than judging each packet in isolation, it keeps a table of active sessions and, for every packet, checks whether it belongs to a connection that was actually established. It looks like a small difference, but it changes the whole logic of defence: the decision stops depending on what the packet looks like and starts depending on whether anyone was expecting it.
Stateful versus stateless
A stateless filter only has what it can see in a single packet: addresses, ports, protocol, flags. A rule like "allow traffic to port 443" is simple and fast, but it cannot tell a reply to your query apart from a packet that arrived out of nowhere. A stateful firewall knows the history: it knows a query went out that this reply matches, or that nothing of the sort did.
For security that has a concrete consequence. A stateless filter needs a rule for every known attack vector, which means it is always one step behind the attacker. A stateful firewall drops everything out of context by definition, before anyone has even named the new vector.
Why it works so well against DDoS
A large share of DDoS traffic consists of packets belonging to no conversation at all. An ACK with no preceding SYN, a DNS or NTP reply nobody asked for, a fragment without a header, traffic from a spoofed source address: none of it stands a chance of matching an entry in the session table. Dropping such a packet requires no attack recognition and no signature, it follows directly from how the thing works.
This shows best with reflected traffic. Replies bounced off CDNs or public resolvers carry entirely genuine source addresses, so an IP blocklist either misses them or takes down services your users depend on. Session state offers a third way out: the source stays reachable and only the packet nobody ordered is dropped.
The cost: the state table is a resource
Tracking sessions costs memory, and the state table itself becomes a target. A classic SYN flood fills it with half-open connections and it is the first thing to fall over. That is why a well-built stateful firewall pairs connection tracking with mechanisms that create no state for an unauthenticated packet: SYN cookies defer creating the entry until a valid ACK returns, and SYN proxy completes the handshake on its own behalf. Table size and entry expiry are parameters to be matched to the traffic, not left at defaults.
Where such a firewall belongs
A stateful firewall in front of a single server protects that server as long as its link has room. In a volumetric attack the uplink becomes the bottleneck, and then it makes no difference how good the filter behind it is. That is why operators move stateful filtering to the network edge, above the customer port, where there is still capacity to absorb the attack traffic and drop it before it competes with real users.
Frequently asked questions
Will a stateful firewall handle layer 7 attacks?
Partly. An application-layer attack carried over properly established HTTPS sessions matches the state table by definition, so session state alone will not stop it. You also need layer 7 filtering that looks at the content of the request rather than just the packet header. Session state does take care of layers 3 and 4, which is the vast majority of the volume.
Does tracking sessions add latency?
In practice not in any way a user can measure, provided the filter is sized for the traffic it handles. Looking up a table entry takes nanoseconds. The problem is usually not the latency but the table filling up, and it is its size and entry expiry policy that decide how it behaves under load.