📍 Article principal de la série : CrowdSec 2026 : guide pratique.

Vingt minutes pour transformer un VPS exposé en infrastructure protégée par CrowdSec. Cette procédure est validée chez plusieurs sysadmins francophones d’Afrique de l’Ouest. À la fin, votre VPS bénéficie de la blocklist communautaire 4M IPs et bloque automatiquement les bots SSH et HTTP.

Prérequis

VPS Debian 12 ou Ubuntu 22.04 LTS / 24.04 LTS.
Accès SSH root.
UFW ou iptables actif.
Niveau attendu : intermédiaire (CLI Linux).
Temps estimé : 20-30 minutes.

Pour installer CrowdSec sur un VPS Debian 12 ou Ubuntu 22.04+, vous avez besoin d’un accès sudo, du repository officiel CrowdSec, et d’au moins 512 Mo de RAM disponibles. Pour les serveurs avec beaucoup de trafic (1000+ req/s), prévoyez 2 Go RAM dédiés à l’agent CrowdSec. Comptez 15-20 minutes pour cette installation initiale, plus 30-45 minutes pour configurer les bouncers et collections selon votre stack applicative.

Étape 1 — Ajouter le repository CrowdSec

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

L’installation détecte automatiquement les services présents (SSH, Caddy, Nginx) et installe les collections appropriées.

Le repository officiel CrowdSec offre des packages signés pour Debian et Ubuntu. Lancez : curl -s https://install.crowdsec.net | sudo sh && sudo apt install crowdsec -y. Le script ajoute la clé GPG, configure /etc/apt/sources.list.d/crowdsec_crowdsec.list et installe le package. Vérifiez avec cscli version qui doit afficher v1.6+ au moment de cet article. Sans cette source officielle, vous risquez d’utiliser une version obsolète des distributions standard.

Étape 2 — Vérifier l’agent

cscli version
cscli metrics
systemctl status crowdsec

Doit retourner « active (running) ». L’agent analyse déjà les logs.

L’installation crée le service systemd crowdsec activé par défaut. Vérifiez : systemctl status crowdsec qui doit afficher active (running). L’agent commence immédiatement à parser les logs configurés dans /etc/crowdsec/acquis.yaml (par défaut auth.log et nginx access.log). Logs accessibles via journalctl -u crowdsec -f. Le LAPI local démarre sur 127.0.0.1:8080 — il sert d’interface entre l’agent et les bouncers locaux.

Étape 3 — Inscrire le serveur à la CAPI

cscli capi register
cscli capi status
# Doit retourner : You can successfully interact with Central API (CAPI)

Le serveur télécharge maintenant la blocklist communautaire toutes les heures.

La CAPI (Central API) est la base communautaire CrowdSec qui partage les blocklists entre tous les utilisateurs. Inscrivez votre serveur : cscli capi register qui génère des credentials et configure /etc/crowdsec/online_api_credentials.yaml. Le serveur télécharge alors la blocklist communautaire (50 000-200 000 IPs malveillantes connues) à chaque heure. Cette intelligence collective bloque proactivement 80-90 % des bots avant même qu’ils ne tentent une attaque sur votre serveur.

Étape 4 — Inscrire à la Console (optionnel mais recommandé)

Console.crowdsec.net donne un dashboard web gratuit (3 machines max).

cscli console enroll -e context $YOUR_TOKEN_FROM_CONSOLE

Token obtenu dans Console → Security Engines → Add a new engine.

app.crowdsec.net offre une interface web gratuite pour visualiser les attaques sur tous vos serveurs. Inscrivez-vous (gratuit) puis lancez sur le serveur : cscli console enroll VOTRE_TOKEN. Le serveur apparaît dans le dashboard cloud avec géolocalisation des attaques, top scenarios déclenchés, IP bloquées par pays. Les décisions restent locales — seules les métadonnées sont remontées, ce qui respecte la souveraineté des données tout en bénéficiant de la vue d’ensemble.

Étape 5 — Installer collections selon votre stack

# Collections par défaut déjà installées : linux, sshd
cscli collections list

# Ajouter selon votre stack
cscli collections install crowdsecurity/caddy
cscli collections install crowdsecurity/nginx
cscli collections install crowdsecurity/wordpress
cscli collections install crowdsecurity/postfix
cscli collections install crowdsecurity/iptables
cscli collections install crowdsecurity/base-http-scenarios

# Recharger
systemctl reload crowdsec

Une collection CrowdSec regroupe des parsers et scenarios pour un service spécifique. Installez selon votre stack : cscli collections install crowdsecurity/nginx pour Nginx, crowdsecurity/wordpress pour WordPress, crowdsecurity/mysql pour MySQL bruteforce. Listez les disponibles avec cscli collections list -a. Pour un serveur LAMP classique, installer 3-5 collections couvre l’essentiel. Redémarrez l’agent : systemctl reload crowdsec après chaque install.

Étape 6 — Installer le bouncer iptables

Le bouncer applique les bans au niveau iptables :

apt install -y crowdsec-firewall-bouncer-iptables
systemctl status crowdsec-firewall-bouncer
cscli bouncers list

Le bouncer met à jour les règles iptables toutes les 60 secondes (configurable).

Le bouncer applique les décisions de blocage. Le plus universel est cs-firewall-bouncer qui injecte des règles iptables ou nftables. Installez : apt install crowdsec-firewall-bouncer-iptables -y. Le bouncer s’enregistre automatiquement au LAPI local et reçoit les IPs à bannir. Vérifiez avec iptables -L CROWDSEC -n qui liste les IPs actuellement bloquées. Pour une stack avec Caddy ou Nginx, le bouncer dédié (crowdsec-caddy-bouncer ou crowdsec-nginx-bouncer) bloque au niveau applicatif et génère des codes 403 propres.

Étape 7 — Tester la détection

Depuis un autre poste, simuler une attaque SSH brute-force :

# Sur poste externe
for i in $(seq 1 10); do ssh -o StrictHostKeyChecking=no badpass@VOTRE_VPS; done

Sur le VPS :

cscli alerts list
# Doit afficher l'alerte sshd-bf
cscli decisions list
# Doit afficher le ban actif

Pour valider que CrowdSec détecte les attaques, simulez avec hping3 ou un script qui fait 10 requêtes invalides en 5 secondes vers un endpoint inexistant. Sous 30-60 secondes, votre IP de test apparaît dans cscli alerts list avec le scenario qui a matché. Si vous testez depuis votre IP personnelle, retirez-la rapidement de la blocklist : cscli decisions delete --ip VOTRE_IP. Cette boucle de test confirme que la chaîne acquisition + parser + scenario + bouncer fonctionne bout en bout.

Étape 8 — Configurer la whitelist

Éviter de vous bannir vous-même en ajoutant votre IP fixe :

nano /etc/crowdsec/parsers/s02-enrich/whitelists.yaml

name: crowdsecurity/whitelists
description: "Whitelist private IPs and admins"
whitelist:
  reason: "Trusted admins"
  ip:
    - "192.168.0.0/16"
    - "10.0.0.0/8"
    - "172.16.0.0/12"
    - "VOTRE.IP.PUBLIQUE.FIXE"
  cidr:
    - "100.64.0.0/10"  # Tailscale

systemctl reload crowdsec

Certaines IPs ne doivent JAMAIS être bloquées : votre IP de bureau, les IPs des moniteurs uptime (Uptime Kuma, Better Stack), les IPs des services de paiement qui callback (Wave, Mixx by Yas). Créez /etc/crowdsec/parsers/s02-enrich/mywhitelists.yaml avec name: mywhitelist\nwhitelist:\n reason: trusted infra\n ip:\n - 196.207.X.X\n - 41.83.Y.Y. Ce fichier est appliqué après les parsers et marque les requêtes comme whitelisted, empêchant les scenarios de les flagger.

Étape 9 — Métriques en temps réel

cscli metrics
# Affiche : parsers, scenarios, bouncers, alerts

Dashboard Console.crowdsec.net affiche le détail visuel.

CrowdSec expose des métriques Prometheus sur 127.0.0.1:6060/metrics. Métriques clés : cs_parser_hits_total (volume de logs parsés), cs_bucket_pour_total (alertes générées), cs_active_decisions (IPs actuellement bloquées). Scrappez avec Prometheus puis dashboard Grafana avec alertes si cs_parser_hits_total tombe à 0 (l’agent ne parse plus rien) ou cs_active_decisions explose au-dessus de 10 000 (attaque massive en cours). Pour les setups simples, cscli metrics affiche un résumé en CLI.

Étape 10 — Logs et debugging

journalctl -u crowdsec -f
tail -f /var/log/crowdsec.log
# Pour bouncer
journalctl -u crowdsec-firewall-bouncer -f

Trois logs critiques. journalctl -u crowdsec -f pour les logs de l’agent en temps réel. /var/log/crowdsec.log pour les détails parsers (utilisé en debug). cscli alerts list pour l’historique des alertes des dernières 24-48h. En cas de comportement bizarre (un scenario qui ne match pas), activez le mode verbose : crowdsec -t -error en foreground qui affiche le pipeline complet pour chaque ligne de log. Ce mode debug est crucial pour valider une nouvelle collection custom avant de la déployer en production.

Erreurs fréquentes

Erreur	Cause	Solution
CAPI register échoue	Pas d’accès Internet sortant	Vérifier UFW outbound 443
Logs non parsés	Format différent	Customiser parser ou ajuster journalctl
Bouncer ne bloque pas	iptables flushé ailleurs	Vérifier UFW + chain CROWDSEC_CHAIN
Agent crash boot	Permission denied logs	Adduser crowdsec adm
Bouncer 401 Unauthorized	API key expirée	`cscli bouncers add new-bouncer`
Faux positif bot Google	Whitelist Googlebot manquant	Ajouter postoverflow whitelist

Trois choses à retenir pour le contexte local

Trois précisions. IP fixe limitée : si pas d’IP publique fixe (typique chez ADSL Sonatel, Maroc Telecom, Orange CI), utiliser Tailscale + whitelist range Tailscale. 4G fluctuante : votre IP mobile change fréquemment, donc impossible de whitelist. Utiliser SSH key + 2FA + bastion fixe sur Tailscale. Logs heure locale : configurer timezone serveur sur Africa/Casablanca, Africa/Dakar, ou Africa/Tunis pour cohérence audits.

Tutoriels frères

CrowdSec se complète bien avec d’autres outils défensifs. Wazuh pour la détection d’intrusion approfondie (HIDS, monitoring fichier). UFW + fail2ban classiques en backup ou baseline. Authentik pour le SSO unifié sur les outils admin. Pour les déploiements multi-serveurs, voyez notre tutoriel CrowdSec multi-serveurs avec LAPI central. Cette stack défense-en-profondeur transforme un serveur exposé en infrastructure de niveau entreprise.

FAQ

Migration depuis Fail2ban ? Désactiver Fail2ban (systemctl disable --now fail2ban) puis installer CrowdSec. Pas de risque doublons.

Performance impact ? Agent : 30-80 Mo RAM. Bouncer : 5-10 Mo. CPU : ~1% en moyenne. Aucun impact perceptible.

Désinscription CAPI ? cscli capi unregister. Plus de blocklist communautaire ensuite.

Compatible Docker ? Oui, image officielle crowdsecurity/crowdsec. Avec mounts logs hôte.

API REST ? Oui, LAPI sur 127.0.0.1:8080. Auth via API keys.

Pour approfondir

🔝 Retour au guide général : guide pratique CrowdSec 2026
Documentation : docs.crowdsec.net

Pour appliquer ce tutoriel sur un vrai serveur

Hostinger reste l’option la plus simple pour démarrer. Lien partenaire — votre achat soutient le blog sans surcoût.

Réserver un VPS Hostinger →

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

Pourquoi CrowdSec a dépassé Fail2ban en 2026 sur les VPS pro

Fail2ban a 20 ans, fonctionne, mais reste limité à votre serveur isolé : si une IP attaque 10 000 sites WordPress depuis 2 mois, votre Fail2ban ne le saura qu’au moment où elle vous attaque vous. CrowdSec inverse la logique — chaque agent partage anonymement les IP malveillantes détectées avec une base communautaire de 250 000+ machines, et reçoit en retour une Community Blocklist de 90 000 IP brûlées mises à jour toutes les 4 heures. Sur un VPS hébergeant un WordPress de PME à Dakar, ce mécanisme bloque 70-85 % des tentatives de brute-force avant même qu’elles atteignent wp-login.php.

CrowdSec est open source (licence MIT), écrit en Go, ~80 Mo RAM, compatible Debian 12, Ubuntu 22.04/24.04, RHEL 9. Ce tutoriel cible un VPS unique avec Nginx + WordPress + SSH exposé. Comptez 35 minutes pour le setup complet et 5 minutes par mois de supervision.

Étape 1 — Préparer le VPS et installer le repo officiel

Connectez-vous en SSH au VPS (Hetzner, Scaleway, OVH, peu importe). Vérifiez l’OS :

cat /etc/os-release | grep PRETTY_NAME
# Ubuntu 24.04 LTS attendu

Ajoutez le dépôt CrowdSec officiel et installez l’agent + le bouncer Nginx :

curl -s https://install.crowdsec.net | sudo sh
apt install -y crowdsec crowdsec-nginx-bouncer
systemctl status crowdsec

Vous devez voir active (running). Si le service échoue, consultez journalctl -u crowdsec -n 50 — la cause la plus fréquente est un port 6060 déjà occupé (changez-le dans /etc/crowdsec/config.yaml).

Étape 2 — Vérifier les collections par défaut et ajouter celles utiles

CrowdSec installe automatiquement la collection Linux de base. Vérifiez puis ajoutez les collections pertinentes pour un VPS WordPress :

cscli collections list
cscli collections install crowdsecurity/nginx
cscli collections install crowdsecurity/wordpress
cscli collections install crowdsecurity/sshd
systemctl reload crowdsec

Chaque collection contient des parsers (lire les logs Nginx au format combined), des scénarios (détecter 5 erreurs 401 en 30 secondes = brute force) et des postoverflows (whitelister votre IP de bureau). La collection WordPress détecte spécifiquement les tentatives sur xmlrpc.php, les scans /wp-config.php.bak et les bots ChatGPT-Crawler agressifs.

Étape 3 — Whitelister votre IP fixe et celle des bureaux clients

Avant d’activer les blocages, sécurisez l’accès admin. Créez /etc/crowdsec/parsers/s02-enrich/whitelist-bureau.yaml :

name: bureau/whitelist
description: "Bureaux et IP fixes admin"
whitelist:
  reason: "Bureau admin"
  ip:
    - "41.221.xxx.xxx"  # Bureau Dakar Sonatel fibre
    - "154.124.xxx.xxx" # Maison admin Free Sénégal
  cidr:
    - "192.168.0.0/16"

Rechargez : systemctl reload crowdsec. Vérifiez avec cscli decisions list qu’aucune décision n’existe pour vos IP. Sans cette whitelist, un test de pénétration depuis votre propre laptop bannira votre IP en 60 secondes et vous casserez SSH — c’est arrivé à tous les admins au moins une fois.

Étape 4 — Activer le bouncer Nginx pour bloquer en temps réel

L’agent détecte, le bouncer bloque. Le paquet crowdsec-nginx-bouncer a déjà été installé à l’étape 1, configurez-le :

cscli bouncers add nginx-bouncer
# Copiez la clé API affichée
nano /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf
# Coller la clé dans API_KEY=
nginx -t && systemctl reload nginx
systemctl restart crowdsec-nginx-bouncer

Testez avec tail -f /var/log/nginx/access.log et bombardez votre /wp-login.php depuis un VPN ou un VPS de test : après 6 erreurs 401 en 60 secondes, votre IP de test reçoit un HTTP 403 ban_reason=ban. Le ban dure 4 heures par défaut.

Étape 5 — Activer la Community Blocklist gratuite

C’est la valeur ajoutée principale de CrowdSec. Créez un compte gratuit sur app.crowdsec.net, récupérez l’API key, puis :

cscli console enroll YOUR_ENROLL_KEY
# Activer la Community Blocklist (gratuite jusqu'à 3 machines)
cscli capi register
systemctl restart crowdsec
cscli decisions list -o json | jq '. | length'

Vous devez voir 90 000 à 110 000 décisions actives en quelques minutes (téléchargement initial). Sur un VPS WordPress moyennement exposé, attendez-vous à voir 200-500 IP de la blocklist tenter une connexion par jour — toutes bloquées avant d’atteindre PHP.

Étape 6 — Surveiller les attaques avec le dashboard cloud

Le dashboard app.crowdsec.net affiche en temps réel les alertes, top des IP attaquantes, top des scénarios déclenchés. Pour 1 VPS c’est gratuit. Pour 4+ machines, il faut passer en plan payant (à partir de 10 USD/mois soit ~6 560 FCFA). Un dashboard local Metabase reste gratuit :

cscli dashboard setup
# Suivez l'URL affichée, mot de passe par défaut admin/admin
cscli alerts list --since 24h

Sur un WordPress de PME ouvert depuis 6 mois, vous verrez typiquement 800-2000 alertes par jour, dont 95 % résolues automatiquement par le ban 4h. Les 5 % restants méritent un coup d’œil hebdomadaire — souvent une IP qui brute-force un endpoint custom (plugin de formulaire mal configuré).

Étape 7 — Intégrer Cloudflare en bouncer remote

Si votre site est derrière Cloudflare, le ban local Nginx ne sert à rien — les attaquants atteignent Cloudflare avant votre VPS. Installez le bouncer Cloudflare :

apt install -y crowdsec-cloudflare-bouncer
nano /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml
# Renseigner CF_TOKEN et zone_id (Cloudflare dashboard)
systemctl restart crowdsec-cloudflare-bouncer
journalctl -u crowdsec-cloudflare-bouncer -n 30

CrowdSec pousse alors les IP bannies dans la WAF custom rules Cloudflare via API. Plan Cloudflare gratuit accepte 10 000 IP en liste, plan Pro (20 USD/mois soit 13 100 FCFA) monte à 100 000. Pour un site WordPress africain, le plan gratuit suffit largement.

Étape 8 — Ajouter SMS Mixx by Yas en alerte critique

Pour être alerté si une attaque DDoS sérieuse se déclenche (scénario http-crawl-non_statics avec 50+ IP simultanées), branchez un webhook vers une passerelle SMS Mixx by Yas :

cat > /etc/crowdsec/notifications/sms-yas.yaml <<'EOF'
type: http
name: sms-yas
log_level: info
format: |
  { "to": "+221771234567", "text": "ALERTE CrowdSec: {{.Alert.Scenario}} - {{.Alert.Source.IP}}" }
url: https://api.mixxbyyas.sn/v1/sms
method: POST
headers:
  Authorization: Bearer YOUR_TOKEN
EOF

Référencez ensuite ce notifier dans un profil /etc/crowdsec/profiles.yaml. Comptez 25 FCFA par SMS Mixx by Yas, soit 5-15 SMS par mois pour un site bien protégé : moins de 400 FCFA/mois pour ne plus jamais découvrir une attaque le lundi matin.

Étape 9 — Tarifs prestation et SLA réaliste pour client PME

Trois niveaux tarifaires testés terrain en 2025-2026 sur le marché Afrique de l'Ouest francophone : (1) Setup one-shot CrowdSec + bouncer Nginx + monitoring — 75 000 à 120 000 FCFA selon nombre de sites WordPress sur le VPS ; (2) SLA mensuel surveillance — 25 000 FCFA/mois pour revue hebdo, ajustement scénarios, support WhatsApp 48h ouvrées ; (3) Forfait incident — 35 000 FCFA par intervention d'urgence (DDoS en cours, IP whitelistée à débloquer en pleine nuit). Réglez par Wave ou virement BCEAO, jamais PayPal.

Dans la continuité, consultez notre guide pour sécuriser un WordPress sur VPS et notre tutoriel Cloudflare débutant.