Hi ha una frase que sentim sovint quan surt el tema DDoS: «tranquils, tenim un bon firewall». I hi ha un número que la desmunta en sec: el desembre del 2025, Cloudflare va mitigar l'atac DDoS més gran registrat fins avui, 31,4 terabits per segon. Això són unes 31.000 vegades el cabal d'una fibra empresarial d'1 Gbps. No cal un rècord: un atac mil vegades més petit que aquest continua sent 30 vegades el teu enllaç. El firewall pot ser boníssim; tant li fa. Quan el trànsit de l'atac arriba al teu firewall, la batalla ja està perduda, perquè el teu enllaç d'accés s'ha omplert uns quilòmetres abans. Un DDoS volumètric no es guanya a casa teva: es guanya aigües amunt. D'això va aquest post: de com es fa de debò, amb BGP i una tècnica que es diu RTBH, i del que un operador pot fer per tu que cap caixa al teu rack no pot.
El mite: «la caixa ho para»
El malentès neix de barrejar dues coses diferents. Un firewall, un IPS o un anti-DDoS d'appliance treballen a la destinació: inspeccionen el trànsit que ja ha arribat fins a tu i decideixen què passa i què no. Contra atacs d'aplicació —peticions HTTP malicioses, abusos d'API, floods de capa 7 amb poc ample de banda— això té sentit i funciona. Però un DDoS volumètric no intenta colar-se per la teva porta: intenta omplir el carrer. El seu objectiu no és el teu servidor, és el teu enllaç d'accés. I l'enllaç se satura al tram entre la xarxa del teu proveïdor i el teu router, un tram on el teu firewall encara no ha vist ni un paquet. Descartar aquest trànsit en arribar és com posar un porter a la porta d'un bar amb el carrer ja bloquejat per la multitud: el porter fa la seva feina perfectament i el bar continua buit, perquè els clients legítims no aconsegueixen arribar-hi.
Hi ha una variant més sofisticada del mateix error: el blackhole local. «Poso una ruta nul·la al meu router de vora i descarto el trànsit cap a la IP atacada». Ho hem vist configurat amb tota la bona intenció, i no serveix per al que la gent creu que serveix: el descart passa al teu router, així que tot el cabal de l'atac continua recorrent el teu enllaç d'accés fins a arribar-hi. Ho sabem per experiència d'operador: el blackhole local no salva el teu enllaç. El paquet s'ha de llençar on encara hi ha capacitat de sobres: al core del proveïdor, o més amunt.
Els números del 2025, per dimensionar el problema
Segons l'informe DDoS del quart trimestre del 2025 de Cloudflare, el 2025 van mitigar 47,1 milions d'atacs DDoS, un 121% més que l'any anterior: una mitjana de més de 5.000 atacs per hora, només a la seva xarxa. Els rècords de mida van caure en cascada: 7,3 Tbps al maig, 11,5 al setembre, 22,2 tres setmanes després i 31,4 Tbps al desembre. Darrere del rècord hi ha la botnet Aisuru-Kimwolf, que ha passat d'més de 300.000 dispositius infectats a una estimació d'entre 1 i 4 milions —sobretot televisors Android, càmeres IP i routers domèstics—. Al desembre va llançar una campanya de 902 atacs contra Cloudflare i els seus clients amb pics de 24 Tbps i 205 milions de peticions per segon.
La dada que més ens interessa no és la mida, sinó la durada: l'atac de 31,4 Tbps va durar 35 segons; el de 22,2 Tbps, 40. Són atacs llampec: quan algú ha obert un tiquet amb el seu proveïdor, fa minuts que s'ha acabat — i pot tornar a començar en qualsevol moment. Aquesta cadència té una conseqüència pràctica directa: una mitigació que depengui d'una trucada de telèfon arriba sempre tard. Detecció i resposta han d'estar automatitzades, o com a mínim pre-acordades i llestes per disparar.
Què és RTBH: llençar l'atac on encara hi ha lloc
RTBH (Remotely Triggered Black Hole) és l'eina clàssica dels operadors per a això, i fa dues dècades que funciona. Està descrita als RFC 3882 i RFC 5635 de l'IETF, i la idea és elegant de tan simple: en comptes de descartar el trànsit al teu router, demanes al teu proveïdor que el descarti al seu. El mecanisme és un anunci BGP. Quan una IP teva està sent atacada, anuncies aquesta adreça concreta (una /32 en IPv4) al teu proveïdor etiquetada amb una comunitat BGP especial —n'hi ha una d'estandarditzada, BLACKHOLE, la 65535:666, definida al RFC 7999—. El proveïdor, en veure aquesta etiqueta, encamina tot el trànsit cap a aquesta IP a un forat negre a la seva pròpia xarxa: al core, a les seves vores, on els enllaços són de centenars de gigues o de terabits i l'atac hi cap sense despentinar-se. Al teu enllaç d'accés ja no arriba res d'aquest cabal. El carrer torna a estar lliure.
I ara la part que gairebé ningú no explica, i que nosaltres preferim dir en veu alta: RTBH completa l'atac contra la IP atacada. En anunciar el blackhole, aquesta adreça deixa de rebre trànsit — tot, també el legítim. És una decisió de triatge: sacrifiques el servei que ja estava caigut de facto perquè la resta de la teva xarxa —el correu, l'ERP, la VPN dels comercials, les altres cinquanta coses que pengen del mateix enllaç— continuï funcionant. Per això RTBH brilla quan l'atac va contra una IP i en tens d'altres per protegir, i per això importa el disseny previ: separar serveis en IPs diferents, saber quines són sacrificables i quines no, i tenir el procediment assajat abans de necessitar-lo.
I si la IP atacada és justament la que no pot caure? Llavors RTBH no és la teva eina, i cal pujar un esglaó: BGP Flowspec (RFC 8955) permet demanar al proveïdor un filtratge més fi —descartar només UDP a cert port, limitar un patró concret— tot i que no tots els operadors ho ofereixen a client; i per a serveis públics crítics, la resposta sol ser posar-los darrere d'una xarxa anycast o un servei de scrubbing dissenyat per absorbir aquests volums. Cada esglaó té el seu cost i la seva complexitat. L'honest és dir que cap d'aquestes decisions no es pren bé durant l'atac: es prenen abans, amb el cap fred i el mapa de serveis al davant.
Com ho fem nosaltres
A everyWAN això no és teoria de manual: som operador amb xarxa pròpia —BGP, trànsit i peering, amb un looking glass públic a lg.everywan.com per a qui vulgui tafanejar— i gestionem RTBH al nostre core. L'altra meitat de l'equació, la que se sol oblidar, és la detecció: no pots disparar un blackhole contra un atac que no veus. Nosaltres analitzem el trànsit amb NetFlow, que ens deixa veure en temps gairebé real quina IP està rebent un cabal anòmal, de quin tipus i des d'on — la diferència entre assabentar-te'n per les teves gràfiques o assabentar-te'n perquè et truca un client amb tot caigut. Detecció amb NetFlow, decisió amb el mapa de serveis al davant, anunci RTBH aigües amunt: aquesta és la seqüència completa, i les tres baules han d'existir abans del primer atac.
Cinc preguntes per saber si estàs preparat
- 1.Quin cabal té el teu enllaç d'accés i què passa quan s'omple? És la pregunta base. Si la resposta és «cau tot el de la seu», ja saps quin és el teu punt únic de fallada.
- 2.El teu proveïdor suporta blackhole remot, i com s'activa? Comunitat BGP a la teva sessió? Un panell? Un tiquet amb hores de cua? La resposta a aquesta pregunta val més que qualsevol fullet anti-DDoS. Si és «no ho sé», aquesta trucada va primer.
- 3.Veuries l'atac abans que t'ho expliquin? Sense visibilitat de trànsit —NetFlow o equivalent— la resposta és no. I amb atacs de 35 segons, assabentar-se'n tard és no assabentar-se'n.
- 4.Tens els serveis repartits en IPs amb criteri? RTBH és cirurgia per IP: si la web pública, la VPN i el correu comparteixen adreça, no en pots sacrificar una sense les altres. Separar-los costa poc un dimarts tranquil i és impossible un divendres sota atac.
- 5.Quin servei no pot caure sota cap concepte? Per a aquest, RTBH no n'hi ha prou: parlem d'anycast, scrubbing o CDN. I convé dimensionar-lo amb el compte fet, no comprar el paquet més car per por — no tothom necessita absorbir 31 Tbps.
Tot això és, al capdavall, la mateixa lliçó que vam explicar amb la caiguda d'AWS CloudFront: les decisions que salven un mal dia es prenen abans del mal dia. A everyWAN dissenyem i operem xarxes i comunicacions d'empresa amb aquesta mentalitat d'operador: connectivitat amb BGP i redundància on toca, visibilitat NetFlow, i mitigació DDoS acordada aigües amunt en comptes de promesa en un fullet. Si no saps què respondria el teu proveïdor a la pregunta 2, parlem — és una conversa de mitja hora que s'agraeix molt més abans del primer atac que després.
En curt
Un DDoS volumètric no ataca el teu servidor: ataca el teu enllaç, i l'enllaç no es defensa des de dins. El firewall continua sent necessari per al que és seu, però contra el volum l'única defensa real és aigües amunt, en xarxes amb capacitat per absorbir-lo i llençar-lo: RTBH per sacrificar una IP i salvar la resta, Flowspec o scrubbing quan cal bisturí en comptes de martell. Els rècords del 2025 —31,4 Tbps, 47 milions d'atacs, ràfegues de 35 segons— no canvien aquesta lògica: la confirmen amb números cada cop més grossos. La pregunta no és si el teu firewall és bo. És si el teu operador sap què fer quan li anunciïs una /32 amb la comunitat 65535:666 — i si tu saps quan anunciar-la.
Fonts (verificades): xifres del 2025 (47,1 milions d'atacs mitigats, +121% interanual, rècord de 31,4 Tbps al desembre amb 35 segons de durada, botnet Aisuru-Kimwolf d'1–4 milions de dispositius, campanya de desembre amb 902 atacs i pics de 24 Tbps / 205 Mrps) — Cloudflare, informe DDoS Q4 2025 i CyberInsider; atac de 22,2 Tbps / 10,6 Bpps i 40 segons (setembre del 2025) i dades prèvies d'Aisuru (300.000+ dispositius segons XLab) — BleepingComputer; tècnica RTBH i comunitat BLACKHOLE — RFC 5635, RFC 7999 i RFC 8955 (IETF). L'experiència d'operació amb RTBH, NetFlow i BGP descrita és de la xarxa pròpia d'everyWAN.
Saps què faria la teva connectivitat sota un DDoS?
A everyWAN som operador amb xarxa pròpia: BGP, trànsit i peering, RTBH al core, visibilitat NetFlow i monitoratge 24/7. Dissenyem la connectivitat de la teva empresa per al dia dolent, no només per al bo.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN