Fail2ban scrute vos logs avec des expressions régulières et insère des règles DROP dans iptables lorsqu'un seuil est franchi. C'est simple, fiable, et parfaitement adapté aux infrastructures mono-serveur. Mais en production moderne, quatre limites majeures sautent aux yeux :
- Réactivité tardive : Fail2ban n'agit que sur ce que vos logs ont déjà vu. Une IP utilisée pour la première fois sur votre serveur passe systématiquement la première barrière (et c'est souvent là que le mal est fait).
- Performance dégradée à grande échelle : chaque IP bannie devient une règle iptables individuelle. Au-delà de 10 000 entrées, les performances réseau s'effondrent.
- Détection à plat : les filtres regex peinent à exprimer des comportements multi-étapes (« 5 échecs SSH suivis d'un scan de ports », par exemple).
- Isolement total : chaque serveur défend seul, sans bénéficier de l'expérience des autres. C'est un peu comme combattre une armée sans radio.
CrowdSec, de son côté, répond à toutes ces limites :
- Un moteur écrit en Go, multi-threadé, jusqu'à 10 fois plus rapide que Python sur le parsing de logs volumineux.
- L'usage d'IP sets nftables qui gèrent des millions d'entrées sans broncher.
- Des scénarios YAML avec leaky buckets capables d'exprimer des séquences temporelles complexes.
- Une API centrale qui partage les indicateurs de compromission entre tous les utilisateurs : votre serveur bénéficie d'une blocklist enrichie de plusieurs millions d'IP malveillantes avant même la première attaque.
Architecture de CrowdSec : agent, LAPI, bouncers
Comprendre l'architecture est franchement essentiel pour exploiter pleinement l'outil. Contrairement à Fail2ban qui mélange détection et application dans le même processus, CrowdSec sépare strictement les rôles. Et c'est tout sauf cosmétique.
Les composants principaux
- Security Engine (le démon
crowdsec) : lit vos logs, les normalise via les parseurs, exécute les scénarios de détection, et produit des décisions (ban, captcha, throttle).
- Local API (LAPI) : écoute par défaut sur
127.0.0.1:8080 et stocke les décisions. C'est le point de vérité local.
- Central API (CAPI) : service SaaS gratuit qui collecte les signaux anonymisés et redistribue la community blocklist.
- Bouncers : agents légers qui interrogent la LAPI et appliquent les décisions là où vous en avez besoin (firewall, Nginx, Traefik, Cloudflare, AWS WAF…).
- Hub : dépôt central de parseurs, scénarios et collections maintenus par la communauté.
Le flux de données
- Acquisitions : lecture des sources (fichiers, journald, syslog, Docker, Kubernetes, Kafka).
- Parsers : conversion des lignes brutes en événements structurés.
- Scénarios : détection comportementale via leaky buckets temporels.
- Décisions : verdict (ban, captcha) avec durée et portée (IP, range, pays).
- Bouncers : application effective à la couche choisie.
Prérequis et environnement de test
Pour reproduire ce guide, vous aurez besoin de :
- Un serveur Linux récent : Ubuntu 24.04 LTS, Debian 12+, AlmaLinux 9, ou Rocky Linux 9.
- 2 Go de RAM minimum (1 Go reste acceptable en lab, mais c'est franchement inconfortable en production).
nftables activé (Fail2ban peut cohabiter le temps de la migration, pas de panique).- Accès
root ou sudo.
- Un accès sortant HTTPS vers
api.crowdsec.net pour la blocklist communautaire.
Vérifiez la version du noyau et du système avant de vous lancer :
uname -r
cat /etc/os-release
nft --version
Installation de CrowdSec sur Linux en 2026
Ajout du dépôt officiel
Le dépôt officiel est désormais signé par une clé GPG renouvelée en 2026 (la précédente expirait en mars, pour info). Utilisez le script d'installation packagecloud :
curl -s https://install.crowdsec.net | sudo bash
sudo apt update
sudo apt install -y crowdsec
Sur AlmaLinux/Rocky, c'est presque pareil :
curl -s https://install.crowdsec.net | sudo bash
sudo dnf install -y crowdsec
Bonne nouvelle : l'installeur détecte automatiquement les services présents (SSH, Nginx, Apache, MariaDB, Postfix) et propose les collections correspondantes. Acceptez les suggestions raisonnables — vous pourrez toujours affiner par la suite.
Vérification du démon et de la LAPI
sudo systemctl status crowdsec
sudo cscli lapi status
sudo cscli capi status
Vous devez obtenir You can successfully interact with Local API (LAPI) et You can successfully interact with Central API (CAPI). Si la CAPI échoue (ce qui arrive plus souvent qu'on ne croit), vérifiez votre pare-feu sortant et la résolution DNS. C'est presque toujours l'un des deux.
Installation d'un bouncer firewall
Sans bouncer, CrowdSec détecte mais ne bloque rien — autant dire qu'il ronronne dans le vide. Le crowdsec-firewall-bouncer est le compagnon naturel pour un serveur Linux :
sudo apt install -y crowdsec-firewall-bouncer-nftables
sudo systemctl status crowdsec-firewall-bouncer
Le bouncer crée automatiquement deux sets nftables (crowdsec-blacklists et crowdsec6-blacklists) et insère une chaîne crowdsec appelée en tête de input. Vérifiez :
sudo nft list table inet crowdsec
sudo nft list set inet crowdsec crowdsec-blacklists | head -20
Si vous préférez iptables (legacy, mais ça arrive), installez crowdsec-firewall-bouncer-iptables à la place. Recommandation 2026 : privilégiez systématiquement nftables. C'est désormais l'API officielle du noyau Linux et les sets apportent un gain de performance qu'on ne discute plus.
Configurer les collections et le hub
Les collections regroupent parseurs et scénarios par service. Listez ce qui est installé :
sudo cscli collections list
sudo cscli hub update
sudo cscli hub upgrade
Pour une stack web typique en 2026, voici ce que j'installe systématiquement :
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/sshd
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/http-cve
sudo cscli collections install crowdsecurity/base-http-scenarios
sudo cscli collections install crowdsecurity/iptables
sudo systemctl reload crowdsec
La collection http-cve est, à mon avis, la plus précieuse de toutes : elle détecte les tentatives d'exploitation de CVE récentes (Log4Shell, GoAnywhere, Ivanti, MOVEit, et les dernières vagues 2026 sur les WAF et reverse proxies). On en récupère plusieurs centaines par jour sur un serveur exposé.
Vérifier l'acquisition des logs
CrowdSec génère automatiquement un fichier acquis.yaml à partir des services détectés. Inspectez-le :
sudo cat /etc/crowdsec/acquis.yaml
Exemple typique pour SSH via journald :
source: journalctl
journalctl_filter:
- "_SYSTEMD_UNIT=ssh.service"
labels:
type: syslog
Si une source manque (par exemple un Nginx en conteneur Docker, classique), ajoutez un bloc supplémentaire et rechargez le démon. Rien de sorcier.
Activer la blocklist communautaire
L'enregistrement à la CAPI est gratuit et, je le dis sans détour, indispensable pour profiter de l'effet réseau. Il s'effectue en principe à l'installation, mais peut être réinitialisé :
sudo cscli capi register
sudo systemctl reload crowdsec
sudo cscli decisions list --origin=CAPI | head -20
En 2026, la blocklist communautaire contient typiquement entre 4 et 8 millions d'IP actives, mises à jour toutes les 2 heures. Vous pouvez aussi souscrire à des blocklists premium via la console gratuite :
sudo cscli console enroll <votre-token-console>
Les blocklists gratuites les plus utiles selon moi : Firehol cybercrime tracker, CrowdSec Pro free tier, et SSH bruteforce IPs.
Sécuriser et durcir votre instance CrowdSec
Allowlister vos propres IP
L'erreur classique (et je suis tombé dedans, comme tout le monde) : se faire bannir par sa propre instance lors d'un test de charge. Depuis la 1.6, CrowdSec dispose d'une commande native bien pratique :
sudo cscli allowlists create maison --description "IPs de l'infrastructure interne"
sudo cscli allowlists add maison 203.0.113.10
sudo cscli allowlists add maison 198.51.100.0/24
Pour une whitelist plus fine basée sur un scénario, créez un parseur de type s02-enrich :
name: maison/whitelist-monitoring
description: "Exclure les sondes Prometheus"
whitelist:
reason: "Prometheus interne"
ip:
- "10.10.0.5"
- "10.10.0.6"
cidr:
- "10.20.0.0/16"
Placez ce fichier dans /etc/crowdsec/parsers/s02-enrich/ puis rechargez.
Restreindre la LAPI
La LAPI écoute sur 127.0.0.1:8080 par défaut. Si vous l'exposez à des bouncers distants, basculez en TLS mutuel — pas de discussion possible :
sudo cscli lapi context show
sudo cscli machines list
Générez une CA interne, signez les certificats des bouncers, et configurez tls dans /etc/crowdsec/config.yaml. N'exposez jamais la LAPI sur Internet sans TLS et authentification mutuelle. Jamais. C'est la garantie de transformer votre solution de défense en porte d'entrée.
Hardening du démon
CrowdSec dispose d'une unité systemd qui peut être renforcée avec une override. C'est rapide, efficace, et ça change la donne en cas de RCE théorique sur l'agent :
sudo systemctl edit crowdsec
Ajoutez :
[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/crowdsec /var/log/crowdsec
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
SystemCallArchitectures=native
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
LockPersonality=true
MemoryDenyWriteExecute=true
Rechargez puis vérifiez le score :
sudo systemctl daemon-reload
sudo systemctl restart crowdsec
systemd-analyze security crowdsec
Écrire un scénario YAML personnalisé
Les scénarios, c'est vraiment l'élément différenciant de CrowdSec. Ils s'appuient sur le pattern du leaky bucket : chaque événement qui matche le scénario remplit un seau qui fuit dans le temps. Quand le seau déborde, une décision est créée. Simple, mais redoutablement puissant.
Exemple concret : détecter un abus d'API JSON sur un endpoint /api/v1/login (5 erreurs 401 en 30 secondes depuis la même IP) :
type: leaky
name: maison/api-login-bruteforce
description: "Bruteforce sur l'API de login"
filter: "evt.Meta.log_type == 'http_access-log' && evt.Parsed.request startsWith '/api/v1/login' && evt.Meta.http_status == '401'"
leakspeed: "10s"
capacity: 5
groupby: evt.Meta.source_ip
blackhole: 5m
labels:
service: api
type: bruteforce
remediation: true
Placez le fichier dans /etc/crowdsec/scenarios/maison-api-login.yaml, validez la syntaxe puis rechargez :
sudo cscli scenarios inspect maison/api-login-bruteforce
sudo systemctl reload crowdsec
Petit conseil : pour tester sans bannir, ajoutez simulated: true au scénario. Les décisions seront listées avec l'origine simulation et n'auront aucun effet réel. Indispensable avant tout passage en prod.
Intégrer un bouncer Nginx pour les captcha
Au-delà du firewall, vous pouvez présenter un captcha aux IP douteuses sans les bannir totalement. Ça améliore considérablement l'UX face aux faux positifs (et croyez-moi, il y en a toujours) :
sudo apt install -y crowdsec-nginx-bouncer
Le script de post-install demande l'URL de la LAPI et configure automatiquement un fichier /etc/nginx/conf.d/crowdsec_nginx.conf. Activez le module hCaptcha ou Turnstile dans /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf :
CAPTCHA_PROVIDER: turnstile
SITE_KEY: 0xAAAAAAAAA
SECRET_KEY: 0xBBBBBBBBB
Rechargez Nginx et déclenchez un captcha sur une IP de test pour vérifier :
sudo cscli decisions add --ip 203.0.113.55 --type captcha --duration 1h
curl -I -H "X-Forwarded-For: 203.0.113.55" https://votre-site.fr/
Migrer progressivement depuis Fail2ban
Une migration en big bang ? Très risqué. Voici plutôt la stratégie en quatre temps que je recommande systématiquement en production :
- Phase 1 — Cohabitation passive (1 semaine) : installez CrowdSec en mode
simulated: true sur l'ensemble des scénarios. Fail2ban reste seul à bannir. Comparez quotidiennement les listes via cscli decisions list et fail2ban-client status sshd.
- Phase 2 — Cohabitation active (1 à 2 semaines) : retirez
simulated sur les scénarios SSH et HTTP basiques. Les deux outils bannissent en parallèle. Surveillez la concordance et chassez les faux positifs.
- Phase 3 — Désactivation graduelle de Fail2ban : désactivez les jails Fail2ban un à un, en commençant par les redondants (sshd, nginx-http-auth), tout en gardant un œil sur le taux de bannissement CrowdSec.
- Phase 4 — Décommissionnement :
sudo systemctl disable --now fail2ban et purgez les chaînes iptables résiduelles.
Si vous avez des jails Fail2ban très personnalisés, traduisez-les en scénarios CrowdSec. La structure regex + maxretry + findtime de Fail2ban se traduit naturellement en parser + leakspeed + capacity de CrowdSec. C'est une transposition presque mécanique une fois qu'on a le coup de main.
Supervision, métriques et console
CrowdSec expose des métriques Prometheus sur 127.0.0.1:6060/metrics :
curl -s http://127.0.0.1:6060/metrics | grep cs_
Les indicateurs clés à surveiller :
cs_bucket_overflowed_total — nombre de scénarios déclenchés par type.cs_parser_hits_total — efficacité des parseurs (un parseur avec 0 hit doit clairement être désinstallé).cs_active_decisions — taille de la blocklist active.cs_lapi_request_duration_seconds — latence côté LAPI.
Pour une visualisation rapide, la CrowdSec Console gratuite offre dashboards, alertes et corrélation multi-instances. L'enrôlement se fait en une commande et les données restent anonymisées côté serveur. Honnêtement, c'est l'un des meilleurs rapports valeur/effort que je connaisse dans l'écosystème sécu Linux.
Logs et investigation
sudo journalctl -u crowdsec -f
sudo tail -f /var/log/crowdsec.log
sudo cscli alerts list --since 1h
sudo cscli alerts inspect <ID>
L'inspection d'une alerte révèle les événements bruts qui ont rempli le seau, le scénario déclenché, et la décision produite. C'est un outil d'investigation forensique précieux quand on cherche à comprendre pourquoi une IP a été bannie (et expliquer la chose à un client mécontent).
Erreurs fréquentes et dépannage
- « No decisions for IP » alors qu'une attaque est en cours : vérifiez que l'acquisition lit bien la bonne source (
cscli metrics doit montrer des lignes lues), et que la collection correspondante est installée.
- Le bouncer firewall ne bloque rien : vérifiez la présence du set nftables (
nft list set inet crowdsec crowdsec-blacklists) et que la chaîne crowdsec est bien insérée avant les règles permissives. Classique.
- Faux positifs sur les CDN/load balancers : configurez
real_ip_header côté Nginx et ajoutez les ranges Cloudflare/Fastly dans une allowlist. Sinon, vous bannirez votre propre CDN — et le téléphone va sonner.
- La CAPI ne synchronise plus : vérifiez l'horloge système (
timedatectl) — une dérive supérieure à 5 minutes invalide les signatures. Étrange, mais fréquent sur les VMs longtemps suspendues.
Aller plus loin : architecture distribuée
Dans un environnement multi-serveur, déployez un agent CrowdSec sur chaque machine, mais une seule LAPI centrale. Les agents distants s'enregistrent via cscli machines add et envoient leurs décisions à la LAPI maître. Les bouncers, eux, n'interrogent que la LAPI maître. Cette topologie « hub-and-spoke » mutualise la blocklist en interne tout en réduisant la surface d'API exposée.
Pour Kubernetes, le CrowdSec Helm chart déploie un DaemonSet pour la collecte et un Deployment pour la LAPI, avec autoscaling. Combiné au bouncer Ingress-NGINX, vous obtenez une protection collaborative à l'échelle du cluster. C'est franchement bluffant à voir tourner.
FAQ : CrowdSec en 2026
CrowdSec remplace-t-il vraiment Fail2ban ?
Fonctionnellement, oui : CrowdSec couvre l'ensemble des cas d'usage Fail2ban (SSH, web, mail) tout en ajoutant la blocklist collaborative et la détection comportementale. Beaucoup d'administrateurs choisissent toutefois de garder Fail2ban en complément pour des règles ultra-spécifiques peu coûteuses, et CrowdSec pour la défense globale. Les deux peuvent cohabiter sans conflit — j'ai personnellement vu cette config tourner pendant des mois sans souci.
CrowdSec est-il gratuit ?
Le moteur, les bouncers, la blocklist communautaire et la console gratuite (jusqu'à 3 instances) sont 100 % libres et gratuits sous licence MIT. Les blocklists premium et la console multi-instance entreprise sont payantes, mais franchement inutiles pour la plupart des projets personnels et PME.
Mes données de logs sont-elles envoyées à CrowdSec ?
Non. Seuls les signaux anonymisés (IP source, scénario déclenché, horodatage) sont transmis à la CAPI lorsque la fonctionnalité est activée. Aucune ligne de log, aucun payload, aucun en-tête HTTP ne quitte votre serveur. Vous pouvez aussi désactiver totalement la CAPI si vous y tenez vraiment.
Quelle est la consommation mémoire et CPU de CrowdSec ?
En conditions courantes, comptez 80 à 250 Mo de RAM et moins de 3 % CPU sur un serveur typique. Lors de pics d'attaque ou sur un proxy à fort débit, ça peut grimper à 500 Mo. Prévoyez 2 Go de RAM disponibles pour une marge confortable.
CrowdSec fonctionne-t-il en IPv6 ?
Oui, depuis la 1.4 et de manière mature en 2026. Le bouncer firewall crée automatiquement un set crowdsec6-blacklists et applique les bans IPv6 en parallèle. Vérifiez simplement que vos parseurs Nginx/SSH capturent bien les adresses sources IPv6 (un piège classique avec certains formats de logs custom).
Conclusion
CrowdSec représente en 2026 la nouvelle référence pour la protection contre les attaques automatisées sur Linux. Sa combinaison unique d'intelligence collaborative, de détection comportementale et d'architecture découplée surclasse Fail2ban sur tous les terrains qui comptent — tout en restant abordable techniquement. Et la migration peut se faire sans rupture grâce à une cohabitation contrôlée.
Ma recommandation pratique, après plusieurs déploiements : si vous administrez du Linux exposé sur Internet (quelle que soit la taille de l'infrastructure), déployez CrowdSec dès aujourd'hui en mode simulé sur un serveur de pré-production, étudiez vos métriques pendant deux semaines, puis basculez en production. Le gain en visibilité et en proactivité est immédiat — et durable.
