De quoi parle-t-on ?

CrowdSec est un moteur de sécurité open source, écrit en Go, qui analyse en continu les journaux (logs) de vos services et les requêtes HTTP afin de repérer les comportements malveillants. Lorsqu’un comportement suspect est identifié — par exemple une rafale de tentatives de connexion SSH infructueuses — CrowdSec prend une décision (typiquement un bannissement d’adresse IP) et la fait appliquer par un composant de remédiation.

Sa particularité tient en deux idées fortes. D’une part, la détection est découplée de la remédiation : le composant qui repère l’attaque n’est pas celui qui la bloque. D’autre part, CrowdSec est collaboratif : chaque instance qui le souhaite partage, de façon anonymisée, les signaux d’attaque qu’elle observe, et reçoit en retour une liste communautaire d’adresses malveillantes validées. Vous bénéficiez ainsi de la vigilance de dizaines de milliers de serveurs à travers le monde.

Vue d’ensemble de l’architecture

CrowdSec s’organise autour de quatre briques principales. Le schéma ci-dessous montre comment elles s’articulent, depuis la lecture des journaux jusqu’au blocage effectif, en passant par le partage communautaire.

Les composants en détail

Le Security Engine

C’est le logiciel que vous installez sur votre serveur. Il joue le rôle de système de détection d’intrusion (IDS) : il repère les menaces et produit des alertes, sans bloquer directement. En interne, il se compose de deux parties.

Le Log Processor assure la détection. Il lit les journaux via une configuration d’acquisition, normalise chaque ligne grâce aux parseurs, enrichit l’événement (géolocalisation, ASN), puis l’évalue contre des scénarios de comportement. La fonctionnalité AppSec fait partie de cette couche : elle filtre les requêtes HTTP des serveurs web compatibles, à la manière d’un pare-feu applicatif (WAF).

La Local API (LAPI) constitue la seconde partie. Elle reçoit les alertes du Log Processor, peut les transformer en décisions selon des profils configurés, stocke le tout dans une base locale (SQLite ou PostgreSQL), et expose ces décisions aux composants de remédiation. Par défaut, elle n’écoute que sur 127.0.0.1:8080 — un point de sécurité à ne jamais négliger.

Les composants de remédiation

Anciennement appelés « bouncers », les composants de remédiation forment la couche de prévention (IPS). Ils interrogent régulièrement la LAPI pour savoir quelles adresses bloquer, puis appliquent la décision là où c’est le plus pertinent : pare-feu (iptables, nftables, pf), serveur web, reverse proxy, CDN. Point essentiel : ils ne prennent jamais de décision, ils se contentent de faire appliquer celles de la LAPI.

La Central API et le Hub

La Central API (CAPI) est la passerelle vers le réseau CrowdSec. Elle reçoit les signaux d’attaque des instances participantes, puis redistribue une liste d’attaquants validés : la community blocklist. Le Hub, lui, distribue les contenus de détection — parseurs, scénarios, et collections (des lots prêts à l’emploi) — maintenus collaborativement et installables en une commande.

La Console et cscli

Au quotidien, vous pilotez CrowdSec de deux manières : la Console, une interface web qui offre une visibilité centralisée sur l’ensemble de vos moteurs, et cscli, l’outil en ligne de commande pour l’administration locale.

Le cycle de vie d’une attaque

Pour bien saisir le fonctionnement, suivons pas à pas ce qui se passe lorsqu’un attaquant tente une attaque par force brute sur SSH. Chaque étape correspond à un composant précis.

Au cœur de la détection : parseurs et scénarios

Plutôt que de vous laisser écrire des expressions régulières à la main, CrowdSec sépare deux responsabilités. Les parseurs comprennent le format des journaux et en extraient des champs structurés. Les scénarios décrivent des comportements malveillants et déclenchent une alerte quand le motif se réalise.

Beaucoup de scénarios reposent sur un mécanisme de seau percé (leaky bucket) : chaque événement suspect ajoute une goutte dans un seau qui fuit lentement. Si les gouttes arrivent plus vite qu’elles ne s’écoulent, le seau déborde et le scénario se déclenche. C’est ce qui permet de distinguer une faute de frappe isolée d’une véritable attaque par force brute.

AppSec : le pare-feu applicatif

La détection par journaux voit une attaque après qu’elle a été enregistrée. Le composant AppSec complète cette approche en inspectant les requêtes HTTP en direct, au niveau applicatif (couche 7). Il attrape ainsi les injections SQL, le cross-site scripting (XSS) ou l’exploitation de failles connues avant qu’elles n’atteignent votre application. Il se couple à un composant de remédiation web installé dans votre reverse proxy.

Prise en main express

Voici les commandes qui couvrent l’essentiel de l’exploitation quotidienne. À adapter à votre distribution et à votre pare-feu (iptables ou nftables — ne les confondez pas, sous peine de règles non appliquées).

# Installer une collection de détection depuis le Hub
sudo cscli collections install crowdsecurity/sshd

# Lister les décisions actives, les alertes, les bouncers
sudo cscli decisions list
sudo cscli alerts list
sudo cscli bouncers list

# Ajouter / retirer une décision manuellement
sudo cscli decisions add --ip X.X.X.X --duration 4h --reason "test"
sudo cscli decisions delete --ip X.X.X.X

# Vérifier l'acquisition et les métriques
sudo cscli metrics

# Recharger après toute modification (acquisition, liste blanche, profil)
sudo systemctl reload crowdsec

Pourquoi le modèle collaboratif change la donne

Un serveur isolé ne voit que les attaques qui le visent. En mutualisant les signaux, CrowdSec transforme chaque instance en capteur d’un réseau mondial de plusieurs dizaines de milliers de participants. Une adresse repérée par de nombreux serveurs rejoint la blocklist communautaire, et l’ensemble des instances en bénéficie presque instantanément. Vous agissez ainsi contre des attaquants connus avant qu’ils ne s’en prennent à vous.

À noter également la dimension réglementaire : le partage repose sur un intérêt légitime (la sécurité du système d’information), ne concerne que des données minimales et pseudonymisées, et le code open source autorise un audit complet. Documenter cet usage dans votre registre de traitements suffit à rester serein côté conformité.

En résumé

CrowdSec repose sur une idée simple mais puissante : détecter les comportements malveillants à partir des journaux et des requêtes HTTP, découpler cette détection du blocage effectif, et partager l’intelligence des menaces à l’échelle d’une communauté mondiale. Le Security Engine observe et décide, la LAPI orchestre, les composants de remédiation appliquent, et la Central API mutualise. Léger, modulaire et collaboratif, il constitue aujourd’hui l’une des briques de sécurité les plus accessibles pour protéger un serveur Linux — du simple VPS personnel jusqu’aux flottes gérées par les hébergeurs.