Estrategias de protección contra ataques DDoS para infraestructuras dedicadas

Comprender contra qué te estás defendiendo realmente

Los ataques DDoS no son una amenaza monolítica. La categoría incluye varios vectores de ataque distintos que requieren diferentes estrategias de mitigación:

Los ataques volumétricos inundan tu canal de red con tráfico: inundaciones UDP, inundaciones ICMP, ataques de amplificación mediante DNS o NTP. Se miden en Gbps y Mpps (millones de paquetes por segundo). Un ataque volumétrico de 100 Gbps contra un servidor con una conectividad de 10 Gbps simplemente llena el canal, independientemente de la calidad del firewall a nivel de servidor. La mitigación requiere un filtrado ascendente antes de que el tráfico llegue a tu centro de datos.

Los ataques de protocolo aprovechan las debilidades del TCP/IP, siendo los más comunes los ataques SYN flood. Estos agotan la capacidad de la tabla de conexiones de tu servidor en lugar del ancho de banda. Un ataque SYN flood sostenido puede derribar un servidor sin saturar en absoluto el enlace de red.

Los ataques de capa 7 (aplicación) se dirigen específicamente a tu aplicación. Los ataques lentos y de baja intensidad, como Slowloris, mantienen las conexiones abiertas indefinidamente, agotando los límites de conexión sin generar un volumen de tráfico significativo. Las inundaciones HTTP envían solicitudes de aspecto legítimo a puntos finales de aplicaciones costosos: páginas con gran volumen de bases de datos, descargas de archivos de gran tamaño, funciones de búsqueda.

Según el Informe sobre amenazas DDoS 2024 Cloudflare, los ataques DDoS HTTP aumentaron considerablemente de un año a otro, y los ataques a la capa de aplicación representan ahora una proporción significativa del total de incidentes DDoS. Los ataques volumétricos siguen produciéndose, pero los atacantes sofisticados se centran cada vez más en la capa de aplicación, precisamente porque el filtrado volumétrico básico no los detiene.

Capa 1: Mitigación aguas arriba (centros de depuración)

En el caso de los ataques volumétricos, ninguna configuración del lado del servidor servirá de ayuda si tu conexión de 10 Gbps ya está saturada con 40 Gbps de tráfico de ataque. La mitigación debe producirse aguas arriba, antes de que el tráfico llegue a tu servidor.

Magic TransitCloudflare y AWS Shield Advanced proporcionan servicios de depuración ascendentes que filtran el tráfico antes de que llegue a tu centro de datos. La capacidad de red Cloudflaresupera los 250 Tbps, lo que significa que pueden absorber ataques volumétricos que saturarían la capacidad de tránsito de cualquier centro de datos individual. Magic Transit anuncia tus prefijos IP a través de BGP y enruta todo el tráfico a través de la infraestructura de depuración Cloudflare, pasando solo el tráfico limpio a tu servidor.

Esta capa no es opcional para infraestructuras que necesitan una disponibilidad garantizada durante ataques volumétricos. Las técnicas del lado del servidor que se describen a continuación abordan los ataques de capa 7 y de protocolo, pero no resuelven el agotamiento del ancho de banda.

La red de servidores dedicadosInMotion Hosting proporciona mitigación DDoS básica a nivel del centro de datos. Para entornos con amenazas de mayor volumen, la incorporación de un servicio CDN o de depuración delante de tu infraestructura InMotion añade la capacidad ascendente necesaria para absorber ataques de gran envergadura.

Capa 2: Limitación de velocidad en el servidor web

Tanto Nginx Apache admiten la limitación de la velocidad de conexión, lo que detiene las inundaciones de capa 7 antes de que consuman los recursos del servidor de aplicaciones.

Configuración de limitación Nginx :

# Define una zona que rastree las solicitudes por dirección IP.

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/m;

servidor {

    ubicación /api/ {

        limit_req zone=api_limit burst=10 nodelay;

        limit_req_status 429;

    }

}

Esta configuración limita cada IP única a 30 solicitudes por minuto contra los puntos finales /api/, con un límite de ráfaga de 10 solicitudes antes de que se active la limitación de velocidad. La documentación sobre limitación de velocidadNginx cubre el conjunto completo de parámetros. Establece las velocidades en función del comportamiento legítimo de los usuarios: un usuario autenticado que envía un formulario no debería activar un límite, pero un script automatizado que accede a un punto final 500 veces por minuto sí debería hacerlo.

Direcciones que limitan las conexiones Ataques de tipo Slowloris:

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

servidor {

    limit_conn conn_limit 20;

    tiempo_de_espera_del_cuerpo_del_cliente 10 s;

    tiempo_de_espera_del_encabezado_del_cliente 10 s;

    tiempo_de_espera_de_envío 10 s;

}

Los valores de tiempo de espera son fundamentales. Slowloris funciona enviando encabezados HTTP muy lentamente, manteniendo las conexiones abiertas. Los tiempos de espera cortos interrumpen estas conexiones antes de que se acumulen.

Capa 3: Reglas de firewall para la mitigación de ataques de protocolo

La protección contra inundaciones SYN comienza con la configuración a nivel del núcleo en Linux:

# Habilita las cookies SYN para gestionar las inundaciones SYN sin agotar las tablas de conexión.

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Reducir el número de veces que se retransmite un SYN-ACK antes de que el núcleo interrumpa la conexión.

echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

# Reducir la duración del estado TIME_WAIT para reciclar las conexiones más rápidamente.

echo «1 4 2 6 10 15 25 26» > /proc/sys/net/ipv4/tcp_retries2

# Hacer permanente

sysctl -p

Para la mitigación a nivel de firewall, nftables (que sustituye a iptables en las distribuciones Linux modernas) proporciona un filtrado de paquetes eficiente con una sobrecarga mínima de la CPU:

# Bloquear paquetes TCP no válidos (habituales en los ataques SYN flood).

nft añadir regla inet filtro entrada tcp indicadores «& (fin|syn|rst|psh|ack|urg) == fin|psh|urg» descartar

# Limitar la velocidad de las nuevas conexiones

nft añadir regla inet filtro entrada ct estado nuevo límite tasa 100/segundo aceptar

nft añadir regla inet filtro entrada ct estado nuevo descartar

Fail2Ban automatiza el bloqueo de IP basándose en patrones de registro, lo que resulta útil para intentos de autenticación fallidos repetidos o solicitudes continuadas desde IP únicas que eluden los limitadores de velocidad. Fail2Ban lee tus registros Nginx, Apache o SSH y añade reglas iptables/nftables automáticamente cuando se superan los umbrales.

Capa 4: Reputación IP y filtrado geográfico

El filtrado por reputación de IP bloquea las IP maliciosas conocidas antes de que lleguen a tu aplicación. Servicios como AbuseIPDB mantienen bases de datos de IP con historial de abuso confirmado. La integración de estas listas de bloqueo en tu firewall o WAF elimina el tráfico de IP que ya se sabe que participan en ataques.

El filtrado geográfico es una decisión más difícil. Bloquear países enteros puede parecer atractivo durante un ataque, pero hay que considerar cuidadosamente los daños colaterales. Las direcciones IP residenciales de cualquier país pueden verse comprometidas y utilizarse como nodos de botnets, por lo que el bloqueo geográfico rara vez proporciona una protección eficaz. Para las aplicaciones que realmente no tienen usuarios legítimos en regiones específicas, el filtrado geográfico es una primera capa razonable.

El nivel gratuito Cloudflareofrece filtrado por reputación de IP y bloqueo a nivel de país sin necesidad de configuración del lado del servidor.

Capa 5: Protecciones a nivel de aplicación

Los ataques de capa 7 más específicos afectan deliberadamente a operaciones de aplicaciones costosas. Objetivos comunes:

• Funciones de búsqueda que activan consultas en bases de datos de texto completo.
• Puntos finales de inicio de sesión que requieren comparación de hash bcrypt
• Puntos finales de descarga de archivos grandes
• WordPress y puntos finales de administración si se exponen públicamente

Protege los terminales costosos con:

• Desafíos CAPTCHA a través de Cloudflare o hCaptcha en los flujos de inicio de sesión y registro.
• Claves API o autenticación en cualquier punto final que ejecute consultas de bases de datos.
• FortalecimientoWordPress: desactiva XML-RPC si no es necesario (deniega todo; en Nginx /xmlrpc.php), bloquea el acceso a /wp-admin/ mediante una lista de direcciones IP permitidas si tu equipo se encuentra en una ubicación geográfica constante.

Respuesta ante incidentes: qué hacer cuando se produce un ataque

Si actualmente estás siendo atacado, prioridades en orden:

1. Identifica el tipo de ataque: comprueba netstat -an | grep SYN_RECV | wc -l para detectar inundaciones SYN; comprueba los registros Nginx para detectar patrones de inundación HTTP; comprueba iftop para detectar ataques volumétricos.
2. Habilita Cloudflare un proxy equivalente inmediatamente: redirige el tráfico a través de un servicio de depuración si aún no está configurado. Esta es la forma más rápida de mitigar el volumen.
3. Temporary IP blocks for obvious attack sources: nft add rule inet filter input ip saddr <attack_ip> drop
4. Ponte en contacto con el servicio de asistencia de InMotion: el equipo de APS puede ayudar con el análisis del tráfico y coordinarse con el centro de operaciones de red para el filtrado ascendente.

Los equipos con el tiempo medio de recuperación más bajo tras sufrir un ataque DDoS son los que han probado su plan de respuesta antes de sufrir un ataque.