SYN flood attack: half-open connections, explained

The mechanism behind that answer is on attack layers.

Establishing a connection takes three messages. The client asks to connect. The server replies that it is willing and starts waiting. The client confirms, and the connection becomes usable.

Between the second and third messages the server is committed: it has allocated an entry, recorded what it needs to remember about the pending connection, and started a timer. That entry stays until the confirmation arrives or the timer expires, and the timer is deliberately generous, because networks lose packets and slow clients are legitimate.

An attacker sends requests and never sends confirmations. Nothing needs to be exploited and no packet needs to be malformed. The server behaves exactly as designed and runs out of room.

Two details make it cheap for the sender.

No state is kept on their side. A connection request costs one packet and no memory, while it costs the recipient memory and a timer.

Source addresses can be forged. Because the sender never intends to complete the exchange, they do not need to receive the reply. The addresses in your counters may belong to hosts that sent nothing.

The evidence is in connection states rather than in application logs.

Three readings of that picture matter.

Half-open entries dominate. Requests arrive, replies are sent, confirmations never come.

Completed connections are scarce. The ratio between the two states is the signal, more than any absolute count.

Processor and memory look fine. Nothing is overloaded in the ordinary sense, which is why this is misdiagnosed as a network problem or as an application fault.

The defence that addresses the mechanism rather than its symptoms works by not allocating anything until the connection proves itself.

Instead of storing what it needs to remember about a pending connection, the server encodes that information into the reply it sends back, in a field the client is required to echo when it confirms. Nothing is kept locally. If the confirmation arrives, the server reconstructs the connection state from what came back and proceeds. If it never arrives, nothing was spent.

The effect is that a flood of unanswered requests costs the server nothing beyond the replies themselves, while legitimate clients are unaffected because they complete the exchange as they always did.

The honest trade-off. The space available for encoding is small, so some optional connection features negotiated during the handshake may not survive when the mechanism engages. Implementations differ in how much they preserve. This is why the mechanism is typically applied only when the queue is under pressure rather than at all times: normal traffic keeps the full feature set, and the degradation applies only while it is needed.

Enlarging the queue raises the volume required to fill it and consumes memory that the application would otherwise have. It buys time rather than solving anything.

Shortening the wait frees entries sooner and drops clients on slow or lossy paths, which falls unevenly on mobile networks and distant regions.

Stateless filtering upstream removes traffic before it reaches anything that tracks connections. Note the requirement: a device that itself tracks state to filter this attack has the same table and the same limit.

Terminating connections at an edge with capacity moves the queue under attack somewhere with more of it, leaving your origin to see only sessions that already completed.

The mechanism above has been standard for a long time, which raises a fair question: why is this attack still worth a page.

Three reasons, and they are all about where the defence is not.

The server is not the only thing holding state. Firewalls, load balancers, and address translation devices in the path track connections too, and the protection on the server does nothing for them. Whichever device has the smallest table and no equivalent mechanism fails first.

The reply still costs something. Answering a request is cheap, but at sufficient volume the replies themselves consume outbound capacity and packet-processing headroom. The queue survives; the link may not, which turns the event into the volumetric problem instead.

Attackers can complete the handshake. Where connections are finished and then abused, the attack moves up a layer and becomes an application problem, which is a different defence entirely. The mechanism here removes one technique rather than the whole category.

Two lookalikes, and both are common.

A genuine traffic spike produces many connections that do complete: the established count rises alongside the half-open count. In a flood the second rises alone.

A broken client or a failing network path produces the same half-open pattern from a small number of sources, with a steady rhythm, and it stops when the other side is fixed. The distinction is the number of distinct sources and whether the pattern adapts when you change something.

Bridge WAF operates on requests, which places it after the stage this attack targets. What applies is termination: connections are established at the platform's edge, so the queue absorbing unfinished handshakes is the platform's rather than your origin's, and your server sees sessions that already completed. Which component covers which layer is a fair question to ask any provider. See what the platform offers at Bridge CDN.