Ataque de Inundación SYN

Cómo Funciona Ataque de Inundación SYN

Cada conexión TCP comienza con un handshake de tres vías: el cliente envía SYN, el servidor responde con SYN-ACK y asigna un Bloque de Control de Transmisión (TCB) para rastrear la conexión pendiente, y el cliente completa con ACK. Una inundación SYN lo convierte en arma enviando paquetes SYN desde direcciones IP falsificadas a velocidades enormes — millones por segundo en ataques modernos. El servidor diligentemente asigna un TCB para cada uno y envía SYN-ACKs a direcciones que no existen o que nunca iniciaron la conexión. Cada TCB consume memoria (típicamente 280-700 bytes dependiendo del sistema operativo) y persiste durante 60-75 segundos hasta que expira. Con suficientes paquetes SYN, la cola de espera se llena completamente y el kernel descarta silenciosamente todos los nuevos intentos de conexión — incluyendo los de usuarios reales.

Ejemplos Reales

Impacto y Evaluación de Riesgo

Las inundaciones SYN son singularmente peligrosas porque atacan la pila TCP del sistema operativo directamente, por debajo de la capa de aplicación, lo que significa que ninguna defensa a nivel de aplicación (WAF, limitación de tasa, autenticación) puede ayudar una vez que la cola de espera se agota. El impacto es binario y total: una vez que la cola se llena, el servidor acepta cero conexiones nuevas en el puerto objetivo. Servidores web, bases de datos, servidores de correo, gateways VPN y cualquier servicio basado en TCP se vuelven completamente inalcanzables. A diferencia de los ataques volumétricos que requieren un ancho de banda que exceda la capacidad del objetivo, las inundaciones SYN pueden denegar el servicio con un ancho de banda relativamente modesto — una inundación SYN de 1 Gbps genera suficientes paquetes para abrumar a la mayoría de los servidores sin protección. El impacto financiero incluye pérdida directa de ingresos durante el tiempo de inactividad, penalidades por SLA, costos de mitigación de emergencia ($3,000-$50,000+ por incidente para servicios de scrubbing) y daño reputacional. Los objetivos de infraestructura crítica (salud, banca, gobierno) enfrentan consecuencias regulatorias y potenciales riesgos de seguridad física cuando los servicios se vuelven inaccesibles.

Cómo Detectar Ataque de Inundación SYN

Monitorear la proporción de paquetes SYN respecto a conexiones establecidas — durante la operación normal esta proporción es cercana a 1:1, mientras que durante una inundación SYN se dispara ya que las conexiones no se completan. Rastrear el número de conexiones en estado SYN_RECEIVED usando netstat o ss; un aumento repentino de docenas a miles indica una inundación activa. Analizar la diversidad de IPs de origen: el tráfico legítimo proviene de conjuntos de IPs relativamente estables, mientras que las inundaciones SYN muestran miles de IPs de origen únicas, frecuentemente de rangos no enrutables (RFC 1918), direcciones bogon o distribuciones geográficamente imposibles. Monitorear la utilización de la cola de espera para cada socket en escucha — acercarse a la capacidad máxima es una advertencia crítica. Las herramientas de análisis de flujo de red (NetFlow, sFlow, IPFIX) pueden identificar patrones de tráfico con predominancia de SYN en el perímetro de red antes de que impacten a los servidores. Desplegar Sistemas de Detección de Intrusiones con firmas para características de inundación SYN: alta tasa de SYN desde fuentes diversas, paquetes SYN con opciones TCP o tamaños de ventana inusuales, y picos de retransmisión de SYN-ACK indicando handshakes sin respuesta.

Cómo Prevenir Ataque de Inundación SYN

Habilitar SYN cookies a nivel de sistema operativo — esta es la mitigación individual más efectiva. Los SYN cookies codifican el estado de conexión en el número de secuencia del SYN-ACK en lugar de asignar un TCB, permitiendo al servidor validar los ACKs de retorno sin mantener estado para conexiones a medio abrir. Aumentar el tamaño de la cola de espera TCP (net.ipv4.tcp_max_syn_backlog en Linux) y reducir el tiempo de expiración de SYN-RECEIVED (net.ipv4.tcp_synack_retries) para expirar las conexiones a medio abrir más rápido. Desplegar un proxy reverso o balanceador de carga que termine las conexiones TCP en nombre de los servidores backend — el proxy absorbe la inundación SYN mientras los backends permanecen protegidos. Implementar BCP 38 (RFC 2827) validación de dirección de origen en el borde de la red para prevenir la falsificación de IP desde tu red y promover su adopción por los proveedores upstream. Para objetivos de alto valor, desplegar servicios dedicados de protección DDoS (centros de scrubbing basados en la nube) que puedan absorber inundaciones SYN de cualquier tamaño antes de que el tráfico alcance tu infraestructura. Configurar firewalls con limitación de tasa de SYN por IP de origen y habilitar el modo proxy SYN de TCP donde esté disponible.

Ejemplos de Código

# 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;
        }
    }
}

Preguntas Frecuentes

Ataques Relacionados