it-swarm-es.com

Cómo protegerse contra la fuerza bruta

¿Cómo implementas adecuadamente las defensas contra el forzamiento bruto? ¿Es mejor almacenar cuántas veces alguien intentó iniciar sesión y bloquearlos después de X intentos? ¿Y cómo se identificaría a "alguien"? Con la sesion? Una IP?

24
Andreas Arnold

El bloqueo de cuenta es una opción, donde la cuenta se bloquea de forma permanente o por un período de tiempo después de x inicios de sesión fallidos. Los problemas aquí son los riesgos de denegación de servicio si un atacante intenta adivinar las contraseñas y también la sobrecarga administrativa de restablecer cuentas (suponiendo que un restablecimiento automático no esté disponible)

Otra opción es introducir CAPTCHA en el proceso de inicio de sesión. Esto tiene como objetivo limitar los ataques automáticos y detener la denegación de servicio de los bloqueos de cuentas. Los problemas con esto pueden ser los requisitos de accesibilidad y el craqueo automático de CAPTCHA. Por lo que he visto, algunos CAPTCHA son más fáciles de descifrar que otros.

Una tercera opción es introducir un retraso progresivo en el proceso de inicio de sesión, por lo que por cada inicio de sesión incorrecto, el proceso será cada vez más lento. Esto tiene un efecto limitado en usuarios reales, pero hace que la fuerza bruta automatizada sea mucho más difícil.

En términos de la segunda parte de su pregunta sobre la identificación del "alguien" que está haciendo el ataque, depende de lo que esté haciendo. Si solo están atacando a un solo usuario, entonces el nombre de usuario es el identificador y las acciones están vinculadas a esa cuenta. Si son de fuerza bruta en una amplia gama de usuarios, la IP de origen (tal vez combinada con el agente del navegador) es una opción. No es perfecto (p. Ej., Uso de botnets, suplantación de identidad de agentes), pero es probablemente la única información que debería tener.

9
Rory McCune

La respuesta para negar la fuerza bruta es negar una gran cantidad de intentos, donde grande está definido por su espacio clave y la aceptación del riesgo.

Cada situación tendrá diferentes soluciones.

Espacio de carne

  • Las puertas están reforzadas contra daños por fuerza bruta.
  • Chocar contra una puerta se mitiga con la posibilidad de alertar a la policía.
  • Las claves solo tienen alrededor de 5 variables, pero se necesitan recursos para tener una de cada clave (es más fácil atacar la cerradura de otras maneras que no son fuerza bruta)

Computadoras

  • Automatizar los ataques de fuerza bruta significa que debes limitar la velocidad de alguna manera. Con un límite de velocidad, puede conocer absolutamente su banda superior de intentos durante un cierto período de tiempo.
  • Monitoreo: si puede limitar los intentos de fuerza bruta a una cierta velocidad (500/día tal vez), entonces el monitoreo y las alertas pueden hacer que una persona sepa que puede ver más de cerca lo que está sucediendo. ¿Cuántos intentos se necesitarán para alcanzar un cierto nivel de riesgo inaceptable?
  • Gran espacio clave: tener requisitos de contraseña complejos puede aumentar en gran medida el número de intentos necesarios para una cierta probabilidad de encontrar la contraseña.
  • Autenticación de dos factores: la fuerza bruta de la contraseña no es suficiente en este caso

Todas las soluciones también tienen compensaciones como todo lo demás en la vida.

  • Limitación de velocidad: los usuarios legítimos de DoS pueden no ser efectivos si el ataque es primero: un intento por cada cuenta antes de intentar una segunda vez
  • Limitación de velocidad por IP: no es efectivo si se trata de un ataque distribuido
  • Complejidad de la contraseña: generalmente es una compensación en la usabilidad, lo que significa que los usuarios escribirán sus contraseñas, disminuyendo la seguridad en una cantidad mayor que la amenaza de fuerza bruta
  • Dos factores: puede verse como costoso, puede perder fichas
13
Bradley Kreider

Lo importante es ¿cómo identificas al 'alguien'?

No puede hacerlo por dirección IP: puede parecer que muchos usuarios tienen la misma dirección de cliente (esto se volverá aún más frecuente con el problema continuo de la falta de direcciones IPV4).

Puede parecer que un usuario se conecta desde múltiples direcciones de clientes, p. Ej. usando proxies con equilibrio de carga de AOL, o menos legítimamente, a través de tor.

Cualquier otra cosa son datos proporcionados por el cliente, por lo que potencialmente pueden modificar cualquier cookie que establezca, la cadena de agente de usuario, etc.

El único enfoque práctico es aplicar una puntuación heurística a la solicitud para intentar compararla con intentos anteriores, pero aún será imposible diferenciar entre ataques sofisticados y usuarios legítimos.

Establezca un umbral de puntuación en el que considere que el cliente está intentando forzar su sitio por fuerza bruta, digamos -20.

Requerir una sesión válida actual a la que hace referencia una cookie de sesión (que es no establecida en la página que solicita un nombre de usuario/contraseña) es un comienzo: si la cookie no se presenta con los detalles de autenticación, redirija a un separado página que elimina la cookie e inicializa la sesión con una puntuación de -10 y una puntuación de (digamos) -2 en la dirección IP del cliente. Podría usar un mecanismo de puntuación dinámica cuando comience a ver múltiples usuarios válidos desde la misma dirección. Del mismo modo, podría mantener una puntuación dinámica por usuario-agente y por el nombre de usuario.

Cuando se presentan cookies + autenticación para un usuario inexistente, agregue una puntuación de -5 a la sesión, -1 a la dirección del cliente, -5 al nombre de usuario.

Cuando se presentan cookies + autenticación con una contraseña no válida, agregue una puntuación de -3 a la sesión, -1 a la dirección del cliente, -4 al nombre de usuario.

Cuando cookie + auth + contraseña válida agregue +4 de la puntuación para la dirección del cliente, +3 al nombre de usuario, +2 al agente de usuario.

Nota: también debe establecer una disminución para permitir que se recupere cualquier puntaje retenido en la dirección del cliente/agente de usuario/nombre de usuario, digamos + 2/hora

Debe pensar en lo que sucede cuando la puntuación supera el umbral. ¿Ha proporcionado un mecanismo para que alguien bloquee el acceso a su sitio?

Si ha bloqueado el acceso con un puntaje alto para un nombre de usuario en particular, envíe un correo electrónico con una URL de restablecimiento al usuario registrado para esa cuenta para que pueda restablecer el puntaje de su nombre de usuario y reducir el puntaje de su agente de usuario /habla a.

4
symcbean

Como sugiero, te refieres al inicio de sesión/contraseña de fuerza bruta en la aplicación web.

Nadie fuerza bruta manualmente. Entonces, si hay dudas de que este sea un humano que intenta autenticarse, muestre Captcha, por ejemplo, del intento de inicio de sesión fallido en 3-d. Además, puede agotar el tiempo de espera entre intentos de inicio de sesión, pero esto no funcionará para ataques distribuidos desde diferentes IP. A continuación, hay dos tipos de fuerza bruta: ciego, solo tratando de iniciar sesión/contraseña al azar, y atacar a algún usuario. Para el último ataque, es efectivo implementar funciones como bloquear la cuenta durante algún tiempo y notificar al usuario por correo electrónico. Para los ciegos, la mitigación de la fuerza bruta puede ser más difícil de implementar, especialmente si el sitio es popular. En este caso, puede realizar un seguimiento de dicha información del usuario, como IP/País/Navegador/etc. Como complemento de esto, puede jugar con cookies de larga duración: una vez que el usuario haya iniciado sesión con éxito, guarde la cookie y luego verifíquela.

Sin una solución de tipo de aplicación web, es posible implementar soluciones a nivel de servidor como el mod_evasive de Apache. O incluso escribir un módulo de servidor web propio, específicamente para tales fines.

Claro, hay muchas otras formas de fortalecer la mitigación del ataque de fuerza bruta, pero a menudo resultan ser ruidosas, bastante inútiles y desagradables. Intenta seguir con KISS.

3
anonymous

Almacene los ips largos de inicios de sesión e intentos de inicio de sesión anteriores.

Después de que N intentos fallidos los pusieron contra el captcha.

Bloquee rápidamente las direcciones que no tienen inicios de sesión exitosos en su historial, sino varios intentos.

Bloquee rápidamente las direcciones que tienen una dirección de origen simultánea o intentos inhumanos de velocidad/resistencia.

3
hpavc

Además, ninguna de estas respuestas tiene en cuenta el método de fuerza bruta en el que un atacante usa una contraseña y la prueba contra todas las cuentas, una reversión del proceso habitual y una que generalmente no está protegida.

El control sería, por supuesto, tener un proceso de monitoreo para múltiples intentos contra diferentes cuentas con la misma contraseña, pero nuevamente es muy difícil de bloquear incluso si provienen de una sola dirección, ¿cómo bloquea esa IP? También podría ser utilizado por usuarios válidos, ¿o simplemente elimina los inicios de sesión con esa contraseña, con el riesgo de bloquear a un usuario válido con esa contraseña?

Y, por supuesto, si un atacante ejecuta este tipo de cosas desde una red distribuida, o durante un largo período de tiempo, ¿cómo correlaciona los incidentes en un perfil de ataque?

Los mecanismos generales de la industria incluyen el bloqueo

  • en intentos directos (más de 3, generalmente menos de 20)
  • retraso progresivo
  • herramientas estadísticas para bloquear incidentes que se parecen al forzamiento bruto distribuido
2
Rory Alsop

Primero, tiene sentido entender qué escenarios/ataques tiene la intención de manejar:

  • El usuario válido escribe incorrectamente la contraseña incorrecta
  • El usuario válido realmente olvidó su contraseña, y está dispuesto a probar manualmente cualquier cosa que se le ocurra.
  • El atacante está intentando adivinar manualmente la contraseña de otra persona
  • El atacante está utilizando una herramienta automatizada para forzar la contraseña de un usuario específico
  • El atacante está utilizando una herramienta automatizada para forzar la contraseña de cualquier usuario posible (es decir, búsqueda de amplitud)
  • El atacante quiere bloquear el acceso de un usuario específico al sitio
  • El atacante quiere bloquear el acceso de la mayoría de los usuarios al sitio
  • El atacante quiere bloquear el acceso de los administradores al sitio
  • El atacante quiere crear mucho trabajo manual o costarle mucho a su organización de alguna otra manera.

(¿Ves? No es tan simple ...) Y hay diferentes soluciones para cada parte de estos ...

  • No revele una lista de nombres de usuario. No lo haga más fácil ... Esto incluye no revelar si el nombre de usuario es válido o no, al rechazar el inicio de sesión.
  • Requerir una política de contraseña segura: larga y compleja.
  • Haga que el mecanismo de "contraseña olvidada" sea fácil y notable. (Por supuesto, asegúrese de que eso también sea seguro).
  • Cada vez que falla una solicitud de inicio de sesión, registre esto en la base de datos. Asegúrese de escribir el nombre de usuario, la dirección IP, la hora, etc.
  • Si se reciben numerosas solicitudes fallidas para un nombre de usuario específico, marque a ese usuario en la base de datos como bloqueado por un corto tiempo. También aliente al usuario a usar la función "Olvidé mi contraseña", si está en la misma sesión.
  • ¿Cuántas solicitudes fallidas? Depende . En resumen, lo que tenga sentido para su sitio, el número exacto no es crítico.
  • ¿Durante cuánto tiempo debe estar bloqueado el usuario? Intervalos cortos Matemáticamente, en realidad no importa, siempre que tenga una política de contraseña segura. Siendo realistas, comience con un intervalo muy corto de unos pocos minutos, luego, si continúa, hágalo incrementalmente más largo. P.ej. después de 5 intentos fallidos, bloquee por 5 minutos; después de otros 3 malos intentos, bloquear por 15; después de otros 2, bloquear por 30; etc.
  • No bloquee las cuentas de usuario de forma permanente. Esto lleva a la cuenta DoS. Y también puede costarle a su personal de soporte mucho tiempo y dinero.
  • A pesar de los puntos anteriores, si su sitio es muy sensible, p. una aplicación bancaria, es posible que desee considerar bloquear permanentemente hasta nuevo aviso, p. que el cliente entre en su sucursal.
  • Los bloqueos deben ser por nombre de usuario, en la base de datos. No por sessionId, y no en la sesión del servidor web.
  • Si recibe muchas solicitudes fallidas con diferentes nombres de usuario, pero desde la misma dirección IP, implemente un bloqueo incremental como el anterior, pero con mayor gracia e intervalos más cortos.
  • Proporcione una función de "nombre de usuario olvidado", además de la contraseña olvidada.
  • Las cuentas de administrador deben tener una gracia más corta, intervalos más largos y nunca bloquearlas permanentemente.
  • En cualquier caso, al bloquear un usuario o IP, envíe una alerta a los administradores. Sin embargo, no es para el bloqueo repetido: no desea inundar la bandeja de entrada del administrador. Pero si continúa, entonces eleve el nivel de alerta después de algunas veces.
  • No use CAPTCHA: la dificultad mínima añadida es trivial, en relación con el valor de acceder a la contraseña del usuario. (Hay muchas formas de evitarlo, CAPTCHA es fundamentalmente roto, independientemente de la implementación ).
  • Por supuesto, como dijo @ rox0r, la autenticación multifactor puede ser adecuada para usted.
  • Otra alternativa es lo que se conoce como " ¡autenticación adaptativa" - si el usuario no pudo iniciar sesión, solicite información adicional (que se había registrado previamente). Dependiendo de factores de riesgo adicionales (por ejemplo, ubicación, patrones de tiempo diferentes a los habituales, etc.), escale la información requerida para autenticarse con éxito. Por ejemplo, el producto de Autenticación Adaptativa de RSA hace esto.
1
AviD

Si se trata de un sitio web comercial, utilice el certificado más la autenticación de contraseña Sin un certificado válido, nunca llegan a intentar adivinar la contraseña. También puede usar algo como RSA SecurID en lugar del certificado.

0
sdanelson