Hay una frase que escuchamos con frecuencia cuando sale el tema DDoS: «tranquilos, tenemos un buen firewall». Y hay un número que la desmonta en seco: en diciembre de 2025, Cloudflare mitigó el mayor ataque DDoS registrado hasta la fecha, 31,4 terabits por segundo. Eso son unas 31.000 veces el caudal de una fibra empresarial de 1 Gbps. No hace falta un récord: un ataque mil veces más pequeño que ese sigue siendo 30 veces tu enlace. El firewall puede ser buenísimo; da igual. Cuando el tráfico del ataque llega a tu firewall, la batalla ya está perdida, porque tu enlace de acceso se llenó unos kilómetros antes. Un DDoS volumétrico no se gana en tu casa: se gana aguas arriba. De eso va este post: de cómo se hace de verdad, con BGP y una técnica que se llama RTBH, y de lo que un operador puede hacer por ti que ninguna caja en tu rack puede.
El mito: «la caja lo para»
El malentendido nace de mezclar dos cosas distintas. Un firewall, un IPS o un anti-DDoS de appliance trabajan en el destino: inspeccionan el tráfico que ya ha llegado hasta ti y deciden qué pasa y qué no. Contra ataques de aplicación —peticiones HTTP maliciosas, abusos de API, floods de capa 7 con poco ancho de banda— eso tiene sentido y funciona. Pero un DDoS volumétrico no intenta colarse por tu puerta: intenta llenar la calle. Su objetivo no es tu servidor, es tu enlace de acceso. Y el enlace se satura en el tramo entre la red de tu proveedor y tu router, un tramo donde tu firewall no ha visto todavía ni un paquete. Descartar ese tráfico al llegar es como poner un portero en la puerta de un bar cuya calle ya está bloqueada por la multitud: el portero hace su trabajo perfectamente y el bar sigue vacío, porque los clientes legítimos no consiguen llegar.
Hay una variante más sofisticada del mismo error: el blackhole local. «Pongo una ruta nula en mi router de borde y descarto el tráfico hacia la IP atacada». Lo hemos visto configurado con toda la buena intención, y no sirve para lo que la gente cree que sirve: el descarte ocurre en tu router, así que todo el caudal del ataque sigue recorriendo tu enlace de acceso hasta llegar a él. Lo sabemos por experiencia de operador: el blackhole local no salva tu enlace. El paquete hay que tirarlo donde todavía hay capacidad de sobra: en el core del proveedor, o más arriba.
Los números de 2025, para dimensionar el problema
Según el informe DDoS del cuarto trimestre de 2025 de Cloudflare, en 2025 mitigaron 47,1 millones de ataques DDoS, un 121% más que el año anterior: una media de más de 5.000 ataques por hora, solo en su red. Los récords de tamaño cayeron en cascada: 7,3 Tbps en mayo, 11,5 en septiembre, 22,2 tres semanas después y 31,4 Tbps en diciembre. Detrás del récord está la botnet Aisuru-Kimwolf, que ha pasado de más de 300.000 dispositivos infectados a una estimación de entre 1 y 4 millones —sobre todo televisores Android, cámaras IP y routers domésticos—. En diciembre lanzó una campaña de 902 ataques contra Cloudflare y sus clientes con picos de 24 Tbps y 205 millones de peticiones por segundo.
El dato que más nos interesa no es el tamaño, sino la duración: el ataque de 31,4 Tbps duró 35 segundos; el de 22,2 Tbps, 40. Son ataques relámpago: para cuando alguien ha abierto un ticket con su proveedor, hace minutos que terminó — y puede volver a empezar en cualquier momento. Esa cadencia tiene una consecuencia práctica directa: una mitigación que dependa de una llamada de teléfono llega siempre tarde. Detección y respuesta tienen que estar automatizadas, o al menos pre-acordadas y listas para disparar.
Qué es RTBH: tirar el ataque donde aún hay sitio
RTBH (Remotely Triggered Black Hole) es la herramienta clásica de los operadores para esto, y lleva dos décadas funcionando. Está descrita en los RFC 3882 y RFC 5635 del IETF, y la idea es elegante de puro simple: en vez de descartar el tráfico en tu router, le pides a tu proveedor que lo descarte en el suyo. El mecanismo es un anuncio BGP. Cuando una IP tuya está siendo atacada, anuncias esa dirección concreta (una /32 en IPv4) a tu proveedor etiquetada con una comunidad BGP especial —existe una estandarizada, BLACKHOLE, la 65535:666, definida en el RFC 7999—. El proveedor, al ver esa etiqueta, enruta todo el tráfico hacia esa IP a un agujero negro en su propia red: en el core, en sus bordes, donde los enlaces son de centenares de gigas o de terabits y el ataque cabe sin despeinarse. A tu enlace de acceso ya no llega nada de ese caudal. La calle vuelve a estar despejada.
Y ahora la parte que casi nadie cuenta, y que nosotros preferimos decir en voz alta: RTBH completa el ataque contra la IP atacada. Al anunciar el blackhole, esa dirección deja de recibir tráfico — todo, también el legítimo. Es una decisión de triaje: sacrificas el servicio que ya estaba caído de facto para que el resto de tu red —el correo, el ERP, la VPN de los comerciales, las otras cincuenta cosas que cuelgan del mismo enlace— siga funcionando. Por eso RTBH brilla cuando el ataque va contra una IP y tienes otras que proteger, y por eso importa el diseño previo: separar servicios en IPs distintas, saber cuáles son sacrificables y cuáles no, y tener el procedimiento ensayado antes de necesitarlo.
¿Y si la IP atacada es justo la que no puede caer? Entonces RTBH no es tu herramienta, y hay que subir un escalón: BGP Flowspec (RFC 8955) permite pedirle al proveedor un filtrado más fino —descartar solo UDP a cierto puerto, limitar un patrón concreto— aunque no todos los operadores lo ofrecen a cliente; y para servicios públicos críticos, la respuesta suele ser ponerlos detrás de una red anycast o un servicio de scrubbing diseñado para absorber estos volúmenes. Cada escalón tiene su coste y su complejidad. Lo honesto es decir que ninguna de estas decisiones se toma bien durante el ataque: se toman antes, con la cabeza fría y el mapa de servicios delante.
Cómo lo hacemos nosotros
En everyWAN esto no es teoría de manual: somos operador con red propia —BGP, tránsito y peering, con un looking glass público en lg.everywan.com para quien quiera curiosear— y gestionamos RTBH en nuestro core. La otra mitad de la ecuación, la que se suele olvidar, es la detección: no puedes disparar un blackhole contra un ataque que no ves. Nosotros analizamos el tráfico con NetFlow, que nos deja ver en tiempo casi real qué IP está recibiendo un caudal anómalo, de qué tipo y desde dónde — la diferencia entre enterarte por tus gráficas o enterarte porque te llama un cliente con todo caído. Detección con NetFlow, decisión con el mapa de servicios delante, anuncio RTBH aguas arriba: esa es la secuencia completa, y los tres eslabones tienen que existir antes del primer ataque.
Cinco preguntas para saber si estás preparado
- 1.¿Qué caudal tiene tu enlace de acceso y qué pasa cuando se llena? Es la pregunta base. Si la respuesta es «se cae todo lo de la sede», ya sabes cuál es tu punto único de fallo.
- 2.¿Tu proveedor soporta blackhole remoto, y cómo se activa? ¿Comunidad BGP en tu sesión? ¿Un panel? ¿Un ticket con horas de cola? La respuesta a esta pregunta vale más que cualquier folleto anti-DDoS. Si es «no lo sé», esa llamada va primero.
- 3.¿Verías el ataque antes de que te lo cuenten? Sin visibilidad de tráfico —NetFlow o equivalente— la respuesta es no. Y con ataques de 35 segundos, enterarse tarde es no enterarse.
- 4.¿Tienes los servicios repartidos en IPs con criterio? RTBH es cirugía por IP: si la web pública, la VPN y el correo comparten dirección, no puedes sacrificar una sin las demás. Separarlos cuesta poco un martes tranquilo y es imposible un viernes bajo ataque.
- 5.¿Qué servicio no puede caer bajo ningún concepto? Para ese, RTBH no basta: hablamos de anycast, scrubbing o CDN. Y conviene dimensionarlo con la cuenta hecha, no comprar el paquete más caro por miedo — no todo el mundo necesita absorber 31 Tbps.
Todo esto es, en el fondo, la misma lección que contamos con la caída de AWS CloudFront: las decisiones que salvan un mal día se toman antes del mal día. En everyWAN diseñamos y operamos redes y comunicaciones de empresa con esta mentalidad de operador: conectividad con BGP y redundancia donde toca, visibilidad NetFlow, y mitigación DDoS acordada aguas arriba en vez de prometida en un folleto. Si no sabes qué respondería tu proveedor a la pregunta 2, hablamos — es una conversación de media hora que se agradece mucho más antes del primer ataque que después.
En corto
Un DDoS volumétrico no ataca a tu servidor: ataca a tu enlace, y el enlace no se defiende desde dentro. El firewall sigue siendo necesario para lo suyo, pero contra el volumen la única defensa real está aguas arriba, en redes con capacidad para absorberlo y tirarlo: RTBH para sacrificar una IP y salvar el resto, Flowspec o scrubbing cuando hace falta bisturí en lugar de martillo. Los récords de 2025 —31,4 Tbps, 47 millones de ataques, ráfagas de 35 segundos— no cambian esta lógica: la confirman con números cada vez más gordos. La pregunta no es si tu firewall es bueno. Es si tu operador sabe qué hacer cuando le anuncies una /32 con la comunidad 65535:666 — y si tú sabes cuándo anunciarla.
Fuentes (verificadas): cifras de 2025 (47,1 millones de ataques mitigados, +121% interanual, récord de 31,4 Tbps en diciembre con 35 segundos de duración, botnet Aisuru-Kimwolf de 1–4 millones de dispositivos, campaña de diciembre con 902 ataques y picos de 24 Tbps / 205 Mrps) — Cloudflare, informe DDoS Q4 2025 y CyberInsider; ataque de 22,2 Tbps / 10,6 Bpps y 40 segundos (septiembre de 2025) y datos previos de Aisuru (300.000+ dispositivos según XLab) — BleepingComputer; técnica RTBH y comunidad BLACKHOLE — RFC 5635, RFC 7999 y RFC 8955 (IETF). La experiencia de operación con RTBH, NetFlow y BGP descrita es de la red propia de everyWAN.
¿Sabes qué haría tu conectividad bajo un DDoS?
En everyWAN somos operador con red propia: BGP, tránsito y peering, RTBH en el core, visibilidad NetFlow y monitorización 24/7. Diseñamos la conectividad de tu empresa para el día malo, no solo para el bueno.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN