DDoS-Attacke: Was tun? Sofortmaßnahmen in 8 Schritten

Die erste Stunde einer DDoS-Attacke verläuft meistens chaotisch. Drei Leute starten den Server neu, jemand löscht Logs, um Platz zu schaffen, und der Hoster erfährt erst nach 40 Minuten vom Problem. Ein Neustart bringt bei einem laufenden Angriff gar nichts, gelöschte Logs fehlen später für die Anzeige. Die folgende Reihenfolge hat sich bewährt, weil sie das Wichtigste zuerst erledigt: die Leute einbinden, die wirklich filtern können.

DDoS-Attacke, was tun: die ersten 15 Minuten

1. Lage klären, ohne etwas zu verändern

Fünf Minuten Diagnose sparen eine Stunde falscher Maßnahmen. Drei Fragen genügen: Ist die Leitung voll? Sind die Verbindungstabellen voll? Oder ist die Anwendung überlastet?

ss -s
ss -tan state syn-recv | wc -l
iftop -i eth0 -nNP
tail -n 20000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

Wie du die Ausgaben liest, steht im Artikel DDoS-Attacke erkennen. Prüfe auch kurz, ob es nicht doch echter Besuch ist, etwa nach einem Newsletter. Die Merkmale dafür findest du unter DDoS oder Traffic-Spitze.

2. Hoster oder Upstream-Provider anrufen

Bei vollen Leitungen und SYN-Floods kann nur der Provider helfen. Je konkreter deine Angaben, desto schneller reagiert er. Eine Meldung wie diese ist ideal:

Server: web01, IP 203.0.113.10
Beginn: 18.10., 14:02 Uhr MESZ
Eingehend ca. 3 Gbit/s UDP, Quellport 123, Port 1 Gbit/s ausgelastet
Bitte um Filterung/Scrubbing für diese IP

Manche Provider schalten die angegriffene IP vorübergehend auf ein Null-Routing, um den Rest des Netzes zu schützen. Dann ist dein Server komplett offline, aber das restliche Rechenzentrum läuft. Frag direkt, ob und wann das passiert.

DDoS-Angriff abwehren: Schutz an der Kante einschalten

3. CDN-Schutz verschärfen

Liegt die Domain bereits hinter Cloudflare, ist der Under Attack Mode das schnellste Werkzeug. Du findest ihn in der Zonen-Übersicht unter den Quick Actions. Jeder Besucher durchläuft dann eine JavaScript-Prüfung, die laut Cloudflare innerhalb von fünf Sekunden entscheidet. Cloudflare selbst beschreibt den Modus als eines der letzten Mittel: Er verfälscht Analytics und blockiert Clients ohne JavaScript, also auch Apps und Webhooks, die deine API ansprechen. Besser ist oft eine Configuration Rule, die ihn nur für die angegriffenen Pfade einschaltet. Details im Artikel DDoS-Schutz mit Cloudflare.

Liegt die Domain noch nicht hinter einem CDN, kannst du sie während des Angriffs umziehen. Das dauert, weil die Nameserver geändert werden müssen und die alte IP bekannt ist. Siehe Schritt 5.

4. Teure Pfade drosseln

Bei Layer-7-Angriffen hilft ein Limit auf die Pfade, die im Log dominieren. Ein Minimalbeispiel für nginx:

limit_req_zone $binary_remote_addr zone=hot:10m rate=2r/s;
limit_req_status 429;

server {
    location /suche {
        limit_req zone=hot burst=5 nodelay;
        proxy_pass http://app;
    }
}

Die Zone gehört in den http-Block. Ein Megabyte Zone speichert laut nginx-Doku rund 8.000 Zustände auf 64-Bit-Systemen, 10 MB reichen also für etwa 80.000 IPs. Wichtig hinter einem CDN: Ohne real_ip_header limitierst du die Adressen des CDN statt der Angreifer. Mehr Varianten stehen im Artikel zum Rate Limiting.

Parallel verlängerst du den Seiten-Cache für nicht angemeldete Besucher und schaltest Funktionen ab, die ohne Cache laufen müssen, etwa die Volltextsuche.

5. Origin-Server abschotten

Ein CDN nützt nichts, wenn der Angreifer die echte Server-IP kennt und direkt angreift. Erlaube auf Port 80 und 443 nur noch die IP-Bereiche deines CDN. Ist die IP schon bekannt, bleibt nur ein Wechsel auf eine neue, die ausschließlich im CDN hinterlegt ist. Prüfe auch MX-Einträge, alte Subdomains und Mail-Header, die die Adresse verraten.

Während und nach dem Angriff: dokumentieren und melden

6. Beweise sichern

Kopiere die Logs, bevor die Rotation sie löscht, und dokumentiere die Integrität:

mkdir -p /root/ddos-2026-10-18
cp /var/log/nginx/access.log* /var/log/nginx/error.log* /root/ddos-2026-10-18/
sha256sum /root/ddos-2026-10-18/* > /root/ddos-2026-10-18/SHA256SUMS

Dazu kommen CDN-Exporte, Screenshots der Graphen, Erpressermails im Originalformat mit Header und alle Ticketnummern.

7. Kommunizieren

Eine Statusmeldung, die nicht auf demselben Server liegt, beruhigt Kunden und entlastet den Support. Zwei Sätze reichen: was los ist, wann das nächste Update kommt. Intern sollte eine Person entscheiden, nicht fünf gleichzeitig.

8. Anzeige erstatten und nachbereiten

Ein DDoS-Angriff kann als Computersabotage nach § 303b StGB strafbar sein. Die Tat wird in vielen Fällen nur auf Antrag verfolgt, deshalb zählt deine Anzeige. Ansprechpartner sind die Polizei, die Online-Wachen der Länder und für Unternehmen die Zentralen Ansprechstellen Cybercrime (ZAC) der Landeskriminalämter. Besonders wichtige und wichtige Einrichtungen im Sinne des BSI-Gesetzes müssen erhebliche Vorfälle außerdem melden, die Erstmeldung spätestens 24 Stunden nach Kenntnis. Wie das konkret abläuft, steht unter DDoS-Anzeige erstatten.

Checkliste: was du auf keinen Fall tun solltest

• Server im Minutentakt neu starten
• Logs löschen, um Speicherplatz zu gewinnen
• die Erpressermail weiterleiten statt sie als Datei mit Header zu sichern
• Lösegeld zahlen
• die neue Server-IP direkt im DNS veröffentlichen
• den Under Attack Mode tagelang anlassen und vergessen

Nach dem Angriff: Schutz dauerhaft einrichten

Wenn es ruhig wird, ist der beste Moment für Vorsorge. Rechne kurz durch, was der Ausfall gekostet hat. Der Artikel zu den Kosten einer DDoS-Attacke zeigt die Rechnung. Danach baust du die Schutzschichten auf, die gefehlt haben: CDN vor der Website, Rate Limits auf teure Pfade, und auf der DNS-Seite Nameserver bei mehr als einem Anbieter, wie im Artikel zu Secondary DNS beschrieben.

Für diesen letzten Teil brauchst du einen Registrar, bei dem du Nameserver frei setzen kannst. Bei betadomain verwaltest du die Nameserver deiner Domains selbst, kannst eine .de-Domain mit DNSSEC absichern und Änderungen über die Domain-API automatisieren, falls du im Notfall per Skript umschalten willst. Druck dir die acht Schritte oben aus und leg sie dorthin, wo sie im Ernstfall jemand findet.

Schritt für Schritt

1. Lage in fünf Minuten klärenMit ss -s, iftop und dem nginx-Access-Log prüfen, ob die Leitung, die Verbindungstabellen oder die Anwendung überlastet sind, und den Beginn mit Uhrzeit notieren.
2. Hoster oder Upstream-Provider informierenTicket oder Notfallnummer nutzen, Zielserver, IP, Beginn und Messwerte nennen und nach Filterung oder Scrubbing fragen.
3. CDN-Schutz verschärfenBei Cloudflare den Under Attack Mode zonenweit oder per Configuration Rule für betroffene Pfade aktivieren, bei anderen CDNs die vergleichbare Challenge-Stufe.
4. Teure Pfade drosselnSuche, Login und API-Endpunkte per nginx limit_req oder WAF-Regel begrenzen und den Seiten-Cache für anonyme Besucher verlängern.
5. Origin-Server abschottenPort 80 und 443 nur für die IP-Bereiche des CDN öffnen, damit der Angriff nicht am Proxy vorbei direkt den Server trifft.
6. Beweise sichernAccess- und Error-Logs kopieren und mit sha256sum hashen, CDN-Analytics exportieren, Erpressermails mit Header speichern, Ticketnummern notieren.
7. Kunden und Team informierenEine kurze Statusmeldung auf einer separat gehosteten Seite oder in sozialen Kanälen veröffentlichen und intern festlegen, wer entscheidet.
8. Anzeige erstatten und nachbereitenAnzeige bei Polizei oder der Zentralen Ansprechstelle Cybercrime erstatten, meldepflichtige Einrichtungen informieren das BSI, danach Schutz dauerhaft einrichten.