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.
Olá @Falco, obrigado pela resposta. Verifiquei os logs imediatamente, uma tentativa de senha correta e uma tentativa de senha incorreta parecem iguais para mim (resposta 200):
(Sanitizei o endereço IP e o domínio, o resto está intacto)
O Twitter usa 400 para senha errada, mas Facebook, LinkedIn, Google e Amazon retornam 200. Na minha opinião, um 200 soa errado, mas parece ser a coisa “normal”?
Talvez você possa começar com um plugin que se conecte a este método aqui
incrível, obrigado pela resposta! Assim que tiver um pouco de tempo livre, tentarei criar um plugin para gerar essas informações! (tudo que preciso é que o endereço IP seja registrado em um arquivo quando alguém tentar fazer login com uma senha incorreta, por exemplo: tentativa de login inválida do IP 10.111.222.33)
Estou escrevendo sobre os papéis de webmaster autodidata e usuário final puro, mas…
Login inválido é erro 200 por definição. Claro, pode e deve ser um erro interno de um aplicativo e, em algum momento, gerar algo mais, como erro 403 mais algo como enviar um link de recuperação, mas não deveria ou não pode acontecer imediatamente.
Fail2ban é uma ferramenta legal, mas realmente superestimada. Vamos esquecer o docker, porque ele torna tudo mais difícil, mas o simples fato de poder contornar o iptables do VPS é algo realmente confuso para mim. Mas os bots têm a tendência de mudar de IP após a cada 3ª tentativa e isso torna o Fail2ban bastante ineficaz contra ataques de força bruta puros via login.
Script kiddies são outra história, é claro. Eles copiam e colam tudo o que encontram, dão uma rodada e não mexem com IPs. Então o Fail2ban pode detê-los, mesmo que raramente possam fazer algum mal, mas aumentam a carga. O problema real é a quantidade de script kiddies quando há um fluxo instantâneo.
Mas, desde que o VPS possa lidar com tal situação, isso simplesmente não importa. Agora é 2023 e a maioria desses idiotas está explorando vulnerabilidades antigas do wordpress em sites de discourse
Mas deveríamos ter alguma lógica para parar logins constantes, mesmo que não seja uma ameaça diária, eu acho.
