CrowdSec devant HAProxy : le pare-feu applicatif qui apprend

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.

Le problème ou le contexte

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.

Ce qui change vraiment

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. Le tout avec des délais serrés pour ne pas pénaliser les visiteurs légitimes.

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 faiti 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.

Voici, le trajet d'une requête une fois CrowdSec posé devant HAProxy :

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.

Pourquoi les entreprises doivent s'y intéresser

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.

Exemple concret

Sur un déploiement en production, on a posé CrowdSec en frontal d'un cluster HAProxy existant. L'installation du moteur est simple

L'installation et la mise à jour du hub se fait rapidement.

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.

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

Nous pouvons dès à présent activer le composant bouncer de CrowdSec : c'est lui qui prend la décision de laisser passer le flux ou non.

systemctl enable --now crowdsec-spoa-bouncer

Nous pouvons vérifier que crowdsec-spoa et crowdsec sont bien démarrés avec la commande :

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

Dernière étape, la plus intéressante : activer le WAF (AppSec). On installe les collections AppSec, on configure le moteur (il écoute en local sur 127.0.0.1:7422), on recharge, et on suit l'activité en direct. Comme tout cela produit des logs précieux sur les détections, décisions de blocage, alertes WAF ils sont disponibles au chemin suivant

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

Nous pouvons faire remonter ces logs sur Graylog pour une meilleure vue et déclencher également des alertes en cas de détection.

Il est possible d'installer un certain nombre de collections selon les règles que l'on souhaite appliquer. Dans notre cas, nous avons installé et appliqué ces deux collections :

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

Puis éditez 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 et appliquée, redémarrez le service :

systemctl reload crowdsec

Vous pouvez suivre les blocages en direct avec la commande :

cscli metrics show appsec

Et détailler les règles issues des collections appliquées avec la commande :

cscli appsec-rules list | grep enabled

Ce qu'on recommande chez Logexia

Nous recommandons d'activer l'AppSec et le bannissement d'IP par étape. Beaucoup s'arrêtent à la réputation d'IP mais c'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. Les trois couches se complètent :

Il convient cependant de procéder par étapes : utilisez la préproduction dès que possible, et n'activez CrowdSec que sur certains backends, en vous appuyant sur ce type d'ACL par exemple :

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.

Centraliser les logs dès le premier jour, dès qu'un blocage survient paramétrez une alerte par mail ou webhook. Un blocage qu'on ne voit pas est un blocage qu'on ne peut ni comprendre ni corriger.

Conclusion

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