Resumen
Deberíamos añadir un sistema de registro de autenticación estandarizado a Discourse que almacene eventos de autenticación de todos los métodos de autenticación habilitados para análisis y solución de problemas.
Detalles
Proporcionaríamos un proveedor de registro de autenticación al que cada sistema de autenticación se conectaría y enviaría eventos.
Como ejemplo, el proveedor de inicio de sesión local podría tener la siguiente lista (no completa) de eventos:
- alguien de [IP] falló el inicio de sesión como el usuario
fhqwhgadsque no existe - alguien de [IP] falló el inicio de sesión como el usuario
supermathie, fue limitado por velocidad - alguien de [IP] falló el inicio de sesión como el usuario
supermathie, pero proporcionó una contraseña inválida - alguien de [IP] inició sesión correctamente como el usuario
supermathie, proporcionó una contraseña válida - alguien de [IP] falló el inicio de sesión como el usuario
supermathie, proporcionó una contraseña válida, pero requiere MFA para continuar - alguien de [IP] falló el inicio de sesión como el usuario
supermathie, proporcionó una contraseña válida, proporcionó un código TOTP inválido - alguien de [IP] inició sesión correctamente como el usuario
supermathie, proporcionó una contraseña válida, proporcionó un código TOTP válido para el tokenvault-work
El problema de depender de los registros existentes (registros web) es que, con la excepción del limitado por velocidad, todos se ven exactamente iguales ([200] POST /session HTTP/1.1). No hay ningún significado que llegue al registro.
Preocupaciones
Existe la preocupación de que los eventos anónimos generen entradas de registro y el equilibrio entre eso y la detección de eventos que son interesantes desde el punto de vista del análisis SIEM, por ejemplo, ataques de pulverización de contraseñas.
Registrar TODO significa que cualquiera en Internet puede llenar sus registros… pero es debatible si esto es realmente un problema o no. Nota de retención a continuación: quizás los fallos se mantengan durante un período de tiempo más corto dentro del registro de la aplicación.
Surge una pregunta similar en torno a los registros basados en tokens de un solo uso, por ejemplo, inicio de sesión por correo electrónico. Los tokens incorrectos probablemente no sean “interesantes” para registrar, pero los tokens reproducidos absolutamente lo son, tanto desde el contexto de SIEM como de soporte al usuario.
Preguntas
Retención: ¿mantener todo para siempre? ¿30 días? ¿90 días? ¿eliminar eventos anónimos antes?
Autenticación de clave API: ¿Se deben registrar aquí las llamadas con claves API de usuario o administrador incorrectas? Probablemente, ayudará a depurar.
¿Cuánto debería ser configurable? por ejemplo, activar los registros de depuración para todo o solo para un proveedor?
Consideraciones de implementación
La implementación debe ser lo suficientemente flexible como para permitir que se agregue otro proveedor de almacenamiento de eventos al pipeline de registro. Un ejemplo de dicho proveedor podría ser un archivo de registro sin procesar, una cola de mensajes o un bucket S3. Los detalles exactos de dicho proveedor están fuera del alcance de este tema, pero la implementación debe ser lo suficientemente flexible como para que un plugin pueda registrarse para recibir registros a medida que se generan.
Antecedentes
Tuvimos un cliente que solicitó esto con la intención de alimentar los eventos a su SIEM y nos dimos cuenta de que era una brecha de funcionalidad en Discourse.
Durante la discusión interna, también descubrimos que esta información sería útil para los administradores del sitio y nuestros propios defensores de soporte, ya que los registros de autenticación podrían estar en varios lugares y uno tiene que saber dónde buscar para encontrarlos. Esto se basa en el conocimiento personal y un registro central aliviaría en gran medida esa carga.
Una forma conveniente de ver estos registros desde la consola de rails sería beneficiosa para nosotros y para los administradores del sitio.