Was ist ein HTTP-Flood-DDoS-Angriff?

Was ist ein HTTP-Flood-DDoS-Angriff?

Ein HTTP-Flood ist ein DDoS-Angriff auf Anwendungsebene (Layer 7). Viele Rechner schicken gewöhnlich aussehende HTTP-GET- oder POST-Anfragen an einen Webserver oder eine API, bis für echte Nutzer keine Kapazität mehr bleibt. Jede Anfrage ist gültiges HTTP, es gibt also kein fehlerhaftes Paket, das man verwerfen könnte. Der Schaden entsteht durch die Arbeit, die jede Anfrage auf dem Server auslöst, nicht durch die verbrauchte Bandbreite.

Er ist eine Form des DDoS-Angriffs auf Anwendungsebene und gehört zur größeren Familie der verteilten Dienstblockaden (DDoS). Dieser Eintrag erklärt, wie Floods funktionieren und wie man sich verteidigt. Er ist keine Anleitung für einen Angriff: Systeme anzugreifen, die einem nicht gehören, ist illegal.

So funktioniert ein HTTP-Flood

• Ein Botnetz sendet den Verkehr. Die Anfragen kommen von sehr vielen kompromittierten Geräten oder gemieteten Rechnern, deshalb fällt keine einzelne IP-Adresse auf.
• Die Anfragen sehen normal aus. Header, Methoden und URLs sind gültig, und der User-Agent wird oft von einem echten Browser kopiert.
• Teure Endpunkte sind das Ziel. Suche, gefilterte Listen, Login und Empfehlungsaufrufe kosten den Server viel mehr als eine statische Datei, schon eine mäßige Anfragerate kann daher Worker-Prozesse oder Datenbankverbindungen erschöpfen.
• Caches werden umgangen. Ein zufälliger Query-Parameter an jeder URL (zum Beispiel ?q=schuhe&_=83721) lässt jede Anfrage neu aussehen, sie passiert das CDN und erreicht Ihren Ursprungsserver.

Ein GET-Flood trifft lesende Endpunkte. Ein POST-Flood trifft schreibende Endpunkte wie Registrierung oder Kontaktformular und belastet die Datenbank oft stärker. Langsame Angriffe wie Slowloris und RUDY sind verwandt, funktionieren aber anders: Sie halten Verbindungen mit sehr wenig Datenverkehr offen, statt eine hohe Anfragerate zu erzeugen.

Beispiel: ein Flood auf eine Suchseite

Ein Shop hat einen Endpunkt /search, der eine ungecachte Datenbankabfrage ausführt. An einem normalen Tag sind es ein paar Anfragen pro Sekunde. Während eines Floods fragen tausende Clients /search mit jeweils einem anderen Zufallsbegriff ab. Jede Anfrage verfehlt den Cache, der Datenbank-Connection-Pool läuft voll, und Checkout-Aufrufe laufen in Timeouts. Browser und Apps wiederholen die Anfragen, was die Last weiter erhöht. Es wurde nichts "gehackt": Die Seite hat schlicht ihre Kapazität verloren, deshalb sind langsame Antworten und steigende Fehlerraten meist das erste Anzeichen.

Warum HTTP-Floods schwer zu stoppen sind

• Sie ähneln einer Lastspitze. Ein Schwall von Anfragen aus vielen IPs kann eine Kampagne oder ein Flood sein. Zu hartes Blockieren kostet Kunden, zu wenig Blockieren lässt die Seite ausfallen.
• Der Aufwand ist ungleich verteilt. Eine kleine Anfrage kann eine Datenbankabfrage und mehrere Folgeaufrufe auslösen.
• Autoscaling kann die Rechnung erhöhen. Wer nach Anfragezahl skaliert, zahlt unter Umständen für den Angriffsverkehr. Setzen Sie ein Maximum.

So verteidigen Sie sich gegen einen HTTP-Flood

• Einen Edge-Dienst vor den Ursprung setzen. Ein CDN liefert cachebare Inhalte aus und fängt Spitzen ab, bevor sie Ihre Server erreichen.
• WAF-Ratenbegrenzung nutzen. Eine Web Application Firewall zählt Anfragen pro Quelle und begrenzt jene, die zu schnell eintreffen. AWS-WAF-Regeln auf Ratenbasis fassen Anfragen zum Beispiel nach selbst gewählten Kriterien zusammen und wenden eine Aktion an, wenn ein Limit überschritten wird.
• Verdächtige Clients prüfen. Eine JavaScript-Challenge oder ein CAPTCHA filtert Bots, die keinen Browser ausführen.
• URLs cachen und normalisieren. Parameter ignorieren, die die Antwort nicht ändern, damit Cache-Busting ins Leere läuft.
• Pro Sitzung und pro Konto begrenzen, nicht nur pro IP, denn ein Botnetz wechselt die Adressen.
• Teure Endpunkte schützen. Timeouts, ein Circuit Breaker oder ein gecachter Fallback verhindern, dass eine langsame Abhängigkeit die ganze Seite lahmlegt.

Den Ablauf Schritt für Schritt finden Sie unter DDoS-Angriffe stoppen.

Häufige Fehler

• Ratenbegrenzung nur nach IP-Adresse.
• Ein Limit unterhalb der echten Lastspitze, sodass ein Produktstart es auslöst.
• Statische Dateien cachen, die teuren Seiten dahinter aber nicht.
• Keine Baseline, sodass niemand weiß, wie "doppelte normale Anfragerate" aussieht.
• Abwarten, bis Kunden den Ausfall melden.

HTTP-Floods, Lasttests und Monitoring

Ein Lasttest ist keine Angriffssimulation und ersetzt weder eine WAF noch einen DDoS-Schutz. Er zeigt aber, wo Ihre eigene Anwendung unter hoher, legitimer Last an ihre Grenzen kommt: welcher Endpunkt zuerst langsam wird und ob Limits und Caching wie geplant arbeiten. Testen Sie nur Systeme, die Ihnen gehören oder für die Sie eine schriftliche Erlaubnis haben, und bevorzugt auf Staging. LoadFocus führt Lasttests mit JMeter und k6 aus Cloud-Regionen aus, der kostenlose Plan erlaubt bis zu 10 virtuelle Nutzer. Den Unterschied zwischen beiden Testarten erklärt Load Testing vs. Stresstest.

Monitoring erkennt einen Flood früh. Alarmieren Sie auf Anfragerate, Fehlerrate und p95-Latenz im Vergleich zu einer Baseline, und überwachen Sie Ihre öffentlichen Endpunkte mit API-Monitoring. Blockiert ein Limit echte Clients, hilft dieser Leitfaden zu API-Ratenbegrenzung beim Lesen der 429-Antworten. Cloud-Anbieter haben eigene Regeln für DDoS-Simulationen: AWS erlaubt sie nur über zugelassene Partner oder nach vorheriger Genehmigung.

Häufige Fragen: HTTP-Flood-DDoS-Angriffe

Was ist der Unterschied zwischen einem HTTP-Flood und einem volumetrischen Angriff?

Ein volumetrischer Angriff versucht, Ihre Netzwerkbandbreite mit rohem Datenverkehr zu füllen. Ein HTTP-Flood sendet gültige Anfragen und erschöpft Serverressourcen wie Worker, Datenbankverbindungen und Kontingente nachgelagerter APIs, oft mit deutlich weniger Bandbreite.

Woran erkenne ich einen HTTP-Flood im Unterschied zu einer viralen Lastspitze?

Schauen Sie auf die Form des Verkehrs. Organische Spitzen konzentrieren sich meist auf wenige Seiten, mit unterschiedlichen Referrern, Browsern und Regionen und Besuchern, die stöbern und kaufen. Floods sind eher gleichförmig: ähnliche User-Agents, ungewöhnliche URLs mit Zufallsparametern, keine Referrer und keine Conversions.

Stoppt ein CDN einen HTTP-Flood?

Bei cachebaren Inhalten hilft es, aber Cache-Busting-Parameter und dynamische Endpunkte erreichen weiter Ihren Ursprungsserver. Kombinieren Sie das CDN mit WAF-Ratenbegrenzung, Challenges und Limits in der Anwendung.

Soll ich pro IP oder pro Sitzung begrenzen?

Beides. IP-Limits fangen einzelne Quellen ab, Sitzungs- oder Kontolimits fangen ein Botnetz ab, das Anfragen auf viele Adressen verteilt.

Kann ich meine Seite gegen einen HTTP-Flood testen?

Sie können Ihre eigene Anwendung per Lasttest auf ihre Kapazitätsgrenzen prüfen, mit Erlaubnis und am besten auf Staging. Eine echte DDoS-Simulation ist ein eigener Dienst, den Anbieter einschränken. Fragen Sie deshalb Ihren Anbieter, bevor Sie etwas ausführen, das einen Angriff nachahmt.