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

CrowdSec protège plus de 500 000 serveurs dans 180 pays en 2026 et partage en temps réel une liste de blocage collaborative — quand un serveur détecte une attaque SSH brute-force depuis une IP, cette IP est immédiatement signalée à tous les autres membres de la communauté. Cette intelligence collective représente un avantage structurel sur les solutions traditionnelles comme fail2ban, qui n'apprennent que de leur propre expérience. Ce guide couvre l'installation complète de CrowdSec sur Linux, la configuration des bouncers (firewall, nginx, Traefik), l'intégration avec la console cloud, et les scénarios de détection avancée pour protéger un serveur exposé en production.

Qu'est-ce que CrowdSec et en quoi diffère-t-il de fail2ban ?

CrowdSec est un IPS (Intrusion Prevention System) comportemental open-source qui analyse les logs système, réseau et applicatifs pour détecter des patterns d'attaque et prendre des décisions de blocage collaboratives. La documentation officielle CrowdSec couvre l'ensemble de l'architecture et des scénarios disponibles. Il est écrit en Go, distribué sous licence MIT, et maintenu par la société française CrowdSec SAS — ce qui en fait l'un des rares outils de sécurité open-source dont le développement principal est porté par une entreprise française.

La différence fondamentale avec fail2ban est architecturale : fail2ban est monolithique (détecte et bloque dans le même processus, parsant les logs en temps réel) et local (n'apprend que de ses propres logs). CrowdSec découple la détection du blocage, utilise une file de messages interne pour le parsing asynchrone, et partage les décisions de blocage avec la communauté mondiale via son CTI (Cyber Threat Intelligence) cloud. Une IP qui attaque un serveur CrowdSec en Allemagne est bloquée préemptivement sur votre serveur parisien dans les minutes qui suivent.

Installation de CrowdSec sur Debian/Ubuntu

L'installation de CrowdSec sur une distribution Debian/Ubuntu se fait via le dépôt officiel. Ajoutez la clé GPG et le dépôt, puis installez le paquet crowdsec. L'agent démarre automatiquement au boot via systemd.

Commandes d'installation :

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

Après installation, CrowdSec scanne automatiquement les services actifs sur le serveur et configure les parsers et scénarios appropriés. Si Apache, nginx, sshd et postfix sont actifs, les collections correspondantes sont suggérées dans la sortie d'installation. Listez les collections disponibles avec cscli hub list et installez les manquantes avec cscli collections install crowdsecurity/nginx.

Retour terrain : Sur un VPS OVH exposé directement sur Internet sans pare-feu cloud en amont, CrowdSec a détecté et bloqué 847 IPs distinctes dans les premières 24h après installation — majoritairement des scanners SSH en provenance de Chine, Russie et Brésil. Parmi ces IPs, 73 % étaient déjà dans la liste de blocage collaborative CrowdSec avant même d'avoir attaqué ce serveur spécifique. La liste collaborative a donc bloqué préemptivement des attaquants qui n'avaient pas encore frappé localement.

Configuration des bouncers : iptables et nftables

Le bouncer est le composant qui traduit les décisions de blocage CrowdSec en actions réseau effectives. Sans bouncer, CrowdSec détecte les attaques mais ne bloque rien — il journalise uniquement. Le bouncer firewall (crowdsec-firewall-bouncer) est le plus couramment déployé : il ajoute les IPs banies dans iptables ou nftables.

Installation du bouncer firewall :

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

Le bouncer s'authentifie auprès du moteur CrowdSec local via une API key générée automatiquement à l'installation (stockée dans /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml). Il interroge l'API locale toutes les secondes pour récupérer les nouvelles décisions de blocage et les applique dans nftables. Les règles nftables créées par le bouncer sont dans une table dédiée (crowdsec) — elles n'interfèrent pas avec vos règles nftables existantes.

Vérifiez que le bouncer est actif et communique avec le moteur : sudo cscli bouncers list doit afficher le bouncer avec son statut "valid". sudo cscli decisions list affiche les IPs actuellement bloquées avec la durée et le scénario déclencheur.

Bouncer nginx et Traefik : protection applicative

Pour les services web, les bouncers nginx et Traefik permettent de bloquer directement au niveau du proxy inverse — les requêtes des IPs banuées reçoivent un code 403 avant même d'atteindre l'application. C'est plus fin que le blocage réseau (iptables) qui coupe la connexion TCP entière, y compris pour les autres services qui pourraient légitimement utiliser cette IP.

Le bouncer nginx (crowdsec-nginx-bouncer) s'installe comme module nginx et consulte l'API CrowdSec locale à chaque requête. Il supporte le challenge CAPTCHA (via hCaptcha) en plus du blocage direct — une IP suspecte mais pas confirmée reçoit un CAPTCHA, une IP bannie reçoit un 403. Cette graduation est configurable dans /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf.

Pour Traefik (très populaire en environnements conteneurisés), le middleware CrowdSec est disponible sous forme de plugin Traefik officiel. Il s'intègre dans la configuration YAML de Traefik et supporte les mêmes actions (block, captcha, redirect). En environnement Docker/Kubernetes, cette intégration permet de protéger l'ensemble des services exposés via Traefik sans modifier chaque service individuellement.

Scénarios de détection : comprendre et personnaliser

Les scénarios CrowdSec sont des fichiers YAML qui définissent les patterns d'attaque à détecter. Ils utilisent un algorithme de Leaky Bucket (seau percé) : chaque événement versé dans le bucket incrémente un compteur, le compteur décroit naturellement avec le temps, et si le compteur dépasse un seuil configuré, une décision de blocage est émise.

Exemples de scénarios installés par défaut :

• crowdsecurity/ssh-bf : détecte les brute-force SSH — 5 échecs d'authentification en 120 secondes → ban 4h.
• crowdsecurity/http-bad-user-agent : détecte les User-Agents de scanners connus (sqlmap, Nikto, Hydra) → ban immédiat.
• crowdsecurity/http-probing : détecte les scans de répertoires (404 excessifs en peu de temps) → ban 24h.
• crowdsecurity/iptables-scan-multi-ports : détecte les scans de ports → ban 24h.

Pour personnaliser un scénario, copiez le fichier YAML de base dans /etc/crowdsec/scenarios/, modifiez les seuils et rechargez le moteur. Par exemple, durcir la détection brute-force SSH à 3 tentatives (au lieu de 5) :

capacity: 3
leakspeed: "10m"
duration: "24h"
labels:
  service: ssh
  type: bruteforce

Intégration avec la console cloud CrowdSec

La console cloud CrowdSec (app.crowdsec.net) permet de centraliser la supervision de plusieurs instances, de visualiser les attaques en temps réel sur une carte mondiale, de gérer les listes de blocage et d'accéder aux métriques globales. L'inscription est gratuite et l'intégration s'effectue en quelques commandes.

Pour connecter votre instance, générez un token dans la console (Settings → Enrollment Keys) et exécutez : sudo cscli console enroll [TOKEN]. L'instance apparaît dans la console dans les 60 secondes. La console affiche les décisions en temps réel, les scénarios déclenchés, les IPs les plus actives, et des statistiques d'attaque par pays et par type.

La fonctionnalité CTI (Cyber Threat Intelligence) de la console permet de consulter la réputation de n'importe quelle IP dans la base de données collaborative : combien de serveurs CrowdSec l'ont détectée, quels scénarios elle a déclenchés, depuis quand elle est active et quelle confiance lui est accordée. C'est un outil de triage rapide lors d'une réponse à incident — vérifiez en secondes si une IP suspecte dans vos logs est connue de la communauté.

CrowdSec en environnement Docker et Kubernetes

CrowdSec supporte nativement les environnements conteneurisés. L'image officielle Docker (crowdsecurity/crowdsec) peut être déployée comme conteneur dans votre stack et recevoir les logs des autres conteneurs via un volume partagé ou le socket Docker.

En Kubernetes, CrowdSec se déploie comme DaemonSet — une instance par nœud — et le bouncer s'intègre avec le NetworkPolicy controller ou l'ingress controller (nginx-ingress, Traefik). Le Helm chart officiel CrowdSec simplifie le déploiement et supporte la configuration via values YAML. Pour les clusters Kubernetes exposés, cette configuration est complémentaire d'un durcissement infrastructure — voir notre guide sur le hardening VMware/ESXi pour les couches de virtualisation sous-jacentes.

Métriques, alertes et intégration SIEM

CrowdSec expose des métriques Prometheus sur le port 6060 par défaut, consultables via curl http://localhost:6060/metrics. Ces métriques couvrent : nombre de requêtes parsées par source, nombre de scénarios déclenchés, nombre de décisions émises, et latence des bouncers. L'intégration avec Prometheus + Grafana permet de construire des dashboards opérationnels et des alertes sur des conditions anormales (pic soudain de déclenchements d'un scénario = attaque en cours).

Pour l'intégration avec un SIEM, CrowdSec peut émettre des événements via Syslog ou via un plugin de forwarding. Les logs sont en format JSON structuré — facilement ingestés par Wazuh, Elastic ou Splunk. En corrélant les événements CrowdSec avec les logs SSH, nginx et système dans votre SIEM, vous pouvez détecter des patterns d'attaque multi-vecteurs qu'un seul outil ne verrait pas : un attaquant qui échoue sur SSH, pivote vers le scan HTTP, puis tente un accès à une API — une chaîne visible seulement avec la corrélation. Voir notre guide complet sur Wazuh SIEM/XDR pour l'architecture de corrélation.

Bonnes pratiques opérationnelles pour CrowdSec en production

Quelques règles qui font la différence entre un CrowdSec qui protège vraiment et un CrowdSec qui génère du bruit :

• Whitelister les IPs de monitoring : ajoutez systématiquement les IPs de vos outils de monitoring (Datadog Agent, Prometheus scraper, Nagios) dans /etc/crowdsec/parsers/s02-enrich/whitelists.yaml. Sans whitelist, les sondes de monitoring seront détectées comme des scanners.
• Vérifier régulièrement les faux positifs : consultez cscli decisions list quotidiennement les premières semaines. Un ISP légitime dont toute la plage IP est bannie crée des incidents de support.
• Maintenir le hub à jour : cscli hub update && cscli hub upgrade toutes les semaines pour bénéficier des nouveaux scénarios et parsers.
• Tester avant de déployer un nouveau scénario : utilisez cscli explain --log /var/log/nginx/access.log --type nginx pour simuler le parsing sans déclencher de décisions réelles.
• Durée de ban adaptée au risque : SSH brute-force → 48h minimum ; scan HTTP → 24h ; User-Agent malveillant → 7 jours. Des durées trop courtes permettent à l'attaquant de repartir rapidement.

Pour une défense en profondeur complète, CrowdSec se combine naturellement avec un durcissement système préalable. Notre guide sur le hardening Proxmox couvre la sécurisation de la couche hyperviseur, et notre guide Escalade de Privilèges Linux traite le durcissement post-compromission — CrowdSec est la première ligne, le hardening est la défense en profondeur.

Questions fréquentes sur CrowdSec Linux

CrowdSec peut-il remplacer un pare-feu réseau ?

Non — CrowdSec est un complément, pas un substitut. Un pare-feu réseau (iptables, nftables, OPNsense) filtre le trafic par port, protocole et IP de façon statique. CrowdSec analyse les comportements applicatifs et prend des décisions dynamiques basées sur des patterns. Les deux sont nécessaires : le firewall bloque les ports non utilisés, CrowdSec bloque les IPs qui abusent des ports autorisés. La combinaison est nettement supérieure à l'un ou l'autre seul.

CrowdSec fonctionne-t-il derrière un reverse proxy ou un load balancer ?

Oui, mais avec une configuration supplémentaire. Par défaut, CrowdSec voit l'IP du reverse proxy (ex. Cloudflare, nginx, HAProxy) dans les logs, pas l'IP du client réel. Configurez le parser pour extraire l'IP depuis les en-têtes X-Forwarded-For ou CF-Connecting-IP. La collection crowdsecurity/nginx gère nativement cet en-tête si votre nginx est configuré pour le passer via proxy_set_header X-Real-IP $remote_addr.

Comment désactiver temporairement un ban CrowdSec sans désinstaller ?

Utilisez cscli decisions delete --ip [adresse-ip] pour supprimer immédiatement le ban d'une IP spécifique. Pour supprimer tous les bans actifs : cscli decisions delete --all. Pour whitelister définitivement une IP : ajoutez-la dans /etc/crowdsec/parsers/s02-enrich/whitelists.yaml et rechargez le moteur avec sudo systemctl reload crowdsec. Le whitelist permanent prévient que la même IP soit bannie à nouveau par les scénarios.

CrowdSec peut-il détecter les attaques applicatives (SQLi, XSS) ?

Partiellement. CrowdSec analyse les logs nginx/Apache et peut détecter des patterns d'attaque dans les URLs (SQLi, path traversal) via des scénarios basés sur des expressions. Mais pour une détection applicative complète, il doit être combiné avec un WAF dédié comme ModSecurity ou le WAF Cloudflare. CrowdSec est fort sur la détection comportementale (qui attaque, depuis où, à quelle fréquence) — le WAF est fort sur la détection de payload (quoi exactement dans la requête). Les deux sont complémentaires.

Quelle est l'empreinte mémoire de CrowdSec sur un VPS 2 Go ?

Le moteur CrowdSec consomme entre 60 et 150 Mo de RAM selon le nombre de scénarios actifs et le volume de logs parsés. Le bouncer firewall ajoute 10-20 Mo. Sur un VPS 2 Go, l'empreinte est donc de 5 à 8 % de la mémoire disponible — comparable à un nginx chargé. Sur des VPS 512 Mo, la cohabitation avec un serveur web et une base de données peut être tendue. Pour les recommandations générales de durcissement des serveurs Linux en production, le guide ANSSI Linux reste la référence française : surveillez la mémoire avec cscli metrics pendant les premières 24h.

CrowdSec et la protection contre les attaques par force brute HTTP

Les attaques par force brute ne se limitent pas à SSH. Les formulaires d'authentification web, les APIs REST avec token, et les interfaces d'administration CMS (WordPress, Drupal, Joomla) sont des cibles permanentes de brute-force HTTP. CrowdSec dispose de scénarios dédiés à ces vecteurs, mais leur configuration demande plus de finesse que la détection SSH qui repose sur des logs structurés.

Le scénario crowdsecurity/http-bf-wordpress_bf détecte les tentatives de brute-force sur les pages de login WordPress (/wp-login.php) : plus de 10 tentatives POST sur 60 secondes → ban 24h. Ce scénario s'appuie sur les codes de réponse HTTP (302 redirect vers wp-admin en cas de succès vs réaffichage de wp-login.php en cas d'échec) pour distinguer les vrais logins des tentatives. Une configuration plus agressive (5 tentatives / 30 secondes) est recommandée si votre WordPress est exposé sans protection supplémentaire.

Pour les APIs REST avec authentification Bearer ou Basic Auth, aucun scénario pré-construit ne convient universellement — les patterns de log varient trop entre frameworks. La meilleure approche est de créer un scénario custom qui détecte les codes HTTP 401 répétés sur les chemins d'API. Ce scénario custom peut ensuite être partagé sur le Hub CrowdSec pour bénéficier à la communauté et être maintenu collectivement.

CrowdSec comme alternative collaborative aux honeypots

Les honeypots sont des systèmes délibérément vulnérables destinés à attirer et observer les attaquants. CrowdSec remplit une fonction complémentaire : il transforme chaque serveur en capteur d'attaque qui contribue à la CTI collective. Contrairement à un honeypot isolé qui observe uniquement les attaquants qui le trouvent, le réseau CrowdSec capture les comportements d'attaque observés sur des milliers de serveurs réels en production.

La liste de blocage collaborative CrowdSec (Community Blocklist) est générée en temps quasi-réel à partir des signaux de tous les membres. En 2026, cette liste contient en permanence entre 50 000 et 150 000 IPs actives — des scanners, des botnets, des infrastructures d'attaque connues. Elle est disponible via l'API CrowdSec ou via les intégrations directes avec les bouncers. Complémentaire aux listes de réputation IP commerciales (AbuseIPDB, Spamhaus), elle se distingue par sa fraîcheur : une IP qui démarre une campagne d'attaque à 14h est dans la liste à 14h05, pas demain matin. Pour approfondir les mécanismes de détection précoce des attaquants, voir notre guide sur les honeypots et déception.

Comparaison CrowdSec, Wazuh et Suricata : quand utiliser quoi ?

CrowdSec, Wazuh et Suricata couvrent des périmètres différents et sont complémentaires plutôt que concurrents. CrowdSec est un IPS comportemental focalisé sur la détection à partir de logs applicatifs et la réponse automatique via bouncers. Wazuh est un SIEM/XDR qui ingère et corrèle des événements de multiples sources (logs, FIM, OSCAP, Vulnerability Scanner). Suricata est un IDS/IPS réseau qui inspecte les paquets en temps réel au niveau réseau.

La combinaison optimale pour un serveur Linux en production : Suricata sur la carte réseau (détection réseau basse couche), CrowdSec sur les logs applicatifs (détection comportementale haute couche, blocage IP), et Wazuh pour la corrélation et l'alerte centralisée. Cette architecture en couches couvre tous les vecteurs d'attaque sans redondance : Suricata voit ce que CrowdSec manque (trafic chiffré non-HTTP, attaques réseau basses couches), CrowdSec voit ce que Suricata manque (comportements applicatifs légitimes qui deviennent malveillants avec le temps), et Wazuh corrèle les deux pour des alertes contextualisées.

Maintenir CrowdSec à jour : stratégie de mise à niveau

CrowdSec publie des mises à jour régulières du moteur (nouvelles fonctionnalités, correctifs de performance) et des mises à jour fréquentes du Hub (nouveaux parsers, nouveaux scénarios, amélioration des règles existantes). Le moteur est géré via le gestionnaire de paquets système (apt upgrade crowdsec), tandis que le Hub se met à jour via cscli hub upgrade. Automatisez cette mise à jour dans un cron hebdomadaire — les nouvelles versions du Hub apportent régulièrement des corrections qui réduisent les faux positifs et améliorent la précision de détection. Sur les environnements à haute disponibilité (plusieurs serveurs CrowdSec), mettez à jour un nœud, validez le comportement pendant 24h, puis mettez à jour les suivants.