So erfassen und analysieren Sie einen DDoS-Angriff mit Wireshark (und tcpdump)

Zuerst die Antwort: der Workflow

Einen Angriff auf die eigene Infrastruktur zu analysieren ist eine Aufgabe in fünf Schritten, und jeder Schritt dient dazu, eine Frage zu beantworten: um welchen Angriffsvektor handelt es sich, damit die richtige Mitigation angewendet werden kann. (Was die Vektoren sind und wie jeder davon gestoppt wird, behandelt unser Begleitartikel DDoS-Angriffe erklärt.)

1. Erfassen Sie ein Sample mit tcpdump: kleine Snapshot-Länge, begrenzte Größe, niemals die Wireshark-GUI auf der betroffenen Maschine.
2. Holen Sie den Mitschnitt vom Server und öffnen Sie ihn in Wireshark auf Ihrer Workstation.
3. Trieren Sie mit den Statistics-Menüs: Protocol Hierarchy zeigt Ihnen, was der Traffic ist, Conversations zeigt Ihnen, wer beteiligt ist, I/O Graphs zeigen Ihnen, wann und wie stark.
4. Bestätigen Sie den Vektor mit Display-Filtern: jede Angriffsfamilie hat eine erkennbare Signatur.
5. Setzen Sie die Erkenntnisse in Handeln um: eine Firewall-Regel, wo Filterung auf dem Host hilft, und ein konkreter, umsetzbarer Bericht an Ihren Provider, wo das nicht der Fall ist.

Eine Abgrenzung vor den Werkzeugen: Dies ist eine Anleitung zur defensiven Forensik, zur Analyse von Angriffen auf Infrastruktur, die Sie selbst betreiben, mit Mitschnitten, zu denen Sie berechtigt sind. Wollen Sie üben, bevor Sie es brauchen (eine gute Idee: mitten im Angriff ist ein schlechter Zeitpunkt, Wireshark zu lernen), gibt es öffentliche Angriffsmitschnitte zum Trainieren, aufgelistet am Ende.

Schritt 1: Mitschneiden unter Last, ohne die Lage zu verschlimmern

Der Instinkt, Wireshark auf dem angegriffenen Server zu öffnen, ist doppelt falsch: Die GUI, die Millionen Pakete pro Sekunde seziert, vollendet die Ressourcenerschöpfung, die der Angreifer begonnen hat, und ein naiver Mitschnitt schreibt vollständige Pakete mit Angriffs-Line-Rate auf die Platte, Gigabyte pro Minute. Das richtige Werkzeug auf dem Opfer ist tcpdump (oder dumpcap, die Capture-Engine von Wireshark, falls installiert), so konfiguriert, dass es günstig bleibt:

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

Warum jedes Flag seine Daseinsberechtigung hat:

• -s 128 begrenzt die pro Paket erfassten Bytes. Für die Vektoridentifikation brauchen Sie Header, keine Payloads; Ethernet- + IP- + TCP/UDP-Header plus etwas Spielraum passen bequem in 128 Bytes. Das wiegt schwerer, als es aussieht: Die Standard-Snapshot-Länge von modernem tcpdump beträgt 262,144 Bytes, weshalb erst eine explizit kleine Snaplen die Datei klein und die Kosten pro Paket niedrig hält.
• -n deaktiviert die Namensauflösung. Tausende angreifende IPs per DNS aufzulösen (womöglich während Ihre Leitung ausgelastet ist) ist Selbstsabotage.
• -c 500000 stoppt nach einer halben Million Pakete, egal was passiert. Ein begrenzter Mitschnitt kann Ihre Platte nicht füllen.
• -w file schreibt rohe Pakete für die spätere Analyse, statt sie ins Terminal zu dekodieren (Dekodieren kostet CPU, das Terminal kostet die Bandbreite Ihrer SSH-Sitzung).

Hält der Angriff an und wollen Sie durchgehende Sichtbarkeit statt eines einzelnen Samples, nutzen Sie einen Ringpuffer, damit die Plattennutzung konstant bleibt, egal wie lange er läuft:

# 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

Zwei praktische Hinweise. Erstens: Fügen Sie einen Capture-Filter hinzu, um Rauschen zu reduzieren, wenn Sie das Ziel bereits kennen, etwa tcpdump ... dst host 203.0.113.10 (durch Ihre eigene Adresse ersetzen; die Beispiele in dieser Anleitung nutzen Dokumentationsbereiche). Zweitens: Bei extremen Paketraten verwirft selbst tcpdump Pakete; es meldet beim Beenden, wie viele. Für die Vektoridentifikation ist das unproblematisch: Ein Sample reicht aus, und statistische Wahrheit übersteht Verluste. (Brauchen Sie vollständige Erfassung bei hohen Raten, ist das Spezialgebiet: dumpcap mit großem Puffer, oder Sampling-Technologien wie sFlow auf Switch-Ebene, für die Triage aber nicht erforderlich.)

Schritt 2: den Mitschnitt von der Maschine holen

Die Analyse findet auf Ihrer Workstation statt, nicht auf dem verwundeten Server:

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

Öffnen Sie ihn in Wireshark; aktuell stabil ist die 4.6er-Serie. Ist die Datei trotz Ihrer Begrenzungen riesig, gilt Wiresharks eigener Hinweis zur Performance: Dateien jenseits weniger Hundert Megabyte werden träge, schneiden Sie also zuerst ein Stück heraus (editcap -c 1000000 big.pcap slice.pcap teilt nach Paketanzahl; editcap wird mit Wireshark ausgeliefert).

Schritt 3: Triage, drei Statistics-Fenster

Beginnen Sie nicht damit, durch Pakete zu scrollen; beginnen Sie mit den aggregierten Ansichten. Drei Fenster, der Reihe nach:

Protocol Hierarchy (Statistics → Protocol Hierarchy)

Ein Blick beantwortet "was ist dieser Traffic?": der Protokollbaum mit Paket- und Byte-Prozentsätzen. Der Mitschnitt eines gesunden Webservers wird von TCP/TLS dominiert. Ein Angriffsmitschnitt ist meist grotesk verzerrt: 95 % UDP, wo Sie gar keins bedienen, oder eine Wand aus nackten TCP-Paketen ohne Anwendungsschichtprotokoll darüber (die Signatur einer Flood aus Handshake-Paketen, die nie zu Verbindungen werden).

Conversations (Statistics → Conversations)

Die Wer-spricht-mit-wem-Tabelle, sortierbar nach Paketen, Bytes und Dauer. Was Sie daraus lesen:

• Streuung der Quellen. Zehntausend Quelladressen, die jeweils ein paar hundert Pakete an ein Ziel senden, sind eine verteilte Flood (oder Spoofing; Schritt 4 unterscheidet beides). Eine Handvoll Quellen, die Millionen Pakete senden, können Sie noch heute per Null-Route sperren.
• Sortieren Sie nach Paketen, nicht nach Bytes, bei Paketraten-Angriffen: Eine SYN-Flood ist bei der Paketanzahl enorm und bei den Bytes bescheiden.
• Der Unterschied zwischen dem UDP-Tab und dem TCP-Tab entscheidet die Familie oft schon von allein.

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

Traffic über die Zeit. Setzen Sie die Y-Achse auf packets/sec (relevante Angriffe sind meist Paketraten-Anomalien, und Byte-Grafiken unterschätzen Floods mit kleinen Paketen), und fügen Sie Grafiklinien mit Filtern hinzu, um Traffic-Klassen zu vergleichen. Eine Linie für tcp.flags.syn == 1 && tcp.flags.ack == 0 gegen eine für den gesamten Traffic zeigt zum Beispiel genau, wann eine SYN-Flood begann und ob sie konstant oder pulsierend verläuft. Angriffsbursts von Sekunden bis wenigen Minuten sind die Norm, nicht die Ausnahme; die meisten echten Angriffe sind kurz.

Schritt 4: den Vektor mit Display-Filtern bestätigen

Nun die konkreten Signaturen. Geben Sie diese in Wiresharks Display-Filterleiste auf Ihrem Mitschnitt ein.

SYN-Flood

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

Das ist jedes initiale SYN. In legitimem Traffic sind SYNs ein winziger Bruchteil des Ganzen, und jedem folgt ein vollständiger Handshake. Bei einer SYN-Flood matcht dieser Filter einen riesigen Anteil des Mitschnitts, und die Folgeschritte kommen nie. Gegenproben:

• Vergleichen Sie die Anzahl mit tcp.flags.syn == 1 && tcp.flags.ack == 1 (den SYN-ACKs des Servers) und mit Traffic aus etablierten Verbindungen. Tausende SYNs, keine abgeschlossenen Conversations → Flood bestätigt.
• Gespoofte oder echte Quellen? Betrachten Sie ip.ttl über die gesamte Flood: echte Botnet-Clients kommen mit der natürlichen Streuung an TTLs an, die Sie bei vielfältigen Netzwerkpfaden erwarten würden; naive Spoofing-Tools senden oft einheitliche oder sauber gemusterte TTLs, identische Window Sizes und Sequenznummern ohne organische Vielfalt. Quellen, die nie auf Ihr SYN-ACK antworten, passen zu Spoofing; Quellen, die Handshakes abschließen und dann angreifen, sind echte Maschinen.

UDP-Amplification / Reflection

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

Reflektierter Angriffs-Traffic kommt vom bekannten Port des missbrauchten Dienstes, DNS (53), NTP (123), CLDAP (389), memcached (11211), SSDP (1900), CharGEN (19), weil es tatsächlich dieser Dienst ist, der Anfragen beantwortet, die der Angreifer in Ihrem Namen gesendet hat. Bestätigende Anzeichen:

• Große, oft fragmentierte Pakete: Amplification bedeutet, dass die Antworten groß sind; prüfen Sie Statistics → Packet Lengths auf eine Verteilung, die am oberen Ende klemmt, sowie ip.flags.mf == 1 || ip.frag_offset > 0 für Fragmente.
• Speziell für DNS: dns.flags.response == 1-Traffic, zu dem Sie keine passenden Queries haben, sowie amplification-freundliche Query-Typen in den Antworten (dns.qry.type == 255, die klassische ANY-Query).
• Die "Quellen" hier sind Reflektoren: selbst Opfer, keine Angreifer. Sie einzeln zu blockieren ist Whack-a-Mole; das umsetzbare Ergebnis lautet "UDP-Quellport N Richtung meiner Adresse upstream droppen", genau die Art von Regel, die die Mitigation Ihres Providers (oder eine Netzwerk-Edge-Firewall) gut anwendet.

ICMP-Flood

Protocol Hierarchy macht diese von allein offensichtlich; bestätigen Sie mit icmp.type == 8 (Echo Requests) in absurden Raten aus vielen Quellen.

HTTP(S)-Floods, und der Verschlüsselungsvorbehalt

Bei Klartext-HTTP können Sie in Wireshark tief einsteigen: http.request-Raten pro Quelle in Conversations, wiederholte identische URIs (http.request.uri contains "/search"), archaische oder fehlende User-Agents. Die meisten Floods zielen heute jedoch auf HTTPS, und ein Mitschnitt kann ohne die Session-Keys des Servers nicht in TLS hineinsehen. Seien Sie ehrlich über diese Grenze: Aus dem Mitschnitt können Sie weiterhin feststellen, dass es sich um einen Angriff auf Anwendungsebene handelt. Ein Sturm kurzlebiger TLS-Verbindungen zeigt sich als tls.handshake.type == 1 (ClientHellos) in anomalen Raten pro Quelle, aber was angefragt wird, zeigen die Access Logs Ihres Webservers, nicht das pcap. Analysieren Sie L7-Floods mit beidem: Der Mitschnitt belegt das Verbindungsmuster, die Logs zeigen die URIs und Header.

Schritt 5: von den Erkenntnissen zur Mitigation

Der Sinn der Analyse ist der Satz, den sie Ihnen zu schreiben ermöglicht. Vergleichen Sie:

"Wir werden geDDoSt, bitte helft uns."

"Seit 14:02 UTC erhalten wir ~3.5 Mio. pps NTP-Reflection (UDP-Quellport 123, Pakete von ~1,200 Byte, viele Fragmente) auf 203.0.113.10. Könnt ihr UDP src 123 Richtung dieser Adresse am Edge droppen?"

Die zweite bekommt innerhalb von Minuten einen präzisen Upstream-Filter angewendet. Routen Sie Ihre Erkenntnisse nach dem, was Sie herausgefunden haben:

• Volumetrisch (Amplification, UDP-Floods): immer upstream; die Pakete haben Ihren Uplink bereits durchquert, Regeln auf dem Host helfen also nicht mehr. Geben Sie die Vektorsignatur an Ihren Provider weiter oder wenden Sie sie in einer Self-Service-Edge-Firewall an, falls vorhanden.
• SYN-Floods: prüfen Sie, ob SYN Cookies aktiv sind (sysctl net.ipv4.tcp_syncookies), begrenzen Sie neue Verbindungen per Rate-Limit, und geben Sie die Signatur an Upstream weiter, wenn das Volumen übersteigt, was der Host bequem verkraftet.
• L7-Floods: Ihr Reverse Proxy und Ihre WAF: Request-Limits pro Quelle, Caching, Challenges für das auffällige Muster aus den Access Logs.

Auf dem Host drückt nftables die Notfallregeln kompakt aus (die Grundlagen finden Sie in unserer Firewall-Baseline und in iptables vs. nftables):

# 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

Sichern Sie danach den Mitschnitt, die Filter, die den Vektor identifiziert haben, und die Regel, die ihn gestoppt hat. Angriffe wiederholen sich; der zweite Vorfall sollte fünf Minuten dauern.

Üben, bevor Sie es brauchen

Mitten im Vorfall ist der falsche Moment, um diesen Workflow zu lernen. Öffentliche Datensätze lassen Sie legal üben:

• StopDDoS packet captures: anonymisierte Real-World- und Labor-DDoS-pcaps, die genau die Vektoren oben abdecken: DNS-/NTP-/CLDAP-/memcached-Reflection, SYN- und UDP-Floods. Das beste Übungsset für diesen Artikel; öffnen Sie eins und durchlaufen Sie die Triage-Abfolge.
• CIC-DDoS2019: ein akademischer Datensatz (University of New Brunswick) mit rohen pcaps von ~13 gelabelten Angriffstypen, vermischt mit gutartigem Traffic; umfangreicher, geeignet für tiefere Studien.
• Die Sample Captures des Wireshark-Wikis enthalten etwas historischen Angriffs-Traffic (Fragmentierungsangriffe, Wurm-Traffic), älter, aber gut geeignet, um den Statistics-Workflow zu üben.

Häufig gestellte Fragen

Kann Wireshark einen DDoS-Angriff stoppen?

Nein. Wireshark ist ein Mikroskop, kein Schild. Seine Aufgabe im Vorfall ist Diagnose: Ihnen zu zeigen, mit welchem Vektor Sie es zu tun haben, damit die eigentliche Mitigation (Upstream-Scrubbing, Edge-Filter, Rate Limits, WAF-Regeln) korrekt ausgerichtet werden kann. Das Stoppen geschieht in der Mitigationsschicht Ihres Providers und in Ihrer Firewall, wie in unserem DDoS-Schutzleitfaden behandelt.

Sollte ich tcpdump oder Wireshark verwenden?

Beides, nacheinander: tcpdump (oder dumpcap) erfasst auf dem Server (es ist leichtgewichtig, headless und sicher auf einer Maschine unter Stress zu betreiben), und Wireshark analysiert die resultierende Datei auf Ihrer Workstation, wo seine Dissectors und Statistik-Werkzeuge glänzen. Die Wireshark-GUI auf einem angegriffenen Produktionsserver zu betreiben ist die eine klar falsche Antwort: Sie verbraucht genau die CPU und den Speicher, die der Angriff zu erschöpfen versucht.

Wie lang sollte der Mitschnitt sein?

Kürzer, als die Intuition nahelegt: Dreißig Sekunden Angriffs-Traffic reichen normalerweise völlig aus, um einen Vektor zu identifizieren, weil Floods statistisch monoton sind: Millionen nahezu identischer Pakete. Begrenzen Sie jeden Mitschnitt (-c für die Anzahl, oder -C/-W für Ringpuffer), damit er die Platte nicht füllen kann, und bevorzugen Sie mehrere kurze Samples gegenüber einer riesigen Datei; ein mehrere Gigabyte großes pcap bringt vor allem eine träge Wireshark-Sitzung, nicht mehr Erkenntnis.

Der Angriff läuft über HTTPS. Ist Mitschneiden dann sinnlos?

Nicht sinnlos, nur begrenzt. Der Mitschnitt offenbart weiterhin die Geschichte auf Verbindungsebene: Quellverteilung, Verbindungsraten, TLS-Handshake-Floods, Paket-Timing, genug, um "Flood auf Anwendungsebene" zu bestätigen und die Clients zu profilieren. Was er nicht zeigen kann, sind die Klartext-Requests innerhalb von TLS, kombinieren Sie das pcap also mit den Access Logs Ihres Webservers, die die entschlüsselte Request-Zeile, Header und Timing für jeden tatsächlich verarbeiteten Request festhalten.

Einsatz bei Serverside

Der beste Zeitpunkt für diese Analyse ist, während Ihr Server erreichbar bleibt, wofür Always-on-Mitigation da ist. Jeder dedicated Server in unserem Netzwerk sitzt hinter Always-on-DDoS-Mitigation auf ASN 55285: Angriffe werden automatisch am Edge gescrubbt, und die Self-Service-Edge-Firewall lässt Sie genau die Art vektorspezifischer Drop-Regeln anwenden, die diese Anleitung Sie herzuleiten lehrt, upstream Ihres Ports, wo volumetrischer Traffic gestoppt werden muss. Provisioning in unter einer Minute, und KVM-Konsolenzugriff, wenn Sie out-of-band an einer Maschine arbeiten möchten.

Runden Sie die Reihe ab mit DDoS-Angriffe erklärt: Formen und Schutz, sinnvollen Standard-Firewall-Regeln und iptables vs. nftables.