Comment gérer quelqu'un qui essaie de se connecter en tant qu'administrateur?

14

Au cours de ces derniers jours, j'ai remarqué dans mon blog que quelqu'un essayait de se faufiler.

La personne a essayé de trouver l'URL de connexion (mon site Web n'est pas ouvert pour l'enregistrement des utilisateurs), elle a donc tout essayé depuis my-domain.com/admin, my-domain.com/administrator .. et aussi my-domain.com/wp- login (ce qui indique que la personne ne connaît pas drupal ..)

Une fois que la personne s'est retrouvée sur / utilisateur, elle a essayé de se connecter en tant qu'administrateur en essayant différents noms d'utilisateur: admin, administrateur, etc. (je n'utilise jamais 'admin' comme nom d'utilisateur pour l'utilisateur root)

Existe-t-il un moyen d'empêcher / protéger un site Web Drupal de ce genre de choses?

Merci

ps: je suis intéressé par la façon de le faire à la fois pour d6 et d7.

security users

— amstram
source

14

Ces types de sondes sont très courants sur Internet. Vous pouvez potentiellement faire certaines choses pour bloquer ce problème et réduire le succès d'un attaquant.

Tout d'abord, je recommande à tout le monde d'utiliser l' authentification à deux facteurs afin que même si l'attaquant devine votre nom d'utilisateur et votre mot de passe, il ne puisse toujours pas se connecter. Il y avait une prime de 500 $ pour briser TFA et bien que les attaquants à chapeau blanc avaient un nom d'utilisateur et un mot de passe qu'ils ne pouvaient pas pénétrer.

Le module d'examen de la sécurité ou Droptor peut aider à surveiller ces échecs de connexion. S'ils se produisent souvent, vous devez commencer à prendre d'autres mesures. Les attaques par force brute sur les mots de passe ne fonctionnent que si quelqu'un les fait beaucoup, donc si cela se produit quelques dizaines de fois, je ne m'inquiéterais pas.

Vous pouvez suivre l'adresse IP utilisée par cette personne à l'aide d'entrées de surveillance, puis utiliser les règles d'accès D6 intégrées (ou l'équivalent d7 - http://drupal.org/project/user_restrictions ) pour bloquer l'accès via cette IP. Vous pouvez également refuser l'accès à l'adresse IP dans Apache ou un autre pare-feu au niveau du serveur. Le pare-feu / serveur Web est un endroit plus efficace pour bloquer les utilisateurs en termes de charge sur le serveur, mais il nécessite généralement un peu plus d'efforts.

Pour Drupal 6 et 7, AjitS a fourni une réponse avec une bonne description de la façon d'utiliser une fonction de limitation de débit pour empêcher les tentatives de connexion répétées à partir de la même IP.

— greggles
source

6

Maintenant, cela ressemble à la réponse d'un gars de l'équipe Drupal Security ;-) +1

— AjitS

Idées intéressantes. Je vais commencer par bloquer les adresses IP en utilisant les règles d'accès d6 pendant quelques jours et voir comment cela aide. Merci à tous !

— amstram

Bravo pour la réponse bien écrite, mais grosse perte de temps. Quoi que vous fassiez, vous aurez toujours ces scripts grattant votre site. Il vous suffit de servir votre page d'administrateur et de connexion en https et d'avoir un mot de passe administrateur décent.

— stefgosselin le

Drupal 7 ne bloque-t-il pas automatiquement l'accès à partir d'une certaine adresse IP après plusieurs tentatives de connexion infructueuses? Un jour, un client m'a appelé pour me dire qu'il ne pouvait plus se connecter car il a essayé son utilisateur / passer 5 fois et a échoué et maintenant il ne peut plus se connecter et j'ai dû nettoyer certaines tables de la base de données pour lui redonner l'accès. ..

— Mario Awad

@stefgosselin https n'est pas une option pour beaucoup de gens, bien que je convienne certainement que c'est une bonne étape. Je ne vois pas non plus comment https aide vraiment avec le problème de la force brute. Je pense que TFA est utile pour les personnes qui ne peuvent pas obtenir https et / ou qui recherchent vraiment une solution aux attaques par force brute.

— gréggle le

3

Pour Drupal 6, vous devez vérifier le module de sécurité de connexion .

Le module de sécurité de connexion améliore les options de sécurité dans l'opération de connexion d'un site Drupal. Par défaut, Drupal n'introduit qu'un contrôle d'accès de base refusant l'accès IP au contenu complet du site.

Avec le module de sécurité de connexion, un administrateur de site peut protéger et restreindre l'accès en ajoutant des fonctionnalités de contrôle d'accès aux formulaires de connexion (formulaire de connexion par défaut dans / user et le bloc appelé "bloc de formulaire de connexion"). En activant ce module, un administrateur de site peut limiter le nombre de tentatives de connexion non valides avant de bloquer des comptes ou de refuser l'accès par adresse IP, temporairement ou définitivement. Un ensemble de notifications peut aider l'administrateur du site à savoir quand quelque chose se passe avec le formulaire de connexion de son site: devinette du mot de passe et du compte, tentatives de connexion bruteforce ou tout simplement comportement inattendu avec l'opération de connexion.

Pour Drupal 7, comme @saadlulu l'a dit, il existe déjà une fonctionnalité de verrouillage de l'accès après 5 tentatives infructueuses de connexion. Si vous voulez plus de contrôle, vous pouvez essayer le module Flood Control .

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.

— AjitS
source

3

Peut-être que l'utilisation de renommer les chemins d'administration aiderait?

Le but de ce module est de sécuriser le backend drupal en redéfinissant le chemin d'administration.

— John
source

en.wikipedia.org/wiki/Security_through_obscurity

— Mark Ferree

Ouais, je sais que "la sécurité à travers l'obscurité" n'est pas vraiment du tout la sécurité, mais je visais en fait à répondre à la question ...

— John

bonne réponse, renommer / user / login en custom / login / path peut être très efficace pour empêcher les bots d'essayer de se connecter sur l'URL par défaut

— underound

3

Je voudrais gérer cela de la même manière que les connexions qui ont échoué depuis d'autres sources (par exemple ssh, ftp) sont gérées, donc elles sont toutes traitées de manière cohérente. Pour cela, je me pencherais sur fail2ban , que j'ai eu beaucoup de succès à utiliser contre les connexions SSH par force brute. Il alimente également bien les outils de surveillance et bloque au niveau du pare-feu, ce qui est généralement plus sûr que d'empêcher uniquement les connexions Drupal car il est courant que plusieurs vecteurs d'attaque proviennent du même endroit, par exemple s'ils exécutent des choses comme metasploit .

— Synchro
source

Je suis d'accord, mais cette installation drupal qui est `` ciblée '' s'exécute sur un serveur d'hébergement partagé qui m'empêche d'avoir accès aux paramètres du niveau du serveur, je ne peux que l'essayer et le protéger depuis Drupal Mais j'envisage de le passer à un serveur dédié dans les prochaines semaines. Merci

— amstram

L'un des avantages de passer au niveau du pare-feu est que Drupal n'est qu'une partie de la surface d'attaque de votre site. Si quelqu'un ne peut pas entrer via Drupal, il verra probablement si ssh ou ftp ou ... d'autres services sont en cours d'exécution, puis essaiera d'entrer via ces méthodes.

— greggles

3

Il s'agit en fait d'un comportement totalement attendu. Chaque fois que vous publiez un site Web sur une adresse IP publique, en quelques heures / jours, vous commencerez à obtenir du trafic de ce type. 99,99% du temps, ce ne sont que des robots qui exécutent un script générique à la recherche d'applications non corrigées ou de mots de passe faciles. Cela explique pourquoi vous voyez des hits sur domain.com/wp-login, l'hôte attaquant (automatisé) ne sait même pas initialement que vous exécutez Drupal, il essaie tous les chemins des CMS populaires, Wordpress, Drupal, etc. .

Je dis ne perdez pas trop de temps à vous en préoccuper. Quoi que vous fassiez, vous trouverez toujours ces scripts grattant votre site ... du monde entier.

Deux choses simples rendront votre application relativement sécurisée:

Servir les pages de connexion et d'administration via https
Avoir un mot de passe décent pour l'administrateur

Quel que soit le schéma de sécurité que vous implémentez, TOUJOURS avoir une sauvegarde récente de vos fichiers.

Bonne chance, joyeux nouvel an.

— stefgosselin
source

2

Ce que vous demandez n'est pas logique si vous voulez supprimer ou empêcher l'accès à / la page utilisateur.

Si vous parvenez à empêcher cette page, comment allez-vous y accéder?

De plus, Drupal fournit déjà un moyen d'arrêter de telles attaques en verrouillant l'accès à un utilisateur après 5 tentatives.

Vous pouvez cependant limiter les tentatives à votre compte administrateur.

— saadlulu
source

Bonjour, Merci d'avoir répondu. Je ne demande rien de spécifique. Je cherche juste des idées sur la façon de gérer cela. Je pense que le «verrouillage 5 tentatives échouées» est une fonctionnalité Drupal 7 uniquement, ai-je raison? Est-il possible d'implémenter une fonctionnalité similaire dans Drupal 6?

— amstram

Je n'en ai aucune idée puisque mon parcours n'est que Frupal 7. Je laisse cela à mes frères de Drupal 6 :). vous pouvez me faire une faveur et accepter ma réponse si vous l'aimez.

— saadlulu

vous pouvez également vérifier la sécurité de connexion de

— saadlulu

Cette "réponse" n'est pas bonne car le verrouillage à 5 tentatives n'est que Drupal 7 et il y a toujours des choses à faire pour éviter le problème, même au-delà.

— greggles