Un web application firewall open source filtre le trafic HTTP avant qu’il n’atteigne l’application. Placé en reverse proxy, il bloque les requêtes suspectes sans modifier le code applicatif. Pour une équipe DevOps, un administrateur système ou un porteur de service web, l’objectif est simple : ajouter une couche de défense claire, testable et facile à administrer.
Ce qu’un WAF open source change dans l’architecture web
Un WAF n’est pas un pare-feu réseau classique. Il ne se limite pas à ouvrir ou fermer des ports. Il inspecte les requêtes applicatives, les paramètres, les en-têtes, les chemins d’URL et certains comportements répétitifs. Sa place naturelle se situe donc devant l’application, entre Internet et le backend, comme un sas de contrôle.
Comprendre BunkerWeb
Le rôle du reverse proxy
Dans une architecture courante, le reverse proxy reçoit les requêtes sur les ports publics, par exemple 80/TCP et 443/TCP, puis les transmet au service interne si elles sont acceptées. Une solution comme BunkerWeb suit ce modèle : elle repose sur NGINX, se place en frontal et protège les applications web exposées.
Ce positionnement a un avantage concret. L’application n’a pas besoin de connaître les règles WAF. Elle continue de répondre normalement, tandis que le filtrage, les bans, les headers de sécurité et la terminaison HTTPS éventuelle sont gérés en amont.
Pourquoi l’open source compte vraiment
Le caractère open source apporte de la transparence sur le fonctionnement, les composants et les règles utilisées. BunkerWeb propose une offre Free sous licence AGPLv3, avec une option PRO pour des besoins plus avancés. Cela permet de commencer avec une base communautaire, puis d’évaluer si un support ou des fonctionnalités commerciales deviennent nécessaires en production.
L’open source ne garantit pas à lui seul une bonne protection. La valeur réelle dépend de la qualité de la configuration, de la surveillance des logs, des mises à jour et de l’intégration dans l’infrastructure existante.
Les attaques qu’un web application firewall open source doit arrêter
Un WAF est utile parce que les applications exposées reçoivent en permanence du trafic automatisé, comme des scanners, des robots de brute force, des tentatives d’injection et des explorations de fichiers sensibles. Même une application peu connue peut être ciblée, simplement parce qu’elle est accessible publiquement.
SQLi, XSS, path traversal et scans automatisés
Les protections attendues couvrent les attaques applicatives classiques : injection SQL, XSS, path traversal, requêtes de scan et comportements assimilables à du brute force. BunkerWeb intègre ModSecurity et utilise OWASP CRS 4, un ensemble de règles conçu pour repérer ces schémas d’attaque.
Le moteur peut fonctionner avec une logique d’anomaly scoring. Au lieu de bloquer uniquement une signature isolée, il attribue un score à une requête selon plusieurs signaux. Dans certaines configurations, un seuil de blocage de 5 et un niveau PL1 servent de base, avec un seuil des réponses à 4 selon le paramétrage.
Rate limiting et ban automatique
Le filtrage de contenu ne suffit pas toujours. Un formulaire de connexion, une API publique ou une page dynamique peuvent subir des vagues de requêtes valides en apparence, mais trop nombreuses. Le rate limiter répond à ce problème en limitant la cadence, par exemple avec une valeur comme LIMIT_REQ_RATE: 2r/s.
Le ban automatique complète ce mécanisme. Lorsqu’une adresse accumule trop de comportements suspects, elle peut être bloquée. Cette logique devient plus utile si les données sont persistées, car les bans et l’historique ne doivent pas disparaître à chaque redémarrage du conteneur.
BunkerWeb comme exemple concret de WAF open source déployable
Parmi les solutions visibles sur ce sujet, BunkerWeb illustre bien l’approche moderne : reverse proxy, WAF, Web UI, configuration pilotée, conteneurs et protections activées par défaut. Son intérêt est de rendre le déploiement accessible avec Docker Compose tout en conservant une architecture plus structurée qu’un simple conteneur isolé.
Instance, Scheduler, API et base de données
L’architecture repose sur plusieurs rôles. L’instance BunkerWeb traite le trafic. Le Scheduler porte la configuration métier et la pousse vers l’instance. L’API interne sert aux échanges entre composants. La base de données conserve la configuration, les états et les informations nécessaires au fonctionnement.
Cette séparation est saine : elle distingue le plan de données, qui voit passer les requêtes des visiteurs, du plan de contrôle, qui administre la sécurité. Elle impose aussi une règle stricte : l’API interne ne doit jamais être exposée à Internet. Elle doit rester sur un réseau interne, idéalement limitée par whitelist IP, par exemple sur 127.0.0.0/8 ou un sous-réseau Docker dédié comme 10.20.30.0/24 selon l’architecture.
All-In-One, lab et production
Le mode All-In-One embarque BunkerWeb, Scheduler, Web UI, Redis et base de données dans une approche pratique pour découvrir, tester ou monter un lab. C’est confortable pour valider le comportement, observer les logs et vérifier les protections sans multiplier les services.
En production, une stack multi-conteneurs est souvent plus lisible. Chaque composant a son rôle, ses volumes, ses droits et ses contraintes réseau. Les prérequis doivent aussi être anticipés. Des configurations mentionnent 6 Go de RAM et 2 CPU comme base, tandis que 8 Go de RAM peuvent être plus confortables selon la charge, les règles activées et le nombre de services protégés.
Pour penser un WAF, il faut l’imaginer comme une chaîne de vérifications successives : l’accès réseau, la validité de la requête, le rythme du visiteur, la réputation temporaire de l’adresse, puis l’entrée vers l’application. Si la vraie IP client est mal remontée derrière un proxy ou un load balancer, les bans, les seuils et les logs perdent en fiabilité. Même avec de bonnes règles, la protection devient moins lisible.
Déployer vite, mais vérifier tout de suite
Docker Compose est le mode de déploiement le plus accessible pour commencer. Il permet de déclarer les services, les réseaux, les volumes, les ports exposés et les variables de configuration dans un fichier unique. L’objectif n’est pas seulement de lancer le WAF, mais de prouver qu’il protège réellement le bon flux.
Les points de configuration à ne pas négliger
Les ports publics doivent être clairement identifiés : 80/TCP pour HTTP, 443/TCP pour HTTPS, et parfois 443/UDP si vous activez des usages liés à QUIC. La Web UI peut être publiée sur un port dédié comme 7000, mais elle doit rester protégée. Certains exemples utilisent aussi 8080 ou 8443 en phase de test, notamment pour éviter de monopoliser les ports standards.
La persistance est indispensable. Un volume monté sur un chemin de données, par exemple /data, évite de perdre la configuration, l’historique et les bans. Les droits doivent être cohérents avec l’utilisateur attendu, par exemple 101:101 lorsque le conteneur l’exige. Pour les journaux, une rotation comme 10 fichiers de 10 Mo permet d’éviter une croissance incontrôlée.
Tester le passage du trafic et les blocages
Une application de test comme whoami est pratique pour vérifier que le trafic traverse bien le WAF et que les headers reçus correspondent à ce qui est attendu. Avec curl, il est possible de contrôler le header Host, d’observer les réponses, puis de déclencher volontairement une requête suspecte afin de confirmer l’apparition d’un blocage dans les logs.
Il faut aussi vérifier le statut healthy des conteneurs, l’initialisation de la base, le téléchargement éventuel de listes ou de règles, puis la bonne propagation de la configuration par le Scheduler. Un WAF démarré n’est pas forcément un WAF opérationnel. Les logs et les réponses HTTP doivent confirmer la chaîne complète.
Protections par défaut, HTTPS et critères de choix
Un bon WAF open source doit offrir une sécurité utile dès les premières requêtes, sans exiger des jours de réglage. Les protections par défaut ne remplacent pas un durcissement adapté, mais elles réduisent fortement l’exposition initiale.
| Fonction | Utilité concrète | Point de vigilance |
|---|---|---|
| ModSecurity + OWASP CRS 4 | Détection SQLi, XSS, path traversal et requêtes anormales | Ajuster les faux positifs selon l’application |
| Rate limiter | Réduction du brute force et des rafales automatisées | Fixer un seuil compatible avec les usages réels |
| Ban automatique | Blocage temporaire des clients hostiles | Configurer correctement la vraie IP client |
| Headers de sécurité | Durcissement des réponses HTTP | Tester l’impact sur les navigateurs et intégrations |
| HTTPS et HSTS | Chiffrement et réduction des dégradations HTTP | Activer HTTPS explicitement et valider les certificats |
Les headers de sécurité automatiques complètent bien le filtrage applicatif. En HTTPS, HSTS peut être activé par défaut avec une durée de 2 ans, ce qui renforce la préférence du navigateur pour les connexions chiffrées. Attention toutefois : HTTPS doit être configuré explicitement, notamment avec les certificats adaptés, par exemple via Let’s Encrypt si l’environnement le permet.
Pour choisir une solution, il faut partir des contraintes réelles : besoin d’une Web UI, simplicité Docker Compose, licence open source, persistance, séparation des composants, compatibilité avec un load balancer, niveau de support attendu. Un lab peut très bien commencer avec une image All-In-One. Une production exposée doit surtout sécuriser l’API interne, documenter les réseaux, sauvegarder la base et surveiller les logs de blocage.
Un web application firewall open source ne rend pas une application invulnérable, mais il ajoute une barrière active, observable et évolutive. Placé correctement, testé dès le déploiement et administré avec rigueur, il devient une pièce centrale de la sécurité applicative.