Comment mettre en place une installation multiserveur de CrowdSec ?

I. Présentation

Dans ce tutoriel, nous allons voir comment effectuer une installation de CrowdSec sur plusieurs machines afin de répliquer les alertes et les décisions entre les différentes instances. Ainsi, lorsqu'un serveur banni une adresse IP, elle est également bannie sur les autres instances CrowdSec synchronisées.

Pour effectuer une installation multiserveur de CrowdSec, toutes les machines doivent avoir une instance CrowdSec installée en local. Ensuite, nous viendrons ajuster la configuration de chaque instance, notamment au niveau de LAPI. Si vous avez plusieurs serveurs exposés sur Internet (un cluster de serveurs Web, par exemple), vous pouvez déployer cette configuration pour que les adresses IP malveillantes soient bannies sur tous les nœuds.

Pour les échanges d'informations, CrowdSec s'appuie sur deux API :

• Local API ou LAPI : ceci correspond à l'hôte local lorsque l'instance CrowdSec fonctionne de façon autonome
• Central API ou CAPI : ceci correspond aux instances CrowdSec dans le Cloud, notamment sollicitées pour récupérer les listes d'adresses IP malveillantes communautaires et pour transmettre les signaux à la console CrowdSec.

Ce contenu est disponible au format vidéo :

• Voir la vidéo sur YouTube

II. Architecture avec un pare-feu PfSense et des serveurs virtuels

Pour le déploiement, plusieurs scénarios sont envisageables. Vous pouvez utiliser une machine CrowdSec destinée à centraliser toutes les décisions et toutes les alertes, et sur laquelle les autres machines viendront se synchroniser. Il est d'ailleurs possible de s'appuyer sur une base de données, pour des questions de performance.

Aujourd'hui, nous allons déployer un scénario basé sur deux machines :

• Un pare-feu PfSense, où CrowdSec sera installé et cet hôte sera utilisé pour héberger le rôle de "Local API" pour les trois machines
• Un serveur Windows Server, où CrowdSec sera installé avec le bouncer windows-firewall

Ici, il n'y a qu'un seul serveur exposé sur Internet, représenté par un serveur Web sous Windows Server, mais il pourrait tout à fait en avoir d'autres (y compris sous Linux). Je vais vous préciser les étapes à effectuer sur les noeuds que l'on pourrait appeler les "clients LAPI".

Remarque : dans la vidéo, le scénario est basé sur trois machines, avec un second serveur en DMZ, sous Linux, lui aussi serveur Web et exposé sur Internet également. Référez-vous à la vidéo si nécessaire, selon vos besoins.

III. Point de départ

Ce tutoriel n'abordera pas l'installation de CrowdSec sur les différents hôtes, ni même l'installation des systèmes d'exploitation. Pour cela, référez-vous aux articles suivants :

• Installer CrowdSec sur Windows Server
• Installer CrowdSec sur PfSense
• Créer un lab virtuel avec VirtualBox et PfSense
• Créer un lab virtuel avec VMware Workstation et PfSense

Quand votre environnement est prêt, vous pouvez passer à la phase de configuration.

IV. Configurer le serveur LAPI central pour CrowdSec

Sur le pare-feu PfSense, nous devons configurer CrowdSec pour qu'il soit en écoute sur une adresse IP du pare-feu, afin de ne pas être accessible uniquement en local. Sans cela, les autres hôtes ne pourront pas venir s'inscrire sur ce serveur LAPI car par défaut l'hôte LAPI est configuré sur l'adresse IP de boucle locale : 127.0.0.1.

Connectez-vous à l'interface d'administration de PfSense, cliquez sur "Services" puis "CrowdSec". Ici, descendez jusqu'à trouver l'option "LAPI host" et remplacez "127.0.0.1" par le nom d'hôte (DNS) de votre pare-feu PfSense, ou l'adresse IP de l'une de ses interfaces. Dans cet exemple, je précise "192.168.200.1" car il s'agit de l'adresse IP de l'interface "DMZ" de mon pare-feu et le serveur Web se situe dans cette zone réseau.

Quand c'est fait, sauvegardez la configuration avec le bouton prévu à cet effet.

Il est à noter que cette modification, bien qu'elle soit effectuée via l'interface web de PfSense, pourrait être effectuée en ligne de commande en modifiant le fichier suivant :

/usr/local/etc/crowdsec/config.yaml

D'ailleurs, ce que nous venons d'effectuer en mode web a permis de modifier le fichier de configuration.

Passez à l'étape suivante.

V. Inscrire et autoriser les hôtes sur le serveur LAPI

Le serveur Web sous Windows Server va devoir s'inscrire sur le serveur LAPI CrowdSec, c'est-à-dire notre pare-feu PfSense. Ensuite, nous devrons approuver la demande d'inscription. Cette étape est à effectuer sur chaque serveur qui doit utiliser le serveur LAPI central.

A. Désactiver l'interface LAPI de CrowdSec

À partir du serveur Windows Server, où CrowdSec est installé, vous devez commencer par modifier le fichier de configuration "config.yaml" situé à cet emplacement :

C:\ProgramData\CrowdSec\config\config.yaml

Dans ce fichier, vous devez ajouter la ligne "enable: false" sous "server:", et commenter la ligne "listen_uri" afin de désactiver la LAPI de CrowdSec. En effet, ce n'est plus utile sur ce serveur puisque nous allons solliciter la LAPI de l'instance CrowdSec installée sur le pare-feu PfSense.

Attention à la syntaxe, notamment aux espaces, car YAML est très pointilleux là-dessus.

Une fois que c'est fait, sauvegardez le fichier.

• CrowdSec - Documentation - Fichier de configuration

B. Inscrire les hôtes CrowdSec sur le serveur LAPI

Toujours sur ce même serveur, ouvrez une console PowerShell ou une Invite de commande afin d'inscrire l'hôte sur le serveur LAPI. Exécutez la commande suivante, en adaptant l'adresse IP (et éventuellement le port, si vous l'avez modifié).

cscli lapi register -u  http://192.168.200.1:8080

Si l'on ne précise pas de nom, comme c'est le cas avec la commande ci-dessus, un ID aléatoire sera généré. Si vous souhaitez préciser un nom, afin que ce soit plus parlant, utilisez la commande de cette façon :

cscli lapi register -u  http://192.168.200.1:8080 --machine <nom de la machine>

Vous devez obtenir un résultat semblable à celui-ci :

Pour prendre en compte l'ensemble des modifications que nous venons d'effectuer, redémarrez le service CrowdSec :

Restart-Service crowdsec

Passez à la suite.

C. Approuver les hôtes CrowdSec

Basculez sur le serveur LAPI, c'est-à-dire sur le pare-feu, afin d'approuver la machine que l'on vient d'inscrire. Connectez-vous à la console, via SSH, par exemple.

Exécutez la commande suivante pour lister les machines :

cscli machines list

Ceci va permettre d'obtenir une liste avec deux machines :

• La machine locale, ici "pfsense"
• La machine distante que l'on vient d'inscrire, identifier par le nom "3f8ba55c46b54537aadaac7c5b7717a44wNuYECMrmksQ9Mm" (car je n'ai pas précisé de nom ; j'ignorais l'option permettant de nommer la machine à ce moment-là)

Désormais, il faut valider / approuver cette nouvelle machine en attente. Pour cela, exécutez la commande suivante :

cscli machines validate <nom de la machine>
cscli machines validate 3f8ba55c46b54537aadaac7c5b7717a44wNuYECMrmksQ9Mm

En principe, vous devriez obtenir un message de confirmation, comme celui-ci :

Passez à la suite.

VI. Déclarer les nouveaux bouncers

A. Ajouter un bouncer et obtenir une clé d'API

Toujours sur le serveur LAPI, à savoir PfSense, nous allons devoir déclarer la machine distante comme étant un bouncer. Ceci signifie qu'elle aura la permission de venir déclarer de nouvelles alertes et décisions pour bloquer des adresses IP malveillantes.

La commande suivante permet de déclarer un bouncer nommé "SRV-WS2022". Vous pouvez reprendre le nom d'hôte de votre machine.

cscli bouncers add <nom de la machine>
cscli bouncers add SRV-WS2022

Comme le montre l'image ci-dessous, nous obtenons une clé d'API pour cet hôte :

Cette clé d'API va lui permettre de s'authentifier sur le serveur LAPI en tant que bouncer.

B. Configurer le bouncer sur l'hôte

Retournez sur le serveur distant. Pour ma part, c'est le serveur Web sous Windows Server. L'objectif va être de configurer le bouncer Windows Firewall installé sur cette machine pour qu'il déclare les décisions sur le serveur LAPI central, plutôt qu'en local. Ceci implique d'installer le bouncer sur le serveur, au préalable.

Éditez le fichier suivant :

C:\ProgramData\CrowdSec\config\bouncers\cs-windows-firewall-bouncer.yaml

Dans ce fichier, vous devez modifier deux options :

• api_endpoint
• api_key

Elles sont mises en évidence sur l'image ci-dessous.

Pour l'option "api_endpoint", vous devez indiquer l'adresse IP (ou le nom d'hôte) ainsi que le port de votre serveur LAPI central (soit le PfSense).

Pour l'option "api_key", vous devez indiquer la clé d'API obtenue précédemment via la commande "cscli bouncers add".

Ce qui donne :

Quand c'est fait, redémarrez le service Windows correspondant au bouncer Firewall :

Restart-Service cs-windows-firewall-bouncer

Du côté de PfSense, si nous regardons l'onglet "Bouncers" présent sur la page de statut de CrowdSec, nous pouvons voir deux bouncers valides ! Il y a le bouncer présent en local sur PfSense et notre hôte distant sous Windows Server.

La configuration est prête, vous allez pouvoir la tester...

VII. Tester la configuration

Pour tester cette configuration, nous allons devoir simuler un comportement malveillant. Dans le cas présent, mon serveur Web Windows Server est accessible grâce à une règle de NAT (car le reverse proxy n'est pas configuré sur le pare-feu) créée sur le pare-feu PfSense.

À l'aide d'une machine distante, je vais accéder à ce site Web qui est celui par défaut de IIS. Il s'agit d'un Lab et l'interface WAN de mon PfSense a l'adresse IP "192.168.1.60", donc j'effectue un scan Web sur cette adresse IP à l'aide de l'outil Nikto.

Ci-dessous, l'action est effectuée à partir d'une machine Kali Linux. Ce scan effectué par Nikto est bruyant et devrait alerter rapidement CrowdSec.

En effet, nous pouvons constater qu'il y a bien eu une décision prise par CrowdSec : bloquer l'adresse IP correspondante à mon hôte Kali Linux. Le résultat ci-dessous est issu de la machine Windows Server.

Nous pouvons voir qu'il y a eu plusieurs alertes générées :

Mais, comment savoir si c'est le pare-feu ou le serveur web qui a pris la décision de bloquer cette adresse IP ?

Pour cela, nous pouvons regarder les détails de l'alerte. Par exemple, l'alerte avec l'ID numéro 4 correspondant à du "http-xss-probbing". Pour cela, nous devons exécuter la commande suivante :

cscli alerts inspect 4

Dans les détails, nous pouvons voir la ligne "Machine :" accompagnée par un nom d'hôte. Ici, j'obtiens un ID de machine (souvenez-vous, la machine n'a pas été nommée lors de son inscription initiale). Cet identifiant correspond bien à mon serveur Web, donc c'est ce serveur qui a bloqué l'adresse IP.

Nous pouvons le vérifier en faisant la correspondance entre cet ID et celui visible dans la liste des machines :

cscli machines list

Voici le résultat en image :

Remarque : nous pouvons également ajouter l'option "-m" aux commandes "cscli alerts list" et "cscli decisions list" pour ajouter une nouvelle colonne avec l'ID de la machine.

Du côté de l'interface Web de PfSense, cette adresse IP est également bannie ! La décision est bien synchronisée entre tous les hôtes. Ainsi, les deux machines vont bloquer tous les flux en provenance de cette adresse IP malveillante.

VIII. Conclusion

Grâce à ce tutoriel basé sur uniquement deux hôtes, nous voyons bien le potentiel et l'intérêt de CrowdSec dans une architecture multiserveur, notamment lorsqu'il y a plusieurs serveurs exposés sur Internet. Le fait de coupler les serveurs avec le pare-feu permet de bannir les adresses IP malveillantes directement en entrée du réseau, ce qui est intéressant pour protéger notre infrastructure.

Sachez que malgré la présence d'une authentification, tous les flux échangés entre les hôtes sont effectués en clair puisque le protocole HTTP est utilisé. Il s'agit de flux interne, entre le serveur en DMZ et le pare-feu, donc c'est acceptable. Toutefois, si vous envisagez d'utiliser un serveur LAPI externe ou qui implique que des flux vont transiter sur Internet, vous devez faire évoluer la configuration pour basculer les connexions en HTTPS.