Zware DDoS-aanval: wat u nu moet doen

Een aanval die na tien minuten voorbij is, is vervelend. Een aanval die al dagenlang elke avond op hetzelfde tijdstip terugkomt, is iets heel anders: dan is uw server geen toevallig doelwit meer. Dit artikel laat zien wat er nu moet gebeuren, wat u zonder extra kosten zelf kunt afschermen en waar die maatregelen ophouden.

Alle commando's gelden voor Debian 12, Debian 13, Ubuntu 22.04 LTS en Ubuntu 24.04 LTS en zijn voor root geschreven; als gewone gebruiker zet u er sudo voor. Wat een DDoS-aanval technisch gezien is, legt het artikel Wat is een DDoS-aanval? uit.

Zolang de aanval loopt: niet opnieuw opstarten en niet de halve configuratie ombouwen. Een herstart wist precies de tellers die u voor de melding aan uw provider nodig hebt, en de aanval komt daarna onveranderd terug.

Waarom juist uw server zo hardnekkig wordt aangevallen

Servers die wekenlang worden bestookt, hebben bijna altijd dezelfde drie eigenschappen. Ten eerste publiceren ze hun adres uit zichzelf: in een serverlijst, in een Discord, via een DNS-record. Ten tweede zit het gebruik vast aan vaste tijden, waardoor een uitval om 20 uur maximaal zichtbaar is. Ten derde is er iemand voor wie die uitval iets waard is: een concurrerend project, een verbannen speler, een boze klant.

Technisch komt daarbij dat veel van de getroffen diensten over UDP lopen. UDP kent geen verbindingsopbouw die u zou kunnen eisen, en afzenderadressen laten zich vervalsen. Een aanvaller hoeft uw dienst dus niet te betreden en hoeft hem ook niet correct aan te spreken om belasting te veroorzaken. Bij TCP-diensten leggen in plaats daarvan halfopen verbindingen beslag op resources, zonder ooit te worden afgerond.

De poorten waar het werkelijk om gaat

Een aanval treft niet "de server", maar een poort. Het volgende overzicht noemt de standaardpoorten van de meest bestookte diensten en is meteen uw controlelijst: alles wat hier niet in staat en toch open is, hoort dicht.

Een tweede groep duikt niet op als doelwit, maar als bron: 53 (DNS), 123 (NTP), 389 (CLDAP), 1900 (SSDP), 11211 (memcached) en eveneens 27015. Overheersen deze bronpoorten, dan gaat het om een reflection- en amplification-aanval. De afzenders zijn in dat geval onbetrokken, slecht geconfigureerde servers, waardoor het blokkeren van afzonderlijke adressen niets oplevert.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet: een netjes geconfigureerde server houdt kleine en middelgrote aanvallen op eigen kracht uit en levert in geval van nood de meetwaarden voor de volgende stap.

1. De eerste minuten: meten in plaats van sleutelen

Voordat u iets wijzigt, legt u vast wat er op dit moment gebeurt. Vier waarden volstaan: de inkomende pakketsnelheid, de verdeling van de verbindingstoestanden, de kernelmeldingen en de vraag of de dienst lokaal nog antwoordt.

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) pakketten/s inkomend op $IF"
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn
dmesg -T | tail -50
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

De naam van de interface komt uit de standaardroute, omdat eth0 op veel KVM-servers helemaal niet bestaat (daar heet die ens3 of enp1s0) en een verkeerd ingevulde naam doodleuk nul pakketten meldt. Een groot blok in SYN-RECV is het patroon van een SYN-flood. Antwoordt de dienst via 127.0.0.1 snel terwijl hij van buitenaf uitvalt, dan zit het probleem in het netwerk. En let op: op de server meet u alleen wat erdoorheen is gekomen, achter een filtering ziet u maar een fractie van het volume. Hoe u dat systematisch aanpakt, staat in DDoS-aanval herkennen.

Komt u via SSH niet meer door, dan is dat geen reden voor een herstart, maar het gevolg van een volle lijn. De toegang loopt dan via de VNC-console in het klantenpaneel, die losstaat van de netwerkverbinding.

2. Inventarisatie: wat luistert er naar buiten?

ss -lntup
nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

Het eerste commando toont uw eigen beeld, het tweede levert vanaf een andere computer het beeld van de aanvaller. Doorslaggevend is het lokale adres: 0.0.0.0:3306 betekent "vanaf het hele internet bereikbaar", 127.0.0.1:3306 betekent "alleen lokaal" en heeft geen firewallregel nodig. Daarbij duiken geregeld vergeten diensten op: een testinstantie, een beheerpaneel, een database zonder lokale binding.

3. Alleen openlaten wat de dienst echt nodig heeft

De volgorde is belangrijk, anders sluit u zichzelf buiten: eerst de vrijgaven, dan het standaardbeleid, dan inschakelen.

ufw allow 22/tcp comment 'SSH'
ufw allow 80,443/tcp comment 'Web'
ufw allow 25565/tcp comment 'Spelpoort'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Controleer daarna met een tweede, vers opgebouwde sessie of u nog binnenkomt: bestaande verbindingen overleven het inschakelen ook wanneer de bijbehorende regel ontbreekt. De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten.

De database hoort niet op het open internet; in /etc/mysql/mariadb.conf.d/50-server.cnf moet bind-address = 127.0.0.1 staan. Beheerinterfaces horen daar evenmin thuis: hebt u geen vast IP-adres voor een gerichte vrijgave, laat de poort dan dicht en bereik hem via een SSH-tunnel.

ssh -N -L 8443:127.0.0.1:8443 root@UW.SERVER.IP.ADRES

Gepubliceerde containerpoorten lopen langs de UFW-ketens heen. Bind ze lokaal, dus -p 127.0.0.1:8080:80 in plaats van -p 8080:80, en leid de toegang via een reverse proxy.

4. De querypoort afschermen zonder hem te sluiten

Veel diensten hebben naast de eigenlijke poort een tweede die statusinformatie uitlevert: bij Steam-gebaseerde games 27015 UDP, bij Minecraft de querypoort, bij TeamSpeak de ServerQuery-interface op 10011 TCP. Ze antwoorden zonder inloggen, en het antwoord is groter dan de vraag, waardoor het zich leent voor amplificatie tegen derden. Sluiten is meestal geen optie, want dan verdwijnt uw server uit de serverlijst. Begrens in plaats daarvan per bronadres:

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

Tien opvragingen per seconde per adres volstaan voor echte spelers en voor uw monitoring, maar verwerpen een bron met duizenden aanvragen per seconde. Bij Minecraft schakelt enable-query=false in de server.properties de querypoort helemaal uit, zonder dat de server uit de lijst verdwijnt. enable-status=false onderdrukt daarnaast het antwoord op de lijstping, maar dan verschijnt uw server als offline. De ServerQuery-interface van TeamSpeak bindt u aan 127.0.0.1.

5. Verbindings- en pakketsnelheden begrenzen

iptables -I INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 40 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name game_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

De eerste regel verwerpt nieuwe TCP-verbindingen zodra één adres er meer dan veertig tegelijk open heeft staan, de tweede verwerpt UDP-pakketten zodra er blijvend meer dan 600 pakketten per seconde uit dezelfde bron komen. Beide getallen zijn startwaarden, geen waarheden: wie te krap instelt, gooit zijn eigen gebruikers eruit. Controleer met iptables -L INPUT -n -v of de tellers oplopen. Blijven ze op nul staan, dan wordt de regel helemaal niet bereikt.

Kale iptables-regels zijn na een herstart verdwenen; u bewaart ze met apt-get install -y iptables-persistent en netfilter-persistent save. Onder UFW horen ze in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen. En dan de principiële grens: limieten per bronadres werken alleen zolang er opvallende bronnen zijn. Stuurt elk van de 200.000 betrokken adressen precies één pakket, dan valt er geen enkele van op.

6. De kernel voorbereiden op veel kleine pakketten

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

SYN-cookies beantwoorden de verbindingsopbouw zonder geheugen te bezetten en staan standaard aan. De twee wachtrijen lopen bij veel gelijktijdige verbindingspogingen als eerste over. Blijvend horen zulke waarden in een bestand onder /etc/sysctl.d/, waarna ze met sysctl --system worden overgenomen. De laatste regel toont de verbindingsregistratie, die er alleen is bij een actieve firewall: loopt die tabel vol, dan verwerpt de server ook legitieme pakketten en meldt hij nf_conntrack: table full, dropping packet.

7. Applicatieniveau: ratelimieten, whitelist, plug-ins en anti-cheat

Aanvallen die niet de lijn, maar de applicatie overbelasten, zien er anders uit: weinig pakketten, maar dure. Een HTTP-flood op de zoekfunctie van een webshop heeft geen gigabit nodig. Bij de webserver is een begrenzing per adres daarom de meest effectieve maatregel, in nginx in het http-blok en daarna in het server- of location-blok:

limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=webconn:10m;

limit_req zone=web burst=20 nodelay;
limit_conn webconn 20;

Tegen terugkerende inlogpogingen vult Fail2ban dat zinvol aan; het instellen ervan staat in Fail2ban instellen. Bij gameservers werken drie dingen tegen alles wat de reguliere weg naar binnen gebruikt: een whitelist (bij Minecraft whitelist=true met enforce-whitelist=true), een realistische bovengrens voor gelijktijdige spelers en netwerkevents die aan serverzijde worden gecontroleerd.

Wat plug-ins en anti-cheatsystemen niet kunnen, mag net zo duidelijk gezegd worden: beide draaien in hetzelfde proces als het spel en controleren pas wanneer een pakket al verwerkt wordt. Staat het proces stil, dan staat de beveiligingslogica er samen mee stil. Voor de whitelist geldt hetzelfde, want wie uw server overspoelt, wil helemaal niet meedoen.

8. Serverlijst, DNS en het eigen IP-adres

Hier loont eerlijkheid meer dan wensdenken: uw IP-adres laat zich niet geheimhouden. Iedereen die ooit verbonden is geweest, kent het, en een vermelding in de lijst publiceert het sowieso. Twee gewoonten helpen toch: publiceer het kale adres nergens zelf, ook niet in het Discord-kanaal of via een statusbot, en laat uw gebruikers via een hostnaam verbinden, zodat een adreswissel niet alle verwijzingen breekt.

Bij de wissel zelf zijn oude DNS-records de klassieker: een vergeten A-record, een subdomein van een statuspagina, een MX-record dat naar dezelfde server wijst. En zelfs dan levert een adreswissel tijd op in plaats van een oplossing.

9. Vastleggen zolang het incident loopt

Zonder vergelijkingswaarde kunt u achteraf niet zeggen of 40.000 pakketten per seconde veel was of gewoon dinsdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens het incident verzamelt u:

mkdir -p /root/incident && cd /root/incident
date -u > 01-tijd.txt
ss -s > 02-sockets.txt
ip -s link > 03-interfaces.txt
sar -n DEV 1 10 > 04-pakketsnelheid.txt
dmesg -T | tail -100 > 05-kernel.txt
tcpdump -ni "$IF" -s 96 -c 500 -q > 06-steekproef.txt

Begrens tcpdump altijd met -c, want een onbegrensde opname op een volle lijn belast de server extra. In het ticket horen daarna het tijdstip met tijdzone, het getroffen IP-adres inclusief poort, de gemeten pakketsnelheid met richting, de verdeling over de protocollen en de opvallende bronpoorten. Met die gegevens wordt een melding meteen opgepakt, met "de server was traag" volgen er alleen maar vragen.

Waar deze maatregelen ophouden

Nu het deel dat geen enkel configuratiebestand oplost. Alle maatregelen tot hier draaien 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.

Rekent u even mee. Een aansluiting van 1 Gbit/s draagt 125 megabyte per seconde en zit vol zodra iemand meer stuurt. Bij de kleinst mogelijke pakketten komt dat neer op ongeveer 1,49 miljoen pakketten per seconde, bij 10 Gbit/s op ongeveer 14,9 miljoen. Een serverkernel verwerkt daarvan, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen. Een aanval die uw lijn nog niet eens voor een derde vult, legt u dus toch plat, omdat de rekentijd opgaat aan het verwerpen.

Ter oriëntatie op de werkelijke ordes van grootte: op KernelHost-servers zijn onder meer een aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver (9987 UDP) en een UDP-flood met meer dan 112,2 Gbit/s op een gameserver (7777 UDP) in realtime gefilterd. Het eerste geval is ongeveer 473 keer zoveel als wat een lijn van 1 Gbit/s maximaal kan vervoeren. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen, anders eindigen ze in uw lijn.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elke server inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft te bestellen, in te schakelen 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 ter plaatse in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn in geval van nood doorslaggevend. De bescherming loopt permanent en hoeft niet eerst op een aanval te reageren, dus er zijn geen eerste minuten waarin de server weg is. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de schadelijke pakketten worden verworpen. Haalt een aanbieder het aangevallen adres daarentegen uit het netwerk, dan is het resultaat voor u identiek aan een geslaagde aanval. Het datacenter is maincubes in Frankfurt am Main, Duitsland; de exploitant is KernelHost GmbH, gevestigd in Wenen, Oostenrijk. De bescherming zit zonder meerprijs in elk serverpakket, van de KVM-rootserver tot de dedicated server.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe geraakt, maar gericht en wekenlang. Daarvoor is er de Advanced DDoS Protection vanaf € 50,00 per maand, PrePaid en zonder minimale looptijd. 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, zonder ticket: de spelpoort krijgt andere regels dan de querypoort.
• Wijzigingen gelden in realtime, u kunt dus midden in een lopende aanval bijsturen.
• Een beschermingsprofiel dat bij het betreffende spel past, plus profielen voor eigen en aangepaste applicaties op willekeurige TCP- of UDP-poorten.

De twee lagen naast elkaar

Voor de meeste projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt.

Veelgemaakte fouten en oplossingen

"Ik heb de server opnieuw opgestart en daarna liep het even weer": dat was de aanval in golven, niet de herstart. Een herstart wist de tellers die u voor de melding nodig had gehad.

"Ik heb het IP-adres gewisseld en was twee uur later weer offline": het nieuwe adres kwam uit dezelfde bron als het oude, meestal een vermelding in de lijst, een statusbot of een oud DNS-record.

"Ik blokkeer de opvallende adressen, maar er komen er steeds nieuwe bij": bij een gedistribueerde aanval zijn het er tienduizenden, en bij reflection-aanvallen blokkeert u sowieso alleen onbetrokken derden.

"Mijn firewallregels grijpen niet": drie oorzaken komen vaak voor. De regels staan achter de UFW-ketens, ze waren na de laatste herstart verdwenen, of de aanval is volumetrisch en de regel werkt correct aan een lijn die al vol zit.

"De belasting was laag en toch was de dienst weg": een typische aanval via de pakketsnelheid. De bandbreedte ziet er onschuldig uit, het aantal pakketten niet. Meet pakketten per seconde, geen megabit.

"In de tcpdump zie ik niets opvallends": wordt het verkeer al in het netwerk ervoor gefilterd, dan komt er op de server zoals verwacht niets aan. Zit de lijn daarentegen vol, dan bereikt u onder omstandigheden zelfs de SSH-sessie niet meer. Gebruik dan de VNC-console in het klantenpaneel.

Kort samengevat

Meet eerst, bouw pas daarna om. Sluit alles wat de dienst niet nodig heeft, begrens de querypoort, de verbindingen en de pakketsnelheden per bronadres en verzamel meetwaarden zolang het incident loopt. Daarmee bent u opgewassen tegen alles wat het zonder noemenswaardige bandbreedte redt. Daarboven beslist uitsluitend het netwerk vóór de server.

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, zodat wij de filterregels voor uw IP-adres bijstellen. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.