DDoS-Angriff auf deine Website: Was jetzt zu tun ist

Deine Website lädt plötzlich kaum noch oder ist ganz weg, und der Server meldet ein Vielfaches der üblichen Anfragen? Dann steckt womöglich ein DDoS-Angriff dahinter. Am meisten hilft jetzt eine Filterschicht vor deinem Server, denn ein Server, der schon überlastet ist, kann sich nicht mehr selbst verteidigen. In diesem Ratgeber erfährst du, wie du einen Angriff erkennst, was in der ersten Stunde zählt und wie du dich so aufstellst, dass der nächste Angriff deutlich weniger Schaden anrichtet.

Woran du einen DDoS-Angriff erkennst

Bei einem DDoS-Angriff (Distributed Denial of Service) schicken sehr viele Quellen gleichzeitig Anfragen an deine Website, bis echte Besucher nicht mehr durchkommen. Nicht jeder Ansturm ist aber ein Angriff. Ein Newsletter, ein Bericht im Fernsehen oder eine Rabattaktion sehen auf den ersten Blick ähnlich aus. Achte deshalb auf diese Anzeichen:

• Es gibt keinen Anlass. Keine Kampagne, keine Presse, kein Launch, und trotzdem schnellen die Anfragen nach oben.
• Die Anfragen treffen immer dieselben URLs. Oft die Startseite, die Suche, das Login oder Adressen mit zufälligen Parametern wie /?x=83729, die den Cache umgehen sollen.
• Die Herkunft passt nicht. Viele Zugriffe kommen aus Ländern, in denen du gar keine Kunden hast, aus Rechenzentren oder mit identischen bzw. leeren User Agents.
• Niemand kauft. Der Traffic steigt, Bestellungen, Anmeldungen und Verweildauer bleiben aber, wo sie sind.
• Der Server ist am Limit. CPU, PHP-Worker oder Datenbankverbindungen sind ausgereizt, und im Error-Log stapeln sich Timeouts sowie 502-, 503- und 504-Fehler.

Ein Blick ins Access-Log

Hast du Shell-Zugriff, verrät dir das Access-Log schnell eine Menge. Diese Befehle zeigen die aktivsten IP-Adressen und die am häufigsten aufgerufenen Pfade (den Log-Pfad passt du an deinen Server an):

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

Schicken nur eine Handvoll IPs Tausende Anfragen, hast du es mit einem kleinen Angriff zu tun, den du direkt sperren kannst. Sind es dagegen Tausende IPs mit jeweils moderaten Mengen, steckt ein Botnetz dahinter. Das lässt sich auf dem Server selbst kaum noch stoppen.

Welche Arten von Angriffen es gibt

Wenn du grob weißt, womit du es zu tun hast, fällt die richtige Reaktion leichter.

Kleine und mittelgroße Websites trifft es meist auf Layer 7, also mit HTTP-Floods. Dafür brauchen Angreifer keine riesige Bandbreite, denn jede einzelne Anfrage verursacht bei dir teure Arbeit: Seite rendern, Suche ausführen, Datenbank abfragen. Schon einige hundert ungecachte Anfragen pro Sekunde können einen typischen Shop oder ein CMS in die Knie zwingen.

Die erste Stunde: Schritt für Schritt

Bleib ruhig und arbeite die Punkte der Reihe nach ab. Notiere dir, was du wann tust, denn das brauchst du später noch.

1. Lage prüfen und Bescheid geben

Schließ zuerst aus, dass ein fehlerhaftes Deployment, ein kaputtes Plugin oder ein echter Besucheransturm die Ursache ist. Danach informierst du alle, die es wissen müssen: dein Team, deine Agentur und deinen Hoster. Hoster sehen Angriffe oft schon in ihrem Netzwerk-Monitoring und filtern bereits. Manchmal leiten sie deine IP sogar ins Leere (Null-Routing), um ihre anderen Kunden zu schützen.

2. Mit dem Hoster sprechen

Frag konkret nach: Was sieht der Hoster, welchen Schutz bietet er und kann er schon auf Netzwerkebene filtern? Manche Tarife enthalten einen Basisschutz, andere nicht. Wird dein Server per Null-Routing abgeschaltet, brauchst du eine Filterschicht davor, bevor er wieder online geht.

3. Sperren, was du eindeutig erkennst

Kommt der Angriff von wenigen IPs oder Netzbereichen, sperrst du sie in der Firewall oder in der Webserver-Konfiguration. Zielt er auf eine teure URL wie die Suche, begrenzt du dort vorübergehend die Anfragen oder schaltest sie kurz ab. Stammt der Traffic größtenteils aus Ländern, die du nicht belieferst, verschafft dir eine befristete Ländersperre oder ein Captcha etwas Luft. Das sind allerdings Notlösungen und keine Strategie.

4. Eine Filterschicht vor den Server setzen

Die eigentliche Lösung ist, schädlichen Traffic abzufangen, bevor er deinen Server überhaupt erreicht. Ein Reverse Proxy oder ein CDN mit DDoS-Schutz filtert die Anfragen am Edge, und dein Server bekommt nur noch zu sehen, was durchgelassen wird. Die Einrichtung läuft meist über einen Wechsel der Nameserver deiner Domain, der greift, sobald die DNS-Caches abgelaufen sind. Machst du das mitten im Angriff, halte dich an eine Checkliste, damit keine E-Mails oder DNS-Einträge verloren gehen. Wie das geht, steht in unserem Ratgeber Nameserver ändern ohne Ausfall.

5. Jede Anfrage billiger machen

Solange der Angriff läuft, sollte jede Anfrage so wenig Arbeit wie möglich auslösen. Liefere so viele Seiten wie möglich aus dem Cache aus, schalte aufwendige Funktionen für einen Tag ab (Live-Suche, Produktempfehlungen, externe API-Aufrufe) und sorge dafür, dass zufällige Parameter deinen Cache nicht aushebeln.

Typische Fehler während eines Angriffs

• Nur den Server aufrüsten. Mehr CPU hilft kurz, doch Angreifer skalieren meist schneller, als dein Hosting-Budget mitwächst. Gegen eine überlastete Leitung bringt es ohnehin nichts.
• Lösegeld zahlen. Manche Angriffe kommen mit einer Forderung. Eine Zahlung garantiert nichts und macht dich zum dankbaren Ziel. Erpressung zeigst du bei der Polizei an.
• Zu großflächig sperren. Wer ganze Länder oder alle Bots aussperrt, trifft schnell auch Kunden und Suchmaschinen-Crawler. Setz im Zweifel lieber auf eine Captcha-Abfrage statt auf eine harte Sperre und nimm befristete Regeln nach dem Angriff wieder raus.
• Andere Angriffsflächen vergessen. Ein DDoS dient manchmal nur als Ablenkung. Prüfe danach Logins, Admin-Konten und kürzliche Änderungen. Darauf weist auch die Übersicht der CISA zu Denial-of-Service-Angriffen hin (Englisch).

Nach dem Angriff: So schützt du deine Website

Ist wieder Ruhe eingekehrt, nutzt du die Erfahrung. Das Ziel: Der nächste Angriff landet in einem Filter und nicht auf deinem Server.

Den Proxy dauerhaft davor lassen

Ein Filter am Edge wirkt am besten, wenn er schon da ist. Richtest du ihn erst während des Angriffs ein, verlierst du Zeit, bis die DNS-Änderung überall angekommen ist. Was ein CDN außer Geschwindigkeit noch bringt, erklärt der Ratgeber Was ist ein CDN und braucht deine Website eins?.

So viel cachen, wie es sicher geht

Jede Seite aus dem Cache ist eine Anfrage, die dein Server nie zu sehen bekommt. Öffentliche Seiten wie Startseite, Kategorien, Produktseiten und Blogartikel gehören in den Cache. Persönliche Seiten wie Warenkorb, Checkout und Kundenkonto bleiben dynamisch. Eine hohe Cache-Trefferquote verschafft deinem Server Reserven für echte Besucher, und ein schneller Ursprungsserver hilft zusätzlich. Wie du den hinbekommst, liest du unter TTFB verbessern.

Den Ursprungsserver abschotten

Lass HTTP- und HTTPS-Traffic nur noch aus den IP-Bereichen deines Proxys zu. Halte die Server-IP außerdem aus öffentlichen DNS-Einträgen, E-Mail-Headern und alten Subdomains heraus, denn genau darüber finden Angreifer sie meistens.

Rate Limits und Alarme einrichten

Begrenzungen für Login, Suche und APIs bremsen sowohl Floods als auch Brute-Force-Versuche. Alarme bei Traffic-Spitzen und Fehlerquoten sorgen dafür, dass du vom nächsten Angriff durch eine Benachrichtigung erfährst und nicht durch einen verärgerten Kunden.

Einen kurzen Notfallplan schreiben

Eine Seite reicht völlig: Wen rufst du beim Hoster an, wer hat Zugriff auf DNS und Proxy, welche Regeln schaltest du ein und wie informierst du deine Kunden? Mitten im Angriff will niemand nach Passwörtern suchen.

So hilft dir fast.site

fast.site sitzt vor deinem bestehenden Hosting. Du behältst deinen Hoster und stellst lediglich die Nameserver deiner Domain auf fast.site um. Ab dann landet dein Traffic zuerst im Edge-Netzwerk und wird dort gefiltert, bevor irgendetwas an deinen Server weitergeht.

Die Erkennung von Layer-7-DDoS-Angriffen läuft auf allen Domains automatisch, ohne dass du etwas konfigurieren musst. Zusätzlich kannst du IPs und CIDR-Bereiche sperren, ganze Länder blockieren oder per Captcha prüfen lassen, eigene Challenge-Regeln anlegen und Rate Limits pro IP setzen. Verwaltete Regelsätze schützen vor SQL-Injection, XSS und schädlichen Bots. Die Details findest du in der Sicherheits-Dokumentation.

Das Caching nimmt deinem Server weitere Last ab. Öffentliche Seiten kommen mit fs-cache: HIT direkt vom Edge, während Warenkorb, Checkout und eingeloggte Sitzungen als BYPASS wie gewohnt bei deinem Server landen. In den Analytics siehst du Anfragen, Fehlerquoten und den Traffic von deinem Server, und bei ungewöhnlichen Spitzen bekommst du einen Alarm.

Wird deine Website gerade angegriffen, geht es über die Seite für akute Angriffe am schnellsten. Ansonsten richtest du den Schutz in Ruhe mit einer kostenlosen 7-Tage-Testphase ein, ganz ohne Kreditkarte, und prüfst das Ergebnis an deiner eigenen Website. Tarife und inkludierten Traffic findest du auf der Preisseite.

Häufige Fragen

Wie lange dauert ein DDoS-Angriff?

Das ist sehr unterschiedlich. Manche Angriffe sind nach Minuten vorbei, andere kommen über Tage in Wellen zurück. Kurze Attacken sind häufig ein Test vor einem größeren Angriff oder begleiten eine Lösegeldforderung. Deshalb bringt ein Schutz, der dauerhaft aktiv ist, mehr als einer, den du erst im Ernstfall einschaltest.

Schadet ein DDoS-Angriff meinem Google-Ranking?

Ein kurzer Ausfall hat in der Regel keine bleibenden Folgen. Ist deine Website aber länger nicht erreichbar oder liefert Fehler, crawlen Suchmaschinen sie womöglich seltener und nehmen Seiten vorübergehend aus dem Index. Je schneller die Website wieder läuft und korrekte Statuscodes liefert, desto geringer bleibt der Schaden.

Ist ein DDoS-Angriff strafbar?

Ja, in Deutschland ist ein DDoS-Angriff als Computersabotage strafbar, und auch in den meisten anderen Ländern steht er unter Strafe. Sichere Logs, Zeitstempel und etwaige Erpresser-Nachrichten und erstatte Anzeige, zum Beispiel über die Onlinewache deiner Polizei. Das gilt ganz besonders, wenn Geld gefordert wird.

Stoppt ein WordPress-Sicherheitsplugin einen DDoS-Angriff?

Nicht wirklich. Ein Plugin läuft innerhalb von WordPress, jede Anfrage erreicht also trotzdem deinen Server, startet PHP und fragt oft schon die Datenbank ab, bevor das Plugin sie blockieren kann. Genau diese Last nutzt ein DDoS-Angriff aus. Gegen Login-Angriffe und Malware sind Plugins sinnvoll, DDoS-Filterung muss aber vor dem Server passieren.

Meine Website ist langsam, der Traffic aber normal. Was nun?

Dann ist es vermutlich kein DDoS-Angriff. Häufige Ursachen sind langsames Hosting, schwere Plugins, fehlendes Caching oder große Bilder. Einen guten Einstieg bietet der Support-Artikel zu einer langsamen Website.