Google slaat ddos-aanval met recordpiek van 398 miljoen requests per seconde af

Google zegt dat het de grootste ddos-aanval in zijn geschiedenis heeft afgeslagen. Het bedrijf wist een HTTP/2-aanval af te slaan die 398 miljoen requests per second behaalde, de grootst bekende ddos-aanval die ooit is geregistreerd.

Google schrijft dat het de aanval in augustus registreerde op zijn eigen Cloud-infrastructuur. Het bedrijf zegt dat eind van die maand een serie aanvallen begon die het tot de dag van vandaag ziet en af weet te slaan. Het hoogtepunt vond plaats in augustus zelf; in twee minuten zag Google een aanval waarbij twee keer een piekhoeveelheid data werd gehaald van 398 miljoen requests per seconde tegen de infrastructuur.

Het is niet bekend wie de aanval heeft uitgevoerd, maar Google heeft wel meer details over de aanval openbaar gemaakt en gedeeld met andere bedrijven. Die kunnen de signatuur van de aanval gebruiken om die vroegtijdig op te merken en af te slaan of om te leiden.

Volgens Google gaat het om een aanval op het HTTP/2-protocol. Hoewel dat protocol vaker wordt misbruikt voor ddos-aanvallen, maakten de aanvallers in dit geval misbruik van een nieuwe techniek op basis van een kwetsbaarheid in dat protocol. Dat noemt Google de 'Rapid Reset'-aanval. Het bedrijf heeft de kwetsbaarheid geregistreerd als CVE-2023-44487. Het bedrijf heeft daar ook een blogpost over geschreven.

Rapid Reset is een Layer 7-aanval waarbij een ddos-aanval kan worden uitgevoerd door het HTTP/2-protocol aan te vallen. HTTP/2 laat browsers verzoeken sturen naar websites om bijvoorbeeld content in te laden. Bij HTTP/2 is het, in tegenstelling tot een eerdere versie van het protocol, mogelijk om meerdere streams met dezelfde verbinding op te starten. Dat moet zorgen voor een snellere doorvoer van content, maar de nieuwe bug buit dat principe uit door honderden of duizenden requests tegelijk te doen en die direct ook weer stop te zetten. Daardoor is het maximale aantal verzoeken dat een aanvaller kan doen niet meer afhankelijk van de zogenaamde round trip time van aanvragen.

Google zegt dat de aanvallers hebben geëxperimenteerd met meerdere varianten van Rapid Reset. Zo wachtten de aanvallers in sommige gevallen een tijd met het stopzetten van de streams of probeerden ze meerdere streams tegelijk te sturen.

De aanval is niet alleen de grootste die Google ooit heeft gedetecteerd, maar de grootste ddos-aanval die ooit bekend is geworden. In 2022 registreerde het bedrijf het vorige dubieuze record; toen vond een ddos-aanval plaats die piekte op 46 miljoen requests per seconde. De nieuwe aanval is met 398 miljoen rps ruim 7,5 keer zo groot als de vorige. Ddos-aanvallen lijken de laatste jaren exponentieel te groeien. Cloudflare zag bijvoorbeeld in 2022 nog een recordaanval van 15,3 miljoen rps, maar minder dan een jaar later zag het bedrijf er een van 71 miljoen.

Reacties (47)

[Anonymoussaurus]

Cloudflare heeft er ook een zeer uitgebreid achtergrondartikel over geschreven met dingen je moet weten als CISO: https://blog.cloudflare.c...-rapid-reset-ddos-attack/

Verder heeft AWS ook een blog: https://aws.amazon.com/bl...stomers-from-ddos-events/

[Xieoxer]

Inmiddels is er ook blog post beschikbaar van 1 van meest gebruikte webservers in de wereld: Nginx. Ik raad jullie aan om deze blogpost te bekijken, omdat hier tips worden gegeven hoe je eventueel kan oplossen.

https://www.nginx.com/blo...acting-f5-nginx-products/

[Reactie gewijzigd door Xieoxer op 23 juli 2024 14:12]

[Stoepie1]

Een vraag. Ik heb er niet zoveel verstand van, maar hoe kan Google wel zo'n aanval afslaan en bijvoorbeeld een Nederlandse bank of andere instelling niet?

[Strebor]

Google heeft bijna oneindig veel meer servers, datacenters en eigen verbindingen tussen die datacenters ter beschikking, verspreid over heel de wereld. Ze hebben dus veel meer vermogen en controle. Nederlandse banken hebben dat niet. Ik neem aan dat Google meerdere NOCs (network operation centres) heeft die network performance continu monitoren en hele teams heeft die erg snel en efficient in kunnen grijpen. Bijvoorbeeld door een datacenter uit te schakelen en toch alle DDOS verkeer daar aan te laten komen (of juist niet).

Dat gezegd hebbende, wanneer was de laatste keer dat een DDOS aanval een Nederlandse bank omver kreeg? Die hebben meestal last van andere storingen, niet van buitenaf geforceerd met bruut geweld.

[Reactie gewijzigd door Strebor op 23 juli 2024 14:12]

[Keypunchie]

Dat gezegd hebbende, wanneer was de laatste keer dat een DDOS aanval een Nederlandse bank omver kreeg? Die hebben meestal last van andere storingen, niet van buitenaf geforceerd met bruut geweld.

2018: nieuws: Rabobank-diensten zijn onbereikbaar door ddos

Dit was overigens niet de aanval die eerder dat jaar plaatsvond, waar Tweakers ook werd aangevallen. Die DDoSser heeft overigens wel de prijs moeten betalen:
nieuws: Ddos'er die fiscus, banken en Tweakers aanviel, krijgt 200 uur taakstraf

[Reactie gewijzigd door Keypunchie op 23 juli 2024 14:12]

[flippy]

"de prijs", als in een maandje schoffelen in een park.

[Keypunchie]

Hoofdzakelijk omdat het OM hem 4 jaar lang heeft laten bungelen.

Dat is overigens voor de meeste mensen, die geen geharde crimineel zijn, ook echt geen pretje.

Dat heeft de rechter meegewogen.

[jmxd]

194 dagen jeugddetentie (180 voorwaardelijk, -14 dagen voorarrest), 200 uur werken, een strafblad, en een proces wat 4 jaar geduurd heeft. Prima straf voor een jonge jongen. Of zat je aan de doodstraf te denken?

[Vlizzjeffrey]

Beter dan 4 jaar cel dan dan zeker weten dat die er als een grotere crimineel uitkomt.

[Aldy]

Dat kan, maar als hij een baan heeft, dan weet ik niet wat de impact daarop is. Of 25 weken lang één dag in de week vrij nemen. Of een achterstand in je studie oplopen. In ieder geval geen VOG meer kunnen halen. Daarnaast zijn het vaak opscheppertjes en 1. daardoor lopen ze vaak tegen de lamp en 2. taakstraf is niet iets om over op te scheppen, gevangenisstraf wel.
Als ik overigens over een DDoS-aanval lees, denk ik altijd: en een lol dat we hadden. (cynisch bedoeld)

[Houtenklaas]

De productiesystemen van banken onderling hangen niet aan het internet. Vervelend als de "customer facing" er uit ligt zoals @Keypunchie meldt, maar dat is alleen maar buitengewoon vervelend en niet meer dan dat. Google heeft inderdaad heel veel meer uitwijkopties dan welk NL bedrijf dan ook ...

[TijsZonderH]

Nederlandse banken zitten tegenwoordig achter de NaWas van NBIP, een samenwerkingsverband van providers en dienstverleners die het mogelijk maakt om ddos-aanvallen op te vangen. Daarom zijn er de afgelopen jaren steeds minder grootschalige ddos-aanvallen geweest op banken of andere belangrijke diensten die ook echt schade opleverden.

[sdsnatcher73]

De aanvallen zijn er misschien nog steeds wel, maar ze hebben niet het beoogde effect meer.

[The Realone]

Waardoor het effectief geen DDoS meer is.

[Aldy]

Daarom zijn er de afgelopen jaren steeds minder grootschalige ddos-aanvallen geweest op banken of andere belangrijke diensten die ook echt schade opleverden.

Heb je het afgeklopt?

[Stemis]

Het 'verweren' van een DDOS, betekent dat je ook de capaciteit moet hebben om dit te detecteren en te verweren. Een lokale instelling heeft niet de resources om al dit verkeer af te handelen. Je hebt ookal gauw een network constraint, als je maar een beperkte hoeveelheid bandwith hebt, is je lijn zo vol; dat nieuw legitiem verkeer ook niet meer erdoor komt

Daarom schalen partijen zich vaak achter de grotere partijen zoals Cloudflare, AWS, Azure middels proxies. Zo kan een kleine partij toch profiteren van DDOS protectie zonder zelf de infrastructuur te hebben om aanvallen van een bepaalde grote af te slaan.

Een kleine instelling kan het dus ook, mits ze zich verschuilen achter een grotere partij met een grote capaciteit OF genoeg infra en bandwith hebben om het zelf te doen.

[kristofv]

Eender wie kan zich in feite hiervoor "indekken" tegenwoordig, door third party diensten af te nemen zoals bijvoorbeeld cloudflare of akamai

Dat zijn bedrijven die zich als het ware tussen jou zelf en de rest van het wereldwijde web plaatsen , zij zijn de portier aan de deur van je spreekwoordelijke huis . Als er abnormaal vaak gebeld wordt (wat een ddos in feite is in mensentaal) dan grijpt cloudflare voor je in en neemt het de gepaste maatregelen.
Die bedrijven hebben dan ook enorme wereldwijde infrastructuur die speciaal ontworpen is om dit soort aanvallen te kunnen afslaan.

Banken etc hebben daar de nodige expertise veelal niet in en gebruiken meestal gewoon cloudflare of akamai of equivalenten. Voor google zou dat onzinnig zijn, meer dan genoeg kennis in huis en hun infra is er ook al , ze hebben gewoon een wereldwijd fiber netwerk.

[Marve79]

Nederlandse banken zijn verplicht hun data en verkeer via Nederland te laten verlopen. Google kan een DDoS aanval wereldwijd mitigeren. Dus een zombie pc in Japan die een aanval doet wordt daar lokaal al gefilterd door het Google datacenter in Japan (of pop, point of presence). Terwijl als je maar een enkel DC hebt zoals de banken vaak heb je een choking point met beperkte bandbreedte. Zie het als een trechter.

[aikebah]

Terwijl als je maar een enkel DC hebt zoals de banken vaak

Reken er maar op dat iedere bank onder toezicht van DNB er minstens 2 zal hebben (primary en uitwijk DC)

[Frame164]

Maar nog steeds (op globaal niveau gezien) vrijwel geen georedundancy. Ja, als er een vliegtuig op een DC valt is de andere nog heel. Maar qua routeringsopties zoals global spelers dat hebben is het vrijwel dezelfde locatie.

[Terrestrial]

Google heeft hier helemaal niks mee te maken, wie zegt dat alle verkeer via google datacenters loopt?

[Hieronymuski]

Nederlandse banken zijn verplicht hun data en verkeer via Nederland te laten verlopen.

Waar basseer je dit op? Het verkeer van ING verloopt via Akamai.

Edit: ABN Amro en Rabobank ook.

nieuws: 'Afhankelijkheid banken van Akamai is twijfelachtig' - update

[Reactie gewijzigd door Hieronymuski op 23 juli 2024 14:12]

[Marve79]

Dat vind ik verrassend. Dwz dat Akamai al het verkeer kan decrypten en toegang krijgt tot jouw bankgegevens.

[Hieronymuski]

Decrypten doen ze sowieso, om het verkeer te kunnen inspecten.

Ze zullen vast niet actief de bankgegevens bekijken enzo, maar is inderdaad wel een dingetje dat 't in theorie mogelijk is.

[Kuuntje]

Die uitleg krijg ik ook graag!

[janjwjmc]

Heeft met infrastructuur te maken.

[sympa]

Een Nederlandse bank heeft de TLS-certificaten niet op bijvoorbeeld Cloudflare staan.
Dus moet hun eigen infrastructuur dat opvangen.
Het is een beetje een keus tussen schaalbaarheid en uptime aan de ene kant, versus privacy en informatieveiligheid aan de andere kant.

[Hieronymuski]

ING draait op Akamai.

[dez11de]

Welke bank of instelling heeft zo'n aanval nog niet af kunnen slaan?

[Mushroomician]

Ik heb vast niet zoveel verstand van maar 398.000.000 req/sec lijkt mij eigenlijk niet zoveel.
Als een programma op 1 machine 65536 source poorten kan inzetten met hetzelfde aantal sockets dan kan het met multithreading over 8 cores ofzo wel minstens 800 * 65536 = 52.428.800 requesten doen per seconde. 989.000.000 ÷ 52.428.800 ≈ 18 machines dus met “maar” 100 requesten per core per seconde per poort. Wat doe ik fout?

[Douweegbertje]

Meerdere zaken. Ten eerste, al is een request 30kb, dat keer 1 miljoen is al 30 GBps. Je komt daar nog net mee weg maar 40GB/s is vaak wel de limiet. Met uitzondering van veel duurdere nodes.
Vervolgens is heel het idee van een DDoS dat je zo goedkoop mogelijk, het de server zo duur mogelijk maakt.
Dus dat kan zijn: grote payloads die versterkt worden, "dure" connecties, de server laten wachten, etc

Een server heeft sowieso overhead m.b.t retries, SSL, etc. Het kan best zijn dat die requests lekker 'hangen' en dat je per QPS het tienvoudige 'open' hebt staan aan sockets.

Verder doe je een berekening in een soort van ideale sandbox situatie. In de realiteit loop je tegen veel meer limitaties aan. Dat is op technisch low level gebied (servers, kernel) maar net zo goed bij vendors als AWS of welke cloud dan ook.

Referentie; ik werk zelf ergens waar we omgaan met die hoeveelheden aan requests

[Robin92]

Ik verwacht dat de bandbreedte van het netwerk van 1 machine niet toereikend is om zoveel sockets te openen (gezien het feit dat dergelijke apparaten vaak IoT devices zijn). Zelf heb ik voor de applicaties die ik bouw load tests moeten doen en ik had echt een max capacity, waar ik vrij snel aan zat. Ook al opende ik meer http/2 connecties.

[4tro]

De uitdaging voor de ddoser zit erin om het gedistribueerd te doen zodat ze niet simpelweg jouw paar ip's naar de blackhole routeren.

[dez11de]

Hoe komt je aan die 800? En waar haal je vandaan dat een machine 65536 requesten per seconde kan doen?

[dlatch]

Om het artikel van Cloudflare te quoten:

It was not long however, before they started to reach record breaking sizes — and eventually peaked just above 201 million requests per second. This was nearly 3x bigger than our previous biggest attack on record.

Concerning is the fact that the attacker was able to generate such an attack with a botnet of merely 20,000 machines. There are botnets today that are made up of hundreds of thousands or millions of machines. Given that the entire web typically sees only between 1–3 billion requests per second, it's not inconceivable that using this method could focus an entire web’s worth of requests on a small number of targets.

Die 398 miljoen requests per seconde staat dus al gelijk aan meer dan 10% van het hele gemiddelde internet verkeer.

[n00bs]

Zit dit probleem ook nog in HTTP/3?

[sympa]

Dit lijkt me oplosbaar in HTTP/2 door het aantal requests te beperken.

[mvdklip]

Het punt met deze aanval is nou juist dat de (al bestaande) limiet op het aantal gelijktijdige requests niet geldt voor het gebruikte scenario. Je kan de limiet als server beheerder instellen maar deze heeft helaas geen effect op dit specifiek type aanval.

[sympa]

Het aantal requests binnen 1 TCP-verbinding kan je dus wel beperken. Maar het blijft lastig, er is toch een factor bij gekomen.

[Mellow Jack]

HTTP3 lijkt dermate anders dat dit specifieke probleem er niet in zit. Het zal vast weer andere issues introduceren. Vond iets als dit wel leuk om te lezen:

https://www.smashingmagaz.../http3-core-concepts-part

Het overstappen naar UDP zal zelfs hele andere, implementatie afhankelijke situaties opleveren

[Beerik]

Ik vind het netjes! Volgens mij zit je dan wel even met spanning te kijken als beheerder

[Luchtbakker]

Ik vraag me altijd af wat hackers denken te behalen met het aanvallen van zulke gigantische bedrijven als Google. Google heeft zo ontiegelijk veel bandbreedte beschikbaar, en een heel leger aan netwerk specialisten. Daar kan je toch met geen enkel botnet tegenop?

[Frame164]

Dat is dan toch de uitdaging lijkt me? Een klein DC aanvallen is niet spannend meer. Google onderuit halen wel.

[the_stickie]

Deze ddos werd verwezenlijkt met 'slechts' 20000 botnet-clients en heeft wel degelijk korte tijd enige impact gehad (ref)
Een simpele (korte) request kost een server meestal heel wat meer resources dan de client. De crux van een geslaagde aanval is de amplification uit te buiten ie de server (veel) meer werk geven dan je client heeft met het uitsturen van verzoeken.

[Marve79]

Het is een beetje proberen he, de uitdaging denk ik. Verder inderdaad vrij kansloos. Ik weet ook uit ervaring dat je na één zo'n aanval de helft van je botnet vaak al kwijt bent. Dus na zo'n aanval moet je weer helemaal opnieuw opbouwen.

En wat bereik je ermee, je houdt die aanval misschien een paar uur vol. Om iemand echt pijn te doen moet je dat constant dag in dag uit volhouden. Of toch op de meest slechte momenten voor zo'n site. Dat is echt een dagtaak.

Maargoed, genoeg mensen blijkbaar met teveel tijd.

[CivLord]

Publiciteit, bragging-rights en een natte onderbroek.