Cloudflare informó de la neutralización de la que considera la mayor ataque DDoS observado hasta la fecha, con un pico de 11,5 Tbps y hasta 5,1 mil millones de paquetes por segundo (pps). El incidente, de unos 35 segundos de duración, encaja con campañas hipervolumétricas de tipo “golpe y huida” diseñadas para saturar enlaces y agotar la capacidad de procesamiento de red en capas L3/L4.
DDoS hipervolumétrico: 11,5 Tbps y 5,1 mil millones pps
Según la compañía, el vector principal fue un UDP flood, es decir, un flujo masivo de paquetes sin conexión previa que busca colapsar anchos de banda y dispositivos de transporte. La cota de 5,1 mil millones pps refleja una presión extrema sobre pilas de red y encaminadores, mientras que los 11,5 Tbps evidencian el esfuerzo por saturar la capacidad de los enlaces de datos.
Por qué importan las métricas Tbps y pps
En DDoS, Tbps mide el volumen total que impacta la capacidad de los enlaces y los upstreams; pps mide la intensidad de paquetes que deben procesar routers, firewalls y balanceadores. Un pps elevado estresa CPU, tablas de estado y pipelines de filtrado, incluso si el volumen en bits parece moderado. En este ataque, ambos indicadores alcanzaron niveles extraordinarios.
Origen del tráfico: nubes públicas e IoT como multiplicadores
Cloudflare señaló que el tráfico malicioso se rastreó hasta proveedores cloud y operadores de IoT, entre ellos Google Cloud. Este patrón confirma una tendencia consolidada: los atacantes combinan botnets de dispositivos conectados comprometidos con cuentas e instancias en nubes públicas para escalar capacidad rápidamente y reducir el tiempo de preparación.
Ataques “hit-and-run” y pruebas de resiliencia
Una ventana de ~35 segundos es típica de campañas de hit-and-run: ráfagas cortas a máxima potencia que pueden sobrepasar defensas locales si la víctima no dispone de Anycast global y scrubbing automatizado. Además de la indisponibilidad, estos picos buscan sondear umbrales de SLA y tiempos de reacción de los mecanismos defensivos.
Evolución del riesgo: picos cada vez más altos y frecuentes
El nuevo registro supera los hitos reportados previamente por el sector: 7,3 Tbps en junio de 2025 y 5,6 Tbps en enero de 2025. La brecha entre máximos se acorta mientras la amplitud crece, impulsada por botnets más grandes y el abuso de infraestructuras cloud. Informes públicos de Cloudflare, Akamai y ENISA coinciden en el auge de ataques breves, intensos y distribuidos, con transferencias de decenas de terabytes en cuestión de segundos.
Implicaciones técnicas y medidas de mitigación
La defensa eficaz frente a UDP floods combina arquitectura Anycast para dispersar carga, centros de scrubbing para limpiar tráfico en origen, rate limits adaptativos y telemetría granular para detectar picos de pps/Tbps en segundos. La automatización —detección, anuncio BGP y activación de filtros— es esencial para encajar ventanas tan cortas.
Recomendaciones clave para organizaciones: 1) Acordar con el carrier el desvío hacia scrubbing centers y la preparación de anuncios BGP en contingencia; 2) Implementar BCP 38/uRPF para frenar el spoofing de IP; 3) Restringir o filtrar servicios UDP no necesarios mediante ACL por puertos y protocolos; 4) Contratar SLA específicos de mitigación y reservar capacidad de banda; 5) Instrumentar alertas por umbrales de pps/Tbps que contemplen ráfagas de decenas de segundos.
Para una postura resiliente: colocar servicios críticos tras proxys con Anycast, segmentar por zonas de disponibilidad, realizar DDoS game days y pruebas de dribbling para medir tiempos de detección y conmutación de rutas. En entornos cloud e IoT, los auditorías de cuentas, el endurecimiento de permisos y la filtración de egress reducen el riesgo de que recursos propios se conviertan en nodos de ataque.
Los DDoS hipervolumétricos estrechan el margen de maniobra a segundos. Es momento de revisar runbooks y planes de respuesta, verificar rutas hacia scrubbing, activar monitoreo de pps/Tbps y probar la automatización de mitigación. Anticiparse y distribuir la defensa marca la diferencia entre mantener la disponibilidad y incumplir el SLA.
