skip to content

In a TCP SYN flood from spoofed source addresses, what server state fills up, why do those entries linger, and why do legitimate clients fail to connect?

level: seniorimportance: should knowfreq 40%

answer

  1. state allocated before the peer is proven
  2. SYN-RECEIVED entries per listening port
  3. spoofed sources must stay silent
  4. SYN-ACK retries until a reclaim timer
  5. legitimate clients hear silence

basics

~20 s

Each SYN leaves a half-open connection in SYN-RECEIVED, held in a limited per-port backlog. Spoofed sources never answer, so entries wait out the server's SYN-ACK retries; with the backlog full, new SYNs are ignored or evict others, and real clients' connects stall.

solid answer

~50 s

For every SYN, a listening TCP allocates state and replies with a `SYN-ACK`, holding the connection in `SYN-RECEIVED` until the final `ACK` arrives. Stacks cap how many of these *half-open* connections a listening port may hold; RFC 4987 notes this backlog is not described in the standards, so its size and overflow behaviour are implementation choices. The attacker forges source addresses that will not answer: a live host receiving an unexpected SYN-ACK would reply `RST` and free the entry at once. With no answer, each entry lives until the server stops retransmitting its SYN-ACK, after an implementation-chosen time (RFC 4987 cites 75 seconds as one example). Refilling the backlog at that pace needs little bandwidth. Once it is full, new SYNs are ignored or overwrite older half-open entries, so legitimate clients hear silence, retransmit their SYNs after second-scale timeouts and connect slowly or not at all.

go deeper

for a junior

Recall that a SYN flood sends many SYNs that never complete the handshake, leaving the server holding state for connections that will never open.

for a middle

Explain SYN-RECEIVED entries, the per-port backlog, and why forged sources must be addresses that will not answer the SYN-ACK with a reset.

for a senior

Recognise the flood from client symptoms, silent SYNs and second-scale connect delays on one port while established traffic flows, and separate half-open exhaustion from link saturation.

for a principal

Weigh where to absorb handshake floods, on the host, a proxy or upstream filtering, and what each option costs legitimate clients with long round-trip times.

## The asymmetry the flood exploits A TCP server commits memory as soon as a single, unverified `SYN` arrives: it must remember the client's ISN, its own ISN, the offered options and a retransmission timer for its `SYN-ACK`. The sender of that SYN commits nothing, especially when the source address is forged. RFC 4987 (Informational, 2007) describes the SYN flooding attack as aimed not at the network or at total host memory but at **the backlog of half-open connections associated with a port number**. ## What fills up - **Half-open connections.** A connection that has received a SYN and sent a SYN-ACK sits in `SYN-RECEIVED`, waiting for the acknowledgment of its SYN. RFC 4987 calls these half-open. - **The backlog.** Kernels limit how many connection records may exist, often per listening port, and the application usually suggests the limit through the `listen()` call. RFC 4987 notes the backlog concept is **not described in the standards**: whether it counts only half-open entries or completed ones too, and what happens on overflow, varies between stacks. - **Overflow behaviour.** Commonly new SYNs are ignored, or older uncompleted entries are replaced; some stacks may send resets instead. - **Not the same queue as completed connections.** Connections that finished the handshake and wait for the application to accept them are a separate matter, owned by the operating-system sockets topic. A terminology trap is worth naming in an interview: | Phrase | RFC 4987 sense | RFC 9293 section 3.5.1 sense | |---|---|---| | half-open connection | a handshake stuck in `SYN-RECEIVED` | an established connection where one end has closed or lost its state without the other knowing | | resolved by | completion, a reset, or the server giving up | the next segment exchanged drawing a reset | ## Why spoofed entries linger 1. The attacker sends a SYN whose source address is forged as S. 2. The server moves that connection to `SYN-RECEIVED` and sends its SYN-ACK to S. 3. If S is a live host, it has no matching connection, so under RFC 9293 its TCP answers the unexpected SYN-ACK with a `RST`. The server accepts the reset and, because the entry came from `LISTEN`, returns it to `LISTEN`, freeing the slot. 4. If S is unused or unreachable, nothing answers. The server retransmits its SYN-ACK with backoff until an implementation timer reclaims the entry. RFC 4987 cites a 75-second timer as one example and 511 seconds observed in one historical BSD stack, and notes the TCP specifications themselves define no such give-up time. This is why attackers choose addresses that will stay silent, and why the attack is cheap: - A barrage only needs to be about the size of the backlog. - It only needs repeating as fast as the victim reclaims entries. - RFC 4987 notes typical default backlogs ranged from a half-dozen to several dozen entries, though servers are often configured higher. ## What legitimate clients experience - **Silence.** A SYN that finds no room is usually ignored, so the client sees nothing and retransmits after its initial timeout, which RFC 6298 recommends be 1 second, doubling per retry. Connects take seconds or time out. The symptom looks like packet loss or a filtering firewall, not like a closed port. - **Evicted handshakes.** Where a stack recycles the oldest half-open entry, a real client's entry can be pushed out before its ACK arrives, which RFC 4987 calls not robust when the attacker fills the backlog faster than handshakes complete. Clients with long round-trip times suffer first. - **Existing connections.** The flood targets connection *setup* on the attacked port; connections already `ESTABLISHED` keep working unless the host is overloaded in some other way. ## Defences, and who owns them RFC 4987 surveys the common defences; their tuning belongs to other topics. | Defence (RFC 4987 section 3) | Idea | Owned by | |---|---|---| | Filtering | drop packets with forged sources near their origin | network defence | | Increasing backlog | make the table bigger | operating-system sockets | | Reducing the SYN-RECEIVED timer | reclaim entries sooner | operating-system sockets | | Recycling the oldest half-open entry | evict under pressure | operating-system sockets | | SYN cache | keep a smaller record until the handshake completes | operating-system sockets | | SYN cookies | keep no record, encode it in the SYN-ACK | network defence | | Firewalls and proxies | complete or validate the handshake on the server's behalf | network defence | The handshake-level lesson is the one to keep: any design that allocates state for an unproven peer can be exhausted by someone who never intends to prove anything.

  • Why does a SYN flood attacker prefer spoofed source addresses that belong to no live host?
    A live host that receives a SYN-ACK for a connection it never opened has no matching state, so its TCP answers with a RST. The server accepts that reset and returns the entry to LISTEN, freeing the slot. Addresses with no live host leave every entry to wait out the server's full SYN-ACK retry period.
  • Why do users of a TCP server under a SYN flood usually see slow or hanging connects rather than immediate refusals?
    Most stacks ignore a SYN they have no room for rather than resetting it, so the client hears nothing and falls back to SYN retransmission from a 1-second initial timeout (RFC 6298), doubling per retry. The result is multi-second connects and timeouts. RFC 4987 notes some stacks may send resets instead, so the exact symptom is implementation-specific.
  • Is the half-open state a SYN flood fills the same thing RFC 9293 calls a half-open connection?
    No. RFC 4987 uses half-open for handshakes stuck in SYN-RECEIVED. RFC 9293 section 3.5.1 uses it for an established connection where one end has closed or lost its state, for example after a reboot, without the other knowing; the next segment exchanged draws a reset. Same phrase, different failures.

saying these in an interview costs you the question

  • A SYN flood works by saturating the server's network link.
  • Half-open entries are freed as soon as the SYN-ACK has been sent.
  • Spoofing the addresses of live hosts makes a SYN flood stronger.
  • The TCP specification fixes the backlog size and its overflow behaviour.
  • A SYN flood tears down every established connection on the server.