Een DDoS-aanval vastleggen en analyseren met Wireshark (en tcpdump)

Eerst het antwoord: de workflow

Een aanval tegen je eigen infrastructuur analyseren is een taak in vijf stappen, en elke stap bestaat om één vraag te beantwoorden: welke aanvalsvector is dit, zodat de juiste mitigatie toegepast kan worden. (Voor wat de vectoren zijn en hoe elk ervan gestopt wordt, zie ons begeleidende artikel, DDoS-aanvallen uitgelegd.)

1. Leg een sample vast met tcpdump: kleine snapshotlengte, begrensde omvang, nooit de Wireshark-GUI op de getroffen machine.
2. Haal de capture van de server en open die in Wireshark op je werkstation.
3. Trieer met de Statistics-menu's: Protocol Hierarchy vertelt je wat het verkeer is, Conversations vertelt je wie erbij betrokken is, I/O Graphs vertellen je wanneer en hoe hard.
4. Bevestig de vector met display filters: elke aanvalsfamilie heeft een herkenbare signatuur.
5. Zet bevindingen om in actie: een firewallregel waar filtering op de host helpt, en een specifiek, uitvoerbaar rapport aan je provider waar dat niet zo is.

Eén afbakening voordat we bij de tooling komen: dit is een gids voor defensieve forensics, het analyseren van aanvallen op infrastructuur die je zelf beheert, met captures die je gerechtigd bent te maken. Wil je oefenen voordat het nodig is (een goed idee: midden in een aanval is een slecht moment om Wireshark te leren kennen), dan zijn er publieke aanvalscaptures om mee te trainen, opgesomd aan het einde.

Stap 1: vastleggen onder belasting zonder de zaak te verergeren

De instinctieve reactie om Wireshark te openen op de aangevallen server is dubbel fout: de GUI die miljoenen packets per seconde ontleedt, maakt het uitputtingswerk af dat de aanvaller begon, en een naïeve capture schrijft volledige packets naar schijf op aanval-line-rate, gigabytes per minuut. Het juiste gereedschap op het slachtoffer is tcpdump (of dumpcap, de capture-engine van Wireshark, als die geïnstalleerd is), zo geconfigureerd dat het goedkoop blijft:

# 30-second sample, headers only, no DNS lookups, bounded packet count
tcpdump -i eth0 -n -s 128 -c 500000 -w /tmp/attack-sample.pcap

Waarom elke vlag zijn plek verdient:

• -s 128 begrenst het aantal bytes dat per packet wordt vastgelegd. Voor vectoridentificatie heb je headers nodig, geen payloads; Ethernet- + IP- + TCP/UDP-headers plus een beetje speling passen ruim in 128 bytes. Dit weegt zwaarder dan het lijkt: de standaard snapshotlengte van moderne tcpdump is 262,144 bytes, dus een expliciete kleine snaplen is wat het bestand klein houdt en de kosten per packet laag.
• -n schakelt naamresolutie uit. Duizenden aanvallende IP's via DNS resolven (mogelijk terwijl je link verzadigd is) is zelfsabotage.
• -c 500000 stopt na een half miljoen packets, wat er ook gebeurt. Een begrensde capture kan je schijf niet vullen.
• -w file schrijft ruwe packets weg voor latere analyse in plaats van te decoderen naar de terminal (decoderen kost CPU; de terminal kost de bandbreedte van je SSH-sessie).

Duurt de aanval voort en wil je doorlopend zicht in plaats van één sample, gebruik dan een ring buffer zodat het schijfgebruik constant blijft, hoe lang het ook duurt:

# rotate at 100 MB, keep at most 10 files (~1 GB ceiling), overwrite oldest
tcpdump -i eth0 -n -s 128 -w /tmp/attack-ring.pcap -C 100 -W 10

Twee praktische kanttekeningen. Ten eerste: voeg een capture filter toe om ruis te beperken als je het doel al kent, bijvoorbeeld tcpdump ... dst host 203.0.113.10 (vervang door je eigen adres; de voorbeelden in deze gids gebruiken documentatiereeksen). Ten tweede: bij extreme packetsnelheden laat zelfs tcpdump packets vallen; het meldt hoeveel bij het afsluiten. Voor vectoridentificatie is dat prima: een sample is alles wat je nodig hebt, en statistische waarheid overleeft drops. (Heb je volledige capture nodig bij hoge snelheden, dan is dat gespecialiseerd terrein: dumpcap met een grote buffer, of samplingtechnieken zoals sFlow op switchniveau, maar voor triage is het niet vereist.)

Stap 2: haal de capture van de machine

Analyse gebeurt op je werkstation, niet op de gewonde server:

scp server:/tmp/attack-sample.pcap .

Open het in Wireshark; de huidige stable is de 4.6-serie. Is het bestand ondanks je begrenzingen toch enorm, dan geldt Wireshark's eigen performance-richtlijn: bestanden boven een paar honderd megabyte worden traag, dus snijd eerst een stuk eraf (editcap -c 1000000 big.pcap slice.pcap splitst op packetaantal; editcap wordt meegeleverd met Wireshark).

Stap 3: triage, drie Statistics-vensters

Begin niet met scrollen door packets; begin met de geaggregeerde weergaven. Drie vensters, in volgorde:

Protocol Hierarchy (Statistics → Protocol Hierarchy)

Eén blik beantwoordt "wat is dit verkeer?": de protocolboom met packet- en byte-percentages. De capture van een gezonde webserver wordt gedomineerd door TCP/TLS. Een aanvalscapture is meestal grotesk scheef: 95% UDP terwijl je dat helemaal niet serveert, of een muur van kale TCP-packets zonder applicatielaagprotocol erbovenop (de signatuur van een flood van handshake-packets die nooit verbindingen worden).

Conversations (Statistics → Conversations)

De wie-praat-met-wie-tabel, sorteerbaar op packets, bytes en duur. Wat je eruit leest:

• Spreiding van bronnen. Tienduizend bronadressen die elk een paar honderd packets naar één bestemming sturen, is een gedistribueerde flood (of spoofing; stap 4 maakt het onderscheid). Een handvol bronnen dat miljoenen packets stuurt, is iets wat je vandaag nog kunt null-routen.
• Sorteer op packets, niet op bytes, bij packetrate-aanvallen: een SYN-flood is enorm in packetaantal en bescheiden in bytes.
• Het onderscheid tussen het UDP-tabblad en TCP-tabblad bepaalt de familie vaak al in zijn eentje.

I/O Graphs (Statistics → I/O Graphs)

Verkeer over tijd. Zet de Y-as op packets/sec (aanvallen die ertoe doen, zijn meestal packetrate-anomalieën, en bytes-grafieken onderschatten floods met kleine packets), en voeg grafieklijnen toe met filters om verkeersklassen te vergelijken. Eén lijn voor tcp.flags.syn == 1 && tcp.flags.ack == 0 tegenover één voor al het verkeer laat bijvoorbeeld precies zien wanneer een SYN-flood begon en of die constant is of pulseert. Aanvalsbursts van enkele seconden tot een paar minuten zijn de norm, niet de uitzondering; de meeste echte aanvallen zijn kort.

Stap 4: bevestig de vector met display filters

Nu de specifieke signaturen. Typ deze in de display-filterbalk van Wireshark op je capture.

SYN-flood

tcp.flags.syn == 1 && tcp.flags.ack == 0

Dat is elke initiële SYN. In legitiem verkeer zijn SYN's een fractie van het totaal en wordt elke SYN gevolgd door een voltooiende handshake. Bij een SYN-flood matcht dit filter een enorm aandeel van de capture, en de vervolgstappen komen nooit. Kruiscontroles:

• Vergelijk aantallen met tcp.flags.syn == 1 && tcp.flags.ack == 1 (de SYN-ACK's van de server) en met verkeer van tot stand gekomen verbindingen. Duizenden SYN's, geen voltooide conversaties → flood bevestigd.
• Gespoofte of echte bronnen? Kijk naar ip.ttl over de hele flood: echte botnetclients komen binnen met de natuurlijke spreiding aan TTL's die je zou verwachten van diverse netwerkpaden; naïeve spoofingtools zenden vaak uniforme of netjes gepatroonde TTL's, identieke window sizes en sequence numbers zonder organische variatie. Bronnen die nooit reageren op je SYN-ACK zijn consistent met spoofing; bronnen die handshakes voltooien en daarna aanvallen zijn echte machines.

UDP-amplification / reflectie

udp.srcport in {53, 123, 389, 11211, 1900, 19}

Gereflecteerd aanvalsverkeer komt van de bekende poort van de misbruikte dienst, DNS (53), NTP (123), CLDAP (389), memcached (11211), SSDP (1900), CharGEN (19), omdat het daadwerkelijk die dienst is, die antwoordt op queries die de aanvaller in jouw naam heeft verstuurd. Bevestigende signalen:

• Grote, vaak gefragmenteerde packets: amplification betekent dat de responses groot zijn; controleer Statistics → Packet Lengths op een distributie die tegen het hoge eind aan zit, en ip.flags.mf == 1 || ip.frag_offset > 0 voor fragmenten.
• Specifiek voor DNS: dns.flags.response == 1-verkeer waar je geen bijpassende queries voor hebt, en amplification-vriendelijke querytypes zichtbaar in de responses (dns.qry.type == 255, de klassieke ANY-query).
• De "bronnen" hier zijn reflectoren: zelf slachtoffers, geen aanvallers. Ze individueel blokkeren is whack-a-mole; de uitvoerbare output is "drop UDP-bronpoort N richting mijn adres, upstream", precies het soort regel dat de mitigatie van je provider (of een edge-firewall op netwerkniveau) goed toepast.

ICMP-flood

Protocol Hierarchy maakt deze vanzelf duidelijk; bevestig met icmp.type == 8 (echo requests) tegen absurde snelheden vanaf veel bronnen.

HTTP(S)-floods, en het encryptievoorbehoud

Voor platte-tekst HTTP kun je diep gaan in Wireshark: http.request-snelheden per bron in Conversations, herhaalde identieke URI's (http.request.uri contains "/search"), archaïsche of afwezige User-Agents. Maar tegenwoordig richten de meeste floods zich op HTTPS, en een packet capture kan niet in TLS kijken zonder de sessiesleutels van de server. Wees eerlijk over die grens: uit de capture kun je nog steeds vaststellen dat het een applicatielaag-aanval is. Een storm van kortstondige TLS-verbindingen is zichtbaar als tls.handshake.type == 1 (ClientHellos) tegen afwijkende snelheden per bron, maar wat er wordt opgevraagd komt uit de access logs van je webserver, niet uit de pcap. Analyseer L7-floods met beide: de capture bewijst het verbindingspatroon, de logs tonen de URI's en headers.

Stap 5: van bevindingen naar mitigatie

Het doel van de analyse is de zin die je ermee kunt schrijven. Vergelijk:

"We worden geDDoSt, help alsjeblieft."

"Sinds 14:02 UTC ontvangen we ~3.5M pps aan NTP-reflectie (UDP-bronpoort 123, packets van ~1,200 byte, veel fragmenten) op 203.0.113.10. Kunnen jullie UDP src 123 richting dat adres droppen op de edge?"

De tweede levert binnen enkele minuten een precies upstream-filter op. Routeer je bevindingen op basis van wat je hebt geleerd:

• Volumetrisch (amplification, UDP-floods): altijd upstream; de packets zijn je uplink al gepasseerd, dus regels op de host helpen niet meer. Geef de vectorsignatuur door aan je provider of pas hem toe in een self-service edge-firewall als je die hebt.
• SYN-floods: controleer of SYN cookies aanstaan (sysctl net.ipv4.tcp_syncookies), rate-limit nieuwe verbindingen, en geef de signatuur door aan upstream als het volume groter is dan wat de host comfortabel opvangt.
• L7-floods: je reverse proxy en WAF: request-limieten per bron, caching, challenges voor het schuldige patroon uit de access logs.

Op de host drukt nftables de noodregels compact uit (zie onze firewall-basis en iptables vs nftables voor de fundamenten):

# emergency: drop NTP-reflection traffic on the host (better: at the edge)
nft add rule inet filter input udp sport 123 drop

# throttle new connections per source during a connection flood
nft add rule inet filter input tcp dport 443 ct state new limit rate over 50/second drop

Bewaar daarna de capture, de filters die de vector identificeerden en de regel die hem stopte. Aanvallen herhalen zich; het tweede incident zou vijf minuten moeten kosten.

Oefenen voordat je het nodig hebt

Midden in een incident is het verkeerde moment om deze workflow te leren. Publieke datasets laten je legaal oefenen:

• StopDDoS packet captures: geanonimiseerde real-world en lab-DDoS-pcaps die precies de vectoren hierboven bestrijken: DNS/NTP/CLDAP/memcached-reflectie, SYN- en UDP-floods. De beste oefenset voor dit artikel; open er één en doorloop de triagevolgorde.
• CIC-DDoS2019: een academische dataset (University of New Brunswick) met ruwe pcaps van ~13 gelabelde aanvalstypes vermengd met onschuldig verkeer; zwaarder, geschikt voor diepere studie.
• De sample captures van de Wireshark-wiki bevatten wat historisch aanvalsverkeer (fragmentatie-aanvallen, wormverkeer), ouder, maar prima om de Statistics-workflow te oefenen.

Veelgestelde vragen

Kan Wireshark een DDoS-aanval stoppen?

Nee. Wireshark is een microscoop, geen schild. De rol in een incident is diagnose: vaststellen met welke vector je te maken hebt, zodat de daadwerkelijke mitigatie (upstream scrubbing, edge-filters, rate limits, WAF-regels) correct gericht kan worden. Het stoppen gebeurt in de mitigatielaag van je provider en in je firewall, zoals behandeld in onze DDoS-beschermingsgids.

Moet ik tcpdump of Wireshark gebruiken?

Allebei, na elkaar: tcpdump (of dumpcap) legt vast op de server (het is lichtgewicht, headless en veilig te draaien op een machine onder druk) en Wireshark analyseert het resulterende bestand op je werkstation, waar de dissectors en statistiektools tot hun recht komen. De Wireshark-GUI draaien op een productieserver die wordt aangevallen is het ene overduidelijk foute antwoord: het verbruikt precies de CPU en het geheugen die de aanval probeert uit te putten.

Hoe lang moet de capture duren?

Korter dan de intuïtie doet vermoeden: dertig seconden aanvalsverkeer is normaal gesproken ruim voldoende om een vector te identificeren, omdat floods statistisch monotoon zijn: miljoenen bijna-identieke packets. Begrens elke capture (-c voor aantal, of -C/-W ring buffers) zodat die de schijf niet kan vullen, en geef de voorkeur aan meerdere korte samples boven één gigantisch bestand; een pcap van meerdere gigabytes levert vooral een trage Wireshark-sessie op, geen extra inzicht.

De aanval loopt over HTTPS. Is vastleggen dan zinloos?

Niet zinloos, alleen begrensd. De capture onthult nog steeds het verhaal op verbindingsniveau: bronspreiding, verbindingssnelheden, TLS-handshake-floods, packet-timing, genoeg om "applicatielaag-flood" te bevestigen en de clients te profileren. Wat niet zichtbaar is, zijn de platte-tekst requests binnen TLS, dus combineer de pcap met de access logs van je webserver, die de gedecodeerde requestregel, headers en timing vastleggen voor elke request die de server daadwerkelijk verwerkte.

Uitrollen op Serverside

Het beste moment voor deze analyse is terwijl je server bereikbaar blijft, en daar dient always-on mitigatie voor. Elke dedicated server op ons netwerk zit achter always-on DDoS-mitigatie op ASN 55285: aanvallen worden automatisch gescrubd op de edge, en de self-service edge-firewall laat je precies het soort vector-specifieke drop-regels toepassen die deze gids je leert afleiden, upstream van je poort, waar volumetrisch verkeer gestopt moet worden. Provisioning binnen een minuut, en KVM-consoletoegang voor wanneer je out-of-band aan een machine wilt werken.

Maak de reeks compleet met DDoS-aanvallen uitgelegd: vormen en bescherming, verstandige standaard firewallregels en iptables vs nftables.