Détectez et bloquez les tentatives d'exploitation de Log4j avec CrowdSec

Posté par  (site web personnel) . Édité par Ysabeau 🧶 🧦 et Julien Jorge. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
24
14
déc.
2021
Administration système

Si vous travaillez dans le domaine de la cybersécurité, le week-end dernier a probablement été moins relaxant que prévu. Et ce, à cause de la découverte de la vulnérabilité zero-day Log4j (CVE-2021-44228). L’équipe CrowdSec s’est retroussé les manches pour développer un scénario capable de détecter et bloquer les tentatives d’exploitation de cette vulnérabilité. Vous pouvez le télécharger directement depuis le Hub de CrowdSec et l’installer en un clin d’œil. Preuve en vidéo.

L’efficacité de CrowdSec se basant sur le pouvoir de la foule, et à la lumière de la taille de leur communauté en pleine expansion, la solution a déjà collecté un grand nombre d’adresses IP qui tentent d’exploiter la vulnérabilité. Vous pouvez consulter la liste ici. Elle est très fréquemment mise à jour et il va sans dire que vous devriez bloquer sans attendre celles qui sont marquées comme « validated ».

Ces adresses IP ont été sélectionnées par l’algorithme de consensus de la solution, ce qui signifie qu’elles ont reçu de nombreux votes défavorables de la part de leur réseau d’utilisateurs. Celles qui sont marquées comme « not enough data » sont très suspectes mais peuvent encore contenir quelques faux positifs. Les adresses classées dans la catégorie « benign » sont utilisées par des personnes qui sont généralement du bon côté de la force, pour aider, scanner, et non à des desseins malfaisants.

Vous pouvez également utiliser leur mode replay, ou forensics, pour analyser les logs de vos serveurs afin de vérifier si une exploitation Log4j a été tentée sur l’une de ces IP, par qui et quand, en utilisant le scénario approprié et la ligne de commande ci-dessous :

sudo cscli hub update
sudo cscli scenarios install crowdsecurity/apache_log4j2_cve-2021-44228
sudo systemctl reload crowdsec

# sudo crowdsec --dsn "file://<log_file_path>" -no-api --type <log_type>
sudo crowdsec --dsn "file:///var/log/nginx/access.log" -no-api --type nginx

sudo cscli alerts list --scenario crowdsecurity/apache_log4j2_cve-2021-44228

Si vous souhaitez accéder à plus de détails concernant cet IPS open source et collaboratif, qui est capable de détecter et bloquer de nombreux comportements malveillants, tout en vous permettant de collaborer entre cyber défenseurs en échangeant les IPs bloquées, visitez leur site web ou leur dépôt GitHub.

Aller plus loin

  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille

      Posté par  . Évalué à 4.

      Ça ne fonctionnera que pour les programmes dont c'est une dépendance statique au démarrage (et donc mise dans la ligne de commande).
      Mais en général, les applications web (celles qui sont vraiment à risque) sont fournies sous forme d'une archive, dans laquelle se trouvent les dépendances, et qui sont chargées dynamiquement. Il n'est même pas nécessaire d'extraire ces dépendances, donc tu ne trouvera peut-être même pas de fichier log4j dans ton système.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille

          Posté par  . Évalué à 5.

          Ah, je n'avais pas fait attention que tu essaie de regarder dans le fichier maps, je pensais que tu regardais directement la ligne de commande.
          Alors ça ne fonctionnera probablement jamais.
          Ce ne sont pas des bibliothèques au sens du format elf, ce sont des classes java qui sont chargées (typiquement) depuis des fichiers jar, qui sont de simples archives zip, et je pense que la JVM ne garde pas les fichiers ouverts en permanence (et ne sont peut-être pas du tout mappés en mémoire).

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille

      Posté par  . Évalué à 2. Dernière modification le 16 décembre 2021 à 14:42.

      j'ai un doute sur la construction a | b && c | d. Amha cela ne fait pas ce que tu souhaites. cat cmdline | xargs -0 n'a pas de sens non plus puisque cmdline est, comme son nom l'indique, une ligne (ou alors une sublitité m'échappe, dans quel cas je te serais reconnaissant de m'éclairer). Quelque chose de la forme grep -q log4j /proc/$pid/cmdline /proc/$pid/maps && echo $pid serait à la fois plus lisible et correct.

      • [^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille

        Posté par  . Évalué à 1.

        (Bon je viens d'apprendre que xargs sans commande équivaut à echo. Je ne comprends pas trop l'intérêt de cette construction… bref)

        Chez moi grep log4j dans /proc/pid/map ne fonctionne pas, sur un process java qui utilise log4, avec openjdk11 sur debian stable.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille

            Posté par  . Évalué à 2.

            Si t’utilise tomcat, je suppute que tu a un war, qui inclue tous les jar de ton appli.
            Une autre pratique courante est d’utiliser un serveur d’appli embedded, et de shader le jar, à savoir exploser toutes les dépendances et les mettre dans un seul gros jar.
            L’avantage étant que tu te fades pas tomcat (ou autre), et surtout, tu lances l’appli avec un simple java -jar monjar.jar, ce qui rend les deploiements vachement plus simple (parce que dire à tomcat d’arrêter cette web app et la relancer, c’est vachement plus compliqué qu’un kill + java -jar monjar.jar).

            Bref, le problème c’est que je vois pas comment ta commande peut marcher dans ce mode.

            Ah, et sinon, même si ça marchait, y’a des chances pour que des bindings log4j soit embarqués par une dépendance transitive si t’utilise slf4j. Ce qui compte c’est de ne pas avoir log4j-core si je me rappelle bien.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.