Coraza Web Application Firewall

Oui. Coraza est entièrement compatible avec le langage de règles SecLang de ModSecurity. Vos règles existantes, y compris vos règles personnalisées et l'OWASP Core Rule Set, fonctionneront sans modification. La migration depuis ModSecurity en est d'autant plus simple.

Coraza est une réimplémentation moderne du concept de ModSecurity en Go. Il prend en charge le même langage de règles mais n'a aucune dépendance C, offre de meilleures performances dans de nombreux scénarios et un support natif des proxies modernes comme Caddy et Traefik. ModSecurity dispose d'un écosystème plus vaste et d'un historique plus long, mais son développement a ralenti depuis que Trustwave en a transféré la maintenance à la communauté.

Coraza ne dispose pas d'un module Nginx natif comme ModSecurity (libmodsecurity + le connecteur ModSecurity-nginx). Il existe plusieurs façons d'utiliser Coraza avec des configurations basées sur Nginx :

• Exécuter Caddy avec le plugin coraza-caddy en tant que reverse proxy devant Nginx
• Utiliser HAProxy avec le plugin coraza-spoa devant Nginx
• Sous Kubernetes, utiliser Envoy avec le filtre coraza-proxy-wasm comme ingress à la place de Nginx
• Il existe un module expérimental coraza-apache, mais pas encore d'équivalent Nginx stable

Si vous avez spécifiquement besoin d'un module WAF s'exécutant au sein de Nginx, ModSecurity reste le meilleur choix pour ce cas d'usage. Si vous êtes flexible sur votre couche de proxy, Coraza avec Caddy est l'option la plus courante et la mieux prise en charge.

Coraza s'intègre à HAProxy via le plugin coraza-spoa, qui utilise le protocole SPOA (Stream Processing Offload Agent) de HAProxy. Le WAF s'exécute comme un processus distinct auquel HAProxy transmet les requêtes pour inspection. Cette intégration est actuellement en phase de test (preview). La mise en place consiste à exécuter le binaire coraza-spoa aux côtés de HAProxy et à configurer HAProxy pour envoyer le trafic à travers le filtre SPOE. Vos règles CRS et vos règles SecLang personnalisées fonctionnent de la même manière qu'avec toute autre intégration Coraza.

Oui, et Kubernetes est l'une des cibles de déploiement les plus solides de Coraza. Les approches courantes :

• Utiliser le plugin coraza-caddy dans un contrôleur d'ingress basé sur Caddy
• Déployer coraza-proxy-wasm comme filtre dans les service meshes basés sur Envoy (Istio, Envoy Gateway)
• Embarquer Coraza comme bibliothèque Go dans un ingress ou une passerelle d'API sur mesure
• L'exécuter comme conteneur sidecar aux côtés de vos pods applicatifs

Parce que Coraza est une bibliothèque Go pure sans dépendance C, il se compile en un binaire unique facile à conteneuriser. Il n'y a aucune bibliothèque partagée ni dépendance d'outillage de build à gérer dans vos images de conteneurs.

Non. Coraza est une bibliothèque de moteur WAF, pas une plateforme managée. Toute la configuration se fait via des fichiers de règles SecLang et la configuration du proxy (Caddy, HAProxy, etc.). Il n'existe aucune interface web intégrée pour gérer les règles ou consulter les requêtes bloquées. Pour la visibilité, vous pouvez envoyer les journaux d'audit de Coraza vers des outils comme la pile ELK, Grafana ou tout SIEM acceptant des journaux au format JSON. Si vous avez besoin d'une gestion de WAF via interface graphique, tournez-vous vers des WAF commerciaux ou des projets comme BunkerWeb, qui encapsulent ModSecurity/CRS dans une interface web.