DDoS-Angriffe stoppen: Praktischer Leitfaden

Eine DDoS-Flut lässt sich nicht am Server stoppen. Mehrschichtige Abwehr: Edge-Netzwerk, WAF-Ratenlimits, Caching, SYN-Schutz, Notfallplan, Tests.

DDoS-Angriffe stoppen

Niemand kann verhindern, dass jemand eine Flut an Traffic losschickt. DDoS-Angriffe zu stoppen heißt daher, den Dienst verfügbar zu halten, während sie laufen. Dazu gehören vier Dinge: schlechten Traffic filtern, bevor er Ihre Server erreicht, abfangen, was durchkommt, die Angriffsfläche verkleinern und vorher festlegen, wer bei einem Alarm handelt. In der Praxis läuft das meiste am Netzwerkrand und nicht auf dem Origin-Server.

Ein Distributed-Denial-of-Service-Angriff (DDoS) nutzt viele Rechner, oft ein Botnetz aus gekaperten Geräten, um ein Ziel zu fluten, sodass legitime Nutzer nicht mehr durchkommen. Die Grundlagen stehen unter Was ist ein DDoS-Angriff.

Zuerst den Angriffstyp bestimmen

Die richtige Abwehr hängt von der angegriffenen Schicht ab:

  • Volumetrische und Reflexionsangriffe (Schicht 3 und 4) versuchen, Ihre Bandbreite zu füllen, etwa durch UDP-Reflexion. Dagegen hilft nur mehr Kapazität als der Angriff hat, also ein Edge-Netzwerk oder ein Scrubbing-Dienst.
  • Protokollangriffe (Schicht 4) erschöpfen den Verbindungszustand, der klassische Fall ist die SYN-Flut.
  • Angriffe auf Anwendungsebene (Schicht 7) senden Anfragen, die legitim aussehen, etwa eine HTTP-Flut auf eine Such- oder Login-Funktion. Sie brauchen wenig Bandbreite und sind schwer von einer Lastspitze zu unterscheiden. Mehr unter DDoS-Angriffe auf Anwendungsebene.

Was Sie einrichten sollten

  • Ein Edge-Netzwerk vor den Origin setzen. Ein CDN oder Cloud-Edge-Dienst mit eingebautem DDoS-Schutz fängt volumetrischen Traffic nahe der Quelle ab. AWS beschreibt diesen Aufbau, CloudFront mit Shield und WAF, in seinem Whitepaper zur DDoS-Resilienz.
  • Eine Web Application Firewall mit ratenbasierten Regeln ergänzen. Blockieren Sie bekannte schlechte Muster und begrenzen Sie Anfragen pro Client, am besten pro IP und pro Sitzung. Bedenken Sie, dass ein Büro oder ein Mobilfunkanbieter hinter einer einzigen IP stehen kann, legen Sie Limits daher anhand echter Nutzung fest.
  • Die Angriffsfläche verkleinern. Halten Sie die Origin-Adresse privat und nur vom Edge-Anbieter erreichbar, schließen Sie ungenutzte Ports und stellen Sie aufwendige Endpunkte (Suche, Login, Exporte) unter strengere Limits.
  • Zwischenspeichern, was möglich ist. Jede am Edge beantwortete Anfrage erreicht den Origin nie, das dämpft Schicht-7-Fluten auf cachebare Seiten.
  • SYN-Fluten im Stack abfangen. Mit SYN-Cookies muss ein Server für halb offene Verbindungen keinen Zustand halten, auf Kosten der Kompatibilität mit einigen TCP-Optionen. RFC 4987 beschreibt SYN-Cookies, Filterung und die übrigen Gegenmaßnahmen samt Zielkonflikten.
  • Skalieren und alarmieren. Auto Scaling verschafft bei Traffic auf Anwendungsebene Zeit, skaliert aber auch Ihre Rechnung, kombinieren Sie es daher mit Alarmen und Obergrenzen.
  • Einen Notfallplan schreiben. Legen Sie fest, wer einen Angriff bestätigt, wer CDN, DNS oder Provider kontaktiert und wer mit Kunden kommuniziert. Die CISA rät dasselbe: einen Plan für Kommunikation, Abwehr und Wiederherstellung haben und Netzwerkadministrator und Provider kontaktieren, um zu klären, was Sie sehen.

Beispiel: HTTP-Flut auf eine Suchseite

Ein Shop merkt, dass die Suche in Zeitüberschreitungen läuft. Die Bandbreite ist normal, aber der Origin hat volle CPU-Last, und das Request-Log zeigt Tausende Suchaufrufe pro Minute von einigen hundert IPs. Die Lösung ist mehrschichtig: zwischengespeicherte Ergebnisse für wiederholte Suchen ausliefern, eine ratenbasierte Regel auf den Suchpfad legen, Clients über dem Limit prüfen lassen und die Anfragerate pro Pfad überwachen, damit die nächste Flut in Minuten auffällt.

Häufige Fehler

  • Nur am Origin verteidigen. Ein einzelner Server oder eine einzelne Leitung lässt sich sättigen, der Schutz am Edge muss daher zuerst stehen.
  • Die eigene IP per Null-Route sperren. Das stoppt die Flut, indem es Ihren Dienst unerreichbar macht, genau das wollte der Angreifer. Nur als letztes Mittel.
  • Schicht 7 ignorieren. Schutz auf Netzwerkebene stoppt keine Anfragen, die wie normale Nutzer aussehen.
  • Keine Referenzwerte. Ohne normale Anfrageraten pro Pfad lässt sich ein Angriff nicht von einer Aktion oder einem viralen Beitrag unterscheiden.
  • Schutz erst mitten im Angriff einrichten. Einen Anbieter während eines Vorfalls anzubinden dauert. Halten Sie Vertrag, DNS und Kontakte vorher bereit.

DDoS-Abwehr, Lasttests und Monitoring

Ein Lasttest beantwortet eine andere Frage als eine DDoS-Simulation. Nutzen Sie ihn, um zu erfahren, wie viel legitimen Traffic Ihr eigenes System verkraftet, wo es zuerst nachlässt und ob Ratenlimits und Autoscaling wie erwartet greifen. Ein Einstieg ist Load Testing vs. Stress Testing (auf Englisch), und Ursachen für API-Ratenbegrenzung (auf Englisch) zeigt, wie sich Limits in einem Test als 429-Antworten äußern. LoadFocus Load Testing führt HTTP-Tests gegen Ihre eigene Website oder API aus Cloud-Regionen aus und eignet sich für solche Kapazitäts- und Ratenlimit-Prüfungen.

Richten Sie kein Lasttest-Werkzeug auf ein System, das Ihnen nicht gehört, und behandeln Sie einen Lasttest nicht als DDoS-Übung. Echte DDoS-Simulationen unterliegen den Regeln der Anbieter: AWS erlaubt sie etwa nur über vorab zugelassene Partner mit festen Volumengrenzen, und die Richtlinie verbietet, den Traffic von einer AWS-Ressource aus zu erzeugen. Prüfen Sie die Richtlinie Ihres CDN- und Cloud-Anbieters und informieren Sie ihn vor jedem Test mit hohem Volumen.

Danach gilt: weiter beobachten. Synthetische Checks aus mehreren Regionen und Alarme auf Fehlerrate und Latenz sind oft das erste Zeichen eines Angriffs von außen.

Häufige Fragen zum Stoppen von DDoS-Angriffen

Kann ich einen DDoS-Angriff allein stoppen?

Nur kleine, mit Ratenlimits und IP-Sperren. Alles, was Ihre Bandbreite füllt oder den Origin erschöpft, braucht ein Edge-Netzwerk oder einen Scrubbing-Dienst mit mehr Kapazität als der Angriff.

Stoppt ein CDN jeden DDoS-Angriff?

Nein. Es fängt die meisten volumetrischen und Protokollangriffe am Edge ab, aber Fluten auf Anwendungsebene brauchen zusätzlich WAF-Regeln, Ratenlimits und auf Ihren Traffic abgestimmtes Caching.

Woran erkenne ich einen DDoS-Angriff?

Typische Anzeichen sind eine plötzlich langsame oder nicht erreichbare Website, ein Anstieg bei Anfragen oder Fehlern und Traffic aus vielen Quellen gleichzeitig. Die CISA nennt ungewöhnlich langsame Leistung und nicht erreichbare Websites als Symptome und weist darauf hin, dass Angreifer einen Angriff manchmal als Ablenkung nutzen.

Reicht Rate Limiting?

Es hilft gegen kleine Fluten und missbräuchliche Clients, stoppt aber keinen verteilten Angriff aus tausenden Quellen und keine volumetrische Flut. Setzen Sie es als eine Schicht unter mehreren ein.

Soll ich Lösegeld zahlen?

Nein. Zahlung garantiert nicht, dass der Angriff endet, und macht Sie zum zahlenden Ziel. Melden Sie die Forderung und aktivieren Sie Ihren Abwehrplan.

Kann ich meinen DDoS-Schutz testen?

Nur im Rahmen der Regeln Ihres Anbieters, meist über einen zugelassenen Partner und mit vorheriger Abstimmung. Für Kapazität und Ratenlimits ist ein kontrollierter Lasttest gegen das eigene System der sicherere Einstieg.

Wie schnell ist Ihre Website?

Steigern Sie ihre Geschwindigkeit und SEO nahtlos mit unserem kostenlosen Geschwindigkeitstest.

Kostenloser Websitespeed-Test

Analysieren Sie die Ladegeschwindigkeit Ihrer Website und verbessern Sie ihre Leistung mit unserem kostenlosen Seitengeschwindigkeits-Checker.