遇到网站DDoS攻击时该怎么办？

Manuel Schulz · 31.10.2025 · IT 安全 · 7 分钟

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. Wenn ihr ähnliche Probleme habt, findet ihr praktische Tools auf unserer Zerlo-Toolseite und weitere Beiträge im Zerlo-Blog .

Feature-Banner: DDoS-Angriff – Symbolbild

来源: 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 ( CISA-Leitfaden). ). HTTP-Floods. Man unterscheidet grob zwischen Angriffen auf der Netzebene (z. B. UDP/ICMP-Floods) und der Anwendungsebene (Layer7), etwa (Denial of Service)). Eine gute, praxisnahe Einführung liefert auch OWASP (

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. Hilfreich sind saubere Logs, die ihr z. B. über Cloudflare Logpush/Log Explorer oder serverseitig auswertet. Eine kompakte Checkliste findet ihr im Zerlo-Blog bei ähnlichen Vorfällen.

Erkennen via Cloudflare

In Cloudflare lassen sich diese Muster sauber aufschlüsseln:

Security → Events/Analytics: Peaks nach Pfad, Land, ASN, Methode, User-Agent segmentieren ( Security Analytics)).
Traffic/Analytics: Viele Edge-Requests bei gleichzeitig hoher Origin-Quote → Indiz für L7-Floods ( Traffic Analytics)).
WAF/Firewall: „Challenged/Blocked“ zählt Mitigations; Regeln feinjustieren ( Cloudflare WAF)).
HTTP-DDoS/Rate Limiting: IP-/Pfad-Hotspots identifizieren ( Rate Limiting Rules, HTTP DDoS Managed Rules)).

Fazit: Für Websites mit vielen Usern ist eine vorgelagerte Schutzschicht wie Cloudflare Application Services praktisch Pflicht – Telemetrie und Werkzeuge helfen, zwischen legitimer Last und Angriff zu unterscheiden und schnell zu reagieren. Intern verweisen wir für Grundlagenartikel auf den Zerlo-Blog und für Tooling auf die Zerlo-Tools.

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. Under-Attack-Mode (UAM) 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

Cloudflare-Statistik: starker Anstieg eingehender Requests

来源: Eigene Darstellung

Kurz: Wir wurden geddost. Mehr Einblicke teilen wir laufend im Zerlo-Blog.

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 hilft ein globales Edge-Netzwerk wie Cloudflare: Anycast, Caching, WAF, Bot Fight Mode, 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. Für Setups und Benchmarks dokumentieren wir Best Practices auch auf zerlo.net/de/tools.

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, Rate-Limits, Caching)).

❝ DDoS verhindern man nicht – man managt ihn. Die Kunst ist, Angriffe für Menschen unsichtbar zu machen, aber für Bots teuer. ❞

Manuel Schulz

Zerlo.net

来源: Kurzüberblick zu Botnetzen und DDoS.

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. Für öffentliche Seiten „ Cache Everything“, “, für Logins/Admins „Bypass on Cookie“. Formulare mit Turnstile absichern.

Betrieb: Security Analytics beobachten, Alerts setzen, Logs sichern. Ein kleines Skript kann UAM automatisch ziehen, wenn Pings ausfallen – und euch benachrichtigen. Beispiele und Snippets dokumentieren wir auf zerlo.net/de/blog.

Cloudflare: sinnvolle WAF-/Rate-Limit-Regeln

(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

# Doku:
# UAM: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
# WAF: https://developers.cloudflare.com/waf/
# Rate Limiting: https://developers.cloudflare.com/waf/rate-limiting-rules/
# Challenges: https://developers.cloudflare.com/cloudflare-challenges/

cloudflare_uam_toggle.sh

#!/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 $CF_API_TOKEN" \
  -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 $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"high"}'

# Mehr: https://developers.cloudflare.com/api/operations/zone-settings-change-security-level

nginx_rate_limit_example.conf

# 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;
  }
}

# OWASP-DoS-Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

Weitere Ressourcen

Grundlagen und Vertiefung: NIST-DoS, NIST-DDoS, CISA-DDoS, OWASP-DoS, Cloudflare Learning Center. Weitere Praxisartikel und Tools findet ihr auf zerlo.net und speziell unter zerlo.net/de/tools.

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. Für individuelle Setups, Checklisten und Snippets verweisen wir auf den Zerlo-Blog und die Zerlo-Tools.