Was tun bei einem DDoS-Angriff auf einer Website?
Vor kurzem wurde Zerlo.net mit einem DDoS-Angriff konfrontiert. Uns hat interessiert: Wie gehen wir damit um, wie erkennen wir so etwas – und wie konnten wir es eindeutig belegen? In diesem Beitrag zeige ich unsere Schritte, was hinter DDoS steckt und wie Cloudflare als Schutzschicht hilft.
Quelle: Eigene Darstellung
Erklärung: Was ist ein DDoS?
Ein Distributed-Denial-of-Service-Angriff (DDoS) ist der Versuch, einen Onlinedienst durch massenhaft verteilte Anfragen lahmzulegen. „Distributed“ bedeutet: Der Angriff kommt gleichzeitig von vielen, oft automatisierten Quellen (Botnetze). Man unterscheidet grob zwischen Angriffen auf der Netzebene (z. B. UDP/ICMP-Floods) und der Anwendungsebene (Layer 7), etwa HTTP-Floods auf dynamische Seiten oder APIs. Letzteres fühlt sich häufig wie legitimer Traffic an – nur dass die Serverlast explodiert.
Wie erkennt man es?
Ein einzelner Messwert reicht selten aus. Typische Muster sind: stark steigende Origin-Last, aber unveränderte echte Sitzungen/Conversions; plötzlich viele Anfragen auf „teure“ Endpunkte (Login, Suche, /api, Formulare); verdächtige oder leere User-Agents; ungewohnte Peaks aus neuen ASNs; hohe CPU/IO-Last ohne Codeänderung.
Erkennen via Cloudflare (professionell-informatisch)
In Cloudflare lassen sich diese Muster sauber aufschlüsseln:
- Security → Events/Analytics: Peaks nach Pfad, Land, ASN, Methode, User-Agent segmentieren.
- Traffic/Analytics: Viele Edge-Requests bei gleichzeitig hoher Origin-Quote deuten auf L7-Floods hin.
- WAF/Firewall: „Challenged/Blocked“ zählt Mitigations; hilft, Regeln zu justieren.
- Rate Limiting/HTTP-DDoS-Logs: zeigen IP-/Pfad-Hotspots, die man gezielt entschärfen kann.
Fazit: Für eine Website mit vielen Usern ist eine vorgelagerte Schutzschicht wie Cloudflare praktisch Pflicht – sie liefert Telemetrie und Werkzeuge, um zwischen legitimer Last und Angriff zu unterscheiden und schnell zu reagieren.
Persönliches
Wir von Zerlo mussten am 31.10.2025 eine ungewöhnlich hohe Auslastung feststellen – zeitweise war die Website mehrfach offline. Zuerst ging ich von einem technischen Problem aus. Dann prüfte ich die Besucherzahlen: nahezu identisch zum Vortag, was merkwürdig war, da unser Zähler nur menschliche Interaktionen (JavaScript) misst.
Der klassische Gegentest: Alles lokal (localhost) starten. Ergebnis: lokal 0 % Last – also musste die externe Last künstlich sein. In Cloudflare war der Zuwachs dann eindeutig sichtbar. Ich aktivierte testweise den Under-Attack-Mode (UAM); die Serverlast fiel auf etwa 5 % im Durchschnitt.
Quelle: Eigene Darstellung
Kurz: Wir wurden geddost.
CloudFlare
Wenn der Webhost bereits einen guten Netzebenen-Schutz hat, reicht das für volumetrische Angriffe oft aus, insbesondere wenn der Provider mitigiert. Wir betreiben bei Zerlo jedoch ein größeres Netzwerk mit mehreren Diensten und brauchen zentrale, vorgelagerte Schnittstellen, die Traffic intelligent terminieren und filtern, bevor er unsere Ursprünge erreicht. Genau hier spielt ein globales Edge-Netzwerk wie Cloudflare seine Stärken aus: Anycast, Caching, WAF, Bot-Management, Rate-Limiting und detaillierte Telemetrie.
Cloudflare ist in der Basis kostenlos nutzbar und kann bei Angriffen kurzfristig „hochgedreht“ werden. Es erkennt nicht jedes Szenario automatisch perfekt – man muss Muster beobachten –, ist danach mit den richtigen Regeln aber sehr effektiv.
Cloudflare Schutzmechanismus erklärt
So einfach wie genial: Vor dem eigentlichen Seitenaufruf kann Cloudflare eine JavaScript-basierte Prüfung (Challenge) vorschalten und dabei Signale aus dem Browser bewerten. Für echte Nutzer passiert das einmalig und kaum merkbar; Bots und Skripte scheitern oder müssen massiv mehr Ressourcen aufwenden. Ergebnis: Die Backend-Last sinkt sofort und ihr gewinnt Zeit für Feintuning (WAF-Regeln, Rate-Limits, Caching).
❝ DDoS verhindert man nicht – man managt ihn. Die Kunst ist, Angriffe für Menschen unsichtbar zu machen, aber für Bots teuer. ❞Zerlo.net
Was kann man dagegen machen?
Nichts. Einen DDoS verhinderst du nicht – jeder im Netz darf dir Pakete schicken. Aber du kannst den Effekt so klein machen, dass die Seite für echte Nutzer verfügbar bleibt. Darum geht es: intelligent dämpfen statt aussitzen.
Kurzfristig: Under-Attack-Mode (UAM) aktivieren, um Layer-7-Last sofort zu dämpfen.
Dauerhaft: WAF-Regeln für POST/APIs/teure GETs, Managed-Challenges für verdächtige User-Agents, Rate-Limiting pro IP auf sensible Endpunkte. Für öffentliche Seiten „Cache Everything“, für Logins/Admins „Bypass on Cookie“.
Betrieb: Security- und Traffic-Analytics beobachten, Alerts setzen, Logs sichern. Ein kleines Skript kann UAM automatisch ziehen, wenn Pings ausfallen – und euch benachrichtigen.
(len(http.user_agent) = 0
or lower(http.user_agent) contains "python"
or lower(http.user_agent) contains "curl"
or lower(http.user_agent) contains "bot"
or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge
(http.request.method eq "POST"
or starts_with(http.request.uri.path, "/api/")
or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge
# Rate Limiting (Beispiel)
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge#!/usr/bin/env bash
# Under-Attack-Mode per API setzen (Beispiel)
# Voraussetzung: CF_API_TOKEN mit Berechtigung 'Zone Settings Edit'
ZONE_ID="<ZONE_ID>"
# UAM EIN
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
--data '{"value":"under_attack"}'
# UAM AUS (z.B. wieder auf 'high' oder 'medium')
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
--data '{"value":"high"}'# Nginx: simples per-IP-Limit (Beispiel)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;
server {
location /api/ {
limit_req zone=perip burst=60 nodelay;
proxy_pass http://backend;
}
}Fazit
DDoS ist kein Ausnahmezustand, sondern ein Betriebsfall. Wer Anomalien schnell erkennt, kurzfristig dämpft und dann gezielt härtet, bleibt online. Für wachsende Websites ist Cloudflare als vorgelagerte Schutzschicht sehr zu empfehlen: Sichtbarkeit, Sofortmaßnahmen und Bausteine für einen robusten Dauerbetrieb.