Een snelweg met te veel auto's
Voordat je een snelweg aanlegt, bepaal je hoeveel rijstroken er moeten komen. Je houdt rekening met de auto's die je verwacht, plus een marge voor de spits. Reken je op 100 auto's per minuut? Dan leg je een tweebaansweg aan. Reken je op 10.000? Dan worden het er behoorlijk wat meer.
En dan rijden er ineens een miljoen auto's tegelijk je weg op. Geen file - de weg slibt compleet dicht. Wie netjes naar zijn werk wilde, staat stil naast iemand die uit Vladivostok is komen rijden om jouw rijbaan te bezetten.
Als die auto's er thuishoren - omdat je een bedrijventerrein hebt aangelegd of een vakantiepark - dan moet je je weg uitbreiden. Capaciteitsplanning. Maar wat als die auto's er níet thuishoren? Je weet niet waar ze vandaan komen, en ze zijn alle anderen tot last?
Welkom bij DDoS.
Wat er onder de motorkap gebeurt
Elk netwerk heeft een bepaalde throughput: het aantal gigabits per seconde dat er gelijktijdig doorheen kan. Voor een relatief klein netwerk kan dat bijvoorbeeld zo'n 150 Mbit/s zijn. Voor een internetknooppunt, waar het verkeer van veel netwerken samenkomt, ligt dat ettelijke ordes hoger. AMS-IX piekte ooit op 15 Tbit/s.
Bij een DDoS-aanval wordt er meer verkeer naar het netwerk gestuurd dan het aankan. Het netwerk gaat effectief plat: de verkeersstroom slibt dicht, en niemand komt er nog bij. Hoe absurd dat verkeer kan worden? GitHub kreeg in 2018 een aanval van 1,35 Tbit/s over zich heen. AWS in 2020 een van 2,3 Tbit/s. Cloudflare meldt elk kwartaal nieuwe records.
Niet één soort DDoS, maar twee
DDoS-aanvallen komen in twee smaken, en het verschil is groot genoeg om er even bij stil te staan.
Volumetrisch (L3/L4). Dit is de snelweg-variant uit het begin van dit artikel. Heel veel verkeer, simpel van inhoud, bedoeld om je netwerk over te laten lopen. Denk aan SYN-floods, UDP-floods en DNS-amplification - technieken met namen die er minder toe doen dan het effect: je netwerk loopt vol.
Applicatieniveau (L7). Een ander beestje. Hier gaat het niet om bandbreedte, maar om dure verzoeken. Stel: je inlogformulier kost achter de schermen 200 ms aan database-werk. Een aanvaller die 10.000 keer per seconde "log in als admin" probeert - met legitiem ogende verzoeken vanaf wisselende IP's - legt je applicatie plat zonder dat er ook maar één gigabit voorbijkomt. Op de bandbreedte-meter zie je weinig, op de server staat alles in de fik. L7-verkeer ziet er op het oog precies hetzelfde uit als dat van een echte bezoeker, en daarom zijn deze aanvallen vaak lastiger te detecteren en filteren dan volumetrische.
Beide soorten zijn DDoS, beide zijn distributed, maar de tegenmaatregelen verschillen. Een netwerk-beschermlaag die alleen op bandbreedte filtert, mist een L7-aanval compleet. En een applicatie die alleen het aantal verzoeken per bezoeker beperkt, helpt niets tegen een netwerk-flood van 250 Gbit/s. Wie zich serieus tegen DDoS wapent, doet beide.
"Kun je de aanval niet gewoon blokkeren?"
Logische vraag. Het korte antwoord: nee. Het lange antwoord zit in de eerste D van DDoS, die staat voor 'distributed'.
Het malafide verkeer komt vanaf duizenden, soms miljoenen locaties tegelijk. Meestal vanaf gehackte apparaten in allerlei landen: routers, IP-camera's, slimme koelkasten, slecht beveiligde Linux-servers. Samen vormen ze één digitaal leger, die allemaal worden ingezet om een bepaald doel aan te vallen.
Daardoor werkt het simpele plan "kijken waar de aanval vandaan komt en het bron-IP blokkeren" niet. Het verkeer komt vanaf zoveel IP's dat je niet één deur kunt dichttrekken. Je moet een patroon zien te ontwaren - iets gemeenschappelijks waarop je het legitieme van het illegitieme verkeer kunt scheiden. Hoe ingewikkelder de aanval, hoe lastiger dat patroon te vinden is - en bij L7 is dat patroon soms bijna onvindbaar.
De enige echte oplossing: kaf van koren scheiden
Er is precies één manier om een DDoS af te wenden: het 'nette' verkeer scheiden van het 'vuile' verkeer, en dat laatste blokkeren. Dat heet 'scrubbing'.
Algoritmes proberen automatisch te bepalen welk verkeer wel door mag, en welke niet. Bij complexere aanvallen is het vaak ook nodig om handmatig de verkeersstroom in de gaten te houden en filters bij te bouwen. Achter de schermen wordt daar tijdens een aanval vrijwel non-stop aan gewerkt: elk nieuw filter scheidt het vuil net iets preciezer van het schone.
Een onvermijdelijk neveneffect: ook verkeer van soms legitieme bezoekers wordt geblokkeerd, omdat geen enkel filter 100% accuraat is. Hoe vaak dat gebeurt, hangt af van hoe ingewikkeld de aanval is.
Twee manieren om te scrubben
Wie gaat dat scrubben doen? Er zijn twee opties.
Doe het zelf - als je netwerk voldoende throughput heeft. Voor kleinere aanvallen is dat prima haalbaar, en er zit geen onnodige tussenstop in je verkeer van een anti-DDoS-provider.
Of routeer het verkeer door een anti-DDoS-provider - zo'n provider heeft veel meer throughput dan jij ooit zou kunnen aanleggen. Bijvoorbeeld Cloudflare beschikt over 500 Tbps, een gigantische hoeveelheid. Een aanval starten die dát overbelast, kost een veelvoud aan tijd en geld vergeleken met een kleine aanval. Niet onmogelijk - met de juiste middelen kan alles - maar de drempel ligt vele ordes hoger.
Vrijwel elke organisatie die DDoS-bescherming niet als kernactiviteit heeft, kiest voor optie 2 zodra de aanval haar eigen netwerk te boven gaat. Zelf een netwerk aanleggen van het kaliber Cloudflare is voor één bedrijf simpelweg onhaalbaar - en dan nog ben je niet 'foolproof'. Sommige aanvallen zijn zo absurd groot dat geen enkele capaciteitsinschatting vooraf voldoet. Geen schande, gewoon een gegeven van het internet: TransIP - de grootste hoster van Nederland - schreef het in 2021 in zo veel woorden zelf op, in een opvallend openhartige postmortem: "the amount of traffic during this attack is larger than our network can handle."
Drie factoren bepalen wat je merkt
Hoe lang het scheiden van schoon en vuil verkeer duurt, en wat 'echte' bezoekers daarvan merken, hangt af van drie dingen:
- Complexiteit. Is het patroon makkelijk te herkennen, of doen de aanvallers hun best om eruit te zien als gewone bezoekers? Je moet het goede en slechte verkeer ergens op kunnen onderscheiden.
- Duur. Een aanval van vijf minuten is iets anders dan een aanval van een week.
- Intensiteit. Praten we over 1 Gbit/s, of over 250 Gbit/s?
"Waarom dan niet áltijd via die anti-DDoS-provider?"
Een terechte vervolgvraag: "Waarom laat je niet continu al je verkeer langs de anti-DDoS-provider lopen? Dan ben je altijd klaar voor een aanval."
Dat heet 'online' scrubbing: je verkeer staat altijd onder die veiligheidsparaplu. Het klinkt logisch, maar heeft drie serieuze nadelen.
- Afhankelijkheid. Wat als jij geen probleem hebt, maar de anti-DDoS-provider wel? Je eigen netwerk werkt prima, maar bezoekers komen er niet, want het verkeer kan niet door de paraplu heen.
- Verlies van legitiem verkeer. Een deel van je echte bezoekers wordt áltijd tegengehouden, ook als er geen aanval is. Scrubbingfilters zijn nooit 100% accuraat - en die schade boek je dan in voor verkeer dat helemaal niemand kwaad wilde doen.
- Garanties bestaan niet. Elke DDoS-aanval is anders. Ook met een paraplu boven je hoofd moet er bij elke nieuwe aanval opnieuw worden gefilterd - en zolang die filters niet staan, voelen je bezoekers de impact alsnog. Zelfs Microsoft liep daar tegenaan: bij een grote Azure-storing verergerde hun eigen DDoS-bescherming de impact door een fout in de implementatie, waardoor de aanval acht uur duurde. 'Online' staan betekent dus niet dat je nergens meer iets van merkt.
Hoe effectief scrubbing ook is tegen grote aanvallen - wanneer er geen aanval gaande is, schiet je met een kanon op een mug. Als je een aanval of het reguliere verkeer zelf kunt afhandelen, is het beter om dat ook te doen.
Daarom kiezen wij voor 'offline' scrubbing. Bij een DDoS kijken we eerst hoe groot de aanval is. Kunnen we hem zelf aan, dan handelen we hem zelf af. Wordt hij te groot voor onze eigen throughput, dan schakelen we de anti-DDoS-provider in. Die gaat dan scrubben en zo nodig bouwen we zelf filters bij.
Wat wij doen
We monitoren ons netwerk dag en nacht op DDoS-aanvallen. DDoS is bijna dagelijkse kost voor ons - en bepaald geen probleem dat alleen wij hebben. Zelfs een dienst als DigiD heeft er structureel last van; beheerder Logius gaf openlijk aan een nieuwe aanpak nodig te hebben. Maar onze klanten merken er zelden iets van. Wat er onder de motorkap gebeurt, verschilt per laag.
Op L3 (volumetrisch) handelen we de meeste aanvallen zelf af. Voor de aanvallen die we zelf niet aankunnen, hebben we contracten lopen met anti-DDoS-providers die we op elk moment kunnen inschakelen. Daarbij geldt het verhaal hierboven: omdat we voor 'offline' scrubbing kiezen, is er bij zo'n echt grote aanval altijd enige overlast totdat het verkeer is omgeleid, en de scrubber zover is dat het goed van slecht verkeer kan onderscheiden. Hoe lang dit duurt, hagnt af van de complexiteit van de aanval.
Op L7 (applicatieniveau) passen we een breed scala aan defensiemechanismen toe, zoals 'tarpitting'. We bieden ook bescherming tegen 'slowloris'-aanvallen, waarbij iemand heel langzaam verbindingen openhoudt om je server langzaam vol te zetten. En we blokkeren IP's die op bekende abuse-blacklists staan - vanaf die adressen komt vrijwel uitsluitend rommel.
Daarnaast experimenteren we met een paar nog intelligenter WAF (Web Application Firewall)-oplossingen, zoals Blackwall en Anubis. De overlast van bots - van kwaadwillende botnets tot AI-scrapers die in een nacht je hele site leegtrekken - wordt steeds groter, en het oude IP-blacklist-werk schiet daar steeds vaker tekort. Nieuwe tooling kijkt veel beter naar gedrag dan naar herkomst, en daar zit de toekomst van L7-bescherming.
Een fundamentele zwakte, geen geheim
De overlast van een DDoS-aanval honderd procent voorkomen is technisch onmogelijk. Wel beloven we dat we er tijdens een aanval met onze neus bovenop zitten, transparant communiceren over wat er aan de hand is, en elke aanval gebruiken om de volgende beter af te slaan.
Het internet is ooit gebouwd op de aanname dat we elkaar volledig vertrouwen. Iedereen mag iedereen aanspreken. Dat is de kracht van het internet, en tegelijk de fundamentele zwakte.
Tot iemand het hele internet herontwerpt - en daar staat niemand voor in de rij - blijft het werken met wat we hebben: slim monitoren, snel filteren, en weten welke knoppen je op welk moment moet indrukken.
← Terug naar Insights