Dieser Leitfaden erklärt die wichtigsten Angriffstypen – von Volumetric bis Layer 7 – und zeigt anhand echter Nginx- und Cloudflare-Logs, wie moderne Angriffe erkannt werden. Mit praxisnahem AWS-vs-Cloudflare-Vergleich und Fokus auf deutsche IT-Architekturen.
In Deutschland laufen die meisten produktiven Systeme entweder vollständig in der Cloud oder in hybriden Architekturen (On-Prem + Cloud). Die Wahl zwischen AWS-nativen Schutzmechanismen und Cloudflare ist daher weniger eine Glaubensfrage, sondern eine architektonische Entscheidung.
Grundannahme in deutschen Unternehmen
- AWS: bevorzugt von Mittelstand, Industrie, SaaS
- Cloudflare: häufig als vorgelagerte Schutzschicht genutzt
- Datenschutz & DSGVO: Standort und Transparenz spielen eine große Rolle
Funktionsvergleich: AWS Shield vs Cloudflare
| Kriterium | AWS Shield (Standard / Advanced) | Cloudflare |
|---|---|---|
| Volumetric DDoS | Automatisch, globales AWS Backbone | Automatisch, globales Anycast-Netz |
| Protocol Attacks | Sehr stark (L3/L4) | Sehr stark |
| Layer-7 Schutz | Nur mit AWS WAF | Integriert (WAF standardmäßig) |
| Kostenmodell | Shield Advanced ~3.000 USD/Monat | Abhängig vom Plan |
| Traffic Scrubbing | Inklusive bei Shield Advanced | Inklusive |
| DSGVO & EU-Standorte | EU-Regionen verfügbar | EU-Datacenters verfügbar |
| Setup-Komplexität | Hoch | Niedrig |
| Hybrid-Use (On-Prem) | Begrenzt | Sehr gut geeignet |
Typische Entscheidung in Deutschland:
- Reine AWS-Workloads: CloudFront + WAF + Shield
- Hybrid oder Multi-Cloud: Cloudflare als vorgelagerte Schicht
Architekturbeispiel (praxisnah)
AWS-zentriert (Enterprise):
Internet → CloudFront → AWS WAF → ALB → Application ↘ AWS Shield (L3/L4)
Hybrid / Mittelstand (häufig in DE):
Internet → Cloudflare → Nginx / Firewall → On-Prem / Cloud Backend
Cloudflare wird hier oft genutzt, um:
- On-Prem-Systeme vor Volumetric Attacks zu schützen
- Compliance-Aufwand zu reduzieren
- Kosten planbarer zu halten
Echte Log-Beispiele: DDoS in der Praxis erkennen
Theorie endet dort, wo Logs beginnen.
Hier zwei realistische Beispiele, wie DDoS-Signaturen in deutschen Setups aussehen.
1. Nginx Access Log – Layer-7-HTTP-Flood
185.244.25.91 - - [12/Mar/2025:10:15:32 +0100] "GET /login HTTP/1.1" 200 512 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" 185.244.25.92 - - [12/Mar/2025:10:15:32 +0100] "GET /login HTTP/1.1" 200 512 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
Auffälligkeiten:
- Viele IPs
- Gleicher Endpoint
- Gleicher User-Agent
- Hohe Frequenz in kurzer Zeit
➡ Klassischer Low-and-Slow Layer-7 Angriff
2. Nginx Error Log – Ressourcenerschöpfung
[error] 24321#24321: *51234 upstream timed out (110: Connection timed out) while reading response header from upstream
Das ist kein Netzwerkproblem, sondern:
- Thread Pools blockiert
- Backend unter Applikationslast
- Häufige Folge von L7-DDoS
3. Cloudflare Log – Automatisch blockierter Angriff
{ "ClientIP": "103.21.244.5", "ClientCountry": "DE", "RequestURI": "/api/v1/auth", "EdgeResponseStatus": 403, "WAFAction": "block", "RuleID": "100173" }
Interpretation:
- API Abuse
- Region nicht verdächtig
- Verhalten ist entscheidend, nicht Herkunft
Was deutsche Teams häufig falsch interpretieren
| Annahme | Realität |
|---|---|
| „IP aus Deutschland = legitim“ | Viele Botnetze nutzen EU-Systeme |
| „CPU ist das Problem“ | Meist Thread Pools oder DB |
| „Firewall reicht“ | L7-Angriffe umgehen Firewalls |
| „Autoscaling löst alles“ | Skaliert Kosten mit |
Bezug zu Cyber-Versicherungen (DE/EU)
Immer mehr deutsche Cyber-Policen verlangen:
- WAF oder CDN im Einsatz
- dokumentierte DDoS-Strategie
- Rate Limiting & Monitoring
Fehlt das, drohen:
- höhere Prämien
- Ausschlüsse
- Ablehnung im Schadensfall
Fazit (erweitert)
In Deutschland entscheidet nicht die Größe der Infrastruktur, sondern ihre Architektur.
AWS Shield und Cloudflare sind keine Gegensätze, sondern Werkzeuge für unterschiedliche Kontexte.
Wer Logs lesen kann, versteht Angriffe früh.
Wer nur auf Verfügbarkeit schaut, reagiert zu spät.