Deben registrarse los intentos de inicio de sesión fallidos

Sí, los intentos de inicio de sesión fallidos deben registrarse:

• Desea saber cuándo las personas intentan ingresar
• Quiere comprender por qué sus cuentas se están bloqueando

También es muy importante, ya que el proceso de registro de Windows anterior nunca enfatizó lo suficiente, también para registrar intentos de inicio de sesión exitosos . Porque si tienes una serie de intentos fallidos de inicio de sesión, realmente deberías saber si al último le siguió un inicio de sesión exitoso.

Los registros son relativamente pequeños. Si hubo suficientes intentos de inicio de sesión que el registro causaría un problema, entonces "no saber sobre los intentos" es probablemente un problema peor que "descubrió sobre ellos cuando nos quedamos sin disco".

Una advertencia rápida: como @Polynomial señala, la contraseña no debe registrarse (parece recordar que hace 25 años algunos sistemas todavía lo hacían). Sin embargo, también debe tener en cuenta que algunos intentos de inicio de sesión legítimos fallarán cuando las personas ingresen su contraseña en el campo de nombre de usuario, por lo que las contraseñas se registran. ¿Duda de mí? Busque sus registros para el evento de Windows ID 4768:

LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       gowenfawr-has-a-cool-password
    Supplied Realm Name:    TEST.INT
    User ID:            NULL SID

En consecuencia, debe limitar el acceso a estos registros a las personas necesarias, no solo volcarlos en un SIEM al que toda la empresa tenga acceso de lectura.

Actualizar para abordar la edición de la pregunta:

  

Según las respuestas hasta ahora, otra pregunta que se me ocurrió es   si los registros del servidor web serían suficientes para registrar tales intentos.   ¿Sería redundante registrarlos en la base de datos?

Las mejores prácticas son que los registros deben enviarse a un agregador de registros por separado en cualquier caso; por ejemplo, considere PCI DSS 10.5.4. En la práctica, este agregador suele ser un SIEM y funciona como una base de datos en lugar de archivos de registro planos.

Entonces, sí, es "redundante" por definición, pero es el tipo de redundancia que es una característica de seguridad, no un error de arquitectura.

Las ventajas de iniciar sesión en una base de datos incluyen la búsqueda, la correlación y la suma. Por ejemplo, la siguiente búsqueda Splunk:

source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,host

Nos permitirá resumir las fallas de autenticación por usuario y host:

Tenga en cuenta que la capacidad de consultar campos discretos como 'usuario' y 'host' depende de que SIEM seleccione los registros y entienda qué significa eso. La accesibilidad de esos campos aquí es un efecto secundario de que Splunk analice automáticamente los registros para mí.

Dado que su pregunta original se ocupó de las limitaciones de espacio, debe señalarse que cualquier base de datos o solución SIEM va a necesitar más espacio en el disco que los registros de archivos de texto plano. Sin embargo, si utiliza una solución de este tipo, casi siempre la colocará en un servidor separado por razones de seguridad y gestión de espacio. (¡Ahora hay incluso soluciones SIEM en la nube para hacerte la vida más fácil!)

Como complemento de la respuesta de @ gowenfawr que explica por qué debe registrar esos intentos, me gustaría decir que hay formas de garantizar que los registros nunca agotarán sus discos.

Al menos en el mundo Unix-Linux, herramientas como logrotate o rotatelogs permiten cambiar el archivo de registro cuando su tamaño supera un cierto umbral. Normalmente se utilizan con el servidor apache (los rotatelogs provienen de la base de Apache) o con el sistema syslog.

Por ejemplo, logrotate se usa para cambiar el nombre de un archivo de registro (en una serie de copias, generalmente alrededor de 10 de ellas) finalmente lo comprime, y advierte al programa que genera el registro para volver a abrir su archivo de registro al enviarlo una señal dedicada o mediante un comando arbitrario.

De esa manera, si su servidor está bajo un ataque DoS, el tamaño de sus archivos de registro permanecerá bajo control. Por supuesto, perderá eventos más antiguos, pero eso es definitivamente mejor que bloquear el servidor debido a una partición de disco agotada.

Realmente depende de qué valor crees que podrías derivar de la información. Hay un valor limitado en tener páginas de registros que le indican que su servidor está bajo ataque; se enfrenta a internet y es probable que esté bajo varios grados de bombardeo constante durante su vida útil.

Dependiendo de la configuración de su servidor, es muy posible que termine creando un problema de disponibilidad porque ha agotado el espacio disponible en el disco con los registros. Sucede Gowenfawr estaba en lo cierto al afirmar que los registros no ocupan mucho espacio, pero esta es la razón por la que los problemas con el agotamiento del espacio en disco pueden tardar años en aparecer, pero son un gran problema cuando lo hacen.

Si decide iniciar sesión, debe diseñar una estrategia de administración de registros y considerar algunos de los siguientes:

• ¿Qué voy a hacer con mis registros? ¿Qué sucede después de establecer que alguien está tratando de obtener acceso a su sistema?
• ¿Mis registros contendrán datos potencialmente confidenciales? (Recuerde, los usuarios reales a veces pueden usar sus credenciales). Si la respuesta es afirmativa, considere la posibilidad de desinfectar los registros antes del almacenamiento o de cifrarlos una vez que esté en reposo
• Eventos de registro y verbosidad
• ¿Con qué frecuencia debo rotar los registros? Rotación de registros es una forma bastante estándar de tratar con los tamaños de registros. Puede permitirle comprimir registros antiguos y, posiblemente, eliminar archivos de registro particularmente antiguos
• Información de seguridad y gestión de eventos. _Usted mencionó que su servidor contendrá información confidencial, dependiendo de lo que sea que desee considerar en SIEM productos que pueden proporcionarle información útil basada en el registro y otros datos, como alertas, paneles de control, análisis forense, etc.

Hablando personalmente, tiendo a encontrar registros que solo son útiles para el análisis forense; ayudan a resolver lo que sucedió después de una violación exitosa. Como mencionó Gowenfawr; los intentos exitosos de iniciar sesión en un sistema son igual de (probablemente más) importantes que los fallidos.

Un último punto, su mecanismo de inicio de sesión debe construirse de manera tal que la probabilidad de que una fuerza bruta distribuida funcione siempre es muy pequeña. No ha dado muchos detalles sobre lo que ha creado, pero el uso de algoritmos fuertes de back-end, especialmente los hash computacionalmente costosos y la introducción de la temporización de retroceso en los intentos de inicio de sesión puede reducir en gran medida las posibilidades de que un atacante logre acceso de esta manera. p>