Was ist ein Application-Layer-DDoS-Angriff?

Was ist ein Application-Layer-DDoS-Angriff?

Ein Application-Layer-DDoS-Angriff — auch Layer-7-(L7-)Angriff genannt — überfordert eine Webanwendung, indem er sie mit Requests flutet, die wie legitime Nutzer-Traffic aussehen. Anders als volumetrische Angriffe, die Netzwerk-Bandbreite saturieren (Layer 3/4), zielen L7-Angriffe auf die Anwendungslogik selbst: teure Endpoints anfordern, Suchformulare hämmern, Login-Seiten missbrauchen oder einfach die Homepage schneller anfordern, als der Server rendern kann. Die verbrauchte Bandbreite ist klein; die CPU- und Datenbank-Last ist enorm.

L7-Angriffe sind genau deshalb gefährlich, weil sie echt aussehen. Eine Flut von HTTP-GET-Requests an /search?q=anything kann eine Seite lahmlegen, ohne die Bandbreite zu überschreiten, die ein einzelner Breitband-Nutzer verbrauchen würde. Generische DDoS-Schutzmaßnahmen, die nach Traffic-Volumen filtern, lassen diese Angriffe durch.

Wie Application-Layer-DDoS-Angriffe funktionieren

Der Angreifer kontrolliert ein Botnet — typischerweise tausende kompromittierte Browser, IoT-Geräte oder gemietete Cloud-Instanzen. Jeder Bot sendet einen kleinen, aber ressourcen-teuren Request ans Ziel. Häufige Angriffsmuster:

• HTTP-Flood: Massives Volumen an GET- oder POST-Requests an teure Endpoints (Suche, dynamische Homepage, Login). Jeder Request kann 100-500 ms Server-Zeit kosten; tausende pro Sekunde saturieren den Worker-Pool.
• Slowloris: Viele TCP-Verbindungen zum Server öffnen, Header langsam senden (ein Byte alle paar Sekunden), den Request nie fertigstellen. Verbindungen bleiben offen und verbrauchen Server-Slots; legitime Nutzer können sich nicht verbinden, weil der Pool erschöpft ist.
• RUDY (R-U-Dead-Yet): Wie Slowloris aber für POST-Requests — POST-Header senden, dann den Body stundenlang in winzigen Chunks tröpfeln lassen.
• Cache-Busting: Eindeutige Query-Parameter anhängen (?id=12345), damit jeder Request den CDN-Cache verfehlt und Origin trifft. Effektiv gegen Sites, die auf CDN-Absorption setzen.
• API-Endpoint-Missbrauch: Wiederholt teure Endpoints aufrufen (Suche, Recommendations, komplexe Aggregationen), die kein normaler Nutzer tausende Male pro Sekunde aufrufen würde.

Warum L7-Angriffe schwerer abzuwehren sind als L3/L4

Volumetrische (Layer-3/4-)Angriffe kündigen sich mit absurden Traffic-Volumen an — dein CDN sieht 100 Gbps eingehend und droppt den offensichtlichen Junk, bevor er Origin erreicht. L7-Angriffe senden kleine, einzeln-legitim-wirkende HTTP-Requests bei moderatem Aggregat-Volumen. Die defensive Herausforderung:

• Jeder Request sieht gültig aus. Filtern nach Volumen allein fängt nichts — die Bandbreite wirkt normal.
• User-Agent-Spoofing. Moderne Bots senden realistische Browser-User-Agents. Blockieren nach UA fängt nur offensichtliche Bots.
• Verteilter Ursprung. Botnets erstrecken sich über tausende Residential-IPs. IP-Blocken ist Whack-a-Mole.
• Behavioral Detection erfordert Kontext. Echter Schutz braucht das Verständnis dessen, was für deine App normal ist — Request-Rate pro Session, Navigations-Muster, Zeit-auf-Seite-Verteilungen. Das richtig zu bauen ist teuer.

Wie man gegen Application-Layer-DDoS verteidigt

Web Application Firewall (WAF) mit Rate Limiting

Eine WAF (Cloudflare, AWS WAF, Akamai) sitzt vor Origin und wendet Regeln an: Rate-Limit pro IP, pro Session, pro Endpoint. Moderne WAFs enthalten Managed Rule Sets, die häufige Angriffsmuster (Slowloris, RUDY, gängige Bot-Fingerprints) automatisch erkennen.

CAPTCHAs und Challenge-Pages

Wenn die WAF verdächtige Muster erkennt (z.B. 50 req/Sek von einer einzelnen IP), serve ein CAPTCHA oder eine JavaScript-Challenge. Bots scheitern an der Challenge; echte Nutzer absolvieren sie. Cloudflares "Under Attack"-Modus macht das automatisch.

Rate-Limit auf AnwendungsebeneAuch mit einer WAF zählt Defense-in-Depth. Anwendungslevel-Rate-Limiting pro Nutzer/Session/IP fängt Angriffe, die den Perimeter umgehen. Express/Nginx/Envoy unterstützen das alle.

Aggressiv cachen

Cache-Busting-Angriffe scheitern an gut gecachten Endpoints. Setze Cache-Control auf alle GET-Endpoints. Variiere auf minimale Header (Cookies nicht in den Cache-Key für nicht-personalisierte Seiten).

Monitoren und alarmieren

Detection geht Mitigation voraus. Überwache Request-Rate, Fehlerrate, p95-Latenz. Wenn die WAF aktiviert wird, solltest du es bereits wissen — proaktives Alerting bei niedrigeren Schwellen fängt den Angriff, bevor er kaskadiert.

FAQ: Application-Layer-DDoS

Wie groß muss ein L7-Angriff sein, um eine Seite lahmzulegen?

Kleiner als die Leute denken. Ein Botnet aus 5.000-10.000 Knoten, das teure Endpoints in moderater Rate trifft, kann den Worker-Pool einer typischen mittelgroßen SaaS-App überfordern. Bandbreite: trivial. CPU/DB: katastrophal.

Schützt Cloudflares kostenlose Stufe gegen L7-Angriffe?

Teilweise. Kostenloses Cloudflare bietet grundlegendes Rate-Limiting und "Under Attack"-Modus, was bei unbedeutenden Angriffen hilft. Anhaltende oder großmaßstäbliche L7-Angriffe brauchen die Pro/Business-Stufe mit Managed-WAF-Regeln und Custom-Rate-Limits.

Was ist der Unterschied zwischen L7-DDoS und HTTP-Flood?

HTTP-Flood ist eine Art von L7-DDoS — die häufigste. Andere L7-Angriffskategorien (Slowloris, RUDY, Cache-Busting, API-Missbrauch) sitzen alle auf Layer 7, nutzen aber unterschiedliche Techniken.

Kann Lasttest einen L7-DDoS simulieren?

Ja — genau das machen Stress- und Soak-Tests. LoadFocus führt JMeter- oder k6-Skripte mit hoher Concurrency aus Cloud-Infrastruktur aus, um zu validieren, dass deine App unter Last responsiv bleibt. Der Unterschied zu einem echten Angriff: Lasttests respektieren Rate-Limits und stoppen auf Signal; Angreifer nicht.

Sollte ich nach IP, Session oder beidem rate-limiten?

Beides. IP-Rate-Limiting fängt offensichtliche Bots aus einzelnen IPs. Session/Nutzer-Rate-Limiting fängt verteilte Angriffe, die aus tausenden IPs kommen aber gegen dasselbe Ziel koordiniert sind. Layere sie.

Wie weiß ich, ob ich angegriffen werde vs. organischen Traffic erlebe?

Vergleiche aktuelle Traffic-Form mit deiner normalen Baseline: Request-Verteilung über Endpoints, Fehlerraten, geografische Verteilung, User-Agent-Diversität. Ein Angriff zeigt typischerweise Uniformität (selbe Endpoints, selber User-Agent, selbe Regionen), während organischer Traffic chaotisch ist.

Wie LoadFocus bei der L7-DDoS-Vorbereitung hilft

LoadFocus führt skriptbare JMeter- und k6-Lasttests gegen deine Endpoints in Skalen aus, die L7-Angriffsmuster nachahmen — hohe Concurrency, Targeting teurer Endpoints, Cache-Busting-Varianten. Nutze es, um zu validieren, dass deine Rate-Limits funktionieren, bevor ein Angreifer sie testet. Führe einen Attack-Pattern-Test auf loadfocus.com/de-de/free-load-test aus oder kombiniere mit API-Monitoring auf loadfocus.com/de-de/api-monitoring für laufende Validierung.