CrowdSec : détection et blocage collaboratif des attaques

CrowdSec est un IDS/IPS open source collaboratif qui analyse vos logs en temps réel, détecte les comportements malveillants (brute force, scans, exploits) et bloque automatiquement les attaquants. Son point fort : chaque utilisateur partage ses signaux avec la communauté (12 600+ stars GitHub), créant une base de threat intelligence collective qui protège tout le réseau.

Ce que vous allez apprendre

Comprendre l’architecture Security Engine, LAPI et Bouncers
Installer et configurer CrowdSec depuis les sources officielles
Protéger un service de A à Z en 10 étapes : détection, collection, acquisition, validation, simulation, bouncer, décisions et métriques
Exploiter CrowdSec au quotidien : console web, dépannage, bonnes pratiques

CrowdSec en bref : un Fail2Ban collaboratif

Analogie : si Fail2Ban est un vigile qui surveille l’entrée de votre immeuble, CrowdSec est un réseau de vigiles connectés : quand l’un d’eux repère un intrus, tous les autres sont immédiatement prévenus et bloquent cette personne avant même qu’elle ne se présente.

CrowdSec se distingue par :

Intelligence communautaire (CAPI) : les signaux d’attaque sont partagés entre tous les utilisateurs, créant une base de threat intelligence collective
Architecture modulaire : Security Engine (détection) + Bouncers (remédiation) découplés, déployables sur des machines différentes
Performance : parsers écrits en Go avec enrichissement GeoIP natif
Sources de logs variées : fichiers, journald, conteneurs Docker, S3, Kafka, Loki…
WAF intégré : le composant AppSec analyse les requêtes HTTP en temps réel (in-band et out-of-band)
LAPI REST complète : API pour piloter les décisions, alertes et bouncers programmatiquement
Console web gratuite : app.crowdsec.net pour superviser vos instances et gérer les blocklists
Licence MIT : open source, libre d’utilisation commerciale

Concepts clés

Avant de passer à l’installation, voici les concepts essentiels à connaître :

Collection : pack préconfiguré de parsers + scénarios pour un service. C’est comme un kit de surveillance prêt à l’emploi.
Parser : analyse et normalise une ligne de log brute. C’est le traducteur qui comprend le format du log.
Scénario : définit un comportement malveillant via un leaky bucket. Par exemple : “plus de 5 échecs en 10s = attaque”.
Décision : action prise (ban, captcha, throttle). C’est la sanction appliquée à un attaquant.
Bouncer : composant qui applique les décisions. C’est le vigile qui exécute l’ordre de blocage.
Enricher : ajoute du contexte (GeoIP, DNS) aux événements. C’est la fiche d’identité ajoutée à chaque événement.
PostOverflow : parser appliqué après la détection, avant la décision. C’est une vérification de dernière minute.
Hub : dépôt centralisé de parsers, scénarios et collections. C’est l’App Store de la sécurité CrowdSec.

Comment installer CrowdSec ?

La méthode la plus simple pour installer CrowdSec sur Debian ou Ubuntu :

# Ajouter le dépôt officiel CrowdSec
curl -s https://install.crowdsec.net | sudo sh

# Installer CrowdSec
sudo apt-get install -y crowdsec

Vérification :

sudo cscli version

Pour installer la dernière version depuis le tarball officiel :

# Télécharger la dernière release
curl -sL https://github.com/crowdsecurity/crowdsec/releases/download/v1.7.6/crowdsec-release.tgz \
  -o /tmp/crowdsec-release.tgz

# Extraire
cd /tmp && tar xzf crowdsec-release.tgz

# Installer avec le wizard interactif
cd crowdsec-v1.7.6
sudo ./wizard.sh --install

Le wizard détecte automatiquement les services actifs (SSH, Nginx…) et propose d’installer les collections correspondantes.

Vérification :

sudo cscli version
# version: v1.7.6-eacc8192
# Codename: alphaga
# BuildDate: 2026-01-23_09:44:14
# GoVersion: 1.25.1

# Ajouter le dépôt officiel
curl -s https://install.crowdsec.net | sudo sh

# Installer CrowdSec
sudo dnf install -y crowdsec

Vérifier que le service fonctionne

sudo systemctl is-active crowdsec
# active

CrowdSec enregistre automatiquement la machine locale comme agent auprès de la LAPI :

sudo cscli machines list
# ──────────────────────────────────────────────────────────────────────────────
#  Name                              IP Address  Status  Version       OS
# ──────────────────────────────────────────────────────────────────────────────
#  ad79f20e75784...                  127.0.0.1   ✔️      v1.7.6-...    ubuntu/24.04
# ──────────────────────────────────────────────────────────────────────────────

Architecture de CrowdSec

Le Security Engine est le nom donné à l’ensemble du système CrowdSec. Il est composé de deux grandes parties internes — le Log Processor et la Local API (LAPI) — auxquelles s’ajoutent des composants externes : les Remediation Components (bouncers) et la Central API (CAPI).

Le Log Processor : de la ligne de log à l’alerte

Le Log Processor est la partie du Security Engine en charge de toute la détection. Il a deux fonctions principales :

Analyser les logs : il lit les journaux depuis des sources de données variées (fichiers, journald, conteneurs Docker, S3, Kafka, Loki…), les parse et les compare à des scénarios de détection
Filtrer le trafic HTTP : via le composant AppSec (WAF), il peut aussi recevoir les requêtes HTTP directement depuis un serveur web compatible et les confronter à des règles AppSec

Quand un scénario ou une règle AppSec se déclenche, le Log Processor envoie une alerte à la LAPI.

Le pipeline de parsing traite chaque ligne de log en trois stages successifs. Un événement doit être parsé avec succès à chaque stage pour passer au suivant — sinon il est ignoré :

s00-raw — normalisation : les logs arrivent de sources différentes (syslog, fichier Nginx, conteneur Docker…). Ce stage les met dans un format prédictible, quel que soit leur origine. Par exemple, un log SSH arrivant par journald et le même arrivant par un fichier syslog produisent le même événement en sortie
s01-parse — extraction : à partir du format normalisé, ce stage extrait les informations pertinentes selon le type d’application. Pour SSH, il identifie le type d’événement (échec d’authentification, connexion réussie…), l’IP source, le nom d’utilisateur, etc.
s02-enrich — enrichissement : les champs extraits sont complétés avec du contexte supplémentaire : géolocalisation GeoIP (pays, ville, ASN), résolution DNS, et vérification des whitelists. C’est aussi à ce stage que les IP privées (RFC1918) sont marquées comme whitelistées

Une fois parsé et enrichi, l’événement est transmis aux scénarios. Un scénario fonctionne comme un leaky bucket (seau percé) : chaque événement qui correspond au filtre du scénario “remplit” le seau. Le seau se vide à un rythme défini par leakspeed. Si le seau déborde (plus d’événements que la capacity dans le temps imparti), un overflow se produit et génère une alerte. Le paramètre groupby (généralement l’IP source) assure que chaque attaquant a son propre seau.

Après un overflow, l’événement passe encore par les postoverflows — un jeu de parsers spéciaux, souvent des whitelists de dernière chance (par exemple, exclure les IP de fournisseurs DNS publics légitimes).

La LAPI : le middleware central

La Local API est le point central qui relie tous les composants. Elle :

Reçoit les alertes du Log Processor et crée des décisions en fonction des profils configurés dans profiles.yaml (type de ban, durée, scope IP ou range…)
Expose les décisions aux Remediation Components (bouncers) via une API REST
Communique avec la CAPI pour envoyer les signaux d’attaque et recevoir en retour les blocklists communautaires

Toute la communication entre composants passe par la LAPI via HTTP. C’est ce qui permet une architecture distribuée : plusieurs Log Processors et plusieurs bouncers sur des machines différentes peuvent partager la même LAPI.

Les Remediation Components (bouncers) : l’exécution

Les bouncers sont des composants externes au Security Engine. Ils interrogent la LAPI pour obtenir la liste des décisions actives et les appliquent concrètement. Ils exploitent les composants existants de votre infrastructure pour bloquer les IP là où c’est le plus efficace :

Pare-feu : cs-firewall-bouncer ajoute les IP dans un ipset et applique une règle DROP via iptables, nftables ou pf
Reverse proxy : bouncers Nginx, Traefik ou HAProxy qui rejettent les requêtes au niveau HTTP
CDN : bouncers Cloudflare ou AWS WAF pour le blocage en amont
Applicatif : bouncers WordPress, PHP pour le blocage au niveau applicatif

Sans bouncer, CrowdSec détecte les attaques mais ne bloque rien. La détection et la remédiation sont volontairement découplées.

La CAPI et la Console : l’intelligence communautaire

La Central API (CAPI) est le point de connexion avec le réseau CrowdSec mondial. Elle reçoit les signaux d’attaque de toutes les installations participantes, les agrège, les valide, puis redistribue des blocklists communautaires (Community Blocklist) à l’ensemble des membres. C’est ce mécanisme collaboratif qui distingue CrowdSec d’un IDS classique : une attaque détectée par un participant protège proactivement tous les autres.

La Console (app.crowdsec.net) est l’interface web qui donne accès à la gestion des alertes et décisions, à la supervision de vos Security Engines et à l’abonnement aux blocklists.

Le composant AppSec (WAF)

Depuis la v1.6, le Log Processor intègre un module WAF qui analyse les requêtes HTTP en temps réel, directement depuis les serveurs web compatibles (Nginx, Apache, Traefik via le bouncer). Deux modes de règles coexistent :

In-band : la requête est analysée avant d’atteindre l’application. Si elle matche une règle, elle est bloquée immédiatement
Out-of-band : la requête est analysée après avoir été transmise à l’application. Ce mode permet la détection sans blocage, utile pour valider de nouvelles règles

Parcours complet d’une attaque

Pour illustrer concrètement, voici ce qui se passe quand un attaquant tente un brute force SSH :

Acquisition — le Log Processor lit les logs SSH via journald (configuré dans acquis.d/)
Parsing — la ligne Failed password for root from 185.220.101.34 traverse les 3 stages : normalisation syslog (s00-raw), extraction des champs SSH (s01-parse), enrichissement GeoIP + vérification whitelist (s02-enrich)
Scénario — l’événement enrichi entre dans le scénario crowdsecurity/ssh-bf. Le seau de l’IP 185.220.101.34 se remplit. Après 6 échecs en moins de 50 secondes, le seau déborde → overflow
Postoverflow — les whitelists de dernière chance sont consultées (IP de DNS publics, CDN connus). L’IP n’est pas whitelistée
Profil — la LAPI reçoit l’alerte, consulte profiles.yaml et crée une décision : ban de 4 heures pour cette IP
Remédiation — le bouncer firewall interroge la LAPI, récupère la nouvelle décision et ajoute l’IP dans l’ipset crowdsec-blacklists → règle iptables DROP appliquée
Partage — en parallèle, le signal est envoyé à la CAPI. Si suffisamment d’installations signalent la même IP, elle est ajoutée à la Community Blocklist et redistribuée à tous les participants

Architecture CrowdSec : Security Engine, LAPI, Bouncers et CAPI

Configuration de base

Maintenant que nous avons installé CrowdSec et compris son architecture, passons à la configuration. La configuration de CrowdSec se trouve dans /etc/crowdsec/. Voici les fichiers principaux :

config.yaml : configuration globale (logs, BDD, API, Prometheus)
acquis.yaml / acquis.d/*.yaml : sources de logs à surveiller
profiles.yaml : politiques de décision (ban, durée, notifications)
local_api_credentials.yaml : identifiants de la machine pour la LAPI
online_api_credentials.yaml : identifiants pour la CAPI (communauté)
simulation.yaml : scénarios en mode simulation (pas de ban réel)

Profils de décision

Le fichier profiles.yaml définit ce qui se passe quand un scénario déclenche une alerte :

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

Ce profil signifie : toute alerte avec remédiation sur une IP → ban de 4 heures.

Le Hub : collections, scénarios et parsers

Le Hub CrowdSec (hub.crowdsec.net) est le dépôt centralisé qui contient plus de 160 parsers, 774 scénarios et 160 collections prêts à l’emploi.

Gérer le Hub

# Mettre à jour l'index du hub
sudo cscli hub update

# Mettre à jour tous les composants installés
sudo cscli hub upgrade

# Lister tout ce qui est installé
sudo cscli hub list
# Loaded: 160 parsers, 11 postoverflows, 774 scenarios, 9 contexts,
#         5 appsec-configs, 191 appsec-rules, 160 collections

Anatomie d’un scénario

Un scénario CrowdSec fonctionne comme un leaky bucket (seau percé). Les événements remplissent le seau, et s’il déborde, une alerte est déclenchée.

Exemple du scénario ssh-bf (brute force SSH) :

type: leaky
name: crowdsecurity/ssh-bf
description: "Detect ssh bruteforce"
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
leakspeed: "10s"      # Le seau se vide d'1 événement toutes les 10s
capacity: 5            # Le seau contient 5 événements max
groupby: evt.Meta.source_ip
blackhole: 1m          # Après déclenchement, ignore l'IP pendant 1 min
reprocess: true
labels:
  service: ssh
  remediation: true    # Active le blocage automatique
  classification:
    - attack.T1110     # MITRE ATT&CK : Brute Force

En clair : si une même IP génère plus de 5 échecs d’authentification SSH en moins de 50 secondes (5 × 10s), CrowdSec déclenche une alerte et bloque l’IP.

Pour voir concrètement comment installer une collection, configurer les logs et valider le pipeline, passez à la section suivante.

Protéger un nouveau service de A à Z

Vous savez installer CrowdSec et vous connaissez le Hub. Passons maintenant au cas concret : comment protéger un service que vous venez d’installer sur votre serveur ? Cette section décrit le workflow complet, de la détection du service jusqu’à la validation de la protection, en prenant Nginx comme exemple.

La démarche est la même pour tout service : SSH, Apache, MariaDB, Postfix, HAProxy, Caddy… Seuls le nom de la collection et le format des logs changent.

Étape 1 : identifier les services à protéger

CrowdSec intègre un mécanisme de service discovery qui détecte automatiquement les services installés sur votre machine. Cette commande est le point de départ :

sudo cscli setup detect --yaml

Résultat (après installation de Nginx) :

setup:
  - detected_service: linux
    hub_spec:
      collections:
        - crowdsecurity/linux
    acquisition_spec:
      filename: linux.yaml
      datasource:
        filenames:
          - /var/log/messages
          - /var/log/syslog
          - /var/log/kern.log
        labels:
          type: syslog
        source: file
  - detected_service: nginx
    hub_spec:
      collections:
        - crowdsecurity/nginx
    acquisition_spec:
      filename: nginx.yaml
      datasource:
        filenames:
          - /var/log/nginx/*.log
        labels:
          type: nginx
        source: file
  - detected_service: openssh-journal-ssh
    hub_spec:
      collections:
        - crowdsecurity/sshd
    acquisition_spec:
      filename: sshd.yaml
      datasource:
        journalctl_filter:
          - _SYSTEMD_UNIT=ssh.service
        labels:
          type: syslog
        source: journalctl

La commande identifie chaque service, la collection à installer et la configuration d’acquisition correspondante (quels fichiers de logs lire, avec quel label).

CrowdSec détecte automatiquement plus de 25 services : Nginx, Apache, HAProxy, Caddy, MariaDB, PostgreSQL, Postfix, Dovecot, Asterisk, Samba, Suricata, AuditD… Pour voir la liste complète :

sudo cscli setup detect --list-supported-services

Étape 2 : examiner la collection avant installation

Avant d’installer quoi que ce soit, inspectez ce que la collection contient :

sudo cscli collections inspect crowdsecurity/nginx

type: collections
name: crowdsecurity/nginx
description: 'nginx support : parser and generic http scenarios'
version: "0.2"
dependencies:
  parsers:
    - crowdsecurity/nginx-logs
  scenarios:
    - crowdsecurity/nginx-req-limit-exceeded
  collections:
    - crowdsecurity/base-http-scenarios

On voit que la collection nginx inclut :

1 parser (nginx-logs) pour comprendre le format des logs Nginx
1 scénario spécifique (nginx-req-limit-exceeded) pour détecter les dépassements de limites de requêtes
1 sous-collection (base-http-scenarios) qui inclut elle-même une autre sous-collection (http-cve) — soit au total 46 scénarios de détection HTTP : brute force, scans de fichiers sensibles, injections SQL, XSS, CVE connues, user-agents malveillants, backdoors…

Étape 3 : installer la collection

sudo cscli collections install crowdsecurity/nginx

CrowdSec télécharge automatiquement toutes les dépendances :

Action plan:
📥 download
 collections: crowdsecurity/base-http-scenarios (1.2),
              crowdsecurity/http-cve (2.9),
              crowdsecurity/nginx (0.2)
 scenarios: crowdsecurity/http-admin-interface-probing (0.5),
            crowdsecurity/http-sensitive-files (0.4),
            crowdsecurity/http-sqli-probing (0.4),
            crowdsecurity/http-xss-probing (0.4),
            crowdsecurity/http-path-traversal-probing (0.4),
            crowdsecurity/CVE-2024-38475 (0.1),
            ... (46 scénarios au total)
 parsers: crowdsecurity/http-logs (1.3),
          crowdsecurity/nginx-logs (2.0)
✅ enable

Vérification :

sudo cscli collections list

──────────────────────────────────────────────────────────────────────────────
 Name                                 📦 Status    Version
──────────────────────────────────────────────────────────────────────────────
 crowdsecurity/base-http-scenarios    ✔️  enabled  1.2
 crowdsecurity/http-cve               ✔️  enabled  2.9
 crowdsecurity/linux                  ✔️  enabled  0.3
 crowdsecurity/nginx                  ✔️  enabled  0.2
 crowdsecurity/sshd                   ✔️  enabled  0.8
 crowdsecurity/whitelist-good-actors  ✔️  enabled  0.2
──────────────────────────────────────────────────────────────────────────────

Étape 4 : configurer l’acquisition des logs

La collection installe les parsers et scénarios, mais elle ne configure pas la source de logs. Vous devez indiquer à CrowdSec où lire les logs du service.

Créez un fichier d’acquisition dans /etc/crowdsec/acquis.d/ :

sudo tee /etc/crowdsec/acquis.d/nginx.yaml << 'EOF'
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx
EOF

Sources de logs alternatives : selon votre infrastructure, les logs peuvent venir de différentes sources.

filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx

source: journalctl
journalctl_filter:
  - _SYSTEMD_UNIT=nginx.service
labels:
  type: nginx

source: docker
container_name_regexp:
  - .*nginx.*
labels:
  type: nginx

Étape 5 : recharger CrowdSec et valider

Après avoir créé le fichier d’acquisition, rechargez le service :

sudo systemctl reload crowdsec

Vérification : les métriques confirment que CrowdSec lit bien les logs Nginx :

sudo cscli metrics

╭─────────────────────────────────────────────────┬────────────┬──────────────┬────────────────╮
│ Source                                          │ Lines read │ Lines parsed │ Lines unparsed │
├─────────────────────────────────────────────────┼────────────┼──────────────┼────────────────┤
│ file:/var/log/nginx/access.log                  │ 41         │ 41           │ -              │
│ journalctl:journalctl-_SYSTEMD_UNIT=ssh.service │ 9          │ 4            │ 5              │
╰─────────────────────────────────────────────────┴────────────┴──────────────┴────────────────╯

Les 41 lignes parsées confirment que le parser nginx-logs traite correctement les logs.

Étape 6 : tester le pipeline complet

Vérifiez que la chaîne complète fonctionne — du log brut jusqu’aux scénarios :

sudo cscli explain \
  --log '185.220.101.34 - - [28/Feb/2026:09:00:00 +0100] "GET /admin/config.php HTTP/1.1" 404 162 "-" "Mozilla/5.0"' \
  --type nginx

line: 185.220.101.34 - - [28/Feb/2026:09:00:00 +0100] "GET /admin/config.php HTTP/1.1" 404 162 "-" "Mozilla/5.0"
        ├ s00-raw
        |       └ 🟢 crowdsecurity/non-syslog (+5 ~8)
        ├ s01-parse
        |       └ 🟢 crowdsecurity/nginx-logs (+23 ~2)
        ├ s02-enrich
        |       ├ 🟢 crowdsecurity/dateparse-enrich (+2 ~2)
        |       ├ 🟢 crowdsecurity/geoip-enrich (+13)
        |       ├ 🟢 crowdsecurity/http-logs (+7)
        |       ├ 🟢 crowdsecurity/public-dns-allowlist (unchanged)
        |       └ 🟢 crowdsecurity/whitelists (unchanged)
        ├-------- parser success 🟢
        ├ Scenarios
                ├ 🟢 crowdsecurity/http-admin-interface-probing
                ├ 🟢 crowdsecurity/http-crawl-non_statics
                └ 🟢 crowdsecurity/http-probing

Lecture du résultat :

s00-raw : le parser non-syslog reconnaît que le log n’est pas au format syslog (c’est un log Nginx direct)
s01-parse : le parser nginx-logs extrait 23 champs (IP source, méthode, URL, code HTTP, user-agent…)
s02-enrich : enrichissement GeoIP (13 champs : pays, ville, ASN), analyse HTTP (7 champs), vérification whitelists
Scénarios : 3 scénarios matchent — scan d’interface admin, crawl de pages non statiques, probing HTTP

Testez aussi avec un scan de fichiers sensibles :

sudo cscli explain \
  --log '185.220.101.34 - - [28/Feb/2026:09:00:00 +0100] "GET /.env HTTP/1.1" 404 162 "-" "Mozilla/5.0"' \
  --type nginx

        ├ Scenarios
                ├ 🟢 crowdsecurity/http-crawl-non_statics
                ├ 🟢 crowdsecurity/http-probing
                └ 🟢 crowdsecurity/http-sensitive-files

Le scénario http-sensitive-files détecte bien la tentative d’accès au fichier .env.

Étape 7 : activer le mode simulation (recommandé)

Avant de bloquer réellement des IP, testez vos nouveaux scénarios en mode simulation. Les alertes sont générées mais aucune décision de ban n’est appliquée :

# Vérifier le statut actuel
sudo cscli simulation status
# global simulation: disabled

# Activer la simulation pour les scénarios HTTP fraîchement installés
sudo cscli simulation enable crowdsecurity/http-probing
sudo systemctl reload crowdsec

Quand un scénario est en simulation, les décisions apparaissent avec le préfixe (simul) :

│ Action     │
│ (simul)ban │

Observez le comportement pendant quelques heures ou jours. Quand vous êtes confiant, désactivez la simulation :

sudo cscli simulation disable crowdsecurity/http-probing
sudo systemctl reload crowdsec

Étape 8 : installer un bouncer pour bloquer réellement

Jusqu’ici, CrowdSec détecte les attaques mais ne bloque rien. Pour appliquer concrètement les décisions, vous devez installer un bouncer.

Analogie : le Security Engine est le juge qui prononce la sentence, le bouncer est le policier qui l’exécute.

Enregistrer le bouncer — chaque bouncer a besoin d’une clé API pour communiquer avec la LAPI :

sudo cscli bouncers add mon-firewall-bouncer
# API key for 'mon-firewall-bouncer':
#
#    ui3wmTop2vYU/4IXyMyCwH2bD4ZM+TGI1WyYgUX+N2A
#
# Please keep this key since you will not be able to retrieve it!

Installer le bouncer firewall — le plus courant, il bloque les IP au niveau du pare-feu :

Debian / Ubuntu
RHEL / Rocky

sudo apt install crowdsec-firewall-bouncer-iptables

sudo dnf install crowdsec-firewall-bouncer

Le bouncer crée automatiquement un ipset nommé crowdsec-blacklists et ajoute une règle iptables DROP pour toutes les IP de cet ensemble.

Vérification :

sudo cscli bouncers list

Supprimer un bouncer (si besoin) :

sudo cscli bouncers delete mon-firewall-bouncer
# INFO bouncer 'mon-firewall-bouncer' deleted successfully

Étape 9 : gérer les décisions de blocage

Les décisions sont les actions concrètes de blocage. Elles sont créées automatiquement quand un scénario déborde, mais vous pouvez aussi les gérer manuellement.

Lister les décisions actives :

sudo cscli decisions list

╭────┬──────────┬───────────────────┬──────────────────────┬────────┬─────────┬────┬────────┬────────────┬──────────╮
│ ID │  Source  │    Scope:Value    │        Reason        │ Action │ Country │ AS │ Events │ expiration │ Alert ID │
├────┼──────────┼───────────────────┼──────────────────────┼────────┼─────────┼────┼────────┼────────────┼──────────┤
│ 1  │ crowdsec │ Ip:185.220.101.34 │ crowdsecurity/ssh-bf │ ban    │ DE      │    │ 6      │ 3h52m      │ 1        │
╰────┴──────────┴───────────────────┴──────────────────────┴────────┴─────────┴────┴────────┴────────────┴──────────╯

Bannir manuellement une IP suspecte sans attendre un scénario :

# Bannir une IP pendant 4 heures
sudo cscli decisions add --ip 192.168.100.200 --duration 4h --reason "IP suspecte"
# INFO Decision successfully added

# Bannir un sous-réseau entier
sudo cscli decisions add --range 10.0.0.0/24 --duration 24h --reason "Réseau malveillant"

Supprimer une décision :

# Supprimer le ban d'une IP spécifique
sudo cscli decisions delete --ip 192.168.100.200
# INFO 1 decision(s) deleted

# Supprimer toutes les décisions
sudo cscli decisions delete --all

Consulter l’historique des alertes (même après expiration des bans) :

sudo cscli alerts list

╭────┬────────────────────┬──────────────┬─────────┬────┬───────────┬──────────────────────╮
│ ID │        value       │    reason    │ country │ as │ decisions │      created_at      │
├────┼────────────────────┼──────────────┼─────────┼────┼───────────┼──────────────────────┤
│ 1  │ Ip:192.168.100.200 │ IP suspecte  │         │    │ ban:1     │ 2026-02-28T07:27:16Z │
╰────┴────────────────────┴──────────────┴─────────┴────┴───────────┴──────────────────────╯

Étape 10 : surveiller avec les métriques

CrowdSec expose des métriques Prometheus sur le port 6060. Utilisez cscli metrics pour vérifier que tout fonctionne :

sudo cscli metrics

╭────────────────────────────────────╮
│ Local API Alerts                   │
├────────────────────────────┬───────┤
│ Reason                     │ Count │
├────────────────────────────┼───────┤
│ crowdsecurity/http-probing │ 1     │
╰────────────────────────────┴───────╯
╭────────────────────────────────────────────────────╮
│ Local API Metrics                                  │
├───────────────────────────────────┬────────┬────────┤
│ Route                             │ Method │ Hits   │
├───────────────────────────────────┼────────┼────────┤
│ /v1/alerts                        │ GET    │ 3      │
│ /v1/alerts                        │ POST   │ 1      │
│ /v1/decisions                     │ DELETE │ 1      │
│ /v1/heartbeat                     │ GET    │ 12     │
│ /v1/watchers/login                │ POST   │ 6      │
╰───────────────────────────────────┴────────┴────────╯

La configuration Prometheus se trouve dans config.yaml :

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

Vous pouvez intégrer ces métriques dans votre stack d’observabilité (Grafana, Prometheus, Victoria Metrics…) pour une supervision continue.

Résumé : protéger un service de bout en bout

Étape	Commande	Ce que ça fait
1. Détecter	`sudo cscli setup detect --yaml`	Identifier les services et collections recommandées
2. Inspecter	`sudo cscli collections inspect crowdsecurity/nginx`	Vérifier le contenu de la collection
3. Installer	`sudo cscli collections install crowdsecurity/nginx`	Télécharger parsers + scénarios + dépendances
4. Configurer	Créer `/etc/crowdsec/acquis.d/nginx.yaml`	Indiquer où lire les logs
5. Recharger	`sudo systemctl reload crowdsec`	Appliquer la configuration
6. Valider	`sudo cscli explain --log "..." --type nginx`	Vérifier le pipeline de parsing
7. Simuler	`sudo cscli simulation enable <scénario>`	Tester sans bloquer
8. Bloquer	`sudo apt install crowdsec-firewall-bouncer-iptables`	Installer le bouncer pour appliquer les décisions
9. Gérer	`sudo cscli decisions list / add / delete`	Contrôler les blocages manuellement
10. Surveiller	`sudo cscli metrics`	Vérifier que tout fonctionne en continu

Console CrowdSec

La Console CrowdSec (app.crowdsec.net) est l’interface web gratuite pour superviser vos instances. Elle permet de :

Visualiser les alertes en temps réel avec géolocalisation
Gérer les décisions depuis une interface graphique
S’abonner aux blocklists communautaires (3 gratuites avec le plan Community)
Surveiller plusieurs instances depuis un tableau de bord unique

Enregistrer votre instance

Créer un compte sur app.crowdsec.net
Enregistrer votre Security Engine : dans la console, cliquez sur + → Enroll a Security Engine pour obtenir la commande d’enrôlement
Exécuter la commande sur votre serveur :
Fenêtre de terminal
```
sudo cscli console enroll <VOTRE_TOKEN>
```
Accepter l’enrôlement dans la console web

Blocklists communautaires

Avec le plan Community (gratuit), vous pouvez souscrire à 3 blocklists d’IP malveillantes. Ces listes sont mises à jour en continu par la communauté CrowdSec et bloquent proactivement les IP connues comme malveillantes, avant même qu’elles n’attaquent votre serveur.

Dépannage

Problèmes courants et solutions

Symptôme	Cause probable	Solution
`bind: address already in use` au démarrage	Port LAPI (8080) occupé	Changer `listen_uri` dans `config.yaml` et `local_api_credentials.yaml`
`No active decisions` malgré des attaques	Pas de bouncer installé	Le Security Engine détecte mais ne bloque pas sans bouncer
IP privée non détectée par les scénarios	Whitelist des IP privées	Normal : le parser `whitelists` exclut les IP RFC1918
`missing login field` au démarrage	Pas enregistré sur la CAPI	Exécuter `sudo cscli capi register`
Scénario ne matche pas un log	Parser manquant ou log mal formaté	Utiliser `cscli explain --log "..." --type syslog` pour diagnostiquer
`crowdsec.service: Failed` après upgrade	Binaires incompatibles	Vérifier `sudo cscli version` et réinstaller si nécessaire

Commandes de diagnostic

# Vérifier le statut du service
sudo systemctl status crowdsec

# Voir les logs CrowdSec
sudo tail -f /var/log/crowdsec.log

# Tester le parsing d'un log
sudo cscli explain --log "VOTRE_LIGNE_DE_LOG" --type syslog

# Vérifier la connexion LAPI
sudo cscli lapi status

# Voir les métriques détaillées
sudo cscli metrics

Bonnes pratiques

Sécurité

Commencez en mode simulation pour tout nouveau scénario avant de l’activer en production
Whitelistez vos IP de management dans /etc/crowdsec/parsers/s02-enrich/whitelists.yaml
Enregistrez-vous sur la CAPI pour bénéficier des blocklists communautaires
Limitez l’écoute LAPI à 127.0.0.1 sauf en architecture multi-serveurs

Exploitation

Mettez à jour le hub régulièrement : sudo cscli hub update && sudo cscli hub upgrade
Supervisez les métriques Prometheus avec votre stack d’observabilité
Consultez les alertes régulièrement : sudo cscli alerts list
Sauvegardez votre configuration avant chaque mise à jour

Architecture multi-serveurs

Pour les infrastructures avec plusieurs serveurs, CrowdSec supporte une architecture distribuée :

Un serveur LAPI centralisé qui reçoit les alertes de tous les agents
Des agents distants (Security Engines) qui analysent les logs localement
Des bouncers distribués qui interrogent la LAPI centralisée

À retenir

CrowdSec est un IDS/IPS collaboratif : chaque utilisateur renforce la protection de tous via la CAPI
L’architecture est modulaire : Security Engine (détection) + LAPI (middleware) + Bouncers (remédiation)
Les collections sont le moyen le plus rapide de protéger un service (SSH, Nginx, Apache…)
Sans bouncer, CrowdSec ne bloque rien : le Security Engine détecte, les bouncers appliquent
cscli explain est votre meilleur allié pour diagnostiquer le pipeline de parsing
Le mode simulation permet de tester un scénario sans impact en production
Le Hub contient 774+ scénarios et 160+ collections prêts à l’emploi
La Console (app.crowdsec.net) offre une supervision graphique gratuite

Prochaines étapes

Firewalld : pare-feu Linux Configurez firewalld pour compléter CrowdSec avec un pare-feu robuste

UFW : pare-feu simplifié Alternative simple à firewalld pour les serveurs Ubuntu

Snort : détection d'intrusion réseau Complétez CrowdSec avec un IDS réseau pour l'analyse de paquets

Nmap : analyse réseau Auditez vos ports ouverts pour valider votre configuration CrowdSec

Traefik : reverse proxy Intégrez CrowdSec avec un bouncer Traefik pour protéger vos applications web

Nginx : serveur web Utilisez le bouncer Nginx pour bloquer les IP malveillantes au niveau HTTP

Ressources

Site officiel : crowdsec.net
Documentation : docs.crowdsec.net
Hub : hub.crowdsec.net
Console : app.crowdsec.net
GitHub : github.com/crowdsecurity/crowdsec (12 600+ stars, MIT)