Cloudflare blokkeert nieuwe record-ddos-aanval van 22,2Tbit/s

Cloudflare zegt dat het opnieuw een ddos-aanval met een recordhoeveelheid verkeer heeft afgeslagen. Die piekte op 22,2Tbit/s, bijna drie keer zo hoog als een record eerder dit jaar. Het aantal van zulke grote aanvallen stijgt.

Cloudflare schrijft op X dat het de aanval eerder deze week detecteerde en dat de systemen hem automatisch afsloegen. Het bedrijf deelt daarover verder geen details, maar zegt dat de aanval zo'n veertig seconden duurde en gedurende die tijd piekte naar 22,2Tbit/s. De aanval bestond uit zo'n 10,6 miljard packets per seconde. Het is niet duidelijk wat voor soort packets dat waren, wie er mogelijk achter de aanval zat en wat voor apparaten daar mogelijk bij betrokken waren.

Ddos-aanvallen groeien de laatste jaren in aantal en omvang. Cloudflare meldt regelmatig nieuwe recordaanvallen, zoals een 5,6Tbit/s-aanval in januari en een 7,3Tbit/s-aanval in juni. Het bedrijf geeft daarbij regelmatig technische uitleg, maar doet dat nu niet.

Reacties (64)

[NoTechSupport]

Wordt er onderzoek gedaan naar welke IPs dit zijn? Ik vermoed toestellen die in een botnet zitten? Worden die geblokkeerd bij Cloudflare? Krijgen die IPs een melding volgende keer ze op een Cloudflare-website komen?

[gamezfreak]

Wordt er onderzoek gedaan naar welke IPs dit zijn? Ik vermoed toestellen die in een botnet zitten? Worden die geblokkeerd bij Cloudflare? Krijgen die IPs een melding volgende keer ze op een Cloudflare-website komen?

Het lastige is dat vaak de IP adressen gespoofed worden en je dus niet snel kan achterhalen wie erachter zit. Je kan a.d.h.v. IP blocks zien uit welk land het komt, maar dat brengt je niet veel informatie mee. Daarnaast kunnen botnets zo groot zijn als de pest, soms worden meerdere botnets aan elkaar gekoppeld voor meer (vuur)kracht achter een aanval. Naast de gebruikelijke landen, zie je soms ook bijv. Tuvalu of andere kleine eilanden voorbij komen. IP adressen blokkeren is niet altijd even makkelijk, gezien spoofing bij komt kijken.
Als tijdelijke maatregel kan je het wel inzetten, maar op lange termijn niet.

De botnets kunnen bestaan uit IoT devices, maar ook servers, PC's, laptops, smartphones en zelfs babymonitors, gezien de security op veel devices matig tot slecht is (standaard inloggegvens, nooit updates gedaan dan wel vanuit fabrikant).

Meestal als je een site iets te vaak achter elkaar bezoekt, krijg je een melding dat je tijdelijk geblokkeerd bent. Dit kan wel eens voorkomen als je een klapperende verbinding hebt en je browser meerdere TCP retransmissions doet, waarna de website je eventjes blokkeert. Of als je bijv. vanaf een grote domein een site probeert te benaderen.

[baseoa]

Bij amplification kun je niet spoofen wie de kwetsbare server heeft draaien. Zonder het juiste destination IP-adres komt de aanval niet aan, en de amplifiers antwoorden met het juiste source-adres

Als die servers worden afgesloten is het heel snel gegaan met dit soort recordaanvallen. In plaats daarvan serveren we het halve internet captcha's en laten we cloudflare alles meelezen—om te zien of het verkeer legitiem oogt, natuurlijk..!

[servicedb]

Ik kan niet aangeven of dit altijd zo is, maar wij hebben wel eens rapportages gehad mbt klanten die bijvoorbeeld de NTP server open hadden staan. Dankzij een zwakte in het UDP protocol kan je doen alsof de doelserver het verzoek aan de NTP server heeft gedaan. Ze hebben hier een uitgebreider artikel over: https://www.cloudflare.com/en-gb/learning/ddos/ntp-amplification-ddos-attack/

Het IP zelf was niet geblokkeerd door Cloudflare. In ieder geval niet lang, mogelijk was dit wel het geval tijdens de aanval zelf. Je bouwt uiteraard wel een reputatie op bij CloudFlare waardoor het aannemelijker is dat je een Ik ben geen robot scherm krijgt.

[Stetsed]

Dit is hetzelfde als een DNS Amplification attack, het gaat niet zozeer door een zwakte in het UDP protocol maar meer omdat je met minder data die jij verstuurd meer requests naar de uiteindelijke persoon stuurt.*

Bijvoorbeeld, jij spooft je IP naar 255.255.255.255, hiervan stuur je berichten naar een DNS/NTP server en vraagt "Hallo meneer, ik will deze data", het ding is het opvragen van die data kost misschien maar 100 bytes, terwijl de response misschien 500 bytes is. Dit betekent dat de eigenaar van 255.255.255.255 nou een bericht krijgt van 500 bytes.

Het is dus ook niet dat je vaker een "Ik ben geen robot scherm krijgt", er is een hogere kans dat je op het netwerk niveau geblokeerd wordt. Want NTP/DNS amplification maakt niet gebruik van dat jou server heel veel moet doen maar meer dat er gewoon zo veel data naartoe wordt gestuurd dat de server het niet aan kan. En de enige manier om die te blokkeren is om eerdere in de chain te blokkeren waar een grootere pijp zit, of waar de hoeveelheid data nog niet samen is gekomen om het probleem te veroorzaken bijvoorbeeld in de individuele POP's.

\* Je kan argumenteren dat dit well een zwakte is binnen het UDP protocol omdat het dit soort dingen toestaan, want het heeft geen handshake waardoor dit soort aanval niet mogelijk is. Maar om het een zwakte in UDP te noemen is ook weer niet helemaal waar want het heeft meer te doen met route validation en dat het mogelijk is om een request te voeren die helemaal niet door de uiteindelijke persoon gemaakt is. Er zijn hier dus ook well maatregelen voor die worden gemaakt, maar is meer fundamenteel

[Reactie gewijzigd door Stetsed op 24 september 2025 15:48]

[gpon]

Het valt mij op dat elke website tegenwoordig bij Cloudflare ondergebracht wordt. Zijn er soms geen gelijkwaardige (EU based) alternatieven meer?

[TD-er]

Op zich vind ik dit best wel een zeer goede vraag.
Ik zit namelijk met ons forum ook veel en veel te veel tijd te steken in het blokkeren van telkens weer een 'aanval' van een idioot AI scraper botnet wat met 100k+ hosts tegelijk alles platgooit, of weer een aanval via IP-spoofed requests.

Maar ik weiger (nog) meer afhankelijk te worden van een Amerikaans bedrijf.

Dus wat dat betreft hoor ik graag van goede alternatieven.

[The Zep Man]

Dus wat dat betreft hoor ik graag van goede alternatieven.

Je kan Anubis of iets soortgelijks implementeren. Schijnt succesvol te zijn. AI crawlers willen namelijk wel graag jouw website bezoeken, maar niet te veel CPU-cycles eraan besteden.

[TD-er]

Zoals ik al zei, die AI bots zijn zo prominent aanwezig, dat ze met gemak je server compleet onbereikbaar maken.

Ze komen makkelijk vanaf 100k+ unieke IP-adressen en gaan dan alles in veelvoud binnenhengelen.
Makkelijk met 5000 - 10000 tegelijkertijd en elk unieke IP haalt dan 1 a 2 pagina's op.
Het lijkt er sterk op dat ze dit doen om niet 'op te vallen', maar ondertussen leggen ze wel alles plat.

[StackMySwitchUp]

Ik kende Anubis ook niet maar het is (als ik het goed begrijp) een tool die a la cloudflare een pagina voor je hoofdpagina zet, en je browser een hash laat uitrekenen, dat kost jouw server niks en de browser een aantal cpu cycles, crawlers gaan daar compleet op kapot en stoppen met crawlen of worden zo gerate-limit dat het niet meer uitmaakt voor je webserver.

[Reactie gewijzigd door StackMySwitchUp op 24 september 2025 15:59]

[The Zep Man]

Zoals ik al zei, die AI bots zijn zo prominent aanwezig, dat ze met gemak je server compleet onbereikbaar maken.

Zoals ik al zei: kijk naar Anubis. Je bent niet de enige met dit probleem.

[Reactie gewijzigd door The Zep Man op 24 september 2025 14:53]

[iRobbery]

https://anubis.techaro.lol

"upstream request timeout"

Ze denken zeker dat ik ook een AI bot ben.

[Stetsed]

Ik draai nu all een tijdje Anubis en ik moet zeggen dat het goed werkt. Het was makelijker te implementeren en nu dat het ondersteuning heeft voor forwardauth is het nog makelijker want je kan het implementeren op de reverse proxy(Traefik/NGINX/Apache enz.). Dus als je problemen hebt dan zou ik dat zeker doen. Het stopt nog niet een bandwith aanval maar voor scrapers die echt 0 respect hebben voor robots.txt of gewoon een normaal schema(Ja OpenAI, me website is niet verandert in de laatste 10 seconden, voor de 100000de keer dit uur)

[jaenster]

Leuk die anubis maar beetje obscure browser en gekke geo ip (bij een relatief onbekende provider) en je site is totaal onbereikbaar. Ik snap dat dit soort dingen nodig zijn maar false positives zijn een no-go

[baseoa]

gekke geo ip (bij een relatief onbekende provider) en je site is totaal onbereikbaar.

Anubis doet geen filtering op IP-adres, laat staan op geoip te vertrouwen voor iets. Als je daarop geblokkeerd wordt, heeft de beheerder dat handmatig toegevoegd

Cloudflare is een provider die wel kijkt naar dit soort factoren (zover we weten; de magische saus is immers geheim en je mag niet te weten komen waarom ze de automatische beslissing over je nemen die ze nemen). Anubis is de tool waar je met een cpu en moderne browser altijd langskomt. Dat niet elke setup een moderne browser en redelijke cpu heeft, is een beperking, maar beter dan magische amerikaanse saus over alles gooien en geen idee hebben wie er meeleest of hoeveel mensen je blokkeert. Gezien veel mensen het nodig lijken te vinden, moedig ik Anubis daarom over het algemeen aan als minst-kwade optie. Zelf heb ik geen enkel filter op m'n server staan. Nergens voor nodig (het bezoekersvolume heeft me al kritisch doen kijken naar performance en rate limiting die op iedereen gelijk wordt toegepast, ook mijzelf), maar dat ligt natuurlijk ook aan geluk en wat voor doelwit je bent

[Reactie gewijzigd door baseoa op 25 september 2025 14:11]

[Stetsed]

Als je dat soort dingen niet wilt dan kan je gewoon zetten dat het nooit blokeert maar alleen maar een challenge geeft maar nooit direct blokeert.

[The Zep Man]

Iets als Anubis kan je ook makkelijk in een bestaande reverse proxy implementeren zonder extra software, zoals haphash voor HAProxy. Dat is kaal 132 bytes aan extra configuratie+code, wat niet het einde van de wereld is.

[DutchEZmoder]

Als je forum alleen voor Nederlandstaligen is dan kun je IP adressen blokkeren die van buiten NL en België komen. De meeste aanvallen kwamen bij mij vanuit de VS en China.

Mijn simpele site kreeg ook wel zo'n 100 aanvallen per dag, met ReCaptcha aan de achterkant, IP blok buiten NL en een ban na 2x verkeerd inloggen aan de achterkant heb ik dit weten terug te draaien naar 1 aanval om de dag.

[TD-er]

Nee mijn forum (ESPEasy forum) is voor een wereldwijd publiek en dat is dan ook het probleem, dat ik helaas hele subnetten heb moeten blokkeren, omdat er extreem veel botnet-achtige aanvallen kwamen uit bijv. Zuid-Amerika, Singapore, Vietnam etc.

[baseoa]

alleen voor Nederlandstaligen is dan kun je IP adressen blokkeren die van buiten NL en België komen.

Als Tweakers dat zou doen, zou ik Tweakers niet meer mogen gebruiken? Lekker is dat, medetweaker

Naast de Nederlanders die bijvoorbeeld nabij de grens wonen, vergeet je twee landen die Nederlands als officiële taal hebben. Lekker voor hun ook als jij ergens systeembeheerder bent en dit soort beslissing neemt of aanraadt

[Reactie gewijzigd door baseoa op 25 september 2025 14:14]

[DutchEZmoder]

Het was een idee, wat je ermee wilt doen en hoe je het wilt uitwerken moet je zelf weten.

[prakka]

Er is Bunny.net

[thePiett]

Wat zijn je ervaringen?

[NielsFL]

Bunny serveert vrolijk oude rommel, ondanks "max-age=0, must-revalidate, no-cache, no-store, private" headers. Je kan het vast ergens instellen, maar bij Cloudflare werken dat soort dingen gewoon meteen goed.

[gpon]

Bunny is slechts een reseller van het Britse Datacamp CDN. Goed voor media en grote bestanden maar niet echt als WAF.

[SilentDecode]

Heel eerlijk, ik was niet bekend met Bunny, maar de naam doet mij denken aan een gare pornosite...

[Hardfreak]

Ik tot kort ook niet.

Omdat AWS Cloudfront nogal DIY is voor image hosting zijn we op zoek gegaan naar een alternatieve CDN en daar kwam Bunny vrij goed uit. Binnenkort gaan we dus een testje doen met zowel Bunny als Cloudflare; beide zijn aanzienlijk goedkoper, hebben mogelijkheden voor image manipulation en zouden dus een goed alternatief zijn.

Het grootste probleem met Bunny is de 2 nine's SLA vs de 100% SLA van Cloudflare. Moeilijk te testen maar management ziet denk ik liever flat fee 100% uptime vs 1u downtime per jaar voor ongeveer dezelfde prijs.

[supersnathan94]

Omdat AWS Cloudfront nogal DIY is voor image hosting

? S3 bucket, uploaden en gas toch?

[jep]

Dat is niet de bedoeling, want Cloudflare is voor websites. Als je file hosting wilt doen moet je Bunny of Cloudfront pakken.

[supersnathan94]

cloudfront is geen hosting maar AWS CDN. Als je cloudfront gebruikt heb je cloudflare niet per se meer nodig.

S3 static serving met cloudfront werkt prima voor afbeeldingen. Wil je per se cloudflare dan kan dat ook, maar dan is het idd DIY.

AWS cloudfront en S3 zijn juist makkelijk in te regelen voor hosting en CDN.

[gpon]

Flare doet al jaren beide.

[orvintax]

In princiepe wel, bunny.net is denk ik een van de meer prominente EU spelers. Alleen we hebben in deze markt hetzelfde kip/ei probleem als bij cloud providers.

[iqcgubon]

Valt mij ook op. Iedereen maar roepen dat we weg moeten van Amerikaanse bedrijven maar 99% van het internet lijkt wel op Cloudflare te draaien.

[david-80]

Ik denk niet dat mijn Udm pro dit aantal kan verwerken mocht er een aanval poging worden uitgevoerd

[supersnathan94]

Ha, Ik weet niet welke provider jij hebt, maar ik weet 100% zeker dat die de hoop al opgegeven heeft voordat de eerste pakketten bij jouw UDM aankomen.

22 terabit/s is echt gigantisch veel. De huidige piek bij AMS-IX is ongeveer de helft daarvan: 12.596 Tb/s Peak in (vandaag)

[GrooV]

Het voordeel van Cloudflare is dat ze met Anycast werken en meer dan 330 locaties hebben. 1 locatie krijg dus nooit zo veel verkeer te verweken maar het wordt verspreid naar de dichtbij zijnde locatie van de aanvaller

[supersnathan94]

Dan nog. AMS-IX verwerkt ook verkeer voor het midden-oosten en Azië.

22 Tb/s is gewoon veel. echt veel.

[arjankoole]

Dat is vrij standaard BGP4 gedrag. Dat deden wij al voor een klant in 1999. Geografisch gescheiden, 1 PoP in NYC de andere in Amsterdam. Traffic uit de USA kwam in NYC terecht, de rest van de planeet (als ze niet toevallig directe verbindingen met de USA hadden en heul kort op NYC zaten) lande in Amsterdam.

Dat aspect van CF is standaard. Het indrukwekkende zit 'm in de hoeveelheid bandbreedte die ze kunnen aanpakken en de intelligentie van hun oplossingen qua detectie en response. ( die is heel erg snel ).

[Keypunchie]

Die geeft huilend de geest, terwijl de stoom uit de ethernetkabels spuit.

[lenwar]

Gelukkig is je ISP daar de beperkende factor in

[MennoGamed]

Haha, dat denk ik niet. Als je hiermee een Router bedoelt, dat ding gaat offline in nog geen seconden. Tenzij het zo is dat de ene router 57,14% meer traffic aankan dat heel AMS-IX

[supersnathan94]

Denk niet dat je de router überhaupt haalt. Je ISP trekt dit al niet.

[MennoGamed]

Haha dat zou me niet verbazen

[localhost]

Testje gisteren ging niet goed? Want toen was de bandbreedte op?https://status.enovationgroup.com/notices/jdnyldiiaycmkdij-landelijke-internetstoring

en ook deze gisteren op hetzelfde moment: https://gathering.tweakers.net/forum/list_message/83502724#83502724

[Reactie gewijzigd door localhost op 24 september 2025 14:28]

[jimmy87]

De NL-IX had een ander probleem, dat had hier niets mee te maken, dat was een multicast loop.

[BezurK]

Wat ik mij vooral afvraag bij dit soort aanvallen: waarom? Wat is de motivatie? Ik mag toch aannemen dat er een financiele motivatie achter zit, maar hoe dan precies?

Ik weet nog wel van DOS en DDOS aanvallen van vroeger dat het vooral om bragging rights ging. Gewoon tof om te doen: een online service offline halen. Geinig. Maar tegenwoordig, met dit soort aanvallen van buitenproportionele omvang, kost het wel zodanig veel geld en moeite dat ik me afvraag wat het ze oplevert?

[jurgen1976]

Diverse redenen, directe afpersing betaal x of we leggen je site plat. Concurrentie redenen site van een concurrent platleggen. Protest, personen of organisaties die het niet eens zijn met handelswijze van een bedrijf of land (Russische hackers vs wapen steun bijvoorbeeld) maar goed vul maar in...

Technische redenen voor bijvoorbeeld vervolg hack, zwakte in systemen vinden, failover faciliteiten on kaart brengen etc.

[nallath]

Ik heb het persoonlijk gezien dat ze een DDOS deden en dan ransom notes gingen sturen en dat ze beweerden dat je site plat ging vanwege een beveiligings lek (en dat ze het dus nog een keer kunnen).

Het was overduidelijk een ddos en ze liepen gewoon tegen cloudflare aan, maar ze probeerden het toch. Ik vermoed dat er voldoende mensen betalen om het de moeite waard te maken.

[arjankoole]

Wat ik mij vooral afvraag bij dit soort aanvallen: waarom? Wat is de motivatie? Ik mag toch aannemen dat er een financiele motivatie achter zit, maar hoe dan precies?

Kan een berg redenen hebben, inclusief terreur, al dan niet van een land. (rusland is er dol op, bijvoorbeeld).

maar als je een klant hebt die interessant is voor afpersers kan het ook een doelwit worden. Heb ik ook wel eens meegemaakt. Als je als bedrijf pegels en vertrouwen van je klanten dreigt te verliezen, dan is de verleiding er wel om te betalen. Daar spelen dat soort lui op in.

[iqcgubon]

Ik werk voor een multinational en je kan er gif op innemen dat op de dag dat ze de jaarcijfers publiceren dat er een DDOS aanval gaat plaatsvinden op de verschillende domeinnamen.

Management wordt daar ENORM zenuwachtig van want "de ruputatieschade!!!"

[Stetsed]

Ik moet zeggen dat ik dit soort berichten altijd well interessant vindt, ik heb zeker zin om de after-action te lezen die Cloudflare normaal maakt om te zien wat er werdt gebruikt. We hebben all eerder zulke gigantische DDoS's gezien maar dit is nog well een caliber hoger.

Dan is altijd natuurlijk de vraag hoe het komt. Want het kan zijn dat het gewoon een absolute mega botnet is, maar wat je ook ziet is dat het vaker komt door gebruik te maken van een vorm van amplification, bijvoorbeeld DNS amplification of NTP amplification.

Ik gebruik Cloudflare persoonlijk niet en draai mijn eigen infra omdat ik het ook leuk vindt om uit te vogelen en geen andere partij er tussen heb, maar als er een partij was die ik zou nemen zou het Cloudflare zijn want ze doen het well goed, en het is altijd interessant om te lezen wat ze publiceren.(All wens ik dat er een Europese Versie was, want zelfs Bunny is niet echt hetzelfde).

[Server.1968]

Ah, maak al jaren gebruik van Cloudflare voor mijn website, die daardoor veel responsiever is (wereldwijd, wat ook het publiek is). Kan me niet voorstellen dat mijn website interessant is voor ddos aaanvallen maar toch fijn te weten dat de server dankzij Cloudflare minder snel omvalt.

[MennoGamed]

Dat hangt er maar net vanaf op welk plan je zit. Op het "free" plan van Cloudflare is de Anti-DDoS zowat niet bestaand. Voor mensen met "Pro" world het al interessanter omdat je dan zelf de WAF kan instellen. Voor mensen met "Busniss" word het nog iets leuker, met een vleugje `machine learning`. Maar, ook daar moet je zelf nog veel instellen om het echte laten werken.

Pas vanaf CloudFlare Enterprise word het interessant, omdat CloudFlare dan opeens zelf actief gaat helpen. Zeker tegenover de SLA die ze op dat moment bieden. Maar dan betaal je, je ook 35x scheef, met een kosten die begint vanaf €3500/maand, en dat is dan alleen Layer 7 voor websites, nog geen eens Layer 3/4 voor je servers.

[topcat1602]

Zal niet van 1 telenet klant zijn met 20mb/s upload. 🙂 Laten ze het hierbij of worden er stappen ondernomen om te achterhalen wie dit initieert?

[MennoGamed]

Het is zowat onmogelijk om te achterhalen wie dit soort dingen doet. IP's komen vanuit een botnet vanuit over de hele wereld vanuit gehackte apparaten, en zelfs als ze iet gehackt zijn worden de IP's gespoofed. Spoofen houd dan weer in dat de IP's gefaked worden, zelfde als een fake ID.

Hoewel er maar 1 iemand nodig is die een commandje ergens op deze heeft hoeven uit te voeren, is de kans om die persoon te vinden bijna nul.

[AW_Bos]

Met wat hoop lopen ze ooit een keer tegen de lamp bij een andere illegale digitale actie, en komt het bewijs voor de aanval wel boven water.

Hoogmoed komt voor de val, zeggen we dan maar.

[baseoa]

Dat is anders wel hoe we het internet schoonhouden. Als je de verzenders van schadelijk verkeer niet blokkeert, is het niet verwonderlijk dat de computers geïnfecteerd blijven en de aanvallen doorgaan

Toen ik bij XS4ALL zat, werd onze verbinding een keer geblokkeerd op basis van een abuse-klacht. Ik heb dat grapje niet nog eens uitgehaald. De abuse-e-mailadressen zijn geautomatiseerd op te halen middels bijvoorbeeld whois, dus je kan die geautomatiseerd versturen op basis van DoS-verkeer. Als andere providers die e-mails negeren, is de volgende stap simpelweg de provider dicht te zetten tot ze hun netwerk wel schoon willen houden

Of je geeft iedereen overal ter wereld captcha's zoals we nu doen, dat is natuurlijk ook leuk

[Reactie gewijzigd door baseoa op 25 september 2025 14:29]

[MennoGamed]

Echter, het steeds blokkeren van adressen gaat uiteindelijk niks oplossen. Bij ontzettend veel instanties (en dan zeker datacenters) kan je gewoon een nieuw IP aanvragen. Steker nog, met gehuurde hardware zoals bijv. Hetzner of OVH koop je gewoon een nieuwe server en ga je weer door. Als het IP vervolgens bij iemand anders komt, is die persoon opeens geblokkeerd. Voor IPv6 is dit nog niet het grootste probleem, maar met IPv4 (aangezien dat op is) wel.

captcha's is voor nu nog wel lachen (/s), maar ook daar gaat een limiet op komen. Zeker met hoe snel AI zich door ontwikkeld gaan captcha's vanzelf omzeilt worden.

[baseoa]

Juist daarom is het toch de oplossing? Wat je zegt: blokkades zijn vervelend, adressen zijn al tekort, captcha's zijn geen eindoplossing. Dan is de provider toch gemotiveerd om diens adresruimte schoon te houden?

Uiteraard moet je wel de provider in kennis stellen van de abuse, anders kunnen die ook niks. Als een provider het goed oppakt zou een tijdelijke blokkade alleen nodig zijn in het geval van directe schade, zoals bij een DoS-aanval, maar bijvoorbeeld niet bij spam

[MennoGamed]

Zeker, en bedoel ook niet te zeggen dat het niet aan de provider (ISP) is. Ik bedoel echt te zeggen dat het een probleem zou zijn als andere, buiten ISP om, IP's gaan blokkeren. Zeker dus met IPv4, aangezien dat steeds meer "shared" is.

Als ISP's er netjes mee omgaan, en de persoon zelf aanpakken i.p.v. het IP zelf, dikke prima. Maar dat lijkt nog lastig

[et36s]

Wat is nu het nut van zo'n aanval. 22TB aan data dat lijkt me geen script kiddie die ergens een ddos tool op het darkweb heeftt gevonden.

[protected22]

Dit is tegelijkertijd zorgwekkend maar best indrukwekkend. Al helemaal om te bedenken dat de vorige ongeveer 3 maanden geleden was en nu meer dan 3x de max-piek van toen was. Ik vind het ook wel interessant om te lezen wat cloudflare doet tijdens of na zo'n aanval en hoe ze hem zo goed kunnen afweren. Vooral omdat de max-piek steeds hoger wordt.