Speravo che Discourse potesse registrare i tentativi di accesso non validi su file, anche se ciò richiede una configurazione specifica. Potrei così creare un filtro e un jail personalizzati per Discourse.
Utilizzo un server fail2ban centralizzato. Il suo funzionamento prevede che tutti i miei container, immagini Docker e VM abbiano un’azione di blocco personalizzata:
in fail2ban si specifica l’azione da eseguire nel proprio jail, ad esempio: action = iptables-allports
basta poi modificare quell’azione: sudo nano /etc/fail2ban/action.d/iptables-allports.conf
Con questa configurazione, il tuo container/Docker/VM bloccherà gli aggressori localmente tramite fail2ban, ma inoltrerà anche queste informazioni al server fail2ban centralizzato. Il server centrale può raccogliere tutti gli indirizzi IP e renderli disponibili come elenco di blocco in formato txt, ad esempio: https://fail2ban.YourDomain.com/banned.txt
In questo modo, il tuo firewall pfSense può iscriversi a questo elenco di blocchi e puoi persino condividerlo con altri router pfSense. Così, se qualcuno tenta di infiltrarsi in una sola applicazione, viene bloccato da tutto. Questo sistema funziona benissimo per me da anni.
E tutto ciò che mi serve per implementare questa soluzione su Discourse è che Discourse scriva una voce in un file di log quando si verifica un tentativo di accesso non valido
I log di NGINX
Occasionalmente i log di NGINX possono contenere alcuni suggerimenti aggiuntivi, si trovano in:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
I file access.log e error.log saranno lì, insieme a una serie di file compressi ruotati. Eseguiendo less access.log.2.gz verrà automaticamente decompresso e visualizzato il file di log.
Questa directory è disponibile anche sull’host in /var/discourse/shared/standalone/log/var-log/nginx.
Purtroppo, i file nginx error.log e access.log non registrano tentativi di accesso non validi.
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.
