¿Qué criterios deben usarse para revisar / priorizar manualmente los inicios de sesión fallidos?

A simple vista, esto es fácil, pero como cualquiera puede saber al leer su pregunta (o para aquellos de nosotros que hemos implementado algo en este sentido), esto se convierte rápidamente en una lata de gusanos.

Veamos algunas métricas potenciales ...

Intentos fallidos por nombre de usuario : la métrica estándar por la cual una cuenta se bloquea, la mantiene baja y la mayoría de los ataques se bloquearán.

nombres de usuario no válidos por IP por x horas : ver 100 intentos de inicio de sesión para nombres de usuario no válidos únicos en una hora desde la misma IP es un buen indicador de actividad maliciosa.

usuarios bloqueados por ip ofensiva durante las últimas x horas : si una IP ha provocado que n usuarios se bloqueen en las últimas x horas, es sospechoso. Desearía comparar esto con la cantidad de usuarios únicos exitosos que iniciaron sesión desde esa IP. Si ha habido un inicio de sesión bueno y 40 usuarios bloqueados, está ocurriendo algo sospechoso y vale la pena prohibir la IP hasta que la investigación pueda confirmar.

avg & el número máximo de inicios de sesión de usuario válidos por IP durante x horas / días : le proporciona una buena base de referencia para el uso estándar de las redes NAT.

La clave es crear líneas de base y marcar cualquier anomalía, ya sea para revisión manual o acción automática. Esa acción automática podría ser bloquear a un usuario, prohibir o limitar la velocidad de una IP, marcar una IP o un usuario como sospechoso y requerir que todos los inicios de sesión de esa fuente pasen por pasos adicionales de prevención de bots, es decir, CAPTCHAs y / o verificación por correo electrónico.

Algunos sitios requieren estos pasos de verificación adicionales de cualquier usuario que inicie sesión desde un nuevo dispositivo, esto también reducirá en gran medida la posibilidad de un ataque basado en un usuario exitoso.

En cuanto a su escenario opcional, digamos que están usando cuentas títere de calcetines para cumplir con las líneas de base para aparecer como un entorno NAT. Digamos que tienen 100 cuentas iniciando sesión con éxito. Si intentan ingresar a una cuenta específica, esa cuenta se bloqueará después de 3-4 intentos. Asumiendo que tienes una política de contraseña decente, ataque prevenido. Digamos que están intentando ingresar a una de las 10 cuentas. ¿Serían normales 10 cuentas bloqueadas en una hora desde un entorno NAT? Duda ... Marque la IP para actividades sospechosas que requieren que los usuarios verifiquen su humanidad después de un intento fallido de contraseña.

Asegurar que los usuarios se bloqueen en un tiempo razonablemente rápido evitará la mayoría de los ataques de fuerza bruta. Agregar métricas basadas en IP para usuarios bloqueados, usuarios no válidos y otras métricas relacionadas en comparación con las líneas de base y vinculado con la prevención de bots estándar y los métodos de verificación de usuarios reducirá aún más su riesgo y garantizará auditores, administradores de sistemas y usuarios felices.

Difícil para una respuesta directa ya que no tengo ninguna indicación de cuántos usuarios tiene, o pretende tener, iniciar sesión en su servidor. Si esto llega a los miles, te dispararás en el pie con tantos falsos positivos, que eventualmente ignorarás todas las alertas.

Así que agregaré mis dos centavos a este estilo de defensor del diablo:

• Brute forzando nombres de usuario o contraseñas. (el período de bloqueo es de 24 horas)

En el caso de que alguien impida forzadamente un nombre de usuario legítimo, activará una alerta que bloquea a un usuario legítimo. Multiplica esto por N y ahora tienes N cantidad de usuarios irritados.

• DoSing la aplicación al bloquear intencionalmente a los usuarios

Esto también es "no intencional", ver más arriba "

• Cualquier ataque por encima de una BotNet o TOR

Esto también es "no intencional", ver más arriba "

• Ataques internos / actividad sospechosa de usuarios internos.

Si tiene que preocuparse por los usuarios internos, tiene problemas más grandes

Esto es lo que haría y he hecho: porque la mayoría de mi base de usuarios que necesita " iniciar sesión " en cualquier cosa, generalmente proviene de lugares definidos (un ISP, un negocio, etc.) ) Tiendo a permitir que entren (a través de firewall) y a bloquear el resto. Esta es una práctica general, sin embargo, no es para todos. Mi método sería el siguiente:

1) Captcha o Cloudflare : el razonamiento para esto es simple; La mayoría de los "ataques" en la actualidad son principalmente automatizados. Captcha y Cloudflare minimizarán esos tipos de ataques.

2) Firewall / ACL fuerte : si dice que está en América del Norte, ¿REALMENTE necesita que su servidor sea visible para las redes APNIC, RIPE, LACNIC, AFRINIC? (Google esos si no entiendes lo que son)

3) Registro y supervisión de SIEM : una vez más, es algo difícil de mencionar, ya que no sé el tamaño de su red, registros, etc. Sin embargo, me baso en el tráfico normal durante un trimestre. , luego ignore TODOS LOS CONOCIMIENTOS, y luego avise si hay incógnitas antes de bloquear.

Las redes difieren, por lo que probablemente darías una mejor respuesta con una mejor descripción. Por ejemplo, tengo una aplicación web a la que acceden N cantidades de usuarios. Tengo / no tengo presupuesto, etc.