Mettre en place une instance centrale CrowdSec pour sécuriser son infrastructure

Dans un contexte où les attaques automatisées sont de plus en plus fréquentes (scan de ports, brute force, exploitation de failles connues…), sécuriser efficacement son infrastructure devient indispensable. Si vous gérez plusieurs serveurs, répéter la même configuration de sécurité sur chacun peut vite devenir contraignant, difficile à maintenir et peu cohérent.

C’est là qu’intervient CrowdSec avec son mode de fonctionnement collaboratif et distribué. Mais pour aller plus loin, il est possible de mettre en place une architecture centralisée, permettant de mutualiser la détection des menaces tout en simplifiant l’administration.

Dans ce tutoriel, nous allons voir comment déployer une instance centrale CrowdSec afin de collecter les événements de plusieurs machines, analyser les comportements suspects et appliquer des décisions de sécurité de manière cohérente sur l’ensemble de votre infrastructure. L’objectif est double : gagner en efficacité face aux attaques et simplifier la gestion de votre sécurité au quotidien.

Nous partirons d’une installation propre pour aller jusqu’à une configuration fonctionnelle, prête à être intégrée dans un environnement réel.

Présentation de Crowdsec

CrowdSec est une solution de sécurité open source qui permet de détecter et bloquer les comportements malveillants sur vos serveurs. Contrairement à des outils plus classiques comme Fail2ban, qui fonctionnent de manière isolée sur chaque machine, CrowdSec adopte une approche collaborative et moderne de la cybersécurité.

Son fonctionnement repose sur l’analyse des logs (SSH, Nginx, Apache, etc.) afin d’identifier des comportements suspects, comme des tentatives de brute force ou des scans automatisés. Lorsqu’une activité malveillante est détectée, CrowdSec génère une décision (par exemple un bannissement d’adresse IP), qui peut être appliquée via des “bouncers” (pare-feu, reverse proxy, CDN…).

L’un des points forts de CrowdSec est sa dimension communautaire : il s’appuie sur une base de données partagée d’adresses IP malveillantes, alimentée en temps réel par les utilisateurs du monde entier. Cela permet de se protéger non seulement des attaques en cours, mais aussi d’anticiper celles déjà observées ailleurs.

Dans une architecture classique, chaque serveur exécute sa propre instance de CrowdSec. Mais il est également possible d’aller plus loin en mettant en place une instance centrale, capable de :

• centraliser l’analyse des logs provenant de plusieurs machines,
• mutualiser la détection des menaces,
• distribuer les décisions de sécurité de manière cohérente.

Cette approche est particulièrement intéressante dans des environnements multi-serveurs, où elle permet de gagner en efficacité, en visibilité et en simplicité d’administration.

Constat

Sur de nombreux sites — et rdr-it.com ne fait pas exception — l’utilisation de CrowdSec est souvent présentée dans un contexte simple : sécuriser un serveur directement exposé sur Internet (VPS ou serveur dédié), principalement pour protéger un serveur web et les accès SSH, voire quelques applications spécifiques.

Ces mises en œuvre ont l’avantage d’être rapides à déployer et pédagogiques, mais elles montrent rapidement leurs limites dès que l’on passe à une infrastructure un peu plus complète. En entreprise, les services sont généralement répartis sur plusieurs serveurs : reverse proxy, applications métiers, outils collaboratifs, authentification, etc. Installer et maintenir une instance de CrowdSec sur chaque machine devient alors chronophage… et dans la pratique, ce n’est pas toujours fait.

Dans ce contexte, on retrouve souvent un schéma “minimaliste” : CrowdSec est installé uniquement sur le reverse proxy pour analyser les logs HTTP(S). C’est déjà un bon début, mais cela reste incomplet. Chaque instance fonctionne de manière isolée, les serveurs ne partagent pas leurs informations et ne se protègent qu’eux-mêmes. On passe donc à côté de tout l’intérêt d’une détection globale et corrélée des attaques.

Pourtant, dans de nombreuses infrastructures, un élément central existe déjà : le firewall. Celui-ci est capable d’appliquer des règles de filtrage globales, à condition de lui fournir une liste d’adresses IP malveillantes pertinente et à jour.

L’idée est donc d’aller plus loin en mettant en place une instance centrale CrowdSec. Celle-ci va collecter les logs de l’ensemble des serveurs (via des outils comme rsyslog), analyser les comportements et produire une liste consolidée d’adresses IP à bloquer.

Cette approche présente plusieurs avantages :

• une centralisation de l’analyse, plus simple à maintenir,
• une corrélation des événements entre plusieurs services,
• et surtout une protection globale de l’infrastructure via le firewall.

Concrètement, cela permet de détecter et bloquer efficacement des menaces variées : brute force sur des outils comme Authentik ou Nextcloud, scans de découverte WordPress, attaques sur SSH ou encore comportements suspects sur vos applications web… le tout avec une seule instance de CrowdSec et une politique de blocage unifiée.

Étant donné que nous allons aborder ici un déploiement plus avancé de CrowdSec, il est important de préciser que ce tutoriel va se concentrer sur les grandes étapes de mise en place.

Chaque infrastructure étant différente (architecture réseau, types de services, organisation des logs, sécurité existante…), les exemples et configurations proposés devront être adaptés à votre contexte. L’objectif est de vous fournir une base solide et une vision globale du fonctionnement, afin que vous puissiez ensuite l’ajuster selon vos besoins et vos contraintes.

Déploiement de Crowdsec

Pour ce type de déploiement avec CrowdSec, il est recommandé de dédier une machine (physique ou virtuelle) sous Linux à cette fonction. Cela permet d’isoler le traitement des logs et d’éviter d’impacter les performances des serveurs applicatifs.

Le déploiement peut se faire directement sur le système ou via des conteneurs Docker. Le choix dépend surtout de vos habitudes. Dans mon cas, je privilégie une installation en conteneur, que je trouve plus simple à maintenir et à faire évoluer (mise à jour, rollback, portabilité…).

Concernant le positionnement dans l’infrastructure, l’idéal est de placer cette machine en DMZ. Elle va agir comme point central de collecte et d’analyse des logs. Si vos serveurs applicatifs sont répartis sur différents VLAN, il faudra bien entendu autoriser les flux réseau nécessaires vers cette instance.

Concrètement, il est nécessaire de permettre l’envoi des logs vers ce serveur, généralement via rsyslog en TCP et/ou UDP sur le port 514. Pensez à adapter vos règles de filtrage en conséquence pour garantir une communication fiable entre vos serveurs et votre instance centrale CrowdSec.

A titre d’exemple voici mon fichier docker-compose.yml :

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    restart: always
    user: root
    environment:
      COLLECTIONS: "crowdsecurity/nginx crowdsecurity/sshd crowdsecurity/wordpress crowdsecurity/base-http-scenarios crowdsecurity/http-cve crowdsecurity/http-dos firix/authentik crowdsecurity/nextcloud crowdsecurity/apache2 corvese/apache-guacamole crowdsecurity/iis crowdsecurity/exchange crowdsecurity/windows"
      GID: "${GID-1000}"
      TZ: "Europe/Paris"
      DISABLE_ONLINE_API: true
    ports:
      - 8080:8080
      - 6060:6060
    volumes:
      #- /var/log:/var/log
      - /var/log/remote-logs/nginx:/var/log/nginx
      - /var/log/remote-logs/docker:/var/log/docker
      #- /var/log/remote-logs/windows:/var/log/windows
      - ./crowdsec/db:/var/lib/crowdsec/data/
      - ./crowdsec/config:/etc/crowdsec/
    networks:
      crowdsec_network:
        ipv4_address: 10.199.0.5
      crowdsec-net:

networks:
  crowdsec_network:
    ipam:
      driver: default
      config:
        - subnet: 10.199.0.0/24
  crowdsec-net:
    external: true

Pour vous aidez dans le déploiements de Crowdsec :

• Crowdsec : sécuriser vos serveurs – installation et configuration
• Crowdsec : installation et configuration en conteneur avec Docker
  

Configuration de rsyslog

Pour commencer installer rsyslog si celui-ci n’est pas présent :

apt install rsyslog -y

Activer rsyslog au démarrage

systemctl enable rsyslog

Vérifier le statut :

systemctl status rsyslog

Démarrer rsyslog si celui-ci ne l’est pas :

systemctl start rsyslog

Créer le ou les dossiers pour le stockage des logs : /var/log/remote-logs

sudo mkdir -p /var/log/remote-logs /var/log-remote-logs/{nginx,docker}

On va maintenant créer le fichier de collecte des logs pour nginx :

nano "etc/rsyslog.d/10-remote.conf

Son contenu :

# Site : rdr-it.com
if $programname == 'nginx-rdritcom' then /var/log/remote-logs/nginx/rdr-it.com.access.log
& stop

# Site : crowdsec.com
if $programname == 'nginx-crowdseccom' then /var/log/remote-logs/nginx/crowdsec.com.access.log
& stop

# Site : exemple.com
if $programname == 'nginx-exemplecom' then /var/log/remote-logs/nginx/exemple.com.access.log
& stop

Editer le fichier /etc/rsyslog.conf pour activer le provider tcp sur le port 514 :

nano /etc/rsyslog.conf

Dans le section modules ajouter :

# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

Redémarrer le service rsyslog :

systemctl restart rsyslog

Le service syslog est prêt à recevoir des logs.

Configurer le service Nginx pour envoyer les logs au serveur rsyslog

Il existe plusieurs solutions pour transférer les logs du serveur Nginx vers le service syslog du serveur Crowdsec :

• Configuration du niveau des virtualhosts
• Configurer le service rsyslog sur le serveur Nginx pour lire les fichiers et les envoyer au serveur Crowdsec

Ayant tester les deux solutions, j’ai une préférence pour la seconde que je vais vous expliquer ici, comme sur le serveur Crowdsec, vous avez besoin d’avoir le service rsyslog d’installé et d’activer.

Fichier de configuration pour envoyer les logs : /etc/rsyslog.d/nginx-stream.conf

nano /etc/rsyslog.d/nginx-stream.conf

Contenu :

# Site : rdr-it.com
input(type="imfile"
      File="/containers/nginx-rproxy/logs/rdr-it.com.access.log"
      Tag="nginx-rdritcom:"
      Severity="info"
      Facility="local7")

# Site : crowdsec.com
input(type="imfile"
      File="/containers/nginx-rproxy/logs/crowdsec.com.access.log"
      Tag="nginx-crowdseccom:"
      Severity="info"
      Facility="local7")

# Site : exemple.com
input(type="imfile"
      File="/containers/nginx-rproxy/logs/exemple.com.access.log"
      Tag="nginx-exemplecom:"
      Severity="info"
      Facility="local7")

local7.* @@<IP-SERVER-CROWDSEC>:514

Comment vous pouvez le voir, le tag ici correspond au programme sur le serveur rsyslog de Crowdsec

Dans le fichier de configuration du service /etc/rsyslog.conf, charger le module imfile

# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html


#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

module(load="imfile")

...

Redémarrer le service rsyslog, à partir de là, vous devriez avoir des logs qui arrive sur rsyslog Crowdsec.

Configuration de Crowdsec pour lire les logs Nginx

Dans le dossier config/acquis.d/ créer le fichier nginx.yaml avec le contenu suivant :

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

Redémarrer Crowdsec pour la prise et à partir de , Crowdsec va commencer à analyser les logs Nginx, utiliser la commande suivant pour vérifier :

cscli metrics
# ou
docker compose exec crowdsec cscli metrics

Ajouter le bouncer: Crowdsec blocklist Mirror

Vous trouverez dans ce tutoriel : Crowdsec : intégration avec les pares-feu Fortigate – Fortinet, toutes les explications pas à pas pour configurer le bouncer et aussi l’ajouter à un firewall fortigate.

Si vous êtes utilisateur de OPNsense, le tutoriel suivant : OPNsense : bloquer des adresses IP avec une liste externe et une règle de firewall explique comment ajouter une liste d’adresse IP et configurer le blocage.

Plus d’applications

Jusqu’ici, nous avons vu comment centraliser les logs de CrowdSec pour Nginx. Et comme évoqué au début de ce tutoriel, l’objectif est justement d’aller plus loin en intégrant d’autres applications comme Nextcloud ou Authentik.

Pour le moment, nous sommes sur la partie la plus “simple” du déploiement : Nginx est en effet pris en charge nativement par CrowdSec en mode Syslog, ce qui facilite grandement l’intégration.

Mais c’est à partir d’ici que les choses deviennent plus intéressantes.

La majorité des scénarios (scenarios) disponibles dans CrowdSec sont conçus pour fonctionner avec des logs bruts, directement issus des fichiers applicatifs. Ce n’est plus forcément le cas lorsque les logs sont centralisés via Syslog, et encore moins lorsque les applications tournent dans des environnements conteneurisés.

C’est notamment le cas pour des applications comme Nextcloud ou Authentik, où les formats de logs peuvent varier, être enrichis, ou simplement ne pas correspondre directement aux patterns attendus par les parsers standards.

Heureusement, la combinaison de rsyslog et CrowdSec offre une grande flexibilité. Il est possible de transformer, enrichir ou normaliser les logs en amont avant qu’ils ne soient analysés. Rsyslog peut déjà effectuer une première mise en forme, filtrage ou routage des événements.

Et si cela ne suffit pas, CrowdSec permet d’aller encore plus loin en créant ses propres parsers personnalisés, afin d’adapter précisément l’analyse aux formats de logs de vos applications.

C’est cette approche hybride — transformation côté syslog + adaptation côté CrowdSec — qui permet de rendre le système réellement efficace dans des environnements complexes et hétérogènes.

En cas de blocage, n’hésiter à faire appel au IA qui peuvent être d’une grande aide, Gemini et Claude sont pas mal pour ça.

Nextcloud en conteneur Docker

Commencer par éditer le fichier de configuration config.php de Nextcloud pour avoir la sortie des logs dans le stream du conteneur à l’aide de PHP :

'log_type' => 'errorlog',
'loglevel' => 2,

Modifier le fichier docker-compose.yml pour envoyer les logs vers le service rsyslog sur le serveur Crowdsec du service de l’application Nextcloud:

    logging:
      driver: syslog
      options:
        syslog-address: "tcp://<IP-SERVER-CROWDSEC>:514"
        # On utilise un préfixe fixe pour faciliter le filtrage rsyslog
        tag: "docker_{{.Name}}"

Sur le serveur Crowdsec, créer un fichier de configuration dédié au logs Nextcloud :

nano /etc/rsyslog.d/11-nextcloud.conf

Contenu :

# --- SECTION NEXTCLOUD NETTOYAGE ---
# Template qui supprime l'espace initial (on commence au caractère 2)
template(name="TmplNextcloudClean" type="string" string="%msg:2:$%\n")
# Filtrage : On ne garde que si c'est le bon conteneur ET qu'il contient le tag applicatif Nextcloud
if ($programname == 'docker_{{name}}' and $msg contains '[nextcloud]') then {
    action(type="omfile" file="/var/log/remote-logs/docker/nextcloud_clean.log" template="TmplNextcloudClean")
    stop
}

Remplacer {{name}} par le nom du service en fonctionnement disponible avec docker ps.

Au niveau de Crowdsec acquid.d/nextcloud.yaml :

---
filenames:
 - /var/log/docker/nextcloud_clean.log
labels:
  type: Nextcloud

Authentik en conteneur Docker

Editer le fichier docker-compose.yml d’Authentik pour envoyer les logs au serveur Crowdsec :

    logging:
      driver: syslog
      options:
        syslog-address: "tcp://<IP-SERVER-CROWDSEC>:514"
        # On utilise un préfixe fixe pour faciliter le filtrage rsyslog
        tag: "docker_{{.Name}}"

Fichier de configuration rsyslog :

nano /etc/rsyslog.d/12-authentik.conf

Contenu :

template(name="TmplAuthentikClean" type="string" string="%msg:2:$%\n")

if ($programname startswith 'docker_authentik') then {
    # On filtre pour ne garder que les erreurs ou les échecs de login
    # On ignore les GET API 200 qui saturent tes logs
    if ($msg contains 'failed' or $msg contains 'invalid' or $msg contains 'warning' or $msg contains 'error') then {
        action(type="omfile" file="/var/log/remote-logs/docker/authentik_clean.log" template="TmplAuthentikClean")
        stop
    }
    # On stoppe ici pour que les logs API normaux n'aillent pas dans le fichier docker général
    stop
}

Au niveau de Crowdsec acquid.d/authentik.yaml :

---
filenames:
 - /var/log/docker/authentik_clean.log
labels:
  type: authentik

Bonus : rotation des logs rsyslog

Penser à mettre en une place un rotation des logs : /etc/logrotate.d/remote-logs

/var/log/remote-logs/*/*.log {
    su root adm
    copytruncate
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
}

Conclusion

La mise en place d’une instance centrale de CrowdSec permet de passer d’une sécurité “locale” à une approche globale et cohérente de la protection de votre infrastructure.

En centralisant les logs, en corrélant les घटनements et en déléguant le blocage à un élément central comme un firewall, vous gagnez à la fois en efficacité, en visibilité et en simplicité d’administration. Cette architecture prend tout son sens dans des environnements multi-serveurs, où les attaques ne ciblent pas uniquement un point d’entrée mais l’ensemble des services exposés.

Bien entendu, ce type de déploiement demande un peu plus de travail qu’une installation classique, notamment sur la gestion des logs et l’adaptation des parsers. Mais une fois en place, il offre un niveau de protection bien supérieur et surtout évolutif.

Il existe également des méthodes pour contourner certains mécanismes de sécurité (comme la suppression des messages d’avertissement côté utilisateur), mais volontairement, elles ne sont pas abordées ici. Aujourd’hui, face aux risques cyber, il est préférable de renforcer la sécurité plutôt que de la masquer.

FAQ