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.
El archivo access.log de nginx debería tener líneas con respuestas 403 a la ruta de inicio de sesión que necesitas para esto. ¿Has revisado los registros?
Hola @Falco, gracias por la respuesta. Revisé los logs de inmediato, un intento de contraseña correcto y un intento de contraseña incorrecto me parecen iguales (respuesta 200):
(Sanitizé la dirección IP y el dominio, el resto no se modificó)
Así que, dado que ambos devuelven una respuesta 200, no puedes usar esto para fail2ban, banearás a todos los usuarios, ya sea con contraseña buena o mala.
Twitter usa 400 para contraseña incorrecta, pero Facebook, LinkedIn, Google y Amazon devuelven un 200. En mi opinión, un 200 suena mal, pero parece ser lo “normal”.
Quizás puedas empezar con un plugin que se enganche a este método aquí:
¡genial, gracias por la respuesta! Tan pronto como tenga un poco de tiempo libre, intentaré crear un plugin para generar esta información. (Todo lo que necesito es la dirección IP registrada en un archivo cuando alguien intenta iniciar sesión con una contraseña incorrecta, por ejemplo: intento de inicio de sesión inválido desde la IP 10.111.222.33)
Estoy escribiendo sobre los roles de webmaster autodidacta y usuario final puro, pero…
El inicio de sesión no válido es un error 200 por definición. Claro, puede y debe ser un error interno de una aplicación, y en algún momento generar algo más, como un error 403 más algo más como enviar un enlace de recuperación, pero no debería o no puede suceder de inmediato.
Fail2ban es una buena herramienta pero realmente sobrevalorada. Olvidemos Docker, porque hace todo más difícil, pero el simple hecho de que pueda eludir iptables de VPS es algo realmente confuso para mí. Pero los bots tienen tendencia a cambiar de IP después de cada tercer intento y eso hace que Fail2ban sea bastante inútil contra un ataque de fuerza bruta puro a través del inicio de sesión.
Los script kiddies son otra historia, por supuesto. Copian y pegan todo lo que encuentran, lo prueban y no juegan con las IPs. Entonces Fail2ban puede detenerlos, incluso rara vez pueden hacer algo dañino, pero aumentan la carga. El problema real es la cantidad de script kiddies cuando hay una inundación instantánea.
Pero mientras el VPS pueda manejar tal situación, simplemente no importa. Ahora es 2023 y la mayoría de esos imbéciles están atacando vulnerabilidades antiguas de WordPress en sitios de Discourse
Pero deberíamos tener alguna lógica para detener los inicios de sesión constantes, sin importar si no es una amenaza cotidiana, supongo.
