I was hoping Discourse could log invalid login attempts to file, even if it is something you have to configure to do so. Then I could create a custom filter and jail for discourse
I use a centralized fail2ban server. the way it works is all my Containers, Docker images, VMs have a custom ban action:
in fail2ban you specify the action to take in your jail, such as: action = iptables-allports
then all you have to do is edit that action: sudo nano /etc/fail2ban/action.d/iptables-allports.conf
With this setup your container/docker/vm will fail2ban them locally, but it will also relay this information to your central fail2ban server. The central server can also take all collected IPs and make them available as txt banlist such as: https://fail2ban.YourDomain.com/banned.txt
Then you can have your pfsense firewall subscribe to this banlist, and you can even share the list with other pfsense routers. This way if they try breaking in on one application, they get banned from everything. This has worked great for me for years.
And all that I need to implement this for discourse is for discourse to write an entry to a log file when there is an invalid login attempt
The NGINX logs
Occasionally NGINX logs may contain some extra tips, they are located at:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
The files access.log and error.log will be there as well as a bunch of rotated compressed files. Running less access.log.2.gz will automatically decompress and display the logfile for you.
This directory is also available on the host at /var/discourse/shared/standalone/log/var-log/nginx .
Unfortunately, the nginx error.log and access.log files do not log any invalid login attempts.
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.
