¿Es seguro Drupal contra ataques de inicio de sesión de fuerza bruta?

9

Un ataque de fuerza bruta es un intento de obtener acceso no autorizado a un sitio web generando e ingresando continuamente varias combinaciones de una contraseña. Esta tarea generalmente la realiza un software de automatización (un "bot") que busca mensajes de éxito o error y sigue probando nuevas contraseñas hasta que recibe un mensaje de éxito.

¿Drupal 7 es seguro contra él de forma predeterminada? ¿Cuál es la configuración más segura? ¿Qué módulo me puede ayudar para un inicio de sesión más seguro?

security Yusef
fuente
1
La respuesta depende de qué tipo de ataque estás hablando. ¿Te refieres a un ataque de fuerza bruta donde el atacante adivina que el usuario "admin" tiene una contraseña de "Contraseña1" y luego adivina quizás que la contraseña es "javagod"?
greggles
sí, como título de la pregunta ataque de inicio de sesión de fuerza bruta :(
Yusef

Respuestas:

12

Como puede ver en el código, la función user_login_final_validate registra un evento de inundación. Eso significa que si una misma IP intenta conectar una contraseña de usuario / inicio de sesión muchas veces seremos "prohibidos" por un tiempo.

Esta es una de las protecciones que ofrece Drupal. Otro, y creo que si le sucede a su sitio web, lo notará muy rápido, es el token CSRF que Drupal genera para cada formulario.

Esto significa que el bot atacante debe generar el formulario, luego obtener el token y asociarlo con el formulario de envío. Eso lleva mucho tiempo y probablemente desanime al atacante. Pero primero, verá que su servidor comienza a calentarse.

yvan
fuente
para el formulario de inicio de sesión de simulación solo necesita copiar / pegar el formulario de inicio de sesión de drupal. Puede probarlo, si copia / pega html de otro sitio de drupal en su archivo de prueba local (solo asegúrese de que la acción del formulario se redirija absolutamente a dominio.com/usuario/ inicio de sesión ), ejecútelo localmente, llénelo con un usuario válido y pase ¡verá que inició sesión!
Yusef
Este formulario funcionará tanto como Drupal como el token (y el formulario) en caché en su base de datos. Una vez que el caché expiró, su formulario no funcionará.
yvan
Limpié el caché pero aún trabajo
Yusef
1
La protección CSRF se puede desactivar y se desactiva en el formulario de inicio de sesión. También está deshabilitado en el formulario de búsqueda. Pero, como dijo Yvan, la protección contra inundaciones evita los ataques de fuerza bruta en el propio formulario. Esto no evitaría un ataque distribuido de alguien que tuviera acceso a una botnet, pero el análisis de registro (algo así como Droptor) que busca inicios de sesión fallidos repetidos para el mismo usuario lo solucionaría.
greggles
3

Además de las buenas medidas que implementa Drupal 7 para detener los intentos de inicio de sesión, sugeriría instalar el módulo Spambot , que se ocupa específicamente de los nuevos intentos de registro de usuarios.

En cada nuevo registro de usuario, ese módulo consultará el servidor Stop Forum Spam para ver si el usuario que intenta registrarse es un bot conocido.

Opcionalmente, puede contribuir a Stop Forum Spam con los intentos de registro de su sitio web.

ermannob
fuente
3

Hay control de inundaciones

El objetivo de este proyecto es agregar una interfaz de administración para las variables ocultas de control de inundaciones en Drupal 7, como los limitadores de intentos de inicio de sesión y cualquier variable oculta futura.

Las funciones para definir e interactuar con el sistema central de control de inundaciones

El sistema de inundación nos proporciona tres funciones:

flood_register_event($name, $window = 3600, $identifier = NULL)

Registre un evento para el visitante actual en el mecanismo de control de inundaciones.

flood_clear_event($name, $identifier = NULL)

Haga que el mecanismo de control de inundaciones se olvide de un evento para el visitante actual.

flood_is_allowed($name, $threshold, $window = 3600, $identifier = NULL)

Comprueba si el usuario puede continuar con el evento especificado. Básicamente, verificamos si un usuario tiene acceso llamando a flood_is_allowed. Si devuelve FALSO, arroje un "Acceso denegado". Cada vez que un usuario realiza la acción, llamamos flood_register_event.

Por defecto, comprueba la dirección IP del usuario. Pero podríamos pasar algún otro identificador único como la identificación del usuario.

Arriba copiado de Jugar con el sistema de inundación de Drupal

niksmac
fuente
1
No copie y pegue de la web sin la atribución adecuada
Clive
1
@Clive me ocuparé de eso a partir de ahora. Y eso es lo que quiero transmitir.
niksmac
0

Pensando (y teniendo) este problema, escribí un módulo que le permite prevenir este tipo de ataques: https://drupal.org/project/AntispammerBot

Puede seleccionar qué roles son seguros, cuántos nodos puede publicar el usuario antes de considerarlo un ataque de spam, etc.

Alejandro Moreno
fuente