SYN Flood Attacks

Every TCP connection begins with a handshake. The client says "I want to connect" (SYN). The server says "OK, I'm ready" (SYN-ACK) and allocates memory, reserves a slot in its connection table, starts a timer. Then the client says "Great, let's go" (ACK), and data flows.

The vulnerability is in step two. The server extends its hand before confirming anyone's there to shake it.

SYN floods fill the room with ghosts.

The Attack

An attacker sends thousands of SYN packets per second to a target server. Each packet carries a forged source IP address—addresses that either don't exist or belong to uninvolved third parties. The server dutifully responds to each one, allocating resources and sending SYN-ACK packets into the void.

The final ACK never comes. The server waits, typically 30 to 120 seconds per half-open connection, holding resources hostage for ghosts. When the connection table fills, the server can't accept new connections. Legitimate users get refused. The service goes dark.

The asymmetry is what makes this devastating. The attacker sends tiny packets requiring almost no resources. The server commits memory and connection slots for each one. A laptop with forged addresses can bring down servers that cost millions—simply by exploiting a protocol designed when the Internet was a trusting place.

Why Spoofing Matters

SYN floods use forged source addresses for three reasons:

Anonymity. The real attacker stays hidden. Every packet claims to come from somewhere else.

Unblockable. You can't filter by IP when every packet has a different source. Block one address, ten thousand more appear.

Guaranteed incompletion. SYN-ACK responses fly to random corners of the Internet, to addresses that never asked for them and won't respond. The handshakes can't complete because there's no one on the other end.

TCP accepts SYN packets without verifying the source can actually receive responses. The server allocates resources on faith. SYN floods weaponize that faith.

The Damage

Connection exhaustion is just the beginning.

Legitimate users can't connect. Browsers timeout. APIs fail. Mobile apps show error screens. Customers leave.

Existing connections degrade. Even users who connected before the attack experience slowdowns as the server struggles under resource pressure.

Retry storms compound the damage. When connections fail, clients retry. Those retries add load to an already overwhelmed server. Automated systems retry aggressively. The attack feeds itself.

Defense overhead consumes resources too. Detection systems, logging, alert generation—all compete for the same strained capacity.

Defenses

SYN cookies change the game entirely. Instead of allocating resources on the initial SYN, the server encodes connection information into the sequence number of its SYN-ACK. Only when the final ACK returns—proving the client can actually receive responses—does the server commit resources.

No half-open connections. No resource exhaustion. Ghosts can knock forever; the server doesn't open the door until someone real answers back.

The tradeoff: SYN cookies lose some TCP options and add slight computational overhead. Most servers accept this happily.

Rate limiting caps new connections per second, globally or per source IP. This prevents floods from consuming all capacity but may throttle legitimate traffic during genuine usage spikes.

Shorter timeouts for half-open connections reduce how long each ghost occupies resources. But too aggressive, and legitimate slow connections get dropped.

Larger connection tables buy time but don't solve the problem. Attackers just send more packets.

Stateful firewalls track TCP state and can proxy handshakes—completing them on behalf of backend servers only after verifying the client is real. Advanced firewalls essentially implement SYN cookie logic externally.

Cloud DDoS protection from services like Cloudflare, Akamai, or AWS Shield absorbs floods through sheer capacity. Their globally distributed infrastructure handles connection establishment, filtering attack traffic before it reaches your servers.

Detection

Catch SYN floods early, before complete denial of service:

• SYN-to-completion ratio dropping sharply (many SYNs, few completed handshakes)
• Half-open connections climbing toward table limits
• Connection failures spiking in logs and monitoring
• Source IP entropy increasing (many connections from random, unrelated addresses)

Monitoring services that track these patterns can alert you while mitigation is still possible.

The Smokescreen

SYN floods sometimes aren't the real attack. While your security team scrambles to mitigate the DDoS, attackers may be quietly exfiltrating data, compromising systems, or probing for vulnerabilities elsewhere.

Don't let the loud attack blind you to quiet ones. Maintain comprehensive monitoring even during incident response.

Why SYN Floods Persist

They're not the dominant DDoS vector anymore, but SYN floods remain common because they're simple to execute, effective against unprepared targets, and useful as components of multi-vector attacks. DDoS-for-hire services include them by default, making the attack accessible to anyone with a grudge and a credit card.

The TCP three-way handshake was designed for a network of researchers who trusted each other. SYN floods exploit that trust. The defenses we've built—SYN cookies, stateful inspection, cloud absorption—are patches on a protocol that assumed good faith.

The assumption was wrong. The Internet grew beyond trust. But TCP remains, and so does this vulnerability in the moment between "I want to connect" and "prove you're real."