SYN Flood

A SYN flood is a denial-of-service attack on TCP. The attacker sends connection-request (SYN) segments and never completes the three-way handshake. The server then keeps each one as a half-open connection until it has no room left for anyone else. RFC 4987 is the IETF's reference document on it. It is informational, not a standard: the memo "does not specify an Internet standard of any kind". It states the mechanism in one sentence: "The basic idea is to exploit this behavior by causing a host to retain enough state for bogus half-connections that there are no resources left to establish new legitimate connections."

What a SYN flood is not matters as much. It is not a bandwidth attack: "The SYN flooding attack does not attempt to overload the network's resources or the end host's memory, but merely attempts to exhaust the backlog of half-open connections associated with a port number." It is not a bug in any one stack. It abuses the handshake exactly as specified. It is not a full outage: the attack "attempts to prevent only the establishment of new incoming connections to the victim port, and does not impact outgoing connection requests, nor previously established connections to the victim port". So sessions already open keep working while nobody new can get in. It is not inherently distributed, either. One host with spoofed source addresses is enough. That is why the precise term is denial of service. It becomes DDoS only when the SYNs come from many sources at once.

What makes it work is cost asymmetry. A SYN costs the attacker one small packet. It costs the server a connection-state allocation. That allocation survives until a reaping timer expires. RFC 4987 notes that the attack "targets end-host resources, which require fewer packets to deplete". The RFC adds that ideally, "the barrage size is no larger than the backlog". Since "Typical default backlog values vary from a half-dozen to several dozen", the packet volume needed to shut an unprotected listener can be trivial. Bill Cheswick and Steve Bellovin found the weakness "as early as 1994". It was "first publicized in 1996, with the release of a description and exploit tool in Phrack Magazine". It has been a standard network-layer vector ever since.

How it works

Opening a TCP connection takes the three-way handshake. RFC 9293, the current TCP standard, defines it as "the procedure used to establish a connection": the client sends SYN, the server replies SYN-ACK, the client replies ACK. The attacker stops after the first step.

1. SYNs arrive at a listening port. The source addresses are normally spoofed. They are chosen with care: "it is important that the spoofed IP addresses be unresponsive to the SYN-ACK segments that the victim will generate."
2. The server allocates state for each one. Per the spec, "the state transitions to SYN-RECEIVED, and some of the TCB is initialized with information from the header fields of the received SYN segment". In practice, most systems copy the Transmission Control Block rather than modify the listening one. So "new (or unused) memory must be devoted to the copied TCB."
3. The final ACK never comes. A reachable host would end it immediately: "If addresses of normal connected hosts are used, then those hosts will send the victim a TCP reset segment that will immediately free the corresponding TCB and allow room in the backlog for legitimate connections to be made." Unresponsive addresses send nothing, so the entry sits there until a timer reclaims it.
4. The backlog fills and new clients are refused. "By keeping the backlog full of bogus half-opened connections, legitimate requests will be rejected." What the refusal looks like depends on the stack: "When the backlog limit is reached, then either incoming SYN segments are ignored, or uncompleted connections in the backlog are replaced."
5. The attacker only has to keep pace with the reaper. "To remain effective, a SYN flooding attack needs to send new barrages of bogus connection requests as soon as the TCBs from the previous barrage begin to be reclaimed." The rate is tuned to the victim's reclamation timer, not to any bandwidth target.

Spoofing is not required. An attacker can instead use a botnet, "a collection of compromised hosts under the attacker's control". In that case, "each host utilized in the attack would have to suppress its operating system's native response to the SYN-ACKs coming from the target." That variant defeats source-address filtering and IP blocklists: every source address is real and reachable.

Why it matters for a CDN

A SYN flood lands wherever the TCP handshake terminates. With a CDN in front, that is no longer your server. The edge server in the nearest point of presence accepts the connection. Your origin only ever sees connections the CDN has already completed and proxied. Cloudflare describes its own version plainly: "Cloudflare handles the handshake process in the cloud, withholding the connection with the targeted server until the TCP handshake is complete."

Two properties do the work. Anycast spreads a single attack across every location announcing the address. The flood is divided among hundreds of machines instead of concentrated on one backlog. Cloudflare's framing is that the mitigation "takes the resource cost of maintaining the connections with the bogus SYN packets off the targeted server and places it on Cloudflare's Anycast network". The edge also defends the handshake with purpose-built stateless machinery rather than a host TCP backlog. That is what the vendor mechanisms below actually are.

The vector's share has fallen, not its relevance. In Cloudflare's 2022 Q2 report, "53% of all network-layer attacks were SYN floods" and they were "the most popular attack vector". By its H1 2026 report, the "attack-vector center of gravity shifted from botnet floods to reflection and amplification", with "DNS-based attacks" at "34.3% of all network-layer activity". A SYN flood is no longer the presumptive vector it was. But it is still one every DDoS service mitigates by default.

What CDNs do

• Cloudflare terminates the handshake at the edge for traffic on proxied (orange-clouded) DNS records. It "automatically detects and mitigates distributed denial-of-service (DDoS) attacks via our autonomous DDoS systems". Its availability table lists "Network-layer (L3/4) DDoS attack protection" on every plan from Free to Enterprise. The deeper SYN-specific system is Advanced TCP Protection, "a stateful TCP inspection engine used to detect and mitigate sophisticated out-of-state TCP attacks such as randomized and spoofed ACK floods or SYN and SYN-ACK floods". Its rules "challenge new connection initiation requests (SYN, SYN-ACK) if they exceed the configured packet-per-second thresholds". It is not a plan upgrade you buy for a website. Cloudflare documents the Advanced DDoS systems for Magic Transit customers, "automatically enabled in Monitor mode with the default thresholds for new Magic Transit customers".
• AWS Shield Standard "is provided automatically and at no extra charge when you use AWS". Its SYN-specific mechanism is a "TCP SYN proxy" that sends "TCP SYN cookies to challenge new connections before allowing them to pass to the protected service". AWS states it "is stateless, which allows it to mitigate the largest known TCP SYN flood attacks without reaching state exhaustion". Read the scope carefully: "TCP SYN proxy is currently available on Amazon CloudFront, Amazon Route 53, and AWS Global Accelerator". Those are the edge and CDN services, not every AWS resource.
• Azure DDoS Protection monitors traffic continuously. It "applies three auto-tuned mitigation policies (TCP SYN, TCP, and UDP) for each public IP of the protected resource, in the virtual network that has DDoS enabled". The plan has to be switched on for that network. This is not baseline behaviour for any public IP. When a threshold is crossed, "DDoS mitigation is initiated automatically", and traffic is redirected. The checks include interacting "with the client to determine if the traffic is potentially a spoofed packet (for example: SYN Auth or SYN Cookie or by dropping a packet for the source to retransmit it)". SYN Auth and SYN Cookie are Microsoft's examples, not an exhaustive list. Microsoft classes SYN floods among protocol attacks, mitigated "by interacting with the client, and blocking malicious traffic".

Watch out for

• A reachable origin makes the CDN irrelevant. If the origin's own IP still answers, the attacker skips the edge. Cloudflare's origin guidance has several parts. Proxy the DNS records. Audit DNS-only records so they "do not contain origin IP information". Avoid hosting mail on the same server. Rotate the origin IPs, "as DNS records are in the public domain" and historical records preserve the old ones.
• An IP allowlist at the origin is not airtight. Cloudflare rates "Explicitly block all traffic that does not come from Cloudflare IP addresses" as only "Moderately secure". It names the reason: "Vulnerable to IP spoofing." A spoofed SYN carrying an edge IP as its source passes a layer-3 allowlist. Certificate-based origin authentication or an outbound-only tunnel is rated "Very secure" instead.
• A real-IP botnet defeats source filtering. RFC 2827 (BCP 38) ingress filtering is deployed by the networks that originate the traffic. "All providers of Internet connectivity are urged to implement filtering described in this document" on their customer links. But ingress filtering "does absolutely nothing to protect against flooding attacks which originate from valid prefixes". It is not something you switch on to protect your own site. RFC 4987 is blunt about depending on it: "end hosts should not rely on filtering policies to prevent attacks from spoofed segments, as global deployment of filters is neither guaranteed nor likely."
• SYN cookies are a trade, not a fix. They "allocate no state at all for connections in SYN-RECEIVED". Instead, they encode that state into the SYN-ACK sequence number. But the sequence number has no room for every TCP option. RFC 4987 is explicit about the bill: "The largest price to be paid for using SYN cookies is in the disabling of the window scaling option, which disables high performance." SACK use is limited too. That is why the RFC concludes they "should not be enabled by default on systems that provide them". Modern Linux splits the difference rather than choosing: tcp(7) documents tcp_syncookies with "default: 1", where 1 means "Send out syncookies when the syn backlog queue of a socket overflows". That means armed, but firing only under pressure. The same page still calls the feature something to use "as a last resort, if at all".
• Enlarging the backlog and shortening the timer are not cures. A bigger backlog does force a bigger barrage. But RFC 4987 found the tactic "has some serious negative aspects as the size of the backlog grows". The implementation it measured "has not been designed to scale past backlogs of a few hundred". And "It is reasonable to assume that other TCP implementations have similar design factors that limit their performance with large backlogs". Cutting the SYN-RECEIVED timer "only requires the attacker to increase the barrage frequency by a linearly proportional amount". It also "can prevent some fraction of legitimate connections from becoming fully established". The RFC's verdict on both: "measurably problematic". Among host-side defenses, only two survive it: "the SYN cache and SYN cookie approaches seem to be the only viable techniques discovered to date".
• State exhaustion and raw volume can arrive together. The classic SYN flood is deliberately small. But nothing stops an attacker sending SYNs at line rate. RFC 4987 puts high packet-rate attacks that "target the network's packet-processing capability and capacity" outside its own scope, "whether or not they happen to use TCP SYN segments as part of the attack". Judge a mitigation on both axes.
• TCP Fast Open raises the stakes. TFO lets application data ride the SYN. RFC 7413 warns the damage is then worse than a plain flood: applications "may waste lots of CPU and memory resources processing the requests and producing the responses". Of the usual defenses, "none are applicable to TFO". The protection is a separate Fast Open cookie plus a cap on pending TFO requests. Past that cap, the server "temporarily disables TFO entirely" so that "regular SYN flood defense techniques" such as SYN cookies can take over.

Best practice

• Terminate TCP and TLS at the CDN edge. Leave the provider's always-on layer-3/4 protection enabled. That combination is the only defense that both absorbs the volume and keeps the half-open state off your machines.
• Make the origin unreachable except through the CDN. Proxy every record. Keep the origin IP out of DNS-only records and off shared mail hosts. Enforce it with certificate-based origin authentication or an outbound-only tunnel rather than an IP allowlist alone.
• On hosts you still run directly, leave tcp_syncookies at its default of 1 so cookies arm on backlog overflow. Set the backlog and SYN-ACK retries deliberately, too. But treat all three as a last line, not as protection.
• Alert on SYN-RECEIVED occupancy, not on bandwidth. A SYN flood can succeed without moving much traffic, so a throughput graph will not show it.
• Do not build the response around blocking source addresses. Spoofing makes a blocklist meaningless. A botnet makes it endless. Let the provider's automatic detection and packet-rate thresholds do that work.