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.
Ciao @Falco grazie per la risposta. Ho controllato subito i log, un tentativo di password corretto e un tentativo di password errato mi sembrano uguali (risposta 200):
(Ho sanitizzato l’indirizzo IP e il dominio, il resto è invariato)
Twitter usa 400 per password errata, ma Facebook, LinkedIn, Google e Amazon restituiscono un 200. Secondo me un 200 suona sbagliato, ma sembra essere la cosa “normale”?
Forse puoi iniziare con un plugin che si aggancia a questo metodo qui
fantastico, grazie per la risposta! Appena avrò un po’ di tempo libero proverò a creare un plugin per generare queste informazioni! (tutto ciò di cui ho bisogno è l’indirizzo IP registrato su un file quando qualcuno tenta di accedere con una password errata, ad esempio: tentativo di accesso non valido dall'IP 10.111.222.33)
Sto scrivendo sui ruoli di webmaster autodidatta e utente finale puro, ma…
Il login non valido è per definizione un errore 200. Certo, può e dovrebbe essere un errore interno di un’app e a un certo punto generare qualcos’altro, come un errore 403 più qualcos’altro come l’invio di un link di recupero, ma non dovrebbe o non può accadere subito.
Fail2ban è uno strumento carino ma davvero sopravvalutato. Dimentichiamo docker, perché rende tutto più difficile, ma il solo fatto che possa bypassare iptables di VPS è davvero una cosa fumosa per me. Ma i bot hanno la tendenza a cambiare IP dopo ogni terzo tentativo e questo rende Fail2ban piuttosto inefficace contro un attacco brute force puro tramite login.
Gli script kiddie sono un’altra storia, ovviamente. Copiano e incollano tutto ciò che trovano, danno una possibilità e non giocano con gli IP. Allora Fail2ban può fermarli, anche se raramente possono fare danni, ma aumentano il carico. Il vero problema è la quantità di script kiddie quando c’è un flood istantaneo.
Ma finché VPS può gestire tale situazione, semplicemente non ha importanza. Ora siamo nel 2023 e per lo più quei cazzoni stanno bussando alle antiche vulnerabilità di WordPress sui siti discourse
Ma dovremmo avere una logica per fermare i login costanti, anche se non è una minaccia quotidiana, credo.
