SYN Flood Attack

How SYN Flood Attack Works

Every TCP connection begins with a three-way handshake: the client sends SYN, the server responds with SYN-ACK and allocates a Transmission Control Block (TCB) to track the pending connection, and the client completes with ACK. A SYN flood weaponizes this by sending SYN packets from forged IP addresses at enormous rates — millions per second in modern attacks. The server dutifully allocates a TCB for each one and sends SYN-ACKs to addresses that either don't exist or never initiated the connection. Each TCB consumes memory (typically 280-700 bytes depending on the OS) and persists for 60-75 seconds until timeout. With enough SYN packets, the backlog queue fills entirely, and the kernel silently drops all new connection attempts — including those from real users.

Real-World Examples

Impact & Risk Assessment

SYN floods are uniquely dangerous because they attack the operating system's TCP stack directly, below the application layer, meaning no application-level defense (WAF, rate limiting, authentication) can help once the backlog queue is exhausted. The impact is binary and total: once the queue fills, the server accepts zero new connections on the targeted port. Web servers, databases, mail servers, VPN gateways, and any TCP-based service become completely unreachable. Unlike volumetric attacks that require bandwidth exceeding the target's capacity, SYN floods can deny service with relatively modest bandwidth — a 1 Gbps SYN flood generates enough packets to overwhelm most unprotected servers. Financial impact includes direct revenue loss during downtime, SLA penalties, emergency mitigation costs ($3,000-$50,000+ per incident for scrubbing services), and reputational damage. Critical infrastructure targets (healthcare, banking, government) face regulatory consequences and potential physical safety risks when services become unavailable.

How to Detect SYN Flood Attack

Monitor the ratio of SYN packets to established connections — during normal operation this ratio is close to 1:1, while during a SYN flood it skyrockets as connections fail to complete. Track the number of connections in SYN_RECEIVED state using netstat or ss; a sudden increase from dozens to thousands indicates an active flood. Analyze source IP diversity: legitimate traffic comes from relatively stable IP pools, while SYN floods show thousands of unique source IPs, often from non-routable ranges (RFC 1918), bogon addresses, or geographically impossible distributions. Monitor the backlog queue utilization for each listening socket — approaching maximum capacity is a critical warning. Network flow analysis tools (NetFlow, sFlow, IPFIX) can identify SYN-heavy traffic patterns at the network perimeter before they impact servers. Deploy Intrusion Detection Systems with signatures for SYN flood characteristics: high SYN rate from diverse sources, SYN packets with unusual TCP options or window sizes, and SYN-ACK retransmission spikes indicating unanswered handshakes.

How to Prevent SYN Flood Attack

Enable SYN cookies at the operating system level — this is the most effective single mitigation. SYN cookies encode the connection state in the SYN-ACK sequence number rather than allocating a TCB, allowing the server to validate returning ACKs without maintaining state for half-open connections. Increase the TCP backlog queue size (net.ipv4.tcp_max_syn_backlog on Linux) and reduce the SYN-RECEIVED timeout (net.ipv4.tcp_synack_retries) to expire half-open connections faster. Deploy a reverse proxy or load balancer that terminates TCP connections on behalf of backend servers — the proxy absorbs the SYN flood while backends remain protected. Implement BCP 38 (RFC 2827) source address validation at the network edge to prevent IP spoofing from your network and advocate for its adoption by upstream providers. For high-value targets, deploy dedicated DDoS protection services (cloud-based scrubbing centers) that can absorb SYN floods of any size before traffic reaches your infrastructure. Configure firewalls with SYN rate limiting per source IP and enable TCP SYN proxy mode where available.

Code Examples

# Enable SYN cookies — the most important single defense
# Activates automatically when backlog queue fills
sysctl -w net.ipv4.tcp_syncookies=1

# Increase the SYN backlog queue (default is often 128-256)
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# Reduce SYN-ACK retransmissions (default 5 → ~180s; reduce to 2 → ~15s)
# Half-open connections expire faster, freeing backlog slots
sysctl -w net.ipv4.tcp_synack_retries=2

# Increase the system-wide connection tracking table
sysctl -w net.netfilter.nf_conntrack_max=1000000

# Enable TCP timestamps (required for SYN cookie MSS encoding)
sysctl -w net.ipv4.tcp_timestamps=1

# Increase the listen() backlog maximum
sysctl -w net.core.somaxconn=65535

# Rate-limit incoming SYN packets per source with iptables
# Allow 10 new connections/sec per IP, burst of 20
iptables -A INPUT -p tcp --syn -m hashlimit \
  --hashlimit-above 10/sec \
  --hashlimit-burst 20 \
  --hashlimit-mode srcip \
  --hashlimit-name syn_flood \
  -j DROP

# Drop packets from non-routable source IPs (anti-spoofing)
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -s 127.0.0.0/8 ! -i lo -j DROP
iptables -A INPUT -s 10.0.0.0/8 -i eth0 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -i eth0 -j DROP
iptables -A INPUT -s 192.168.0.0/16 -i eth0 -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/4 -j DROP

# Persist across reboots
sysctl -p

import subprocess
import re
import time
import logging

logger = logging.getLogger('syn_flood_monitor')

def get_tcp_state_counts():
    """Parse ss output to count connections by TCP state"""
    result = subprocess.run(
        ['ss', '-tan', 'state', 'all'],
        capture_output=True, text=True
    )
    
    states = {}
    for line in result.stdout.strip().split('\n')[1:]:
        parts = line.split()
        if parts:
            state = parts[0]
            states[state] = states.get(state, 0) + 1
    
    return states

def get_syn_packet_rate(interface='eth0', duration=5):
    """Measure incoming SYN packet rate using tcpdump"""
    result = subprocess.run(
        ['timeout', str(duration), 'tcpdump', '-i', interface,
         '-c', '100000', 'tcp[tcpflags] & tcp-syn != 0',
         '-q', '--immediate-mode'],
        capture_output=True, text=True, timeout=duration + 5
    )
    
    # Count captured SYN packets
    lines = result.stdout.strip().split('\n')
    syn_count = len([l for l in lines if l.strip()])
    return syn_count / duration  # packets per second

def monitor_syn_flood(
    syn_received_threshold=500,
    syn_rate_threshold=1000,
    check_interval=10
):
    """Continuous SYN flood monitoring with alerting"""
    while True:
        states = get_tcp_state_counts()
        syn_received = states.get('SYN-RECV', 0)
        established = states.get('ESTAB', 0)
        
        # Alert 1: High number of half-open connections
        if syn_received > syn_received_threshold:
            logger.critical(
                f'SYN FLOOD INDICATOR: {syn_received} half-open connections '
                f'(threshold: {syn_received_threshold}), '
                f'{established} established'
            )
        
        # Alert 2: Abnormal ratio of half-open to established
        if established > 0:
            ratio = syn_received / established
            if ratio > 0.5:  # Normally < 0.01
                logger.warning(
                    f'Abnormal SYN-RECV/ESTAB ratio: {ratio:.2f} '
                    f'({syn_received}/{established})'
                )
        
        time.sleep(check_interval)

if __name__ == '__main__':
    logging.basicConfig(level=logging.INFO)
    monitor_syn_flood()

# Nginx as reverse proxy absorbs SYN floods for backend servers.
# The OS handles SYN cookies; Nginx only sees completed connections.

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 65535;
    multi_accept on;
    use epoll;
}

http {
    # Timeouts to quickly reclaim resources from slow/dead connections
    keepalive_timeout       15s;
    client_header_timeout   10s;
    client_body_timeout     10s;
    send_timeout            10s;
    reset_timedout_connection on;

    # Limit concurrent connections per IP
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

    # Limit new connection rate per IP
    limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=20r/s;

    server {
        listen 443 ssl http2 backlog=65535;

        # Max 50 concurrent connections per IP
        limit_conn conn_per_ip 50;

        # Max 20 requests/sec per IP, burst 40
        limit_req zone=req_per_ip burst=40 nodelay;

        location / {
            proxy_pass http://backend;
            proxy_buffering on;

            # Backend only receives fully established, legitimate connections
            proxy_connect_timeout 5s;
            proxy_read_timeout    30s;
            proxy_send_timeout    10s;
        }
    }
}

Frequently Asked Questions

Related Attacks