FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Comment protéger son site WordPress avec CrowdSec ?

20 décembre 2021 à 11:30

I. Présentation

Dans ce tutoriel, nous allons voir comment protéger un site WordPress avec l'outil CrowdSec afin de bannir les adresses IP malveillantes.

Grâce à CrowdSec, on va pouvoir protéger notre site WordPress contre toutes les attaques courantes, notamment les scans avec des outils de sécurité, mais aussi les attaques par brute force sur le formulaire de connexion de WordPress.

Afin de pousser un peu plus loin la configuration de l'extension CrowdSec, je vais utiliser un site WordPress derrière un reverse proxy HAProxy. Si vous n'utilisez pas de reverse proxy et que votre site Web est publié directement sur Internet (ou via un NAT), vous pouvez aussi utiliser l'extension CrowdSec (et ce sera encore plus rapide).

Le site WordPress "it-connect.tech" sera mon cobaye pour cette démonstration. Je vais manipuler le serveur Web où est déployé le site WordPress afin de mettre en place CrowdSec et le "PC de l'attaquant" présent sur le schéma ci-dessous.

Je ne vais pas détailler l'installation de mon serveur Web (LAMP - Linux Apache MariaDB PHP) ni l'installation de WordPress dans ce tutoriel. Si besoin, je vous oriente vers ces deux tutoriels existants :

II. Installation de CrowdSec sur le serveur

Sur mon serveur web sous Debian 11, je vais installer CrowdSec directement à partir des dépôts officiels.

sudo apt-get update
sudo apt-get install -y crowdsec

Le cas échéant, si le paquet n'est pas disponible (sur une version Linux plus ancienne, par exemple), vous devez utiliser cette méthode pour réaliser l'installation :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash 
sudo apt install crowdsec

Lors de l'installation, CrowdSec va analyser votre machine afin de détecter les services présents et de télécharger les collections associées. Ces composants vont permettre à CrowdSec de détecter les attaques (sans les bloquer).

On peut lister les collections avec la commande suivante :

sudo cscli collections list

On peut voir que la collection "WordPress" est automatiquement installée : CrowdSec a détecté la présence du CMS. En complément, on retrouve d'autres collections, dont "base-http-scenarios", ce qui va nous permettre d'être protégé contre les attaques Web courantes, y compris sur notre site WordPress.

Suite à l'installation, il est préférable d'effectuer une mise à jour des collections pour être certain de bénéficier des dernières versions et de tous les scénarios de détection. Voici les deux commandes à saisir :

sudo cscli hub update
sudo cscli hub upgrade

III. Mise en place du Bouncer CrowdSec dans WordPress

A. Installation et configuration de l'extension CrowdSec

À partir de l'interface d'administration de WordPress, cliquez sur le lien "Ajouter" du menu "Extensions".

Grâce à la zone de recherche, vous pouvez trouver facilement l'extension "CrowdSec". Ensuite, il suffit de cliquer sur le bouton "Installer maintenant".

Dans la foulée de l'installation, cliquez sur le bouton "Activer" pour activer l'extension. Cela n'aura pas d'impact sur votre site, car il faut lier le Bouncer CrowdSec à notre instance locale CrowdSec pour que cela fonctionne.

À ce sujet, accédez à la console de votre serveur Web et saisissez la commande ci-dessous pour générer une clé d'API pour notre Bouncer. Il faudra copier cette valeur.

sudo cscli bouncers add wordpress-bouncer

Ensuite, retournez sur WordPress et cliquez à gauche sur "CrowdSec" dans le menu afin d'accéder à la configuration de l'extension. Il va falloir renseigner plusieurs options :

  • LAPI URL : indiquez "http://localhost:8080", car CrowdSec est installé sur le même serveur que WordPress.
  • Bouncer API Key : collez la clé d'API générée précédemment
  • Bouncing level : en mode "Normal bouncing", CrowdSec va bannir ou présenter le Captcha aux clients malveillants selon la configuration, tandis qu'en mode "Flex bouncing", le blocage sera toujours effectué via un Captcha. Enfin, le mode "Bouncing disabled" permet à CrowdSec d'être transparent donc il ne bloquera plus personne, y compris les pirates. Prenons le mode "Normal bouncing" pour le moment.
  • Public website only : désactivez cette option afin de protéger la partie publique du site, mais aussi l'espace d'administration (wp-admin). Si cette option est active, CrowdSec protège seulement la partie publique du site (front office).

Validez en cliquant sur le bouton "Enregistrer les modifications".

À partir de la ligne de commande de votre serveur, exécutez la commande suivante pour lister les bouncers actifs :

cscli bouncers list

On constate que le bouncer WordPress est bien présent et valide ! Bonne nouvelle !

B. Un reverse proxy ? Configurez le module remoteip

Pour fonctionner, le bouncer WordPress va s'appuyer sur les journaux du serveur Web notamment pour identifier le client source par son adresse IP.

Dans le cas où vous utilisez un reverse proxy ou un CDN comme CloudFlare, c'est l'adresse IP du proxy qui est visible dans les journaux puisque c'est lui qui communique en direct avec le serveur Web. Cela ne joue pas en notre faveur, mais heureusement on peut ajuster la configuration d'Apache pour récupérer l'adresse IP d'origine du client.

Note : en amont, il faut configurer le reverse proxy pour qu'il ajoute le champ "X-Forwarded-For" à l'en-tête des requêtes HTTP afin de transmettre l'adresse IP du client au serveur Web.

Pour configurer Apache, il faut activer le module "remoteip" (normalement installé par défaut) :

a2enmod remoteip

Ensuite, il faut modifier le fichier de configuration d'Apache :

nano /etc/apache2/apache2.conf

Il faut modifier le format des logs et plus particulièrement la ligne qui termine par "combined". Il faut remplacer "%h" par "%a" pour spécifier dans les logs l'adresse IP du client d'origine plutôt que l'adresse IP de l'hôte qui contact le serveur Web directement.

Ce qui donne :

Enfin, on va ajouter à Apache que le champ "X-Forwarded-For" contiendra l'adresse IP du client d'origine au sein de l'en-tête HTTP. Pour cela, on utilise l'option RemoteIPHeader du module remoteip. Ajoutez la ligne suivante au fichier apache2.conf :

RemoteIPHeader X-Forwarded-For

Il ne reste plus qu'à sauvegarder le fichier et redémarrer Apache :

systemctl restart apache2

Nous verrons dans la suite de ce tutoriel l'impact de cette modification sur les logs d'Apache. La configuration de CrowdSec étant prête, nous allons pouvoir attaquer notre site WordPress.

IV. Tester le bon fonctionnement

Pour simuler une attaque contre un site Web, en l'occurrence ici un site WordPress, il y a plusieurs façons de faire. On peut utiliser Nikto, Wapiti, WPScan ou tout simplement Curl avec un user-agent suspect.

C'est d'ailleurs Curl que je vais utiliser, car ce que j'aime bien quand il s'agit de faire une démo, c'est que l'on voit en direct le code de retour HTTP : 200 quand la page se charge correctement, et il passe à 403 ou 401 une fois que CrowdSec est intervenu (le code dépend de la décision : bannir ou captcha).

On va contacter notre site en utilisant le user-agent OpenVAS (un outil de sécurité), ce qui ne devrait pas plaire à CrowdSec, car il est dans la liste des "bad user agent". Ce qui donne la commande :

curl -I https://it-connect.tech -H "User-Agent: OpenVAS"

Sur la copie d'écran ci-dessous, on peut voir qu'au début le serveur Web me répond bien, avec un code HTTP 200 donc j'accède au site. Ensuite, j'obtiens une réponse "403 Forbidden", ce qui correspond à un accès refusé. On va aller voir avec un navigateur ce qu'il se passe...

À partir du navigateur, si je tente d'accéder à l'espace d'administration de mon site WordPress ou au site en lui-même, j'obtiens un message qui m'indique je suis actuellement banni par le système ! Nous verrons dans la suite de ce tutoriel comment personnaliser cette page.

À partir de la ligne de commande, on peut lister les décisions actives dans CrowdSec et on peut voir la présence de notre adresse IP publique. L'action "BAN" montre bien que l'adresse IP est bannie pour une raison claire "http-bad-user-agent", ce qui montre clairement que CrowdSec n'a pas aimé que je me présente avec le user-agent OpenVAS.

sudo cscli decisions list

Si l'on regarde les journaux d'Apache, on peut voir la ligne avec le code HTTP 403, et cette même ligne commence bien par l'adresse IP publique utilisée par le PC de l'attaquant. Toutes les autres lignes visibles sur l'image ci-dessous correspondent aux différents "check alive" effectué par le reverse proxy pour vérifier si le serveur Web est opérationnel (d'où l'adresse IP du reverse proxy qui apparaît toutes les secondes).

J'ai l'avantage d'être à la fois l'attaquant et l'admin du site WordPress alors je vais débloquer mon adresse IP (via un autre accès sur le serveur) :

sudo cscli decisions delete --ip X.X.X.X

On va tester d'une seconde façon l'efficacité de CrowdSec : en s'attaquant au formulaire de connexion de WordPress, accessible via la page wp-login.php.

Brute force WordPress : comment va réagir CrowdSec ?
Brute force WordPress : comment va réagir CrowdSec ?

Si on liste les décisions actives, comme nous avons fait précédemment, on peut voir que cette fois-ci la raison du blocage est différente : http-fb-wordpress_bf. CrowdSec a bien détecté que j'étais en train d'effectuer un brute force sur la page de connexion !

Notre site WordPress est protégé par CrowdSec, mais pour finir je vous propose de voir quelques options supplémentaires du Bouncer WordPress.

V. Optimiser la configuration du Bouncer WordPress

A. Les options avancées du Bouncer WordPress

Dans l'interface d'administration de WordPress, à gauche sous le menu CrowdSec cliquez sur "Advanced".

Cette partie permet d'accéder à quelques options supplémentaires, dont l'option "Trust these CDN IPs (or Load Balancer, HTTP Proxy)". Cette option va permettre de préciser les adresses IP correspondantes au CDN que vous utilisez, par exemple CloudFlare, ou alors l'adresse IP de votre reverse proxy, comme dans mon cas. C'est pour cette raison que je spécifie l'adresse IP "192.168.100.1".

Ensuite, vous pouvez activer l'option "Hide CrowdSec mentions", cela va permettre d'éviter d'afficher sur la page de blocage que c'est CrowdSec qui sécurise le site. Même si CrowdSec c'est génial, ce n'est pas la peine d'afficher le nom de l'outil publiquement. 😉

Vous pouvez sauvegarder les changements.

Au sein de la section de configuration globale de CrowdSec, nous avons choisi le mode "Normal bouncing" pour bannir les adresses IP lorsque c'est utile. Si vous choisissez le mode "Flex bouncing", un captcha sera présenté. À titre d'information, voici ce que ça donne côté utilisateur via le navigateur :

B. Personnaliser la page de blocage CrowdSec

La page de blocage qui s'affiche lorsque l'on est banni ou la page du captcha sont toutes les deux en anglais. Sachez qu'il est possible de les configurer totalement via l'extension CrowdSec de WordPress. Cette fois-ci, sous le menu "CrowdSec", choisissez "Theme customization".

Vous allez pouvoir modifier le texte des deux pages, mais aussi jouer sur les couleurs, ainsi que sur le style CSS de la page ! De cette façon, la page de blocage présentée par CrowdSec pourra respecter la charte graphique de votre site.

Voici un exemple :

Ce qui donne en production :

C. Brute force WordPress : modifier le seuil de blocage

En listant les scénarios via la ligne de commande (cscli scenarios list), on peut voir que le fichier de configuration du scénario "http-bf-wordpress_bf" est situé à cet emplacement :

/etc/crowdsec/scenarios/http-bf-wordpress_bf.yaml

Pour ajuster le comportement de ce scénario, notamment le seuil de blocage, il faut modifier ce fichier. On obtient le contenu suivant :

Il y a deux paramètres ajustables :

  • capacity: 5
  • leakspeed: "10s"

Il faut interpréter cette configuration par défaut de cette façon : nous avons un sceau (bucket) d'une capacité de 5 unités au maximum (capacity: 5) et une unité de ce sceau est retirée toutes les 10 secondes (leakspeed: "10s"). À chaque fois que j’effectue une tentative en erreur sur la page de login, une unité est ajoutée dans le sceau et à la 6ème unité, le sceau déborde donc je dois être banni (ou avoir un captcha). Vous pouvez ajuster ces deux valeurs en fonction de vos besoins.

Note : à cause de la mise en cache des informations via PHP, il peut y avoir une certaine latence entre le moment où l'action se produit et le moment où la décision est appliquée.

Avec toutes ces informations, vous êtes désormais en mesure de déployer CrowdSec sur votre serveur Web afin de protéger votre site WordPress des attaques informatiques.

VI. CrowdSec : les autres épisodes

Avant de vous laisser, je tenais à vous rappeler que j'ai déjà publié deux épisodes sur l'installation et la configuration de CrowdSec correspondant à deux autres cas de figure. Voici les liens :

Je profite de cet article et de l'actualité du moment liée à la faille de sécurité critique "Log4Shell" pour vous informer que CrowdSec a publié un scénario afin de détecter et bloquer cette attaque. Grâce aux différentes instances de la communauté CrowdSec, plus de 1 100 adresses IP ont déjà été bloquées pour avoir tenté d'exploiter la vulnérabilité Log4Shell. Vous pouvez accéder à cette liste d'IP gratuitement ici.

En complément, vous pouvez accéder à une carte qui permet de voir en temps réel les adresses IP à l'origine d'attaques cherchant à exploiter cette faille de sécurité : Log4j - Carte temps réel CrowdSec.

The post Comment protéger son site WordPress avec CrowdSec ? first appeared on IT-Connect.

Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec

2 novembre 2021 à 10:30

I. Présentation

Dans ce tutoriel, nous allons voir comment l'outil gratuit CrowdSec va nous permettre de protéger un serveur Web (Apache et PHP) contre les attaques informatiques.

Pour rappel, CrowdSec est un outil open source, gratuit, français, qui s'inspire du célèbre outil Fail2ban et qui a pour objectif de protéger votre serveur, en détectant puis en bloquant les attaques.

Récemment, les équipes de CrowdSec ont travaillé sur le développement d'un bouncer PHP pour protéger les serveurs Web qui tournent sur "Apache + PHP". Une excellente une idée puisque PHP est utilisé sur une très très grande majorité des sites Internet à l'échelle mondiale.

A. L'objectif du jour

Pour suivre ce tutoriel, nous allons utiliser deux machines : un serveur Web qui sera notre cible, et une seconde machine pour émettre une attaque très légère, mais réelle. Ce qui donne :

  • Un serveur Web sous Debian 11
    • Apache et PHP installés, avec un site Web tout simple
    • CrowdSec va être déployé pour protéger le serveur
  • Un poste client pour simuler une attaque, sous Kali Linux pour ma part
    • L'outil Nikto sera utilisé pour effectuer un scan du serveur Web afin de rechercher des vulnérabilités ou des erreurs de configuration

Avant d'aller plus loin, je vous invite à prendre connaissance de mon premier article au sujet de CrowdSec où je présente plus précisément l'outil et dans lequel nous avons vu comment protéger un serveur Web sous Nginx.

Si vous êtes prêt à découvrir ce second cas d'usage de CrowdSec, poursuivez la lecture !

II. Mise en place d'Apache et PHP sur Debian 11

Pour la mise en place du serveur Apache avec PHP, je vous recommande de lire ce tutoriel sur la mise en place d'un serveur LAMP sous Debian 11. Il servira de point de départ afin d'avoir un serveur Web opérationnel.

On va se contenter d'une simple page d'accueil "index.php" avec un message "Hello !". Pour créer cette page, suivez ces quelques étapes.

sudo nano /var/www/html/index.php

Insérez ce petit bout de code :

<?php
echo "<h1>Hello !</h1>";
?>

Enfin, supprimez la page d'accueil d'origine d'Apache.

sudo rm /var/www/html/index.html

Le serveur Web est prêt, nous avons une page PHP en place. Elle est accessible sur le domaine it-connect.tech.

III. Installation de CrowdSec sur Debian 11

Sur Debian 11, CrowdSec est directement dans les dépôts, ce qui va nous faciliter la vie. Il suffit de mettre à jour le cache des paquets et de lancer l'installation :

sudo apt-get update
sudo apt-get install -y crowdsec

Le cas échéant, si le paquet n'est pas disponible, vous devez utiliser cette méthode pour réaliser l'installation :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash 
sudo apt install crowdsec

Lors de l'installation, CrowdSec va analyser votre machine afin de détecter les services présents et de télécharger les collections associées. Ces composants vont permettre à CrowdSec de détecter les attaques (sans les bloquer).

On peut lister les collections avec la commande suivante :

cscli collections list

Si la collection "base-http-scenarios" est présente dans la liste, ce qui normalement le cas si vous avez déjà installé Apache sur votre serveur, cela va notamment permettre de bloquer les mauvais User Agents, comme ceux utilisés par certains outils de scans. Ceci n'est qu'un exemple, car cette collection va détecter d'autres événements comme la recherche de backdoors, etc.

On peut regarder si nous avons des décisions actives au niveau de notre instance CrowdSec. En toute logique, non. Vérifions que ce soit bien le cas avec la commande ci-dessous issue de "cscli", l'ensemble de commandes associées à CrowdSec.

sudo cscli decisions list

IV. Mon serveur Web Apache + PHP vs Nikto

A. Premier scan avec Nikto

Rappel : Nikto est un outil open source qui sert à analyser un serveur Web à la recherche de vulnérabilités ou de défaut de configuration.

Avant toute chose, il faut installer l'outil Nikto sur la machine qui sert à réaliser le scan. Pour ma part, j'utilise Kali Linux via WSL (Windows Subsystem for Linux).

L'installation s'effectue très simplement :

sudo apt-get update
sudo apt-get install nikto

Avant d'exécuter le scan Nikto, vous pouvez vérifier que votre machine Kali Linux parvient à charger la page d'accueil de votre site :

curl -I it-connect.tech

Si vous obtenez un résultat avec un code de retour HTTP égal à 200, c'est tout bon ! Maintenant, on va lancer un scan de notre serveur Web avec Nikto. Pour cela, on spécifie l'adresse IP de l'hôte cible ou le nom de domaine, et on laisse tourner. Comme ceci :

nikto -h it-connect.tech

Suite au scan avec Nikto, mon adresse IP est bien dans le viseur de CrowdSec puisqu'il a décidé de bannir mon adresse IP. Cependant, l'adresse IP n'est pas bloquée. En effet, CrowdSec doit s'appuyer sur un Bouncer pour appliquer la décision et bannir l'adresse IP.

sudo cscli decisions list

On peut voir aussi que mon analyse avec Nikto a généré plusieurs alertes, ce qui donne des indications sur les types d'attaques détectés (reason).

cscli alerts list

B. Installation de PHP Composer

Pour déployer le Bouncer PHP sur son serveur, il faut installer Composer sinon il ne s'installera pas correctement. Pour l'installer, nous avons besoin de deux paquets : php-cli et unzip, que l'on va installer sans plus attendre :

sudo apt-get update
sudo apt-get install php-cli unzip

Ensuite, il faut se positionner dans son répertoire racine et récupérer l'installeur avec Curl :

cd ~
curl -sS https://getcomposer.org/installer -o composer-setup.php

Une fois qu'il est récupéré, il faut vérifier que le hash SHA-384 correspond bien à l'installeur que l'on vient de télécharger. Cela permet de s'assurer de l'intégrité du fichier. On stocke le hash dans une variable nommée "HASH" :

HASH=`curl -sS https://composer.github.io/installer.sig`

Puis, on lance la commande fournie sur le site officiel de Composer qui va permettre de vérifier le hash avant que l'installation soit lancée :

php -r "if (hash_file('SHA384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

Vous devez obtenir le message "Installer verified". Sinon, cela signifie que votre installeur est corrompu, vous devez relancer le téléchargement.

Enfin, lancez l'installation de Composer :

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Pour vérifier que l'installation est opérationnelle, exécutez simplement :

composer

Vous devez obtenir ceci :

Composer est correctement installé, vous pouvez passer à l'installation du Bouncer en lui-même.

C. Mise en place du Bouncer PHP

Souvenez-vous du premier tutoriel sur CrowdSec où j'utilisais un serveur NginX. J'avais utilisé le Bouncer NginX directement pour bloquer les adresses IP que CrowdSec souhaitait bannir. Cette fois-ci, comme nous n'utilisons pas NginX mais Apache, on va se tourner vers un autre Bouncer : PHP.

Note : le Bouncer PHP développé par CrowdSec prend en charge de nombreuses versions (PHP 7.2.x, 7.3.x, 7.4.x et 8.0.x).

Nous avons besoin de Git pour installer ce Bouncer afin de cloner le projet. Pour installer Git :

sudo apt-get install git

Ensuite, on récupère le projet en le clonant en local :

git clone https://github.com/crowdsecurity/cs-php-bouncer.git

On obtient un dossier nommé "cs-php-bouncer" dans lequel on va se positionner :

cd cs-php-bouncer/

Puis, on lance le script d'installation (il ne doit pas être lancé avec le compte "root", ni "sudo" !) en spécifiant que l'on utilise le serveur Web "Apache" :

./install.sh --apache
Installation du Bouncer PHP sur CrowdSec
Installation du Bouncer PHP sur CrowdSec

Enfin, on suit les instructions qui s'affichent à l'écran pour finaliser l'installation. On définit comme propriétaire sur le dossier "/usr/local/php/crowdsec/" l'utilisateur associé à Apache. Par défaut, il s'agit de l'utilisateur "www-data".

sudo chown www-data /usr/local/php/crowdsec/

Puis, on termine en rechargeant la configuration d'Apache :

sudo systemctl reload apache2

Si on liste les Bouncer installés sur notre serveur, on va voir qu'il apparaît dans la liste :

sudo cscli bouncers list

D. Deuxième scan avec Nikto : le bouncer PHP va-t-il se montrer intraitable ?

Cette fois-ci, on devrait être en mesure de détecter l'attaque, de décider de bannir l'adresse IP de l'hôte "Nikto" et surtout d'appliquer la décision grâce au Bouncer PHP. C'est ce que nous allons vérifier.

On peut commencer par utiliser Curl pour vérifier que l'on obtient bien un code de retour HTTP 200.

curl -I it-connect.tech

Puis, on lance notre scan Nikto :

nikto -h it-connect.tech

Cette fois-ci, le scan mouline un peu... Comme s'il était bloqué par quelque chose. Si on force son arrêt (CTRL+C) et que l'on relance la commande Curl, on peut voir que le code de retour HTTP a changé : HTTP/1.0 403 Forbidden. Ce qui correspond à un accès refusé sur la page, y compris si l'on essaie d'accéder au serveur avec l'adresse IP au lieu du nom.

Si j'essaie d'accéder au site avec un navigateur, on peut voir qu'un message s'affiche pour indiquer que mon adresse IP a été bloquée par CrowdSec ! Le Bouncer PHP est entré en action !

Je vous rappelle que l'on peut débannir manuellement une adresse IP avec la commande suivante (nous allons utiliser cette commande dans la suite du tutoriel) :

sudo cscli decisions delete --ip X.X.X.X

De la même façon, on peut aussi bannir manuellement une adresse IP :

sudo cscli decisions add --ip X.X.X.X

V. Bouncer PHP : mise en place d'un captcha

Avec la configuration actuelle, l'adresse IP sera bloquée pour une durée de 4 heures et l'utilisateur n'a pas de possibilité d'être débloqué pendant ce temps. À moins de prendre la peine de contacter le Webmaster du site...

Pour limiter l'impact des éventuels faux positifs sur la règle "bad user agents", nous allons présenter un captcha à l'utilisateur bloqué, plutôt qu'un blocage pur. De cette façon, un robot sera bloqué tandis qu'un utilisateur réel pourra  déverrouiller l'accès au site. Nous allons réserver le même sort au crawlers malveillants (robots d'exploration).

Pour cela, il faut éditer le fichier de configuration nommé "profiles.yaml", qui est au format YAML, comme son nom l'indique.

sudo nano /etc/crowdsec/profiles.yaml

Ce fichier contient une configuration par défaut qui sert à bloquer les adresses IP pendant 4 heures, peu importe le type d'attaque détectée. Nous souhaitons conserver ce comportement, à l'exception de deux types d'alertes :

  • http-crawl-non_statics
  • http-bad-user-agent

Il faut que l'on ajoute notre configuration au début du fichier, et non pas à la fin. À ce jour, CrowdSec gère la priorité par rapport à l'ordre dans le fichier puisque dès que l'on match sur une règle, on ne vérifie pas la suite (un peu sur le même principe que les ACL sur un routeur, finalement) compte tenu de la présence de la directive "on_success: break" (voir ci-dessous).

Autrement dit, si l'on ajoute notre configuration spécifique à la suite dans le fichier profiles.yaml, cela ne fonctionnera pas, car la première règle correspondra (matchera) toujours, et donc notre règle ne sera pas prise en compte.

Voici le bout de code à ajouter au tout début du fichier :

# Bad User agents + Crawlers - Captcha 4H
name: crawler_captcha_remediation
filters:
- Alert.Remediation == true && Alert.GetScenario() in ["crowdsecurity/http-crawl-non_statics", "crowdsecurity/http-bad-user-agent"]
decisions:
- type: captcha
duration: 4h
on_success: break
---

La partie "filters" sert à spécifier que l'on cible seulement les scénarios d'alertes "http-crawl-non_statics" et "http-bad-user-agent". Ensuite, au niveau du "type", on spécifie "captcha" au lieu de "ban" qui est l'action standard.

Enfin, la partie "duration" sert à spécifier la durée pendant laquelle on présente un captcha à l'adresse IP associée au "blocage". En l'occurrence, 4h par défaut, mais vous pouvez modifier cette valeur.

Au final, vous obtenez ceci :

Sauvegardez le fichier et fermez-le. Il ne reste plus qu'à relancer CrowdSec :

sudo systemctl restart crowdsec

Avant de refaire des tests, on va supprimer la décision qui s'applique actuellement sur notre adresse IP, c'est-à-dire "ban". On utilise la commande ci-dessous en remplaçant "X.X.X.X" par l'IP publique correspondante.

sudo cscli decisions delete --ip X.X.X.X

Ensuite, il faut que l'on simule un accès depuis un user-agent non autorisé, car si j'utilise Firefox, Chrome, Brave, Edge, etc... cela ne fonctionnera pas, car ce sont des user-agent légitimes. Pour cela, on peut se référer à la liste de user-agents malveillants relayée par CrowdSec sur GitHub. Pour l'outil à utiliser, on partira sur l'excellent Curl que l'on a déjà utilisé précédemment.

Nous allons utiliser le modèle de commande suivant :

curl -I it-connect.tech -H "User-Agent: <nom-user-agent>"

Voici quelques exemples :

curl -I it-connect.tech -H "User-Agent: Cocolyzebot"
curl -I it-connect.tech -H "User-Agent: Mozlila"
curl -I it-connect.tech -H "User-Agent: OpenVAS"
curl -I it-connect.tech -H "User-Agent: Nikto"

En effectuant deux-trois requêtes Curl à destination de notre site, on se retrouve rapidement avec un code d'erreur HTTP : 401 Unauthorized. Comprenez accès non autorisé.

Maintenant que je suis bloqué par CrowdSec, on va utiliser un navigateur classique pour voir comment réagit le serveur Web.

Aaaaah ! Bonne nouvelle ! Une page avec un captcha s'affiche ! Pour outrepasser le blocage, il suffit de compléter le captcha, de cliquer sur "Continue", afin d'accéder au site.

CrowdSec - Page de blocage avec captcha
CrowdSec - Page de blocage avec captcha

Si on liste les décisions actives, on peut voir que mon adresse IP est bien associée à l'action "captcha" au lieu de l'action "ban". On peut voir aussi que mon instance CrowdSec a banni quelqu'un d'autre, qui visiblement, s'en prend à mon serveur Web.

sudo cscli decisions list

Si l'on effectue un scan avec Nikto comme nous l'avons fait à plusieurs reprises dans cette démonstration, nous n'aurons pas le captcha, nous allons être directement bannis. En fait, il y a bien un user-agent Nikto, mais le scan avec cet outil va générer d'autres alertes avant celle sur le user-agent, ce qui implique que c'est l'action "bannir" qui va s'appliquer avant l'action "captcha". En soi, ce n'est pas plus mal, car quelqu'un qui scanne notre serveur Web, on préfère autant qu'il soit complètement bloqué.

VI. Conclusion

Voilà, nous venons de voir comment sécuriser une application ou un site Internet qui tourne sur un serveur Web Apache + PHP en détectant et bloquant les attaques avec CrowdSec. On peut voir que CrowdSec est un outil efficace et personnalisable grâce à la mise en place du captcha.

Je vous rappelle que vous pouvez démarrer un container Metabase pour accéder à un dashboard afin de visualiser de beaux graphiques et avoir des métriques précises quant à l'activité de CrowdSec sur votre serveur (voir mon précédent tutoriel).

Pour finir, quelques liens :

The post Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec first appeared on IT-Connect.
❌