Cómo detener ataques DDoS: guía práctica

Cómo detener los ataques DDoS

Nadie puede impedir que otro envíe una avalancha de tráfico, así que detener un ataque DDoS significa mantener tu servicio disponible mientras ocurre. Para eso hacen falta cuatro cosas: filtrar el tráfico malo antes de que llegue a tus servidores, absorber lo que pase, reducir lo que un atacante puede alcanzar y decidir de antemano quién actúa cuando salta una alerta. En la práctica, casi todo se ejecuta en el borde de la red y no en el servidor de origen.

Un ataque de denegación de servicio distribuido (DDoS) usa muchas máquinas, a menudo una botnet de dispositivos secuestrados, para saturar un objetivo y que los usuarios legítimos no puedan entrar. Consulta qué es un ataque DDoS para lo básico.

Primero, identifica el tipo de ataque

La defensa adecuada depende de la capa atacada:

• Ataques volumétricos y de reflexión (capas 3 y 4) intentan llenar tu ancho de banda, por ejemplo con reflexión UDP. Solo ayuda tener más capacidad que el ataque, es decir, una red de borde o un servicio de limpieza de tráfico.
• Ataques de protocolo (capa 4) agotan el estado de las conexiones; el caso clásico es la inundación SYN.
• Ataques a la capa de aplicación (capa 7) envían peticiones que parecen legítimas, como una inundación HTTP contra un buscador o un inicio de sesión. Necesitan poco ancho de banda y cuesta distinguirlos de un pico de tráfico. Más en ataques DDoS a la capa de aplicación.

Qué conviene tener montado

• Poner una red de borde delante del origen. Una CDN o un servicio de borde en la nube con protección DDoS integrada absorbe el tráfico volumétrico cerca de su origen. AWS describe este montaje, CloudFront con Shield y WAF, en su documento técnico sobre resiliencia frente a DDoS.
• Añadir un firewall de aplicaciones web con reglas basadas en tasa. Bloquea patrones malos conocidos y limita las peticiones por cliente, idealmente por IP y por sesión. Recuerda que una oficina o un operador móvil pueden compartir una sola IP, así que fija los límites a partir del uso real.
• Reducir la superficie de ataque. Mantén privada la dirección del origen y accesible solo desde tu proveedor de borde, cierra los puertos que no uses y pon límites más estrictos a los endpoints costosos (búsqueda, login, exportaciones).
• Cachear todo lo posible. Cada petición que se responde en el borde es una que el origen nunca ve, lo que amortigua las inundaciones de capa 7 sobre páginas cacheables.
• Tratar las inundaciones SYN en la pila. Las SYN cookies permiten al servidor no guardar estado de las conexiones a medio abrir, a costa de la compatibilidad con algunas opciones TCP. La RFC 4987 describe las SYN cookies, el filtrado y las demás contramedidas con sus contrapartidas.
• Escalar y alertar. El autoescalado da tiempo frente al tráfico de capa de aplicación, pero también escala tu factura, así que combínalo con alertas y límites.
• Redactar un plan de respuesta. Decide quién confirma un ataque, quién contacta con tu CDN, DNS o proveedor de acceso y quién comunica a los clientes. El consejo de CISA es el mismo: tener un plan de comunicación, mitigación y recuperación, y contactar con tu administrador de red y tu ISP para confirmar lo que ves.

Ejemplo: una inundación HTTP en una página de búsqueda

Una tienda ve que su buscador da tiempo de espera agotado. El ancho de banda es normal, pero el origen está al máximo de CPU y el registro de peticiones muestra miles de búsquedas por minuto desde unos cientos de IP. La solución es por capas: servir resultados en caché para búsquedas repetidas, añadir una regla basada en tasa sobre la ruta de búsqueda, desafiar a los clientes que la superen y alertar sobre la tasa de peticiones por ruta para detectar la próxima inundación en minutos.

Errores comunes

• Defender solo en el origen. Un servidor o un enlace se pueden saturar, así que la protección en el borde va primero.
• Hacer null-routing de tu propia IP. Frena la inundación porque deja tu servicio inalcanzable, justo lo que quería el atacante. Solo como último recurso.
• Ignorar la capa 7. La protección a nivel de red no frena peticiones que parecen de usuarios normales.
• No tener una línea base. Sin las tasas normales de peticiones por ruta, no distingues un ataque de unas rebajas o una publicación viral.
• Montar la protección en pleno ataque. Dar de alta un proveedor durante un incidente es lento. Ten contrato, DNS y contactos listos de antemano.

Defensa DDoS, pruebas de carga y monitorización

Una prueba de carga responde a una pregunta distinta de una simulación DDoS. Úsala para saber cuánto tráfico legítimo aguanta tu propio sistema, dónde se degrada primero y si tus límites de tasa y tu autoescalado actúan como esperas. Empieza por load testing vs stress testing (en inglés), y mira causas de la limitación de tasa en APIs (en inglés) para ver cómo aparecen los límites como respuestas 429 en una prueba. Las pruebas de carga de LoadFocus ejecutan tests HTTP contra tu propio sitio o API desde regiones en la nube, lo que sirve para este tipo de comprobaciones de capacidad y límites de tasa.

No apuntes ninguna herramienta de carga a un sistema que no sea tuyo y no trates una prueba de carga como un ejercicio DDoS. Las simulaciones DDoS reales se rigen por las normas de cada proveedor: AWS, por ejemplo, solo las permite a través de socios preaprobados y con límites de volumen fijos, y su política prohíbe generar el tráfico desde un recurso de AWS. Revisa la política de tu CDN y de tu proveedor de nube y avísales antes de cualquier prueba de gran volumen.

Después, sigue vigilando: las comprobaciones sintéticas desde varias regiones y las alertas de tasa de errores y latencia suelen ser la primera señal de un ataque desde fuera.

Preguntas frecuentes sobre cómo detener ataques DDoS

¿Puedo detener yo solo un ataque DDoS?

Solo los pequeños, con límites de tasa y bloqueo de IP. Todo lo que llene tu ancho de banda o agote tu origen necesita una red de borde o un servicio de limpieza con más capacidad que el ataque.

¿Una CDN detiene todos los ataques DDoS?

No. Absorbe la mayoría de los ataques volumétricos y de protocolo en el borde, pero las inundaciones a nivel de aplicación necesitan además reglas WAF, límites de tasa y una caché ajustada a tu tráfico.

¿Cómo sé si sufro un ataque DDoS?

Las señales típicas son un sitio de pronto lento o inalcanzable, un salto en peticiones o errores y tráfico de muchas fuentes a la vez. CISA cita el rendimiento anormalmente lento y los sitios no disponibles como síntomas, y señala que a veces los atacantes usan un ataque como distracción.

¿Basta con limitar la tasa?

Ayuda contra inundaciones pequeñas y clientes abusivos, pero no frena un ataque distribuido desde miles de fuentes ni una inundación volumétrica. Úsalo como una capa más.

¿Debo pagar el rescate?

No. Pagar no garantiza que el ataque pare y te marca como objetivo que paga. Denuncia la exigencia y activa tu plan de mitigación.

¿Puedo probar mi protección DDoS?

Solo dentro de las normas de tu proveedor, normalmente mediante un socio aprobado y con coordinación previa. Para capacidad y límites de tasa, una prueba de carga controlada contra tu propio sistema es la forma más segura de empezar.