Protéger un serveur Linux avec CrowdSec : le guide pour bien débuter

CrowdSec est une solution open source et française qui se présente comme une alternative collaborative à Fail2ban. Son objectif : protéger vos serveurs via la détection et le blocage des adresses IP malveillantes. Cet article présente le fonctionnement de CrowdSec et son installation sur Linux.

Version originale de l'article : 7 juillet 2021.

Différences entre Fail2ban et CrowdSec

Vous connaissez surement Fail2Ban, un outil qui permet d'analyser les journaux de votre machine Linux dans le but de bannir les adresses IP correspondantes à des hôtes qui ont des comportements malveillants ou suspects. Par exemple, si une machine effectue de multiples tentatives de connexion en SSH, elle sera bannie au bout d'un certain nombre d'échecs.

Cet outil est conçu pour fonctionner en autonomie : vous avez la main sur la configuration et sur son comportement. Il n'a pas besoin de communiquer avec un service externe pour fonctionner : c'est une différence notable en comparaison de CrowdSec. En effet, CrowdSec a un aspect collaboratif que Fail2ban n'a pas, ce qui n'est pas sans rappeler Waze, dans un tout autre domaine.

Voici l'idée globale qui se cache derrière ce système de détection et de prévention d'intrusions (IDS/IPS) nouvelle génération : si votre machine détecte un comportement malveillant, elle va bannir l'adresse IP à l'origine de l'action. Ce signal sera remonté auprès de la base centralisée de CrowdSec par l'intermédiaire d'une API. L'intérêt étant d'avoir une liste d'adresses IP malveillantes communautaire, gérée par CrowdSec et redistribuée auprès des différentes instances.

Bien sûr, il y a un mécanisme de réputation qui entre en jeu : une adresse IP n'est pas bannie chez tout le monde dès le premier signalement, c'est un peu plus complexe que cela, vous vous en doutez bien : l'algorithme de consensus est là pour éviter les faux positifs. Mais cela veut donc dire que votre instance CrowdSec va bannir "par défaut" des milliers d'adresses IP grâce à cette base alimentée par les instances CrowdSec du monde entier.

Note : les listes noires d'adresses IP malveillantes sont récupérées par l'intermédiaire d'une communication avec la CAPI (CrowdSec API).

Ce fonctionnement est aussi répétable à votre échelle, grâce à l'API locale de CrowdSec. Si vous déployez plusieurs instances, elles peuvent en quelque sorte se synchroniser : si l'une de vos instances bannit une IP, la règle sera répliquée sur vos autres instances.

Voici un tableau comparatif entre Fail2ban et CrowdSec :

Critère	Fail2ban	CrowdSec
Philosophie	Isolé : votre serveur se défend tout seul dans son coin. C'est le comportement natif de cet outil.	Collaboratif : si une IP attaque un voisin, vous êtes protégé avant même d'être visé.
Architecture	Monolithique : analyse et blocage sont un seul processus.	Découplée : l'agent (qui lit les logs) et le Bouncer (qui bloque les adresses IP) sont séparés. Idéal pour protéger plusieurs serveurs via une seule décision.
Langage	Python	Go (Golang)
Remédiation	Niveau réseau : modifie principalement le pare-feu local pour bloquer l'IP (règle iptables).	Multi-niveaux : selon votre configuration, il peut bloquer (règle de firewall), mais aussi présenter un captcha à l'utilisateur ou notifier.
Performance	Peut consommer beaucoup de CPU/RAM si les logs sont très volumineux.	Léger, rapide et capable de traiter des milliers de logs par seconde. Merci Go.
Environnement	Conçu pour des serveurs "Bare Metal" ou des machines virtuelles.	S'adapte à beaucoup de plateformes, de la machine virtuelle à Docker, en passant par Kubernetes, etc... Approche Cloud Native.

Pourquoi faut-il changer ? Avec Fail2Ban, vous attendez que le cambrioleur casse votre fenêtre pour réagir. Avec CrowdSec, votre système sait que ce cambrioleur a cassé une fenêtre deux rues plus loin il y a 5 minutes, alors il verrouille en prévention. Une instance Fail2ban est isolée, c'est ce qui est à la fois une force et une faiblesse : aucune dépendance à un tiers, ce que certains vont privilégier.

Le fonctionnement de CrowdSec

Avant de procéder à l'installation de CrowdSec, prenons un instant pour regarder de plus près son architecture, afin de bien comprendre son fonctionnement. Il est important de comprendre qu'il y a deux composants :

• L'Agent CrowdSec (CrowdSec Security Engine) détecte les menaces, mais il ne bloque pas les adresses IP,
• Les Bouncers appliquent la sanction (blocage firewall, captcha, etc.), c'est donc eux qui appliquent les décisions. Il peut s'agir d'un bouncer qui gère le firewall Linux, qui s'intègre directement à un serveur Web ou directement à un applicatif comme WordPress.

L'agent CrowdSec va lire les journaux en fonction des sources déclarées et configurées, puis en fonction des alertes générées, il décidera d'une action à appliquer sur telle ou telle adresse IP. Pour la détection des comportements malveillants, vous n'avez pas à créer vos propres règles, bien que ce soit possible.

CrowdSec met à disposition de la communauté des collections correspondant à différents services et scénarios d'applications. Certaines sont maintenues par CrowdSec, d'autres par des membres de la communauté. Une collection regroupe plusieurs éléments : la façon de parser les logs et les scénarios d'attaques que le moteur de sécurité peut détecter.

Pour sa configuration, CrowdSec s'appuie sur des fichiers au format YAML (par exemple : acquis.yaml). Un jeu de commandes permet aussi d'afficher facilement la liste des adresses IP bannies, de consulter les alertes, d'installer un nouveau scénario ou encore de déclarer un bouncer. La CLI de CrowdSec est cscli. En complément, vous pouvez inscrire votre instance auprès de la console CrowdSec pour avoir une visibilité globale et précise sur les adresses IP qui s'en prennent à votre machine. Toutefois, la version gratuite de la console CrowdSec a certaines limites.

Installation de CrowdSec sur Debian 13

Pour ce premier article au sujet de CrowdSec et en guise d'introduction, je vous propose de prendre un serveur Linux sous Debian 13 équipé d'un accès SSH. Nous verrons comment protéger l'accès SSH de ce serveur avec CrowdSec.

Je vous recommande d'installer d'abord les paquets de vos services (SSH, Nginx, etc...) avant d'installer CrowdSec. Simplement parce que lors de son installation, CrowdSec détectera ces services et il installera automatiquement les collections utiles pour ces services (notamment pour être capable de lire les journaux de ces services).

Note : même si vous protégez votre serveur avec CrowdSec, cela n'empêche pas d'appliquer les bonnes pratiques en matière de configuration sur les différents services que vous hébergez. Pour le SSH, on peut notamment citer l'utilisation d'un port d'écoute personnalisé, l'authentification par clé publique ou encore le fait de ne pas autoriser le compte root à se connecter en SSH.

Installation du moteur de détection CrowdSec

Commençons par l'installation du moteur de détection de CrowdSec. Pour cela, exécutez la commande ci-dessous pour automatiser l'ajout du dépôt de CrowdSec sur votre machine.

curl -s https://install.crowdsec.net | sudo sh

Ensuite, nous lançons l'installation de CrowdSec :

sudo apt install crowdsec

Lors de l'installation, CrowdSec va analyser votre machine à la recherche de services installés qu'il est capable de prendre en charge. Il va donc adapter sa configuration en conséquence, comme je l'évoquais précédemment.

Sur mon serveur, il y a plusieurs services présents, dont le SSH, mais aussi MariaDB et Apache2. De ce fait, il a créé plusieurs fichiers de configuration lui permettant de parser les logs de ces services. Dans la sortie de la commande d'installation, j'ai pu voir passer ces lignes :

creating /etc/crowdsec/acquis.d/setup.apache2.yaml
creating /etc/crowdsec/acquis.d/setup.linux.yaml
creating /etc/crowdsec/acquis.d/setup.mariadb.yaml
creating /etc/crowdsec/acquis.d/setup.mysql.yaml
creating /etc/crowdsec/acquis.d/setup.sshd.yaml

Si je regarde le contenu du fichier /etc/crowdsec/acquis.d/setup.sshd.yaml correspondant à SSH, je peux voir qu'il sert à déclarer la façon dont CrowdSec doit accéder aux logs SSH. Ici, il va s'appuyer sur journalctl comme source, tandis que parfois la source sera file, si les journaux sont des fichiers plats (comme ceux d'Apache2, par exemple).

Dès à présent, vous pouvez lister les collections CrowdSec présentes sur votre machine. Ce sera l'occasion d'exécuter votre première commande avec la CLI de CrowdSec et de confirmer que le service est opérationnel.

cscli collections list

Enfin, sachez qu'à tout moment vous pouvez relancer le service CrowdSec ou afficher son statut via les commandes habituelles :

sudo systemctl restart crowdsec
sudo systemctl status crowdsec

Passons à la seconde étape : l'installation du composant correspondant à la remédiation.

Installation du bouncer firewall pour Linux

Actuellement, notre instance CrowdSec est capable de détecter les comportements malveillants et de générer des alertes, mais elle ne bloquera pas la moindre adresse IP. C'est normal, il manque le composant de remédiation appelé Bouncer.

Listez les bouncers installés sur votre machine via la commande ci-dessous, vous constaterez que la liste est vide.

sudo cscli bouncers list

──────────────────────────────────────────────────────────────────
 Name  IP Address  Valid  Last API pull  Type  Version  Auth Type
──────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────────────────

Dans le cadre de cet exemple, le bouncer nommé crowdsec-firewall-bouncer-iptables sera installé. En réalité, CrowdSec supporte plusieurs firewalls, dont iptables et nftables (voir cette page).

sudo apt install crowdsec-firewall-bouncer-iptables

Désormais, il y a bien un bouncer CrowdSec installé et actif, connecté au moteur de détection par API. Les deux composants sont sur la même machine, d'où la présence de l'adresse IP 127.0.0.1.

Il est temps de tester l'efficacité de cette instance CrowdSec.

Protéger un accès SSH avec CrowdSec

Le service SSH est actif sur la machine Linux. CrowdSec également, y compris avec le composant de remédiation. En principe, ce que nous venons de faire est suffisant pour détecter et bloquer les adresses IP malveillantes qui auront un comportement détectable par CrowdSec (ce qui dépend des collections installées).

Depuis une machine distante, tentez simplement de vous connecter en SSH à plusieurs reprises en saisissant volontairement des identifiants incorrects.

ssh admin@<ip serveur crowdsec>

Au bout de la 6ème connexion échouée, CrowdSec devrait bannir votre adresse IP. Ce sera visible côté client SSH, car la connexion SSH ne montera plus.

Côté CrowdSec, comment le vérifier ?

Exécutez la commande ci-dessous, elle permet de lister les adresses IP bannies (ou en tout cas celles pour lesquelles une décision s'applique).

sudo cscli decisions list

L'adresse IP de ma machine est bien visible ! La raison de cette décision est la suivante : crowdsecurity/ssh-bf, ce qui correspond bien au brute force SSH que nous avons tenté. Nous pouvons constater que cette adresse IP a été bannie pendant 4 heures (valeur par défaut dans CrowdSec).

Vous pouvez aussi afficher les alertes via cette commande (ce sont les alertes qui entrainent la décision de bloquer une IP) :

sudo cscli alerts list

Puis, demander des précisions sur une alerte spécifique en précisant son ID. Cela permet d'obtenir des renseignements précis sur l'action malveillante détectée. Dans le contexte d'une attaque brute force par SSH, le nom d'utilisateur ciblé par l'attaquant (ici admin) est également précisé.

sudo cscli alerts inspect 1

Sachez que les scénarios de détection des attaques SSH sont intégrés dans plusieurs collections, dont la crowdsecurity/linux et la crowdsecurity/sshd. Il y a notamment les scénarios suivants :

crowdsecurity/ssh-bf
crowdsecurity/ssh-cve-2024-6387
crowdsecurity/ssh-generic-test
crowdsecurity/ssh-refused-conn
crowdsecurity/ssh-slow-bf
crowdsecurity/ssh-time-based-bf

La configuration de chaque scénario est définie par un fichier YAML stocké dans le répertoire suivant : /etc/crowdsec/scenarios/.

D'ailleurs, je vous invite à ouvrir le fichier /etc/crowdsec/scenarios/ssh-bf.yaml correspondant au scénario crowdsecurity/ssh-bf. Si l'adresse IP a été bannie au bout de 6 tentatives en échec, ce n'est pas un hasard : c'est la configuration de CrowdSec qui implique cela, avec le système de bucket (type leaky).

Le bucket fonctionne comme un seau qui se remplit à chaque action suspecte d'une IP et se vide lentement avec le temps : s'il déborde parce que les tentatives sont trop nombreuses ou trop rapides, l'attaque est confirmée et déclenche une alerte ou un bannissement. L'image ci-dessous montre bien la capacité de 5 avant un débordement du bucket (capacity: 5).

Protéger un serveur Web Nginx avec CrowdSec

Considérons un second cas d'usage pour la suite de ce guide d'introduction à CrowdSec : la protection de base d'un serveur Web Nginx. CrowdSec est déjà installé, Nginx a été installé après l'IPS/IDS, alors comment le protéger ?

Installer et configurer la collection Nginx

Tout d'abord, vous devez commencer par installer la collection correspondante à Nginx :

sudo cscli collections install crowdsecurity/nginx

Action plan:
📥 download
 collections: crowdsecurity/nginx (0.2)
 scenarios: crowdsecurity/nginx-req-limit-exceeded (0.3)
 parsers: crowdsecurity/nginx-logs (2.0)
✅ enable
 collections: crowdsecurity/nginx
 scenarios: crowdsecurity/nginx-req-limit-exceeded
 parsers: crowdsecurity/nginx-logs

downloading parsers:crowdsecurity/nginx-logs
downloading scenarios:crowdsecurity/nginx-req-limit-exceeded
downloading collections:crowdsecurity/nginx
enabling parsers:crowdsecurity/nginx-logs
enabling scenarios:crowdsecurity/nginx-req-limit-exceeded
enabling collections:crowdsecurity/nginx

Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.

Puis, créez le fichier /etc/crowdsec/acquis.d/setup.nginx.yaml avec le contenu suivant pour indiquer à CrowdSec comment il doit parser les logs de Nginx.

filenames:
  - /var/log/nginx/*.log
labels:
  type: nginx

La collection installée précédemment contient notamment un parser capable d'interpréter les journaux de Nginx.

Enfin, quand c'est fait, relancez CrowdSec :

sudo systemctl reload crowdsec

Installer le bouncer Nginx

Vous pouvez ensuite installer le bouncer spécifique à Nginx, ce qui permettrait de se passer de celui pour le firewall (tout dépend de comment vous souhaitez bloquer les IP malveillantes). L'idée ici étant de vous expliquer comment installer un bouncer manuellement.

Téléchargez le paquet d'installation du bouncer cs-nginx-bouncer :

wget https://github.com/crowdsecurity/cs-nginx-bouncer/releases/download/v1.1.5/crowdsec-nginx-bouncer.tgz

Puis, décompressez l'archive obtenue.

tar -xzvf crowdsec-nginx-bouncer.tgz

Quand c'est fait, positionnez-vous dans le répertoire créé après avoir extrait le contenu de l'archive. Puis, exécutez le script d'installation :

./install.sh

Le script d'installation va en profiter pour installer quelques dépendances, si elles sont manquantes bien sûr. Voici la liste des dépendances installées sur ma machine par ce Bouncer : libnginx-mod-http-lua, luarocks. Pour information, LUA est un système qui permet de développer et d'intégrer des modules au sein de Nginx.

Voilà, désormais, si vous listez vos bouncers, vous devriez en voir un dans la liste avec un nom sous la forme crowdsec-nginx-bouncer-<ID>.

sudo cscli bouncers list

Tester la protection

Pour vérifier que CrowdSec analyse bien les journaux de Nginx et qu'il est capable de bannir les adresses IP malveillantes, il y a plein de tests possibles. Vous pouvez utiliser Nikto, par exemple. Il s'agit d'un outil open source pour scanner les serveurs Web. Il permet de rechercher des vulnérabilités, des fichiers dangereux, etc...

Vous pouvez aussi simplement utiliser curl en modifiant la valeur du user-agent pour vous faire passer pour Nikto. Ce sera suffisant pour déclencher une alerte CrowdSec. Depuis une machine distante, exécutez cette commande (à plusieurs reprises pour générer des logs) :

curl -v -A "Nikto" http://<ip serveur nginx>

Si vous jouez avec Nikto, utilisez plutôt ceci :

nikto -h <ip serveur nginx>

Dans les deux cas, votre machine devrait être rapidement bloquée !

Un tour dans la liste des décisions vous le montrera ! Ici, la raison est claire : CrowdSec n'a pas apprécié notre user-agent.

sudo cscli decisions list

Comme nous l'avons vu précédemment, vous pouvez aller plus loin en inspectant l'alerte associée. Elle permet d'avoir des précisions supplémentaires.

Personnaliser la durée du ban de CrowdSec

Par défaut, CrowdSec va bannir les adresses IP malveillantes pendant 4 heures. Vous pouvez modifier la configuration, notamment si vous souhaitez allonger la durée de validité d'une décision.

Éditez le fichier suivant :

/etc/crowdsec/profiles.yaml

Vous pourrez constater la directive duration qui indique la durée d'un bannissement. Vous n'aurez qu'à changer cette valeur puis à relancer le service CrowdSec.

name: default_ip_remediation
#debug: true
filters:
 - Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
 - type: ban
   duration: 4h

Sachez également que, par défaut, CrowdSec va bannir uniquement les adresses IP publiques. Si vous effectuez des tests uniquement sur votre réseau local, vous risquez de penser que CrowdSec ne fonctionne pas. Là encore, vous avez la main pour ajuster ce comportement.

La liste blanche des plages d'adresses IP est définie dans ce fichier de configuration :

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

Nous voyons bien les plages d'adresses IPv4 privées apparaître dans ce fichier :

name: crowdsecurity/whitelists
description: "Whitelist events from private ipv4 addresses"
whitelist:
  reason: "private ipv4/ipv6 ip/ranges"
  ip:
    - "::1"
  cidr:
    - "127.0.0.0/8"
    - "192.168.0.0/16"
    - "10.0.0.0/8"
    - "172.16.0.0/12"

Si vous avez besoin de mettre en liste blanche certaines adresses IP, c'est possible ! Vous pouvez créer votre propre liste blanche sur le même format. A ce sujet, consultez cet article :

• CrowdSec : comment créer une liste blanche d'IP ?

Cheat Sheet : les commandes CrowdSec essentielles

Pour bien prendre en main CrowdSec, l'utilisation de la ligne de commande cscli est votre meilleure alliée. Pour vous aider, voici le tableau récapitulatif des commandes indispensables, classées par type d'action. Pensez à ajouter le préfixe sudo à ces commandes en fonction du contexte d'exécution.

Commande	Description / Action
Gestion du Hub et des mises à jour
cscli hub update	Met à jour l'index local du Hub (à faire avant d'installer quoi que ce soit).
cscli hub upgrade	Met à jour tous les parsers, scénarios et collections installés vers leur dernière version.
cscli hub list	Liste tous les éléments du Hub présents sur la machine.
Gestion des collections et des scénarios
cscli collections list	Affiche les collections (packs de règles) actuellement installées.
cscli collections install <nom>	Installe une collection spécifique (par exemple : crowdsecurity/nginx).
cscli collections upgrade --all	Met à jour toutes les collections installées sur la machine.
cscli scenarios list	Liste les scénarios de détection actifs.
Gestion des décisions (adresses IP bannies)
cscli decisions list	Affiche la liste des IPs actuellement bloquées (ou sous remédiation).
cscli decisions add -i <IP> -t ban -d 24h	Bannit manuellement une IP (-i) pour une durée de 24 heures (-d).
cscli decisions delete -i <IP>	Supprime la décision (débannit) pour une IP spécifique.
cscli decisions delete --all	Attention : supprime toutes les décisions actives (Flush complet).
Alertes et investigation
cscli alerts list	Affiche l'historique des alertes levées par le système.
cscli alerts inspect -d <ID>	Affiche les détails techniques d'une alerte spécifique via son ID (logs concernés, scénario).
cscli alerts flush	Vide l'historique des alertes (utile pour faire le ménage sans toucher aux bans).
Monitoring et diagnostic
cscli metrics	Affiche un tableau de bord textuel : logs parsés, scénarios déclenchés, acquisition. Au début, cela peut s'avérer utile pour s'assurer que CrowdSec parvient à lire les logs de vos services.
cscli explain -d "<ligne de log>" -t <service>	Outil de debug : montre comment CrowdSec interprète une ligne de log précise.
Bouncers (remédiation)
cscli bouncers list	Vérifie l'état des bouncers connectés (Firewall, Nginx, etc.) et leur dernière communication.
cscli bouncers add <nom du bouncer>	Crée un nouveau bouncer et génère sa clé API. À faire avant de configurer le bouncer sur le serveur. C'est utile pour certains bouncers, comme celui de WordPress, par exemple.
cscli bouncers delete <nom du bouncer>	Supprime un bouncer et révoque immédiatement sa clé API.

Conclusion

En suivant ce tutoriel, vous devriez être en mesure de faire vos premiers pas avec CrowdSec sur Linux ! Pour aller plus loin, je vous oriente vers mes autres articles d'utilisation de CrowdSec où j'évoque des scénarios d'utilisation différents :

• Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec
• Comment créer un scénario de notifications avec CrowdSec ?
• Comment mettre en place une installation multiserveur de CrowdSec ?
• Installer CrowdSec sur un pare-feu PfSense pour protéger son réseau
• Intégration de CrowdSec avec le reverse proxy Traefik
• Comment sécuriser un serveur Windows avec CrowdSec ?
• Comment protéger son site WordPress avec CrowdSec ?
• Comment protéger un serveur Microsoft Exchange avec CrowdSec ?