En el primer semestre de 2026, Cloudflare mitigó 23,2 millones de ataques DDoS de capa de red: unos 5.300 cada hora. La cifra impone menos tras el desglose, porque el 96,6 % no llegó a 500 Mbps y nueve de cada diez terminaron en menos de diez minutos. Ese mismo desglose esconde lo importante: 100 Mbps bastan para saturar un servidor sin protección, y un ataque de medio minuto no da tiempo a que nadie descuelgue un teléfono.
Todo lo que sigue se decide antes de ese medio minuto. Protegerse no consiste en evitar el ataque, sino en abaratar sus consecuencias.
¿Qué es un ataque DDoS y por qué el cortafuegos llega tarde?
Un ataque de denegación de servicio distribuido (DDoS) satura un servicio con tráfico lanzado desde miles de orígenes a la vez, normalmente una botnet (una red de equipos comprometidos a las órdenes del atacante) o servidores ajenos mal configurados que amplifican las peticiones. Hay tres familias. Los ataques volumétricos agotan el ancho de banda. Los de protocolo agotan los recursos de equipos intermedios, como balanceadores o cortafuegos. Y los de capa de aplicación ahogan al servidor con peticiones de aspecto legítimo.
La familia volumétrica es la que invalida el instinto de resolverlo en casa. Si tu conexión a Internet es de 1 Gbps y el atacante envía diez, todo lo que hay detrás, cortafuegos incluido, se queda mirando un enlace saturado. La mitigación tiene que ocurrir antes de llegar a ti: en la red del operador o en un servicio de filtrado con más capacidad que el ataque. A eso se refiere la expresión «defensa aguas arriba».
Los datos de 2026 añaden un matiz importante. Los ataques de reflexión y amplificación (los que rebotan peticiones en servidores ajenos para multiplicar su tamaño) ganan terreno. Los basados en DNS supusieron el 34,3 % de la actividad de capa de red del semestre, de acuerdo con el informe semestral de Cloudflare. Y las inundaciones CLDAP, la variante sin conexión de LDAP que abusa de controladores de dominio expuestos por UDP, crecieron un 580 % en un trimestre hasta convertirse en el tercer vector más frecuente.
¿Con qué proveedores hay que contar antes del ataque?
Tres capas, y las tres se negocian en frío, con el servicio todavía en pie. La primera es el operador: hay que saber qué mitigación incluye tu contrato de conectividad, con qué umbrales y en cuánto tiempo. La segunda es un servicio de filtrado de tráfico en la nube, capaz de absorber el volumen que tu enlace no puede. La tercera, para servicios web, es una CDN (red de distribución de contenidos) con cortafuegos de aplicaciones, que aleja el tráfico de tu origen y encaja los ataques de capa de aplicación.
La guía de denegación de servicio del NCSC británico añade una recomendación tan sensata como infrecuente: valorar más de un proveedor para las funciones que no pueden caer.
Queda la decisión entre protección siempre activa y protección bajo demanda. Cloudflare ha documentado un ataque récord por volumen que duró solo 35 segundos: cuando la alerta llega al analista, el ataque ha terminado. La mitigación que se activa llamando a alguien no llega a tiempo; para servicios que no pueden permitirse la caída, tiene que estar siempre encendida y decidir sola.
El DNS merece contrato aparte. Si tu DNS autoritativo cae, la web dejará de resolverse en cuanto expiren las cachés de los resolvedores. Las inundaciones de DNS llegaron a ser el 40 % de los ataques de capa de red en el segundo trimestre del año, así que el proveedor de DNS necesita red anycast (la que reparte el servicio entre decenas de nodos) y protección específica. Los registros, por su parte, necesitan tiempos de vida lo bastante largos para que las cachés sigan respondiendo durante la interrupción.
La parte que solo depende de tu arquitectura
Hay decisiones que ningún proveedor puede tomar por ti. La central es qué se sacrifica primero. Separar los flujos críticos de los prescindibles, servir desde caché lo que no exija sesión y definir un modo mínimo del servicio: eso convierte una parada total en una molestia. La jerarquía se decide en un despacho, con tiempo, y se implementa en la arquitectura; durante el ataque solo se ejecuta.
El segundo frente es la elasticidad. El NCSC recomienda diseñar para escalar con rapidez y absorber lo que el filtrado no retenga, sea con las API de la nube o con capacidad de reserva en el centro de datos. Frente al volumen puro, escalar pierde; su margen está en los ataques de protocolo y aplicación, donde gana minutos.
Y hay una obligación con terceros: que tu infraestructura no sirva de munición contra otros. Un controlador de dominio con el puerto 389/UDP publicado en Internet es exactamente el reflector que alimenta las inundaciones CLDAP. El bastionado de los servicios expuestos, servidores DNS recursivos abiertos incluidos, evita amplificar el ataque de otro.
¿Quién lanza estos ataques y por qué?
En la Unión Europea, el DDoS fue el tipo de incidente dominante del último ejercicio analizado por ENISA: el 77 % de los notificados, con el hacktivismo detrás de la mayoría, aunque solo un 2 % de sus acciones llegó a interrumpir un servicio.
El detonante suele ser geopolítico y la reacción, inmediata: tras la operación militar que Israel y Estados Unidos lanzaron contra Irán a finales de febrero (Epic Fury), los investigadores registraron 149 reivindicaciones hacktivistas de DDoS contra 110 organizaciones en 72 horas, según recoge el informe de Cloudflare. El NCSC británico mantiene un aviso activo por la campaña sostenida de grupos prorrusos contra administraciones locales e infraestructura crítica.
El otro motor es el mercado: la capacidad de ataque se alquila. La operación policial internacional PowerOFF, coordinada por Europol, retiró 53 dominios de DDoS de pago y destapó bases de datos con más de tres millones de cuentas de usuario. Y cuando uno de estos ataques alcanza un servicio del que depende un país, el resultado se parece a lo que atravesó Noruega este verano, según recogió The Record: tres ataques en tres meses contra la pasarela estatal de identidad, el último de más de treinta horas.
¿Cómo se detecta y quién responde?
Un ataque de diez minutos no se gestiona: se encaja. Lo que sí se gestiona son las réplicas, porque un DDoS breve deja retransmisiones TCP, tiempos de espera agotados y degradación en cadena que puede tardar horas en resolverse, como documenta Cloudflare. Detectarlo exige una referencia de cuál es tu tráfico normal, alertas del proveedor de mitigación integradas con las tuyas y un centro de operaciones de seguridad (SOC) que trate la disponibilidad como una señal de seguridad más. En Hard2bit insistimos en ese punto porque es donde más incidentes se alargan: el ataque termina y nadie mira las réplicas.
La respuesta se escribe antes: hacen falta un plan de respuesta a incidentes que cubra el escenario de denegación de servicio, una página de estado alojada fuera de la infraestructura afectada y un acuerdo de respuesta ya firmado, para no negociar tarifas con el servicio caído. La comunicación con usuarios y autoridades arranca en la primera hora. Después viene el ensayo anual: el NCSC recomienda probar las defensas para saber qué volumen y qué tipos de ataque aguantan, en lugar de descubrirlo en producción.
¿Obliga la normativa a algo concreto?
NIS2 considera incidente notificable la perturbación operativa grave de un servicio, sin necesidad de que se pierda un solo dato: los plazos de alerta y notificación corren también cuando lo que cae es la disponibilidad. DORA es más exigente con las entidades financieras y convierte el ensayo en obligación: la resiliencia operativa se demuestra con pruebas periódicas, no se declara por escrito.
Lo que se puede prometer y lo que no
Garantizar que los ataques no llegarán es un compromiso imposible: con 128.000 mitigados al día solo en la red de Cloudflare, la pregunta relevante dejó de ser si llegan. Lo que sí puede prometerse, y medirse, es el resultado: que un DDoS cueste minutos de degradación controlada en lugar de días de servicio caído y semanas de réplicas.
La asimetría de costes es la mejor noticia de esta guía: un contrato de mitigación se revisa en una tarde y un ensayo cabe en una mañana, mientras que a Noruega el tercer asalto de su verano le supuso más de un día de servicios degradados. En Hard2bit hacemos ese trabajo con organizaciones que no pueden permitirse la interrupción, y lo más caro del proceso suele ser descubrir tarde que faltaba una pieza.
Este artículo combina análisis de fuentes públicas (Cloudflare, ENISA, NCSC, Europol) con recomendaciones generales de arquitectura y contratación. Las cifras corresponden a los periodos que indica cada fuente y pueden evolucionar. Ninguna medida debe aplicarse sin evaluarla frente a la arquitectura, los contratos y las obligaciones regulatorias de cada organización; los cambios sobre servicios expuestos, como cerrar puertos o migrar el DNS, deben planificarse y probarse antes de ejecutarse en producción.
