CrowdSec : un IPS collaboratif pour protéger un serveur web

Point de départ : de Fail2ban à CrowdSec

Vous connaissez peut-être Fail2ban (mis en œuvre dans le cours Nextcloud) : il surveille les journaux d’un service (SSH, serveur web…), repère par des expressions régulières les tentatives suspectes répétées et bannit l’adresse IP fautive en ajoutant une règle au pare-feu local. C’est simple, léger et efficace — mais chaque serveur se défend seul, avec ce qu’il voit.

CrowdSec reprend exactement cette idée de départ (lire les journaux, détecter, bannir), puis la prolonge : séparer la détection du blocage, et surtout mutualiser ce que voient des milliers de serveurs.

Critère	Fail2ban	CrowdSec
Principe	Lit les journaux, détecte, bannit	Identique au départ : lit les journaux, détecte, décide
Langage / licence	Python, GPL v2	Go (plus performant sur de gros volumes), MIT
Règles de détection	Filtres à base d’expressions régulières, regroupés dans des jails	Parseurs et scénarios en YAML, regroupés en collections installables depuis le Hub
Blocage	Actions intégrées : règle iptables/nftables sur la machine	Bouncers séparés : pare-feu, Nginx, Cloudflare, captcha…, éventuellement sur une autre machine
Portée	Un serveur = une instance isolée	Plusieurs serveurs peuvent partager une même API locale
Renseignement	Uniquement ce que le serveur voit lui-même	Liste communautaire : on bloque des attaquants signalés ailleurs, avant même qu’ils ne vous visent
Bannissement par défaut	10 minutes (bantime)	4 heures
Adresses privées	Seule la boucle locale est ignorée (ignoreip)	Toutes les plages privées sont ignorées par défaut
Administration	fail2ban-client	cscli

Action	Fail2ban	CrowdSec
Voir les bannis	fail2ban-client status sshd	cscli decisions list
Débannir	fail2ban-client set sshd unbanip X.X.X.X	cscli decisions delete --ip X.X.X.X
Bannir à la main	fail2ban-client set sshd banip X.X.X.X	cscli decisions add --ip X.X.X.X

IDS et IPS : de quoi parle-t-on ?

Les systèmes de détection d’intrusion (IDS) analysent le trafic réseau ou les journaux pour repérer des signes d’attaque. Les systèmes de prévention d’intrusion (IPS) réalisent la même analyse, mais peuvent en plus bloquer ce qu’ils jugent malveillant, ce qui permet de stopper l’attaque en cours.

Tous deux comparent l’activité observée à une base de menaces connues (signatures) et/ou à des modèles de comportement. La différence tient à ce qui se passe ensuite : l’IDS est un système de surveillance, l’IPS est un système de contrôle.

	IDS (Intrusion Detection System)	IPS (Intrusion Prevention System)
Rôle	Surveiller et alerter	Surveiller et bloquer
Position	En dérivation (copie du trafic, journaux)	En coupure, comme un pare-feu, entre l’extérieur et le réseau interne
Action	Aucune action automatique : un humain ou un autre outil doit prendre le relais	Rejette automatiquement les paquets ou requêtes correspondant à une menace
Point fort	Excellent outil d’analyse a posteriori pour l’équipe de réponse à incident (CSIRT)	Réaction immédiate, sans intervention humaine
Risque principal	Volume d’alertes à traiter (« fatigue d’alerte »)	Faux positif bloquant : un utilisateur légitime est banni

De nombreux éditeurs intègrent aujourd’hui ces fonctions dans des pare-feu dits UTM (Unified Threat Management) ou NGFW (Next-Generation Firewall), qui réunissent filtrage, IDS/IPS, antivirus et filtrage web dans un même équipement — c’est le cas de pfSense avec les paquets Suricata ou Snort.

Ce qu’apportent les IDS/IPS à une stratégie de cybersécurité

• Automatisation : ils fonctionnent en grande partie seuls et s’intègrent facilement aux outils de sécurité existants.
• Conformité : ils aident à démontrer que des mesures de protection sont en place (contrôles du CIS, exigences NIS 2, ISO 27001) et produisent des traces d’audit utiles lors d’une enquête.
• Application de la politique de sécurité : ils sont configurables pour faire respecter des règles internes au niveau du réseau (par exemple, bloquer un VPN non autorisé).

CrowdSec : présentation

CrowdSec est une solution de sécurité open source, gratuite dans sa version de base et française. Elle reprend le principe de Fail2ban — lire les journaux, détecter un comportement malveillant, bannir l’adresse IP — en le modernisant sur trois points :

• La séparation détection / blocage : le moteur décide, des composants spécialisés appliquent la décision.
• Le partage communautaire : chaque instance signale les adresses qu’elle a bannies à une API centrale. CrowdSec agrège ces signalements et redistribue une liste de blocage communautaire. Un mécanisme de réputation évite qu’une adresse soit bannie partout dès le premier signalement.
• Le Hub : les règles de détection (parseurs, scénarios, collections) sont maintenues par CrowdSec et la communauté, et s’installent en une commande.

Architecture

Depuis la version 1.0, tous les composants communiquent via une API REST locale (LAPI). Seule cette API accède à la base de données, ce qui rend les composants indépendants les uns des autres.

Composant	Rôle
Security Engine (agent)	Lit les journaux (acquisition), les découpe (parseurs) et les confronte aux scénarios. Si un scénario se déclenche, il crée une alerte et une décision.
API locale (LAPI)	Stocke alertes et décisions, et les distribue aux composants de remédiation.
Composants de remédiation (bouncers)	Interrogent la LAPI et appliquent les décisions : blocage dans Nginx, dans le pare-feu (nftables), captcha, etc.
API centrale (CAPI)	Reçoit les signalements de toutes les instances et diffuse la liste de blocage communautaire.
cscli	Outil en ligne de commande pour tout piloter : collections, décisions, alertes, bouncers, métriques.
Console CrowdSec	Interface web (app.crowdsec.net) pour visualiser alertes et décisions d’une ou plusieurs instances.

Le schéma de principe se lit ainsi : les agents détectent → la LAPI centralise → les bouncers bloquent, tandis que la LAPI échange avec la CAPI (envoi des signalements, réception de la liste communautaire).

Modèle économique : l’« open core »

CrowdSec est une entreprise, pas une association : elle doit financer son développement. Elle applique le modèle de l’open core : le cœur du produit est gratuit et open source, et l’éditeur vend des services construits autour. Ce support n’utilise que la partie gratuite, qui suffit pour protéger un serveur.

	Version communautaire (gratuite)	Offres payantes
Moteur, cscli, bouncers, Hub	Inclus, open source (licence MIT)	Identiques : on paie des services, pas le logiciel
Listes de blocage	Liste communautaire (en échange de vos signalements)	Liste communautaire premium ; listes spécialisées (renseignement sur les menaces, par secteur, par pays, robots d’IA…)
Console web	Nombre d’alertes remontées et durée d’historique limités	Historique étendu, gestion centralisée de plusieurs serveurs et des allowlists, notifications, accès API (Console Premium, facturée par moteur)
Renseignement sur les menaces	Réputation de base via la liste communautaire	API de réputation d’adresses IP, suivi des CVE activement exploitées
Support	Forum, Discord, documentation	Support et correctifs d’urgence, en option

Le point clé est l’effet de réseau : chaque instance gratuite envoie ses signalements à l’API centrale. Plus il y a d’utilisateurs gratuits, plus la base de renseignement de CrowdSec est riche… et c’est précisément cette base, affinée et enrichie, qui est vendue aux entreprises. Les utilisateurs gratuits ne sont pas de simples clients non payants : ce sont eux qui produisent la matière première.

Le laboratoire

Machine	Rôle	Configuration
SRV-WEB	Cible	Debian 13 (Trixie), Nginx opérationnel, accès SSH
KALI	Attaquant	Kali Linux avec Nikto et curl (préinstallés)
Réseau	—	Les deux VM sur un réseau isolé de l’hyperviseur, joignables entre elles

Installation de CrowdSec sur Debian 13

Plusieurs méthodes existent : paquet des dépôts Debian, dépôt officiel CrowdSec, image Docker… On retient le dépôt officiel, car les paquets Debian ont souvent du retard et, pour un outil de sécurité, la fraîcheur des règles compte autant que celle du binaire.

Préparer le serveur

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y nginx curl
systemctl status nginx --no-pager

Ajouter le dépôt CrowdSec

La documentation propose un script qui ajoute le dépôt et sa clé de signature. Plutôt que de l’exécuter « à l’aveugle », on le télécharge, on le lit, puis on l’exécute :

curl -fsSL https://install.crowdsec.net -o install-crowdsec.sh
less install-crowdsec.sh        # lire avant d'exécuter !
sudo sh install-crowdsec.sh
apt-cache policy crowdsec       # vérifier que la version vient du dépôt CrowdSec

Installer le moteur

sudo apt install -y crowdsec

Pendant l’installation, CrowdSec analyse la machine pour repérer les services qu’il sait surveiller. Il détecte ici le système Linux, SSH et les journaux de Nginx (/var/log/nginx/access.log et error.log), crée les fichiers d’acquisition correspondants dans /etc/crowdsec/acquis.d/ et installe les collections associées.

sudo cscli collections list              # collections installées
sudo systemctl status crowdsec --no-pager
# si la collection nginx est absente :
sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec

Élément du Hub	Rôle	Exemple
Parseur	Découpe une ligne de journal en champs exploitables	crowdsecurity/nginx-logs
Scénario	Décrit un comportement malveillant (seuils, fenêtres de temps)	crowdsecurity/http-probing
Collection	Regroupe parseurs et scénarios pour un service	crowdsecurity/nginx

Adapter au labo (adresses privées)

sudo cscli parsers remove crowdsecurity/whitelists --force
sudo systemctl reload crowdsec

Vérifiez enfin que CrowdSec lit bien les journaux Nginx : la section Acquisition Metrics doit afficher des lignes lues pour /var/log/nginx/access.log.

sudo cscli metrics

Premier scan Nikto : détection sans blocage

Nikto est un scanner de vulnérabilités web open source : il recherche fichiers sensibles, défauts de configuration, en-têtes de sécurité manquants, etc. Il s’agit d’une reconnaissance, pas d’une exploitation — mais c’est souvent la première étape d’une attaque réelle.

État initial

Sur SRV-WEB, listez les décisions actives, c’est-à-dire les adresses que CrowdSec a décidé de bloquer :

sudo cscli decisions list

Le résultat doit être No active decisions. Ajoutez maintenant l’option --all : apparaissent les adresses issues de la liste communautaire (origine CAPI), construite à partir des signalements de toutes les instances CrowdSec.

sudo cscli decisions list --all | head -20

Lancer le scan depuis KALI

nikto -h http://IP_SRV_WEB

Observer la réaction de CrowdSec

sudo cscli decisions list
sudo cscli alerts list
sudo cscli alerts inspect ID_ALERTE -d

L’adresse de KALI apparaît avec une décision ban d’une durée de 4 heures (valeur par défaut). La liste des alertes montre les scénarios déclenchés : http-probing, http-sensitive-files, http-path-traversal-probing, http-bad-user-agent, http-crawl-non_statics…

Avant de passer à la suite, supprimez cette décision pour repartir d’un état propre :

sudo cscli decisions delete --ip IP_KALI

Mettre en place un composant de remédiation

Pour qu’une décision soit appliquée, CrowdSec s’appuie sur des composants de remédiation, historiquement appelés bouncers. Chacun interroge régulièrement la LAPI et applique les décisions à son niveau : refus de la requête, présentation d’un captcha, suppression des paquets…

Bouncer	Niveau d’action	Effet pour l’attaquant	Intérêt
Nginx (crowdsec-nginx-bouncer)	Serveur web (module Lua)	Page 403 Forbidden ou captcha	Visible et pédagogique ; protège seulement le site
Pare-feu (crowdsec-firewall-bouncer-nftables)	Noyau Linux (nftables)	Paquets ignorés : plus aucun service ne répond	Protège toute la machine (SSH compris)
Autres	Cloudflare, Traefik, HAProxy, WordPress…	Variable	Bloquer au plus près de l’application ou en amont

Installer le bouncer Nginx

Il n’est plus nécessaire de télécharger une archive depuis GitHub : le bouncer est disponible dans le dépôt CrowdSec déjà configuré. Le paquet installe ses dépendances (lua5.1, libnginx-mod-http-lua…) et s’enregistre automatiquement auprès de la LAPI avec sa propre clé d’API.

sudo apt install -y crowdsec-nginx-bouncer
sudo cscli bouncers list             # le bouncer doit apparaître
sudo nginx -t && sudo systemctl reload nginx

Si le bouncer n’apparaît pas dans la liste, il faut l’enregistrer à la main : on génère une clé d’API, puis on la reporte dans le paramètre API_KEY du fichier /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf, avant de recharger Nginx.

sudo cscli bouncers add nginx-bouncer     # affiche la clé une seule fois
sudo nano /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf   # API_KEY=CLE
sudo nginx -t && sudo systemctl reload nginx

Second scan : CrowdSec passe à l’action

Depuis KALI, vérifiez d’abord que le site répond normalement :

curl -I http://IP_SRV_WEB       # attendu : HTTP/1.1 200 OK

Relancez le scan, puis, pendant ou juste après, la même requête curl :

nikto -h http://IP_SRV_WEB
curl -I http://IP_SRV_WEB       # attendu : HTTP/1.1 403 Forbidden

Le code 403 Forbidden indique un accès refusé : le bouncer Nginx applique la décision. Comptez quelques secondes : le scénario doit d’abord se déclencher, puis le bouncer consulte la LAPI (à chaque requête avec un court cache en mode live, à intervalle régulier en mode stream) ; le blocage n’est donc pas instantané. Confirmez côté serveur avec sudo cscli decisions list : l’adresse de KALI est bannie pour 4 heures. Cette liste n’affiche que la dernière alerte par adresse alors que plusieurs décisions peuvent exister : decisions delete --ip les supprime toutes. Les journaux Nginx (/var/log/nginx/error.log) mentionnent d’ailleurs le refus prononcé par CrowdSec.

Gérer les décisions manuellement

Besoin	Commande
Débannir une adresse (faux positif)	sudo cscli decisions delete --ip X.X.X.X
Bannir manuellement (4 h par défaut)	sudo cscli decisions add --ip X.X.X.X
Bannir 24 h avec un motif	sudo cscli decisions add --ip X.X.X.X --duration 24h --reason "scan Nikto"
Bannir une plage entière	sudo cscli decisions add --range 203.0.113.0/24

Une décision ajoutée manuellement porte l’origine cscli et, sans motif précisé, une raison du type manual ‘ban’ from ….

Ne pas se bannir soi-même : les listes d’autorisation

Depuis la version 1.6.8, les allowlists permettent de déclarer, directement avec cscli, les adresses qui ne doivent jamais être bannies — typiquement le poste d’administration. Les modifications sont prises en compte immédiatement.

sudo cscli allowlists create admins -d "Postes d'administration"
sudo cscli allowlists add admins IP_POSTE_ADMIN -d "poste d'administration"
sudo cscli allowlists inspect admins

Visualiser l’activité

L’ancienne commande cscli dashboard, qui déployait un tableau de bord Metabase dans un conteneur Docker, a été dépréciée puis retirée (version 1.7.0). CrowdSec la jugeait trop limitée, et de nombreuses installations n’étaient ni mises à jour ni sécurisées alors que l’image Metabase faisait l’objet de vulnérabilités (CVE).

Outil	Usage
sudo cscli metrics	Lignes lues par source, parseurs et scénarios sollicités, activité des bouncers
sudo cscli alerts list / inspect	Historique et détail des alertes
Console CrowdSec (app.crowdsec.net)	Interface web officiellement supportée : alertes, décisions, abonnement à des listes de blocage supplémentaires
Prometheus + Grafana	Alternative auto-hébergée : CrowdSec expose des métriques au format Prometheus

Pour rattacher une instance à la Console, on crée un compte, on récupère la clé d’enrôlement, puis :

sudo cscli console enroll CLE_ENROLEMENT
# dans la Console : Engines > sélectionner l'instance > Accept enroll
sudo systemctl restart crowdsec
sudo cscli console status      # CAPI authentifiée, instance « enrolled »

Maintenir CrowdSec à jour

Les règles évoluent en permanence : un IPS non mis à jour perd rapidement de son efficacité.

sudo cscli hub update        # récupère l'index des parseurs, scénarios, collections
sudo cscli hub upgrade       # met à jour les éléments installés
sudo apt update && sudo apt upgrade   # met à jour le moteur et les bouncers

Une fois les essais terminés, réactivez la protection des adresses privées retirée à l’étape Adapter au labo :

sudo cscli parsers install crowdsecurity/whitelists
sudo systemctl reload crowdsec

Aller plus loin

• Protéger SSH : la collection crowdsecurity/sshd est installée par défaut ; associée au bouncer pare-feu, elle bloque les attaques par force brute.
• Composant AppSec : CrowdSec propose un module de type WAF qui inspecte les requêtes HTTP en temps réel (règles virtuelles contre des CVE connues), en complément de l’analyse des journaux. Depuis la version 1.8, il peut aussi soumettre les visiteurs à une détection de robots (page de défi), désactivée par défaut : à tester avant de l’activer, car elle s’applique à tous les visiteurs.
• Mode simulation : sudo cscli simulation enable <scénario> génère des alertes sans bannir — utile pour régler un scénario avant de l’activer en production.

Ressources

• Documentation officielle : docs.crowdsec.net
• Hub (parseurs, scénarios, bouncers) : app.crowdsec.net/hub
• Code source : github.com/crowdsecurity/crowdsec
• Sur ce site : Pare-feu et règles de filtrage, Cybersécurité 4 — Détection et réponse à incident, Supervision informatique, et la veille technologique, qui suit les nouvelles versions de CrowdSec.

Synthèse

Mémento cscli

Commande	Rôle
cscli collections list	Collections installées
cscli metrics	Vérifier l’acquisition des journaux et l’activité
cscli decisions list [--all]	Décisions actives (locales [+ communautaires])
cscli decisions add / delete --ip X	Bannir / débannir manuellement
cscli alerts list / inspect ID -d	Alertes et détail
cscli bouncers list	Composants de remédiation enregistrés
cscli allowlists create / add	Adresses à ne jamais bannir
cscli hub update / upgrade	Mise à jour des règles
cscli capi status	Vérifier la connexion à l’API centrale (partage communautaire)