Was ist ein Application-Layer-DDoS-Angriff?

Was ist ein Application-Layer-DDoS-Angriff?

Ein Application-Layer-DDoS-Angriff, auch Layer-7- oder L7-Angriff genannt, überflutet eine Webanwendung oder API mit Requests, die wie normale Nutzer aussehen. Er füllt nicht die Netzwerkleitung, sondern erschöpft, was die Anwendung zum Antworten braucht: Worker-Threads, CPU, Datenbankverbindungen und Arbeitsspeicher. Jeder Request ist klein, deshalb verrät das Traffic-Volumen allein den Angriff kaum.

Er ist das leise Gegenstück zu volumetrischen Angriffen, die auf Layer 3 und 4 die Bandbreite sättigen. Das größere Bild zeigt der Eintrag DDoS-Überblick, die häufigste L7-Form beschreibt der Eintrag HTTP-Flood.

So funktionieren Angriffe auf Anwendungsebene

Der Angreifer steuert ein Botnet aus kompromittierten Geräten oder gemieteten Cloud-Servern. Jeder Bot sendet Requests, die billig zu senden und teuer zu beantworten sind. Typische Muster:

• HTTP-Flood: eine hohe Rate an GET- oder POST-Requests auf aufwendige Endpoints wie Suche, Login oder eine dynamische Startseite.
• Slowloris: viele Verbindungen, die offen bleiben, weil die Request-Header extrem langsam gesendet werden, bis der Server keinen freien Verbindungsplatz mehr hat.
• RUDY (R-U-Dead-Yet): dieselbe Idee für POST-Bodys, die Byte für Byte eintröpfeln.
• Cache-Busting: ein eindeutiger Query-String pro Request (?x=8841), damit ein CDN nicht aus dem Cache antworten kann und jeder Request Ihren Origin erreicht.
• API-Missbrauch: wiederholte Aufrufe teurer Endpoints wie Berichte, Exporte oder Aggregationen, die kein echter Nutzer so oft aufruft.

Beispiel: ein Such-Endpoint

Angenommen, /search?q=... führt eine ungecachte Datenbankabfrage von 200 ms aus und Ihre App hat 20 Worker. Das sind bestenfalls etwa 100 Suchen pro Sekunde (Zahlen zur Veranschaulichung). Ein Botnet, das 150 Suchen pro Sekunde schickt, stößt nie an Ihr Bandbreitenlimit, doch der Worker-Pool ist voll, die Warteschlange wächst und echte Besucher sehen Timeouts und 503-Fehler. Die Traffic-Kurve wirkt unauffällig, die Latenz-Kurve nicht.

Warum Layer 7 schwerer abzuwehren ist als Layer 3/4

• Jeder Request ist gültig. Nichts ist fehlerhaft, nichts lässt sich am Netzwerkrand verwerfen.
• Bots sehen aus wie Browser. Realistische User-Agent-Strings machen UA-Blocking schwach.
• Die Quellen sind verteilt. Botnets nutzen viele Adressen, einzelne IPs zu sperren ist ein Hase-und-Igel-Spiel.
• Normal hängt von Ihrer App ab. Sie müssen Ihre übliche Request-Rate pro Session und Endpoint kennen, um Abweichungen zu erkennen.

So wehren Sie sich

• Rate Limiting am Edge und in der App. Eine Web Application Firewall (WAF) kann pro IP, Session und Endpoint begrenzen. Setzen Sie zusätzlich ein Limit in der App, falls Traffic den Edge umgeht. Antworten Sie mit 429 Too Many Requests und einem Retry-After-Header. Ursachen und Lösungen erklärt der Leitfaden zu API-Rate-Limiting.
• Verdächtige Clients herausfordern. Ein CAPTCHA oder eine JavaScript-Challenge filtert einfache Bots, bevor sie teuren Code erreichen.
• Cachen, was geht. Anonyme GET-Antworten cachen und Cookies bei nicht personalisierten Seiten aus dem Cache-Key heraushalten.
• Teure Endpoints günstiger machen. Indizes, Paginierungslimits und Timeouts sorgen dafür, dass ein Request keinen Worker lange blockiert.
• Latenz beobachten, nicht nur Traffic. Alarmieren Sie auf p95-Latenz, Fehlerrate und Worker-Auslastung. Die komplette Checkliste steht unter DDoS-Angriffe stoppen.

Häufige Fehler

• Sich bei einem verteilten Botnet allein auf IP-Sperren verlassen.
• Nur die Login-Seite begrenzen und Suche, Export und API-Routen offen lassen.
• Hinter einem Proxy oder CDN auf die Proxy-Adresse statt auf die echte Client-Adresse begrenzen, sodass alle einen gemeinsamen Zähler teilen.
• Keine Baseline für normalen Traffic, sodass niemand sagen kann, was abnormal ist.
• Annehmen, dass das CDN alles abfängt, obwohl nicht cachebare Endpoints direkt den Origin treffen.

Welche Rolle Lasttests und Monitoring spielen

Ein Lasttest ist keine DDoS-Simulation, und LoadFocus simuliert keine DDoS-Angriffe. Ein Lasttest zeigt, wie sich Ihre eigene Anwendung bei einer von Ihnen gewählten Last aus bekannten Cloud-Regionen verhält, und zwar nur gegen Systeme, die Sie testen dürfen. Das hilft defensiv: Sie erfahren, wie viele Requests pro Sekunde Ihre teuren Endpoints verkraften und ob Ihre Rate Limits mit 429 statt mit Timeouts antworten. Wie Sie das planen, steht in Lasttest vs. Stresstest, ausführen können Sie es mit LoadFocus Lasttests. Kombinieren Sie es mit API-Monitoring, damit langsame oder fehlerhafte Endpoints einen Alarm auslösen (kostenlose Checks laufen alle 5 Minuten).

Häufige Fragen: Application-Layer-DDoS

Wie groß muss ein L7-Angriff sein?

Kleiner, als die meisten erwarten. Entscheidend ist, wie viel Arbeit Ihre App pro Request leistet, nicht die Bandbreite. Ein Endpoint mit aufwendiger Datenbankabfrage lässt sich schon mit einer moderaten Request-Rate erschöpfen.

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

Ein HTTP-Flood ist eine Art von L7-DDoS und die häufigste. Slowloris, RUDY, Cache-Busting und API-Missbrauch sind weitere Arten auf derselben Ebene.

Stoppt ein CDN Angriffe auf Anwendungsebene?

Es hilft bei cachebaren Seiten und bringt oft Rate Limiting und Bot-Regeln mit. Bei nicht cachebaren Requests wie Logins, Suchen oder API-Aufrufen hilft es nicht, sie erreichen weiterhin Ihren Origin, sofern sie nicht begrenzt werden.

Soll ich nach IP, Session oder beidem begrenzen?

Nach beidem. IP-Limits fangen einfache Bots ab. Session- oder Konto-Limits fangen verteilte Angriffe ab, bei denen jede Adresse nur wenige Requests sendet.

Wie unterscheide ich einen Angriff von einer Traffic-Spitze?

Vergleichen Sie mit Ihrer Baseline: welche Endpoints betroffen sind, aus welchen Regionen, mit welchen User-Agents und wie sich Fehler verhalten. Angriffe wirken gleichförmig (gleiche Pfade, gleicher User-Agent), echte Spitzen sind vielfältig und haben einen Anlass wie eine Kampagne oder einen Launch.