Bruteforce vs Denial of Service

Para las cuentas de administrador, tenías razón, requerir una VPN es la dirección correcta.
Mejor aún, requiere autenticación de múltiples factores para los usuarios de administración.

Estas son siempre buenas ideas.

Dicho esto, si por alguna razón no es factible, y está atascado con los inicios de sesión de contraseña públicos regulares, no todo está perdido.

Suponiendo que sus cuentas de administrador estén sujetas a una política de contraseña segura, la fuerza bruta directa requerirá muchos, muchos, muchos, muchos, muchos intentos. El intento de fuerza bruta de la contraseña a través de su formulario de inicio de sesión, a través de Internet, llevará mucho, muy, muy, mucho tiempo, y esto solo será factible si es posible ejecutar muchos intentos de inicio de sesión en paralelo, usando muchos computadoras.
El elemento clave aquí es velocidad .

Por lo tanto, la solución es ralentizar los intentos de inicio de sesión repetidos, sin detener realmente al usuario real (que intenta iniciar sesión con la misma cuenta al mismo tiempo que el bruteforce).
No, ni siquiera piense en probar CAPTCHA: si bien esto tiene un pequeño efecto, no está lo suficientemente cerca como para reducir la velocidad de los ataques, en un orden de magnitud (la mejor opción es probablemente alrededor del 20%, no lo suficientemente lenta) .

Una solución mucho más efectiva (y más simple) es limitación de velocidad .
Es decir. No más de 5 intentos de inicio de sesión en un minuto. O 50. O incluso 500.
Esto también se puede ver como un mecanismo de bloqueo de liberación automática, con un retraso de tiempo muy corto.
Los cálculos aún están a su favor (puede limitarlos a la velocidad que desee en función de sus amenazas esperadas), y aún puede dejar margen para que el usuario genuino inicie sesión.

Después de varios bloqueos, es posible que desee implementar bloqueos más largos por IP, pero tenga cuidado con ese enfoque, ya que las direcciones IP generalmente no se alinean con un usuario específico (ya sea por IP compartida, IP de roaming, etc.). Así que usa eso, si debes, pero gentilmente.

Además, asegúrese de alertar a un administrador, después de varios bloqueos, permitiendo una respuesta manual adicional.

Para una solución simple, diría que implementar un retraso exponencialmente creciente por usuario por dirección IP.

Demora requerida entre los intentos 1 y 2 de IP a.b.c.d para el usuario x : 1 segundo

... intenta 2 y 3: 2 segundos

... intenta 3 y 4: 4 segundos

...

... intenta 7 y 8: 1 minuto 4 segundos

De esa manera, un adversario no puede acceder a DoS desde una dirección IP o un usuario individual y ha mitigado la fuerza bruta de manera bastante efectiva porque el retraso rápidamente se vuelve irrazonable. Incluso si tienen acceso a una gran cantidad de direcciones IP, es probable que no haya suficiente para forzar el espacio de claves de la contraseña, solo algunas palabras del diccionario.

Este permitiría permitir a los usuarios de fuerza bruta con la misma contraseña, pero si ve esa cantidad de solicitudes fallidas, probablemente debería marcarla de todos modos (en ese sentido, un usuario con varios intentos fallidos es probablemente no sea raro, pero varios usuarios con malos intentos de la misma dirección IP en rápida sucesión serían sospechosos).

La forma correcta de hacer esto es usar un límite de velocidad por IP e introducir un CAPTCHA al iniciar sesión para las cuentas de usuario que han tenido un gran número de intentos de inicio de sesión no válidos. El CAPTCHA no necesita ser particularmente fuerte, ya que está principalmente allí para prevenir ataques de drive-by no dirigidos. Uno de los beneficios de este método es que previene los ataques de múltiples contraseñas de un solo usuario y los ataques de contraseñas de múltiples usuarios sin causar la condición de DoS.

Sin embargo, recomendaría no incrementar indefinidamente los tiempos de espera. Si un atacante está en la misma red que el usuario, es posible que tengan la misma dirección IP de acceso público, lo que les permite esencialmente suspender al usuario al enviar constantemente solicitudes de inicio de sesión incorrectas. Este puede ser un caso bastante oscuro para la gran parte, pero considere las redes universitarias y escolares. En cambio, la limitación de la velocidad no impondría ningún retraso en los primeros 2 intentos fallidos, 5 segundos en el tercer intento, 15 segundos en el tercero y 30 segundos para todos los intentos posteriores.

Un caso interesante es un ataque de una sola contraseña para muchos usuarios desde una gran cantidad de IP de origen, por ejemplo. sobre tor. Esto probablemente derrotaría a la mayoría de estos mecanismos. Una de las mejores maneras que he visto para prevenir este tipo de ataque es monitorear la tasa de inicio de sesión fallida de global e introducir la limitación de la tasa en todo el sitio y los CAPTCHA cuando se detecta un ataque a gran escala.

Para cuentas de administración fijas, puede valer la pena tener una pantalla de inicio de sesión separada. Esto se puede monitorear y controlar mucho más estrechamente, y le permite evitar problemas con la mayoría de los intentos de conducir.

Otro mecanismo útil para aumentar el costo de los intentos de adivinación de contraseñas es una función de prueba de trabajo del lado del cliente. Los he visto en uso en algunos sitios, y creo que están bastante ordenados. Esencialmente, el servidor envía un valor de desafío c , y el cliente debe calcular un valor de sal s tal que los primeros n bits de sha1(c || s) sean cero. El valor de n se puede modificar de la misma manera que se puede ajustar una cuenta de iteración en un algoritmo de derivación de clave. El cliente debe calcular un valor de s (mediante fuerza bruta) que cumpla con los criterios, y enviarlo de vuelta al servidor. El servidor puede entonces verificar de forma trivial y económica que s es correcto. La implementación de esto en el lado del cliente normalmente se haría en JavaScript. Para los usuarios legítimos, esto no debe suponer más de un segundo de retraso en el inicio de sesión, pero para los atacantes que usan sus propios sistemas para intentar miles de contraseñas, aumenta el costo en términos de tiempo y consumo de energía. Además, en los casos en que se utiliza una botnet u otro malware como plataforma para estos intentos de contraseña, es más probable que el uso elevado de la CPU avise al usuario de que algo está mal en su máquina.

¿Puedo sugerir una solución de baja tecnología? No tengo cuentas por defecto. Quitar root y administrador en linux / windows es lo primero que hago. No puedo hablar de un panel de administración desconocido, pero esta podría ser una opción.

El bloqueo continuo de las direcciones IP que realizan ataques de fuerza bruta es una forma perfecta de hacerlo. Si su aplicación registra los intentos fallidos en alguna ubicación estándar, como syslog, puede escribir fácilmente una cárcel para que fail2ban bloquee automáticamente las IP ofensivas después de una serie de fallas de autenticación.

Esas preguntas de la imagen. Usted sabe, qué palabra hay en esta imagen ... Después del intento fallido 3, tiene que responder qué palabra está en la imagen para impulsar su intento de inicio de sesión. De esta manera, en realidad no bloquea la cuenta, pero evita que un sistema automatizado continúe funcionando al cambiar la solicitud de entrada.

Si está preocupado, puede ser que OCR haga una pregunta que tenga múltiples respuestas con un relleno de burbuja (botón de opción), es decir, haga una pregunta que un humano sabría, pero ninguna máquina lo sabría.

¿Cuál de las siguientes rimas con naranja?

A) Washington B) Nada C) Sasquatch, etc ...

Incluso combínalos.

Por último, utilice la autenticación de múltiples factores. Me conecto a mi cuenta de StarCraft (el valor geek acaba de subir) usando una aplicación de iOS para darme un token.

Algunas cosas vienen a la mente.

1) No utilice nombres de usuario administrativos predeterminados ... nunca. No hay razón para ello. Si bien la seguridad por oscuridad no es realmente segura, dejar sus nombres de usuario administrativos obvios sigue haciendo la vida más fácil para un atacante. Si no conocen el nombre de usuario del administrador, no pueden intentar mantenerlo bloqueado.

2) Autentique automáticamente la sesión desde el correo electrónico para restablecer la contraseña / permitir el acceso. Esto permite un enfoque alternativo para ingresar sin tener que preocuparse por el bloqueo. Es más tedioso, ya que requiere recibir un correo electrónico que le permita ingresar, pero funciona. Una vez dentro, cambiar el nombre de usuario nuevamente detendrá el ataque de manera efectiva.

3) Lista blanca de IP: esta siempre debería ser una opción, puede incluirla en la lista blanca por un tiempo limitado si así lo desea y podría hacerlo de manera similar a como funciona el número 2, donde se agregaría la lista blanca cuando se envíe el correo electrónico. Se hace clic en el enlace.

4) VPN, como usted mencionó, funcionará, es similar en principio a la inclusión de una IP en la lista blanca, pero permitiría IP dinámicas para un cliente legítimo. Dependiendo del contexto, podría ser un poco excesivo, ya que cambiar un nombre de usuario sigue siendo la forma más fácil de evitar este tipo de ataque DoS.

No bloquea a un usuario solo por su nombre de usuario, lo bloquea por nombre de usuario + IP. De esta manera el usuario legítimo no será bloqueado. Por otro lado, dos bot tendrá que cambiar la IP y, finalmente, se bloqueará el rango de IP de la granja de servidores.