Sécurisation d’un site web de type WordPress à l’aide de CrowdSec

Magazine
Marque
Linux Pratique
Numéro
133
Mois de parution
septembre 2022
Spécialité(s)


Résumé

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.


Body

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.

J’ai choisi de ne masquer aucun des éléments d’authentification et d’identification que j’ai utilisés lors de l’écriture de l’article. Il est bien évident que tous ces éléments seront détruits et rendus inutilisables avant la parution de l’article.

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 :

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

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

On peut noter qu’en ce qui concerne les paquets CrowdSec, pour les paquets de type Debian, l’intégrité est gérée par le dépôt tandis que pour les paquets de type RPM l’intégrité est gérée par une signature ajoutée aux paquets après la construction du paquet. De fait, pour les paquets Debian l’intégrité est gérée par packagecloud.io, alors que pour les paquets de type RPM elle est gérée directement par CrowdSec.

Maintenant que les dépôts sont configurés, il ne reste plus qu’à installer CrowdSec :

sudo apt install 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.

figure 01-s 2

Figure 1 : Liste des scenarios et parsers installés.

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 :

❯ sudo cscli scenarios list – a|grep wordpress
crowdsecurity/http-bf-wordpress_bf 🚫 disabled, update-available
crowdsecurity/http-bf-wordpress_bf_xmlrpc 🚫 disabled, update-available
crowdsecurity/http-wordpress_user-enum 🚫 disabled, update-available
crowdsecurity/http-wordpress_wpconfig 🚫 disabled, update-available
❯ sudo cscli scenarios install crowdsecurity/http-bf-wordpress_bf crowdsecurity/http-bf-wordpress_bf_xmlrpc crowdsecurity/http-wordpress_user-enum crowdsecurity/http-wordpress_wpconfig
INFO[22-06-2022 02:01:06 PM] crowdsecurity/http-bf-wordpress_bf : OK
INFO[22-06-2022 02:01:06 PM] Enabled scenarios : crowdsecurity/http-bf-wordpress_bf
INFO[22-06-2022 02:01:06 PM] Enabled crowdsecurity/http-bf-wordpress_bf
INFO[22-06-2022 02:01:06 PM] crowdsecurity/http-bf-wordpress_bf_xmlrpc : OK
INFO[22-06-2022 02:01:06 PM] Enabled scenarios : crowdsecurity/http-bf-wordpress_bf_xmlrpc
INFO[22-06-2022 02:01:06 PM] Enabled crowdsecurity/http-bf-wordpress_bf_xmlrpc
INFO[22-06-2022 02:01:06 PM] crowdsecurity/http-wordpress_user-enum : OK
INFO[22-06-2022 02:01:06 PM] Enabled scenarios : crowdsecurity/http-wordpress_user-enum
INFO[22-06-2022 02:01:06 PM] Enabled crowdsecurity/http-wordpress_user-enum
INFO[22-06-2022 02:01:06 PM] crowdsecurity/http-wordpress_wpconfig : OK
INFO[22-06-2022 02:01:06 PM] Enabled scenarios : crowdsecurity/http-wordpress_wpconfig
INFO[22-06-2022 02:01:06 PM] Enabled crowdsecurity/http-wordpress_wpconfig
INFO[22-06-2022 02:01:06 PM] Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.

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 :

#Generated acquisition file – wizard.sh (service : nginx) / files : /var/log/nginx/error.log /var/log/nginx/access.log
filenames :
— /var/log/nginx/error.log
— /var/log/nginx/access.log
labels :
type : nginx
---
#Generated acquisition file – wizard.sh (service : sshd) / files : /var/log/auth.log
filenames :
— /var/log/auth.log
labels :
type : syslog
---
#Generated acquisition file – wizard.sh (service : linux) / files : /var/log/syslog /var/log/kern.log /var/log/messages
filenames :
— /var/log/syslog
— /var/log/kern.log
— /var/log/messages
labels :
type : syslog
---

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

figure 02-s 0

Figure 2 : Métriques de CrowdSec.

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.

Il est possible d’effectuer cette opération en ligne de commandes, dans le cas de notre site WordPress :
❯ for i in $(seq 1 6) ; do curl – L – b – d " log=user&pwd=password&testcookie=1&rememberme=forever " https://wp-lp.sabban.eu/wp-login.php – s >/dev/null ; done

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.

figure 03-s 11

Figure 3 : Métriques de CrowdSec.

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 :

❯ sudo apt install crowdsec-firewall-bouncer-iptables

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.

figure 04-s 7

Figure 4 : Bavardage avec @BotFather.

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 :

name : default_ip_remediation
#debug : true
filters :
— Alert. Remediation == true && Alert. GetScope() == “Ip”
decisions :
— type : ban
duration : 4h
#duration_expr : Sprintf('%dh', (GetDecisionsCount(Alert. GetValue()) + 1) * 4)
notifications :
# – slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# – splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
— http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
# – email_default # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success : break

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] :

type : http # Don't change
name : http_default # Must match the registered plugin in the profile
 
# One of “trace”, “debug”, “info”, “warn”, “error”, “off”
log_level : info
 
# group_wait : # Time to wait collecting alerts before relaying a message to this plugin, eg " 30 s "
# group_threshold : # Amount of alerts that triggers a message before <group_wait> has expired, eg " 10 "
# max_retry : # Number of attempts to relay messages to plugins in case of error
# timeout : # Time to wait for response from the plugin before considering the attempt a failure, eg " 10 s "
 
#-------------------------
# plugin-specific options
 
# The following template receives a list of models. Alert objects
# The output goes in the http request body
format : |
{
"chat_id" : "-665931437 ",
"text”: "
{{range. -}}
{{$alert :=. -}}
{{range. Decisions -}}
{{. Value}} will get {{. Type}} for next {{. Duration}} for triggering {{. Scenario}}.\r\n https://www.shodan.io/host/{{. Value}}
{{end -}}
{{end -}}
"
}
 
# The plugin will make requests to this url, eg : https://www.example.com/
url : https://api.telegram.org/bot5561512049 : AAFpPMNCD-zzl6hmxZ8KyfPCtbpbyZBchCk/sendMessage
 
# Any of the http verbs : “POST”, “GET”, “PUT”…
method : POST
 
headers :
Content-Type : " application/json "
 
# skip_tls_verification : # true or false. Default is false

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 :

sudo apt purge crowdsec-firewall-bouncer-iptables

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.

❯ sudo apt install crowdsec-nginx-bouncer

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.

figure 05-s 3

Figure 5 : Page de blocage proposée par le bouncer nginx.

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.

figure 07-s 7

Figure 6 : Enregistrement d’une application utilisant reCAPTCHA.

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 :

name : default_ip_remediation
#debug : true
filters :
— Alert. Remediation == true && Alert. GetScope() == “Ip”
decisions :
— type : captcha
duration : 4h
#duration_expr : Sprintf('%dh', (GetDecisionsCount(Alert. GetValue()) + 1) * 4)
notifications :
# – slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# – splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
— http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
# – email_default # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success : break

Il faut maintenant renseigner le fichier de configuration du bouncer nginx /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf.

ENABLED=true
API_URL=http://127.0.0.1:8080
API_KEY=348e09526a17881abc0bd7a3bb41cb7a
CACHE_EXPIRATION=1
# bounce for all type of remediation that the bouncer can receive from the local API
BOUNCING_ON_TYPE=all
FALLBACK_REMEDIATION=ban
REQUEST_TIMEOUT=3000
UPDATE_FREQUENCY=10
# live or stream
MODE=live
# exclude the bouncing on those location
EXCLUDE_LOCATION=
#those apply for “ban” action
# /!\ REDIRECT_LOCATION and RET_CODE can't be used together. REDIRECT_LOCATION take priority over RET_CODE
BAN_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/ban.html
REDIRECT_LOCATION=
RET_CODE=
#those apply for “captcha” action
# ReCaptcha Secret Key
 
SECRET_KEY=6Lf_aa0gAAAAAB9WSPNYV3QvCrtfO2pBioVyvGRD
# Recaptcha Site key
SITE_KEY=6Lf_aa0gAAAAAFSRQzDDoFPJLl1-i9uIrsmOYSDU
CAPTCHA_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/captcha.html
CAPTCHA_EXPIRATION=3600

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.

figure 08-s 5

Figure 7 : Demande de captcha.

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.

name : default_ip_remediation_ssh
debug : true
filters :
— Alert. Remediation == true && Alert. GetScope() == “Ip” && Alert. GetScenario() in ["crowdsecurity/ssh-bf ", " crowdsecurity/ssh-slow-bf ", " crowdsecurity/ssh-bf_user-enum "]
decisions :
— type : ban
duration : 4h
#duration_expr : Sprintf('%dh', (GetDecisionsCount(Alert. GetValue()) + 1) * 4)
notifications :
# – slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# – splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
— http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
# – email_default # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success : break
---
name : default_ip_remediation_http
#debug : true
filters :
— Alert. Remediation == true && Alert. GetScope() == “Ip” && Alert. GetScenario() not in ["crowdsecurity/ssh-bf ", " crowdsecurity/ssh-slow-bf ", " crowdsecurity/ssh-bf_user-enum "]
decisions :
— type : captcha
duration : 4h
#duration_expr : Sprintf('%dh', (GetDecisionsCount(Alert. GetValue()) + 1) * 4)
notifications :
# – slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# – splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
— http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
# – email_default # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success : break

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/



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Stubby : protection de votre vie privée via le chiffrement des requêtes DNS

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Depuis les révélations d’Edward Snowden sur l’espionnage de masse des communications sur Internet par la NSA, un effort massif a été fait pour protéger la vie en ligne des internautes. Cet effort s’est principalement concentré sur les outils de communication avec la généralisation de l’usage du chiffrement sur le web (désormais, plus de 90 % des échanges se font en HTTPS) et l’adoption en masse des messageries utilisant des protocoles de chiffrement de bout en bout. Cependant, toutes ces communications, bien que chiffrées, utilisent un protocole qui, lui, n’est pas chiffré par défaut, loin de là : le DNS. Voyons ensemble quels sont les risques que cela induit pour les internautes et comment nous pouvons améliorer la situation.

Surveillez la consommation énergétique de votre code

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Être en mesure de surveiller la consommation énergétique de nos applications est une idée attrayante, qui n'est que trop souvent mise à la marge aujourd'hui. C'est d'ailleurs paradoxal, quand on pense que de plus en plus de voitures permettent de connaître la consommation instantanée et la consommation moyenne du véhicule, mais que nos chers ordinateurs, fleurons de la technologie, ne le permettent pas pour nos applications... Mais c'est aussi une tendance qui s'affirme petit à petit et à laquelle à terme, il devrait être difficile d'échapper. Car même si ce n'est qu'un effet de bord, elle nous amène à créer des programmes plus efficaces, qui sont également moins chers à exécuter.

Donnez une autre dimension à vos logs avec Vector

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Avoir des informations précises et détaillées sur ce qu’il se passe dans une infrastructure, et sur les applications qu'elle héberge est un enjeu critique pour votre business. Cependant, ça demande du temps, temps qu'on préfère parfois se réserver pour d'autres tâches jugées plus prioritaires. Mais qu'un système plante, qu'une application perde les pédales ou qu'une faille de sécurité soit découverte et c'est la panique à bord ! Alors je vous le demande, qui voudrait rester aveugle quand l'observabilité a tout à vous offrir ?

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 63 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous