BunkerWeb : ce pare-feu web open source qui protège vos sites sans toucher au code

Un site vitrine hébergé sur un NAS d'atelier, exposé directement sur Internet, sans aucune couche de filtrage devant lui : c'est un scénario que l'on croise encore souvent chez des artisans ou petites structures du Lot-et-Garonne qui gèrent eux-mêmes leur hébergement. La moindre faille dans l'application web devient alors une porte d'entrée directe. C'est exactement le problème qu'un WAF (Web Application Firewall, ou pare-feu applicatif web) comme BunkerWeb est censé limiter, en s'intercalant entre le visiteur et le serveur.

Avant d'installer quoi que ce soit, il vaut mieux comprendre ce que fait réellement cet outil, où il place le curseur entre sécurité et simplicité, et pour qui il a du sens. C'est l'objet de cet article : ni notice marketing, ni tutoriel technique complet, mais un tour d'horizon honnête.

Qu'est-ce que BunkerWeb, concrètement ?

BunkerWeb est un reverse proxy — un serveur qui reçoit toutes les requêtes à la place du serveur applicatif, les examine, puis ne transmet que celles jugées légitimes. Il s'appuie sur NGINX, un logiciel de serveur web largement répandu, auquel il ajoute une couche de filtrage de sécurité.

Cette couche repose notamment sur le moteur ModSecurity, couplé aux règles OWASP CRS 4 (Core Rule Set), un ensemble de signatures maintenu par la communauté OWASP pour repérer les tentatives d'injection SQL, de script malveillant ou d'autres attaques web classiques. BunkerWeb y ajoute un limiteur de débit et un système de bannissement automatique des adresses suspectes.

Une version gratuite, sous licence libre

La version de base de BunkerWeb est distribuée sous licence AGPLv3, une licence open source qui autorise l'usage, la modification et la redistribution du code, avec des obligations de partage si le logiciel est modifié et exposé en service réseau. Cela en fait un outil accessible sans barrière d'entrée financière pour l'essayer.

Une réserve s'impose ici : les montants exacts d'une éventuelle licence professionnelle ou d'un abonnement à l'offre cloud gérée ne sont pas confirmés par les sources consultées. Ces informations, si elles existent, évoluent et doivent être vérifiées directement sur le site de l'éditeur avant toute décision budgétaire.

Comment BunkerWeb décide-t-il de bloquer une requête ?

Le comportement de BunkerWeb face à une menace détectée dépend d'un réglage central, appelé SECURITY_MODE. Selon la documentation officielle de BunkerWeb, ce paramètre est configuré par défaut sur block : toute requête jugée dangereuse est bloquée activement.

Un second mode existe, detect, qui se contente d'enregistrer les activités suspectes dans les journaux sans bloquer la requête. Ce mode sert surtout à observer le comportement du filtre avant de l'activer pleinement, afin de repérer les faux positifs — des requêtes légitimes bloquées à tort — sans pénaliser les visiteurs réels.

Dans la pratique, je recommande toujours de démarrer en mode détection quelques temps sur un site en production avant de basculer en blocage strict. C'est la seule façon de vérifier que le filtrage ne casse pas un formulaire de contact ou un espace client légitime.

Limiter le débit et bannir automatiquement

BunkerWeb permet aussi de plafonner le nombre de requêtes par seconde qu'une même source peut envoyer, via une directive comme LIMIT_REQ_RATE — un réglage à 20r/s est un ordre de grandeur courant pour freiner un robot trop insistant sans gêner un usage humain normal. Les journaux, eux, sont soumis à une rotation régulière, avec une taille standard de 10m pour LOG_MAX_SIZE.

Faut-il l'installer soi-même ou passer par une offre gérée ?

BunkerWeb existe sous plusieurs formes de déploiement, et le choix change beaucoup la charge de travail derrière. Une image dite Tout-En-Un (All-In-One, ou AIO) regroupe dans un seul conteneur Docker BunkerWeb, son planificateur (Scheduler), l'interface d'administration Web UI, la base Redis et la base de données.

Cette formule est présentée comme la plus simple pour démarrer rapidement. En face, une architecture multi-conteneurs, où chaque composant tourne séparément, permet une meilleure isolation et une maîtrise plus fine en environnement de production — les sources divergent sur ce point, sans qu'aucune ne tranche clairement en faveur de l'une ou de l'autre pour tous les cas d'usage.

Il existe aussi une offre gérée, BunkerWeb Cloud, où l'éditeur héberge et exploite l'infrastructure de filtrage à la place du client. Selon la documentation officielle, l'offre Standard attribue 8 Go de RAM et 2 CPU par instance, avec une réplication sur deux instances pour assurer la haute disponibilité.

Comment le mettre en place sans perdre la vraie adresse IP des visiteurs ?

Un piège classique quand on place un reverse proxy devant un site : le serveur applicatif ne voit plus l'adresse IP du visiteur, mais celle du proxy. Cela fausse les statistiques, les blocages géographiques et les journaux de sécurité. BunkerWeb prévoit un mécanisme pour corriger ce point.

1. Vérifier la méthode transmise par le proxy en amont : en-tête HTTP X-Forwarded-For ou protocole PROXY (v1 ou v2).
2. Activer la prise en charge via le paramètre USE_REAL_IP (ou USE_PROXY_PROTOCOL selon la méthode).
3. Définir REAL_IP_FROM avec la liste des réseaux IP de confiance de l'équilibreur de charge.
4. Renseigner REAL_IP_HEADER avec le nom de l'en-tête utilisé, par exemple X-Forwarded-For.
5. Redémarrer le service ou recréer les conteneurs Docker pour que les nouvelles variables d'environnement soient prises en compte.

Cette étape est souvent négligée, et c'est pourtant elle qui détermine si le filtrage par débit ou par géolocalisation fonctionnera correctement une fois BunkerWeb en place.

BunkerWeb convient-il à une TPE ou un artisan du Lot-et-Garonne ?

Prenons un cas fréquent en Lot-et-Garonne : un artisan installé du côté de Bon-Encontre héberge son site vitrine sur un NAS domestique, accessible depuis Internet pour que ses clients puissent consulter son catalogue. Il n'a ni le temps ni l'envie de devenir administrateur système, mais il veut fermer la porte aux robots qui scannent en permanence le web à la recherche de failles.

Un point mérite attention si le serveur tourne sur un NAS Synology : le système DSM réserve par défaut les ports 80 et 443, ceux normalement utilisés pour le web, ce qui impose de mettre en place des redirections réseau (NAT) spécifiques pour exposer BunkerWeb sans conflit, d'après des retours d'utilisateurs sur le forum spécialisé forum-nas.fr.

À noter aussi : l'interface d'administration Web UI est généralement accessible localement sur le port 7000, un détail à connaître avant de chercher pendant une heure pourquoi l'écran de connexion ne s'affiche pas à l'adresse habituelle.

Pour une structure sans équipe technique, l'auto-hébergement demande un minimum de rigueur : suivi des mises à jour, lecture des journaux, gestion des faux positifs. C'est un vrai projet, pas une case à cocher. Se faire accompagner pour l'installation et le suivi d'un tel outil, ou plus largement pour sécuriser l'exposition d'un site ou d'un NAS sur Internet, relève d'un accompagnement en infogérance plutôt que d'une manipulation isolée.

Un point de vigilance avant de se lancer

Une information technique mérite d'être signalée : l'intégration de BunkerWeb avec Docker Swarm est déclarée obsolète par l'éditeur et sera supprimée dans une version ultérieure, selon la documentation avancée officielle. Quiconque envisage une architecture reposant sur Swarm doit en tenir compte avant de bâtir un projet dessus.

Plus largement, la documentation d'un projet open source évolue vite : paramètres renommés, modes de déploiement recommandés qui changent, fonctionnalités dépréciées. Avant toute mise en production, la vérification de la version en vigueur sur la documentation officielle n'est pas une option.

BunkerWeb n'est pas un remplacement de sauvegarde, ni un antivirus, ni une solution qui dispense de mettre à jour l'application web elle-même : c'est une couche de filtrage supplémentaire, pas un bouclier universel. Un site mal maintenu derrière un WAF reste un site vulnérable, simplement un peu moins exposé aux attaques les plus grossières.

Questions fréquentes

Sources

• Documentation officielle BunkerWeb — Fonctionnalités
• Documentation officielle BunkerWeb — Intégrations
• Documentation officielle BunkerWeb — Fonctionnalités avancées
• Stéphane Robert — Sécuriser ses services avec BunkerWeb
• Forum des NAS — BunkerWeb reverse proxy WAF open source