CrowdSec devant HAProxy : le pare-feu applicatif qui apprend

Par Damien Nebois
July 27, 2026
7 min

Un load balancer bien configuré reçoit le trafic et le redistribue vers les backends. Mais il ne fait pas le tri entre un vrai visiteur et un robot qui scanne vos URLs à la recherche d'une faille.

HAProxy répartit le trafic, mais ne filtre pas les menaces

Dès qu'un frontal web est exposé sur Internet, il est attaqué en continu, dès la première heure : scans de ports, bruteforce sur les formulaires de connexion, injections SQL, cross-site scripting, exploitation de CVE fraîchement publiées, le plus souvent par des bots automatisés.

HAProxy fait très bien son travail de répartiteur : il route, il équilibre, il assure la terminaison SSL. Mais il n'a aucune idée de ce qui est légitime ou malveillant dans une requête. On peut écrire quelques ACL de filtrage à la main, mais personne ne va maintenir des listes d'IP malveillantes ni une règle pour chaque nouvelle technique d'attaque. Il manque une couche de protection.

CrowdSec devant HAProxy : IPS comportemental et WAF

C'est le rôle de CrowdSec : un moteur de détection comportemental, open source, qui analyse le trafic, repère les comportements malveillants et applique une remédiation (blocage, page d'attente, captcha). Sa particularité : il est communautaire. Quand une IP se fait bannir pour comportement agressif chez des milliers d'utilisateurs, elle alimente une liste de réputation partagée.

Devant HAProxy, tout passe par le protocole SPOE (Stream Processing Offload Engine) : HAProxy sous-traite l'analyse de chaque requête à CrowdSec. Pour chaque connexion, il transmet l'IP source, la méthode, le chemin, les en-têtes et le corps de la requête, et CrowdSec répond en quasi temps réel — laisser passer, ou bloquer — avec des délais serrés pour ne pas pénaliser les visiteurs légitimes.

Point fort : le bouncer SPOA de HAProxy est le seul à embarquer l'AppSec, c'est-à-dire un véritable WAF (Web Application Firewall). CrowdSec ne se contente donc pas de bannir des IP : il inspecte le contenu applicatif pour bloquer les injections et fait du virtual patching, c'est-à-dire neutraliser l'exploitation d'une faille connue avant même que vous ayez patché l'application. On peut y ajouter le Core Rule Set de l'OWASP, le jeu de règles de référence du secteur.

Résultat concret : les scans et les IP déjà connues pour être hostiles sont écartés en amont, les tentatives d'exploitation web sont bloquées au niveau applicatif, et le trafic légitime atteint vos applications normalement.

Pourquoi une PME devrait s'y intéresser

La logique est simple. Vous avez d'abord rendu votre frontal disponible — c'est le sujet de notre article sur la haute disponibilité de HAProxy. L'étape suivante, c'est de le rendre sûr. Un frontal hautement disponible mais non protégé, c'est une porte blindée grande ouverte.

L'intérêt de CrowdSec, c'est qu'il apporte une protection de niveau grande entreprise (IPS comportemental, WAF, réputation mondiale) sans licence coûteuse ni appliance dédiée. Il tourne sur la machine qui héberge déjà HAProxy, se met à jour tout seul via son hub, et s'inscrit dans une démarche de sécurité continue plutôt que dans un audit ponctuel.

Déploiement : CrowdSec devant un cluster HAProxy

Sur un déploiement en production, nous avons posé CrowdSec en frontal d'un cluster HAProxy existant. L'installation du moteur et la mise à jour du hub sont rapides :

apt install crowdsec -y
curl -s https://install.crowdsec.net | sh
cscli hub update && cscli hub upgrade
systemctl restart crowdsec

On installe ensuite la collection HAProxy, un paquet qui regroupe des scénarios de détection adaptés :

cscli collections install crowdsecurity/haproxy

Puis on déclare l'agent SPOE côté HAProxy (fichier /etc/haproxy/crowdsec.cfg), qui définit les messages envoyés à CrowdSec et pointe vers le backend crowdsec-spoa. Ce backend se déclare ainsi dans HAProxy :

backend crowdsec-spoa
 mode tcp
 server crowdsec-spoa 127.0.0.1:9000 check

On active alors le bouncer, le composant qui applique la décision — laisser passer le flux ou le bloquer :

systemctl enable --now crowdsec-spoa-bouncer

On vérifie que crowdsec-spoa et crowdsec écoutent bien sur leurs ports :

ss -lntp | grep -E '9000|7422'

Dernière étape, la plus intéressante : activer le WAF (AppSec). On installe les collections AppSec, puis on configure le moteur (il écoute en local sur 127.0.0.1:7422) :

cscli collections install crowdsecurity/appsec-generic-rules
cscli collections install crowdsecurity/appsec-virtual-patching

On édite ensuite le fichier /etc/crowdsec/acquis.d/appsec.yaml :

appsec_configs:
 - crowdsecurity/appsec-generic-rules
 - crowdsecurity/appsec-virtual-patching
labels:
 type: appsec
listen_addr: 127.0.0.1:7422

Après chaque collection installée, on recharge le service :

systemctl reload crowdsec

On suit l'activité du WAF en direct :

cscli metrics show appsec

Et on détaille les règles actives issues des collections appliquées :

cscli appsec-rules list | grep enabled

Les journaux (détections, décisions de blocage, alertes WAF) sont disponibles ici :

/var/log/crowdsec-spoa/crowdsec-spoa-bouncer.log

Nous les faisons remonter dans Graylog pour une vue centralisée et pour déclencher des alertes dès qu'une détection survient.

Nos recommandations pour un déploiement sans faux positifs

Activez l'AppSec et le bannissement d'IP par étapes. Beaucoup s'arrêtent à la réputation d'IP, mais ce n'est qu'une partie de CrowdSec : le WAF applicatif et le virtual patching sont ce qui protège réellement contre l'exploitation d'une CVE le jour où elle sort.

Procédez progressivement : utilisez la préproduction dès que possible et n'activez CrowdSec que sur certains backends, à l'aide d'une ACL de ce type :

http-request send-spoe-group crowdsec crowdsec-http-no-body if ACL_votresite
http-request deny status 403 if ACL_votresite { var(txn.crowdsec.remediation) -m str ban }
use_backend back_votresite if ACL_votresite

Surveillez les faux positifs au démarrage : un WAF trop strict peut bloquer des requêtes légitimes. On démarre en observation, puis on durcit progressivement en ajustant les règles activées plutôt que de tout bloquer d'emblée. Enfin, centralisez les logs dès le premier jour : un blocage qu'on ne voit pas est un blocage qu'on ne peut ni comprendre ni corriger.

Conclusion : un frontal disponible ET protégé

Rendre un frontal disponible, c'est la première moitié du travail. Le rendre capable de refuser les requêtes malveillantes, c'est la seconde. CrowdSec ajoute cette intelligence devant HAProxy, gratuitement, avec la force d'un réseau mondial derrière.

CrowdSec, HAProxy, bouncer, bots, sécurité