Ajuste de parámetros del kernel sysctl para mitigar ataques SYN Flood

Ajuste de parámetros del kernel sysctl para mitigar ataques SYN Flood

Un ataque SYN Flood explota la fase inicial del protocolo TCP para agotar la tabla de conexiones pendientes del servidor. En servidores dedicados es crítico ajustar parámetros del kernel (sysctl) para reducir la superficie de ataque y mantener la disponibilidad. Aquí explico qué parámetros afectan la capacidad de respuesta, valores recomendados, ejemplos prácticos de configuración persistente y cómo validar cambios sin detener servicios.

¿Qué es un SYN Flood y por qué afecta al servidor?

Un SYN Flood envía numerosas solicitudes SYN sin completar el handshake TCP, llenando la cola de conexiones pendientes (SYN_RECV) y evitando que nuevas conexiones legítimas sean atendidas. Para una descripción técnica y antecedentes históricos, consulta la página sobre SYN Flood en Wikipedia. OWASP también resume el vector y sus efectos en aplicaciones en su ficha.

Enfoque: ajustar el kernel con sysctl

El kernel Linux expone parámetros en /proc/sys que se administran con sysctl. Ajustar estos parámetros puede:

  • Permitir más solicitudes pendientes (backlog).
  • Activar mecanismos defensivos como TCP SYN Cookies.
  • Reducir el tiempo de espera y reutilizar sockets en TIME_WAIT.
  • Balancear la tolerancia entre disponibilidad y compatibilidad con clientes detrás de NAT.

Parámetros clave y su explicación

1. net.ipv4.tcp_syncookies

Activar SYN cookies ayuda cuando la cola de SYN_RECV está saturada: el kernel no reserva memoria y responde con cookies en lugar de mantener estado. Es una defensa básica y transparente.

2. net.ipv4.tcp_max_syn_backlog y net.core.somaxconn

tcp_max_syn_backlog controla cuántas solicitudes SYN pendientes puede mantener el kernel; somaxconn limita la cola de listen(2). Aumentarlas permite absorber picos, pero requieren más memoria.

3. net.ipv4.tcp_synack_retries y net.ipv4.tcp_abort_on_overflow

tcp_synack_retries define cuántas veces el servidor reenviará SYN-ACK; reducirlo acelera la limpieza de intentos no confirmados. tcp_abort_on_overflow hace que el kernel responda con RST cuando la cola está llena, liberando recursos rápidamente pero pudiendo producir errores hacia clientes lentos.

4. net.ipv4.tcp_tw_reuse, tcp_tw_recycle y tcp_max_tw_buckets

TIME_WAIT consume entradas; tcp_tw_reuse permite reutilizarlas para nuevas conexiones salientes (útil en servidores con muchas conexiones salientes). Avoid tcp_tw_recycle: puede romper clientes detrás de NAT y está obsoleto en muchos kernels. Ajusta tcp_max_tw_buckets para limitar la memoria consumida por TIME_WAIT.

5. net.ipv4.ip_local_port_range

Ajustar el rango de puertos efímeros amplía la cantidad de conexiones salientes posibles.

6. net.core.netdev_max_backlog y net.core.somaxconn

Controlan la cola de paquetes recibidos por la interfaz y la cola de pendientes de listen(2) a nivel de kernel; esenciales para servidores de alta concurrencia y mitigación de picos.

7. net.netfilter.nf_conntrack_max (si aplica)

Si usas conntrack (firewall estatal), su tabla también puede saturarse con SYN Floods. Aumentar nf_conntrack_max o implementar reglas de descarte temprano puede ser necesario.

Ejemplo de configuración persistente (archivo sysctl)

Crea un archivo seguro como /etc/sysctl.d/99-syn-flood.conf con este bloque de configuración. Ajusta valores según recursos y carga del servidor.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.core.somaxconn = 1024
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_abort_on_overflow = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_tw_reuse = 1
# net.ipv4.tcp_tw_recycle = 0  (evitar)
net.ipv4.ip_local_port_range = 1024 65535
# Si usas conntrack:
# net.netfilter.nf_conntrack_max = 131072

Aplica inmediatamente con:

sudo sysctl -p /etc/sysctl.d/99-syn-flood.conf
# o para pruebas puntuales
sudo sysctl -w net.ipv4.tcp_syncookies=1

Valores recomendados y criterios

No existe una única talla para todos. Heurística práctica:

  • Servidores pequeños (1 CPU, 1–2 GB RAM): tcp_max_syn_backlog=512–1024, somaxconn=512.
  • Servidores medianos (2–4 CPU, 4–8 GB RAM): tcp_max_syn_backlog=1024–2048, somaxconn=1024.
  • Servidores de alto tráfico: somaxconn=2048–4096, netdev_max_backlog=10000+, ajustar según pruebas de carga.

Recuerda que aumentar backlog sin memoria suficiente puede provocar out-of-memory en situaciones extremas.

Pruebas y monitorización después del ajuste

Monitorea el impacto y busca señales de mejora o efectos adversos:

  • Ver conexiones en estado SYN_RECV: ss -tn state syn-recv o netstat -ant | grep SYN_RECV.
  • Resumen de sockets: ss -s.
  • Contador de conexiones por IP (útil para detectar atacantes): ss -n src :80 o herramientas tipo conntrack -L | wc -l si usas conntrack.
  • Registros del sistema: journalctl -k y logs del firewall para paquetes descartados.

Consideraciones operativas y riesgos

Los ajustes del kernel afectan a todo el sistema:

  • tcp_syncookies ayuda pero puede degradar características TCP opcionales y afectar rendimiento bajo cargas legítimas inusuales.
  • tcp_tw_reuse puede ser útil, pero tcp_tw_recycle debe evitarse por problemas con NAT y dispositivos móviles.
  • Modificar retransmisiones (tcp_synack_retries) puede hacer que clientes lentos o redes con perdidas pierdan conexiones legítimas.
  • Aumentar tablas (nf_conntrack, backlog) incrementa consumo de memoria; monitoriza uso de RAM y límites del kernel.

Complementos técnicos: firewall y proxys

Los ajustes sysctl son efectivos, pero en ataques grandes conviene combinar con medidas en capa de red:

  • Uso de reglas de firewall para drop/limit por IP o emplear SYNPROXY (iptables/nftables) para completar handshake antes de pasar la conexión al stack del kernel.
  • Servicios de mitigación en el borde (CDN/DDoS protection) como explican las prácticas de mitigación de Cloudflare.
  • Rate limiting en el L7 (Nginx/HAProxy) para bloquear patrones maliciosos una vez que lleguen a la aplicación.

Procedimiento recomendado paso a paso

  • 1) Audita estado actual: ss -s, top, free, conntrack -L.
  • 2) Activa tcp_syncookies temporalmente: sysctl -w net.ipv4.tcp_syncookies=1.
  • 3) Incrementa tcp_max_syn_backlog y somaxconn en pequeños intervalos y monitoriza.
  • 4) Ajusta tiempos (tcp_synack_retries, tcp_fin_timeout) si hay congestión sostenida.
  • 5) Implementa reglas firewall y/o SYNPROXY si el ataque persiste.
  • 6) Hacer persistente con /etc/sysctl.d/99-syn-flood.conf y documentar cambios.

Conclusión

Mitigar un SYN Flood en servidores dedicados requiere equilibrio: sysctl permite respuestas rápidas desde el kernel, pero no sustituye una estrategia completa de mitigación de DDoS. Activa TCP SYN Cookies, aumenta con prudencia el backlog, evita parámetros obsoletos como tcp_tw_recycle, y combina ajustes con firewall, SYNPROXY o mitigación en el borde para proteger la disponibilidad. Monitoriza continuamente y valida cada cambio en un entorno controlado antes de aplicarlo en producción. Para contextos operativos y mejores prácticas sobre gestión de incidentes relacionados, revisa documentación técnica de respuesta a incidentes y mitigación.

Lecturas recomendadas: documentación de mitigación de Cloudflare, referencia técnica sobre SYN Flood en Wikipedia y la ficha de OWASP sobre el ataque en OWASP.

Tags: