DDoS-Angriff erkennen: woran Sie ihn zweifelsfrei erkennen

Der Dienst antwortet nicht mehr, die Auslastungsanzeige steht oben an, und im Chat steht die Frage: werden wir angegriffen? Diese Frage lässt sich messen. Sie lässt sich sogar ziemlich schnell messen, wenn man weiß, welche vier Zahlen man in welcher Reihenfolge ansieht und welche Gegenprobe aus einem Verdacht einen Befund macht.

Dieser Beitrag behandelt ausschließlich die Diagnose. Es geht nicht darum, einen Angriff abzuwehren, sondern darum, ihn zweifelsfrei von einem Lastproblem, einem Softwarefehler oder schlicht von Erfolg zu unterscheiden. Wer wissen will, was ein DDoS-Angriff technisch ist, findet das unter Was ist ein DDoS-Angriff. Wer nach dem Befund handeln will, liest weiter unter Server vor DDoS-Angriffen schützen.

Vier Verdächtige, ein Symptom

"Server ist langsam" ist kein Befund, sondern ein Symptom mit mindestens vier plausiblen Ursachen. Bevor Sie ein einziges Kommando eintippen, sollten Sie wissen, welche Muster Sie eigentlich unterscheiden wollen.

Der vierte Verdächtige fehlt in dieser Tabelle, weil er keine eigene Spalte braucht: geplante Arbeiten. Backups, Reindizierungen, Log-Rotationen und Paketaktualisierungen laufen zu vorhersagbaren Zeiten. Ein Blick auf systemctl list-timers und die Crontabs kostet zehn Sekunden und beendet erstaunlich viele Angriffsverdachtsfälle.

Die ersten 60 Sekunden: vier Zahlen

Erheben Sie in dieser Reihenfolge vier Werte. Die Kombination ist aussagekräftig, jeder einzelne Wert für sich ist es nicht.

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

Die Deutung:

• Hohe Last, hohe Netzlast, viele halboffene Verbindungen, aber 127.0.0.1 antwortet in Millisekunden: das Problem sitzt vor der Anwendung, also auf der Netzwerkebene. Das ist das klassische Bild eines Angriffs.
• Hohe Last, normale Netzlast, 127.0.0.1 antwortet langsam: Anwendung oder Datenbank. Kein Angriff, sondern Arbeit für den Entwickler.
• Niedrige Last, hohe Netzlast: stark verdächtig. Ein Paketsturm, der gar nicht erst bis in die Anwendung durchdringt, verbraucht wenig CPU und viel Leitung.
• Alles niedrig, Dienst trotzdem von außen nicht erreichbar: siehe weiter unten, der Abschnitt über Fälle ohne messbare Spur.

Für den Lastwert selbst gilt: /proc/loadavg zählt auch Prozesse mit, die auf Ein- und Ausgabe warten. Ein Wert von 40 bei vier Kernen kann sowohl ein Angriff als auch eine überlastete Festplatte sein. vmstat 1 5 trennt das sauber, die Spalte r zeigt rechenbereite Prozesse, b blockierte und wa den Wartezeitanteil.

Verbindungen zählen: ss statt netstat

Fast alle Anleitungen im Netz beginnen mit netstat. Auf einem aktuellen System endet das so:

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

netstat gehört zum Paket net-tools, das auf Debian 12, Debian 13, Ubuntu 22.04 und Ubuntu 24.04 in Standardinstallationen nicht mehr enthalten ist. Auf der Red-Hat-Familie (AlmaLinux, Rocky, RHEL, Oracle Linux) ebenfalls nicht. Nachinstallieren können Sie es, sinnvoller ist aber ss aus iproute2: es ist auf praktisch jedem Server vorhanden, deutlich schneller bei vielen Verbindungen und liefert exakt dieselbe Information.

ss -s

Damit die folgenden Befehle alle laufen, brauchen Sie eine Handvoll Pakete, und die heißen je nach Distributionsfamilie unterschiedlich. Das ist die häufigste Stelle, an der eine kopierte Anleitung auf AlmaLinux gleich in der ersten Zeile hängen bleibt:

Auf Debian und Ubuntu also apt-get install -y iproute2 net-tools procps sysstat dnsutils tcpdump, auf der Red-Hat-Familie dnf -y install iproute net-tools procps-ng sysstat bind-utils tcpdump. curl nehmen Sie dort besser nicht mit in die Liste: Es ist als curl-minimal bereits installiert, und das Vollpaket kollidiert damit (curl-minimal ... conflicts with curl). Falls Sie es doch brauchen, hilft dnf -y --allowerasing install curl.

Die erste Zeile nennt die Gesamtzahl der Sockets, die TCP-Zeile schlüsselt auf: estab, closed, orphaned, timewait. Ein hoher timewait-Wert allein ist kein Angriffsindiz, sondern die Normalfolge vieler kurzer HTTP-Verbindungen.

Interessanter ist die Verteilung über die Zustände:

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

Auffällig ist ein großer Block in SYN-RECV. Diese Verbindungen wurden begonnen, aber nie bestätigt, was genau das Muster eines SYN-Floods ist. Zählen lässt sich das direkt:

ss -Htn state syn-recv | wc -l

Die Spaltenfalle, an der die meisten Einzeiler scheitern

Sobald Sie ss einen Zustandsfilter mitgeben, entfällt die Zustandsspalte in der Ausgabe. Die Gegenstelle steht dann in Spalte 4 statt in Spalte 5. Genau deshalb liefern kopierte Einzeiler aus Foren regelmäßig Unsinn: sie zählen Ports statt IP-Adressen oder geben leere Zeilen aus. Merksatz: ohne Filter ist die Gegenstelle $5, mit Filter $4. Das -H unterdrückt zusätzlich die Kopfzeile, sodass wc -l ohne Korrektur stimmt.

Verbindungen je Quell-IP, IPv6-fest:

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

Das sed schneidet nur den letzten Doppelpunkt samt Port ab. Der verbreitete Ansatz mit cut -d: -f1 funktioniert bei IPv4, zerlegt IPv6-Adressen aber nach dem ersten Block und macht die Auswertung wertlos. Bei IPv6 bleiben die eckigen Klammern stehen, das stört beim Zählen nicht.

Die Interpretation braucht Augenmaß. Hundert Verbindungen von einer einzigen IP können ein Angriff sein, aber genauso gut ein Firmen-NAT, ein Mobilfunk-Carrier-NAT oder ein Reverse-Proxy vor Ihrem Server. Wenn ein Content-Delivery-Netz oder ein Loadbalancer vorgeschaltet ist, sehen Sie ohnehin nur dessen Adressen und müssen stattdessen im Webserver-Log auf X-Forwarded-For ausweichen.

Für UDP gilt derselbe Aufbau mit -u. Und um überhaupt zu wissen, welcher Dienst auf welchem Port lauscht:

ss -tulnp

Netzwerklast und Paketrate richtig messen

Bandbreite in Megabit ist die Zahl, die jeder nennt. Die aussagekräftigere ist die Paketrate. Ein Angriff mit 200.000 winzigen Paketen pro Sekunde bringt einen Server zum Erliegen, obwohl die Bandbreite harmlos aussieht.

Zuerst der Schnittstellenname, denn eth0 ist längst nicht überall die richtige Antwort. Übliche Namen sind ens3, enp1s0 oder eth0:

ip -br link

Danach zwei Messungen im Abstand einer Sekunde, ganz ohne Zusatzpakete. Der Name der Schnittstelle wird dabei aus der Standardroute geholt, statt ihn hinzuschreiben:

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)) Pakete/s eingehend auf $IF"

Die Umständlichkeit hat einen handfesten Grund. Schreiben Sie hier fest eth0 hinein und heißt die Schnittstelle in Wirklichkeit ens3 oder enp1s0, wie es bei den meisten KVM-Servern der Fall ist, dann gibt der Befehl zwar zweimal cat: /sys/class/net/eth0/statistics/rx_packets: No such file or directory aus, meldet danach aber seelenruhig 0 Pakete/s eingehend und beendet sich mit Rückgabewert 0. In einem Artikel über Angriffserkennung ist das die gefährlichste aller Varianten: Sie lesen null Pakete, geben Entwarnung, und der Angriff läuft weiter. Das || exit 1 verhindert genau das.

Dasselbe mit rx_bytes ergibt die Bytes pro Sekunde. Aus beiden Werten berechnen Sie die durchschnittliche Paketgröße, und die verrät die Angriffsart:

• unter 100 Byte im Mittel bei sehr hoher Paketrate: SYN-, ACK- oder UDP-Flood. Das Ziel ist die Paketverarbeitung, nicht die Leitung.
• 1200 bis 1500 Byte bei hoher Bandbreite, Quellports 53, 123, 389 oder 11211: Reflexions- und Verstärkungsangriff. Die Quell-IPs sind fremde Server, nicht die Angreifer.
• normale Größenverteilung, saubere HTTP-Anfragen: Anwendungsebene. Dann entscheidet das Webserver-Log, nicht der Paketzähler.

Komfortabler geht es mit sar aus dem Paket sysstat:

sar -n DEV 1 3

Stolperstelle: Die Live-Messung funktioniert sofort nach der Installation, die historische Auswertung mit sar -f dagegen nicht. Auf Debian und Ubuntu ist die Datensammlung ab Werk abgeschaltet, in /etc/default/sysstat steht ENABLED="false". Wer das erst im Angriffsfall bemerkt, hat keine Vergleichswerte von vorgestern. Das ist der Grund, dieses Paket vorsorglich zu aktivieren und nicht erst im Ernstfall.

Und die wichtigste Einschränkung überhaupt: im Server messen Sie nur, was durchgekommen ist. Liegt eine Filterung davor, sehen Sie einen Bruchteil des tatsächlichen Volumens oder gar nichts. Die verlässliche Zahl steht im Traffic-Graphen im Kundenbereich, nicht in /proc/net/dev.

Kernel-Meldungen lesen

Der Kernel protokolliert Überlastsituationen, die auf Anwendungsebene unsichtbar bleiben. Auf Ubuntu und aktuellen Debian-Versionen ist der Ringpuffer für normale Benutzer gesperrt, ohne sudo erscheint:

dmesg: read kernel buffer failed: Operation not permitted

Das ist keine Fehlfunktion, sondern kernel.dmesg_restrict=1. Mit Root-Rechten und Zeitstempeln:

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

Die Meldung, nach der die meisten suchen, lautet im Wortlaut:

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

Es gibt zwei Varianten und einen Formatunterschied, den man kennen sollte:

• Sending cookies bedeutet, dass SYN-Cookies aktiv sind und die Verbindungen weiterhin bedient werden. Dropping request erscheint stattdessen, wenn net.ipv4.tcp_syncookies auf 0 steht. Dann werden Anfragen verworfen, echte Besucher inklusive.
• Ältere Kernel nennen nur die Portnummer, neuere zusätzlich die Lauschadresse in der Form 0.0.0.0:443. Auf Debian 12 sehen Sie daher die kurze Form, auf Debian 13 und Ubuntu 24.04 die lange. Wer nach dem exakten alten Wortlaut grept, findet auf neuen Systemen nichts.

Wichtig für die Ehrlichkeit der Diagnose: diese Meldung beweist keinen Angriff. Sie erscheint auch, wenn eine Anwendung mit einem zu kleinen Listen-Backlog arbeitet und ein legitimer Lastschub sie überrennt. Sie ist ein Indiz, das durch andere Messwerte gestützt werden muss.

Die zugehörigen Zähler liefert nstat:

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

Auch hier eine Stolperstelle: nstat merkt sich beim Aufruf einen Zwischenstand und zeigt beim nächsten Mal nur noch die Differenz. Das ist gewollt und für die Messung sogar praktisch, überrascht aber jeden, der beim zweiten Aufruf plötzlich Nullen sieht. Mit -a erzwingen Sie Absolutwerte, mit -s unterdrücken Sie das Fortschreiben.

Zwei weitere Meldungen, die im Angriffsfall regelmäßig auftauchen und beide zu Paketverlust bei legitimen Besuchern führen:

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

Den Füllstand der Verbindungsverfolgung prüfen Sie mit cat /proc/sys/net/netfilter/nf_conntrack_count im Vergleich zu nf_conntrack_max. Beide Dateien existieren nur, wenn das Modul geladen ist, also wenn eine Firewall aktiv ist. Auf einem System ohne Regeln fehlen sie, das ist normal.

Webserver-Protokolle: Muster statt Bauchgefühl

Auf Debian und Ubuntu liegen die Protokolle unter /var/log/nginx/access.log beziehungsweise /var/log/apache2/access.log. Auf der Red-Hat-Familie heißt der Apache-Pfad /var/log/httpd/access_log, ohne Punkt vor der Endung. Drei Auswertungen genügen fürs Erste:

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

Die Unterscheidung zwischen Angriff und echtem Ansturm ergibt sich aus dem Verhältnis dieser drei Listen:

• Verhältnis Anfragen zu eindeutigen IPs. Zehntausend Anfragen von 6.000 Adressen sind Publikum. Zehntausend Anfragen von 30 Adressen sind es nicht.
• Folgeanfragen. Ein echter Besucher lädt nach der HTML-Seite Stylesheets, Skripte und Bilder. Wenn in der Pfadliste ausschließlich eine einzige URL steht und keine einzige statische Datei, war kein Browser am Werk.
• Herkunft. Bei einem Werbeerfolg steht im Referrer-Feld eine Quelle: eine Nachrichtenseite, ein soziales Netzwerk, eine Suchmaschine. Bei einem Angriff ist das Feld typischerweise leer oder mit einer erfundenen Adresse gefüllt.
• Kennung des Programms. Ein einziger, exakt identischer User-Agent über zehntausende Anfragen ist ein Werkzeug. Auffällig sind auch Kennungen sehr alter Browserversionen.
• Statuscodes. Überwiegend 200 spricht für Publikum, ein Wall aus 404 oder 499 für automatisiertes Abklopfen beziehungsweise für Clients, die vor der Antwort abbrechen.

Vorsicht bei Suchmaschinen: Eine IP behauptet im User-Agent gern, Googlebot zu sein. Prüfen lässt sich das nur über einen Rückwärts- und anschließenden Vorwärtsauflösungstest. Erst wenn der Rückwärtsname auf eine Domain des Anbieters zeigt und dieser Name wieder auf dieselbe IP auflöst, stimmt die Behauptung.

dig -x 66.249.66.1 +short

Für eine echte Googlebot-Adresse kommt dabei ein Name wie crawl-66-249-66-1.googlebot.com. zurück, den Sie anschließend mit dig +short crawl-66-249-66-1.googlebot.com wieder auf dieselbe IP auflösen lassen. Kommt gar nichts zurück, kann das auch an einem Server ohne ausgehende DNS-Auflösung liegen und ist dann kein Beweis.

Und der wichtigste Satz zu Logs überhaupt: ein Angriff auf Netzwerkebene steht nicht im Webserver-Log. Ein SYN-Flood erreicht die Anwendung nie und hinterlässt dort keine einzige Zeile. Ein leeres Log widerlegt also gar nichts, es grenzt nur die Ebene ein.

Die Gegenprobe: so wird aus dem Verdacht ein Befund

Bis hierher haben Sie Indizien. Belastbar werden sie durch Gegenproben, die jeweils genau eine Hypothese widerlegen können.

1. Dienst anhalten. Stoppen Sie den Webserver für 30 Sekunden. Bleibt die eingehende Paketrate unverändert hoch, liegt der Angriff unterhalb der Anwendung. Bricht sie ein, waren es Anfragen an Ihre Anwendung, egal ob böswillig oder nicht.
2. Innen gegen außen. Antwortet curl über 127.0.0.1 in Millisekunden, während der Abruf von außen in einen Zeitüberschreitungsfehler läuft, ist die Anwendung gesund und die Leitung das Problem.
3. Zweite Messung. Wiederholen Sie die Paketmessung zwei Minuten später. Angriffe halten an oder kommen in Wellen zurück. Eine einmalige Spitze war eine Spitze.
4. Blick von außen. Ein externer Erreichbarkeitstest von mehreren Standorten trennt "für alle unerreichbar" von "nur für Sie unerreichbar". Der zweite Fall ist meist ein Routing- oder Providerproblem beim Betrachter, kein Angriff.
5. Richtung prüfen. Vergleichen Sie rx_packets mit tx_packets. Ist die ausgehende Rate die auffällige, werden Sie nicht angegriffen, sondern Ihr Server greift an. Dann ist er kompromittiert oder wird als Reflektor missbraucht, und der Fall ändert sofort seine Dringlichkeit.

Woran Sie erkennen, dass die Diagnose trägt: Sie können in einem Satz sagen, welches Protokoll auf welchen Port mit welcher Rate trifft, ob eingehend oder ausgehend, und Sie haben zwei unabhängige Messungen, die dasselbe zeigen. Alles darunter ist eine Vermutung.

Wenn es keine messbare Spur gibt

Vier Situationen, die regelmäßig für Verwirrung sorgen:

• Sie kommen gar nicht mehr auf den Server. Bei ausgelasteter Leitung schafft es auch SSH nicht mehr durch. Der Zugang läuft dann über die Konsole im Kundenbereich, die unabhängig von der Netzwerkanbindung des Systems funktioniert. Genau dafür ist sie da.
• Der Dienst war weg, im Server steht nichts. Das ist bei vorgelagerter Filterung der Regelfall, nicht die Ausnahme. Wird der Angriff im Netz abgefangen, sieht das System nur eine kurze Delle. Der Nachweis steht dann im Traffic-Graphen im Kundenbereich.
• Das Log endet mitten im Vorfall. Prüfen Sie, ob in der Zwischenzeit eine Log-Rotation gelaufen ist, das ältere Material liegt als access.log.1 oder access.log.2.gz daneben. Ist access_log in der Konfiguration abgeschaltet oder gepuffert, fehlen die letzten Zeilen schlicht.
• Der Kernel schweigt. Auf containerbasierten Systemen gehört der Ringpuffer dem Wirtssystem, dmesg zeigt dort nichts Eigenes. Auf einem KVM-Rootserver mit eigenem Kernel ist das kein Thema.

Was Sie dokumentieren, bevor Sie den Anbieter kontaktieren

Eine Meldung mit "Server war heute Nachmittag langsam" verlängert die Bearbeitung um mehrere Runden. Eine Meldung mit Messwerten wird sofort bearbeitet. Sammeln Sie, solange der Vorfall läuft, denn die Zähler in /proc werden beim Neustart zurückgesetzt.

mkdir -p /root/vorfall && cd /root/vorfall
date -u > 01-zeit.txt
ss -s > 02-sockets.txt
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn > 03-zustaende.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-paketrate.txt
dmesg -T | tail -100 > 07-kernel.txt
nstat -az > 08-counter.txt

Wenn die Leitung es zulässt, gehört ein kurzer Paketmitschnitt dazu. Begrenzen Sie ihn, ein unbegrenzter Mitschnitt auf einer vollen Leitung füllt die Platte in Minuten und verschärft das Problem:

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

tcpdump -D listet die verfügbaren Schnittstellen auf, falls die Variable $IF aus dem Messabschnitt weiter oben nicht mehr gesetzt ist. Beide Aufrufe brauchen root-Rechte.

Ins Ticket gehören dann:

1. Zeitpunkt von Beginn und Ende, mit Zeitzone. date -u vermeidet jede Diskussion darüber.
2. Betroffene IP-Adresse und betroffener Port.
3. Gemessene Paketrate und Bandbreite, ausdrücklich mit Richtungsangabe.
4. Protokollverteilung und, falls erkennbar, die Quellports der Gegenstellen.
5. Eine Handvoll Beispiel-Quelladressen, mit dem Hinweis, dass Absender gefälscht sein können.
6. Auszug aus dem Webserver-Log mit dem wiederkehrenden Anfragemuster, drei bis fünf Zeilen genügen.
7. Was kurz vorher geändert wurde: Deployment, DNS-Umstellung, Werbekampagne, neue Portfreigabe.
8. Ergebnis der Gegenprobe: war der Dienst über 127.0.0.1 erreichbar, während er von außen ausfiel?

Häufige Fehlschlüsse

• Viele TIME-WAIT-Verbindungen als Angriffsbeweis. Sie sind die normale Folge kurzer HTTP-Verbindungen und verschwinden von selbst.
• Die SYN-Flooding-Meldung als Beweis. Ein zu klein konfigurierter Listen-Backlog erzeugt sie auch bei legitimem Lastschub.
• Eine IP mit vielen Verbindungen sperren, ohne zu prüfen. Hinter Firmen-NAT, Mobilfunk-NAT oder einem vorgeschalteten Proxy sperren Sie damit ganze Kundengruppen aus.
• Aus hoher Bandbreite auf einen Angriff schließen. Prüfen Sie zuerst die Richtung. Ausgehende Spitzen sind meistens ein Backup oder ein beliebter Download.
• Aus leeren Logs auf "kein Angriff" schließen. Angriffe auf Netzwerkebene erreichen die Anwendung nie.
• Im laufenden Vorfall neu starten. Der Neustart löscht alle Zähler, die Sie für die Meldung gebraucht hätten, und der Angriff läuft danach unverändert weiter.

Wer diese Reihenfolge einmal geübt hat, braucht für einen belastbaren Befund keine fünf Minuten. Und wer die Messwerte im Ticket mitliefert, überspringt die Rückfragen und kommt direkt zur Lösung. Passend dazu: die Checkliste für neue Rootserver und Fail2ban einrichten für die Nachbereitung auf Anwendungsebene.