Esperaba que Discourse pudiera registrar los intentos de inicio de sesión no válidos en un archivo, incluso si eso requiere una configuración específica. De esa manera, podría crear un filtro y una jail personalizados para Discourse.
Uso un servidor fail2ban centralizado. El funcionamiento es el siguiente: todos mis contenedores, imágenes de Docker y máquinas virtuales tienen una acción de bloqueo personalizada.
En fail2ban, especificas la acción a realizar en tu jail, por ejemplo: action = iptables-allports
Luego, solo tienes que editar esa acción: sudo nano /etc/fail2ban/action.d/iptables-allports.conf
Con esta configuración, tu contenedor/docker/VM aplicará el bloqueo localmente mediante fail2ban, pero también retransmitirá esta información a tu servidor central de fail2ban. El servidor central puede tomar todas las direcciones IP recopiladas y ponerlas a disposición como una lista de bloqueo en formato de texto, por ejemplo: tudominio.com
Luego, puedes configurar tu firewall pfSense para que se suscriba a esta lista de bloqueo e incluso compartirla con otros routers pfSense. De esta manera, si intentan acceder de forma no autorizada a una aplicación, quedan bloqueados en todas. Esto ha funcionado muy bien para mí durante años.
Y todo lo que necesito para implementar esto en Discourse es que este registre una entrada en un archivo de registro cuando haya un intento de inicio de sesión no válido
Los registros de NGINX
Ocasionalmente, los registros de NGINX pueden contener algunos consejos adicionales; se encuentran en:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
Allí estarán los archivos access.log y error.log, así como varios archivos comprimidos rotados. Ejecutar less access.log.2.gz descomprimirá y mostrará automáticamente el archivo de registro por ti.
Este directorio también está disponible en el host en /var/discourse/shared/standalone/log/var-log/nginx.
Desafortunadamente, los archivos error.log y access.log de nginx no registran ningún intento de inicio de sesión inválido.
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.
