CrowdSec : protéger un serveur Linux contre les attaques avec l'IA collaborative

Les serveurs Linux exposés sur Internet sont des cibles permanentes : tentatives de connexion SSH par force brute, scans de ports automatisés, exploitation de vulnérabilités web — les logs ne mentent pas. Face à cette réalité, les administrateurs systèmes ont longtemps compté sur Fail2ban, un outil solide mais fondamentalement limité à l'analyse locale et à des règles statiques. CrowdSec change la donne en introduisant une approche collaborative et intelligente de la protection des serveurs. En agrégeant les signaux de menace de milliers de serveurs dans le monde entier, CrowdSec constitue une intelligence collective en temps réel : une IP qui attaque un serveur à Paris est automatiquement bloquée sur les serveurs de Tokyo, New York et Bordeaux. Ce guide complet vous accompagne pas à pas dans l'installation, la configuration et l'optimisation de CrowdSec sur vos serveurs Debian et Ubuntu, du déploiement du firewall bouncer jusqu'à la connexion à la console cloud, en passant par les scénarios de détection SSH, HTTP et portscan.

CrowdSec vs Fail2ban — architecture et différences fondamentales

Fail2ban est un outil éprouvé, apparu en 2004, qui surveille les fichiers de logs pour détecter des patterns d'échecs d'authentification et bannir temporairement les IP coupables via iptables ou d'autres mécanismes. Il est simple, efficace pour les cas basiques, et présent sur la quasi-totalité des distributions Linux. Mais son architecture présente des limites structurelles importantes.

Fail2ban fonctionne en mode réactif pur : il attend qu'une IP attaque votre serveur avant de la bloquer. Il n'a aucune connaissance du monde extérieur. Une IP connue de la communauté internationale comme malveillante peut marteler votre serveur sans être bloquée préventivement. De plus, Fail2ban est mono-serveur par défaut — partager des listes de bannissement entre plusieurs machines nécessite des scripts maison complexes.

CrowdSec adopte une architecture radicalement différente, organisée autour de trois couches distinctes :

• L'Agent CrowdSec : analyse les logs en temps réel, détecte les comportements malveillants selon des scénarios écrits en YAML, et remonte les signaux à une API locale (LAPI).
• La Local API (LAPI) : cerveau central du système, elle agrège les décisions, les stocke dans une base de données locale (SQLite ou PostgreSQL), et communique avec les bouncers.
• Les Bouncers : composants d'exécution qui appliquent concrètement les décisions de blocage — firewall, reverse proxy, application web, etc.

Cette séparation agent/LAPI/bouncer est fondamentale : elle permet de faire évoluer chaque composant indépendamment et de déployer plusieurs bouncers sur le même serveur (bloquer au niveau firewall ET au niveau applicatif simultanément).

La dimension collaborative est la vraie révolution de CrowdSec. Chaque instance qui détecte une attaque peut partager ce signal (anonymisé) avec la CrowdSec Central API. En retour, vous bénéficiez des blocklists communautaires, alimentées par des centaines de milliers de serveurs dans le monde. Résultat : une IP qui a attaqué un serveur en Allemagne sera bloquée préventivement sur votre serveur français, avant même qu'elle n'ait tenté quoi que ce soit.

Installer CrowdSec sur Debian/Ubuntu

CrowdSec propose un dépôt officiel pour les distributions basées sur Debian. L'installation est propre et maintenable via apt.

Commencez par ajouter le dépôt CrowdSec :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

Installez ensuite le package principal :

sudo apt-get update
sudo apt-get install crowdsec -y

L'installation détecte automatiquement les services présents sur votre système (nginx, apache2, sshd) et installe les collections adaptées. Vérifiez l'état du service :

sudo systemctl status crowdsec

Le service doit être active (running). Vérifiez également que l'agent détecte bien vos sources de logs :

sudo cscli collections list

Cette commande liste les collections installées. Une collection regroupe plusieurs scénarios de détection et les parseurs de logs associés. Par défaut, si nginx est présent, la collection crowdsecurity/nginx est installée. Si vous avez SSH (cas universel), crowdsecurity/sshd est incluse.

Vérifiez les sources de logs surveillées :

sudo cscli bouncers list
sudo cat /etc/crowdsec/acquis.yaml

Le fichier acquis.yaml liste les fichiers de logs analysés. Sur un serveur Debian standard avec nginx et SSH, vous trouverez typiquement /var/log/auth.log et /var/log/nginx/access.log.

Les composants CrowdSec (Agent, LAPI, Bouncers)

Comprendre l'architecture en profondeur est essentiel pour configurer CrowdSec correctement, surtout en vue d'un déploiement multi-serveurs.

L'Agent est le composant qui lit les logs. Il utilise des parseurs pour comprendre le format de chaque type de log (auth.log, nginx access.log, Apache error.log, etc.) et des scénarios pour détecter les patterns d'attaque. Quand un scénario est déclenché, l'agent crée une alerte et la transmet à la LAPI.

La LAPI (Local API) tourne sur le même serveur par défaut (port 8080). Elle reçoit les alertes de l'agent, les stocke, prend des décisions de bannissement (durée, type : ban, captcha, throttle), et expose une API REST que les bouncers interrogent régulièrement pour obtenir la liste des IP à bloquer. C'est aussi la LAPI qui communique avec la CrowdSec Central API pour partager les signaux et recevoir les blocklists communautaires.

Les Bouncers sont des processus indépendants qui s'authentifient auprès de la LAPI via une clé API et récupèrent périodiquement les décisions actives. Ils n'ont pas accès aux logs et ne prennent aucune décision eux-mêmes — ils exécutent uniquement ce que la LAPI leur dit de faire. Cette architecture découplée est une force : si le bouncer crashe, les décisions ne sont pas perdues. Si l'agent plante, les décisions déjà prises restent appliquées.

Les fichiers de configuration principaux se trouvent dans /etc/crowdsec/ :

• config.yaml : configuration générale (LAPI, base de données, logs)
• acquis.yaml : sources de logs à surveiller
• profiles.yaml : règles de décision (qui décide du ban, de la durée)
• parsers/ : parseurs de logs
• scenarios/ : scénarios de détection

Installer le Firewall Bouncer (iptables ou nftables)

Sans bouncer, CrowdSec détecte les attaques mais ne bloque rien. Le Firewall Bouncer est le plus fondamental : il applique les décisions directement au niveau du firewall kernel, via iptables ou nftables.

Installez le bouncer depuis le dépôt CrowdSec :

sudo apt-get install crowdsec-firewall-bouncer-iptables -y

Ou pour nftables (recommandé sur les systèmes récents) :

sudo apt-get install crowdsec-firewall-bouncer-nftables -y

Lors de l'installation, le bouncer est automatiquement enregistré auprès de la LAPI locale et une clé API est générée. Vérifiez :

sudo cscli bouncers list

Vous devriez voir votre bouncer listé avec son nom et son statut. Vérifiez également que le service est actif :

sudo systemctl status crowdsec-firewall-bouncer

La configuration du bouncer se trouve dans /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Les paramètres clés sont :

mode: nftables  # ou iptables
api_url: http://127.0.0.1:8080/
api_key: VOTRE_CLE_API
deny_action: DROP  # ou REJECT
deny_log: true
deny_log_prefix: "crowdsec: "

Le mode DROP est recommandé : les paquets des IP bannies sont silencieusement ignorés, ce qui ne révèle pas à l'attaquant que son IP est connue. Avec REJECT, l'attaquant reçoit un message d'erreur TCP RST, ce qui peut l'informer de son bannissement.

Pour vérifier que le bouncer applique bien les règles, simulez un bannissement :

sudo cscli decisions add --ip 1.2.3.4 --reason "test" --duration 1m
sudo iptables -L -n | grep 1.2.3.4  # doit apparaître
sudo cscli decisions delete --ip 1.2.3.4

Collections et scénarios de détection (SSH, HTTP, portscans)

CrowdSec organise ses règles de détection en collections, qui regroupent les parseurs et scénarios nécessaires pour protéger un service donné. Le Hub CrowdSec propose des centaines de collections maintenues par la communauté et l'équipe CrowdSec.

Installez les collections essentielles :

# Protection SSH (brute-force, enumération d'utilisateurs)
sudo cscli collections install crowdsecurity/sshd

# Protection nginx
sudo cscli collections install crowdsecurity/nginx

# Protection Apache
sudo cscli collections install crowdsecurity/apache2

# Détection de portscans
sudo cscli collections install crowdsecurity/portscan

# Scénarios génériques HTTP (CVE, path traversal, injections)
sudo cscli collections install crowdsecurity/http-cve

Après l'installation de nouvelles collections, rechargez CrowdSec :

sudo systemctl reload crowdsec

Les scénarios individuels se trouvent dans /etc/crowdsec/scenarios/. Chaque fichier YAML décrit un type d'attaque et ses critères de déclenchement. Par exemple, le scénario crowdsecurity/ssh-bf définit :

type: leaky
name: crowdsecurity/ssh-bf
description: "Detect SSH brute-force"
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
leakspeed: "10s"
capacity: 5
groupby: evt.Meta.source_ip

Ce scénario utilise un seau percé (leaky bucket) : si une IP génère plus de 5 échecs d'authentification SSH en moins de 50 secondes (5 × 10s), elle est bannie. Le paramètre groupby agrège les événements par IP source.

Pour WordPress, ajoutez :

sudo cscli collections install crowdsecurity/wordpress

Pour les bases de données exposées :

sudo cscli collections install crowdsecurity/mysql

Listez tous les scénarios actifs :

sudo cscli scenarios list

Tester la détection (générer des événements, vérifier les décisions)

Une fois CrowdSec configuré, il est impératif de tester son fonctionnement avant de compter dessus en production. La méthode la plus sûre est d'utiliser l'outil cscli pour simuler des décisions sans générer de vraies attaques.

Vérifiez les alertes actuelles :

sudo cscli alerts list

Sur un serveur exposé depuis plusieurs heures, cette liste devrait déjà contenir des entrées — CrowdSec aura détecté des tentatives réelles. Consultez les décisions actives :

sudo cscli decisions list

Pour tester la détection SSH manuellement, vous pouvez injecter des événements dans les logs. La méthode recommandée est d'utiliser cscli simulation :

# Activer le mode simulation pour un scénario (log sans bannir)
sudo cscli simulation enable crowdsecurity/ssh-bf

# Générer 6 tentatives SSH échouées depuis une IP de test
for i in {1..6}; do
  logger -n 127.0.0.1 -P 514 "Failed password for invalid user test from 192.168.1.100 port 22222 ssh2"
done

# Vérifier les alertes simulées
sudo cscli alerts list

# Désactiver la simulation
sudo cscli simulation disable crowdsecurity/ssh-bf

Pour un test réel de bout en bout (avec bannissement effectif), utilisez une IP que vous contrôlez (VPN, second VPS) et tentez plusieurs connexions SSH échouées. Vérifiez ensuite :

sudo cscli decisions list
# L'IP de test doit apparaître avec une durée de bannissement

Vérifiez aussi dans les logs du bouncer que la règle iptables a bien été créée :

sudo journalctl -u crowdsec-firewall-bouncer -f

Gérer les listes blanches (whitelist IPs légitimes)

Un système de détection trop agressif peut bannir des IP légitimes : votre bureau, un monitoring externe, une IP de déploiement CI/CD. CrowdSec propose des whitelists à deux niveaux : au niveau des parseurs (avant la détection) et au niveau des profils (après la détection).

La méthode recommandée est une whitelist au niveau parseur, dans /etc/crowdsec/parsers/s02-enrich/whitelist.yaml :

name: crowdsecurity/whitelists
description: "Whitelist for trusted IPs"
whitelist:
  reason: "IPs de confiance"
  ip:
    - "192.168.1.0/24"
    - "10.0.0.0/8"
    - "VOTRE_IP_BUREAU"
  cidr:
    - "172.16.0.0/12"

Créez ce fichier et rechargez :

sudo systemctl reload crowdsec

Pour les IP qui ont déjà été bannies et que vous souhaitez débloquer :

sudo cscli decisions delete --ip VOTRE_IP
sudo cscli decisions delete --range 192.168.1.0/24

Il est également possible de whitelister par expression. Par exemple, pour exclure les bots de moteurs de recherche connus :

whitelist:
  reason: "Googlebot and legitimate crawlers"
  expression:
    - "evt.Parsed.source_ip in ['66.249.64.0/19']"

Pensez à documenter vos whitelists et à les versionner dans un dépôt Git privé — elles font partie de votre politique de sécurité et doivent être auditables. Vous pouvez aussi consulter notre article sur la journalisation de sécurité Linux pour comprendre comment corréler les événements CrowdSec avec un SIEM.

Connecter à la console CrowdSec Cloud (partage de threat intelligence)

La CrowdSec Console (app.crowdsec.net) est le tableau de bord cloud officiel. Elle permet de visualiser les alertes de tous vos serveurs, de gérer les bouncers, et surtout d'activer le partage de threat intelligence pour bénéficier des blocklists communautaires premium.

Créez un compte gratuit sur crowdsec.net. Une fois connecté, générez une clé d'enrôlement depuis la console (section "Instances"). Enrôlez votre serveur :

sudo cscli console enroll CLE_ENROLEMENT_DEPUIS_LA_CONSOLE

Acceptez l'instance depuis l'interface web de la console. Vérifiez l'enrôlement :

sudo cscli console status

Une fois connecté, activez les fonctionnalités de partage :

sudo cscli console enable share-signals
sudo cscli console enable console-management

La console cloud vous donne accès aux blocklists premium (Firehol, Spamhaus, listes IP de VPN malveillants, etc.) que vous pouvez abonner depuis l'interface. Ces listes sont téléchargées périodiquement et intégrées aux décisions de bannissement.

Consultez également les docs officielles CrowdSec pour configurer les notifications (Slack, PagerDuty, email) depuis la console lorsqu'une nouvelle IP est bannie.

Monitoring et dashboards (Prometheus, Metabase)

CrowdSec expose nativement des métriques au format Prometheus, ce qui facilite l'intégration dans n'importe quelle stack de monitoring.

Activez les métriques Prometheus dans /etc/crowdsec/config.yaml :

prometheus:
  enabled: true
  level: full
  listen_addr: 127.0.0.1
  listen_port: 6060

Rechargez et vérifiez :

sudo systemctl reload crowdsec
curl http://127.0.0.1:6060/metrics | head -50

Configurez votre Prometheus pour scraper ce endpoint, puis importez le dashboard Grafana officiel (ID 14584) pour visualiser en temps réel le nombre d'alertes par scénario, les IP bannies, les événements parsés, etc.

CrowdSec propose également une intégration Metabase pour des dashboards plus riches. Installez Metabase via Docker :

docker run -d -p 3000:3000 \
  -v /var/lib/crowdsec/data/metabase.db:/metabase-data/metabase.db \
  metabase/metabase

CrowdSec fournit un script de configuration automatique de Metabase :

sudo /usr/share/crowdsec/wizard.sh --metabase

Ce dashboard Metabase intégré offre des vues géographiques des attaques, des tendances temporelles, et des classements des scénarios les plus déclenchés — très utile pour justifier la valeur de CrowdSec auprès de la direction.

Pour une vue rapide en ligne de commande des statistiques :

sudo cscli metrics

Cette commande affiche le nombre de lignes parsées, les alertes générées, et les décisions prises par scénario.

Déploiement multi-serveurs avec un LAPI central

L'un des avantages majeurs de CrowdSec par rapport à Fail2ban est sa capacité à fonctionner en mode distribué. Avec un LAPI central, tous vos serveurs partagent les mêmes décisions de bannissement : une IP qui attaque votre serveur web est automatiquement bannie sur votre serveur de base de données et votre serveur mail.

Architecture recommandée :

• Serveur LAPI central : tourne uniquement la LAPI et la base de données (PostgreSQL recommandé pour les volumes importants)
• Serveurs agents : tournent l'agent CrowdSec configuré pour pointer vers le LAPI central
• Bouncers : déployés sur chaque serveur, pointant vers le LAPI central

Sur le serveur LAPI central, configurez PostgreSQL dans /etc/crowdsec/config.yaml :

db_config:
  type: postgresql
  user: crowdsec
  password: MOTDEPASSE_SECURISE
  db_name: crowdsec
  host: 127.0.0.1
  port: 5432
  sslmode: require

Exposez la LAPI sur l'interface réseau du serveur (avec TLS en production). Sur chaque serveur agent, modifiez /etc/crowdsec/config.yaml pour pointer vers le LAPI central :

api:
  client:
    insecure_skip_verify: false
    url: https://LAPI_CENTRAL_IP:8080/
    credentials_path: /etc/crowdsec/local_api_credentials.yaml

Enregistrez chaque agent auprès du LAPI central :

sudo cscli lapi register --url https://LAPI_CENTRAL_IP:8080/ --machine HOSTNAME_UNIQUE

Approuvez chaque machine depuis le serveur LAPI central :

sudo cscli machines list
sudo cscli machines validate HOSTNAME_UNIQUE

Dans cette architecture, vous pouvez également consulter notre article sur la gestion d'infrastructure Linux avec Ansible pour automatiser le déploiement de CrowdSec sur tous vos serveurs. La combinaison CrowdSec + Ansible vous permet de mettre à jour les configurations de sécurité sur des dizaines de serveurs en quelques secondes.

Pour un déploiement à grande échelle, considérez l'utilisation de l'orchestration Kubernetes avec le Helm chart CrowdSec officiel, qui déploie automatiquement un agent par nœud et une LAPI centrale.

Il est aussi possible d'utiliser CrowdSec en combinaison avec un reverse proxy comme Traefik ou nginx pour appliquer des bouncers HTTP directement dans la chaîne de traitement des requêtes. Le bouncer nginx de CrowdSec (crowdsec-nginx-bouncer) permet de retourner un code 403 ou une page CAPTCHA directement depuis nginx, avant même que la requête n'atteigne votre application, ce qui réduit la charge sur votre backend.

La configuration d'un environnement multi-serveurs complet comprend également la gestion des notifications. CrowdSec permet d'envoyer des alertes vers Slack, Teams, PagerDuty ou n'importe quel webhook via ses plugins de notification. Configurez un plugin de notification dans /etc/crowdsec/notifications/ :

# /etc/crowdsec/notifications/slack.yaml
type: slack
name: slack_default
log_level: info
format: |
  {{range . -}}
  [CrowdSec] Nouvelle alerte : {{.Alert.Scenario}} — IP {{.Alert.Source.IP}} bannie pour {{.Alert.Decisions | len}} décisions
  {{end -}}
webhook: https://hooks.slack.com/services/VOTRE/WEBHOOK/URL

Référencez ce plugin dans vos profils de décision (/etc/crowdsec/profiles.yaml) pour déclencher la notification à chaque nouveau bannissement. Cette visibilité en temps réel est précieuse pour les équipes SOC ou pour tout administrateur système souhaitant rester informé des tentatives d'intrusion sur son infrastructure.

Enfin, pensez à mettre à jour régulièrement vos collections et scénarios depuis le Hub CrowdSec. De nouveaux scénarios sont publiés régulièrement pour couvrir les nouvelles CVE et techniques d'attaque :

sudo cscli hub update
sudo cscli hub upgrade
sudo systemctl reload crowdsec

Cette mise à jour peut être automatisée via un cron hebdomadaire. Consultez notre guide sur la sécurisation Linux avec le CIS Benchmark pour intégrer CrowdSec dans une stratégie de durcissement complète de vos serveurs.

Questions fréquentes sur CrowdSec

CrowdSec est-il gratuit et open source ?

Oui, CrowdSec est entièrement open source (licence MIT) et gratuit pour un usage personnel et professionnel. Le modèle économique repose sur des fonctionnalités premium de la console cloud (blocklists avancées, gestion multi-équipes) et des offres entreprise. L'agent, la LAPI et les bouncers principaux sont gratuits sans limitation du nombre de serveurs ou d'IP bannies.

CrowdSec peut-il remplacer un pare-feu hardware ou un WAF ?

CrowdSec est un IPS (Intrusion Prevention System) comportemental basé sur les logs, non un pare-feu réseau ni un WAF à proprement parler. Il complète ces solutions sans les remplacer. Le bouncer firewall agit au niveau iptables/nftables, ce qui est efficace, mais il reste un outil de sécurité applicative comportementale. Pour une défense en profondeur, utilisez CrowdSec conjointement avec un firewall réseau (hardware ou cloud) et un WAF comme ModSecurity ou Cloudflare WAF.

Comment CrowdSec gère-t-il les faux positifs ?

CrowdSec propose plusieurs mécanismes : les whitelists par IP/CIDR/expression, les scénarios en mode simulation (détection sans blocage), et des seuils configurables dans les scénarios. La communauté maintient également les scénarios officiels avec des paramètres calibrés pour minimiser les faux positifs. En cas de doute, la console cloud permet d'inspecter chaque décision et ses raisons avant de la valider.

Quelle est la différence entre un ban et un captcha avec CrowdSec ?

CrowdSec propose plusieurs types de remédiation dans ses profils : ban (blocage total), captcha (présentation d'un CAPTCHA pour les IP suspectes), et throttle (limitation de débit). Le type captcha nécessite un bouncer compatible (nginx bouncer, HAProxy bouncer) qui peut injecter une page CAPTCHA dans la réponse HTTP. C'est particulièrement utile pour les IP avec un faible score de confiance qui pourraient être de faux positifs (VPN légitimes, Tor sorties).

CrowdSec fonctionne-t-il avec les conteneurs Docker ?

Oui, et c'est l'un de ses points forts. CrowdSec propose un mode de lecture des logs Docker (lecture directe des logs de conteneurs via l'API Docker ou les fichiers JSON), des images Docker officielles pour déployer l'agent et la LAPI dans des conteneurs, et un bouncer Docker natif. Pour les environnements Kubernetes, un Helm chart officiel déploie automatiquement des DaemonSets pour la collecte de logs et des bouncers réseau.