Qué es un ataque DDoS: tipos, capas y mitigación

Un ataque DDoS (Distributed Denial of Service) es un intento de dejar un servicio inaccesible saturándolo con tráfico o peticiones enviadas de forma coordinada desde miles de orígenes distintos. El objetivo no es robar datos ni ganar acceso, sino agotar un recurso finito: ancho de banda, tabla de conexiones, CPU o hilos del servidor de aplicación. Cuando ese recurso se agota, los usuarios legítimos dejan de conectarse y el servicio cae. Esta guía es la referencia canónica de DDoS del cluster defensivo: define el ataque, lo clasifica por capa OSI, explica los vectores de amplificación y cierra con un stack de mitigación y un playbook de respuesta.

DDoS frente a DoS: cuál es la diferencia

La distinción es cuestión de escala y origen. Un ataque DoS (Denial of Service) procede de una única máquina o conexión. Es más fácil de detectar y de bloquear: basta con filtrar la IP de origen o aplicar un límite de tasa sobre ella. Un ataque DDoS (Distributed Denial of Service) procede de cientos, miles o millones de orígenes simultáneos, habitualmente máquinas comprometidas dentro de una botnet. Esa distribución es precisamente lo que lo hace difícil de mitigar: no hay una sola IP que bloquear, el tráfico llega desde ASNs y países diversos, y buena parte de él viene con la dirección de origen falsificada.

En la práctica, cualquier defensa moderna asume DDoS. El reto real es separar millones de peticiones maliciosas de las legítimas cuando ambas parecen tráfico de usuario normal.

Taxonomía por capa OSI

La forma más útil de clasificar un ataque DDoS es por la capa del modelo OSI que satura. Cada categoría se mide con una unidad distinta y se mitiga con controles distintos.

Volumétricos (capa 3 y 4)

Buscan agotar el ancho de banda del enlace. Se miden en bits por segundo (bps) y llegan al rango de los terabits en los casos grandes. Los vectores típicos son el UDP flood (envío masivo de datagramas UDP a puertos aleatorios, forzando al host a responder con ICMP port unreachable) y el ICMP flood o ping flood. Como UDP no tiene handshake, es trivial generar volumen y falsificar el origen.

De protocolo (capa 4)

No buscan saturar el ancho de banda sino agotar tablas de estado en servidores, firewalls y balanceadores. Se miden en paquetes por segundo (pps). El caso paradigmático es el SYN flood: el atacante envía una avalancha de segmentos TCP SYN con origen falsificado, el servidor reserva memoria para cada conexión medio abierta (half-open) y responde con SYN-ACK a una dirección que nunca completa el handshake. La tabla de conexiones se llena y el servidor rechaza conexiones legítimas. Variantes relacionadas: ACK flood, RST flood y fragmentación TCP/UDP.

De aplicación (capa 7)

Los más peligrosos y difíciles de filtrar, porque cada petición es sintácticamente válida y de bajo volumen. Se miden en peticiones por segundo (rps). El HTTP flood lanza oleadas de GET o POST contra endpoints costosos (búsquedas, logins, generación de PDF) para agotar CPU y conexiones a base de datos con un caudal de tráfico ridículo. Slowloris va al extremo opuesto: abre muchas conexiones y las mantiene vivas enviando cabeceras HTTP parciales muy despacio, sin cerrarlas nunca, hasta agotar el pool de conexiones del servidor con apenas unos kilobits por segundo. En 2023, la técnica HTTP/2 Rapid Reset (CVE-2023-44487) permitió récords de más de 398 millones de rps abriendo y cancelando flujos HTTP/2 de forma inmediata.

Amplificación y reflexión

Los ataques volumétricos más grandes de la historia no vienen directamente de la botnet, sino de rebotar tráfico en servidores mal configurados de terceros. El mecanismo es la reflexión con amplificación: el atacante envía una petición pequeña a un servicio UDP público con la dirección de origen falsificada (la de la víctima), y el servicio responde con un paquete mucho mayor dirigido a la víctima. La falsificación del origen es posible porque muchas redes no filtran la salida (ver qué es el spoofing).

El factor de amplificación es la clave. Los vectores más explotados:

• DNS (puerto 53): resolvers abiertos que responden consultas ANY. Factor de 28x a 54x.
• NTP (puerto 123): el comando monlist (CVE-2013-5211) devuelve las últimas direcciones atendidas. Factor de hasta 556x.
• memcached (puerto 11211): expuesto sin autenticación por UDP. Factor de hasta 51.000x. Fue el vector del ataque de 1,35 Tbps contra GitHub en febrero de 2018 (Memcrashed).
• CLDAP (puerto 389): factor de 56x a 70x. AWS Shield mitigó por esta vía un ataque de 2,3 Tbps en febrero de 2020.
• SSDP (puerto 1900) y Chargen (puerto 19): factores menores pero abundantes en dispositivos domésticos.

La mitigación de origen consiste en cerrar estos servicios a Internet o desactivar las funciones abusables (deshabilitar monlist, no exponer memcached por UDP, cerrar resolvers recursivos). A nivel de red, el filtrado de salida BCP38 (RFC 2827) impediría la falsificación del origen que sostiene toda la reflexión.

Botnets y servicios booter/stresser

El origen de la mayoría de ataques distribuidos es una botnet: routers SOHO, cámaras IP y dispositivos IoT comprometidos con credenciales por defecto. Mirai demostró el modelo en 2016 con picos de aproximadamente 1,2 Tbps contra Dyn DNS, que tumbaron Twitter, Spotify y GitHub. El parque de dispositivos vulnerables no ha dejado de crecer, y con él la superficie de reclutamiento (ver ciberseguridad IoT/OT).

Ese poder de fuego se alquila. Los servicios booter o stresser se anuncian con apariencia legítima ("herramientas de test de estrés") pero venden ataques bajo demanda por horas contra cualquier objetivo, por importes tan bajos como decenas de euros. Han democratizado el DDoS hasta el punto de que hoy no hace falta capacidad técnica para lanzar uno. Las operaciones policiales internacionales (como Operation PowerOFF) desmantelan estas plataformas de forma recurrente, pero reaparecen con nuevos dominios.

Stack de mitigación

Ninguna capa por sí sola detiene un DDoS moderno. La defensa efectiva se organiza en capas complementarias, de la red al servidor de aplicación.

Rate limiting y ACLs. Límites de tasa por IP, sesión o token, y listas de control de acceso que descartan protocolos y puertos no usados. Primera línea, útil contra picos moderados e insuficiente por sí sola contra volumen distribuido.

SYN cookies y hardening de protocolo. Contra SYN floods, activar SYN cookies evita reservar estado hasta que el handshake se completa. Contra Slowloris, un proxy inverso que bufferiza la petición completa antes de pasarla al backend (nginx, o mod_reqtimeout en Apache) y timeouts agresivos de conexión.

Scrubbing y Anycast. Ante volumen que supera la capacidad del enlace, el tráfico se redirige (vía BGP o cambio de DNS) hacia centros de limpieza distribuidos que absorben y filtran el ataque, devolviendo solo tráfico limpio por túnel GRE. La arquitectura Anycast anuncia la misma IP desde decenas de puntos de presencia, repartiendo un ataque volumétrico entre toda la red en lugar de concentrarlo en un único data center.

Servicios gestionados de scrubbing. AWS Shield (Standard y Advanced), Cloudflare Magic Transit, Akamai Prolexic, Google Cloud Armor, Azure DDoS Protection e Imperva ofrecen capacidad de mitigación de terabits que ninguna organización individual puede sostener por su cuenta.

WAF para capa 7. Los ataques de aplicación pasan indistinguibles por la red y solo se filtran entendiendo la petición HTTP: firmas, reputación de IP, challenges JavaScript, CAPTCHA adaptativo y análisis de comportamiento. Es la función de un Web Application Firewall, imprescindible contra HTTP flood, Slowloris y Rapid Reset.

Detección y respuesta. Un IDS y la telemetría de flujos (NetFlow, sFlow) frente a una línea base de tráfico permiten detectar la anomalía en segundos, condición previa para activar cualquier mitigación a tiempo.

Playbook de respuesta a incidentes

Alineado con NIST SP 800-61, la respuesta a un DDoS sigue un guion:

1. Preparación. Línea base de tráfico documentada, umbrales de alerta, contactos del ISP y del proveedor de scrubbing, y runbook probado antes del incidente.
2. Detección y clasificación. Confirmar que es DDoS (no un pico legítimo), identificar la capa (bps, pps o rps) y el vector.
3. Mitigación. Activar el filtrado adecuado a la capa: scrubbing y Anycast para volumétrico, SYN cookies y ACLs para protocolo, WAF y challenges para capa 7. Como último recurso ante saturación total, RTBH (Remote Triggered Black Hole, RFC 5635) coordinado con el upstream.
4. Comunicación. Notificar al ISP y al proveedor. En España, coordinación con INCIBE-CERT o CCN-CERT según el sector, y bajo NIS2 el aviso temprano al CSIRT de referencia en 24 horas.
5. Post-incidente. Análisis de la telemetría capturada, ajuste de umbrales y lecciones aprendidas.

Encaje con compliance

La disponibilidad es un requisito regulatorio, no solo operativo:

• NIS2 (artículo 21). Continuidad y gestión de incidentes; el aviso temprano al CSIRT en 24 horas aplica a incidentes significativos de disponibilidad.
• DORA (artículo 11). Resiliencia operativa digital para el sector financiero, con planes de continuidad frente a interrupciones.
• ISO 27001:2022 (controles 5.29, 8.6, 8.20). Continuidad, gestión de capacidad y seguridad de red.
• ENS Real Decreto 311/2022 (medida mp.com.4). Protección frente a la denegación de servicio como control explícito de disponibilidad.

Preguntas frecuentes

¿Qué es DDoS en pocas palabras?

DDoS son las siglas de Distributed Denial of Service, denegación de servicio distribuida. Es un ataque que satura un servicio online con tráfico o peticiones enviadas simultáneamente desde muchos orígenes para dejarlo inaccesible a los usuarios legítimos. No busca robar información, sino tirar el servicio.

¿Cuál es la diferencia entre DoS y DDoS?

Un DoS procede de una sola máquina y se bloquea filtrando su IP. Un DDoS procede de miles de orígenes distribuidos, normalmente una botnet, y con frecuencia con la dirección de origen falsificada, lo que impide bloquear un único punto y obliga a mitigar por volumen y por comportamiento.

¿Cuánto puede durar un ataque DDoS?

Desde ráfagas de pocos minutos (hit-and-run, pensadas para eludir la activación de defensas) hasta campañas de días con oleadas intermitentes. Depende del objetivo del atacante y del coste de sostener el ataque.

¿Un firewall tradicional detiene un DDoS?

No por sí solo. Un firewall de estado puede incluso ser la víctima cuando su tabla de conexiones se agota con un SYN flood. La mitigación efectiva combina scrubbing en red, Anycast, WAF de capa 7 y límites de tasa, no una única regla de firewall.

¿Se puede prevenir por completo un DDoS?

No se puede impedir que alguien lo intente, pero sí reducir el impacto casi a cero con arquitectura preparada: proveedor de scrubbing dimensionado, Anycast, WAF, runbook de respuesta y capacidad de reserva. El objetivo realista es mantener la disponibilidad durante el ataque.

Recursos relacionados

• Qué es una botnet: la infraestructura que origina la mayoría de ataques distribuidos.
• Qué es un WAF: control clave frente a DDoS de capa 7.
• Qué es el spoofing: la falsificación de origen que hace posible la reflexión y la amplificación.
• Qué es un IDS: detección temprana de la anomalía de tráfico.
• Ciberseguridad IoT/OT: los dispositivos que hoy nutren las botnets de DDoS.

Defensa frente a DDoS en Secra

En Secra ayudamos a validar la resiliencia frente a DDoS en tres frentes: revisión de la arquitectura de mitigación (scrubbing, Anycast, WAF y límites de tasa), endurecimiento de servicios expuestos que podrían actuar como reflectores de amplificación, y pruebas controladas que miden cuánto tarda tu equipo en detectar y contener una saturación. Si tu organización nunca ha ensayado un incidente de disponibilidad o depende de un servicio crítico sin plan de continuidad frente a denegación de servicio, escríbenos a través de contacto o consulta nuestros servicios gestionados.