Pendant des années, Fail2ban a été le réflexe de tout administrateur Linux pour bannir les adresses IP trop insistantes. Efficace mais solitaire, il ne protège que la machine sur laquelle il tourne et ignore tout de ce que subissent les autres serveurs du monde. CrowdSec part d’une idée simple : si chaque serveur attaqué partage l’adresse de son agresseur, tous les autres peuvent la bloquer avant même d’être visés. Développé par une start-up française et publié sous licence MIT, CrowdSec s’est imposé comme l’une des briques de sécurité open source les plus déployées sur les serveurs exposés à Internet.
Voici un tour d’horizon complet de cet IPS collaboratif, de son architecture à sa mise en production.
Qu’est-ce que CrowdSec ?
CrowdSec est une solution de sécurité open source et participative, écrite en Go, qui analyse les journaux de vos services pour détecter les comportements malveillants (force brute SSH, scans de ports, scans web, tentatives d’exploitation…) puis déclenche une remédiation : blocage au pare-feu, réponse HTTP 403, captcha, etc.
Sa particularité tient en une devise : « Detect Here, Remedy There ». La détection et le blocage sont découplés : on peut analyser les logs de plusieurs serveurs à un seul endroit et appliquer les décisions à différents niveaux de l’infrastructure (pare-feu, reverse proxy, application, CDN).
Une architecture modulaire
CrowdSec repose sur plusieurs composants qui communiquent entre eux :
Le Security Engine (Log Processor) : il lit les sources de données (fichiers de logs, journald, syslog, sorties de conteneurs Docker), les normalise grâce à des parsers, puis les confronte à des scénarios décrivant des comportements d’attaque.
La Local API (LAPI) : elle centralise les alertes et les transforme en décisions (bannir telle IP pendant telle durée) selon les profils définis dans
/etc/crowdsec/profiles.yaml.Les Remediation Components (bouncers) : ils interrogent la LAPI et appliquent les décisions là où c’est pertinent : iptables/nftables, Nginx, Traefik, HAProxy, Apache, PHP, WordPress, Cloudflare…
La Central API (CAPI) : elle reçoit les signaux de toute la communauté et redistribue la blocklist communautaire.
Point essentiel à retenir : sans bouncer, CrowdSec détecte mais ne bloque rien. Le moteur seul agit comme un IDS ; c’est l’ajout d’un composant de remédiation qui en fait un véritable IPS.
La force du collectif : la blocklist communautaire
Lorsqu’un scénario se déclenche, le moteur envoie à la CAPI un signal volontairement minimal : l’adresse IP, le nom du scénario et l’horodatage. Vos lignes de logs ne quittent jamais votre serveur. Côté CrowdSec, un moteur de consensus croise les signaux de milliers d’installations, écarte les faux positifs et les tentatives d’empoisonnement, puis publie une liste d’adresses réellement malveillantes que chaque instance récupère automatiquement.
Le partage est un échange : il peut être désactivé, mais vous perdez alors l’accès à la blocklist communautaire, qui constitue le principal atout de l’outil.
Installation sur Debian / Ubuntu
CrowdSec fournit des paquets officiels pour Debian, Ubuntu, RHEL, Fedora, Alpine, FreeBSD, mais aussi pour Windows, Docker, Kubernetes ou OPNsense. Sur une distribution Debian ou Ubuntu, l’installation se fait en ajoutant le dépôt officiel puis en installant le moteur et un bouncer pare-feu :
# Ajout du dépôt officiel CrowdSec
curl -s https://install.crowdsec.net | sudo sh
# Installation du Security Engine
sudo apt install crowdsec
# Installation du bouncer pare-feu (iptables ou nftables)
sudo apt install crowdsec-firewall-bouncer-iptables
# sudo apt install crowdsec-firewall-bouncer-nftables
# Vérification
sudo systemctl status crowdsec
sudo cscli bouncers listÀ l’installation, CrowdSec détecte automatiquement les services présents (SSH, Nginx, Apache…) et installe les collections correspondantes. Le bouncer installé par paquet s’enregistre lui-même auprès de la LAPI ; pour un bouncer installé manuellement, il faut générer une clé d’API avec cscli bouncers add.
Le Hub : des règles de détection déclaratives
La logique de détection n’est pas figée dans le binaire : elle vit sur le Hub CrowdSec sous forme de petits fichiers YAML (parsers, scénarios, collections) eux aussi sous licence MIT. Ils se gèrent avec cscli comme des paquets, ce qui permet de mettre à jour la détection sans attendre une nouvelle version du moteur.
AppSec : un WAF intégré
Depuis la version 1.6, CrowdSec embarque un composant AppSec qui transforme l’installation en véritable pare-feu applicatif (WAF). Il inspecte les requêtes HTTP transmises par un bouncer compatible (Nginx, OpenResty, Traefik, WordPress…) et applique des règles de virtual patching ciblant les vulnérabilités activement exploitées. Il est également possible d’y ajouter l’OWASP Core Rule Set grâce au moteur Coraza intégré.
Les commandes cscli du quotidien
L’outil en ligne de commande cscli est le point d’entrée pour piloter CrowdSec :
# Mettre à jour les règles du Hub
sudo cscli hub update && sudo cscli hub upgrade
# Installer une collection (ex. Nginx)
sudo cscli collections install crowdsecurity/nginx
# Lister les alertes et inspecter une alerte
sudo cscli alerts list
sudo cscli alerts inspect <ID>
# Voir et gérer les décisions
sudo cscli decisions list
sudo cscli decisions add --ip 203.0.113.10 --duration 4h --reason "test manuel"
sudo cscli decisions delete --ip 203.0.113.10
# Statistiques : lignes analysées, scénarios, blocages
sudo cscli metrics
# Rattacher l'instance à la Console web
sudo cscli console enroll <CLE_D_ENROLEMENT>CrowdSec ou Fail2ban ?
Approche : Fail2ban réagit uniquement aux attaques vues localement ; CrowdSec bloque aussi, de manière préventive, les adresses signalées par la communauté.
Architecture : Fail2ban détecte et bloque sur la même machine ; CrowdSec sépare détection et remédiation, ce qui permet de centraliser l’analyse de plusieurs serveurs et de bloquer au niveau le plus pertinent.
Remédiation : au-delà du simple bannissement, CrowdSec peut répondre par un captcha, une page 403 ou un blocage au niveau du CDN, avec des durées différenciées par scénario.
Performances : le moteur écrit en Go traite des volumes de logs importants avec une empreinte mémoire réduite.
Couverture applicative : avec AppSec, CrowdSec couvre aussi la couche WAF, ce que Fail2ban ne propose pas.
La Console et le modèle économique
La Console (app.crowdsec.net) est un tableau de bord SaaS qui agrège les alertes et décisions de toutes vos instances, avec un niveau gratuit couvrant un petit nombre de machines. Le moteur, les bouncers, cscli et le contenu du Hub restent entièrement libres ; CrowdSec monétise principalement des blocklists premium, des données de Threat Intelligence (CTI) et des fonctionnalités d’équipe pour les entreprises.
Bonnes pratiques de déploiement
Toujours installer au moins un bouncer, sans quoi aucune attaque n’est bloquée.
Déclarer vos adresses d’administration et de supervision dans une allowlist pour éviter de vous bannir vous-même.
Adapter les profils : un captcha pour les scanners web, un bannissement long pour la force brute SSH.
Surveiller régulièrement
cscli metricspour vérifier que les logs sont bien lus et parsés.Garder le moteur et le Hub à jour : les nouvelles versions corrigent régulièrement des failles et ajoutent des règles de virtual patching.
Dans une infrastructure multi-serveurs, centraliser les décisions sur une LAPI unique partagée par tous les bouncers.
Conclusion
CrowdSec a profondément renouvelé la protection des serveurs exposés : là où les outils classiques se défendent seuls, il fait de chaque installation un capteur au service de toutes les autres. Léger, modulaire, extensible grâce à son Hub et désormais doté d’un WAF, il s’intègre aussi bien sur un simple VPS que dans une infrastructure Kubernetes. Pour un administrateur système comme pour un RSSI, c’est aujourd’hui l’une des premières briques à déployer pour réduire drastiquement le bruit des attaques automatisées.
