J’espérais que Discourse puisse enregistrer les tentatives de connexion invalides dans un fichier, même si cela nécessite une configuration spécifique. Ensuite, je pourrais créer un filtre et un jail personnalisés pour Discourse.
J’utilise un serveur fail2ban centralisé. Le principe est que tous mes conteneurs, images Docker et machines virtuelles disposent d’une action d’interdiction personnalisée :
Dans fail2ban, vous spécifiez l’action à exécuter dans votre jail, par exemple : action = iptables-allports
Ensuite, il suffit de modifier cette action : sudo nano /etc/fail2ban/action.d/iptables-allports.conf
Avec cette configuration, votre conteneur/Docker/VM effectuera l’interdiction localement via fail2ban, mais transmettra également ces informations à votre serveur fail2ban central. Le serveur central peut également rassembler toutes les adresses IP collectées et les rendre disponibles sous forme de liste d’interdiction au format texte, par exemple : https://fail2ban.VotreDomaine.com/banned.txt
Ensuite, vous pouvez configurer votre pare-feu pfSense pour s’abonner à cette liste d’interdiction, et vous pouvez même partager cette liste avec d’autres routeurs pfSense. Ainsi, si une entité tente de s’infiltrer dans une application, elle sera bannie de toutes les autres. Cette méthode fonctionne parfaitement pour moi depuis des années.
Et tout ce dont j’ai besoin pour mettre cela en œuvre avec Discourse, c’est que Discourse écrive une entrée dans un fichier journal lorsqu’une tentative de connexion invalide se produit
Les journaux NGINX
Occasionnellement, les journaux NGINX peuvent contenir quelques conseils supplémentaires. Ils se trouvent à l’adresse suivante :
cd /var/discourse
./launcher enter app
cd /var/log/nginx
Les fichiers access.log et error.log s’y trouvent, ainsi qu’un ensemble de fichiers compressés rotatifs. Exécuter la commande less access.log.2.gz décompresse et affiche automatiquement le fichier journal pour vous.
Ce répertoire est également accessible sur l’hôte à l’adresse /var/discourse/shared/standalone/log/var-log/nginx.
Malheureusement, les fichiers error.log et access.log de nginx n’enregistrent aucune tentative de connexion invalide.
Le fichier nginx access.log devrait contenir des lignes avec des réponses 403 à la route de connexion dont vous avez besoin. Avez-vous vérifié les journaux ?
Bonjour @Falco, merci pour votre réponse. J’ai vérifié les journaux immédiatement, une tentative de mot de passe correct et une tentative de mot de passe incorrect me semblent identiques (réponse 200) :
(J’ai assaini l’adresse IP et le domaine, le reste est intact)
Donc, puisqu’ils renvoient tous les deux une réponse 200, vous ne pouvez pas l’utiliser pour fail2ban, vous bannirez tous les utilisateurs, qu’ils aient un bon ou un mauvais mot de passe.
Twitter utilise 400 pour un mot de passe incorrect, mais Facebook, LinkedIn, Google et Amazon renvoient un 200. À mon avis, un 200 semble faux, mais il semble que ce soit la chose « normale » ?
Peut-être pourriez-vous commencer par un plugin qui s’accroche à cette méthode ici :
Génial, merci pour votre réponse ! Dès que j’aurai un peu de temps libre, j’essaierai de créer un plugin pour générer ces informations ! (tout ce dont j’ai besoin, c’est que l’adresse IP soit enregistrée dans un fichier lorsque quelqu’un tente de se connecter avec un mot de passe incorrect, par exemple : tentative de connexion invalide depuis l'IP 10.111.222.33)
J’écris sur les rôles de webmaster autodidacte et d’utilisateur final pur, mais…
Une connexion invalide est une erreur 200 par définition. Bien sûr, cela peut et devrait être une erreur interne d’une application, et à un moment donné, générer autre chose, comme une erreur 403 plus quelque chose comme l’envoi d’un lien de récupération, mais cela ne devrait pas ou ne peut pas se produire immédiatement.
Fail2ban est un bon outil mais vraiment surestimé. Oublions Docker, car cela rend tout plus difficile, mais le simple fait qu’il puisse contourner iptables de VPS est vraiment une chose brumeuse pour moi. Mais les bots ont tendance à changer d’IP après chaque 3ème tentative, ce qui rend Fail2ban assez inefficace contre les attaques par force brute via la connexion.
Les script kiddies sont une autre histoire, bien sûr. Ils copient-collent tout ce qu’ils trouvent, font une tentative et ne jouent pas avec les adresses IP. Alors Fail2ban peut les arrêter, même s’ils peuvent rarement faire du mal, mais augmenter la charge. Le vrai problème est la quantité de script kiddies lorsqu’il y a un déluge instantané.
Mais tant que le VPS peut gérer une telle situation, cela n’a pas d’importance. Nous sommes en 2023 et la plupart de ces connards frappent les vulnérabilités anciennes de WordPress sur les sites Discourse
Mais nous devrions avoir une certaine logique pour arrêter les connexions constantes, même si ce n’est pas une menace quotidienne, je pense.
