How a SYN Flood Attack Works and How to Stop It

That is where a SYN flood attack works. It sends more connection requests than your systems can safely hold, then leaves those requests unfinished.

Key Takeaways

• The target keeps temporary state for unfinished connections, which can fill queues and connection tables.  
• A tcp syn flood may overload a server, firewall, load balancer, or another stateful device before the application sees any request.  
• Effective syn flood protection uses several layers, including edge filtering, SYN proxies, syn cookies, rate controls, and origin restrictions.

How the TCP Three-Way Handshake Creates the Vulnerability SYN Floods Exploit

TCP is a transport protocol used when two systems need a reliable connection. Before application data moves, the client and server complete a three-way handshake.

1. The client sends a SYN packet to ask for a connection.  
2. The server replies with a SYN-ACK packet.  
3. The client sends an ACK packet to confirm the connection.

After the final ACK arrives, the connection becomes established. The client can then send HTTP requests, API calls, or other application data.

The vulnerable point appears after step two. Once the server sends SYN-ACK, it waits for the final ACK and stores information about the pending request. This is called a half-open connection.

The problem begins when new SYN packets arrive faster than old entries expire. The queue that holds pending connections, often called the SYN backlog, begins to fill. A firewall, proxy, or load balancer may also store connection state. If any of these systems reaches its limit, legitimate clients may be delayed or rejected before your application can respond.

How a SYN Flood Attack Works Step by Step

1. The attacker selects a TCP service. The target may be a website on port 443, an API gateway, a mail server, or another public TCP service.  
2. Large numbers of SYN packets arrive. Each packet asks the target to begin a new connection.  
3. The target sends SYN-ACK replies. Your server or edge device treats each SYN as a possible real user and waits for confirmation.  
4. The final ACK never arrives. The attacking system ignores the reply, blocks it, or uses a spoofed address that cannot complete the handshake.  
5. Half-open connections build up. Pending entries consume backlog space, memory, CPU time, and connection-table capacity.  
6. Legitimate users lose access. Their valid SYN packets may be dropped, delayed, or refused because the target has too little room left.

The attack does not always need to fill your internet connection. SYN packets are small, but each one can make the receiver perform work and hold state.

The Different Types of SYN Flood Attacks

A direct SYN flood uses real source addresses. The attacking devices receive the SYN-ACK packets but do not return the final ACK. Blocking can help when the traffic comes from a small number of sources.

A spoofed SYN flood uses false source IP addresses. Your server sends replies to systems that never requested a connection. The apparent sources may change constantly, which makes simple address blocking unreliable.

A distributed SYN flood uses many compromised devices across different networks and regions. The traffic can look more like genuine demand because it is spread across many sources.

A state-table flood focuses on a firewall, NAT device, proxy, or load balancer. Your origin server may have spare capacity while the device in front of it runs out of connection entries. This is why you must monitor the whole delivery path instead of checking only server CPU and memory.

What SYN Flood Traffic Looks Like at the Network Level

The strongest sign is a mismatch between connection starts and completed handshakes. You see a sharp rise in SYN packets, but final ACK packets do not increase at the same rate.

You may also see:

• Many connections staying in the SYN_RECV state  
• Rising packet rates without matching HTTP request growth  
• Full connection tables on firewalls or load balancers  
• Higher connection latency while established sessions still work

Flow records can show where the traffic comes from and how quickly it changes. Firewall and load balancer metrics can show whether a state table is filling before the origin becomes overloaded.

You should not depend on one fixed threshold. A ticket launch or major news event can also create a sudden rise in new connections. Compare current traffic with the normal pattern for that service, region, time of day, and user base.

The most useful alerts often combine several signals. You might watch SYN rate, handshake completion rate, SYN_RECV count, retransmissions, and connection failures together.

How to Stop a SYN Flood Attack: Defenses That Work

• Defense: SYN proxy
  What It Does: Completes the client handshake before opening a connection to the origin
  Main Limitation: The proxy must have enough capacity
• Defense: SYN cookies
  What It Does: Avoid storing normal pending state until the final ACK returns
• ‍
• ‍
  Main Limitation: They do not remove bandwidth or CPU limits
• Defense: Rate controls
  What It Does: Restrict abnormal connection attempts
  Main Limitation: Strict rules may block shared networks
• Defense: Edge filtering
  What It Does: Screens attack traffic before it reaches the origin
  Main Limitation: Direct origin access can bypass it

Start with syn cookies on supported systems. They encode enough connection information into the SYN-ACK sequence number so the server does not need to store normal pending state. If a valid ACK returns, the server reconstructs the connection information. This protects the backlog, but the server still has to receive packets and send replies.

A SYN proxy adds another layer. It completes the handshake with the client before opening a separate connection to the protected server. Half-open requests remain at the proxy instead of reaching the origin.

Use rate controls carefully. Limits based on source address can reduce direct floods, but many legitimate users may share one public address through a carrier or corporate network. Better controls also consider geography, network reputation, port, request pattern, and handshake completion behavior.

Tune the host as well. Review backlog limits, retransmission settings, operating system protections, and connection metrics. A larger backlog may help during short spikes, but it is not a complete defense.

Most importantly, block direct access to the origin when you use a CDN or DDoS protection provider. Allow connections only from approved edge networks or private paths. Otherwise, an attacker can discover the origin IP and send traffic around your protection layer.

Why CDN and Multi-CDN Architecture Reduces SYN Flood Exposure

A CDN places distributed edge servers between users and your origin. Clients connect to the edge instead of opening TCP connections directly to your application server.

The edge can validate handshakes, apply rate controls, and absorb large packet volumes across many locations. Unfinished connections stay away from the origin, which reduces pressure on your server and the devices close to it.

A multi-CDN architecture adds another provider and another delivery path. You can move traffic when one CDN has a regional failure, reaches a service limit, or applies the wrong security policy. This reduces your dependence on one network.

Multi-CDN does not protect you automatically. You still need reliable health checks, fast traffic steering, matching security rules, and enough capacity at each provider. Your origin must accept traffic only from approved CDN networks.

Test the failover process before an incident. Confirm that traffic can move, security controls remain active, and the remaining provider can handle the extra load.

Conclusion

A SYN flood turns TCP’s normal waiting period into a resource problem. You reduce the risk by watching handshake behavior, protecting pending connection state, filtering traffic before it reaches the origin, and limiting direct origin access. A CDN or multi-CDN design adds capacity, distance, and another path when one layer fails.

FAQs

How does a SYN flood differ from a UDP flood?

A SYN flood targets the TCP handshake by creating unfinished connections that consume queues or connection state. A UDP flood sends connectionless packets to consume bandwidth or packet-processing capacity. UDP does not use a three-way handshake, so it does not depend on half-open connections or a SYN backlog.

Can SYN cookies fully prevent a SYN flood attack?

No. SYN cookies protect the pending connection queue by avoiding normal state storage until a valid ACK arrives. They do not remove bandwidth limits, packet-processing costs, firewall capacity limits, or upstream congestion. You still need edge filtering, monitoring, rate controls, and protection for every stateful device in the delivery path.

What SYN flood volume typically causes a service outage?

There is no universal attack volume that always causes an outage. The failure point depends on packet rate, backlog size, CPU capacity, firewall limits, available bandwidth, system settings, and legitimate demand. Measure your own infrastructure and alert on abnormal handshake behavior instead of relying on a fixed public threshold.

Can firewalls stop SYN floods without affecting legitimate traffic?

Firewalls can reduce SYN floods through SYN proxying, connection limits, source reputation, and handshake validation. However, strict rules can block real users, especially when many people share one public IP address. Test controls against normal traffic and monitor rejection rates while you adjust limits during an attack.

Does a CDN protect against SYN flood attacks?

A CDN can terminate TCP connections at distributed edge locations, validate handshakes, and keep half-open connections away from your origin. It offers less protection when the origin remains publicly reachable. Restrict origin access to approved CDN networks and keep a tested backup path for stronger protection during large or regional attacks.

‍

‍