Cybersécurité

CrowdSec 2026 : guide complet (alternative Fail2ban moderne avec partage de signatures collaboratif)

5 دقائق للقراءة

Fail2ban a 18 ans en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer), et il montre son âge : configuration en regex, pas de partage entre serveurs, blocage uniquement local. CrowdSec est l’alternative moderne open source qui s’est imposée chez les sysadmins francophones d’Afrique de l’Ouest et du Maghreb : détection comportementale, blocklist communautaire mise à jour en temps réel par 100 000+ machines mondiales (4 millions d’IP malicieuses connues), bouncers pour Caddy, Nginx, Cloudflare, AWS WAF. Auto-hébergé gratuit, ou plan Premium à 7 USD/mois pour les blocklists premium. Réduit le bruit dans vos logs de 90% en quelques jours.

Sommaire

Pourquoi CrowdSec domine en 2026

Cinq raisons concrètes expliquent l’adoption massive.

Détection comportementale. Fail2ban regex sur les logs (« 5 échecs SSH = ban »). CrowdSec analyse les comportements (« cette IP scan le port 22, le 80, le 443 puis tente login admin = ban »). Précision largement supérieure, faux positifs négligeables.

Blocklist communautaire. Chaque alerte locale est partagée (anonymisée) avec la communauté CrowdSec. Le serveur central agrège, filtre, et redistribue une blocklist consensus mise à jour toutes les heures. Vos serveurs bénéficient des attaques détectées sur 100 000+ autres machines. Réduction des attaques nouvelles de 70-90% selon retours terrain.

Bouncers multi-couches. CrowdSec détecte. Les bouncers bloquent à différents niveaux : Caddy/Nginx (HTTP), iptables (TCP), Cloudflare (Edge), AWS WAF (Cloud). Vous choisissez où bloquer selon votre stack.

Performance. Écrit en Go, agent CrowdSec consomme 30-80 Mo RAM. Bouncer iptables mise à jour en temps réel sans restart. Sur Hetzner CX23 (4 Go RAM), aucun impact perceptible.

Multi-stack. Parsers prêts pour : SSH, Caddy, Nginx, Apache, Postfix, Dovecot, MySQL, MongoDB, WordPress, Vaultwarden, Forgejo, Coolify. La majorité de votre stack auto-hébergée est couverte out-of-the-box.

Concepts fondamentaux

Architecture en trois composants

  1. Agent CrowdSec : analyse les logs, applique scénarios de détection, génère des alertes. Écrit en Go.
  2. LAPI (Local API) : reçoit les alertes, gère les décisions (ban, captcha), partage avec CAPI (Central API).
  3. Bouncers : composants externes qui appliquent les décisions. Caddy bouncer, Nginx bouncer, iptables bouncer, Cloudflare bouncer, etc.

Hub : parsers, scenarios, postoverflows

Le Hub CrowdSec est un repository GitHub avec 200+ collections de :

  • Parsers : transforment les logs bruts en événements structurés.
  • Scenarios : règles de détection comportementale.
  • Postoverflows : enrichissement (whitelist IPs, scoring).
  • Collections : packs prêts à l’emploi (collection « linux », « caddy », « mysql »).

Decisions : ban, captcha, throttle

Quand un scenario match, l’agent crée une decision : ban (blocage complet), captcha (challenge utilisateur), throttle (rate limiting). Durée configurable (1 heure, 1 jour, 1 semaine, 4 mois).

CAPI : Central API et blocklists

L’agent envoie ses alertes (anonymisées) à la CAPI CrowdSec. CAPI agrège et calcule un consensus. Les blocklists communautaires sont téléchargées par votre agent toutes les heures. Vos serveurs bénéficient des attaques détectées partout.

Console CrowdSec (Cloud)

Dashboard web gratuit (jusqu’à 3 machines) : visualiser alertes en temps réel, top attaquants, géolocation, scenarios déclenchés. URL app.crowdsec.net. Optionnel, n’envoie pas vos logs.

Vue d’ensemble pratique

1. Installation agent + LAPI sur chaque VPS

Une commande sur Debian/Ubuntu installe agent + LAPI + collections par défaut. Voir Déployer CrowdSec sur VPS.

2. Bouncers pour votre stack

Selon votre reverse proxy : Configurer bouncers Caddy et Nginx.

3. Protéger Vaultwarden, Forgejo, WordPress

Collections dédiées à activer. Voir Protéger Vaultwarden, Forgejo, WordPress avec CrowdSec.

4. Multi-VPS centralisé

Pour 5+ VPS, configurer un LAPI central + agents distribués. Voir CrowdSec multi-serveurs avec LAPI central.

Tutoriels du cluster CrowdSec

Cas d’usage

VPS unique avec WordPress

Blog WordPress sur Hetzner CX23 à Casablanca : CrowdSec analyse logs Caddy, NGINX, et auth.log. Détecte 200-500 tentatives SSH par jour, 50-200 brute-force WordPress. Blocklist communautaire bloque 90% en amont. Logs deviennent lisibles.

Cluster Coolify + 10 apps

VPS Hetzner CCX23 avec Coolify, Vaultwarden, Forgejo, Outline, Plausible, Immich. CrowdSec couvre toute la stack. Aucune attaque ne passe inaperçue.

Mail server Mailcow

Mailcow exposé attire les bots. CrowdSec collection postfix+dovecot+rspamd : détecte spam, brute-force IMAP, smurf. Réduit la charge serveur de 40-60%.

API publique fintech

API Wave-like ouverte au public : CrowdSec rate-limit + détection scrape + signature attack patterns. Protection sans WAF cloud coûteux.

Multi-VPS ESN

ESN à Tunis avec 8 VPS clients : LAPI central + agents distribués. Vue unifiée sur Console. Décisions partagées entre serveurs (IP banni sur VPS A → banni partout).

Réalités opérationnelles à Dakar et alentours

Quatre adaptations spécifiques.

Coût. CrowdSec gratuit en self-hosted. 0 USD/mois vs Cloudflare Pro WAF (240 USD/an), Sucuri (199 USD/an/site), AWS Shield Advanced (3 000 USD/mois). Économies massives pour PME africaines.

Exclusion d’IPs locales. Whitelist explicite des IPs bureau, IPs partenaires, IPs critiques pour éviter blocages accidentels. Wave/Orange Money payment APIs viennent d’IPs spécifiques à whitelister.

Détection trafic suspect géo. Scenarios géo pour bloquer accès admin depuis pays à risque (Russie, Iran, Corée du Nord). Garder accès depuis Sénégal, Côte d’Ivoire, Maroc, Tunisie naturellement.

Conformité. Logs enrichis CrowdSec aident audit ARTCI, CDP, NESA. Décisions documentées avec timestamp + scenario + IP origine.

Erreurs fréquentes

Erreur Cause Solution
Faux positifs admins bloqués Pas de whitelist Whitelist par IP fixe ou range bureau
Bouncer bloque trop tard Cache iptables non rafraîchi Vérifier interval bouncer (60s par défaut)
Logs non parsés Format date différent Customiser parser collection
Communautaire pas téléchargée Pas inscrit cscli capi register
Multi-VPS désynchronisé LAPI central pas joignable Tunnel Tailscale entre VPS
Cloudflare bouncer 429 API rate limit Plan Pro Cloudflare ou batch updates

FAQ

CrowdSec remplace-t-il Fail2ban ? Oui complètement. Migration recommandée : désactiver Fail2ban, installer CrowdSec.

Compatible WAF Cloudflare ? Bouncer Cloudflare envoie les bans à votre Cloudflare account, qui bloque à l’edge. Combine self-hosted + edge protection.

Console gratuite ? Oui jusqu’à 3 machines. Au-delà 7 USD/machine/mois.

Performance ? Agent : 30-80 Mo RAM. Bouncer iptables : <1 Mo. Aucun impact mesurable.

Compatible IPv6 ? Oui complet, parsers et bouncers IPv6.

Mises à jour ? apt upgrade ou docker pull. Configurations préservées.

RGPD ? CrowdSec partage uniquement IP + scenario + timestamp avec CAPI. Pas de données personnelles. Conforme RGPD.

Pour approfondir

Comparaison face aux alternatives 2026

Solution Coût Auto-hébergé Détection Communautaire
CrowdSec 0 € (self-hosted) Oui Comportementale 4M IP partagées
Fail2ban 0 € Oui Regex Aucune
Wazuh 0 € (self-hosted) Oui SIEM complet Limited
Cloudflare WAF Pro 240 USD/an/domaine Non Edge Cloudflare
AWS Shield Advanced 3 000 USD/mois Non Cloud AWS
Sucuri 200 USD/an/site Non Edge + Cloud Sucuri

Où héberger votre projet web ?

Hostinger propose des plans dimensionnés pour les freelances et PME. Lien d’affiliation — pas de surcoût pour vous.

Comparer les plans →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Étape 1 : comprendre ce qui distingue CrowdSec de Fail2ban

Fail2ban est un classique éprouvé : il analyse les logs locaux, applique des règles, bannit les IP coupables via iptables. Sa limite est qu’il fonctionne en silo — chaque serveur réinvente la roue. Une attaque qui frappe un VPS à Dakar n’apprend rien au VPS suivant à Abidjan.

CrowdSec inverse la logique : chaque agent participant remonte (anonymement) les IP qu’il a vu attaquer, et redescend une liste consolidée d’IP malveillantes vues partout dans le monde dans les dernières heures. Résultat : un VPS fraîchement déployé bloque dès le premier jour des dizaines de milliers d’IP réputées dangereuses, sans avoir lui-même subi d’attaque.

Étape 2 : préparer un VPS Linux propre

CrowdSec tourne sur Debian 12, Ubuntu 22.04/24.04, AlmaLinux 9, Rocky Linux 9, et la plupart des distributions modernes. Pour ce tutoriel, on utilise Debian 12 sur un VPS Hetzner CX22 (2 vCPU, 4 Go de RAM, 4,51 EUR HT/mois soit ~3 000 FCFA).

ssh root@VOTRE_IP_VPS
apt update && apt upgrade -y
apt install curl ca-certificates -y

Sortie de référence : un système à jour, prêt à recevoir le dépôt CrowdSec. Mettez aussi à jour l’horloge système (timedatectl set-timezone Africa/Dakar selon votre fuseau) car les analyses de logs sont sensibles à l’heure.

Étape 3 : ajouter le dépôt officiel et installer CrowdSec

CrowdSec maintient un dépôt APT officiel signé. Ajoutez-le proprement :

curl -s https://install.crowdsec.net | sudo sh
apt install crowdsec -y

L’installation détecte automatiquement les services présents (SSH, Nginx, Apache) et propose des collections de scénarios adaptés. Acceptez les choix par défaut pour un premier déploiement. Test concluant : la commande systemctl status crowdsec retourne active (running).

Étape 4 : installer un bouncer pour appliquer les bannissements

L’agent CrowdSec détecte, mais ne bloque pas seul — c’est un bouncer (videur) qui applique. Pour un VPS standard, le bouncer firewall est le bon choix :

apt install crowdsec-firewall-bouncer-iptables -y
systemctl enable --now crowdsec-firewall-bouncer

Le bouncer crée automatiquement deux ipset (crowdsec-blacklists et crowdsec6-blacklists) et insère les règles iptables. Vérifiez avec iptables -L INPUT -n | grep crowdsec. Sortie de référence : deux règles DROP référençant les ipset.

Étape 5 : activer le partage collaboratif (CTI Community)

Le cœur de CrowdSec : la blocklist communautaire. Inscrivez votre instance sur le hub :

cscli capi register
cscli console enroll <votre-token-app-crowdsec>

Récupérez le token sur https://app.crowdsec.net (compte gratuit, jusqu’à 3 machines). Une fois enrolé, votre agent reçoit la blocklist communautaire toutes les deux heures et remonte les IP que vous identifiez localement. Vérifiez : cscli decisions list --origins CAPI doit afficher des milliers d’IP au bout de quelques minutes.

Étape 6 : surveiller un service web (Nginx)

Si votre VPS héberge Nginx, indiquez à CrowdSec où trouver les logs :

cscli collections install crowdsecurity/nginx
systemctl reload crowdsec

Le fichier /etc/crowdsec/acquis.yaml doit contenir une entrée pointant vers /var/log/nginx/access.log et /var/log/nginx/error.log. CrowdSec applique alors les scénarios HTTP standard : scan d’admin (wp-login, phpMyAdmin), brute-force, énumération d’URL. Résultat attendu après quelques heures : cscli alerts list affiche des alertes nginx-bf, nginx-probing, etc.

Étape 7 : tester un bannissement manuel

Pour valider que la chaîne fonctionne de bout en bout :

cscli decisions add --ip 192.0.2.42 --duration 1h --reason "test"
cscli decisions list | grep 192.0.2.42
iptables -L INPUT -n | head

L’IP de test apparaît dans les décisions et dans l’ipset. Retirez-la après vérification : cscli decisions delete --ip 192.0.2.42. Cela confirme que le bouncer applique bien les ordres reçus de l’agent.

Étape 8 : ajouter des collections pour d’autres services

Le hub CrowdSec contient des centaines de collections. Pour un serveur typique en Afrique de l’Ouest francophone hébergeant WordPress, ajoutez :

cscli collections install crowdsecurity/sshd
cscli collections install crowdsecurity/wordpress
cscli collections install crowdsecurity/iptables
systemctl reload crowdsec

WordPress est particulièrement ciblé : énumération d’utilisateurs ?author=1, brute-force sur wp-login.php, abus de l’API XML-RPC. La collection wordpress couvre ces patterns en standard. Voir notre guide principal sur la sécurité WordPress.

Étape 9 : exposer un dashboard local

Pour visualiser les alertes sans payer la console SaaS, installez le dashboard local Metabase fourni par CrowdSec :

cscli dashboard setup -l 127.0.0.1 -p 3000

Accédez ensuite à http://127.0.0.1:3000 via un tunnel SSH : ssh -L 3000:127.0.0.1:3000 root@VOTRE_IP. Vous obtenez les graphiques par scénario, par IP source, par pays. Très utile pour repérer qu’une vague d’attaques vient d’une géographie précise.

Étape 10 : maintenir et superviser dans la durée

Mettez à jour CrowdSec mensuellement (apt update && apt upgrade crowdsec) et rechargez les scénarios via cscli hub upgrade. Configurez une alerte email ou un webhook Slack/Discord via le plugin de notification quand une alerte critique se déclenche.

Vérifiez périodiquement les faux positifs : cscli alerts list --since 24h. Si un crawler légitime (bot Google, Bing) est banni à tort, ajoutez-le à une whitelist. Pour explorer plus loin, voir notre tutoriel sur le hardening complet d’un VPS Linux.

Avec cette installation, un VPS d’entrée de gamme bloque facilement 50 000 à 200 000 IP malveillantes simultanément, sans charge significative — l’agent consomme typiquement 30 à 60 Mo de RAM et < 1 % de CPU.

Étape 11 : intégrer CrowdSec à un reverse-proxy Cloudflare

Quand votre site passe par Cloudflare, l’IP source vue par Nginx est celle de Cloudflare, pas du visiteur réel. Activez le module real-ip de Nginx avec les plages Cloudflare officielles, sinon CrowdSec bannira par erreur les IP du CDN. Utilisez aussi le bouncer crowdsec-cloudflare-bouncer qui synchronise vos décisions vers les règles Cloudflare WAF, bloquant ainsi les IP malveillantes en bordure du réseau avant même qu’elles atteignent votre VPS à Falkenstein, Helsinki ou Strasbourg.

apt install crowdsec-cloudflare-bouncer -y
cscli bouncers add cloudflare-bouncer
# Renseignez le token Cloudflare avec la permission Zone WAF Edit
nano /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml
systemctl enable --now crowdsec-cloudflare-bouncer

Résultat type : sur le dashboard Cloudflare, l’onglet Security > WAF > Tools affiche désormais les IP bloquées poussées par CrowdSec, mises à jour toutes les dix secondes.

Étape 12 : automatiser les sauvegardes de configuration

La configuration CrowdSec mérite une sauvegarde régulière, surtout les whitelists et scénarios personnalisés. Une commande tâche cron hebdomadaire suffit pour archiver l’ensemble vers un stockage externe.

cscli config backup /root/crowdsec-backup-$(date +%F).tar.gz
# Ajout cron : tous les dimanches à 2h
echo "0 2 * * 0 root cscli config backup /root/crowdsec-\$(date +\\%F).tar.gz" \
  >> /etc/crontab

Synchronisez ensuite ces archives vers un bucket S3-compatible (Scaleway Object Storage, Wasabi, Backblaze B2). En cas de réinstallation suite à un incident, la restauration se fait en deux minutes via cscli config restore.

Étape 11 : intégrer CrowdSec à un reverse-proxy Cloudflare

Quand votre site passe par Cloudflare, l’IP source vue par Nginx est celle de Cloudflare, pas du visiteur réel. Activez le module real-ip de Nginx avec les plages Cloudflare officielles, sinon CrowdSec bannira par erreur les IP du CDN. Utilisez aussi le bouncer crowdsec-cloudflare-bouncer qui synchronise vos décisions vers les règles Cloudflare WAF, bloquant ainsi les IP malveillantes en bordure du réseau avant même qu’elles atteignent votre VPS à Falkenstein, Helsinki ou Strasbourg.

apt install crowdsec-cloudflare-bouncer -y
cscli bouncers add cloudflare-bouncer
nano /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml
systemctl enable --now crowdsec-cloudflare-bouncer

Sortie attendue : sur le dashboard Cloudflare, l’onglet Security WAF Tools affiche désormais les IP bloquées poussées par CrowdSec, mises à jour toutes les dix secondes. Pour un site visant Dakar, Abidjan, Cotonou ou Lomé, cette double protection (WAF Cloudflare + iptables local) absorbe les vagues d’attaques sans dégrader le temps de réponse pour les visiteurs légitimes connectés en 4G locale.

Étape 12 : automatiser les sauvegardes de configuration

La configuration CrowdSec mérite une sauvegarde régulière, surtout les whitelists et scénarios personnalisés. Une tâche cron hebdomadaire suffit pour archiver l’ensemble vers un stockage externe et garantir une restauration rapide en cas d’incident.

cscli config backup /root/crowdsec-backup-$(date +%F).tar.gz
echo "0 2 * * 0 root cscli config backup /root/crowdsec-bk.tar.gz" \
  >> /etc/crontab

Synchronisez ensuite ces archives vers un bucket S3-compatible (Scaleway Object Storage, Wasabi, Backblaze B2). En cas de réinstallation suite à un incident, la restauration se fait en deux minutes via cscli config restore. C’est la différence entre une remise en route en quelques minutes et une journée complète à reconfigurer scénarios, bouncers et whitelists à la main.

مشاركة