- Els atacs DDoS han passat de centenars de Gbps a hiperatacs de diversos Tbps, recolzats en botnets IoT i tècniques d'amplificació UDP.
- La mitigació professional combina scrubbing centers, CDNs Anycast, firewalls, WAF i bones pràctiques de hardening i monitorització primerenca.
- La Protecció de Flux Programable de Cloudflare permet lògica de paquets al C/eBPF per filtrar trànsit UDP específic a nivell d'aplicació.
- Una estratègia efectiva exigeix defensa en profunditat, automatització, plans de contingència i col·laboració amb ISP i proveïdors cloud.
Vivim en una època en què la xarxa és el teixit connectiu de gairebé tot el que fem. Quan una empresa es queda sense servei per un atac de denegació de servei, no només cau una web: es paralitzen vendes, processos interns, atenció al client i, en els casos més greus, serveis essencials. Per això, la mitigació personalitzada d'atacs DDoS amb protecció de flux programable ha esdevingut una peça estratègica en qualsevol arquitectura moderna.
L'aparició de tecnologies com la Protecció de Flux Programable de Cloudflare per a Magic Transit , l'ús de lògica pròpia a C desplegada com a eBPF, la integració amb núvols com AWS i Azure i el suport de serveis especialitzats de defensa han canviat radicalment el panorama. Ara és possible modelar què és trànsit “bo” o “maliciós” a nivell de paquet, adaptar la mitigació a protocols UDP molt específics (com els de videojocs en línia o VoIP) i combinar-ho amb solucions d'intel·ligència de negoci i IA que aprenen de cada atac.
Què és un atac DDoS i per què s'ha tornat un problema tan seriós
Un atac de denegació de servei distribuït, o DDoS, cerca saturar els recursos d'un sistema (servidors, enllaços, aplicacions o infraestructures intermèdies) llançant una allau de trànsit des de moltes fonts simultànies. A diferència d?un DoS clàssic, en què un únic origen dispara l?atac, en un DDoS intervenen milers o fins i tot milions de dispositius compromesos, organitzats en una botnet.
La motivació darrere dels atacs DDoS és variada: xantatges econòmics, sabotatge entre competidors, activisme, represàlies contra periodistes o mitjans, o simplement proves de força de nous botnets en mode “demostració de capacitats”. El resultat, això sí, és sempre el mateix: indisponibilitat del servei , degradació greu del rendiment i danys econòmics i de reputació.
Els darrers anys s'ha constatat un augment constant de la freqüència i la intensitat d'aquests atacs. Informes de grans proveïdors de seguretat assenyalen un creixement sostingut dels atacs hipervolumètrics (per sobre d'1 Tbps o de mil milions de paquets per segon), moltes vegades dirigits a infraestructures crítiques com ara serveis financers, utilities o telecomunicacions.
Tipus d'atacs DDoS: de la xarxa a l'aplicació
Per entendre com funciona una mitigació de DDoS personalitzada, convé repassar les categories d'atacs principals. En termes generals, els podem agrupar en quatre grans famílies, lligades a diferents capes del model OSI ia diferents recursos que busquen esgotar.
Atacs de capa de xarxa (L3/L4) Se centren a explotar els protocols de xarxa i transport (IP, TCP, UDP, ICMP) per drenar recursos limitats del servidor o de la infraestructura intermèdia: CPU, memòria, taules de tallafocs, connexions pendents o buffers de xarxa. Exemples clàssics són els SYN flood (inunden de peticions de connexió TCP que mai completen el handshake), les inundacions UDP a ports aleatoris o els atacs ICMP.
Atacs de capa d'aplicació (L7) No apunten tant a l'amplada de banda com als recursos de la pròpia aplicació web o API. Generen un volum enorme de peticions HTTP (GET/POST), consultes complexes a cercadors interns, trucades a APIs pesades o interaccions que, encara que semblen legítimes, forcen el backend, la base de dades o els sistemes de generació de contingut a treballar al límit.
Atacs volumètrics L'objectiu és negar l'enllaç fins a deixar-lo inutilitzable. S'envien quantitats massives de trànsit, sovint aprofitant tècniques d'amplificació i reflexió en serveis UDP mal configurats, com a servidors DNS públics (DNS, NTP, Memcached, CLDAP, SNMP, SSDP, Chargen, SLP, etc.), de manera que un petit paquet de petició origina una resposta molt més gran dirigida a la víctima.
Atacs multivector Són, ara com ara, els més complexos. Combinen diversos mètodes (volumètrics, de protocol i d'aplicació) i canvien d'estratègia a temps real segons detecten que una defensa està tenint èxit. Un mateix atac pot arrencar com a inundació UDP, passar després a SYN flood i, a continuació, pivotar un atac HTTP de capa 7, obligant la víctima a disposar de defenses completes i coordinades.
Evolució real dels atacs DDoS: de Mirai als hiperatacs Tbps
La teoria està bé, però on es veu la veritable magnitud del problema, és en els casos reals. A l'última dècada hem passat d'atacs de centenars de Gbps a esdeveniments que superen amb comoditat els diversos terabits per segon (Tbps) , amb taxes de paquets que arriben a milers de milions per segon.
El 2016, l'atac contra Dyn —un important proveïdor de DNS— va arribar al voltant d'1,2 Tbps i va deixar fora de joc temporalment llocs com Twitter, GitHub, PayPal i Netflix. Es va fer servir la botnet Mirai, que va reclutar més de 600.000 dispositius IoT (routers, càmeres i DVR amb credencials per defecte) per generar un trànsit massiu cap als servidors DNS de Dyn, probablement barrejant inundacions UDP i tècniques d'amplificació.
Aquell mateix any, el bloc de seguretat KrebsOnSecurity va patir un atac d'uns 623 Gbps , també impulsat per Mirai. Durant gairebé quatre dies es van llançar principalment paquets UDP grans a ports aleatoris, saturant els enllaços i obligant a desviar el trànsit cap a serveis de mitigació especialitzats com Akamai Prolexic, que van aplicar filtratge per firmes i comportaments.
El 2018, GitHub va ser blanc d'un atac de 1,35 Tbps basat en amplificació Memcached. Els atacants enviaven petites peticions UDP a servidors Memcached exposats al port 11211, usant la IP de GitHub suplantada. Cada petició mínima desencadenava respostes 50-100 vegades més grans adreçades als sistemes de GitHub, que es van veure obligats a desviar el trànsit a centres de neteja on es filtraven les respostes Memcached pels seus patrons específics.
El 2020, Amazon va notificar que AWS Shield havia mitigat un atac de 2,3 Tbps recolzat en reflexió CLDAP (UDP 389). El vector va consistir a bombardejar servidors LDAP sense estat amb consultes que generaven respostes dalt volum cap a la víctima. AWS va distribuir el trànsit a través de la seva xarxa global i va aplicar regles de filtratge per a aquest patró concret de CLDAP.
Més recentment han aparegut botnets com Mēris , que va explotar vulnerabilitats a routers MikroTik. El 2021 es van registrar pics de 21,8 milions de peticions per segon (RPS) i, el 2022, es van assolir els 46 milions RPS contra infraestructures de Google, amb volums aproximats d'1,3 Tbps. La mitigació va passar per pegats dispositius en massa, tancar ports com el 5678 i aplicar regles de filtratge específiques per a la signatura de Mēris en xarxes com Cloudflare o Akamai.
A l'abril de 2025, Cloudflare va reportar un hiper-atac d'uns 6,5 Tbps i diversos milers de milions de paquets per segon. Segons la seva anàlisi, es va tractar d'una botnet encara no atribuïda, amb característiques similars a Mēris i Aisuru, que va fer servir principalment inundacions UDP directes des de dispositius IoT i servidors mal configurats, sense necessitat d'amplificació clàssica. La defensa es va recolzar a la xarxa Anycast global de Cloudflare, mitigació amb XDP/eBPF a la vora, scrubbing dinàmic i limitació de taxa per IP i per regió.
I el maig del 2025, KrebsOnSecurity va tornar a ser notícia en resistir un atac aproximadament de 6,3 Tbps llançat per la botnet Aisuru. En aquest cas, es van generar uns 585 milions de paquets UDP per segon durant 40-45 segons. Google Project Shield, que protegia el lloc, va activar immediatament polítiques de filtratge agressiu d'UDP no sol·licitat i va desviar el trànsit cap a centres de neteja distribuïts a la seva xarxa global, de manera que l'impacte en el servei va ser pràcticament imperceptible.
Recursos i tècniques dels atacants: botnets, amplificació i evasió
Per aconseguir aquestes xifres desorbitades, els atacants tenen diferents recursos que combinen segons l'objectiu. Les botnets massives són la base: xarxes de dispositius compromesos a tot el món, reclutats explotant vulnerabilitats conegudes, contrasenyes per defecte o serveis d'administració exposats. Mirai, Mēris o Aisuru són noms de família, però hi ha infinitat de variants enfocades a diferents fabricants o serveis.
El segon gran recurs són els servidors mal configurats que actuen com a reflectors. Qualsevol servei UDP sense autenticació que respongui amb més dades de les que rep és un candidat: DNS (port 53), NTP (123), Memcached (11211), CLDAP (389), SNMP (161), SSDP, Chargen, SLP, TFTP, Portmap, serveis P2P o fins i tot. L'atacant envia peticions petites suplantant com a origen la IP de la víctima, i els servidors amplifiquen i tornen la resposta a l'objectiu real.
A DNS, per exemple, una consulta tipus ANY a un resoldre obert pot multiplicar per unes 28 vegades la mida de la petició. A NTP, l'antic comando MONLIST arribava a ràtios de 50-500 vegades. Memcached és un cas extrem: una sol·licitud minúscula pot tornar fins a centenars de KB, aconseguint ràtios d'amplificació de desenes de milers. CLDAP es mou en factors de 56-70x, mentre que SLP s'ha arribat a fer servir amb valors superiors a 2000x.
A més, els atacants afinen les tècniques d'evasió. L' IP spoofing continua sent un clàssic per amagar l'origen real i explotar la reflexió. Altres mètodes inclouen rotar constantment vectors d'atac, barrejar trànsit xifrat per forçar majors càrregues de processament al costat defensor, utilitzar tècniques “low and slow” (consum progressiu de recursos sense pics evidents) o apropar el trànsit a la capa d'aplicació, on s'assembla molt més al trànsit legítim.
A la fase prèvia a l'atac es fan servir eines d'escaneig massiu com masscan o zmap per localitzar serveis vulnerables, i kits d'explotació específics per a IoT o servidors. Durant l'atac, es recorre a generadors de trànsit com hping3, LOIC/HOIC o scripts al C/Python optimitzats, mentre que per a l'anàlisi posterior els mateixos atacants poden emprar Wireshark, tcpdump i plataformes de monitoratge.
Fases d‟un atac DDoS i la necessitat d‟una defensa adaptativa
Encara que moltes vegades es perceben com a explosions caòtiques de trànsit, els atacs DDoS sofisticats passen per diverses fases ben diferenciades . Primer, l'etapa de reconeixement, en què l'atacant estudia la superfície exposada, identifica dominis, adreces IP, serveis oberts, CDN o proveïdors de mitigació presents, i cerca punts febles.
Després té lloc el compromís de dispositius, és a dir, la infecció dequips que alimentaran la botnet. Això pot implicar explotar vulnerabilitats de routers, càmeres, sistemes de gestió remota o servidors, moltes vegades aprofitant programari no actualitzat o credencials per defecte. Un cop reclutats, es connecten a la infraestructura C2, que centralitza ordres i actualitzacions.
La fase d'execució de l'atac sol sincronitzar-se amb moments crítics per a la víctima: campanyes de màrqueting, llançaments de productes, caps de setmana amb menor personal de guàrdia o dates sensibles a nivell polític o mediàtic. L'objectiu és maximitzar l'impacte i la pressió . Als atacs de nova generació, a més, hi ha un component d'adaptació dinàmica: el botnet monitoritza la resposta de la víctima i canvia de vector si detecta mitigació efectiva.
Al costat defensor, això obliga a dissenyar estratègies igualment adaptatives. No n'hi ha prou amb un tallafoc estàtic o un llindar d'ample de banda: calen sistemes capaços de detectar anomalies de trànsit en temps real , correlacionar esdeveniments, desplegar regles noves sobre la marxa i escalar recursos (computació, emmagatzematge i capacitat de xarxa) sota demanda.
Un estudi recent reflectia que els atacs DDoS contra infraestructures crítiques han crescut més d'un 50% en quatre anys, i que sovint s'utilitzen com a cortina de fum per a altres intrusions, com ara la implantació de ransomware mentre l'equip de seguretat està centrat a “apagar el foc” de la denegació de servei.
Mitigació tradicional: scrubbing centers, CDNs, firewalls i WAF
Les defenses professionals davant de DDoS es recolzen en una combinació de tecnologies i proveïdors. El component més característic són els centres de neteja de trànsit (scrubbing centers) , grans infraestructures distribuïdes que poden absorbir desenes de Tbps i filtrar el trànsit maliciós abans de tornar només les connexions vàlides cap al client.
Empreses com Netscout/Arbor, Akamai/Prolexic, Cloudflare, Radware, Imperva o AWS Shield gestionen xarxes globals amb múltiples punts de presència. Quan es detecta un atac, el trànsit destinat a l'organització víctima es redirigeix (mitjançant canvis BGP o actualitzacions DNS) cap a aquests centres, on s'apliquen filtres basats en signatures, comportament, llistes negres, anàlisi estadística i regles personalitzades.
En paral·lel, moltes organitzacions despleguen appliances anti-DDoS on-premise en els seus propis data centers o en els del seu ISP. Dispositius com Arbor TMS, Radware DefensePro, FortiDDoS o certes solucions de F5 s'encarreguen de detectar i mitigar atacs fins a un límit de capacitat concret. El més habitual és combinar aquestes caixes locals amb una solució de scrubbing al núvol per a atacs que excedeixin la seva capacitat.
Les CDN i arquitectures Anycast —com les de Cloudflare, Akamai, Fastly o Google Cloud CDN— afegeixen una altra capa de defensa en dispersar geogràficament la càrrega. En publicar un servei darrere una CDN, el trànsit es reparteix per múltiples nodes, i els atacs volumètrics es dilueixen en no concentrar-se en un únic punt. A més, solen integrar WAF (Web Application Firewall) i polítiques de limitació de taxa a nivell HTTP.
Finalment, els tallafocs de xarxa (Cisco, Palo Alto, iptables en Linux, etc.) i els WAFs especialitzats (ModSecurity, Cloudflare WAF, AWS WAF) permeten filtrar trànsit per IP, ports, flags i patrons d'aplicació . Encara que per si sols no frenen un atac Tbps a nivell de backbone, són essencials per bloquejar vectors coneguts, limitar connexions sospitoses i protegir les capes 6/7 de la pila.
Protecció de Flux Programable i mitigació personalitzada amb Magic Transit
En aquest context d'atacs cada cop més complexos i protocols cada cop més específics, sorgeixen solucions com la Protecció de Flux Programable (Programmable Flow Protection) de Cloudflare per a Magic Transit , que marquen un salt qualitatiu: permeten a les empreses escriure la seva pròpia lògica de mitigació i desplegar-la directament a la xarxa d'un proveïdor global.
La idea és senzilla però potent: els clients de Magic Transit poden carregar programes de processament de paquets amb estat escrits a C . Cloudflare valida, compila i transforma aquests programes a eBPF, executant-los en espai d'usuari dins de la seva infraestructura global. Això permet inspeccionar trànsit UDP d'aplicació de manera conscient del protocol: entendre capçaleres específiques d'un joc en línia, d'un sistema de trading d'alta freqüència, de serveis de VoIP o de plataformes de streaming, i decidir, paquet a paquet, què es permet i què es bloqueja.
Aquesta lògica personalitzada està integrada amb Flowtrackd, la plataforma de mitigació stateful de Cloudflare. La funció suporta topologies simètriques i asimètriques, encara que, en aquesta fase beta tancada, se centra a analitzar el trànsit entrant. Tota la gestió es realitza a través de l'API de Cloudflare, amb endpoints per pujar programes, crear regles associades, llistar configuracions o eliminar segons canvien les necessitats.
El que és rellevant aquí és que ja no depenem únicament de les firmes i heurístiques genèriques del proveïdor. Una empresa de videojocs, per exemple, pot definir clarament quin és el flux legítim del protocol UDP propietari (handshake, missatges de posició, keep-alives, etc.) i quins patrons són propis d'un atac. Aquesta lògica es compila i es desplega a tots els punts de presència de Cloudflare, apropant la decisió a la frontera de la xarxa.
Per a entorns amb protocols a mida o aplicacions molt exigents en latència, aquesta mitigació d'atacs DDoS amb protecció de flux programable representa un canvi de joc: s'hi afegeix una capa d'intel·ligència específica del negoci per sobre de la defensa estàndard. I en combinar-la amb serveis cloud com AWS o Azure, i amb solucions de programari a mida (com les que desenvolupen companyies especialitzades en IA i analítica, tipus Q2BSTUDIO), es pot automatitzar encara més la detecció i actualització de regles en funció de noves amenaces.
Per què els ISP i les organitzacions necessiten mitigació DDoS avançada
Els proveïdors de serveis d'Internet (ISP) i les grans organitzacions són a primera línia de foc. Un atac prou gran pot saturar no només un client concret, sinó tota una part de la xarxa d'un operador i provoca caigudes en cascada que afecten milers d'usuaris. Per això la mitigació DDoS s'ha convertit en un requisit indispensable, no un extra opcional.
Des del punt de vista de negoci, les conseqüències de no defensar-se són clares: interrupció del servei, incompliment d'acords de nivell de servei (SLA), penalitzacions contractuals, pèrdua directa d'ingressos i fugida de clients cap a competidors percebuts com a més fiables. Si una aplicació crítica no està disponible quan l'usuari la necessita, el més normal és que busqui alternatives.
En sectors com la banca, les assegurances, els serveis públics o la sanitat, l'impacte pot anar més enllà del que és econòmic: interrupcions de processos físics , riscos operatius i afectació a serveis essencials. A més, hi ha un cost reputacional difícil de recuperar quan una marca apareix associada a “sistema caigut” durant hores a xarxes socials i mitjans.
Per si no n'hi hagués prou, els atacs DDoS s'utilitzen sovint com a tapadora per a ofensives més perjudicials. Mentre l'equip de seguretat està concentrat a gestionar l'allau de trànsit, els atacants poden intentar moure's lateralment dins de la xarxa, desplegar ransomware o exfiltrar dades. És a dir, el DDoS funciona com a esquer i distracció en atacs de diverses fases.
Les solucions modernes de mitigació, tant on premis com al núvol, permeten reduir sensiblement el temps d'inactivitat, mantenir la continuïtat de negoci i protegir tant actius locals com recursos en núvols públics. La clau és que puguin escalar automàticament davant pics massius de trànsit i que ofereixin garanties clares de capacitat i temps de resposta.
Tècniques concretes de mitigació: del rate limiting al blackholing
Més enllà dels grans blocs tecnològics, hi ha una sèrie de tècniques específiques que s'apliquen cada dia per fer front a atacs de diferents tipus. Una de les més bàsiques és el filtratge perimetral mitjançant tallafocs i llistes de control d'accés (ACL), en routers i switches, bloquejant paquets segons IP d'origen, destinació, ports, flags TCP o mida.
Una altra peça clàssica és la limitació de taxa (rate limiting) , tant a les capes 3/4 com a HTTP. En sistemes Linux, iptables ofereix mòduls com ara hashlimit o SYNPROXY per controlar quantes connexions o paquets per segon s'accepten des d'una mateixa IP. Al plànol d'aplicació, proxies com Nginx o HAProxy poden fixar límits de peticions per client o per ruta.
Per a atacs de capa 7 és molt útil establir desafiaments o autenticació addicional . Els CAPTCHAs, JavaScript challenges i mecanismes similars permeten discriminar millor entre navegadors reals i bots automatitzats, reduint la càrrega sobre l'aplicació real. A TCP, tècniques com les SYN cookies ajuden a que el servidor no hagi d'emmagatzemar estat de cada intent de connexió fins que es completi el handshake.
Quan el volum de l'atac és inassumible fins i tot per a la infraestructura de mitigació, es pot recórrer al BGP blackholing : l'ISP anuncia la ruta cap a la xarxa atacada com un “forat negre”, descartant tot el trànsit destinat a aquest prefix abans que entri al backbone. És un últim recurs perquè suposa fer indisponible el servei, però evita que l'atac arrossegui altres parts de la xarxa.
Els serveis d'scrubbing al núvol —com els que ofereixen Cloudflare, Akamai, AWS Shield, Google Project Shield, Radware o altres— permeten derivar tot el trànsit cap als seus centres i netejar-lo allà, aplicant regles específiques per a vectors com amplificació Memcached, CLDAP, DNS, NTP, flots. Cada atac bloquejat alimenta models de machine learning i bases de dades de signatures que s'apliquen en mitigacions futures.
Bones pràctiques i lliçons apreses davant dels DDoS actuals
Dels grans incidents dels darrers anys se n'extreuen diverses lliçons clares. La primera és que assegurar els dispositius IoT és fonamental: bona part de la potència de botnets com Mirai, Mēris o Aisuru ve de encaminadors domèstics, càmeres i altres dispositius amb firmware desactualitzat i contrasenyes de fàbrica.
La segona és que cal eliminar vectors d'amplificació dins de les nostres xarxes: deshabilitar serveis UDP innecessaris, filtrar NTP, DNS o Memcached cap a l'exterior, aplicar regles de tallafocs que només permetin consultes des de rangs autoritzats i revisar periòdicament els ports exposats. Qualsevol servidor mal configurat es pot convertir en un amplificador al servei d'un atacant.
També és essencial comptar amb detecció primerenca d'anomalies . Eines com NetFlow, sFlow, IDS/IPS (Snort, Suricata), plataformes d'anàlisi de logs o SIEM han d'estar configurades per alertar quan apareguin pics inusuals de trànsit, canvis bruscos als patrons de connexió o firmes conegudes d'atacs. Com més aviat s'activi la resposta, menys marge hi ha perquè l'atac escali.
En entorns web, és gairebé obligatori utilitzar WAF actualitzats, CAPTCHAs quan encaixa amb l'experiència d'usuari i caixets o CDNs que absorbeixin part de la càrrega. A nivell de sistema, habilitar galetes SYN, ajustar llindars de connexions simultànies i tancar qualsevol servei no essencial redueix la superfície d'atac.
Finalment, tota organització hauria de tenir un pla de contingència DDoS documentat : un runbook amb passos clars, responsables designats, contactes tècnics als proveïdors de mitigació i als ISP, i criteris predefinits sobre quan activar scrubbing, quan sol·licitar blackholing o quan degradar funcions no essencials per protegir el nucli del negoci.
La tendència apunta a atacs cada cop més veloços, intensos i adaptatius, però també a defenses més intel·ligents i personalitzables. Aprofitar les capacitats de solucions com la Protecció de Flux Programable, combinades amb escrutini constant del trànsit, bones pràctiques de configuració i arquitectures redundants al núvol, permet a les empreses seguir operant amb normalitat fins i tot en plena tempesta de paquets, protegint no només les dades, sinó també la reputació i la confiança dels seus clients.
