Jump to content

Comment protéger son serveur Linux des attaques avec CrowdSec ? | Linux | IT-Connect


Ldfa
 Share

Recommended Posts

I. 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).

schema-crowdsec.jpg

schema-crowdsec.jpg

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

debian-apt-get-install-crowdsec.png

debian-apt-get-install-crowdsec.png

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 :

crowdsec-detection-des-services-800x27.p

crowdsec-detection-des-services-800x27.p

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).

crowdsec-cscli-decisions-list-all-800x26

crowdsec-cscli-decisions-list-all-800x26

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-scan-crowdsec.png

nikto-scan-crowdsec.png

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.

crowdsec-cscli-decisions-list-detection-

crowdsec-cscli-decisions-list-detection-

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é.

crowdsec-cscli-alerts-list-800x386.png

crowdsec-cscli-alerts-list-800x386.png

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.

crowdsec-telecharger-bouncer-nginx.png

crowdsec-telecharger-bouncer-nginx.png

À 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 !

crowdsec-cscli-bouncers-list.png

crowdsec-cscli-bouncers-list.png

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 !

nikto-vs-crowdsec-nginx-800x367.jpg

nikto-vs-crowdsec-nginx-800x367.jpg

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 !

crowdsec-cscli-decisions-list-detection-

crowdsec-cscli-decisions-list-detection-

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 :

crowdsec-metabase-dashboard-creation.png

crowdsec-metabase-dashboard-creation.png

À partir de l'hôte local ou d'un hôte distant, on peut accéder à l'interface de Metabase et s'authentifier.

connexion-dashboard-metabase-crowdsec.jp

connexion-dashboard-metabase-crowdsec.jp

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é ! 😉

crowdsec-dashboard-metabase-01-800x388.p

crowdsec-dashboard-metabase-01-800x388.p

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.

crowdsec-dashboard-metabase-02-800x347.p

crowdsec-dashboard-metabase-02-800x347.p

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

mise-a-jour-composants-crowdsec.jpg

mise-a-jour-composants-crowdsec.jpg

Quelques liens :

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.

Afficher l’article complet

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.