DDoS-aanval herkennen: zo stelt u het met zekerheid vast

De dienst reageert niet meer, de systeembelasting staat helemaal bovenaan, en in de chat verschijnt de vraag: worden wij aangevallen? Die vraag laat zich meten. Ze laat zich zelfs vrij snel meten, mits u weet welke vier getallen u in welke volgorde bekijkt en welke tegenproef van een vermoeden een vaststelling maakt.

Dit artikel gaat uitsluitend over de diagnose. Het doel is niet om een aanval af te weren, maar om hem zonder twijfel te onderscheiden van een overbelasting, een softwarefout of gewoon van succes. Wilt u weten wat een DDoS-aanval technisch gezien is, lees dan Wat is een DDoS-aanval. Wilt u naar aanleiding van de vaststelling handelen, ga dan verder met Server beschermen tegen DDoS-aanvallen.

Vier verdachten, één symptoom

"De server is traag" is geen vaststelling, maar een symptoom met minstens vier plausibele oorzaken. Voordat u ook maar één commando intypt, moet u weten welke patronen u eigenlijk uit elkaar wilt houden.

De vierde verdachte ontbreekt in deze tabel omdat hij geen eigen kolom nodig heeft: geplande taken. Back-ups, herindexeringen, logrotaties en pakketupdates draaien op voorspelbare tijdstippen. Een blik op systemctl list-timers en de crontabs kost tien seconden en maakt verrassend veel vermoedens van een aanval meteen af.

De eerste 60 seconden: vier getallen

Verzamel in deze volgorde vier waarden. De combinatie zegt iets, elke afzonderlijke waarde op zichzelf niet.

cat /proc/loadavg
ss -s
cat /proc/net/dev
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

De interpretatie:

• Hoge load, hoge netwerkbelasting, veel halfopen verbindingen, maar 127.0.0.1 antwoordt in milliseconden: het probleem zit vóór de applicatie, dus op netwerkniveau. Dat is het klassieke beeld van een aanval.
• Hoge load, normale netwerkbelasting, 127.0.0.1 antwoordt traag: applicatie of database. Geen aanval, maar werk voor de ontwikkelaar.
• Lage load, hoge netwerkbelasting: sterk verdacht. Een pakketstorm die de applicatie helemaal niet bereikt, verbruikt weinig CPU en veel lijncapaciteit.
• Alles laag, dienst toch van buitenaf onbereikbaar: zie verderop, de paragraaf over gevallen zonder meetbaar spoor.

Voor de loadwaarde zelf geldt: /proc/loadavg telt ook processen mee die op invoer en uitvoer wachten. Een waarde van 40 bij vier cores kan net zo goed een aanval als een overbelaste schijf zijn. vmstat 1 5 scheidt dat netjes: de kolom r toont processen die klaarstaan om te rekenen, b de geblokkeerde processen en wa het aandeel wachttijd.

Verbindingen tellen: ss in plaats van netstat

Bijna alle handleidingen op internet beginnen met netstat. Op een actueel systeem eindigt dat zo:

Command 'netstat' not found, but can be installed with:
apt install net-tools

netstat hoort bij het pakket net-tools, dat op Debian 12, Debian 13, Ubuntu 22.04 en Ubuntu 24.04 niet meer in de standaardinstallatie zit. Op de Red Hat-familie (AlmaLinux, Rocky, RHEL, Oracle Linux) evenmin. U kunt het alsnog installeren, maar zinvoller is ss uit iproute2: dat staat op vrijwel elke server, is bij veel verbindingen duidelijk sneller en levert exact dezelfde informatie.

ss -s

Om alle volgende commando's te kunnen draaien hebt u een handvol pakketten nodig, en die heten per distributiefamilie anders. Dat is de plek waar een gekopieerde handleiding op AlmaLinux het vaakst al in de eerste regel blijft steken:

Op Debian en Ubuntu dus apt-get install -y iproute2 net-tools procps sysstat dnsutils tcpdump, op de Red Hat-familie dnf -y install iproute net-tools procps-ng sysstat bind-utils tcpdump. curl zet u daar beter niet in de lijst: het is als curl-minimal al geïnstalleerd en het volledige pakket botst daarmee (curl-minimal ... conflicts with curl). Hebt u het toch nodig, dan helpt dnf -y --allowerasing install curl.

De eerste regel noemt het totale aantal sockets, de TCP-regel splitst dat uit: estab, closed, orphaned, timewait. Een hoge timewait-waarde alleen is geen aanwijzing voor een aanval, maar het normale gevolg van veel korte HTTP-verbindingen.

Interessanter is de verdeling over de toestanden:

ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn

Opvallend is een groot blok in SYN-RECV. Die verbindingen zijn wel gestart, maar nooit bevestigd, en dat is precies het patroon van een SYN-flood. Tellen kan direct:

ss -Htn state syn-recv | wc -l

De kolomval waarop de meeste oneliners stuklopen

Zodra u ss een toestandsfilter meegeeft, vervalt de toestandskolom in de uitvoer. Het externe adres staat dan in kolom 4 in plaats van in kolom 5. Precies daarom leveren gekopieerde oneliners uit forums regelmatig onzin op: ze tellen poorten in plaats van IP-adressen, of ze geven lege regels terug. Ezelsbruggetje: zonder filter staat het externe adres in $5, met filter in $4. De -H onderdrukt bovendien de kopregel, zodat wc -l zonder correctie klopt.

Verbindingen per bron-IP, bestand tegen IPv6:

ss -Htn state established | awk '{print $4}' | sed 's/:[^:]*$//' | sort | uniq -c | sort -rn | head -20

De sed knipt alleen de laatste dubbele punt met de poort eraf. De veelgebruikte aanpak met cut -d: -f1 werkt bij IPv4, maar hakt IPv6-adressen al na het eerste blok af en maakt de analyse waardeloos. Bij IPv6 blijven de vierkante haken staan, dat hindert bij het tellen niet.

De interpretatie vraagt om gevoel voor verhoudingen. Honderd verbindingen vanaf één enkel IP kunnen een aanval zijn, maar net zo goed een bedrijfs-NAT, een carrier-grade NAT van een mobiele provider of een reverse proxy vóór uw server. Staat er een content delivery network of een load balancer voor, dan ziet u sowieso alleen de adressen daarvan en moet u in het log van de webserver uitwijken naar X-Forwarded-For.

Voor UDP geldt dezelfde opbouw met -u. En om te weten te komen welke dienst op welke poort luistert:

ss -tulnp

Netwerkbelasting en pakketsnelheid correct meten

Bandbreedte in megabit is het getal dat iedereen noemt. Veelzeggender is de pakketsnelheid. Een aanval met 200.000 minuscule pakketten per seconde legt een server plat, ook al ziet de bandbreedte er onschuldig uit.

Eerst de naam van de interface, want eth0 is lang niet overal het juiste antwoord. Gebruikelijke namen zijn ens3, enp1s0 of eth0:

ip -br link

Daarna twee metingen met een seconde ertussen, volledig zonder extra pakketten. De naam van de interface wordt daarbij uit de standaardroute gehaald in plaats van uitgeschreven:

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"

Die omslachtigheid heeft een goede reden. Zet u hier vast eth0 neer terwijl de interface in werkelijkheid ens3 of enp1s0 heet, zoals op de meeste KVM-servers het geval is, dan geeft het commando weliswaar tweemaal cat: /sys/class/net/eth0/statistics/rx_packets: No such file or directory uit, maar meldt daarna doodleuk 0 pakketten/s inkomend en sluit af met returncode 0. In een artikel over het herkennen van aanvallen is dat de gevaarlijkste variant van allemaal: u leest nul pakketten, geeft het sein veilig, en de aanval loopt gewoon door. De || exit 1 voorkomt precies dat.

Hetzelfde met rx_bytes geeft de bytes per seconde. Uit beide waarden berekent u de gemiddelde pakketgrootte, en die verraadt het type aanval:

• gemiddeld onder 100 byte bij een zeer hoge pakketsnelheid: SYN-, ACK- of UDP-flood. Het doelwit is de pakketverwerking, niet de lijn.
• 1200 tot 1500 byte bij hoge bandbreedte, bronpoorten 53, 123, 389 of 11211: reflectie- en amplificatieaanval. De bron-IP's zijn servers van derden, niet de aanvallers.
• normale verdeling van de pakketgroottes, nette HTTP-verzoeken: applicatieniveau. Dan beslist het log van de webserver, niet de pakketteller.

Comfortabeler gaat het met sar uit het pakket sysstat:

sar -n DEV 1 3

Valkuil: de live meting werkt meteen na de installatie, de historische analyse met sar -f daarentegen niet. Op Debian en Ubuntu staat het verzamelen van gegevens standaard uit, in /etc/default/sysstat staat ENABLED="false". Wie dat pas tijdens een aanval merkt, heeft geen vergelijkingswaarden van eergisteren. Dat is de reden om dit pakket preventief in te schakelen en niet pas als het menens is.

En de belangrijkste beperking van allemaal: op de server meet u alleen wat er is doorgekomen. Zit er filtering voor, dan ziet u een fractie van het werkelijke volume of helemaal niets. Het betrouwbare getal staat in de verkeersgrafiek in het klantenpaneel, niet in /proc/net/dev.

Kernelmeldingen lezen

De kernel legt overbelastingssituaties vast die op applicatieniveau onzichtbaar blijven. Op Ubuntu en recente Debian-versies is de ringbuffer voor gewone gebruikers afgeschermd, zonder sudo verschijnt:

dmesg: read kernel buffer failed: Operation not permitted

Dat is geen storing, maar kernel.dmesg_restrict=1. Met rootrechten en tijdstempels:

dmesg -T | grep -Ei 'syn flood|conntrack|neighbour|drop'

De melding waar de meeste mensen naar zoeken, luidt letterlijk:

TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.

Er zijn twee varianten en een verschil in formaat dat u moet kennen:

• Sending cookies betekent dat SYN-cookies actief zijn en dat de verbindingen gewoon bediend blijven worden. Dropping request verschijnt in plaats daarvan als net.ipv4.tcp_syncookies op 0 staat. Dan worden verzoeken weggegooid, echte bezoekers incluis.
• Oudere kernels noemen alleen het poortnummer, nieuwere daarnaast ook het luisteradres in de vorm 0.0.0.0:443. Op Debian 12 ziet u dus de korte vorm, op Debian 13 en Ubuntu 24.04 de lange. Wie op de exacte oude formulering grept, vindt op nieuwe systemen niets.

Belangrijk voor een eerlijke diagnose: deze melding bewijst geen aanval. Ze verschijnt ook wanneer een applicatie met een te kleine listen-backlog werkt en een legitieme belastingspiek haar overrompelt. Ze is een aanwijzing die door andere meetwaarden ondersteund moet worden.

De bijbehorende tellers levert nstat:

nstat -az TcpExtSyncookiesSent
nstat -az TcpExtListenDrops
nstat -az TcpExtListenOverflows

Ook hier een valkuil: nstat onthoudt bij elke aanroep een tussenstand en toont de volgende keer alleen nog het verschil. Dat is met opzet zo en voor de meting zelfs praktisch, maar het verrast iedereen die bij de tweede aanroep opeens nullen ziet. Met -a dwingt u absolute waarden af, met -s onderdrukt u het bijwerken van die tussenstand.

Twee andere meldingen die bij een aanval regelmatig opduiken en die allebei tot pakketverlies bij legitieme bezoekers leiden:

nf_conntrack: table full, dropping packet
neighbour: arp_cache: neighbor table overflow!

De vullingsgraad van de connection tracking controleert u met cat /proc/sys/net/netfilter/nf_conntrack_count in vergelijking met nf_conntrack_max. Beide bestanden bestaan alleen als de module geladen is, dus als er een firewall actief is. Op een systeem zonder regels ontbreken ze, en dat is normaal.

Logbestanden van de webserver: patronen in plaats van onderbuikgevoel

Op Debian en Ubuntu staan de logbestanden onder /var/log/nginx/access.log respectievelijk /var/log/apache2/access.log. Op de Red Hat-familie heet het Apache-pad /var/log/httpd/access_log, zonder punt voor de extensie. Drie analyses volstaan om te beginnen:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Het onderscheid tussen een aanval en een echte toeloop volgt uit de verhouding tussen deze drie lijsten:

• Verhouding tussen verzoeken en unieke IP's. Tienduizend verzoeken vanaf 6.000 adressen is publiek. Tienduizend verzoeken vanaf 30 adressen is dat niet.
• Vervolgverzoeken. Een echte bezoeker laadt na de HTML-pagina ook stylesheets, scripts en afbeeldingen. Staat er in de padlijst uitsluitend één enkele URL en geen enkel statisch bestand, dan was er geen browser aan het werk.
• Herkomst. Bij een geslaagde campagne staat er in het referrerveld een bron: een nieuwssite, een sociaal netwerk, een zoekmachine. Bij een aanval is dat veld meestal leeg of gevuld met een verzonnen adres.
• Identificatie van het programma. Eén enkele, exact identieke user-agent over tienduizenden verzoeken is een tool. Opvallend zijn ook identificaties van zeer oude browserversies.
• Statuscodes. Overwegend 200 wijst op publiek, een muur van 404 of 499 op geautomatiseerd aftasten respectievelijk op clients die afbreken voordat het antwoord er is.

Wees voorzichtig met zoekmachines: een IP beweert in de user-agent graag Googlebot te zijn. Dat valt alleen te controleren met een reverse lookup gevolgd door een forward lookup. Pas als de reverse naam naar een domein van de aanbieder wijst en die naam weer naar hetzelfde IP herleidt, klopt de bewering.

dig -x 66.249.66.1 +short

Bij een echt Googlebot-adres komt daar een naam als crawl-66-249-66-1.googlebot.com. uit, die u vervolgens met dig +short crawl-66-249-66-1.googlebot.com weer naar hetzelfde IP laat herleiden. Komt er helemaal niets terug, dan kan dat ook aan een server zonder uitgaande DNS-resolutie liggen en is het dus geen bewijs.

En de belangrijkste zin over logbestanden: een aanval op netwerkniveau staat niet in het log van de webserver. Een SYN-flood bereikt de applicatie nooit en laat daar geen enkele regel achter. Een leeg log weerlegt dus helemaal niets, het bakent alleen het niveau af.

De tegenproef: zo wordt een vermoeden een vaststelling

Tot hier hebt u aanwijzingen. Ze worden pas hard door tegenproeven die elk precies één hypothese kunnen weerleggen.

1. Dienst stopzetten. Stop de webserver 30 seconden. Blijft de inkomende pakketsnelheid onveranderd hoog, dan zit de aanval onder de applicatie. Zakt ze in, dan waren het verzoeken aan uw applicatie, kwaadaardig of niet.
2. Binnen tegen buiten. Antwoordt curl via 127.0.0.1 in milliseconden terwijl de aanvraag van buitenaf in een timeout loopt, dan is de applicatie gezond en is de lijn het probleem.
3. Tweede meting. Herhaal de pakketmeting twee minuten later. Aanvallen houden aan of komen in golven terug. Een eenmalige piek was een piek.
4. Blik van buitenaf. Een externe bereikbaarheidstest vanaf meerdere locaties scheidt "voor iedereen onbereikbaar" van "alleen voor u onbereikbaar". Het tweede geval is meestal een routerings- of providerprobleem aan de kant van de waarnemer, geen aanval.
5. Richting controleren. Vergelijk rx_packets met tx_packets. Is de uitgaande snelheid de opvallende, dan wordt u niet aangevallen, maar valt uw server zelf aan. Dan is hij gecompromitteerd of wordt hij als reflector misbruikt, en verandert de urgentie van het geval onmiddellijk.

Waaraan u merkt dat de diagnose houdt: u kunt in één zin zeggen welk protocol op welke poort met welke snelheid binnenkomt, inkomend of uitgaand, en u hebt twee onafhankelijke metingen die hetzelfde laten zien. Alles daaronder is een vermoeden.

Als er geen meetbaar spoor is

Vier situaties die regelmatig voor verwarring zorgen:

• U komt helemaal niet meer op de server. Bij een volgelopen lijn komt ook SSH er niet meer doorheen. De toegang loopt dan via de console in het klantenpaneel, die los van de netwerkverbinding van het systeem werkt. Precies daarvoor is ze bedoeld.
• De dienst was weg, op de server staat niets. Bij filtering die ervoor zit is dat de regel, niet de uitzondering. Wordt de aanval in het netwerk opgevangen, dan ziet het systeem alleen een korte deuk. Het bewijs staat dan in de verkeersgrafiek in het klantenpaneel.
• Het log stopt midden in het incident. Controleer of er intussen een logrotatie is gelopen, het oudere materiaal ligt er als access.log.1 of access.log.2.gz naast. Is access_log in de configuratie uitgeschakeld of gebufferd, dan ontbreken de laatste regels simpelweg.
• De kernel zwijgt. Op systemen op containerbasis hoort de ringbuffer bij het hostsysteem, dmesg toont daar niets eigens. Op een KVM-rootserver met een eigen kernel speelt dat niet.

Wat u documenteert voordat u de provider benadert

Een melding met "de server was vanmiddag traag" verlengt de afhandeling met meerdere rondes. Een melding met meetwaarden wordt meteen opgepakt. Verzamel de gegevens zolang het incident loopt, want de tellers in /proc worden bij een herstart teruggezet.

mkdir -p /root/incident && cd /root/incident
date -u > 01-tijd.txt
ss -s > 02-sockets.txt
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn > 03-toestanden.txt
ss -Htn state established | awk '{print $4}' | sed 's/:[^:]*$//' | sort | uniq -c | sort -rn | head -50 > 04-top-ips.txt
ip -s link > 05-interfaces.txt
sar -n DEV 1 10 > 06-pakketsnelheid.txt
dmesg -T | tail -100 > 07-kernel.txt
nstat -az > 08-tellers.txt

Als de lijn het toelaat, hoort er ook een korte packet capture bij. Begrens die, want een onbegrensde opname op een volle lijn vult de schijf in enkele minuten en maakt het probleem erger:

tcpdump -D
tcpdump -ni "$IF" -s 96 -c 2000 -w /root/incident/opname.pcap

tcpdump -D somt de beschikbare interfaces op, voor het geval de variabele $IF uit het meetgedeelte hierboven niet meer gezet is. Beide aanroepen vereisen rootrechten.

In het ticket horen dan:

1. Het tijdstip van begin en einde, met tijdzone. date -u voorkomt elke discussie daarover.
2. Het betrokken IP-adres en de betrokken poort.
3. De gemeten pakketsnelheid en bandbreedte, uitdrukkelijk met vermelding van de richting.
4. De verdeling over de protocollen en, als dat herkenbaar is, de bronpoorten van de externe adressen.
5. Een handvol voorbeelden van bronadressen, met de aantekening dat afzenders vervalst kunnen zijn.
6. Een fragment uit het log van de webserver met het terugkerende patroon van verzoeken, drie tot vijf regels volstaan.
7. Wat er kort daarvoor is gewijzigd: een deployment, een DNS-omzetting, een reclamecampagne, een nieuw opengezette poort.
8. Het resultaat van de tegenproef: was de dienst via 127.0.0.1 bereikbaar terwijl hij van buitenaf uitviel?

Veelgemaakte denkfouten

• Veel TIME-WAIT-verbindingen als bewijs van een aanval. Ze zijn het normale gevolg van korte HTTP-verbindingen en verdwijnen vanzelf.
• De SYN-flooding-melding als bewijs. Een te klein geconfigureerde listen-backlog veroorzaakt haar ook bij een legitieme belastingspiek.
• Een IP met veel verbindingen blokkeren zonder te controleren. Achter een bedrijfs-NAT, een NAT van een mobiele provider of een proxy die ervoor staat sluit u daarmee hele groepen klanten buiten.
• Uit hoge bandbreedte een aanval afleiden. Controleer eerst de richting. Uitgaande pieken zijn meestal een back-up of een populaire download.
• Uit lege logbestanden "geen aanval" afleiden. Aanvallen op netwerkniveau bereiken de applicatie nooit.
• Tijdens een lopend incident herstarten. De herstart wist alle tellers die u voor de melding nodig had, en de aanval loopt daarna onveranderd door.

Wie deze volgorde één keer geoefend heeft, heeft voor een houdbare vaststelling geen vijf minuten nodig. En wie de meetwaarden meteen in het ticket zet, slaat de vervolgvragen over en komt direct bij de oplossing. Daarbij passen: de checklist voor nieuwe rootservers en Fail2ban instellen voor de nazorg op applicatieniveau.