DDoS-aanvallen uitgelegd: veelvoorkomende vormen en hoe je je ertegen beschermt

Eerst het antwoord: geen enkele laag stopt een DDoS-aanval

Een distributed denial-of-service-aanval is een poging om een resource waar je van afhankelijk bent (je bandbreedte, de connectietabel van je server, of het vermogen van je applicatie om verzoeken te beantwoorden) uit te putten met verkeer van veel bronnen tegelijk. Het nuttigste om te begrijpen is dat verschillende aanvalsvormen verschillende resources uitputten, en dat een verdediging die tegen de ene familie werkt niets doet tegen de andere:

• Volumetrische aanvallen vullen je netwerkverbinding. Zodra je uplink verzadigd is, maakt het niet meer uit wat je op de server configureert; het verkeer moet upstream worden geabsorbeerd of gedropt, door de mitigatie van je hostingprovider of een scrubbing-service.
• Protocolaanvallen (state-exhaustion) vullen de connectie-trackingtabellen van servers, firewalls en load balancers. Deze bestrijd je met SYN cookies, verstandige timeouts en rate limits, deels op de server zelf, deels aan de edge.
• Aanvallen op applicatieniveau putten je applicatie zelf uit met verzoeken die er legitiem uitzien. Hiervoor heb je Layer 7-verdediging nodig: caching, rate limiting, een WAF of CDN, en het hardenen van de applicatie.

Effectieve bescherming is dus gelaagd: scrubbing op providerniveau voor volume, edge- en kernelinstellingen voor state, en maatregelen op applicatieniveau voor Layer 7, plus een firewallbasis die je aanvalsoppervlak sowieso al verkleint. De rest van dit artikel behandelt elke familie in detail en zet de lagen daarna in elkaar tot een praktische verdediging.

De drie families van DDoS-aanvallen

Securityleveranciers classificeren DDoS-aanvallen op tientallen manieren, maar vrijwel alles wat je in de praktijk tegenkomt valt in drie families, onderscheiden door de resource die ze uitputten.

Volumetrische aanvallen: de verbinding vollopen

Het doel is brute kracht: meer verkeer versturen dan je lijn aankan. De meest voorkomende vorm is een simpele UDP flood (zinloze datagrams op line rate), die volgens de telemetrie van Cloudflare eind 2025 bovenaan de lijst van network-layer vectoren stond, met een groei van 231% kwartaal-op-kwartaal.

De interessantere variant is de reflectie-/amplificatieaanval. De aanvaller stuurt kleine verzoeken naar open internetdiensten (DNS-resolvers, NTP-servers, blootgestelde memcached-instances) met het bronadres gespoofed naar dat van jouw server. Die diensten "antwoorden" vervolgens aan jou, en bij het juiste verzoek is dat antwoord vele malen groter dan de vraag. De klassieke amplificatiefactoren uit CISA's advisory over UDP-based amplificatie laten zien waarom aanvallers deze techniek zo graag gebruiken:

Bij memcached kan één megabit aan upstream-verkeer van de aanvaller uitgroeien tot tientallen gigabits die bij jouw adres aankomen. Reflectie-aanvallen zijn ook de reden waarom het verkeer dat je tijdens een aanval vastlegt vaak afkomstig lijkt van poort 53, 123, 389 of 11211; de reflectors zijn legitieme servers die antwoorden op wat zij denken dat jouw vragen zijn. (Onze aanvullende gids over het analyseren van een DDoS-aanval met Wireshark laat zien hoe je deze signatures herkent in een capture.)

Een nieuwer volumetrisch patroon dat het kennen waard is, is carpet bombing: in plaats van zich op één IP te richten, spreidt de aanvaller gematigde volumes uit over een heel subnet of over duizenden bestemmingspoorten, waarbij hij onder de per-IP-detectiedrempels blijft terwijl de totale capaciteit toch verzadigd raakt. NETSCOUT telde in de tweede helft van 2025 750 tot 830 carpet-bombing-aanvallen per dag.

Hoe groot kunnen volumetrische aanvallen worden? Het publieke record is in een verbazingwekkend tempo opgelopen: van 3.8 Tbps eind 2024, via een aanval van 7.3 Tbps in juni 2025, tot een aanval van 31.4 Tbps en 14.1 miljard pakketten per seconde in december 2025, aangedreven door van Mirai afstammende IoT-botnets (Aisuru en zijn afsplitsingen), opgebouwd uit gehackte routers, camera's en Android TV-boxen. Dat zijn records tegen de grootste mitigatienetwerken ter wereld, geen alledaagse gebeurtenissen, maar zelfs een onopvallende flood van meerdere gigabits overschrijdt de uplink van de meeste individuele servers, en dat is precies het punt van de "upstream eerst"-regel uit de volgende sectie.

Protocolaanvallen: de connectiestatus uitputten

In plaats van pure bandbreedte richten deze aanvallen zich op de statustabellen die servers, firewalls en load balancers voor elke connectie bijhouden.

De klassieker is de SYN flood. Door de TCP-handshake wijst de server state toe zodra een SYN binnenkomt, terwijl hij wacht op de finale ACK die nooit komt. Genoeg half-open connecties en de listen queue zit vol: legitieme clients kunnen niet meer verbinden, terwijl bandbreedte en CPU verder prima zijn. SYN floods staan nog altijd in de top drie van network-layer vectoren in de data van Cloudflare, decennia nadat ze voor het eerst beschreven werden; ze zijn goedkoop, effectief en makkelijk te genereren met gespoofde bronnen.

De standaardverdediging, SYN cookies, codeert de connectiestatus in het sequence number van de SYN-ACK zelf, zodat de server niets toewijst voordat de handshake voltooid is. Linux zet dit standaard aan (net.ipv4.tcp_syncookies = 1) en dat moet ook aan blijven staan voor elke server die met het internet verbonden is.

Verwante vormen in deze familie zijn ACK/RST floods (rommelpakketten die conntrack-lookups afdwingen), fragmentatieaanvallen (onvolledige fragmenten die reassembly-buffers bezet houden), en connectiefloods die de handshake voltooien en dan inactief blijven staan om slots te bezetten. Let op: een stateful firewall (inclusief de conntrack-gebaseerde regels op je eigen server) is zelf ook een statustabel waarop een aanvaller kan mikken, wat een van de redenen is waarom firewallregels voor servers met veel blootstelling bewust bepaald verkeer niet tracken. Onze gids met standaard firewallregels laat zien waar die afweging ligt.

Aanvallen op applicatieniveau: verzoeken die er legitiem uitzien

Layer 7-aanvallen slaan de leidingen over en putten de applicatie zelf uit: HTTP request floods gericht op dure endpoints, cache-busting (gerandomiseerde query strings die elk verzoek dwingen door te dringen tot de origin), slowloris-achtige aanvallen die connecties openhouden door headers één byte per keer te versturen, en trucs op protocolniveau zoals HTTP/2 Rapid Reset (CVE-2023-44487), dat stream-cancellation misbruikte om in 2023 honderden miljoenen requests per seconde te genereren voordat implementaties reset-rate-controls toevoegden.

Dit zijn de moeilijkste aanvallen om te filteren, omdat elk verzoek op zichzelf geldig is; de kwade opzet zit in het volume en de spreiding. Moderne HTTP floods komen overwegend van botnets en headless browsers die geloofwaardige TLS-fingerprints en user agents tonen. Mitigatie is dan ook applicatiebewust: agressieve caching zodat verzoeken nooit de origin bereiken, rate limits per client en per endpoint, een WAF of CDN die clients gedragsmatig scoort, en het goedkoop of afgeschermd maken van je dure endpoints (zoeken, inloggen, rapportages genereren).

Hoe vaak komt dit voor?

Vaak genoeg om het als operationele zekerheid te behandelen in plaats van als staartrisico. Cloudflare alleen al blokkeerde in 2025 47.1 miljoen DDoS-aanvallen, een stijging van 121% jaar-op-jaar, en NETSCOUT telde wereldwijd ruim 16 miljoen aanvallen over het hele jaar, waarvan meer dan de helft multivector was: combinaties van bovenstaande families die tegelijk werden ingezet.

Twee statistieken zijn het belangrijkst voor hoe je je verdediging plant:

• Aanvallen zijn kort. 89% van de network-layer-aanvallen en 71% van de HTTP-aanvallen eindigt binnen tien minuten; zelfs het record van 31.4 Tbps duurde 35 seconden. Een mitigatie die afhankelijk is van een mens die de aanval opmerkt, een ticket opent en scrubbing inschakelt, is regelmatig pas klaar met uitrollen nadat de aanval al voorbij is. Always-on geautomatiseerde mitigatie is nu de norm, niet on-demand scrubbing.
• Aanvallen zijn multivector. NETSCOUT constateerde dat ongeveer 42% van de aanvallen twee tot vijf vectoren gebruikte. Als je je tegen één familie verdedigt en de andere negeert, vertel je de aanvaller alleen maar op welke knop hij moet drukken.

De mitigatiestack, laag voor laag

Zie de verdediging als vier lagen, van het internet naar binnen toe. Elke laag stopt wat de lagen eronder niet kunnen.

Laag 1: upstream mitigatie (het enige antwoord op volume)

De onvermijdelijke natuurkunde: als de aanval groter is dan je verbinding, kan alleen iemand upstream van die verbinding hem stoppen. Een server op een poort van 10 Gbit/s kan zich niet wegfirewallen uit een flood van 50 Gbit/s; de pakketten hebben al gewonnen tegen de tijd dat ze de interface bereiken waar je regels op draaien.

Upstream verdedigingen werken doordat ze meer capaciteit en een beter uitzichtpunt hebben dan welke individuele server dan ook:

• Anycast-absorptie en scrubbing, de aanpak van grote mitigatienetwerken en DDoS-beschermde hosts: aanvalsverkeer wordt aangetrokken naar de dichtstbijzijnde van vele locaties, dungespreid, gefilterd, en alleen schoon verkeer wordt afgeleverd. Zo zijn de multi-terabit-records geabsorbeerd, autonoom en zonder menselijk ingrijpen.
• RTBH (remotely triggered blackhole): een tool voor netwerkoperators die al het verkeer naar een doelprefix aan de rand van het netwerk dropt. Het beschermt de rest van het netwerk, maar maakt voor de geblackholede host het werk van de aanvaller af; in de moderne praktijk wordt het gebruikt als een botte eerste reactie, die daarna verfijnd wordt met BGP FlowSpec-regels die alleen de aanvalssignatuur (protocol, poorten, pakketgrootte) matchen en droppen in plaats van alles.

Als klant beheer je dit niet zelf; je kiest een host of mitigatieprovider die dat wel doet, en je controleert of de bescherming always-on is in plaats van reactief. Aangezien negen op de tien aanvallen binnen tien minuten voorbij zijn, zit in dat onderscheid het grootste deel van de waarde.

Laag 2: edge filtering en rate limiting

Tussen de upstream scrubber en je applicatie zitten verdedigingen die weinig kosten en het middendeel van het dreigingsmodel afzwakken:

• Network-ACL's / edge-firewallregels: als je server alleen HTTPS bedient, heeft verkeer naar UDP 11211 of TCP 23 daar niets te zoeken. Door niet-service-verkeer te droppen voordat het de conntrack van je server raakt, verwijder je complete aanvalsklassen. Een self-service network-edge firewall (die wij op onze dedicated servers leveren) doet dit filteren op het netwerk, upstream van je poort.
• Rate limiting per bron: limieten op nieuwe connecties per seconde per IP absorberen het lichtere deel van connectiefloods en brute-force-ruis. Bot maar effectief tegen ongeraffineerde aanvallen; niet effectief tegen breed gedistribueerde aanvallen, en dat is prima; daar zijn laag 1 en laag 4 voor.

Laag 3: de host zelf

Instellingen op de host zelf redden je niet van een volumetrische flood, maar ze bepalen hoe soepel je alles kleiner dan dat overleeft:

• SYN cookies aan (standaard bij Linux, controleren met sysctl net.ipv4.tcp_syncookies).
• Een default-deny firewallbasis zodat alleen je daadwerkelijke diensten verkeer accepteren; ons artikel over verstandige standaard firewallregels geeft een complete, geannoteerde ruleset, en als je nog moet kiezen met welke tooling je die schrijft, zie iptables vs nftables.
• Conntrack-sizing en timeouts: verhoog op drukke servers net.netfilter.nf_conntrack_max en verkort agressieve timeouts zodat rommelstatus snel verloopt, of sluit je high-volume serviceports helemaal uit van tracking.
• Geen onbedoelde reflectors. De keerzijde van de amplificatietabel hierboven: zorg dat jouw server niet degene is die amplificeert. Draai geen open resolver, schakel NTP monlist uit (opgelost in ntpd 4.2.7+, maar controleer alles wat ouder is), en stel memcached nooit via UDP bloot aan het internet.

Laag 4: verdediging op applicatieniveau

Voor HTTP floods en aanverwante aanvallen: zet een CDN of reverse proxy met caching voor je dynamische applicaties, rate-limit dure endpoints los van goedkope, houd HTTP/2-implementaties gepatcht (Rapid Reset en zijn opvolger uit 2025, „MadeYouReset", worden allebei afgezwakt door bijgewerkte servers), en ontwerp zo dat anonieme verzoeken standaard cachebaar zijn. Als je zelf een reverse proxy draait op een dedicated server, dekken limit_req en limit_conn van nginx een verrassend groot deel van het probleem.

Een aanval detecteren: de signalen

De meeste aanvallen kondigen zich aan als een plotselinge anomalie in precies één resource. De moeite van het monitoren (en alarmeren) waard:

• Bandbreedte: inkomend verkeer dat vastzit op je poortsnelheid is de volumetrische signatuur. Als je provider verkeer grafisch weergeeft van zowel vóór als na mitigatie, is het verschil de aanval.
• Packet rate: miljoenen kleine pakketten per seconde bij bescheiden bandbreedte wijst op packet-rate-aanvallen (SYN/ACK floods) in plaats van bandbreedte-aanvallen.
• Half-open connecties: ss -s dat synrecv-aantallen in de duizenden toont, betekent een SYN flood in volle gang.
• Applicatieverzadiging bij normale systeembelasting: worker pools vol, responstijden die pieken, maar netwerk en CPU onopvallend, de L7-signatuur.
• Bronpoortpatronen: inkomende floods vanaf poort 53/123/389/11211 betekenen dat je gereflecteerd verkeer ontvangt.

Wanneer je precies moet weten waarmee je te maken hebt (om een FlowSpec-achtig filter te schrijven of je provider bruikbare details te geven), leg dan een sample vast en analyseer die; dat is het onderwerp van onze gids voor DDoS-analyse met Wireshark.

Een incident-response-draaiboek

Als het zover is, telt de volgorde van handelen meer dan heldendom:

1. Bevestig dat het een aanval is, geen storing of een launch. Controleer of het verkeer afwijkend is qua aard (rare poorten, bronnen die er gespoofed uitzien, één URL die gebeukt wordt) en niet alleen qua volume.
2. Identificeer de vector: via het mitigatiedashboard van je provider of een pakketsample van 30 seconden. De familie bepaalt de reactie: volumetrisch → upstream; state → tunen en rate-limiten; L7 → cachen en filteren.
3. Zet de mitigatie in die je al hebt. Als de bescherming van je host always-on is, controleer dan of hij ingrijpt (grafieken van gescrubd verkeer); is iets self-service (edge-firewallregels, mitigatieprofielen), pas dan de regel toe die bij de vector past.
4. Verklein je oppervlak tijdens de aanval. Zet tijdelijk niet-essentiële listeners uit, schakel agressieve caching in, zet dure endpoints achter een challenge als je een WAF hebt.
5. Praat met je provider in specifieke termen. „SYN flood, ~4 Mpps, gespoofte bronnen, gericht op 203.0.113.10:443" levert veel sneller een bruikbare reactie op dan „we worden aangevallen".
6. Leg achteraf vast wat werkte. Aanvallen herhalen zich. Het filter dat deze keer werkte, moet een opgeslagen profiel worden, geen herinnering.

Veelgestelde vragen

Kan een firewall op mijn server een DDoS-aanval stoppen?

Sommige soorten wel, andere niet, en weten welke is het hele spel. Een firewall op de server dempt effectief kleine SYN floods, connectiefloods en rommelverkeer gericht op poorten die je niet gebruikt. Bij een volumetrische aanval die je uplink verzadigt, helpt hij niet: die pakketten hebben de kabel achter je firewall al gepasseerd, dus het filteren moet upstream gebeuren, bij de edge of scrubbing-laag van je provider.

Wat is het verschil tussen DoS en DDoS?

Een DoS-aanval komt van één bron; de extra D staat voor „verspreid" (distributed): veel bronnen tegelijk, tegenwoordig meestal een IoT-botnet of een vloot proxy's. Die spreiding maakt de aanvallen zowel groot (een botnet van een miljoen Android TV-boxen genereerde het huidige record van 31.4 Tbps) als lastig te filteren op bronadres, omdat er geen enkel adres is om te blokkeren; mitigatie moet in plaats daarvan aansluiten op de vorm van de aanval.

Hoe lang duren DDoS-aanvallen?

Korter dan de meeste mensen verwachten: ruwweg negen op de tien aanvallen op netwerkniveau eindigen binnen tien minuten, en zelfs recordaanvallen duurden minder dan een minuut. Die kortstondigheid is voor aanvallers een voordeel (korte uitbarstingen ontwijken on-demand mitigatie die minuten nodig heeft om in te grijpen), en het is waarom always-on bescherming „bel ons als het zover is"-scrubbing als best practice heeft verdrongen.

Heb ik DDoS-bescherming nodig voor een kleine site?

Ja, in de zin dat je moet kiezen voor infrastructuur waar bescherming standaard bij zit, in plaats van het later als noodgreep aan te schaffen. Kleine sites worden om weinig glorieuze redenen aangevallen: een ontevreden gebruiker met een $20-abonnement op een booterdienst, een concurrent, of gewoon een toevallige omstander in het verkeerde subnet bij een carpet-bombing-aanval. Omdat aanvallen goedkoop zijn om te lanceren en bescherming tegenwoordig door goede hosting-providers zonder meerkosten wordt meegeleverd, pleit de economische logica ervoor om het te hebben voordat je het nodig hebt.

Uitrollen op Serverside

Elke server op ons netwerk staat achter always-on DDoS-mitigatie; aanvallen worden automatisch gedetecteerd en gescrubd aan de rand van het netwerk, wat (zoals dit artikel hopelijk duidelijk heeft gemaakt) de enige plek is waar volumetrische aanvallen gestopt kunnen worden. Daarbovenop bevatten onze dedicated servers een self-service firewall aan de rand van het netwerk, zodat je niet-service-verkeer kunt droppen voordat het ooit je poort bereikt, plus self-service mitigatiebeheer om de bescherming af te stemmen op jouw workload. Provisioning duurt minder dan een minuut, op ons eigen ASN 55285-netwerk.

Voor de helft van de verdediging die op de host zelf draait, begin je met onze standaard firewallregels voor een Linux-server, kies je je tooling met iptables vs nftables, en leer je precies te identificeren wat je raakt met hoe je een DDoS-aanval vastlegt en analyseert in Wireshark. Zet je een nieuwe machine op, dan behandelt onze Linux-distributiegids de keuze van het basis-OS.