SYN Flood

Security

A DDoS attack that exhausts server resources by sending massive volumes of TCP SYN packets without completing the three-way handshake. Each half-open connection consumes memory until the server can't accept new legitimate connections.

Updated Mar 9, 2026

Full Explanation

A TCP connection starts with the client sending SYN, the server responding SYN-ACK, and the client completing with ACK. A SYN flood sends millions of SYN packets with spoofed source IPs. The server allocates resources for each half-open connection and waits for ACKs that never come. Eventually, the connection table fills up and legitimate users can't connect.

CDNs are a natural defense against SYN floods because they absorb the attack at the edge. The attacker has to overwhelm the CDN's massive distributed infrastructure rather than your single origin server. CDN edge nodes handle TCP termination, so SYN floods never reach the origin.

At the network level, SYN cookies are the standard defense. Instead of storing state for each SYN, the server encodes the connection info in the SYN-ACK sequence number. Only when the client completes the handshake does the server allocate resources. This makes SYN floods ineffective because no state is consumed for spoofed connections.

Examples

Linux SYN cookie protection:

# Enable SYN cookies (usually on by default)
sysctl -w net.ipv4.tcp_syncookies=1

# Increase SYN backlog
sysctl -w net.ipv4.tcp_max_syn_backlog=65536

# Reduce SYN-ACK retries (faster timeout for half-open)
sysctl -w net.ipv4.tcp_synack_retries=2

# Make persistent
cat >> /etc/sysctl.conf << EOF
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_synack_retries = 2
EOF

Monitoring SYN flood indicators:

# Count half-open connections
ss -s | grep 'SYN-RECV'
# Or:
netstat -an | grep SYN_RECV | wc -l

# Watch for spikes
watch -n 1 'ss -tn state syn-recv | wc -l'
# Normal: < 100. Under attack: thousands.

Video Explanation

Frequently Asked Questions

A DDoS attack that exhausts server resources by sending massive volumes of TCP SYN packets without completing the three-way handshake. Each half-open connection consumes memory until the server can't accept new legitimate connections.

Linux SYN cookie protection:

# Enable SYN cookies (usually on by default)
sysctl -w net.ipv4.tcp_syncookies=1

# Increase SYN backlog
sysctl -w net.ipv4.tcp_max_syn_backlog=65536

# Reduce SYN-ACK retries (faster timeout for half-open)
sysctl -w net.ipv4.tcp_synack_retries=2

# Make persistent
cat >> /etc/sysctl.conf << EOF
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_synack_retries = 2
EOF

Monitoring SYN flood indicators:

# Count half-open connections
ss -s | grep 'SYN-RECV'
# Or:
netstat -an | grep SYN_RECV | wc -l

# Watch for spikes
watch -n 1 'ss -tn state syn-recv | wc -l'
# Normal: < 100. Under attack: thousands.

Related CDN concepts include:

  • TCP (TCP) — Transmission Control Protocol. The reliable, ordered, connection-oriented transport protocol underneath HTTP/1.1 and HTTP/2. TCP's three-way …