Un load balancer bien configuré recoit le traffic et le redistribue sur les backend. Il ne fait cependant pas le tri entre un vrai visiteur et un robot qui scanne vos URLs à la recherche d'une faille.
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 fait 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 protège.
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.
Et surtout, c'est le 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 : 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 ce qui reste, le trafic légitime, atteint vos applications normalement.
Pour une PME, la logique est simple. Vous avez 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 solide mais 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.
Nous recommandons d'activer l'AppSec et le bannissement d'IP par étape. Beaucoup s'arrêtent à la réputation d'IP mais ce n'est qu'une partie des fonctionnalités 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.
Il convient de procéder par étapes : utilisez la préproduction dès que possible, surveillez les faux positifs au démarrage (un WAF trop strict peut bloquer des requêtes légitimes), et centralisez les logs dès le premier jour avec une alerte par mail ou webhook.
Rendre un frontal disponible, c'est la première moitié du travail. Le rendre capable de refuser des requêtes malveillantes, c'est la seconde. CrowdSec ajoute cette intelligence devant HAProxy, gratuitement, avec la force d'un réseau mondial derrière.
