IT-Sicherheit
WAF (Web Application Firewall)
Eine Web Application Firewall (WAF) inspiziert HTTP-Verkehr auf Layer 7 und blockiert Webangriffe wie SQL-Injection, XSS und Path Traversal.
- Schutz auf Layer 7
- Reverse Proxy, Regelwerke
- OWASP Core Rule Set
- ModSecurity, Coraza
- gegen SQLi, XSS, Path Traversal
Eine Web Application Firewall (WAF) schützt Webanwendungen auf der Anwendungsebene (Layer 7). Sie inspiziert den HTTP/HTTPS-Verkehr und blockiert verbreitete Angriffe wie SQL-Injection, Cross-Site-Scripting und Path Traversal, also genau die Klasse von Angriffen, die ein klassischer Paketfilter nicht sieht, weil er den Inhalt nicht interpretiert.
Dieser Artikel erklärt die Funktionsweise als Reverse Proxy, die positiven und negativen Sicherheitsmodelle, das OWASP Core Rule Set, die Open-Source-Engines ModSecurity und Coraza sowie die Betriebshinweise rund um Tuning und die Abgrenzung zu sicherer Programmierung.
1. Funktionsweise
Eine WAF sitzt typischerweise als Reverse Proxy vor der Anwendung: Jede Anfrage läuft durch sie hindurch, wird gegen Regelwerke geprüft und dann weitergeleitet, geloggt oder blockiert. Man unterscheidet das negative Modell (alles erlaubt außer bekannten Angriffsmustern, einfach, aber pflegeintensiv) und das positive Modell (nur explizit Erlaubtes durchlassen, sicherer, aber aufwendiger). Moderne WAFs kombinieren beides.
2. OWASP Core Rule Set
Das OWASP Core Rule Set (CRS) ist das verbreitetste generische Regelwerk und deckt die Angriffsklassen der OWASP Top 10 ab. Es arbeitet mit anomaliebasiertem Scoring: Verdächtige Merkmale sammeln Punkte, überschreitet eine Anfrage den Schwellwert, wird sie blockiert. Über Paranoia-Level lässt sich die Aggressivität steuern, Level 1 ist der übliche Einstieg in Produktionsumgebungen.
3. Engines: ModSecurity und Coraza
ModSecurity ist die klassische Open-Source-Engine; sie liegt seit 2024 bei der OWASP Foundation (der kommerzielle Trustwave-Support endete). Die aktuelle libmodsecurity (v3) wird über Konnektoren etwa an nginx angebunden. Der moderne Nachfolger Coraza (OWASP, in Go) versteht dieselbe Regelsprache (SecLang) und ist mit dem CRS v4 kompatibel; er lässt sich als Caddy-Plugin oder als WebAssembly-Filter für Envoy und Istio einsetzen, ideal für Cloud-native Umgebungen.
Die WAF-Welt verschiebt sich von ModSecurity als Webserver-Modul hin zu Coraza als einbettbarer, Cloud-nativer Engine, beide aber sprechen dasselbe Regelwerk, das OWASP CRS.
4. Betrieb und Grenzen
Eine WAF ist kein Ersatz für sichere Programmierung: Logikfehler, fehlerhafte Berechtigungsprüfungen und Angriffe mit formal gültigen Anfragen kann sie strukturell nicht abfangen. Neue Deployments laufen zunächst im Detection-Modus (nur protokollieren), um über Wochen eine Baseline zu bilden und False Positives zu beseitigen, erst dann wird scharf geschaltet. Generische Regelwerke erzeugen ohne Tuning Fehlalarme bei legitimem Verkehr.
Erst beobachten, dann blockieren
Eine WAF direkt scharf zu schalten, blockiert oft legitimen Verkehr. Bewährt ist: im Log-only-Modus starten, Baseline bilden, False Positives tunen, hochkonfidente Regeln zuerst aktivieren und schrittweise erweitern. Eine WAF ergänzt sicheren Code, sie ersetzt ihn nicht.
5. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Fängt verbreitete Webangriffe (SQLi, XSS, Path Traversal) ab | Kein Ersatz für sichere Programmierung; Logikfehler bleiben |
| Generisches OWASP CRS, engine-übergreifend (ModSecurity, Coraza) | Ohne Tuning False Positives bei legitimem Verkehr |
| Self-hosted mit voller Kontrolle und Datenhoheit | Erfordert Pflege, Tuning und einen sauberen Rollout (erst Detection) |
Häufige Fragen zu WAF (Web Application Firewall)
Nein. Eine WAF ist ein zusätzlicher Schutzschild gegen verbreitete, signaturbeschreibbare Angriffe, aber Logikfehler, fehlerhafte Zugriffskontrolle und Angriffe mit gültigen Anfragen kann sie nicht abfangen. Sicherer Code bleibt die Grundlage.
Beide nutzen dieselbe Regelsprache und das OWASP CRS. ModSecurity (v3) ist etabliert und über Konnektoren etwa an nginx angebunden. Coraza ist der moderne Go-Nachfolger, thread-sicher und besonders für Cloud-native Setups (Caddy, Envoy/Istio via WebAssembly) geeignet.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
WAF (Web Application Firewall) im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.