Dans un précédent article, Benoît Benedetti présentait le logiciel CrowdSec [1] et montrait comment s’en servir pour détecter et bloquer des attaques. Dans cet article, nous allons nous intéresser à un cas d’usage plus spécifique. Il s’agit ainsi d’utiliser l’écosystème proposé par CrowdSec pour améliorer la sécurité d’un site web de type WordPress contre des attaques à la fois ciblées et opportunistes. Cela s’articulera autour de la détection des attaques et de la notification de ces attaques. Pour finir, nous proposerons deux remédiations différentes contre ces attaques.
1. Introduction
CrowdSec est une solution logicielle libre pour détecter les attaques en lisant les journaux générés par les différents services exposés d’une machine. Chaque détection peut s’accompagner d’une remédiation spécifique à l’attaque. Dans l’écosystème CrowdSec, l’agent crowdsec est chargé des détections en ingérant différentes sources de journaux (fichier, journald, Docker ou autres). Les fichiers journaux (logs) sont normalisés par des parsers puis traités par des scénarios. Ces scénarios expriment dans quelles conditions une alerte doit être levée. L’installation des parsers et des scénarios est à la charge de l’utilisateur, même si un outil est fourni pour l’aider. Ces parsers et scénarios sont proposés au travers du hub (https://hub.crowdsec.net). En général, il faut installer un parser pour un type de log produit par un service, tandis qu’un scénario correspond à un type de menace particulière. Par exemple, il existe un parser pour le service openssh, mais un scénario pour la détection de login par force brute, et un autre pour détecter l’énumération des utilisateurs.
La force du logiciel CrowdSec est de proposer de partager anonymement les alertes déclenchées pour construire une base de données enrichie des menaces de chaque utilisateur en temps réel. L’agent va pouvoir télécharger les éléments de cette base de données compatibles avec les scénarios installés et bénéficier ainsi de la connaissance des menaces auxquelles les autres utilisateurs de CrowdSec ont été confrontés. Il faut noter que cette base de données est protégée contre les empoisonnements.
Nous allons donc mettre en œuvre cette solution logicielle pour améliorer la sécurité d’une installation de WordPress propulsée par nginx. Je laisse à la sagacité du lecteur la mise en œuvre et la configuration d’un WordPress. On peut noter qu’une recherche à l’aide du moteur de recherche préféré du lecteur pourra lui donner profusion de ressources et que ce que l’article propose pourrait être mis en œuvre sur beaucoup d’autres types d’installations pour peu que ce soit un site web muni d’une mire de login.
Notons que l’installation est faite sur une Debian 11 et que l’error log et l’access log de nginx se trouvent respectivement dans /var/log/nginx/error.log et /var/log/nginx/access.log.
2. Configuration
2.1 Installation et configuration de l’agent CrowdSec
CrowdSec utilise les services de packagecloud.io comme dépôt de paquetages. Pour le moment, Debian, Ubuntu, Rasperry Pi OS, Red Hat, CenOS, Fedora et Amazon Linux sont supportés. La documentation de packagecloud.io indique la commande suivante pour installer les dépôts de CrowdSec :
Même si exécuter un script directement après téléchargement est évidemment une mauvaise idée, ce script permet à la fois de configurer les dépôts CrowdSec de packagecloud.io, et d’installer les clefs GPG liées à ce dépôt et les outils nécessaires pour en vérifier l’intégrité.
Maintenant que les dépôts sont configurés, il ne reste plus qu’à installer CrowdSec :
Notons dès à présent qu’un certain nombre de parsers et de scénarios ont déjà été installés comme le montre la figure 1.
Tous les scénarios liés à des services web et à ssh ont déjà été installés. Une détection des services est exécutée au moment de l’installation, cela permet d’installer les parsers et scénarios pertinents. Il faut par contre installer les scénarios spécifiques à WordPress, car pour le moment il n’y a pas de détection des applicatifs web spécifiques :
Vérifions maintenant que tout fonctionne correctement. D’abord, il faut s’assurer que les journaux ingérés par l’agent CrowdSec soient les bons. Ceci est configuré dans le fichier /etc/crowdsec/acquis.yaml :
Nous pouvons constater que l’installeur a détecté les sources de journaux de manière satisfaisante. Les fichiers error.log et access.log sont vus comme source de type nginx.
Le type du parser permet à l’agent CrowdSec de savoir quel parser appliquer. En fait, lorsque le parser est de type syslog, le format de log contient le nom du service, et c’est ce nom de service qui est utilisé pour déterminer le parser, tandis que lorsque le format de journalisation ne spécifie pas le nom du service, il n’y a pas d’autre solution que de l’indiquer à l’agent CrowdSec. C’est pour cette raison qu’il est nécessaire d’indiquer le type nginx pour nos fichiers access.log et error.log.
Vérifions maintenant que l’ensemble fonctionne comme prévu. La méthode est simple : il suffit de tenter de se loguer avec un mot de passe aléatoire sur la page de login du WordPress. On vérifie ensuite que l’événement a été détecté.
La commande cscli metrics nous permet de constater qu’une ligne du fichier access.log a été lue, normalisée et qu’un scénario a été initié. En effet, nous constatons que le bucket crowdsecurity/http-bf-wordpress_bf a été instancié et qu’un événement a été versé dedans. Néanmoins, nous n’avons pas, avec cette manière de procéder, la certitude que c’est nous qui avons généré cet événement. Ainsi pour s’en assurer, nous allons déclencher le scénario et nous assurer que la décision résultante implique notre IP. Pour ce faire, nous allons simplement répéter l’opération qui consiste à utiliser un mot de passe aléatoire un nombre suffisant de fois pour obtenir une prise de décision de la part de l’agent crowdsec.
Ensuite, il suffit de lister les décisions pour constater que la décision prise concerne notre IP à l’aide de la commande cscli decisions list comme le montre la figure 3.
2.2 Installation et configuration d’un bouncer CrowdSec
Dans la terminologie de l’écosystème CrowdSec le service chargé de remédiation est appelé bouncer. Il s’agit pour ce bouncer de proposer une remédiation au niveau adapté. Dans notre cas d’espèce, nous allons commencer par installer et configurer le firewall bouncer. Celui-ci peut s’installer en plusieurs saveurs iptables, nftables et pf. Nous allons nous intéresser à iptables. Pour l’installer, il suffit de faire :
Maintenant, les décisions entraîneront un blocage immédiat de l’IP malveillante. Il faut faire attention, lors de nos tests, de ne pas nous couper nos propres accès. La configuration du bouncer est accessible à travers le fichier /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Le seul aspect vraiment critique de la configuration du bouncer est l’entrée api_key qui est en fait la clé permettant l’authentification auprès de l’agent crowdsec. Cette clé a été générée automatiquement au moment de l’installation. Si on voulait la générer à nouveau ou connecter le bouncer à un agent d’une autre machine, il est possible de le faire grâce à la commande cscli bouncers add <nom du bouncer>.
Notons qu’il existe pour les bouncers deux manières de récupérer les décisions auprès de l’agent crowdsec. La première manière, le mode stream est d’aller chercher les nouvelles décisions toutes les 10 s, et la deuxième manière, le mode live est d’aller chercher si l’IP fait partie d’une décision pour chaque tentative de connexion. Ce bouncer utilise le mode stream.
3. Configuration de notifications
Dans ce paragraphe, nous allons mettre en place la configuration nécessaire pour que les alertes émises par l’agent CrowdSec nous soient notifiées. Plusieurs supports sont supportés : e-mail, slack, splunk et http. Nous allons utiliser ce dernier pour notifier un compte Telegram.
3.1 Création d’un bot Telegram
D’après la documentation de Telegram, il semble que la manière correcte de faire est de créer un bot [2]. D’abord, il faut créer un groupe. Ensuite, un bavardage avec @BotFather comme le montre la figure nous permet de créer un bot. Ainsi, grâce à la commande /newbot, @BotFather nous demande un nom et nom d’utilisateur pour notre nouveau bot. Enfin, celui-ci nous donne un token d’accès à l’API HTTP.
Il reste à ajouter notre bot au groupe que l’on souhaite utiliser pour les notifications.
Il nous faut également obtenir le chat_id de notre bot. Nous pouvons l’obtenir à l’adresse https://api.telegram.org/bot<BotToken>/getUpdates. Il peut être nécessaire de bavarder un peu avec le bot et d’envoyer quelques commandes (/my_id, /start ou /help) pour rendre l’URL proposée active.
3.2 Configuration de l’agent Crowdsec
Les fichiers de configuration impliqués dans la configuration des notifications sont le fichier de configuration des profils /etc/crowdsec/profiles et /etc/crowdsec/notifications/http.yaml.
3.2.1 Profils
Intéressons-nous d’abord à la configuration du profil. Le fichier de configuration est donné par :
Notons dès à présent l’entrée de configuration filters. C’est une liste de filtres chargée de discriminer quelles sont les décisions qui sont prises en charge par ce profil. Ces filtres sont basés sur le paquet golang expr [3] augmenté d’un certain nombre d’éléments auxiliaires [4]. Ils permettent une réelle souplesse de configuration pour s’adapter aux besoins spécifiques : ils permettent d’agir sur les valeurs présentes dans la décision. Celles-ci sont configurables par le scénario. Pour ce qui est de la configuration par défaut, le flag Alert. Remediation est ajouté par le scénario, pour déterminer si les décisions doivent faire l’objet de remédiation. Ce flag est présent systématiquement pour les scénarios dont CrowdSec considère la probabilité de faux-positif comme très faible. C’est effectivement le cas pour les scénarios http-bf-wordpress_bf, http-bf-wordpress_bf_xmlrpc, http-wordpress_user-enum et http-wordpress_wpconfig qui nous intéressent. L’autre partie de l’expression, Alert. GetScope(), vérifie que la remédiation concerne l’IP, ce qui est le cas par défaut quand le scénario ne précise pas autre chose. Pour chaque décision prise par l’agent CrowdSec, si la valeur du filtre appliqué sur la décision renvoie True, alors le profil s’applique. Ainsi, un ban de quatre heures est appliqué (pour que ban soit vraiment effectif, il faut qu’un bouncer au moins soit installé), et la décision est envoyée aux plugins de notifications actifs. Comme nous avons besoin du plugin de notification http, il suffit pour nous de rendre actif le plugin http_default comme montré dans le fichier de configuration d’exemple.
3.2.2 Configuration des notifications http
Passons maintenant au fichier de configuration des notifications http /etc/crowdsec/notifications/http.yaml. La documentation officielle propose la chose suivante [5] :
Le type est simplement le choix du plugin qui va être exécuté. L’entrée name doit impérativement correspondre à au moins une entrée du fichier de profil. Les options de configuration suivantes permettent de paramétrer l’arrivée groupée ou non des notifications. Ainsi, par défaut, le plugin attend au maximum 30 s pour tenter d’envoyer une notification groupée, à moins qu’il y ait plus de 10 notifications en attente. C’est l’entrée format qui est le template de la notification. Le langage de templating est Sprig [6]. Enfin, il reste à configurer l’URL avec le token d’authentification que nous avons récupéré auprès de @BotFather. Pour finir, il faut renseigner le chat_id que nous avons récupéré précédemment. Notons qu’il faut indiquer que la notification est envoyée en JSON.
4. Mise en place de remédiation applicative
Nous souhaitons maintenant utiliser un autre bouncer de manière à mettre en œuvre une remédiation des attaques qui soit moins binaire que de bloquer ou non un attaquant.
4.1 Installation du bouncer nginx
Si le paquet crowdsec-firewall-bouncer-iptables est toujours installé, il faut commencer par l’enlever en utilisant la commande :
Installons maintenant le bouncer nginx. La partie bouncer est écrite en lua et utilise le module lua de nginx. Celle-ci requiert un certain nombre de dépendances liées à lua.
Nous pouvons maintenant tester ce bouncer. Par défaut, ce bouncer retourne une erreur http 403 à l’attaquant avec la page html fournie avec le bouncer qui se trouve à /var/lib/crowdsec/lua/templates/ban.html.
Ainsi, lorsque nous effectuons un nombre suffisant de tentatives de connexions à notre site web WordPress, nous obtenons effectivement la page de blocage proposée par le bouncer nginx comme le montre la figure 5.
4.2 Configuration du bouncer pour utiliser des captchas
Plutôt que d’envisager un ban pur et simple, il est possible de proposer des remédiations plus souples. Par exemple, il est possible d’imposer l’utilisation d’un captcha pour les IP malveillantes. L’intérêt est simple, cela permet d’éviter des faux-positifs. Les utilisateurs légitimes, qui se seraient trompés de nombreuses fois de mot de passe pourraient avoir ainsi une chance d’utiliser le service. L’utilisation de captcha est un bon compromis pour bloquer l’accès aux bots malveillants effectuant leurs attaques automatiquement à l’aide de scripts.
Le défaut de l’utilisation des captchas est bien sûr l’accessibilité des personnes ayant un handicap visuel ou auditif. Néanmoins, l’imposition d’un captcha est un moyen de continuer à rendre notre site accessible, et dans ce cadre-là, probablement plus acceptable que placé d’office sur une page d’accueil.
Dans le cadre de notre bouncer nginx, pour le moment seul reCAPTCHA v2 est supporté. Pour le mettre en place, il est nécessaire de s’enregistrer auprès des services de Google. Pour ce faire, à l’heure actuelle le service se trouve à l’adresse https://www.google.com/recaptcha/admin/create. Cela se remplit assez facilement, l’important est de préciser reCAPTCHAv2 et de préciser le domaine auquel le captcha va s’appliquer comme le montre la figures 6.
Il ne faut pas oublier de changer la configuration du profil côté CrowdSec. En effet, il faut changer le type de remédiation de ban à captcha :
Il faut maintenant renseigner le fichier de configuration du bouncer nginx /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf.
API_URL et API_KEY permettent de s’authentifier auprès de l’agent CrowdSec. API_KEY a été généré à l’installation du bouncer. SECRET_KEY et SITE_KEY sont les éléments d’authentification que le service d’enregistrement auprès de Google nous a fournis.
Après relance du service CrowdSec et de nginx, notre habituelle tentative de force brute sur notre site web se solde effectivement par la demande de remplir un captcha comme le montre la figure 7.
4.3 Utilisation des deux bouncers
Nous allons maintenant utiliser les deux bouncers simultanément. Le bouncer iptables sera utilisé pour les attaques du service ssh, et le bouncer nginx pour toutes les attaques du service http. Pour obtenir cette configuration, nous allons utiliser deux profils différents avec un filtrage des décisions pour affecter à l’un ou l’autre des bouncers.
Pour affecter les attaques sur le service ssh au bouncer iptables, nous avons ajouté l’expression && Alert. GetScenario() in ["crowdsecurity/ssh-bf ", " crowdsecurity/ssh-slow-bf ", " crowdsecurity/ssh-bf_user-enum "] qui va tester si la décision est issue d’un des trois scénarios ssh. En revanche, pour affecter les décisions au bouncer nginx, nous avons simplement inversé la condition sur les scénarios ssh. Si la décision n’est pas issue d’une attaque sur le service ssh, alors elle est affectée au bouncer nginx.
Notons quand même qu’après le déclenchement du bouncer iptables, un attaquant n’aura plus l’occasion de déclencher l’autre bouncer puisqu’il sera bloqué au niveau du firewall.
Conclusion
Nous avons présenté l’utilisation de CrowdSec dans un environnement web simple. Ce que nous avons montré est tout à fait réutilisable dans d’autres environnements de type web. Il existe aussi d’autres possibilités de bouncer comme OpenResty, Ingress Nginx pour les environnements Kubernetes, WAF AWS pour les environnements serverless sur AWS ou même une librairie PHP pour une inclusion directement dans l’application. De plus, le développement continue, de nouvelles fonctionnalités et de nouveaux bouncers sont prévus. Nous avons également montré comment utiliser deux bouncers côte à côte en filtrant les décisions.
Références
[1] Benoît Benedetti, Détecter et bloquer les attaques avec CrowdSec, l’IPS/IDS communautaire :
https://connect.ed-diamond.com/linux-pratique/lp-132/detecter-et-bloquer-les-attaques-avec-crowdsec-l-ips-ids-communautaire
[2] https://core.telegram.org/api
[3] https://github.com/antonmedv/expr
[4] CrowdSec : Documentation Expr Helpers, https://docs.crowdsec.net/docs/v1.3.0/expr/helpers
[5] CrowdSec : Documentation Telegram Notification Plugin,
https://docs.crowdsec.net/docs/v1.3.0/notification_plugins/telegram
[6] Sprig, http://masterminds.github.io/sprig/
