Was ist ein HTTP-Flood-DDoS-Angriff?

Was ist ein HTTP-Flood-DDoS-Angriff?

Ein HTTP-Flood ist ein Layer-7-(Application-Layer-)DDoS-Angriff, bei dem der Angreifer massive Volumen von HTTP-GET- oder POST-Requests an einen Ziel-Webserver sendet. Jeder einzelne Request sieht legitim aus — properly-formed HTTP, realistischer User-Agent-Header, plausibler URL — was HTTP-Floods schwer zu filtern macht, ohne echte Nutzer dabei zu blockieren. HTTP-Floods sind das häufigste L7-DDoS-Angriffsmuster: einfach auszuführen, schwer abzuwehren und unverhältnismäßig destruktiv relativ zur verbrauchten Bandbreite.

Anders als volumetrische (Layer-3/4-)Angriffe, die Netzwerk-Bandbreite mit Raw-Packet-Floods saturieren, erschöpfen HTTP-Floods serverseitige Ressourcen: Webserver-Worker-Pools, Datenbankverbindungen, Anwendungsspeicher und Downstream-API-Quoten. Ein Botnet aus 5.000-10.000 Knoten, das einen teuren Endpoint mit 5 Requests/Sek pro Knoten hämmert — 25.000-50.000 RPS aggregiert — kann eine typische mittelgroße SaaS-Anwendung lahmlegen, ohne die Bandbreite zu überschreiten, die ein einzelner Residential-Breitband-Nutzer verbrauchen würde.

Wie HTTP-Flood-Angriffe funktionieren

Der Angreifer kontrolliert ein Botnet — ein Netzwerk kompromittierter Geräte: gehackte Browser, IoT-Geräte (Kameras, Router, Smart Appliances) oder gemietete Cloud-Instanzen, die auf Darkweb-Foren für 5-50 $/Stunde für kurze Angriffe gekauft werden. Jeder Bot im Netzwerk sendet HTTP-Requests ans Ziel mit diesen Eigenschaften:

• Properly-formed HTTP. Echte HTTP/1.1- oder HTTP/2-Requests mit gültigen Headern — Host, User-Agent (oft gespooft, um wie Chrome/Safari/Firefox auszusehen), Accept, etc. Was basic HTTP-Parsing nicht besteht, wird sowieso an der WAF gedroppt.
• Verteilte Source-IPs. Requests kommen aus tausenden geografisch verteilten IPs — typischerweise Residential-IP-Space, gemietet von kompromittierten Geräten, ISP-CGNAT-Pools oder transienten IP-Ranges von Cloud-Providern.
• Gezielte Endpoint-Auswahl. Smarte Angreifer zielen auf die teuersten Endpoints: /search?q=..., /api/recommendations, die dynamische Homepage ohne Caching, Login-Formulare, die die Auth-Datenbank treffen. Jeder Request triggert signifikante CPU- und Datenbank-Arbeit.
• Cache-Busting-Variation. Eindeutige Query-Parameter anhängen oder Fragmente randomisieren, um jeden Request durch das CDN zu Origin zu zwingen: /search?q=test&_cb=12345, /search?q=test&_cb=12346, etc. CDN-Caching wird nutzlos.

HTTP-Flood vs. andere L7-Angriffsmuster

HTTP-Flood ist der häufigste L7-Angriff, aber mehrere Varianten und benachbarte Muster existieren:

• HTTP-Flood (dieser Eintrag): Hohes Volumen vollständig geformter HTTP-Requests. Kann GET-Flood (read-heavy Endpoints) oder POST-Flood (write-heavy Endpoints — oft schädlicher, weil Writes die Datenbank treffen) sein.
• Slowloris: Öffnet viele TCP-Verbindungen, sendet partielle HTTP-Header langsam, beendet sie nie. Verbindungen bleiben offen und verbrauchen Server-Slots; legitime Nutzer können sich nicht verbinden, weil der Connection-Pool erschöpft ist.
• RUDY (R-U-Dead-Yet): Slow-POST-Angriff — sendet gültige POST-Header, dann tröpfelt er den Body stundenlang in winzigen Chunks. Webserver hält die Verbindung am Leben und wartet, dass der Body abgeschlossen wird.
• Recursive GET: Hämmert teure rekursive Endpoints (Suche-mit-Filtern, komplexe Aggregationen), die viele Backing-Services pro Request anfassen.
• Form-Spam-Flood: POST-Floods auf Formulare (Login, Signup, Kontakt), die Downstream-Seiteneffekte triggern: gesendete E-Mails, neue User-Records, Log-Einträge.

Warum HTTP-Floods gefährlich sind

• Schwer von echten Nutzern zu unterscheiden. Ein Spike in Homepage-GETs aus tausenden eindeutigen IPs sieht aus wie ein viraler Hit ODER ein HTTP-Flood. Verteidiger müssen wählen: aggressiv blocken und echte Nutzer verlieren oder permissiv sein und verwundbar bleiben.
• Ressourcen-Amplifikation. Ein 1-KB-HTTP-Request kann eine 100-ms-Datenbank-Query plus einen 200-ms-Recommendation-Call plus einen 50-ms-Downstream-API-Hit triggern. Jedes Byte Angriffs-Input wird zu 100+ Bytes serverseitiger Arbeit.
• Kosten-Amplifikation. Wenn du auf Traffic autoscaled, skaliert ein HTTP-Flood deine Infrastruktur-Rechnung nach oben. Der Angreifer zahlt für ein Botnet; du zahlst AWS für die Worker, die den Angreifer bedienen.
• Kaskadierende Ausfälle. Wenn der Worker-Pool saturiert ist, beginnen echte Nutzer mit Timeouts. Ihre Browser retryen, was die Last weiter erhöht. Die Anwendung kann fallen, bevor der Angriff in irgendeinem traditionellen Sinn "Saturation" erreicht.

Wie man gegen HTTP-Floods verteidigt

WAF mit Rate Limiting

Eine moderne WAF (Cloudflare, AWS WAF, Akamai, Fastly) sitzt vor Origin und wendet Rate-Limits pro IP, pro Session, pro Endpoint an. Die meisten Managed-WAF-Rule-Sets erkennen häufige Bot-Fingerprints und HTTP-Flood-Muster automatisch. Tune das Rate-Limit auf deinen normalen Peak-Traffic plus 50% Puffer — alles darüber triggert die WAF.

JavaScript-Challenges und CAPTCHAs

Wenn die WAF ein Flood-Muster erkennt, serve eine JavaScript-Challenge oder CAPTCHA. Die meisten Botnets führen kein JavaScript aus und lösen CAPTCHAs nicht im Maßstab; echte Browser tun's. Cloudflares "Under Attack"-Modus automatisiert das. Moderne Challenges sind für die meisten legitimen Nutzer unsichtbar.

Aggressives Caching

Cache-Busting-Angriffe scheitern an gut gecachten Endpoints. Setze Cache-Control: max-age auf alle GET-Endpoints. Nutze ein CDN mit hohen Cache-Hit-Ratios. Für dynamische Endpoints erwäge stale-while-revalidate, um gecachten Content zu servieren, während Origin sich erholt.

Application-Level-Rate-Limiting

Defense-in-Depth. Auch mit einer WAF sollte deine Anwendung auf Session/Nutzer-Ebene rate-limiten. Eine WAF fängt IP-basierte Floods; Anwendungs-Rate-Limits fangen Angreifer, die durch Residential-IPs rotieren, aber gegen dieselben Accounts koordinieren.

Auf Failover vorbereiten

Identifiziere deine teuersten Endpoints und habe einen Circuit-Breaker-Plan. Wenn /api/recommendations der Bottleneck während Angriffen ist, konfiguriere ihn so, dass er einen gecachten Fallback oder eine einfache Error-Response zurückgibt, wenn die Last X Requests/Sek übersteigt. Besser ein Feature degradieren als die ganze Site zusammenbrechen lassen.

Proaktiv monitoren und alarmieren

Du solltest von einem HTTP-Flood erfahren, bevor Kunden es tun. Alarmieren bei: Request-Rate über 2x der Rolling-Baseline, Fehlerrate über 1%, p95-Latenz über SLO. Automatisierte Mitigation (WAF-Auto-Aktivierung) schließt die Lücke von "erkannt" zu "abgewehrt", aber proaktives Monitoring fängt Angriffe, die die WAF nicht fängt.

FAQ: HTTP-Flood-DDoS-Angriffe

Wie groß muss ein HTTP-Flood sein, um eine Seite lahmzulegen?

Kleiner als die Leute denken. 25.000-50.000 RPS, die teure Endpoints targeten, können den Worker-Pool einer typischen mittelgroßen SaaS-Anwendung überfordern. Angreifer brauchen keine Millionen Requests pro Sekunde — nur genug, um deine teuersten Endpoints schneller zu saturieren, als Autoscale reagieren kann.

Stoppt Cloudflares kostenloser Plan HTTP-Floods?

Teilweise. Der kostenlose Plan bietet basic DDoS-Schutz (meist Layer 3/4) und "Under Attack"-Modus für L7-Angriffe. Anhaltende oder ausgeklügelte HTTP-Floods brauchen den Pro/Business-Plan mit Managed-WAF-Regeln, Rate-Limiting-Controls und Bot-Management.

Wie unterscheide ich einen HTTP-Flood von einem viralen Traffic-Spike?

Schau dir die Traffic-Form an: virale Spikes konzentrieren sich auf eine oder wenige URLs (die Seite, die viral ging) mit diversen User-Agents, Geografie und Referrers. Floods sind uniform: dieselben URLs, getroffen von denselben User-Agents aus denselben Regionen, keine organischen Referrers. Conversion-Rate hilft auch — viraler Traffic konvertiert; Flood-Traffic nicht.

Kann ich einen Lasttest fahren, der einen HTTP-Flood nachahmt?

Ja — genau das macht Stress-Testing. Nutze LoadFocus, um JMeter- oder k6-Skripte mit hoher Concurrency aus Cloud-Regionen auszuführen, deine teuren Endpoints mit realistischen Request-Formen treffend. Validiert, dass deine Rate-Limits, CDN und Autoscale funktionieren, BEVOR ein Angreifer sie testet. Der Unterschied: Lasttests respektieren Rate-Limits und stoppen auf Signal; Angreifer nicht.

Sollte ich nach IP oder Session rate-limiten?

Beides. IP-Rate-Limiting fängt Angriffe aus einzelnen Quellen. Session/Nutzer-Rate-Limiting fängt verteilte Angriffe, die aus tausenden IPs kommen, aber gegen deine Endpoints koordiniert sind. Layere sie — keiner allein reicht.

Was sind die Kosten, unvorbereitet auf einen HTTP-Flood zu sein?

Drei Buckets: direkt (Downtime-Kosten — verlorene Transaktionen, SLA-Strafen), indirekt (Autoscale-Kosten — deine Infrastruktur-Rechnung multipliziert während Angriffstraffic bedient wird), reputationell (Kundenabwanderung nach öffentlichen Ausfällen, Ranking-Verluste, wenn Googlebot während Angriffen nicht crawlen kann). Für eine typische E-Commerce-Site kostet ein 4-Stunden-Ausfall während Peak-Traffic mindestens fünfstellig.

Wie LoadFocus dir hilft, dich auf HTTP-Floods vorzubereiten

LoadFocus führt skriptbare JMeter- und k6-Lasttests in Skalen aus, die HTTP-Flood-Angriffsmuster nachahmen: hohe RPS, Targeting teurer Endpoints, Cache-Busting-Varianten. Führe einen Stresstest auf loadfocus.com/de-de/free-load-test gegen deine Staging-Umgebung aus, um zu validieren, dass deine Rate-Limits, CDN-Caching und Autoscale funktionieren, bevor ein Angreifer sie für dich stress-testet. Kombiniere mit API-Monitoring aus 25+ Regionen, um echte Angriffe früh zu fangen.