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

Pour une ESN gérant 8 VPS clients, ou une PME avec serveurs production + staging + dev + monitoring, l’architecture LAPI central centralise les décisions : une IP bannie sur VPS A est bannie sur tous. Vue unifiée Console, gestion simplifiée. Ce tutoriel détaille l’architecture validée chez plusieurs ESN à Casablanca, Tunis, et Abidjan.

Prérequis

5+ VPS Linux (Hetzner, OVH).
VPN privé entre les VPS (Tailscale, Headscale, ou WireGuard).
CrowdSec installé sur chaque (voir tutoriel installation).
Niveau attendu : avancé.
Temps estimé : 1-2 heures.

Pour un déploiement CrowdSec multi-serveurs avec LAPI (Local API) central, vous avez besoin d’un VPS dédié au LAPI (CX11 Hetzner suffit, 2 Go RAM). Plusieurs serveurs applicatifs avec CrowdSec installé en mode agent. Un réseau privé (Tailscale, WireGuard, ou subnet Hetzner Cloud Network) pour sécuriser la communication entre agents et LAPI. CrowdSec v1.6 minimum sur tous les nodes pour la compatibilité protocolaire. Comptez 1-2 heures pour cette installation initiale, puis 15 minutes par agent supplémentaire ajouté.

Étape 1 — Architecture cible

VPS LAPI central : héberge le LAPI + base SQLite ou Postgres centralisée. Recommandé : Hetzner CX23 dédié à cette fonction.

VPS agents : analysent leurs logs, envoient alertes au LAPI central, lisent les décisions. Pas de LAPI local.

Bouncers : sur chaque VPS, lisent décisions du LAPI central via API.

Étape 2 — Préparer le LAPI central

Sur le VPS dédié :

nano /etc/crowdsec/config.yaml

api:
  server:
    listen_uri: 0.0.0.0:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    online_client:
      credentials_path: /etc/crowdsec/online_api_credentials.yaml
db_config:
  type: sqlite
  db_path: /var/lib/crowdsec/data/crowdsec.db
  # Ou Postgres pour 50+ agents
  # type: postgresql
  # host: ...
  # port: 5432

systemctl restart crowdsec

Sur le VPS dédié LAPI, installez CrowdSec via le repository officiel : curl -s https://install.crowdsec.net | sudo sh && sudo apt install crowdsec. Désactivez les acquisitions logs locales (le LAPI ne traite pas de logs lui-même, juste les décisions remontées par les agents) en commentant le contenu de /etc/crowdsec/acquis.yaml. Modifiez /etc/crowdsec/config.yaml pour exposer l’API LAPI sur 0.0.0.0:8080 (ou sur l’IP privée Tailscale uniquement pour plus de sécurité).

Étape 3 — Sécuriser l’accès LAPI

Le LAPI ne doit pas être exposé publiquement. Options :

Tailscale : tous agents sur tailnet, LAPI sur 100.64.0.X.
WireGuard : VPN privé entre VPS.
Cloudflare Tunnel : LAPI accessible uniquement via tunnel signé.

Recommandation : Tailscale, simplicité.

Le LAPI ne doit JAMAIS être exposé sur Internet public. Trois options pour le sécuriser. Premièrement, écouter uniquement sur le subnet Tailscale (listen_uri: 100.64.0.1:8080). Deuxièmement, utiliser HTTPS avec certificat client mutuel (mTLS). Troisièmement, placer derrière un reverse proxy Caddy avec authentification HTTP basique. Pour une infrastructure à 5-10 serveurs en zone UEMOA, l’option Tailscale offre le meilleur ratio simplicité/sécurité.

Étape 4 — Inscrire chaque agent au LAPI central

Sur chaque VPS agent :

# Désactiver LAPI local
nano /etc/crowdsec/config.yaml
# Sous api:server: : enabled: false

# Créer credentials pour LAPI central
cat > /etc/crowdsec/local_api_credentials.yaml << EOF
url: http://100.64.0.5:8080  # Tailscale IP du LAPI central
login: agent-vps-X
password: A_GENERER_VIA_LAPI_CENTRAL
EOF

Sur chaque serveur applicatif (qui exécute votre site web, API, mailcow, etc.), modifiez /etc/crowdsec/config.yaml pour pointer vers le LAPI central : api: client: credentials_path: /etc/crowdsec/local_api_credentials.yaml. Désactivez le LAPI local sur chaque agent : api: server: enable: false. Cette configuration fait que les agents remontent leurs détections au LAPI central et n’ont plus de DB locale.

Étape 5 — Sur le LAPI central, créer machine pour chaque agent

# Sur LAPI central
cscli machines add agent-vps-1 --auto
cscli machines add agent-vps-2 --auto
cscli machines add agent-vps-3 --auto
# Note password retourné, copier dans config agent

Sur le LAPI, lancez cscli machines add agent-web1 --auto qui génère un identifiant et une clé. Récupérez le fichier credentials généré (/var/lib/crowdsec/data/…) et copiez-le sur l’agent web1 dans /etc/crowdsec/local_api_credentials.yaml. Répétez pour chaque agent (web2, mail, db). Cette inscription mutuelle authentifie chaque agent et empêche un attaquant qui compromettrait un node de polluer le LAPI avec de fausses décisions.

Étape 6 — Inscrire les bouncers au LAPI central

Sur chaque VPS avec bouncer (firewall, Caddy, Nginx) :

# Sur LAPI central : créer bouncer key
cscli bouncers add bouncer-vps-1 --auto
# Note la clé

# Sur VPS agent : pointer bouncer vers LAPI central
nano /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
api_url: http://100.64.0.5:8080
api_key: VOTRE_CLE

Les bouncers (Caddy, Nginx, Cloudflare, fail2ban) appliquent les décisions de blocage. Ils s’inscrivent au LAPI : cscli bouncers add caddy-bouncer-web1 --auto qui génère une API key. Configurez le bouncer (par exemple crowdsec-caddy-bouncer) avec cette clé et l’URL du LAPI. Le bouncer télécharge périodiquement la liste des IPs à bloquer et les applique. Pour 10 sites web sous Caddy, un bouncer par site avec sa propre clé permet d’auditer qui consomme la base de décisions.

Étape 7 — Vérifier la communication

# Sur LAPI central
cscli machines list
# Doit lister tous les agents avec validated=true

cscli bouncers list
# Doit lister tous les bouncers

Sur le LAPI, listez les agents connectés : cscli machines list qui doit montrer tous les agents avec leur statut (last_heartbeat récent). cscli decisions list liste les blocages actifs sur l’ensemble du parc. Sur un agent, cscli alerts list montre les détections locales. Si un agent ne remonte pas, vérifiez la connectivité réseau (firewall, Tailscale up) et les credentials. Pour debug, lancez crowdsec en mode foreground avec crowdsec -t.

Étape 8 — Tester le partage décisions

# Sur agent VPS-1, simuler attaque
ssh badpass@VPS-1 # x10

# Sur LAPI central
cscli alerts list
# Doit montrer alerte de VPS-1

cscli decisions list --type ban
# Doit montrer ban actif

# Sur VPS-2 (autre agent), vérifier que décision est appliquée
cscli decisions list
# Doit aussi voir le ban (téléchargé du LAPI central)

Étape 9 — Console unifiée

Inscrire le LAPI central à la Console :

cscli console enroll -e context VOTRE_TOKEN_CONSOLE

La Console affiche désormais alertes de tous les agents en vue unifiée.

CrowdSec Console (app.crowdsec.net) offre un dashboard web gratuit pour visualiser les décisions sur l’ensemble du parc. Inscrivez le LAPI avec cscli console enroll VOTRE_TOKEN. Le dashboard montre les attaques par origine géographique (très utile pour identifier les patterns d’attaque par pays), les scenarios déclenchés, et les top blocked IPs. Les décisions restent locales, seules les métadonnées sont remontées au cloud — cohérent avec le principe de souveraineté des données.

Étape 10 — Backup centralisé

Sauvegarder régulièrement la base SQLite ou Postgres du LAPI central. Sans elle, perte de l’historique alertes et décisions actives.

Le LAPI stocke ses décisions en SQLite par défaut (/var/lib/crowdsec/data/crowdsec.db). Pour les déploiements production, migrez vers Postgres ou MariaDB pour la fiabilité. Sauvegardez quotidiennement la base via Restic vers Backblaze B2. Pour la disaster recovery (perte du VPS LAPI), configurez un LAPI standby avec réplication continue. Sans backup, perdre le LAPI = perdre tout l’historique des décisions et la timeline des attaques.

Erreurs fréquentes

Erreur	Cause	Solution
Agent ne joint pas LAPI	Tailscale pas up	Vérifier `tailscale ping`
Machine pas validée	Pas de `--auto` au create	`cscli machines validate agent-vps-X`
Décisions pas propagées	Bouncer ne pull pas	Vérifier ticker_interval
SQLite saturée	50+ agents sur SQLite	Migrer vers Postgres
Auth password échoue	Caractère spécial mal échappé	Réinitialiser password
Console n’affiche que LAPI	Agents pas enrollés	Enroll chaque machine séparément

Spécificités ouest-africaines à connaître

Trois précisions. VPN entre datacenters : Hetzner Falkenstein + OVH Roubaix + Africa Data Centres Lagos. Tailscale reliera tous, latence acceptable. Coût total : 1 LAPI central (4,51 €) + 8 agents (déjà existants), aucun coût supplémentaire. Audit consolidé : pour ESN avec multiple clients, vue unifiée des incidents simplifie le reporting trimestriel.

Tutoriels frères

Cette stack CrowdSec multi-serveurs se complète bien avec d’autres outils sécurité self-hosted. Wazuh pour la détection d’intrusion approfondie (HIDS, monitoring fichier). Authentik pour le SSO unifié sur les outils admin. Tailscale pour le réseau privé maillé entre serveurs. Caddy ou Nginx pour le reverse proxy avec bouncer CrowdSec intégré. Ces briques forment une défense en profondeur cohérente pour une PME africaine qui prend la sécurité au sérieux.

FAQ

Limite agents par LAPI ? SQLite : 20 agents confortables. Postgres : 500+.

Failover LAPI central ? CrowdSec ne supporte pas HA natif. Solution : 2 LAPIs en réplication Postgres + DNS round-robin.

Console suffit pour tout ? Pour < 50 machines oui. Au-delà, scripting cscli.

Multi-tenant ESN ? Pas de tenancy CrowdSec. Workaround : LAPI séparé par client.

Migration SQLite → Postgres ? Procédure documentée, comptez 30 min.

Pour étoffer le tableau

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

Solution d’hébergement pour ce tutoriel

Hostinger accueille un site WordPress, un VPS Linux ou une boutique en ligne sans configuration complexe.

Démarrer chez Hostinger →

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

Pourquoi centraliser CrowdSec sur plusieurs serveurs en 2026

Quand vous gerez plus de trois VPS exposes sur Internet — un Nginx public a Dakar, deux backends Node a Abidjan, un MariaDB de secours a Lome — chaque machine accumule sa propre liste de bans. Sans coordination, un attaquant brute-force banni sur le frontal continue d’essayer le SSH du backend pendant des heures. CrowdSec resout ce probleme avec un Local API (LAPI) central qui agrege les decisions de tous les bouncers et redistribue les bans en temps reel.

Cette architecture remplace avantageusement Fail2ban quand votre stack depasse deux serveurs ou quand vous voulez beneficier de la communaute (CrowdSec mutualise les IPs malveillantes signalees par 100 000+ instances dans le monde, dont une part croissante en Afrique de l’Ouest).

Etape 1 — Provisionner le serveur LAPI central

Choisissez un VPS dedie a la securite, idealement sur la meme zone reseau que vos serveurs proteges pour minimiser la latence. Un Hetzner CX22 (4,51 EUR / mois soit environ 2 960 FCFA) suffit pour 20 a 30 bouncers. Installez Debian 12 minimal puis appliquez le depot officiel.

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

A la fin de l’installation vous devez voir active (running) dans systemctl status crowdsec. Si la commande retourne une erreur de port, verifiez qu’aucun autre service n’occupe le 8080.

Etape 2 — Exposer le LAPI sur le reseau prive

Par defaut le LAPI ecoute sur 127.0.0.1 — il faut l’ouvrir sur l’interface privee pour que les bouncers distants s’y connectent. Editez /etc/crowdsec/config.yaml et remplacez listen_uri.

api:
  server:
    listen_uri: 10.0.0.5:8080
    use_forwarded_for_headers: true

Redemarrez avec sudo systemctl restart crowdsec. Verifiez ensuite avec ss -tlnp | grep 8080 que le service ecoute bien sur l’IP privee. Pour la securite, n’exposez jamais le 8080 sur l’IP publique — utilisez un VPN WireGuard ou un reseau prive type Hetzner vSwitch.

Etape 3 — Generer les credentials machine pour chaque agent distant

Chaque serveur protege embarque un agent CrowdSec local qui transmet ses logs au LAPI central. Generez un identifiant machine pour le frontal Nginx d’Abidjan.

sudo cscli machines add abidjan-front-01 --auto

La commande retourne un fichier YAML avec login et mot de passe. Copiez ce fichier sur le serveur distant dans /etc/crowdsec/local_api_credentials.yaml. Repetez l’operation pour chaque machine du parc.

Etape 4 — Configurer un agent distant en mode log-only

Sur le serveur Abidjan, installez crowdsec puis desactivez le LAPI local (sinon vous aurez deux APIs concurrentes).

sudo curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec -y
sudo sed -i 's/server: true/server: false/' /etc/crowdsec/config.yaml

Verifiez ensuite que l’agent contacte bien le LAPI central avec sudo cscli lapi status. Vous devez voir You can successfully interact with Local API. Si la commande timeout, ouvrez le port 8080 dans le firewall prive du LAPI.

Etape 5 — Deployer un bouncer Nginx sur le frontal public

Le bouncer est le composant qui applique reellement les bans. Le bouncer Nginx s’integre via la directive access_by_lua de OpenResty.

sudo apt install crowdsec-nginx-bouncer -y
sudo cscli bouncers add nginx-abidjan-01

Copiez la cle API generee dans /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf. Rechargez Nginx avec sudo nginx -t && sudo systemctl reload nginx. Pour tester, declenchez un scan depuis une IP de test — vous devez voir un 403 Forbidden apparaitre dans les logs au bout de 30 secondes.

Etape 6 — Activer la communaute pour mutualiser les IPs malveillantes

L’enrichissement community list ajoute environ 50 000 IPs bannies en temps reel depuis le reseau CrowdSec mondial. Activez-le sur le LAPI central uniquement.

sudo cscli capi register
sudo systemctl restart crowdsec
sudo cscli alerts list -a | head -20

Au bout de quelques minutes vous verrez apparaitre des decisions community_blocklist dans la liste des alertes. Ces IPs sont automatiquement propagees a tous vos bouncers.

Etape 7 — Surveiller la flotte avec cscli et metabase

La commande sudo cscli machines list affiche l’etat de tous les agents enregistres. Une machine inactive depuis plus de 10 minutes apparait avec un point rouge — surveillez cet etat dans votre routine matinale. Pour un dashboard graphique, deployez le conteneur metabase fourni par CrowdSec via sudo cscli dashboard setup.

Etape 8 — Tester un ban distribue de bout en bout

Le test final consiste a declencher un brute-force depuis une IP exterieure et verifier qu’elle est bannie sur tous les frontaux simultanement. Lancez 10 tentatives SSH echouees depuis votre poste vers le backend, puis interrogez le LAPI.

sudo cscli decisions list --ip VOTRE_IP_TEST

Vous devez voir une decision ban avec une duree de 4 heures. Tentez ensuite d’acceder au frontal Nginx depuis cette IP — la requete doit etre rejetee en 403. Le ban est synchronise sur l’ensemble du parc.

Cout d’exploitation realiste pour un parc de 5 serveurs

Un VPS LAPI dedie a 4,51 EUR / mois plus la bande passante interne (gratuite chez Hetzner sur le meme datacenter) ramene le cout total autour de 3 000 FCFA par mois. Compare au temps perdu a auditer manuellement les logs de chaque serveur, le retour sur investissement est immediat des le premier mois d’exploitation.

Pour creuser ce sujet sur le durcissement reseau, consultez notre guide cybersecurite Afrique francophone defense 2026 et le tutoriel securiser un VPS Debian 12.

Etape bonus — Integrer Slack pour les alertes critiques

Les bans isoles ne necessitent pas de notification, mais une attaque coordonnee depuis 50 IPs en 5 minutes meritent un ping immediat. CrowdSec fournit le plugin notification-slack qui pousse les decisions vers un webhook Slack ou Discord.

sudo apt install crowdsec-notifier-slack -y
sudo nano /etc/crowdsec/notifications/slack.yaml

Configurez le webhook URL fourni par Slack et seuillez les alertes a partir de 5 bans simultanes. Vous evitez ainsi le bruit tout en restant alerte sur les pics anormaux qui peuvent traduire un debut d’attaque ciblee.

Etape bonus — Whitelister les IPs de votre bureau a Dakar

Rien de plus frustrant qu’un developpeur banni de son propre serveur parce qu’il a tape trois fois un mauvais mot de passe. Creez une whitelist explicite des plages IP de vos bureaux Sonatel ou Orange a Dakar et Abidjan.

sudo cscli decisions add --ip 41.82.X.X --type whitelist --duration 8760h --reason "bureau dakar"

Renouvelez tous les 12 mois. Pour une protection plus elegante, utilisez un parser local qui exclut les ranges IP au moment de la detection, evitant l’inscription dans la base de decisions.

Erreurs frequentes a eviter en production

La premiere erreur classique consiste a oublier de redemarrer Nginx apres l’installation du bouncer — les nouvelles regles ne sont pas chargees et le ban reste theorique. La seconde est d’exposer le port 8080 du LAPI sur l’IP publique sans authentification supplementaire — un attaquant peut alors effacer toutes vos decisions. Toujours cantonner ce port au reseau prive ou a un VPN WireGuard.