Wat is een DDoS-aanval? Techniek, niveaus en afweer

Een DDoS-aanval is de poging om een dienst onbereikbaar te maken door kunstmatig overbelasting te veroorzaken, gelijktijdig uitgevoerd vanaf zeer veel verschillende afzenders. De afkorting staat voor Distributed Denial of Service, dus voor een gedistribueerd veroorzaakte dienstweigering. Aangevallen wordt daarbij niet de inhoud van een server en ook geen veiligheidslek in zijn software, maar een bron die eindig is: de bandbreedte van de lijn, de pakketsnelheid van de netwerkkaart, een plaats in een toestandstabel van de kernel of de rekentijd die de applicatie aan één enkele aanvraag besteedt. Is een van deze vier bronnen bezet, dan komen echte gebruikers er niet meer doorheen, en dat zonder dat iemand in het systeem is ingebroken.

Dit artikel is de inleiding op het onderwerp. Het legt uit op welke drie niveaus aanvallen plaatsvinden, met welke versterkingsfactoren uit één byte aanvraag 51.000 byte antwoord wordt, waar de aanvalscapaciteit vandaan komt en wat zij op de markt kost, waaraan u een aanval aan uw eigen meetwaarden herkent, wat op de server zelf nog helpt en waar die grens precies loopt. Alle getallen zijn met bron benoemd, zodat u ze kunt natrekken. Ligt uw dienst op dit moment stil, lees dan eerst de paragraaf "Wat u bij een aanval moet doen, in deze volgorde" en meet in plaats van te schroeven.

Wat een DDoS-aanval technisch is

Elke DDoS-aanval leeft van een asymmetrie: een pakket versturen moet de aanvaller minder kosten dan het het doel kost om dat pakket te verwerken. Al het overige is alleen de vraag op welke plaats die asymmetrie het grootst is. Er zijn precies vier plaatsen, en elk daarvan heeft een harde bovengrens die uit te rekenen is.

De bandbreedte van de lijn. Een aansluiting van 1 Gbit/s vervoert 125 megabyte per seconde, meer niet. Wie meer stuurt, veroorzaakt verlies, en dat verlies raakt de pakketten van uw gebruikers net zo hard als die van de aanvaller, omdat een volle aansluiting niet kiest.

De pakketsnelheid. Het kleinste toegestane ethernetpakket is 64 byte lang en bezet met preambule en pakketpauze 84 byte op de lijn. In 1 Gbit/s passen daarvan ongeveer 1,49 miljoen per seconde. Een gewone serverkernel verwerkt afhankelijk van CPU en netwerkkaart enkele honderdduizenden, voordat hij begint te verwerpen. De pakketsnelheid is daarom bijna altijd de grens die eerder wordt bereikt dan de bandbreedte.

De toestandstabellen. De kernel houdt halfopen TCP-verbindingen en pakketstromen bij. Die tabellen zijn in aantal begrensd, niet in bit per seconde. Zij laten zich met heel weinig bandbreedte vullen wanneer elk pakket een nieuw afzenderadres draagt.

De rekentijd van de applicatie. Een zoekopdracht, een aanmeldpoging met wachtwoordcontrole of een serveropvraging die een volledige modlijst teruggeeft, kost het doel duizend keer meer dan de afzender. Hier heeft een werkzame aanval vaak nog geen 10 Mbit/s nodig.

DoS en DDoS: het verschil dat u kunt meten

De begripsmatige grondslag levert RFC 4732, "Internet Denial-of-Service Considerations", een informationele publicatie van de IETF van november 2006. Daar staat letterlijk: "A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work." Een DoS-aanval is dus via het effect gedefinieerd, niet via het aantal bronnen. Gedistribueerd, dus DDoS, is hij wanneer die bronnen talrijk en onderling onafhankelijk zijn.

Praktisch telt het verschil op precies één plaats: bij de lengte van uw blokkeerlijst. Een DoS-aanval uit één bron beëindigt u met één regel. Cloudflare heeft in mei 2025 een aanval gedocumenteerd die uit 122.145 verschillende bronadressen uit 161 landen en 5.433 autonome systemen kwam, gemiddeld 26.855 nieuwe adressen per seconde, in de piek 45.097. Tegen zoiets bestaat geen blokkeerlijst die snel genoeg groeit, en elke vermelding daarin kost bovendien geheugen en zoektijd op het apparaat dat toch al overbelast is.

De gezamenlijke leidraad "Understanding and Responding to Distributed Denial-of-Service Attacks" van CISA, FBI en MS-ISAC verdeelt aanvallen in precies drie technieken: volumetrisch, protocolgericht en applicatiegericht. Die driedeling is de nuttigste die er is, omdat zij tegelijk beschrijft welke van uw vier bronnen wordt aangevallen en waar de afweer moet zitten.

De drie niveaus van een DDoS-aanval

Volumetrische aanvallen op layer 3 en 4

Een volumetrische aanval wil niets anders dan de lijn vóór het doel vullen. Gemeten wordt in bit per seconde. Het middel is in de regel een UDP-flood, omdat UDP geen verbindingsopbouw kent die men zou kunnen eisen, en omdat afzenderadressen zich laten vervalsen.

Het momenteel grootste openbaar gedocumenteerde voorbeeld: Cloudflare meldt voor de periode tot eind 2025 een automatisch afgeweerde aanval van 31,4 Tbit/s die 35 seconden duurde. Dat is de capaciteit van ongeveer 31.400 serveraansluitingen van 1 Gbit/s, gelijktijdig, voor een goede halve minuut. In hetzelfde rapport staat een tweede waarde die de orde van grootte beter grijpbaar maakt dan de piekwaarde: in 2025 heeft dezelfde beheerder 47,1 miljoen DDoS-aanvallen afgeweerd, een plus van 121 procent ten opzichte van het jaar ervoor, gemiddeld 5.376 aanvallen per uur.

Het beter gedocumenteerde geval van mei 2025 laat zien hoe zo'n aanval eruitziet wanneer u hem ontleedt: 7,3 Tbit/s in de piek, 37,4 terabyte gegevens in 45 seconden, dat is gemiddeld ongeveer 830 gigabyte per seconde. Een lijn van 1 Gbit/s had voor dezelfde hoeveelheid gegevens ruim drie dagen nodig gehad. 99,996 procent van het verkeer bestond uit zuivere UDP-floods, verdeeld over gemiddeld 21.925 doelpoorten gelijktijdig, in de piek 34.517. Die verdeling over alle poorten is typisch: de aanvaller weet niet welke poort belangrijk is, dus neemt hij ze allemaal.

Protocolaanvallen: de tabellen, niet de lijn

Een protocolaanval maakt gebruik van het feit dat de kernel toestanden moet bijhouden. Het standaardvoorbeeld is de SYN-flood: de aanvaller stuurt TCP-pakketten met gezet SYN-bit en vervalst afzenderadres, de server legt voor elk daarvan een vermelding aan in zijn wachtrij voor halfopen verbindingen, antwoordt met SYN-ACK naar een adres dat nooit heeft geantwoord, en wacht. Gemeten wordt hier in pakketten per seconde, niet in gigabit.

De lengte van die wachtrij staat in net.ipv4.tcp_max_syn_backlog en ligt op een gewone server in het viercijferige bereik. Een wachtrij met 1.024 plaatsen is bij 1,49 miljoen SYN-pakketten per seconde in minder dan een milliseconde vol. Daarvoor volstaat puur rekenkundig 1 Gbit/s, en wanneer alleen de tabel het doel is, volstaat een fractie daarvan.

Tot dezelfde familie hoort een methode die pas in 2021 is beschreven: de TCP-reflectie via toestandsgebonden tussenapparaten. Het werk "Weaponizing Middleboxes for TCP Reflected Amplification" laat zien dat firewalls en censuurinfrastructuur die de TCP-toestand maar half meevolgen, op één enkel vervalst pakket met hele pagina's antwoord reageren. Daarmee laat zich voor het eerst ook TCP voor versterking misbruiken, wat tot dan toe als praktisch onmogelijk gold.

Applicatieaanvallen op layer 7

Een applicatieaanval ziet eruit als gewoon verkeer, omdat het gewoon verkeer is, alleen in de verkeerde hoeveelheid. Gemeten wordt in aanvragen per seconde. Hij komt over een volledig opgebouwde verbinding en overleeft dus elke controle die alleen de verbindingsopbouw beoordeelt, en hij heeft weinig bandbreedte nodig: 10.000 HTTP-aanvragen per seconde zijn afhankelijk van de aanvraaggrootte minder dan 50 Mbit/s en toch genoeg om een database op de knieën te krijgen.

De maatstaf daarvoor heet HTTP/2 Rapid Reset, op 10 oktober 2023 openbaar gemaakt als CVE-2023-44487. De zwakte zit in het multiplexvermogen van HTTP/2: de aanvaller opent een datastroom, stuurt de aanvraag en breekt de stroom onmiddellijk weer af. De server is al aan het werk begonnen, de aanvaller heeft echter direct weer een vrije plaats in het venster. De daarmee behaalde waarden lagen op 201 miljoen aanvragen per seconde (Cloudflare), 398 miljoen (Google) en 155 miljoen (Amazon). Ter vergelijking: de tot dan hoogste door Cloudflare gemeten layer 7-aanval lag op 71 miljoen aanvragen per seconde.

Bij gameservers is het layer 7-niveau de verbindingsopbouw zelf. Nullping, QuietException en fake handshake-floods tegen Minecraft-netwerken hebben bijna geen bandbreedte nodig en leggen hele proxyverbanden lam, omdat elk pakket de proxy tot een dure toestandsbeslissing dwingt. Hoe die patronen er precies uitzien, staat in Minecraft-DDoS-bescherming en nullping-bescherming.

De drie niveaus naast elkaar

Echte aanvallen houden zich niet aan die indeling. Het in de praktijk onaangenaamste geval is de aanval in meerdere lagen: een volumetrisch deel dat de lijn bezighoudt, plus een layer 7-deel dat doorkomt op het moment dat de aandacht bij de bandbreedte ligt. Een van de hieronder getoonde, bij KernelHost gefilterde aanvallen bestond uit meer dan twaalf verschillende hoofdpatronen gelijktijdig.

Versterkingsaanvallen: hoe uit één byte 51.000 worden

Een versterkingsaanval is een aanval waarbij de aanvaller niet zelf op het doel schiet, maar vreemde, openbaar bereikbare diensten ertoe brengt dat voor hem te doen. Hij stuurt een kleine aanvraag naar een open dienst en vult als afzender het IP-adres van het slachtoffer in. De dienst antwoordt plichtsgetrouw, alleen dan aan het slachtoffer, en het antwoord is een veelvoud groter dan de aanvraag.

De verhouding tussen antwoordgrootte en aanvraaggrootte heet Bandwidth Amplification Factor, kort BAF. Een BAF van 50 betekent dat een aanvaller met 1 Gbit/s eigen aansluiting 50 Gbit/s op het doel richt. Twee dingen horen samen om dat te laten werken: een protocol over UDP dat meer antwoordt dan het gevraagd wordt, en de mogelijkheid het afzenderadres te vervalsen. Daarom is IP-spoofing de voorwaarde voor elke versterkingsaanval en niet slechts een verhullingstactiek.

Voor de verdediger volgt daaruit een onaangename eigenschap: het verkeer komt van echte, legitieme servers. Het zijn reële DNS-resolvers, reële tijdservers, reële gameservers. Een blokkeerlijst op bronadres sluit dus of halve landen uit, of zij werkt niet.

De versterkingsfactoren van de misbruikte protocollen

De volgende factoren komen uit de waarschuwing TA14-017A van US-CERT respectievelijk CISA, "UDP-Based Amplification Attacks", die sinds 2014 doorlopend wordt uitgebreid. Zij is de referentie waarnaar de hele branche verwijst.

De tabel verklaart waarom de lijst met geblokkeerde poorten in elke goed onderhouden firewall er vergelijkbaar uitziet. Wat u zelf kunt doen is overzichtelijk, maar belangrijk: controleer met ss -lnup of op uw server een dienst uit deze tabel open in het netwerk staat. Een memcached die niet aan 127.0.0.1 is gebonden, maakt van uw server een wapen tegen derden, kost u uw eigen uitgaande bandbreedte en brengt uw IP-adres op blokkeerlijsten waar het moeilijk weer van af komt.

Waarom spelopvraagprotocollen hierbij horen

Gameservers staan met twee rollen in deze tabel. Zij zijn versterker, omdat hun querypoort op een klein pakket antwoordt met naam, kaart, aantal spelers en de volledige modlijst. En zij zijn slachtoffer, omdat diezelfde opvraging rekentijd kost, vaak op precies de kern die de spelsimulatie draagt.

De versterkingsfactor van het Steam-protocol ligt met 5,5 laag, die van het oudere Quake-protocol met 63,9 hoog. De werking hangt echter niet alleen aan de factor, maar aan de antwoordgrootte in het afzonderlijke geval: een server met 200 mods levert een duidelijk groter antwoord dan een server zonder. Bohemia Interactive documenteert voor Arma 3 onder ticket T83469 sinds 2015 dat al 4 Mbit/s vervalste opvragingen naar de Steam-querypoort volstond om een server te bevriezen. Vier megabit per seconde is minder dan één enkele huishoudaansluiting opbrengt.

Daaruit volgt de regel die voor elk spel geldt: de querypoort begrenzen, niet blokkeren. Wie hem blokkeert, verdwijnt uit de serverlijst en wordt door nieuwe spelers niet meer gevonden. Welke poort dat per spel is en hoe strak hij gehouden mag worden, staat in de spelspecifieke artikelen verderop, bijvoorbeeld voor Arma 3, CS2 en de Source-titels of Rust.

Het geval memcached: 1,35 Tbit/s tegen GitHub

Op 28 februari 2018 was GitHub van 17:21 tot 17:26 UTC niet bereikbaar en tot 17:30 UTC slechts met onderbrekingen. De aanval bereikte 1,35 Tbit/s bij 126,9 miljoen pakketten per seconde en kwam uit meer dan 1.000 verschillende autonome systemen en tienduizenden afzonderlijke eindpunten. Versterkt werd hij via memcached, met een factor van maximaal 51.000: één byte van de aanvaller bracht tot 51 kilobyte in de richting van het doel voort.

Dit geval is tot op vandaag het beste leerstuk, omdat het drie dingen in één keer laat zien. Ten eerste: versterking verslaat botnetgrootte. De aanvaller had geen honderdduizend apparaten nodig, hij had open memcached-instanties nodig, waarvan er toen wereldwijd meer dan 90.000 in het netwerk stonden. Ten tweede: 126,9 miljoen pakketten per seconde is ongeveer 85 keer zoveel als een lijn van 1 Gbit/s überhaupt kan vervoeren. Geen enkele instelling op de server verandert daar iets aan. Ten derde: de afweer werkte omdat het verkeer naar een filternetwerk werd omgeleid en de uitvaltijd daarmee bij negen minuten eindigde in plaats van bij negen uur.

Waar de capaciteit voor een DDoS-aanval vandaan komt

Botnets van overgenomen apparaten

Een botnet is een verband van vreemde, met malware overgenomen apparaten die een aanvaller centraal op afstand bestuurt. De eigenaars merken daar in de regel niets van, omdat het apparaat blijft doen waarvoor het is gekocht. Aangevallen worden vooral apparaten die permanent aan het netwerk hangen, zelden worden bijgewerkt en standaardwachtwoorden dragen: routers, bewakingscamera's, netwerkrecorders, tv-boxen.

De maatstaf is Mirai, waarvan de broncode eind september 2016 is gepubliceerd. Het werk "Understanding the Mirai Botnet" (USENIX Security 2017) volgt het netwerk zeven maanden lang en becijfert het hoogtepunt op meer dan 600.000 geïnfecteerde apparaten. De aanval op de site van Brian Krebs in september 2016 bereikte 620 Gbit/s en kwam uit meer dan 175.000 apparaten. Bij de aanval op de DNS-beheerder Dyn op 21 oktober 2016, die Twitter, Spotify en Reddit gelijktijdig onbereikbaar maakte, werden ongeveer 107.000 aanvallende IP-adressen geteld.

Negen jaar later is de orde van grootte een andere. Cloudflare herleidt de recordaanval van 31,4 Tbit/s tot een botnet met een geschatte grootte van één tot vier miljoen geïnfecteerde apparaten, overwegend Android-tv-boxen. In de aanvalsgolf van december 2025 werden 902 hypervolumetrische aanvallen geteld, gemiddeld 53 per dag, met piekwaarden van 9 miljard pakketten per seconde, 24 Tbit/s en 205 miljoen aanvragen per seconde. De botnetgrootte is daarmee binnen een decennium met factor 5 gegroeid, de behaalde bandbreedte met factor 50.

Booter- en stresserdiensten en wat een aanval kost

Tussen het botnet en de opdrachtgever zit een dienst die de aanvalscapaciteit per abonnement verkoopt. Die diensten treden op als "booter", "stresser" of "IP-stresser" en beweren in hun voorwaarden dat zij voor belastingtests van eigen systemen dienen. Zij controleren daarbij nooit of het ingevoerde doel aan de gebruiker toebehoort, en precies dat is het verschil tussen een gereedschap en een aanbod.

De bediening is een webinterface met drie velden: doel, poort, duur. Er zijn betaalprocessen, klantenservice en wederverkoopprogramma's. De instappakketten liggen rond 10 tot 20 euro per maand, grotere pakketten met meer bandbreedte en langere aanvalsduur op enkele honderden euro's per maand. Daarmee is de vraag beantwoord waarom het ook kleine projecten treft: een aanval die een gameserver de zaterdagavond kost, kost de veroorzaker minder dan twee bioscoopkaartjes en geen technische kennis.

Daar staat een permanente opsporingsdruk tegenover. In de actieweek van de internationale operatie PowerOFF in april 2026 hebben autoriteiten uit 21 landen 53 domeinen van zulke diensten overgenomen, vier personen aangehouden en 25 huiszoekingen uitgevoerd. Daarbij kregen de rechercheurs toegang tot de gegevens van meer dan drie miljoen gebruikersaccounts, en meer dan 75.000 geïdentificeerde gebruikers zijn aangeschreven. In december 2024 waren in dezelfde operatie 27 platforms uitgeschakeld. Wie zo'n dienst betaalt, laat dus een betaalspoor achter in een database die vroeg of laat in beslag wordt genomen.

Waaraan u een DDoS-aanval herkent

Wat de gebruikers melden, en wat dat al zegt

De eerste informatie komt bijna altijd van de gebruikers, en zij is bruikbaarder dan zij klinkt. Vier meldingen hebben een duidelijke betekenis:

• "Iedereen vloog er tegelijk uit." Een gelijktijdige afbreking bij alle gebruikers wijst op de lijn of op het dienstproces, niet op afzonderlijke verbindingen. Een belastingprobleem treft gebruikers na elkaar.
• "De ping springt van 20 naar 400 en terug." Schommelende looptijd bij een verbinding die blijft bestaan, is het patroon van een overvolle wachtrij vóór het doel, niet van een overbelast proces.
• "De serverlijst toont ons als offline, maar ik kan wel verbinden." Dat is de vingerwijzing naar een queryflood: de querypoort antwoordt niet meer, de spelpoort nog wel.
• "Via mobiel internet kom ik binnen, via mijn eigen aansluiting niet." Verschillend gedrag per toegangsnetwerk duidt erop dat niet uw server, maar een weg daarheen verzadigd is.

De vier meetwaarden op de server

Daarna wordt gemeten, en wel in deze volgorde: pakketsnelheid, bandbreedte, verbindingstoestanden, tellers voor verworpen pakketten. De bezettingsweergave van de CPU komt als laatste, omdat zij bij een netwerkaanval vaak onopvallend blijft.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 levert pakketten en bytes per seconde per interface over tien seconden. Beslissend is de verhouding: veel pakketten bij weinig bytes betekent kleine pakketten, dus een protocolaanval. Weinig pakketten bij zeer veel bytes betekent grote pakketten, dus een versterkingsaanval. ip -s link show toont in de kolommen dropped en overrun of de kernel al verwerpt. ss -tn state syn-recv telt halfopen verbindingen: een driecijferige waarde is normaal, een vijfcijferige is een SYN-flood. En nstat levert de tellers die blijven staan, ook wanneer de aanval voorbij is.

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal loopt. Zonder normaalwaarde kunt u niet zeggen of 40.000 pakketten per seconde veel is of gewoon zaterdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. De uitvoerige handleiding voor de uitwerking staat in DDoS-aanval herkennen.

De logregels die eenduidig zijn

Vier meldingen in het kernellogboek en in het webserverlogboek zijn praktisch bewijzend. dmesg -T | tail -50 toont de eerste drie:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

De eerste regel betekent dat de wachtrij voor halfopen verbindingen is overgelopen en dat de kernel op SYN-cookies is overgeschakeld. Staat daar in plaats daarvan Dropping request, dan staat net.ipv4.tcp_syncookies op 0 en verwerpt de server aanvragen inclusief de echte. De tweede regel betekent dat de verbindingsregistratie vol is, en vanaf dat moment verwerpt de server ook legitiem verkeer. De derde regel is een bijeffect: de kernel onderdrukt meldingen, omdat hij anders met loggen bezig zou zijn. De vierde regel verplaatst het probleem naar de applicatie.

In het toegangslogboek van de webserver zijn twee dingen veelzeggend. Een plotseling aandeel van statuscode 499 betekent dat de client de verbinding sluit voordat het antwoord klaar is, en precies dat doet een layer 7-aanval die alleen werk wil uitlokken en niet wil lezen. En een leeg referrerveld bij bijna alle aanvragen onderscheidt een aanval van een echte bezoekerstoeloop, die referrers van zoekmachines en sociale netwerken meebrengt.

De tegenproef: aanval, toeloop of eigen fout

Wat op de server zelf helpt

Op de server is meer te bereiken dan vaak wordt beweerd, en wel tegen alles wat klein blijft: slordige bots, afzonderlijke bronnen, queryfloods en applicatieaanvallen. De gereedschappen daarvoor zijn nftables, de verbindingsregistratie, de SYN-cookies en een ratelimiet per bronadres. Alle volgende gegevens gelden voor Debian 12, Debian 13, Ubuntu 22.04 LTS en Ubuntu 24.04 LTS en zijn voor root geschreven.

nftables: vroeg verwerpen, weinig rekenen

Het uitgangspunt luidt: een pakket dat wordt verworpen, moet zo vroeg en zo goedkoop mogelijk worden verworpen. Elke regel die daarvoor loopt, kost rekentijd maal pakketsnelheid. De volgende regelset voor /etc/nftables.conf laat een webserver en een speldienst door en verwerpt de rest, met een ratelimiet voor nieuwe TCP-verbindingen per bronadres:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Vul onder adminips uw eigen vaste adres in voordat u laadt, anders sluit u zichzelf buiten van SSH. Controleren en activeren gaat zo:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Drie punten bepalen de werking. ct state established,related accept staat bewust als tweede regel, zodat bestaande verbindingen niet door de hele regelset lopen. ct state invalid counter drop verwijdert foutieve vlagcombinaties en te laat gekomen fragmenten, zonder dat u ze afzonderlijk moet beschrijven. En counter vóór elke drop is de reden waarom u naderhand weet welke regel heeft gegrepen: blijven de tellers op nul, dan wordt de regel niet bereikt, en dat is een volledig andere diagnose dan een regelset zonder werking.

SYN-cookies en de grens van de backlog

SYN-cookies zijn een methode waarbij de server een halfopen verbinding niet onthoudt, maar de nodige gegevens versleuteld in zijn eigen antwoordnummer schrijft. Komt het derde pakket van de verbindingsopbouw terug, dan rekent hij daaruit de toestand weer uit. Daarmee loopt de wachtrij niet meer over, want voor die verbindingen bestaat geen wachtrij.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Deze waarden horen in een bestand onder /etc/sysctl.d/ en worden met sysctl --system overgenomen, anders zijn ze na de volgende herstart weg. Op Debian en Ubuntu staat tcp_syncookies standaard op 1, wat juist is. De waarde 1 betekent niet "altijd cookies", maar "cookies zodra de wachtrij overloopt".

De prijs daarvoor is reëel en wordt zelden genoemd. In een cookie is geen plaats voor de TCP-opties van de tegenpartij. Linux redt vensterverruiming en selectieve bevestiging alleen wanneer net.ipv4.tcp_timestamps op 1 staat, omdat de gegevens dan in de tijdstempel meereizen. Zonder tijdstempel vallen ze weg, en de verbinding loopt voor de rest van haar levensduur langzamer. Bovendien zijn er voor de maximale pakketgrootte slechts drie bit beschikbaar, dus acht grove trappen in plaats van de exacte waarde. SYN-cookies zijn een noodbedrijf dat verbindingen redt, geen instelling voor het normale geval.

conntrack: de tabel die als eerste vol is

De verbindingsregistratie van de kernel legt voor elke pakketstroom een vermelding aan, ook voor UDP, hoewel UDP geen verbindingen kent. Precies die tabel is bij een gedistribueerde aanval de eerste bron die opraakt, en zij raakt zeer snel op: bij 1,49 miljoen pakketten per seconde met telkens een nieuw afzenderadres is een tabel met 262.144 plaatsen in minder dan een vijfde seconde gevuld.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Een vermelding bezet ongeveer 300 byte, 524.288 vermeldingen dus ongeveer 150 megabyte kernelgeheugen. De grootte van de hashtabel wordt niet via sysctl, maar als moduleparameter gezet, gebruikelijk op een kwart van de bovengrens, in /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Voor een zuivere spel- of voiceserver is de elegantere oplossing het spelverkeer helemaal niet te laten volgen. Dat spaart de tabel volledig uit:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Let op: notrack en toestandsgebonden regels sluiten elkaar uit. Wie een poort van de registratie uitzondert, mag voor die poort geen regel met ct state meer gebruiken, anders grijpt de vrijgave niet meer en is de dienst dicht.

Ratelimiet per bronadres

Een ratelimiet per bronadres is de meest werkzame afzonderlijke maatregel op de server, omdat zij precies raakt wat een aanvaller doet en precies doorlaat wat een gebruiker doet. Het verschil is groot: een echte serverbrowser vraagt enkele keren per minuut op, een aanvaller honderden keren per seconde. Met nftables werkt u daarvoor met dynamische verzamelingen, zoals in de regelset hierboven, met klassiek iptables met hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Alle getallen in zulke regels zijn startwaarden, geen waarheden. Meet eerst een week in normaal bedrijf, anders gooit u eigen gebruikers eruit, en dat op het slechtst mogelijke moment. Let er bovendien op dat kale iptables-regels na een herstart weg zijn (apt-get install -y iptables-persistent, daarna netfilter-persistent save) en dat zij onder UFW in /etc/ufw/before.rules horen, omdat zij anders bij de volgende ufw reload verdwijnen. De volledige regelset voor het dagelijkse bedrijf staat in Server tegen DDoS-aanvallen beschermen.

Waar elke filtering op de server ophoudt

Nu het deel dat geen enkel configuratiebestand oplost. Alle maatregelen tot hier lopen op uw server, dus aan het einde van de lijn. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is. Zit de lijn ervóór vol, dan komen de pakketten van uw gebruikers al eerder niet meer aan, en dat onafhankelijk van hoe goed uw regelset is.

Deze tabel beantwoordt de vraag of eigen bescherming volstaat, voor elk afzonderlijk geval. De aanval op GitHub met 126,9 miljoen pakketten per seconde past in pakketsnelheid net op een aansluiting van 100 Gbit/s, bij 1,35 Tbit/s volume zou u er echter veertien gelijktijdig nodig hebben. De recordaanval van 31,4 Tbit/s staat gelijk aan 314 volledig verzadigde aansluitingen van 100 Gbit/s. Een gameserver hangt doorgaans aan 1 Gbit/s of aan tweemaal 1 Gbit/s: de grens van de eigen bescherming ligt daarmee rond 1,5 tot 3 miljoen pakketten per seconde, en praktisch duidelijk daaronder, omdat de kernel er eerder mee ophoudt.

Er is nog een tweede, onaangenamere grens. Zodra de lijn verzadigd is, bereikt u onder omstandigheden zelfs de SSH-sessie niet meer waarmee u wilde meten. Wie dan geen netwerkonafhankelijke toegang heeft, bijvoorbeeld een VNC-console in het klantenpaneel, kan zelfs niet meer nakijken wat er gebeurt.

Wat alleen vóór de server helpt: filtering in het netwerk en scrubbing

Werkzaam filteren kan alleen wie meer capaciteit heeft dan de aanval. Dat veronderstelt een plaats waar veel lijnen samenkomen, dus een netwerk en niet een machine. Daar bestaan twee methoden die elkaar aanvullen.

Realtime filtering in het netwerk. Het volledige verkeer loopt permanent door een filtertrap die elk pakket beoordeelt voordat het naar de server wordt doorgegeven. Het voordeel is dat er geen omschakeling is: de bescherming hoeft een aanval niet eerst te herkennen om te werken. Precies dat is bij games beslissend, want een omschakeltijd van twee minuten is een verloren ronde, en een omschakeltijd van twee minuten bij een aanval die 35 seconden duurt, is helemaal geen afweer.

Scrubbing. Herkent het netwerk een grote volumetrische aanval, dan wordt het betrokken verkeer naar filtercentra omgeleid, daar van de schadelijke delen bevrijd en vervolgens in de richting van het doel afgeleverd. De zin van die omleiding is nabijheid: het aanvalsverkeer eindigt op de plaats waar het binnenkomt, in plaats van pas bij het datacenter. De filterregels worden daarvoor in het netwerk verdeeld, technisch beschreven in RFC 8955 als Flow Specification.

De structurele tegenmaatregel tegen vervalste afzenderadressen is overigens al sinds het jaar 2000 bekend en staat in RFC 2827, de BCP 38: wie een klant aansluit, verwerpt op die grens alle pakketten waarvan het afzenderadres niet bij die klant hoort. RFC 3704 breidt dat uit naar netwerken met meerdere aansluitingen. Zouden alle netwerkbeheerders dat doorvoeren, dan was de hele klasse van versterkingsaanvallen voorbij. Zij is dat niet, omdat het volstaat dat enkelen het niet doen.

En er is een derde methode die u moet kennen, omdat zij vaak als bescherming wordt verkocht: null-routing, technisch Remote Triggered Black Hole Filtering volgens RFC 5635. Daarbij wordt het aangevallen IP-adres in het netwerk als onbereikbaar aangekondigd en wordt al het verkeer daarnaartoe verworpen, het aanvalsverkeer net zo goed als dat van uw gebruikers. Dat beschermt het netwerk van de aanbieder, voor u is het resultaat identiek aan een geslaagde aanval, en meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

Wat KernelHost daartegenover zet

De permanente bescherming die in elk serverpakket inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen, te bestellen of te configureren:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, nog voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn doorslaggevend. De bescherming loopt permanent en is vanaf de oplevering van de server actief, er zijn dus geen eerste minuten van een aanval waarin de dienst weg is. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de schadelijke pakketten worden verworpen. Welke games en protocollen eigen filterprofielen hebben, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen, elke avond op hetzelfde tijdstip en met wisselende patronen. Daarvoor is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid, zonder minimale looptijd en zonder installatiekosten. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres uit het Frankfurtse kernnetwerk, waarnaar uw server binnen ons eigen netwerk wordt omgezet. Aan uw kant is geen enkele aanpassing nodig.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u stelt gescheiden in wat op de spelpoort is toegestaan en wat op de querypoort, en kunt daarmee precies de asymmetrie uit de paragraaf over de opvraagprotocollen benutten.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van op een onderhoudsvenster te wachten.
• Een beschermingsprofiel dat bij de betreffende dienst past, net zo goed als voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten.

De Advanced DDoS Protection richt zich op KernelHost-klanten en veronderstelt een server bij KernelHost. Loopt uw project momenteel elders en wordt het daar regelmatig aangevallen, dan is verhuizen naar hier de weg, en niet het op afstand beheren van uw huidige adres.

De twee lagen naast elkaar

Zes echt gefilterde aanvallen uit de praktijk

De volgende zes aanvallen troffen servers van KernelHost-klanten en werden volledig in realtime gefilterd, telkens zonder uitval. De afbeeldingen komen uit de live monitoring van de afweer.

TeamSpeak 3-voiceserver, poort 9987 UDP. Complexe aanval met meerdere gelijktijdige patronen, ruim 473,4 Gbit/s en ruim 41,5 miljoen pakketten per seconde. Dat is ongeveer de 28-voudige pakketsnelheid van een aansluiting van 1 Gbit/s.

ARK-gameserver, poort 7777 UDP. Eenvoudige UDP-flood zonder complexe structuur, maar wel ruim 112,2 Gbit/s en ruim 8,7 miljoen pakketten per seconde. Hoe een ARK-cluster daarnaast zelf wordt afgeschermd, staat in ARK-server beschermen tegen DDoS.

All-port-aanval, poorten 0-65535 TCP en UDP. Meer dan twaalf verschillende hoofdaanvalspatronen tegen alle poorten gelijktijdig, in totaal ruim 21,3 Gbit/s en ruim 3,9 miljoen pakketten per seconde. Dit geval laat de spreiding over alle poorten zien die ook het Cloudflare-geval van mei 2025 met gemiddeld 21.925 doelpoorten vertoont.

Minecraft en OpenVPN, poorten 25565 TCP en 1194 UDP. Gecombineerde aanval met meer dan zestien verschillende hoofdaanvalspatronen, ruim 4 miljoen pakketten per seconde en ruim 8,6 Gbit/s. Beide diensten bleven doorlopend bereikbaar, ook al spreken zij verschillende protocollen.

UDP-flood op één enkele servicepoort, acht minuten. Het zwaarste van de zes gevallen: 745,5 Gbit/s en 73,1 miljoen pakketten per seconde, ongeveer de 49-voudige pakketsnelheid van een aansluiting van 1 Gbit/s. 99,93 procent van het verkeer ging naar één enkele doelpoort, de bronnen waren volledig verspreid. Na acht minuten was de aanval voorbij, de dienst bleef doorlopend bereikbaar.

Aanhoudende aanval van drie uur en 31 minuten. 501,2 Gbit/s en 43,9 miljoen pakketten per seconde, niet als één enkele piek, maar als een reeks golven zonder pauze. Zeven gelijktijdige aanvalspatronen, waaronder versterking via SSDP, MS SQL RS, L2TP en RIPv1. De doelpoorten waren gespreid over het volledige bereik 1024 tot 65535, het wisselen van poort had dus niets opgeleverd. Meer over beide gevallen in Hoe lang duurt een DDoS-aanval.

Wat u bij een aanval moet doen, in deze volgorde

De volgorde is belangrijker dan de afzonderlijke stappen, omdat de meest gemaakte fouten in de eerste vijf minuten gebeuren.

1. Meten, niet schroeven. Leg eerst de waarden uit sar -n DEV 1 10, ip -s link show, ss -s en dmesg -T in een bestand vast. Na de aanval zijn ze weg, en zonder die waarden kan niemand u helpen.
2. Niet opnieuw opstarten. Een herstart wist alle tellers, alle verbindingstoestanden en elk bewijs, en de belasting is na enkele seconden weer terug.
3. Vaststellen welk niveau het is. Bytes gedeeld door pakketten geeft de gemiddelde pakketgrootte. Onder 100 byte duidt op een protocolaanval, boven 1.000 byte op een versterkingsaanval, normale groottes bij hoge CPU-belasting op layer 7.
4. Beheerpoorten dichtdoen. Panel, database, RCON en alles wat niet openbaar hoeft te zijn, wordt tot uw eigen adres beperkt. Dat verkleint het aanvalsoppervlak onmiddellijk en zonder risico voor de gebruikers.
5. Een ratelimiet instellen, strak op de querypoort en ruim op de gebruikspoort. Blokkeer de querypoort niet, anders verdwijnt u uit elke serverlijst.
6. Het eigen adres niet overhaast wisselen. Een adreswissel werkt alleen zolang het nieuwe adres niet weer openbaar staat, en een vergeten oud DNS-record maakt de wissel zinloos.
7. De aanbieder met cijfers erbij betrekken. Open een ticket met tijdstip, doelpoort, pakketsnelheid, bandbreedte en de gemiddelde pakketgrootte. Die vijf gegevens bepalen hoe snel de filterregels voor uw adres worden bijgesteld.
8. Daarna documenteren. Leg vast wanneer het begon, hoe lang het duurde en welk patroon het was. Terugkerende aanvallen op hetzelfde tijdstip zijn het criterium voor de vraag of een project een dedicated beschermd IP-adres nodig heeft.

Het uitvoerige verloop voor een zware, langer lopende aanval staat in Zware DDoS-aanval: wat nu.

Juridische situatie: een DDoS-aanval is een strafbaar feit

In Oostenrijk valt een DDoS-aanval onder § 126b van het Oostenrijkse Strafgesetzbuch (StGB), "verstoring van de werking van een computersysteem". Het grondfeit voorziet in een vrijheidsstraf tot zes maanden of een geldboete tot 360 dagboetes. Duurt de verstoring langere tijd, dan is het tot twee jaar. Worden veel systemen aangevallen met een programma dat kennelijk daarvoor is gemaakt, dan is het tot drie jaar. En bij een schade boven 300.000 euro, bij een aanval op kritieke infrastructuur of als lid van een criminele organisatie ligt het kader op zes maanden tot vijf jaar. Aanvullend stelt § 126c StGB al het vervaardigen, verspreiden en toegankelijk maken van de daarvoor bestemde programma's strafbaar.

In Duitsland geldt § 303b StGB, "computersabotage": tot drie jaar vrijheidsstraf of een geldboete, tot vijf jaar wanneer de gegevensverwerking een bedrijf, een onderneming of een overheidsinstantie dient, en in bijzonder zware gevallen zes maanden tot tien jaar, bijvoorbeeld bij bedrijfsmatig handelen of bij aantasting van kritieke infrastructuur. De poging is strafbaar, en voor voorbereidingshandelingen verwijst § 303b lid 5 StGB naar § 202c StGB.

Booter- en stresserdiensten zijn daarom geen grijs gebied, maar het betaalde deel van een strafbaar feit. Drie punten worden daarbij regelmatig verkeerd begrepen. Ten eerste maakt de aanduiding "alleen voor belastingtests van eigen systemen" niets legaal, omdat de diensten niet controleren wie het ingevoerde doel toebehoort. Ten tweede is ook de opdrachtgever strafbaar, niet alleen de exploitant: Europol heeft na de actieweek in april 2026 uitdrukkelijk meer dan 75.000 geïdentificeerde gebruikers aangeschreven om precies dat duidelijk te maken. Ten derde is een belastingtest op de eigen server via zo'n dienst evenmin een oplossing, omdat het aanvalsverkeer door het netwerk van de aanbieder en dus over de lijnen van andere klanten loopt, wat elk hostingcontract verbiedt. Wie de belastbaarheid van zijn dienst werkelijk wil meten, doet dat aangekondigd en in overleg met de aanbieder. Deze paragraaf geeft de stand van de wetgeving weer en is geen juridisch advies.

De passende leidraad voor uw dienst

Dit artikel legt het principe uit. Welke poort open hoort, welke configuratiedirective welke opvraging begrenst en waar de grens bij het betreffende spel ligt: dat staat in de artikelen over de afzonderlijke dienst, telkens met een feitentabel van de poorten.

• Basis en verloop: DDoS-aanval herkennen, Server tegen DDoS-aanvallen beschermen, Zware DDoS-aanval: wat nu, Game-DDoS-bescherming met realtime filtering
• Minecraft en voice: Minecraft en nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Rollenspel op GTA-basis: FiveM, RedM, RAGE MP en alt:V, SA-MP en open.mp, MTA:SA
• Overleven en opbouwen: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Tactiek en shooters: CS2 en Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Kort samengevat

• Een DDoS-aanval bezet een van vier eindige bronnen: bandbreedte, pakketsnelheid, een toestandstabel van de kernel of de rekentijd van de applicatie. Hij gebruikt geen veiligheidslek, daarom beschermt bijwerken alleen niet.
• RFC 4732 definieert een DoS-aanval via het effect, niet via het aantal bronnen. Gedistribueerd heet hij wanneer de bronnen talrijk zijn: in het Cloudflare-geval van mei 2025 waren het 122.145 adressen uit 161 landen.
• CISA, FBI en MS-ISAC onderscheiden drie technieken: volumetrisch in Gbit/s, protocolgericht in pakketten per seconde, applicatiegericht in aanvragen per seconde. Elk daarvan vraagt een andere afweer.
• Versterkingsaanvallen misbruiken open UDP-diensten. De factoren lopen van 5,5 bij het Steam-protocol via 30,8 bij SSDP en 556,9 bij NTP tot 51.000 bij memcached, na te lezen in US-CERT TA14-017A.
• De capaciteit komt uit botnets van overgenomen apparaten, van 600.000 bij Mirai in 2016 tot geschat één tot vier miljoen achter de recordaanval van 31,4 Tbit/s, en wordt vanaf ongeveer 10 euro per maand doorverkocht.
• Op de server werken nftables, SYN-cookies, aangepaste conntrack-grenzen en een ratelimiet per bronadres. Zij eindigen rond 1,5 miljoen pakketten per seconde, omdat een aansluiting van 1 Gbit/s niet meer vervoert.
• Boven die grens beslist uitsluitend de filtering in het netwerk vóór de server. Null-routing is geen afweer, maar het resultaat dat de aanvaller wilde.
• Bij KernelHost is de permanente bescherming in twee lagen bij elk serverpakket zonder meerprijs inbegrepen en vanaf de oplevering actief, zonder null-routing: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk plus Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. De Advanced DDoS Protection vult haar vanaf 50,00 € per maand aan met een dedicated beschermd IP-adres en zelf beheerbare regels per poort.
• Een DDoS-aanval is in Oostenrijk volgens § 126b StGB en in Duitsland volgens § 303b StGB strafbaar, voor opdrachtgevers net zo goed als voor de exploitanten van de diensten.

Draait uw project al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets ongewoons, open dan een supportticket met de vijf gegevens uit stap 7, zodat de filterregels voor uw IP-adres worden bijgesteld. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.