CrowdSec 2026 : protection collaborative contre attaques, IPS moderne et threat intelligence

La sécurité des serveurs exposés sur Internet nécessite une vigilance constante face à des attaques automatisées qui n'ont cessé de s'intensifier. CrowdSec apporte une approche révolutionnaire : un système IPS (Intrusion Prevention System) collaboratif où la détection d'attaque par un serveur bénéficie à toute la communauté via une threat intelligence partagée. Ce guide complet explore comment CrowdSec transforme la sécurité serveur en combinant détection locale intelligente et intelligence collective.

Les limites des solutions traditionnelles

Fail2ban a longtemps été la solution de référence pour protéger les serveurs Linux contre les attaques bruteforce. Son principe est simple : analyser les logs (SSH, Nginx, etc.), détecter les patterns d'attaque (tentatives login échouées répétées), et bannir les IPs offensantes via iptables. Fail2ban a bien fonctionné pendant des années mais montre aujourd'hui ses limites face à l'évolution des menaces.

Réactivité locale uniquement : Fail2ban protège seulement le serveur sur lequel il tourne. Si une IP attaque votre serveur A à 14h00, votre serveur B sera complètement vulnérable à la même IP jusqu'à ce qu'elle l'attaque également. Il n'y a aucun partage d'information entre vos propres serveurs, encore moins avec la communauté.

Patterns d'attaque statiques : Les règles Fail2ban sont définies manuellement via regex sur logs. Quand de nouvelles techniques d'attaque émergent, vous devez attendre qu'un mainteneur écrive une nouvelle regex, la teste, la release. Ce cycle prend des semaines voire des mois pendant lesquels vous êtes vulnérable.

Pas d'intelligence sur les IPs : Fail2ban ne sait rien d'une IP avant qu'elle n'attaque. Une IP connue pour avoir bruteforcé 10,000 serveurs dans les dernières 24h sera traitée exactement comme une IP inconnue jusqu'à sa première attaque sur votre serveur.

Configuration fastidieuse : Chaque service nécessite sa propre jail Fail2ban. SSH, Nginx, Apache, Postfix, etc. - vous devez configurer, tester et maintenir des dizaines de règles. La complexité augmente exponentiellement avec le nombre de services.

CrowdSec : l'approche collaborative

CrowdSec repense complètement cette approche en introduisant trois innovations majeures :

1. Threat intelligence collaborative : Chaque instance CrowdSec partage (anonymement) les IPs malveillantes qu'elle détecte vers la CrowdSec Central API. En retour, elle reçoit la blocklist communautaire agrégée de millions de serveurs mondiaux. Résultat : une IP qui attaque un serveur en Asie est bloquée préventivement sur votre serveur en Europe, avant même sa première tentative d'attaque.

Cette intelligence collective est puissante. La communauté CrowdSec compte plus de 150,000 instances actives (2026). Chaque jour, des millions d'IPs malveillantes sont détectées et partagées. Votre serveur bénéficie instantanément de cette vigilance globale.

2. Parsers et scénarios modulaires : Plutôt que des regex manuelles, CrowdSec utilise des parsers (comprendre les logs) et des scenarios (détecter les comportements malveillants). Ces composants sont distribués via un Hub communautaire, maintenus collaborativement, et s'installent en une commande. Un nouveau type d'attaque ? Le scénario est créé par la communauté et déployable instantanément sur tous les serveurs.

3. Architecture découplée : CrowdSec sépare détection (agent analysant logs) et remediation (blocage effectif via bouncers). Cette séparation permet une flexibilité extrême : détectez sur un serveur, bloquez sur un firewall centralisé. Ou détectez localement, bloquez via Cloudflare. Les bouncers existent pour iptables, nftables, Nginx, Apache, HAProxy, Cloudflare, AWS WAF, etc.

Cas d'usage modernes

CrowdSec excelle dans plusieurs scénarios critiques :

Protection SSH : Les attaques bruteforce SSH sont ubiquitaires. CrowdSec détecte non seulement les tentatives répétées (comme Fail2ban) mais aussi des patterns subtils : scan de users, exploitation de CVEs, tunneling malveillant. La blocklist communautaire coupe court à 90%+ des tentatives avant même qu'elles n'atteignent sshd.

Protection applicative web : Au-delà du simple rate limiting, CrowdSec détecte des attaques applicatives : SQL injection, path traversal, credential stuffing, API abuse. Les scénarios s'adaptent à votre stack : WordPress, Drupal, APIs REST, etc. Le blocage s'effectue soit au niveau applicatif (bouncer Nginx) soit au firewall (avant que le trafic n'atteigne l'app).

Protection multi-serveurs : Dans une architecture avec load balancer + N backends, CrowdSec centralise la détection et le blocage. Un backend détecte une attaque → l'IP est bloquée sur le LB pour tous les backends. Ou inversement : détection distribuée sur les backends, décisions de blocage consolidées sur un firewall central.

Compliance et audit : CrowdSec log toutes les décisions (ban, captcha, throttle) avec contexte complet. Ces logs sont exploitables pour compliance SOC2, ISO27001, ou forensics post-incident. L'intégration avec SIEM (Splunk, Elasticsearch) est native.

Composants et responsabilités

Comprendre l'architecture CrowdSec est essentiel pour un déploiement optimal. Trois composants principaux :

1. Agent (Security Engine) : Le cœur de CrowdSec. L'agent lit les logs (via files, journald, syslog, etc.), les parse avec les parsers appropriés, et évalue les scénarios de détection. Quand un scénario match (ex: 5 tentatives SSH échouées en 1 minute), l'agent crée une décision de blocage (ban cette IP pendant 4 heures). Ces décisions sont stockées dans une base de données locale (SQLite ou PostgreSQL).

L'agent participe également au réseau collaboratif : il push les signaux d'attaques vers la CrowdSec Central API (opt-in, anonymisé), et pull la blocklist communautaire. Cette synchronisation bidirectionnelle s'effectue toutes les minutes.

2. Local API (LAPI) : Interface entre l'agent et les bouncers. La LAPI expose une API REST que les bouncers interrogent pour récupérer les décisions de blocage. Elle gère l'authentification des bouncers (via API keys), l'agrégation des décisions (dédupe, priorités), et peut être déployée séparément de l'agent pour scale horizontalement dans les grandes infrastructures.

3. Bouncers : Composants d'enforcement qui appliquent les décisions. Chaque bouncer est spécialisé pour une technologie : iptables, nftables, Nginx, HAProxy, Cloudflare, etc. Les bouncers interrogent la LAPI périodiquement (toutes les 10-30 secondes), récupèrent les décisions actives, et les traduisent en actions concrètes (DROP packets, 403 HTTP, Captcha, etc.).

Cette architecture découplée offre une flexibilité unique. Vous pouvez avoir :

• 1 agent, N bouncers sur même host (config simple)
• N agents (multi-hosts), 1 LAPI centralisée, M bouncers (scaling)
• Agents edge + LAPI cloud + bouncers CDN (architecture distribuée)

Data flow et décisions

Suivons le cycle de vie d'une attaque détectée :

1. Génération événement :

Application (sshd) → Log "Failed password for invalid user admin"
→ /var/log/auth.log

2. Collecte par agent :

CrowdSec agent → lit /var/log/auth.log
→ Parser syslog reconnaît format
→ Parser crowdsecurity/sshd-logs extrait : user=admin, IP=1.2.3.4, action=failed

3. Évaluation scénarios :

Scénario crowdsecurity/ssh-bf (bruteforce) :
- Condition : 5 failed attempts en 2 minutes depuis même IP
- IP 1.2.3.4 a maintenant 5 tentatives en 90 secondes
→ Scénario triggered !

4. Création décision :

Agent → Crée décision :
  type: ban
  IP: 1.2.3.4
  durée: 4 heures
  raison: ssh-bf
→ Stocke dans DB locale
→ Push signal vers CrowdSec Central API

5. Bouncer récupère décision :

cs-firewall-bouncer → Poll LAPI toutes les 10s
→ GET /v1/decisions/stream
→ Reçoit : ban 1.2.3.4 pour 4h

6. Application blocage :

cs-firewall-bouncer →
  iptables -A INPUT -s 1.2.3.4 -j DROP
→ IP bloquée immédiatement

7. Bénéfice communautaire :

CrowdSec Central API → Agrège signal de votre serveur
→ IP 1.2.3.4 détectée par 50+ serveurs en 1h
→ Ajoutée à blocklist communautaire
→ Distribuée à 150k+ instances CrowdSec mondialement

Ce cycle prend typiquement 10-30 secondes entre détection initiale et blocage effectif.

Installation agent CrowdSec

L'installation de CrowdSec est standardisée sur les distributions majeures :

Debian/Ubuntu :

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

# Installer agent + cli
sudo apt install crowdsec

# Démarrer service
sudo systemctl enable crowdsec
sudo systemctl start crowdsec

# Vérifier status
sudo cscli version
sudo cscli metrics

# Agent tourne et analyse logs automatiquement

RHEL/CentOS/Fedora :

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

# Installation
sudo dnf install crowdsec

# Démarrage
sudo systemctl enable --now crowdsec

L'installation détecte automatiquement les services actifs (SSH, Nginx, etc.) et configure les parsers/scenarios appropriés. Cette auto-détection fonctionne remarquablement bien dans 90% des cas.

Configuration initiale

Le fichier principal /etc/crowdsec/config.yaml définit la configuration globale :

# /etc/crowdsec/config.yaml

common:
  daemonize: true
  pid_dir: /var/run/
  log_media: file
  log_level: info
  log_dir: /var/log/
  working_dir: .

config_paths:
  config_dir: /etc/crowdsec/
  data_dir: /var/lib/crowdsec/data/
  simulation_path: /etc/crowdsec/simulation.yaml
  hub_dir: /etc/crowdsec/hub/
  index_path: /etc/crowdsec/hub/.index.json

crowdsec_service:
  acquisition_path: /etc/crowdsec/acquis.yaml
  parser_routines: 1

cscli:
  output: human
  color: auto

db_config:
  type: sqlite
  db_path: /var/lib/crowdsec/data/crowdsec.db
  # Ou PostgreSQL pour production HA :
  # type: postgresql
  # host: postgres
  # port: 5432
  # user: crowdsec
  # password: secret
  # db_name: crowdsec

api:
  client:
    credentials_path: /etc/crowdsec/local_api_credentials.yaml
  server:
    listen_uri: 127.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    console_path: /etc/crowdsec/console.yaml
    online_client:
      credentials_path: /etc/crowdsec/online_api_credentials.yaml

Configuration acquisition (/etc/crowdsec/acquis.yaml) définit quels logs lire :

# /etc/crowdsec/acquis.yaml

# Logs SSH via journald
source: journalctl
journalctl_filter:
  - '_SYSTEMD_UNIT=sshd.service'
labels:
  type: syslog

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

---
# Logs Apache
filenames:
  - /var/log/apache2/access.log
  - /var/log/apache2/error.log
labels:
  type: apache2

---
# Logs application custom
filenames:
  - /var/log/myapp/*.log
labels:
  type: syslog

Enrôlement communauté

Pour bénéficier de la threat intelligence collaborative, enrôlez votre instance :

# Enroller vers CrowdSec Central API
sudo cscli console enroll ENROLLMENT_KEY

# Vérifier enrôlement
sudo cscli console status
# Status: enrolled
# Sharing: enabled

# Votre instance partage maintenant signaux d'attaques
# et reçoit la blocklist communautaire

L'ENROLLMENT_KEY est obtenue gratuitement sur app.crowdsec.net. Cet enrôlement est opt-in et anonyme - aucune donnée sensible n'est partagée, seulement les signaux d'attaques (IPs, scénarios).

Comprendre les parsers

Les parsers transforment les logs bruts en événements structurés exploitables par les scénarios. Chaque parser est spécialisé pour un format de log :

# Parser syslog (simplifié)
name: crowdsecurity/syslog-logs
description: Parse syslog format
grok:
  pattern: '%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:logsource} %{SYSLOGPROG}: %{GREEDYDATA:message}'
  apply_on: message

# Parser SSH (s'enchaîne après syslog)
name: crowdsecurity/sshd-logs
description: Parse OpenSSH logs
onsuccess: next_stage
grok:
  patterns:
    - 'Failed password for %{USERNAME:user} from %{IP:source_ip}'
    - 'Accepted password for %{USERNAME:user} from %{IP:source_ip}'
  apply_on: message
statics:
  - parsed: service
    value: ssh
  - parsed: evt.type
    value: auth

Les parsers s'enchaînent en stages : syslog → sshd-logs. Chaque parser enrichit l'événement avec des champs structurés (source_ip, user, action, etc.).

Scénarios de détection

Les scénarios définissent les comportements malveillants à détecter :

# Scénario SSH bruteforce (simplifié)
name: crowdsecurity/ssh-bf
description: Detect SSH bruteforce
type: leaky_bucket
capacity: 5 # Nombre tentatives autorisées
leakspeed: 2m # Fenêtre temporelle
groupby: source_ip # Grouper par IP attaquante
filter: "evt.type == 'auth' && evt.outcome == 'failure' && evt.service == 'ssh'"
blackhole: 4h # Durée ban
labels:
  service: ssh
  type: bruteforce
  remediation: true

Ce scénario détecte 5 tentatives SSH échouées en 2 minutes depuis une même IP et crée un ban de 4h.

Leaky bucket : Concept élégant pour rate limiting. Imaginez un seau percé : chaque tentative échouée ajoute une unité, le seau se vide lentement (leak). Si le seau déborde (capacity dépassée), l'attaque est confirmée.

Hub : installer composants

Le CrowdSec Hub centralise parsers, scénarios, collections (bundles), et post-overflows :

# Lister collections disponibles
cscli collections list

# Installer collection Linux complète
sudo cscli collections install crowdsecurity/linux

# Cette collection inclut automatiquement :
# - Parsers : syslog, sshd, nginx, apache, etc.
# - Scénarios : ssh-bf, http-bf, http-scan, etc.

# Installer scénarios additionnels
sudo cscli scenarios install crowdsecurity/http-path-traversal
sudo cscli scenarios install crowdsecurity/http-sqli

# Installer parser spécifique
sudo cscli parsers install crowdsecurity/postfix-logs

# Mettre à jour tous composants
sudo cscli hub update
sudo cscli hub upgrade

# Recharger CrowdSec après installation
sudo systemctl reload crowdsec

Les collections simplifient grandement la configuration. crowdsecurity/linux couvre 95% des besoins typiques d'un serveur Linux. Des collections spécialisées existent : WordPress, Drupal, NextCloud, etc.

Firewall bouncer (iptables/nftables)

Le bouncer firewall bloque au niveau réseau, empêchant le trafic malveillant d'atteindre les services :

Installation :

# Ubuntu/Debian
sudo apt install crowdsec-firewall-bouncer-iptables

# Configuration
sudo nano /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Configuration :

# /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

mode: iptables # Ou nftables
pid_dir: /var/run/
update_frequency: 10s # Fréquence poll LAPI

log_mode: file
log_dir: /var/log/
log_level: info

api_url: http://localhost:8080/
api_key: YOUR_API_KEY

# Actions
deny_action: DROP # DROP ou REJECT
deny_log: true

Générer API key :

# Créer bouncer dans LAPI
sudo cscli bouncers add firewall-bouncer

# Output : API key
# API key: abc123def456...

# Insérer dans config bouncer
# Puis restart
sudo systemctl restart crowdsec-firewall-bouncer

# Vérifier status
sudo cscli bouncers list
# NAME              IP ADDRESS  VALID  LAST API PULL         TYPE
# firewall-bouncer  127.0.0.1   ✔️      2024-01-24T14:32:10  firewall

Le bouncer crée automatiquement des chaînes iptables dédiées :

# Voir règles créées
sudo iptables -L crowdsec-chain -n -v

# Exemple output :
# Chain crowdsec-chain (1 references)
# target     prot opt source        destination
# DROP       all  --  1.2.3.4       0.0.0.0/0     # ssh-bf
# DROP       all  --  5.6.7.8       0.0.0.0/0     # http-bf
# ...

Nginx bouncer

Le bouncer Nginx bloque au niveau applicatif, permettant des actions plus fines (403, captcha, throttle) :

Installation :

# Dépendances Lua
sudo apt install lua-nginx-module libnginx-mod-http-lua

# Bouncer
sudo apt install crowdsec-nginx-bouncer

# Configuration
sudo nano /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf

Configuration Nginx :

# /etc/nginx/sites-enabled/default

http {
    # Charger module CrowdSec
    lua_shared_dict crowdsec_cache 50m;

    init_by_lua_block {
        cs = require "crowdsec"
        cs.init("/etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf")
    }

    server {
        listen 80;
        server_name example.com;

        # Check CrowdSec avant traitement
        access_by_lua_block {
            cs.allow()
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

Le bouncer Nginx offre des remediations variées :

• ban : 403 Forbidden
• captcha : Challenge JavaScript (comme Cloudflare)
• throttle : Rate limiting (X req/min)

Configuration remediations :

# /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf

api_url: http://localhost:8080/
api_key: BOUNCER_API_KEY

mode: stream # live, stream, ou file
update_frequency: 10s

# Actions par type décision
ban_template_path: /etc/crowdsec/bouncers/templates/ban.html
captcha_template_path: /etc/crowdsec/bouncers/templates/captcha.html

# Captcha provider
captcha_provider: recaptcha
recaptcha_site_key: YOUR_SITE_KEY
recaptcha_secret_key: YOUR_SECRET_KEY

# Throttle settings
throttle_enabled: true
throttle_duration: 60 # Limite X req pendant 60s

Cloudflare bouncer

Pour sites derrière Cloudflare, le bouncer CF bloque directement dans le CDN :

# Installation
curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec-cloudflare-bouncer

# Configuration
sudo nano /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml

Configuration :

# /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml

crowdsec_lapi_url: http://localhost:8080/
crowdsec_lapi_key: BOUNCER_API_KEY

cloudflare_token: YOUR_CF_API_TOKEN
cloudflare_zone_id: YOUR_ZONE_ID

update_frequency: 30s

# Actions
cloudflare_ban_action: managed_challenge # block, challenge, managed_challenge

Avec ce setup, les IPs malveillantes sont bloquées dans Cloudflare avant d'atteindre votre serveur origin. Économie de bande passante et protection DDoS renforcée.

Types de décisions

CrowdSec supporte plusieurs types de décisions :

ban : Blocage total de l'IP

# Créer ban manuel
sudo cscli decisions add -i 1.2.3.4 -d 1h -r "manual ban - abuse"

# Lister bans actifs
sudo cscli decisions list

# Supprimer ban
sudo cscli decisions delete -i 1.2.3.4

captcha : Challenge JavaScript (bouncer applicatif requis)

sudo cscli decisions add -i 1.2.3.4 -t captcha -d 30m

throttle : Rate limiting

sudo cscli decisions add -i 1.2.3.4 -t throttle -d 1h

Scopes et durées

Les décisions ont des scopes (portée) et durées configurables :

Scope IP : Bloquer une IP individuelle

sudo cscli decisions add -i 5.6.7.8 -d 4h

Scope Range : Bloquer un subnet entier

sudo cscli decisions add -r 5.6.7.0/24 -d 12h -r "spam network"

Scope AS : Bloquer un Autonomous System

sudo cscli decisions add --as 12345 -d 24h -r "hostile AS"

Durées intelligentes : CrowdSec adapte automatiquement les durées selon la sévérité :

• Première offense : 4h
• Récidive (IP réattaque après ban) : 24h
• Récidive multiple : 7 jours
• IP dans blocklist communautaire : jusqu'à 30 jours

Cette escalade décourage les attaquants persistants.

Whitelists et simulation

Whitelists : Ne jamais bloquer certaines IPs (vos propres IPs, IPs office, etc.) :

# Whitelist IP
sudo cscli parsers install crowdsecurity/whitelists

# Éditer whitelist
sudo nano /etc/crowdsec/parsers/s02-enrich/whitelist.yaml

whitelist.yaml :

name: crowdsecurity/whitelist
description: Whitelist IPs
whitelist:
  reason: Whitelisted
  ip:
    - 203.0.113.1 # Office IP
    - 203.0.113.0/24 # Office subnet
  expression:
    # Ne pas bloquer localhost
    - evt.Parsed.source_ip == '127.0.0.1'

Mode simulation : Tester sans bloquer (dry-run) :

# Activer simulation pour un scénario
sudo nano /etc/crowdsec/simulation.yaml

# /etc/crowdsec/simulation.yaml
simulation: true # Global simulation

# Ou simulation par scénario
scenarios:
  - crowdsecurity/ssh-bf # Simule seulement SSH BF

En simulation, les décisions sont créées mais pas appliquées par les bouncers. Utile pour valider la config avant production.

Métriques et dashboard

CrowdSec expose des métriques via cscli et console web :

# Métriques CLI
sudo cscli metrics

# Output :
# Acquisition Metrics:
# ╭──────────────┬────────────┬────────────╮
# │   Source     │  Lines read│ Lines parsed│
# ├──────────────┼────────────┼────────────┤
# │ file:/var/log│   12,450   │   12,401   │
# │/nginx/access │            │            │
# ╰──────────────┴────────────┴────────────╯
#
# Parser Metrics:
# ╭─────────────────┬──────┬────────╮
# │     Parser      │ Hits │ Parsed │
# ├─────────────────┼──────┼────────┤
# │crowdsecurity/   │ 8,234│ 8,234  │
# │nginx-logs       │      │        │
# ╰─────────────────┴──────┴────────╯
#
# Scenario Metrics:
# ╭─────────────────┬──────────┬────────╮
# │    Scenario     │Triggered │Current │
# │                 │          │Decisions│
# ├─────────────────┼──────────┼────────┤
# │crowdsecurity/   │    45    │   23   │
# │ssh-bf           │          │        │
# │crowdsecurity/   │    12    │    5   │
# │http-bf          │          │        │
# ╰─────────────────┴──────────┴────────╯

# Décisions actives
sudo cscli decisions list

# Alertes (événements déclenchés)
sudo cscli alerts list

Console web : Via app.crowdsec.net après enrôlement, dashboard interactif avec :

• Timeline des attaques
• Top IPs malveillantes
• Scenarios les plus triggérés
• Carte géographique des attaques
• Contribution à la communauté (signaux partagés)

Intégration Prometheus

La LAPI CrowdSec expose nativement les métriques Prometheus sur /metrics sans plugin supplémentaire :

# Métriques directement accessibles
curl http://localhost:8080/metrics

# Ajouter à Prometheus scrape config
# /etc/prometheus/prometheus.yml
scrape_configs:
  - job_name: 'crowdsec'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'

Métriques exportées :

# Décisions actives
crowdsec_decisions_total{type="ban"}

# Alertes par scénario
crowdsec_alerts_total{scenario="crowdsecurity/ssh-bf"}

# Lignes parsées
crowdsec_parser_hits_total{parser="crowdsecurity/nginx-logs"}

# Bouncers actifs
crowdsec_bouncers_total

Grafana dashboard : Importer dashboard ID 15824 pour visualiser CrowdSec dans Grafana.

Alertes personnalisées

Configurez des notifications pour événements critiques :

# /etc/crowdsec/profiles.yaml

name: default_ip_remediation
filters:
  - Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
  - type: ban
    duration: 4h
on_success: break
notifications:
  - slack_alerts # Référence vers plugin Slack

---
# /etc/crowdsec/notifications/slack.yaml
type: slack
name: slack_alerts
webhook: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
format: |
  🚨 CrowdSec Alert
  Scenario: {{.Alert.GetScenario}}
  IP: {{.Alert.GetValue}}
  Duration: {{.Alert.GetDecisions.Duration}}

Slack reçoit une notification à chaque attaque détectée. Plugins similaires existent pour Email, Telegram, PagerDuty, etc.

Protection serveur web Nginx

Configuration complète pour protéger un serveur web :

1. Installer CrowdSec + collections web :

sudo apt install crowdsec
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/http-cve

2. Configurer acquisition Nginx :

# /etc/crowdsec/acquis.yaml
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx

3. Installer bouncer Nginx :

sudo apt install crowdsec-nginx-bouncer
# Configuration dans section précédente

4. Activer scénarios avancés :

# Détection CVEs web
sudo cscli scenarios install crowdsecurity/http-cve-2021-41773
sudo cscli scenarios install crowdsecurity/http-cve-2021-42013

# Détection scans
sudo cscli scenarios install crowdsecurity/http-probing
sudo cscli scenarios install crowdsecurity/http-crawl-non_statics

5. Tuning sensibilité :

# /etc/crowdsec/scenarios/http-bf.yaml
# Ajuster selon trafic légitime
capacity: 10 # 10 tentatives au lieu de 5
leakspeed: 5m # Fenêtre 5 min au lieu de 2

Architecture multi-serveurs

Pour infrastructure avec N serveurs backends + 1 LB :

Setup : LAPI centralisée, agents distribués, bouncer sur LB.

LB (LAPI + bouncer) :

# Installer LAPI standalone
sudo apt install crowdsec

# Configurer listen externe
# /etc/crowdsec/config.yaml
api:
  server:
    listen_uri: 0.0.0.0:8080  # Pas seulement 127.0.0.1

# Installer bouncer firewall sur LB
sudo apt install crowdsec-firewall-bouncer-iptables

Backends (agents seulement) :

# Installer agent
sudo apt install crowdsec

# Pointer vers LAPI centrale
# /etc/crowdsec/config.yaml
api:
  client:
    credentials_path: /etc/crowdsec/local_api_credentials.yaml

# /etc/crowdsec/local_api_credentials.yaml
url: http://lb-internal:8080/
login: backend-agent-1
password: GENERATED_PASSWORD

Générer credentials agents (sur LB) :

# Créer agent machine account
sudo cscli machines add backend-agent-1
# Output : password

# Répéter pour chaque backend
sudo cscli machines add backend-agent-2
sudo cscli machines add backend-agent-3

Avec ce setup, les backends détectent et remontent vers LAPI centrale, le bouncer LB bloque pour tous.

Export vers Elasticsearch

Pour compliance et forensics, exportez les décisions vers Elasticsearch via le système de notification (pas de plugin separate) :

Configuration notification :

# /etc/crowdsec/notifications/elasticsearch.yaml
type: elasticsearch
name: elasticsearch_export

url: http://elasticsearch:9200
index: crowdsec-decisions
username: crowdsec
password: ${ES_PASSWORD}

# Format JSON enrichi
format: |
  {
    "timestamp": "{{.Alert.CreatedAt}}",
    "scenario": "{{.Alert.GetScenario}}",
    "ip": "{{.Alert.GetValue}}",
    "duration": "{{.Alert.GetDecisions.Duration}}",
    "reason": "{{.Alert.Message}}",
    "source": "{{.Alert.Source.IP}}",
    "events_count": {{.Alert.EventsCount}},
    "server": "{{.MachineID}}"
  }

Les décisions sont indexées dans Elasticsearch, exploitables pour :

• Dashboards Kibana temps réel
• Alertes ML (détecter patterns anormaux)
• Forensics post-incident
• Compliance audits

Corrélation avec logs applicatifs

Enrichissez vos logs applicatifs avec décisions CrowdSec :

Exemple Nginx log format :

# /etc/nginx/nginx.conf
http {
    log_format crowdsec '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent" '
                        'crowdsec_decision=$http_x_crowdsec_decision';

    access_log /var/log/nginx/access.log crowdsec;
}

Le bouncer Nginx ajoute un header X-CrowdSec-Decision (ban/captcha/allow), logged par Nginx. Corrélation immédiate entre accès web et décision CrowdSec.

Optimisation parsers

Les parsers sont évalués séquentiellement. Optimisez l'ordre :

# Voir ordre actuel
ls -la /etc/crowdsec/parsers/s01-parse/

# Les parsers plus fréquents devraient être premiers
# Ex: syslog avant postfix (plus de logs syslog que postfix)

Désactiver parsers inutiles :

# Si pas de Postfix installé, désactiver parser
sudo cscli parsers remove crowdsecurity/postfix-logs

Tuning base de données

Par défaut, CrowdSec utilise SQLite. Pour production HA ou haute volumétrie, passez à PostgreSQL :

# /etc/crowdsec/config.yaml
db_config:
  type: postgresql
  host: postgres.internal
  port: 5432
  user: crowdsec
  password: ${DB_PASSWORD}
  db_name: crowdsec
  sslmode: require

PostgreSQL offre meilleures performances pour :

• Décisions volumétrie élevée (100k+ IPs bloquées)
• Requêtes bouncers concurrentes (50+ bouncers)
• LAPI haute disponibilité (plusieurs instances LAPI)

Caching bouncers

Les bouncers maintiennent un cache local des décisions pour réduire la latence :

# /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
cache_retention_duration: 60s # Durée cache locale

# Le bouncer query LAPI seulement toutes les update_frequency (10s)
# Entre-temps, il utilise le cache → latence <1ms

Pour bouncers applicatifs (Nginx, HAProxy), augmentez le cache :

# Nginx bouncer
lua_shared_dict crowdsec_cache 100m;  # 100 MB cache

Problèmes courants

Agent ne détecte pas d'attaques :

Symptôme : cscli metrics montre 0 scenarios triggered

Diagnostic :

# Vérifier acquisition fonctionne
sudo cscli metrics
# Lines read > 0 ? Sinon, logs pas lus

# Vérifier parsers matchent
sudo journalctl -u crowdsec -f
# Observer si logs parsés correctement

# Tester parser manuellement
echo "Jan 24 14:30:00 server sshd[12345]: Failed password for invalid user admin from 1.2.3.4" | \
  sudo cscli explain --dsn "file://-" --type syslog

Faux positifs (légitime bloqué) :

Symptôme : Utilisateurs légitimes bloqués

Solution :

# Identifier décision problématique
sudo cscli decisions list

# Supprimer
sudo cscli decisions delete -i LEGITIMATE_IP

# Whitelist
sudo nano /etc/crowdsec/parsers/s02-enrich/whitelist.yaml
# Ajouter IP à whitelist

# Ou ajuster sensibilité scénario
# Ex: SSH BF capacity: 5 → 10

Bouncer ne bloque pas :

Symptôme : Décisions créées mais IPs pas bloquées

Diagnostic :

# Vérifier bouncer actif
sudo cscli bouncers list
# Last API pull récent (<1 min) ?

# Vérifier bouncer a les décisions
curl -H "X-Api-Key: BOUNCER_API_KEY" \
  http://localhost:8080/v1/decisions/stream
# Retourne liste décisions ?

# Vérifier firewall rules créées
sudo iptables -L crowdsec-chain -n
# IPs présentes ?

# Logs bouncer
sudo journalctl -u crowdsec-firewall-bouncer -f

Checklist production

Avant de déployer CrowdSec en production :

□ Agent installé et opérationnel
□ Collections appropriées installées (linux, nginx, etc.)
□ Acquisition configurée pour tous logs critiques
□ Enrôlement communauté activé
□ Au moins 1 bouncer configuré (firewall ou applicatif)
□ Whitelist IPs internes/office configurée
□ Mode simulation testé (pas de faux positifs)
□ Métriques monitoring configurées (Prometheus/Grafana)
□ Alertes notifications configurées (Slack/Email)
□ Backup configuration (/etc/crowdsec/)
□ Runbooks documentation créée

CrowdSec révolutionne la sécurité serveur en combinant détection locale intelligente et intelligence collective globale. Son approche collaborative transforme chaque serveur protégé en sentinelle bénéficiant à toute la communauté, créant un réseau de défense distribué extrêmement résilient.

Points clés :

• Intelligence collaborative : Threat intelligence partagée entre 150k+ instances
• Parsers/Scenarios modulaires : Déploiement rapide via Hub communautaire
• Architecture découplée : Agent (détection) + Bouncers (enforcement) flexibles
• Multi-plateforme : Firewall, Nginx, Apache, Cloudflare, AWS WAF, etc.
• Open-source et gratuit : Pas de vendor lock-in, communauté active

Commandes essentielles :

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

# Collections
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/nginx

# Monitoring
sudo cscli metrics
sudo cscli decisions list
sudo cscli alerts list

# Bouncer
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers add firewall-bouncer

Avec CrowdSec, transformez votre infrastructure en forteresse collaborative où chaque attaque détectée renforce la sécurité de l'ensemble de la communauté. La sécurité devient un bien commun, pas un combat solitaire.