Drupal est-il sûr contre les attaques par connexion par force brute?

9

Une attaque par force brute est une tentative d'obtenir un accès non autorisé à un site Web en générant et en saisissant continuellement diverses combinaisons d'un mot de passe. Cette tâche est généralement effectuée par un logiciel d'automatisation (un «bot») qui recherche les messages de réussite ou d'échec et continue d'essayer de nouveaux mots de passe jusqu'à ce qu'il reçoive un message de réussite.

Drupal 7 est-il protégé par défaut? quelle est la configuration la plus sécurisée pour cela? Quel module peut m'aider pour une connexion plus sécurisée?

security

— Yusef
source

1

La réponse dépend du type d'attaque dont vous parlez. Voulez-vous dire une attaque par force brute où l'attaquant suppose que l'utilisateur "admin" a un mot de passe "Password1" et devine ensuite que le mot de passe est "javagod"?

— gréggle le

oui, comme titre de la question attaque de connexion par force brute :(

— Yusef

12

Comme vous pouvez le voir dans le code, la fonction user_login_final_validate enregistre un événement flood. Cela signifie que si une même IP essaie de connecter plusieurs fois un mot de passe utilisateur / login, nous serons "bannis" pendant un certain temps.

C'est l'une des protections offertes par Drupal. Un autre, et je pense que si cela arrive à votre site Web, vous le remarquerez très rapidement, c'est le jeton CSRF que Drupal génère pour chaque formulaire.

Cela signifie que le bot attaquant devrait générer le formulaire, puis récupérer le jeton et l'associer au formulaire de soumission. Cela prend beaucoup de temps et découragera probablement l'attaquant. Mais d'abord, vous verrez votre serveur commencer à chauffer.

— yvan
source

pour le formulaire de connexion de simulation, il vous suffit de copier / coller le formulaire de connexion drupal . connexion ), exécutez-le localement, remplissez-le avec un utilisateur valide et passez-vous voir connecté !!!!!

— Yusef

Ce formulaire fonctionnera aussi longtemps que Drupal que le jeton (et le formulaire) mis en cache sur sa base de données. Une fois le cache expiré, votre formulaire ne fonctionnera pas.

— yvan

J'ai effacé le cache mais je travaille toujours

— Yusef

1

La protection CSRF peut être désactivée et est désactivée sur le formulaire de connexion. Il est également désactivé sur le formulaire de recherche. Mais, comme l'a déclaré yvan, la protection contre les inondations empêche les attaques par force brute sur le formulaire lui-même. Cela n'empêcherait pas une attaque distribuée de la part de quelqu'un qui avait accès à un botnet, mais l'analyse des journaux (quelque chose comme Droptor) qui recherche des connexions échouées répétées pour le même utilisateur résoudrait cela.

— greggles

3

En plus des bonnes mesures que Drupal 7 met en œuvre pour arrêter les tentatives de connexion, je suggère d'installer le module Spambot , qui traite spécifiquement des nouvelles tentatives d'enregistrement des utilisateurs.

À chaque nouvel enregistrement d'utilisateur, ce module interrogera le serveur Stop Forum Spam pour voir si l'utilisateur qui tente de s'inscrire est un bot connu.

Vous pouvez éventuellement contribuer à Stop Forum Spam avec les tentatives d'enregistrement de votre site Web.

— ermannob
source

3

Il y a le contrôle des inondations

Ce projet est destiné à ajouter une interface d'administration pour les variables de contrôle des inondations cachées dans Drupal 7, comme les limiteurs de tentatives de connexion et toutes les futures variables cachées.

Les fonctions pour définir et interagir avec le système de contrôle des inondations de base

Le système d'inondation nous offre trois fonctions:

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

Enregistrez un événement pour le visiteur actuel au mécanisme de contrôle des inondations.

flood_clear_event($name, $identifier = NULL)

Faites oublier au mécanisme de contrôle des crues un événement pour le visiteur actuel.

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

Vérifie si l'utilisateur est autorisé à poursuivre l'événement spécifié. Fondamentalement, nous vérifions si un utilisateur a accès en appelant flood_is_allowed. S'il renvoie FAUX, lancez un «Accès refusé». Chaque fois qu'un utilisateur effectue l'action, nous appelons flood_register_event.

Par défaut, il vérifie l'adresse IP de l'utilisateur. Mais nous pourrions passer un autre identifiant unique comme l'ID utilisateur.

Ci-dessus copié de Jouer avec le système d'inondation de Drupal

— niksmac
source

1

Veuillez ne pas copier et coller à partir du Web sans attribution appropriée

— Clive

1

@Clive je vais m'en occuper à partir de maintenant. Et c'est ce que je veux transmettre.

— niksmac

0

En pensant (et en ayant) ce problème, j'ai écrit un module qui vous permet d'empêcher ce type d'attaques: https://drupal.org/project/AntispammerBot

Vous pouvez sélectionner quels rôles sont sûrs, combien de nœuds l'utilisateur peut publier avant de le considérer comme une attaque de spam, etc.

— Alejandro Moreno
source