Tutorial para mitigar ataques DDoS con CPU optimizado

pexels photo 1010487 5

Tutorial para mitigar ataques DDoS con CPU optimizado

Durante un ataque DDoS reciente contra un proveedor de hosting español, varios servidores con procesadores Intel Xeon de 16 núcleos se saturaron en menos de cuatro minutos porque el kernel no estaba configurado para distribuir las interrupciones de red de forma eficiente.

La optimización de afinidad de CPU y parámetros del scheduler permitió mantener el servicio activo incluso recibiendo más de 800 000 paquetes por segundo. Este tutorial para mitigar ataques DDoS con CPU optimizado explica cómo aplicar esas mismas técnicas en entornos reales sin depender exclusivamente de soluciones externas.

Table
  1. Por qué la CPU se convierte en el primer cuello de botella
    1. Parámetros clave del kernel que afectan la mitigación
  2. Configuración paso a paso de afinidad y aislamiento de CPU
    1. Optimización del driver y RSS
  3. Herramientas de monitorización y ajuste en tiempo real
    1. Comparativa de enfoques de mitigación
  4. Ejemplos reales de configuraciones aplicadas
  5. Limitaciones y consideraciones prácticas
  6. Pasos recomendados para implementar el tutorial para mitigar ataques DDoS con CPU optimizado

Por qué la CPU se convierte en el primer cuello de botella

Los ataques DDoS basados en paquetes pequeños (UDP flood o SYN flood) generan millones de interrupciones por segundo. Cada interrupción obliga al kernel a despertar un núcleo de CPU, copiar datos del buffer de la tarjeta de red y decidir qué hacer con el paquete. Cuando esta carga no se distribuye correctamente, un solo núcleo alcanza el 100 % mientras el resto permanece casi inactivo.

La mayoría de distribuciones Linux modernas usan el driver de la tarjeta de red en modo NAPI, pero la configuración por defecto del irqbalance y del scheduler CFS no siempre es la más adecuada para tráfico malicioso sostenido. Ajustar la afinidad manualmente y desactivar funciones innecesarias del kernel reduce drásticamente el consumo de CPU por paquete.

Parámetros clave del kernel que afectan la mitigación

  • El parámetro net.core.netdev_budget controla cuántos paquetes procesa cada ciclo de NAPI; subirlo a 600 o 800 en servidores con 10 Gbps permite absorber picos sin que se acumulen colas.
  • net.core.netdev_max_backlog define el tamaño de la cola de paquetes antes de que se descarten; valores entre 30000 y 60000 suelen ser efectivos en ataques de 500 kpps.
  • El sysctl kernel.sched_min_granularity_ns y kernel.sched_wakeup_granularity_ns influyen en cómo el scheduler reparte tiempo entre procesos de red y aplicaciones.

Configuración paso a paso de afinidad y aislamiento de CPU

El primer paso consiste en identificar qué núcleos están recibiendo las interrupciones de la tarjeta de red. La herramienta cat /proc/interrupts muestra claramente qué CPU atiende cada IRQ. En la mayoría de servidores con tarjetas Intel o Mellanox, las interrupciones se reparten entre los primeros cuatro núcleos por defecto.

Para aislar núcleos específicos y dedicarlos exclusivamente al procesamiento de red se puede usar el parámetro de arranque isolcpus=4-15 en GRUB. Los núcleos aislados ya no ejecutarán procesos normales del sistema, lo que reduce latencia y jitter durante picos de tráfico.

  1. Edita /etc/default/grub y añade isolcpus=4-15 nohz_full=4-15 a la línea GRUB_CMDLINE_LINUX_DEFAULT.
  2. Ejecuta update-grub y reinicia el servidor.
  3. Verifica con cat /proc/cmdline que los parámetros se aplicaron correctamente.
  4. Usa taskset -c 0-3 para mover servicios importantes (nginx, sshd, systemd) a los núcleos no aislados.

Optimización del driver y RSS

Receive Side Scaling (RSS) permite que la tarjeta de red distribuya los flujos entre varias colas de hardware, cada una asociada a una interrupción distinta. En tarjetas Intel se configura con el módulo ixgbe o i40e. El número de colas debe coincidir con el número de núcleos dedicados al procesamiento de red.

Una configuración habitual en servidores con 16 núcleos es dejar 8 colas RSS y asignarlas a los núcleos 4 a 11 mediante ethtool -X eth0 equal 8 seguido de la afinidad manual de cada IRQ con echo 1 > /proc/irq/XX/smp_affinity_list.

Herramientas de monitorización y ajuste en tiempo real

Durante un ataque es fundamental observar en tiempo real cómo se comporta la CPU. Herramientas como perf top -e cycles y mpstat -P ALL 1 permiten ver qué funciones del kernel están consumiendo más ciclos. En ataques SYN flood suele destacar tcp_v4_rcv y __inet_lookup.

  • htop con árbol de procesos activado muestra rápidamente si algún worker de nginx o del firewall está monopolizando un núcleo.
  • ss -tuln combinado con watch ayuda a detectar si se están acumulando sockets en estado SYN-RECEIVED.
  • ethtool -S eth0 muestra contadores de paquetes descartados por la tarjeta antes de llegar al kernel.

Comparativa de enfoques de mitigación

Método Consumo CPU adicional Latencia introducida Facilidad de despliegue
iptables + conntrack optimizado Medio Baja Alta
XDP en driver Bajo Muy baja Media
BPF + tc filter Bajo Baja Media-Alta
Cloudflare Magic Transit Nulo en origen Variable Baja

Ejemplos reales de configuraciones aplicadas

En un servidor de videojuegos con procesador AMD EPYC 7402 que recibía ataques de 1,2 millones de paquetes UDP por segundo, se aplicó la siguiente configuración: 12 núcleos aislados, 8 colas RSS y un script de XDP que descartaba paquetes con puerto origen 0 o con longitud menor a 40 bytes. El consumo de CPU en los núcleos de red bajó de 94 % a 37 % sostenido.

Otro caso fue un proveedor de streaming español que usaba nginx con 32 workers. Tras mover los workers a núcleos no aislados y fijar las interrupciones de la tarjeta Mellanox ConnectX-5 en los núcleos 0-7, el servidor soportó un ataque SYN de 650 000 paquetes por segundo sin que la latencia de las peticiones HTTP superara los 180 ms.

Un tercer ejemplo corresponde a un clúster de bases de datos PostgreSQL que aplicó irqaffinity y desactivó el conntrack para el tráfico de replicación. Durante un ataque mixto TCP/UDP de 40 minutos, el uso de CPU nunca superó el 61 % en los núcleos dedicados a red.

Limitaciones y consideraciones prácticas

La optimización de CPU no sustituye a un buen filtrado en el borde de red ni a servicios de protección DDoS distribuidos. Cuando el ataque supera la capacidad del enlace de salida (por ejemplo, 10 Gbps saturados), ningún ajuste de CPU en el servidor de destino será suficiente. En esos casos la mitigación debe realizarse antes de que el tráfico llegue al centro de datos.

Tampoco es recomendable aislar todos los núcleos en servidores con menos de 12 núcleos, ya que las aplicaciones pueden quedarse sin recursos suficientes para atender peticiones legítimas una vez que el ataque remite.

Pasos recomendados para implementar el tutorial para mitigar ataques DDoS con CPU optimizado

  1. Realiza una auditoría de interrupciones y tráfico actual con perf y ethtool durante 48 horas en condiciones normales.
  2. Define qué núcleos dedicarás exclusivamente a red y actualiza GRUB con los parámetros de aislamiento.
  3. Configura RSS y afinidad de IRQ según el número de núcleos aislados.
  4. Prueba el entorno con herramientas como hping3 o trafgen antes de exponer el servidor a tráfico real.
  5. Documenta los valores de sysctl y las afinidades para poder replicarlos rápidamente en otros servidores del mismo modelo.

La combinación de aislamiento de CPU, ajuste fino de RSS y monitorización constante permite a muchos equipos técnicos mantener servidores en pie durante ataques que antes los dejaban fuera de servicio en minutos. Cada entorno requiere pruebas específicas, pero los principios de distribución de carga y reducción de interrupciones son aplicables en la mayoría de servidores Linux actuales.

Si quieres conocer otros artículos parecidos a Tutorial para mitigar ataques DDoS con CPU optimizado puedes visitar la categoría Ciberseguridad.

Entradas Relacionadas