WAF open source : quel pare-feu applicatif choisir

Trois logiciels libres filtrent les requêtes avant qu'elles n'atteignent une application web, et chacun a sa méthode. BunkerWeb prend la place du reverse proxy et bloque d'office ce que signale l'OWASP Core Rule Set (CRS). CrowdSec part des logs et d'une liste d'IP partagée entre ses utilisateurs, et son WAF ne bloque, dans sa configuration de base, que des failles connues. open-appsec se greffe sur le proxy en place et juge chaque requête avec des modèles appris, sans signatures. Les trois se combinent : BunkerWeb et open-appsec savent appliquer les décisions de CrowdSec.

Règles OWASP, réputation partagée ou modèle appris

BunkerWeb et le composant AppSec de CrowdSec chargent tous deux le CRS, mais n'en font pas le même usage. BunkerWeb l'applique en ligne, en version 4 et au niveau de paranoïa 1, le moins strict des quatre : une requête qui déclenche une règle est refusée. Le déploiement de base que documente CrowdSec ne bloque en ligne que des failles connues, avec la collection de correctifs virtuels de son Hub, 190 règles qui visent chacune une CVE. Le CRS s'y ajoute hors bande : il laisse passer la requête, mais une IP qui le déclenche sur plus de cinq requêtes distinctes en peu de temps est bannie.

La réputation n'attend pas qu'une requête soit suspecte : une IP signalée ailleurs est refusée dès sa première requête. Chez CrowdSec, les scénarios lisent les logs, ceux de SSH comme ceux de NGINX, et chaque moteur qui remonte ses alertes reçoit en échange une liste communautaire d'IP malveillantes. BunkerWeb tient son propre réseau, BunkerNet, actif par défaut, qui distribue les IP bloquées par les autres instances.

Le modèle appris est la voie d'open-appsec, publié par Check Point. Un premier modèle, entraîné hors ligne, juge chaque requête ; s'il la trouve suspecte, un second, appris sur le trafic du site, tient compte de l'URL et des utilisateurs en jeu pour décider du blocage. L'éditeur promet ainsi une protection contre les failles zero-day sans signatures à tenir à jour ni exceptions à gérer. Les signatures reviennent pourtant dans son moteur IPS, qui couvre plus de 2 800 CVE web et reste réservé aux abonnés.

Où chaque outil se branche

BunkerWeb est lui-même le reverse proxy : un serveur NGINX, installé en paquet Linux, en conteneurs Docker ou comme Ingress controller sur Kubernetes. Son service autoconf suit les conteneurs et les Ingress qui apparaissent, et reconfigure l'instance sans la recréer. L'adopter revient à remplacer le proxy existant.

CrowdSec sépare la détection du blocage. Le moteur lit les logs et range ses décisions dans une API locale, que des bouncers appliquent dans le pare-feu ou le reverse proxy, au besoin sur d'autres machines. Le moteur seul ne bloque rien. Pour le WAF, il faut un bouncer qui lui transmet les requêtes : NGINX, OpenResty, Traefik, HAProxy ou Envoy.

open-appsec s'installe dans le proxy déjà en place. Un module en C, l'« attachment », se greffe sur NGINX, Kong, APISIX, Envoy ou la passerelle d'entrée Istio, et passe les requêtes à un agent par mémoire partagée. Sur Linux, l'installeur prend un module précompilé pour la version du serveur, et une version absente de la liste oblige à le compiler. L'équipe publie aussi des images de NGINX Proxy Manager qui l'embarquent.

Les projets documentent eux-mêmes leurs combinaisons. Le plugin CrowdSec de BunkerWeb en fait un bouncer, qui peut aussi soumettre les requêtes au composant AppSec, et son image tout-en-un embarque un agent CrowdSec, éteint par défaut. open-appsec peut bloquer les adresses fournies par CrowdSec, sur Ingress NGINX ou sous Docker avec NGINX ou Kong, et une collection CrowdSec lit en retour ses logs pour alimenter la liste communautaire.

Ce que chaque outil demande pour tourner

Relevé dans les dépôts et les documentations le 7 octobre 2026.

Hors image tout-en-un, BunkerWeb fait tourner au moins l'instance NGINX et le scheduler, qui range la configuration en base et la génère ; sur Kubernetes, plusieurs instances partagent un Redis ou un Valkey. CrowdSec conseille MySQL, MariaDB ou PostgreSQL à une API locale très sollicitée. Sans jeton du portail my.openappsec.io, le fichier Compose d'open-appsec lance l'agent, le NGINX équipé, smartsync, qui fusionne l'apprentissage des instances, son stockage, un service de tuning et PostgreSQL 18. L'agent y partage l'espace IPC de l'hôte, et l'exemple tire l'image latest. Aucune des trois documentations ne chiffre la mémoire nécessaire.

Avant de bloquer : détection seule et faux positifs

BunkerWeb a un mode detect qui journalise sans bloquer, et ses réglages par défaut le justifient : 2 requêtes par seconde par IP et par URL, et 24 heures de bannissement pour un client qui reçoit 10 erreurs HTTP en 60 secondes. Son README « recommande fortement » d'ajuster ces valeurs. Les faux positifs du CRS se corrigent par des fichiers de configuration chargés avant ou après les règles, et le niveau de paranoïa se relève de la même façon.

open-appsec démarre en mode Learn/Detect. Avec assez de trafic, l'apprentissage prend « environ 2 à 3 jours », et la documentation conseille de passer en mode Prevent au niveau « Graduate », le troisième sur cinq.

La documentation de CrowdSec donne pour minimes les faux positifs de ses correctifs virtuels, qui ne visent que des failles connues. Elle prévient en revanche que le CRS appliqué en ligne peut demander des réglages pour les limiter.

Ce que chaque instance envoie et reçoit

BunkerNet, activé d'office, inscrit l'instance BunkerWeb auprès de api.bunkerweb.io, y signale chaque IP bloquée avec la raison du blocage et un contexte minimal, puis télécharge la liste commune. USE_BUNKERNET=no coupe l'échange. BunkerNet est aussi la condition pour inscrire une instance dans la console de CrowdSec, avec qui Bunkerity revendique un partenariat.

CrowdSec envoie à son API centrale, pour chaque alerte, le nom et la version du scénario, l'heure, l'identifiant de la machine et l'IP en cause, jamais les logs. La liste reçue dépend de cette contribution : 15 000 IP pour une instance qui remonte régulièrement des signaux, 3 000 dans la version Lite servie aux autres. La documentation cite deux causes de rétrogradation : des services auto-hébergés fréquentés par un petit cercle, ou déjà fermés par un VPN, un géoblocage ou une authentification OAuth.

La documentation d'open-appsec ne mentionne pas de liste partagée entre ses utilisateurs. Son service smartsync met en commun l'apprentissage des instances d'un même déploiement, et c'est la collection CrowdSec qui fait sortir ses logs vers une liste communautaire.

Ce que réservent les éditions payantes

BunkerWeb réserve dix-neuf modules à sa version PRO, dont l'authentification OpenID Connect, SAML ou LDAP devant les applications, l'exporteur Prometheus, l'anti-DDoS et la gestion de plusieurs utilisateurs dans l'interface. Le site affiche 49 € par mois pour l'offre Shield et 149 € pour Fortress, et la licence exige un accès sortant vers api.bunkerweb.io. La version libre est sous AGPL-3.0 : qui expose une version modifiée en service réseau doit en publier le code.

Le moteur de CrowdSec, son Hub et ses bouncers officiels pare-feu, NGINX et HAProxy sont sous licence MIT. L'offre Premium, facturée par moteur inscrit et sans prix affiché, ajoute la synchronisation des décisions entre instances, des listes d'autorisation centralisées, jusqu'à un an d'historique et une liste de 60 000 IP sans obligation de contribuer. La console gratuite s'arrête à 500 alertes par mois, sur deux mois d'historique.

Le dépôt d'open-appsec est sous Apache-2.0, modèle « basic » compris, mais le README réserve ce modèle aux tests et à la surveillance seule. Le modèle « advanced », recommandé en production, se télécharge après connexion au portail de l'éditeur, sous une licence propre. L'anti-bot, la validation de schéma d'API, l'analyse des fichiers et l'IPS demandent un abonnement à Check Point WAF, l'édition entreprise, ou à l'édition Premium. La documentation marque cette dernière « deprecated », mais la page des tarifs la vend toujours de 79 à 109 dollars par mois. En édition communautaire, la limitation de débit n'admet qu'une règle.

Où en sont les projets

BunkerWeb, dont le dépôt date de 2019, a publié neuf versions stables depuis janvier 2026, et sa 1.6.16 en est à la quatrième release candidate. Son intégration Swarm est dépréciée, et le mode Gateway API de Kubernetes reste en bêta. CrowdSec a sorti six versions stables en 2026, contre onze en 2025 ; la 1.8.0 de fin août corrigeait deux failles de déni de service et a introduit une détection des bots encore en alpha. open-appsec a publié quatre versions en 2026, contre dix en 2025, et sa branche principale compte 10 commits cette année, dont un lot de 216 fichiers. Les notes de ses trois dernières versions s'en tiennent à la prise en charge de nouvelles versions de NGINX et de distributions Linux, et à des correctifs. L'audit de code par un tiers que cite son README date de 2022.