Comment protéger son serveur Linux des attaques avec CrowdSec ?
mercredi 7 juillet 2021 à 11:30I. Présentation
Vous connaissez surement Fail2Ban, un outil qui permet d'analyser les journaux de votre machine Linux dans le but de bannir les adresses IP correspondantes à des hôtes qui ont des comportements malveillants ou suspects. Dans ce tutoriel, nous allons voir comment mettre en place CrowdSec pour protéger son serveur Linux des attaques.
Qu'est-ce que l'outil CrowdSec ?
CrowdSec est un outil open source, gratuit, français, qui s'inspire de Fail2ban et qui a pour objectif de protéger votre serveur, en détectant puis en bloquant les attaques.
Lorsque des adresses IP sont bloquées par une instance de CrowdSec, l'information est remontée dans une base centralisée au travers d'une API : ce qui permet d'avoir une liste d'adresses IP malveillantes communautaire et gérée par CrowdSec. Bien sûr, il y a un mécanisme de réputation qui entre en jeu : une adresse IP n'est pas bannie chez tout le monde dès le premier signalement, c'est un peu plus complexe que cela vous vous en doutez bien.
Actuellement, CrowdSec est disponible en version 1.0. Suite à la sortie de cette version, CrowdSec a fait évoluer l'architecture interne de sa solution puisque les composants (client, bouncers, processus) communiquent entre eux via une API REST locale. L'utilisation d'une API est particulièrement intéressante pour rendre indépendants les composants les uns des autres et éviter d'attaquer directement la base de données (c'est réservé au service de l'API REST locale).
Pour ce premier article au sujet de CrowdSec et en guise d'introduction, je vous propose de prendre un serveur Web Nginx comme cible et d'apprendre à le protéger avec CrowdSec.
Voici les prérequis pour suivre ce tutoriel :
- Une machine Debian avec un serveur Web Nginx opérationnel et accessible depuis l'extérieur (pour l'attaque distante)
- Une machine avec l'outil Nikto installé (cela peut-être via WSL) pour réaliser l'attaque
II. Installation de CrowdSec sur Debian 10
Pour l'installation, il y a plusieurs façons de faire : simplement aller piocher dans les dépôts de Debian (sur Debian Bullseye pour le moment), utiliser le dépôt CrowdSec, installer soi-même le package .deb, l'installer en mode interactif à partir d'une archive et d'un script d'installation, ou alors à partir d'une image Docker.
Nous allons utiliser le dépôt CrowdSec. Il suffit de l'ajouter à notre machine et de mettre à jour la liste des paquets :
wget -qO - https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/crowdsec.asc |sudo apt-key add - && echo "deb https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/$(lsb_release -cs) $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/crowdsec.list > /dev/null sudo apt-get update
sudo apt-get update
Ensuite, on lance l'installation de crowdsec :
sudo apt-get install crowdsec
Lors de l'installation, Crowdsec va analyser votre machine à la recherche de services qu'il prend en charge. Dans cet exemple, il détecte bien le système Linux, mais également les fichiers journaux de Nginx : access.log et error.log.
Ce qui donne :
Grâce à cette analyse de notre machine locale, Crowdsec va installer les collections correspondantes aux services détectés et qui vont lui permettre de détecter les attaques.
Pour lister les collections CrowdSec, utilisez la commande suivante du CLI CrowdSec (cscli) :
cscli collections list
À la fin de l'installation, on redémarre Crowdsec :
sudo systemctl reload crowdsec
Passons à l'utilisation de Crowdsec en prenant une simulation d'attaque comme exemple.
III. Scan du serveur Nginx : comment Crowdsec va-t-il réagir ?
A. Première analyse de notre serveur Web avec Nikto
Nikto est un outil open source qui permet de scanner les serveurs Web. Il permet de rechercher des vulnérabilités, des fichiers dangereux, etc... À l'aide de cet outil, on va déclencher un scanner sur notre serveur Web Nginx pour voir comment réagit Crowdsec. Il s'agit simplement d'un scanne, et non d'une attaque.
Avant toute chose, manipulons quelques instants la ligne de commande CrowdSec : cscli. Pour lister les décisions actives, c'est-à-dire les adresses IP que CrowdSec a décidé de bloquer, il faut exécuter la commande suivante :
cscli decisions list
On peut voir que la liste est vide : No active decisions. Essayez maintenant avec un paramètre supplémentaire :
cscli decisions list --all
Là, nous avons d'autres adresses IP : il s'agit des adresses IP obtenues à partir de la liste centralisée et partagée par CrowdSec directement (construire à partir des instances CrowdSec et des remontées associées).
Passons à l'utilisation de Nikto.
Depuis une machine distante, située sur un autre réseau, je vais déclencher un scan à destination de mon site it-connect.tech. Pour cette attaque, je vais utiliser l'outil mentionné précédemment : Nikto. Voici la commande à utiliser pour déclencher l'analyse :
nikto -h it-connect.tech
Nikto va requêter le site it-connect.tech à la recherche de vulnérabilités et de défaut de configuration. Sur le serveur Web, relancez la commande précédente : il se passe des choses.
cscli decisions list
Mon adresse IP fait l'objet d'une surveillance et Crowdsec a envie de la bannir pour une durée de 4 heures ! On peut voir qu'il y a deux événements associés à cette adresse IP.
Je dis bien "qu'il a envie" de la bannir, car il ne l'a pas fait, en tout cas, pour le moment ! 
- Disons que pour le moment, CrowdSec a identifié l'adresse IP malveillante.
Pour en savoir un peu plus, listons les alertes :
cscli alerts list
Le champ "VALUE" nous donne l'adresse IP source : il s'agit de l'adresse IP publique de la machine qui exécute le scanner via Nikto. On peut voir qu'il y a de nombreuses alertes générées par CrowdSec suite au scan que j'ai déclenché.
B. L'intervention du Bouncer Nginx
Pour que CrowdSec puisse bloquer une adresse IP, autrement dit qu'il puisse mettre en pratique la décision, il s'appuie sur des Bouncers. Ces bouncers vont permettre de contrer les menaces grâce à différentes actions (bloquer, présentation d'un Captcha, etc.).
Un bouncer s'apparente à un module qui va appliquer la décision. Par exemple, si l'on installe le Bouncer Nginx (ce que nous allons faire juste après), CrowdSec va bloquer mon adresse IP directement dans Nginx (et pas sur le firewall de ma machine Linux, vraiment dans Nginx) pour appliquer l'action "bannir".
Voici un lien vers la liste des bouncers disponibles : CrowdSec - Bouncers
Note : il existe de nombreux bouncers et d'autres sont en cours de développement. Par exemple, il y a un bouncer CloudFlare, un bouncer WordPress, mais pas encore de bouncer Apache.
Pour protéger notre serveur Nginx, on va installer le Bouncer Nginx. Il faut que l'on télécharge le paquet pour l'installer manuellement. Par la suite, il sera possible d'installer encore plus simplement les Bouncers.
À partir de la ligne de commande, on télécharger le fichier "cs-nginx-bouncer.tgz" :
wget https://github.com/crowdsecurity/cs-nginx-bouncer/releases/download/v0.0.4/cs-nginx-bouncer.tgz
Ensuite, on décompresse l'archive obtenue :
tar -xzvf cs-nginx-bouncer.tgz
On se positionne dans le dossier "cs-nginx-bouncer-v0.0.4" :
cd cs-nginx-bouncer-v0.0.4/
On lance l'installation :
sudo ./install.sh
D'ailleurs, le script d'installation va en profiter pour installer quelques dépendances, si elles sont manquantes bien sûr. Voici la liste des dépendances installées sur ma machine par ce Bouncer : lua, lua-sec, libnginx-mod-http-lua, lua-logging. Pour information, LUA est un système qui permet de développer et d'intégrer des modules au sein de Nginx.
Pour vérifier que notre bouncer est opérationnel, on va lister les bouncers :
sudo cscli bouncers list
Il est bien là et il est valide : parfait !
Avant d'aller plus loin, on va redémarrer Nginx :
sudo systemctl restart nginx
C. Deuxième analyse avec Nikto : CrowdSec va-t-il me bannir ?
Désormais, CrowdSec dispose d'un bouncer capable de nous bannir si l'on effectue des actions suspectes. On va vérifier s'il fonctionne correctement.
Sur la machine Kali Linux, on va tenter de se connecter à notre site Web. On va effectuer une requête avec l'outil CURL :
curl -I it-connect.tech
On voit bien que le code retourné par la page est "HTTP/1.1 200 OK" : cela signifie que l'on a pu accéder à la page du site et qu'il n'y a pas eu d'erreur.
Maintenant, je relance mon scanne Nikto :
nikto -h it-connect.tech
Dans la foulée, je relance ma commande CURL : oups, j'ai un code différent cette fois-ci ! J'obtiens le code "HTTP/1.1 403 Forbidden", ce qui correspond à un accès refusé. Il y a de fortes chances pour que je sois bloqué par CrowdSec !
Nous allons le vérifier facilement avec la commande suivante (que l'on a vue précédemment) :
cscli decisions list
Sans réelle surprise, mon adresse IP apparaît bien et je suis bannie pour une durée de 4 heures !
Puisqu'il s'agit d'un faux positif étant donné que je m'attaque moi-même, cela me donne l'occasion de vous montrer comment débannir manuellement une adresse IP (il faut remplacer X.X.X.X par l'adresse IP publique) :
cscli decisions delete --ip X.X.X.X
De la même façon, on peut aussi bannir manuellement une adresse IP :
cscli decisions add --ip X.X.X.X
Dans ce cas, la raison du bannissement sera "Manual ban from <login API>". Par défaut, une adresse IP est bannie pendant 4 heures, mais on peut être un peu plus méchant et partir sur 24 heures directement :
cscli decisions add --ip X.X.X.X --duration 24h
IV. Le tableau de bord CrowdSec via Metabase
CrowdSec propose un container Docker basé sur Metabase pour bénéficier d'un tableau de bord très sympathique qui va permettre d'analyser les attaques subies par sa machine. Au préalable, il faut penser à installer Docker (apt-get install docker.io -y) sur la machine. Ensuite, on peut créer le container de cette façon :
sudo cscli dashboard setup --listen 0.0.0.0
À la fin de la création, le nom d'utilisateur et le mot de passe s'affichent dans la console :
À partir de l'hôte local ou d'un hôte distant, on peut accéder à l'interface de Metabase et s'authentifier.
Une fois connecté, on obtient des statistiques précises et des graphiques : nombre de décisions actives, nombre d'alertes, répartition des attaques par adresses IP, etc... Je me suis amusé à attaquer ma propre machine, mais visiblement je ne suis pas le seul a avoir essayé !
Un peu plus bas dans la page, nous avons d'autres graphes. Cette interface est très pratique pour effectuer des analyses pendant ou après une attaque.
Note : la commande cscli metrics permet d'obtenir des informations sur les métriques à partir de la ligne de commande, mais bon, une fois que l'on a gouté à l'interface Metabase c'est difficile de s'en passer.
Il faut savoir que CrowdSec est capable d'intégrer à ce tableau de bord d'anciens logs générés par vos applications avant même que l'outil soit déployé sur votre serveur.
Lorsque vous avez terminé d'utiliser le dashboard, vous pouvez l'arrêter temporairement grâce à cette commande :
sudo cscli dashboard stop
Pour le relancer, il suffira d'exécuter :
sudo cscli dashboard start
V. Conclusion
Ce premier tutoriel au sujet de CrowdSec touche à sa fin : je dis bien "ce premier article", car je pense qu'il y en aura d'autres sur le sujet ! Nous avons vu le bouncer pour Nginx, mais il existe un bouncer nommé "cs-firewall-bouncer" et qui va permettre à CrowdSec d'interagir avec le firewall, notamment iptables et nftables.
Grâce à CrowdSec, nous avons pu mettre en place un outil efficace pour protéger notre serveur Web en détectant et bloquant les attaques.
Pour finir, voici la commande qui va vous permettre de voir s'il y a des mises à jour disponibles pour les différents bouncers, collections, etc... De votre installation :
sudo cscli hub update
Ensuite, pour déclencher la mise à jour :
sudo cscli hub upgrade
Voilà, c'est tout pour cette fois !
Que pensez-vous de CrowdSec ? Pensez-vous le tester pour protéger un ou plusieurs de vos serveurs ?
Merci à Thibault Koechlin d'avoir pris le temps de me présenter CrowdSec.
The post Comment protéger son serveur Linux des attaques avec CrowdSec ? first appeared on IT-Connect.
