DDoS-bescherming: verdediging in lagen

Een DDoS-aanval steelt geen gegevens. Hij zorgt dat je dienst onbereikbaar wordt, en dat lukt door de hulpbron uit te putten die het eerst op is: je bandbreedte, je verbindingstabel, je processor of je databaseconnecties.

Daarom is het eerlijke antwoord op de vraag hoe je je tegen zo'n aanval beschermt geen los product en geen enkele firewallregel. Verschillende aanvallen putten verschillende hulpbronnen uit, en elke laag dekt een ander faalpad af. Hieronder staan de lagen in de volgorde waarin ze een aanval daadwerkelijk afstoppen, gevolgd door een draaiboek voor het moment dat het al misgaat. Ligt je site er nu uit, sla dan direct door naar dat draaiboek verderop.

Wat een DDoS-aanval precies uitput

Aanvalsfamilie	Voorbeelden	Wat het vult	Waar je het moet stoppen
Volumetrisch	UDP-floods, DNS- en NTP-amplificatie, carpet bombing	je netwerklink	upstream, bij je hoster of een scrubbingnetwerk
Protocol en toestand	SYN-floods, ACK-floods, verbindingsfloods	verbindingstabellen op servers, firewalls en loadbalancers	limieten aan de rand, kernel-tuning en SYN-cookies
Applicatielaag (L7)	HTTP-floods, cache-busting, slowloris, API-misbruik	processor, workers, databaseverbindingen	CDN en WAF, caching, limieten per route

De praktische consequentie is ongemakkelijk: is de aanval groter dan je uplink, dan maakt niets wat je op de server instelt nog uit. De pakketten hebben dan al gewonnen voordat een lokale firewallregel ze ziet. Volumetrische bescherming moet dus upstream staan. De rest kun je zelf harden, en daar gaan de volgende acht lagen over.

Laag 1: mitigatie boven je origin

Elke serieuze verdediging begint met capaciteit die niet van jou is. Een scrubbingnetwerk of anycast-netwerk spreidt aanvalsverkeer over tientallen locaties, filtert het en stuurt alleen schone verzoeken door naar je server.

Zet je publieke verkeer achter een CDN of reverse proxy met DDoS-mitigatie inbegrepen (Cloudflare, AWS CloudFront met Shield, Azure Front Door, Gcore, Bunny, Fastly).
Vraag je hoster welke mitigatiecapaciteit voor je IP staat en of die altijd aanwezig is of pas aanslaat bij detectie. Bescherming op aanvraag laat precies op het moment dat de aanval begint een gat vallen.
Geef anycast de voorkeur: dat verdeelt volumetrische golven geografisch in plaats van één datacenter te vragen alles te absorberen.

De klassieke fout is denken dat een CDN op zichzelf genoeg is. Het is laag één van negen.

Laag 2: het echte IP van je server afschermen

Dit is de stap die de meeste teams overslaan, en die laag één geruisloos ongedaan maakt. Komt een aanvaller achter het werkelijke IP-adres van je server, dan omzeilt hij de CDN en slaat hij rechtstreeks toe. Die techniek heet direct-to-origin.

Waar origin-IP's weglekken:

DNS-archieven met oude A-records van vóór de verhuizing achter de proxy.
Certificaattransparantielogs met TLS-certificaten die voor de origin-hostnaam zijn uitgegeven.
Subdomeinen zoals mail., vpn., ftp. en dev. die naar dezelfde server wijzen.
E-mailheaders, waarin uitgaande mail het origin-IP in Received:-regels kan meesturen.
Oude records zoals MX-, SPF- en TXT-vermeldingen die naar infrastructuur buiten de CDN verwijzen.

Wat je doet: roteer het origin-IP nadat de CDN live staat, sluit de origin af met een firewall zodat alleen de gepubliceerde IP-reeksen van de CDN poorten 80 en 443 bereiken, en controleer je eigen exposure elk kwartaal opnieuw.

Laag 3: een WAF voor laag 7

Een netwerkfirewall ziet een geldige TCP-verbinding en laat hem door. Een WAF leest het HTTP-verzoek, en daar zit de schade van de applicatielaag: misvormde verzoeken, exploitpogingen en botgolven op login- en zoekroutes.

Zet eerst de beheerde regelsets aan, de OWASP-kernregels plus de threat intelligence van je leverancier. Voeg daarna gerichte eigen regels toe: weiger te grote bodies op uploadroutes, daag verzoeken naar beheerpaden uit en limiteer per endpoint in plaats van per site. Een WAF die alleen standaardregels draait, vangt bekende patronen en mist wat er voor jouw applicatie specifiek misgaat.

Laag 4: snelheidslimieten op elk niveau

Snelheidslimieten zijn de goedkoopste maatregel die je hebt, en tegelijk de meest verkeerd geconfigureerde. Regels die alleen op de webserver staan, doen niets tegen verkeer dat het netwerk al verzadigt. Regels die alleen op IP-adres letten, raken een botnet met duizenden bronadressen nauwelijks.

Leg je limieten daarom in lagen:

Rand: verzoeken per IP, per ASN en waar zinvol per land.
Applicatie: per sessie, per API-sleutel en per ingelogde gebruiker.
Per endpoint: strakke limieten op login, wachtwoordherstel, zoeken en afrekenen, de dure routes waar aanvallers op mikken.

Gebruik token-bucket- of sliding-window-limieten in plaats van harde caps per seconde, en geef een 429 terug met een Retry-After-header, zodat nette clients rustiger aan doen in plaats van agressief te herhalen.

Laag 5: de TCP-stack harden

Een SYN-flood vult de verbindingstabel al voordat er één HTTP-verzoek binnenkomt. De oplossingen zijn oud, saai en effectief:

Zet SYN-cookies aan.
Verhoog de listen-backlog en stem somaxconn en tcp_max_syn_backlog af op je werkelijke gelijktijdigheid.
Verkort tcp_fin_timeout en verlaag keepalive-tijden op loadbalancers.
Beperk het aantal gelijktijdige verbindingen per bron aan de rand.

Test elke wijziging onder belasting: waarden overnemen zonder je eigen nulmeting maakt het vaak erger.

Laag 6: caching laten werken

Een verzoek dat uit de cache komt, bereikt je origin nooit en kost dus geen worker en geen databaseverbinding. Alles wat statisch kan zijn, moet statisch zijn: afbeeldingen, CSS, JavaScript en HTML voor anonieme bezoekers.

Twee details doen ertoe tijdens een aanval:

Cache-busting is een aanvalstechniek. Willekeurige querystrings dwingen elk verzoek door naar de origin. Stel je CDN zo in dat irrelevante queryparameters op cachebare routes worden genegeerd.
De cache-hitratio is een beveiligingscijfer. Zakt hij tijdens een incident van 85 naar 20 procent, dan betaal je origincapaciteit voor aanvalsverkeer in plaats van voor bezoekers.

Laag 7: een nulmeting en alarmering op afwijking

Je kunt je niet verdedigen tegen wat je niet ziet. Leg vóór een aanval vast hoe normaal eruitziet: verzoeken per seconde, bytes in en uit, het aandeel 4xx en 5xx, p95-latentie, verbindingsaantallen en de meest gevraagde URL's.

Alarmeer vervolgens op afwijking, niet op absolute drempels. Een piek van vijf keer het normale aantal verzoeken bij een stabiel foutpercentage is vaak een marketingresultaat. Een vlak verkeersbeeld met oplopende latentie en groeiende verbindingstabellen wijst op uitputting van toestand. NetFlow- of IPFIX-data naast je applicatielogs geeft je beide beelden naast elkaar.

Wie hier structureel naar kijkt, herkent een aanval in minuten in plaats van uren. Die houding lijkt op wat onderzoekers doen wanneer er nog geen alert is afgegaan; de methodiek staat in wat threat hunting in cyberbeveiliging is.

Laag 8: het herstelplan schrijven vóór je het nodig hebt

Onder aanval is het slechtste moment om te bepalen wie de hoster belt, wie klanten informeert en wie de noodmodus mag aanzetten. Schrijf een draaiboek van één pagina:

Wie verklaart een incident en waar dat wordt gemeld.
Wie contact opneemt met de hoster of CDN-support, met accountnummers erbij.
Welke maatregelen in welke volgorde aangaan, en wie ze mag aanzetten.
Wie met klanten communiceert en wat de eerste verklaring letterlijk zegt.
Wanneer juridische stappen of aangifte aan de orde zijn, zeker bij afpersing.

Oefen dat draaiboek één keer per kwartaal met een tabletopoefening. Een draaiboek dat niemand heeft gelezen, is decoratie.

Bij afpersing komt de juridische kant erbij. Een pure beschikbaarheidsaanval is meestal geen datalek, dus de meldplicht van 72 uur bij de Autoriteit Persoonsgegevens gaat pas lopen zodra blijkt dat er persoonsgegevens zijn buitgemaakt of gewijzigd. Computervredebreuk valt daarnaast onder artikel 138ab van het Wetboek van Strafrecht. Bewaar daarom logs, pakketopnames en tijdstempels: je provider, je verzekeraar en een eventuele aangifte vragen er alle drie om.

Laag 9: capaciteit inkopen met een contract

Voor bedrijven waar downtime direct omzet kost, hoort mitigatiecapaciteit contractueel geregeld te zijn: een scrubbing-SLA, een afgesproken drempel, vaste escalatiecontacten en een supportniveau dat tijdens een aanval daadwerkelijk opneemt.

Gratis of goedkope tiers zijn uitstekend voor kleine sites en slecht voor bedrijven die duizenden euro's per uur verliezen. Stem de tier af op de werkelijke kosten van een storing, niet op de prijs per maand.

Als je nu onder aanval ligt

Werk in deze volgorde, van minst naar meest ingrijpend:

Stel vast dat het een aanval is. Kijk naar bronnen, verzoekpatronen, populairste URL's en geografie. Vergelijk met een legitieme campagne voordat je iets blokkeert.
Bepaal de laag. Verzadigde bandbreedte wijst upstream, uitputting van verbindingstabellen wijst op L3/L4, en processor en latentie op specifieke routes wijzen op L7.
Open meteen een ticket bij je provider. Upstream mitigatie kost tijd om te activeren; begin daarmee voordat je diagnose af is.
Zet je randmaatregelen aan. Noodmodus, beheerde WAF-regels, strakkere limieten en een JS-challenge op de zwaarst misbruikte routes.
Bescherm de origin. Controleer dat de origin alleen verkeer van de CDN accepteert en blokkeer verzoeken die rechtstreeks op het IP binnenkomen.
Communiceer. Statuspagina eerst, supportkanalen daarna. Stilte richt meer schade aan dan de aanval zelf.
Bewaar bewijs. Logs, pakketopnames en tijdstempels zijn nodig voor je provider, voor je verzekering en voor juridische opvolging.

Bij afpersing, een betalingseis om te stoppen, ga je niet op de voorwaarden van de aanvaller in. Ons incidentresponsteam werkt tijdens een lopende aanval samen met je hoster en pakt daarna de hardening aan.

Checklist van tien minuten

Publiek verkeer loopt via een CDN of scrubbingsdienst met DDoS-mitigatie.
Het origin-IP is geroteerd, met een firewall beperkt tot de IP-reeksen van de provider en niet vindbaar via DNS-historie of certificaatlogs.
De WAF staat aan met beheerde regels plus eigen regels voor beheer- en loginpaden.
Er zijn limieten aan de rand, in de applicatie en op dure endpoints.
SYN-cookies staan aan en verbindingslimieten zijn afgestemd op een gemeten nulmeting.
Statische bestanden en anonieme HTML worden gecachet met een hoge hitratio.
Dashboards en alerts dekken verkeer, bandbreedte, foutpercentage, latentie en verbindingen.
Er bestaat een actueel draaiboek van één pagina met benoemde eigenaren.
Het contract met hoster of CDN noemt mitigatiecapaciteit en supportreactietijd.
Iemand heeft deze lijst in het laatste kwartaal doorlopen.

Elk vakje dat je open laat, is een gat dat een aanval als eerste vindt.

Wat DDoS-bescherming kost

Grove indeling, van meest naar minst toegankelijk:

Optie	Gangbare kosten	Geschikt voor
Gratis of pro-tier van een CDN (Cloudflare, Bunny)	0 tot 25 dollar per maand	blogs, kleine bedrijfssites, SaaS met laag risico
Bescherming van de cloudprovider (AWS Shield Standard)	inbegrepen bij de infrastructuur	workloads die al op die cloud draaien
Beheerde WAF plus DDoS (Gcore, Imperva, AWS Shield Advanced)	ongeveer 55 tot 3.000+ dollar per maand	omzetkritische applicaties, compliance-eisen
Dedicated scrubbing (Akamai, Radware, Link11, Myra)	enterprisecontracten, vaak 5.000+ dollar per maand	hoogwaardige doelwitten, gaming, financiën

Het bedrag dat ertoe doet is niet de abonnementsprijs, maar de kosten van een uur downtime, vermenigvuldigd met hoe vaak je verwacht doelwit te zijn. Voor de meeste kleine bedrijven is een goed geconfigureerde gratis of lage tier met een geoefend draaiboek eerlijker gezegd beter dan een duur apparaat dat niemand kan bedienen.

Fouten die sites onnodig offline houden

De IP-reeksen van de CDN zelf blokkeren. Het lijkt tijdens een aanval een efficiënte maatregel en haalt je hele site onderuit.
Alleen op IP limiteren. Botnets roteren bronadressen; stuur ook op gedrag.
De homepage beschermen en de API niet. Aanvallers zoeken de dure route op.
L3/L4 helemaal negeren. Een SYN-flood verschijnt nooit in je HTTP-logs.
Geen origin-bescherming. De CDN absorbeert de golf terwijl de aanvaller het echte IP blijft beuken.
Een ongetest draaiboek. Onder druk doet een team standaard eerst de verkeerde handeling.

Veelgestelde vragen

Kun je een DDoS-aanval volledig voorkomen?

Nee. Iedereen kan verkeer naar een publieke dienst sturen. Het realistische doel is dat verkeer opvangen en filteren terwijl legitieme gebruikers online blijven, en dat is precies wat verdediging in lagen doet.

Is een CDN genoeg om een DDoS-aanval te stoppen?

Een CDN vangt volumetrische golven en veel misbruik op de applicatielaag af, maar lost geen origin-exposure op, geen misbruik van dure endpoints en geen uitputting van toestand. Het is één laag van negen.

Hoe onderscheid je een aanval van een gewone verkeerspiek?

Kijk naar samenstelling, niet naar volume. Een piek uit één regio of vanaf één URL, met afwijkende user-agents, oplopende latentie en een vlakke conversieratio is een aanval. Een piek die netjes over je normale bronnen is verdeeld, is meestal een campagne die werkt.

Wat moet een klein bedrijf eerst doen?

Verkeer achter een CDN met mitigatie zetten, het origin-IP afschermen, beheerde WAF-regels aanzetten en het draaiboek van één pagina schrijven. Die volgorde dekt de meest voorkomende aanvallen voor het minste geld.

Heb je een gespecialiseerde DDoS-provider nodig?

Alleen als downtime meer kost dan het contract. Begin met de CDN-tier, meet je werkelijke exposure en stap over wanneer de rekensom klopt.

Waar je verder leest

Verdediging in lagen is vooral configuratiehygiëne: een upstream-laag met capaciteit, een origin die niemand kan vinden, verzoekmaatregelen die bij je applicatie passen en een draaiboek dat het team echt heeft geoefend.

Wie wil weten hoe vaak dit soort incidenten voorkomt en welke kant het op gaat, vindt de cijfers in de staat van cyberbeveiliging in 2026. Leeft daarnaast het vermoeden dat er al langer iets mis is, dan helpen de signalen uit de tien tekenen dat je bedrijf is gecompromitteerd om te bepalen wanneer een onderzoek zinvol is.