Eu esperava que o Discourse pudesse registrar tentativas de login inválidas em um arquivo, mesmo que fosse algo que você precisasse configurar para fazer. Assim, eu poderia criar um filtro e um jail personalizados para o Discourse.
Eu uso um servidor fail2ban centralizado. O funcionamento é o seguinte: todos os meus Containers, imagens Docker e VMs têm uma ação de banimento personalizada:
No fail2ban, você especifica a ação a ser tomada no seu jail, por exemplo: action = iptables-allports
Depois, tudo o que você precisa fazer é editar essa ação: sudo nano /etc/fail2ban/action.d/iptables-allports.conf
Com essa configuração, seu container/docker/VM aplicará o fail2ban localmente, mas também repassará essas informações para o seu servidor fail2ban central. O servidor central também pode pegar todos os IPs coletados e disponibilizá-los como uma lista de banimento em texto, por exemplo: https://fail2ban.SuaDominio.com/banned.txt
Daí, você pode fazer com que seu firewall pfSense assine essa lista de banimento, e até mesmo compartilhar a lista com outros roteadores pfSense. Assim, se alguém tentar invadir um aplicativo, será banido de tudo. Isso funcionou muito bem para mim há anos.
E tudo o que preciso para implementar isso no Discourse é que o Discourse escreva uma entrada em um arquivo de log quando houver uma tentativa de login inválida
Os logs do NGINX
Ocasionalmente, os logs do NGINX podem conter algumas dicas extras, eles estão localizados em:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
Os arquivos access.log e error.log estarão lá, assim como vários arquivos rotacionados e compactados. Executar less access.log.2.gz irá automaticamente descompactar e exibir o arquivo de log para você.
Este diretório também está disponível no host em /var/discourse/shared/standalone/log/var-log/nginx.
Infelizmente, os arquivos nginx error.log e access.log não registram nenhuma tentativa de login inválida.
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.
