Coraza Web Application Firewall

Ja. Coraza ist vollständig kompatibel mit der SecLang-Regelsprache von ModSecurity. Ihre bestehenden Regeln, einschließlich benutzerdefinierter Regeln und des OWASP Core Rule Set, funktionieren ohne Anpassung. Das macht die Migration von ModSecurity unkompliziert.

Coraza ist eine moderne Neuimplementierung des ModSecurity-Konzepts in Go. Es unterstützt dieselbe Regelsprache, hat aber keine C-Abhängigkeiten, in vielen Szenarien eine bessere Performance und native Unterstützung für moderne Proxys wie Caddy und Traefik. ModSecurity verfügt über ein größeres Ökosystem und eine längere Erfolgsbilanz, doch seine Entwicklung hat sich verlangsamt, seit Trustwave die Pflege an die Community übergeben hat.

Coraza verfügt nicht über ein natives Nginx-Modul wie ModSecurity (libmodsecurity + der ModSecurity-nginx-Connector). Es gibt einige Möglichkeiten, Coraza mit Nginx-basierten Setups zu nutzen:

• Caddy mit dem coraza-caddy-Plugin als Reverse Proxy vor Nginx betreiben
• HAProxy mit dem coraza-spoa-Plugin vor Nginx einsetzen
• In Kubernetes Envoy mit dem coraza-proxy-wasm-Filter als Ingress statt Nginx verwenden
• Es gibt ein experimentelles coraza-apache-Modul, aber noch kein stabiles Nginx-Äquivalent

Wenn Sie speziell ein WAF-Modul benötigen, das innerhalb von Nginx läuft, ist ModSecurity für diesen Anwendungsfall nach wie vor die bessere Wahl. Wenn Sie bei Ihrer Proxy-Schicht flexibel sind, ist Coraza mit Caddy die häufigste und am besten unterstützte Option.

Coraza wird über das coraza-spoa-Plugin in HAProxy integriert, welches das SPOA-Protokoll (Stream Processing Offload Agent) von HAProxy nutzt. Die WAF läuft als separater Prozess, an den HAProxy Anfragen zur Prüfung weiterleitet. Dies befindet sich derzeit im Preview-Status. Für das Setup wird das coraza-spoa-Binary neben HAProxy betrieben und HAProxy so konfiguriert, dass es den Datenverkehr durch den SPOE-Filter leitet. Ihre CRS-Regeln und benutzerdefinierten SecLang-Regeln funktionieren genauso wie bei jeder anderen Coraza-Integration.

Ja, und Kubernetes ist eines der stärksten Einsatzziele von Coraza. Gängige Ansätze:

• Das coraza-caddy-Plugin in einem Caddy-basierten Ingress-Controller verwenden
• coraza-proxy-wasm als Filter in Envoy-basierten Service Meshes (Istio, Envoy Gateway) bereitstellen
• Coraza als Go-Bibliothek in einen eigenen Ingress oder ein API-Gateway einbetten
• Es als Sidecar-Container neben Ihren Anwendungs-Pods betreiben

Da Coraza eine reine Go-Bibliothek ohne C-Abhängigkeiten ist, kompiliert es zu einem einzigen Binary, das sich leicht containerisieren lässt. In Ihren Container-Images müssen keine Shared-Library- oder Build-Tool-Abhängigkeiten verwaltet werden.

Nein. Coraza ist eine WAF-Engine-Bibliothek, keine Managed-Plattform. Die gesamte Konfiguration erfolgt über SecLang-Regeldateien und die Proxy-Konfiguration (Caddy, HAProxy usw.). Es gibt keine integrierte Web-Oberfläche zum Verwalten von Regeln oder zum Einsehen blockierter Anfragen. Für Transparenz können Sie Coraza-Audit-Logs an Tools wie den ELK-Stack, Grafana oder jedes SIEM senden, das JSON-Logs akzeptiert. Wenn Sie eine GUI-basierte WAF-Verwaltung benötigen, sehen Sie sich kommerzielle WAFs oder Projekte wie BunkerWeb an, die ModSecurity/CRS mit einer Web-Oberfläche versehen.