During these last days, I noticed in my dblog, that someone has been trying to sneak around.

The person tried finding the login url (my website isn't open for user registration) so they tried everything from my-domain.com/admin, my-domain.com/administrator.. and also my-domain.com/wp-login (which indicates that the person isn't familiar with drupal..)

Once the person ended up on /user he or she tried to login as admin by trying different usernames : admin, administrator etc... (I never use 'admin' as a username for the root user)

is there a way to prevent/protect a drupal website from this sort of things ?


ps : i'm interested in how to do this both for d6 and d7.


6 Answers 6


These kinds of probes are very common across the internet. There are a few things you can potentially do to block this problem and reduce the success of an attacker.

First, I recommend everyone use Two Factor Authentication so that even if the attacker guesses your username and password they still can't login. There was a bounty for $500 to break TFA and although the white-hat attackers had username and password they couldn't break in.

The security review module or Droptor can help monitor these failed logins. If they happen a lot then you need to start taking more actions. Brute force attacks on passwords only work if someone does them a lot so if it just happens a few dozen times I wouldn't worry.

You can track the IP address in use by this person using watchdog entries and then use the built-in D6 Access Rules (or the d7 equivalent - http://drupal.org/project/user_restrictions ) to block access via that IP. You could also deny access to the IP in Apache or some other server level firewall. The firewall/webserver is a more efficient place to block the users in terms of load on the server, but it usually requires a bit more effort.

For Drupal 6 and 7, AjitS has provided an answer with a good description of how to use a rate-limiting feature to prevent repeated login attempts from the same IP.

  • 6
    Now that sounds like the answer from a guy from the Drupal Security team ;-) +1
    – AjitS
    Dec 26, 2012 at 13:31
  • Interesting ideas. I'll start by blocking the IP adresses using d6 access rules for a few days and see how that helps. Thanks to all of you !
    – amstram
    Dec 26, 2012 at 14:26
  • Kudos for the well written answer, but big waste of time. No matter what you do, you will always have these scripts scraping your site. Just serve your admin and login page in https and have a decent admin password. Jan 2, 2013 at 4:50
  • Doesn't Drupal 7 automatically block access from a certain IP address after repeated failed login attempts? I once had a client call me saying he can no longer login as he tried his user/pass around 5 times and failed and now he can no longer log in and I had to clean up some tables from the db to give him back access...
    – Mario Awad
    Jan 3, 2013 at 15:36
  • @stefgosselin https isn't an option for a lot of folks, though I certainly agree that's a good step. I also don't see how https really helps with the brute force problem. I think TFA is helpful for people who can't get https and/or who are really looking for a solution to brute force attacks.
    – greggles
    Jan 5, 2013 at 0:55

For Drupal 6 you should check for the Login Security module.

Login Security module improves the security options in the login operation of a Drupal site. By default, Drupal introduces only basic access control denying IP access to the full content of the site.

With Login Security module, a site administrator may protect and restrict access by adding access control features to the login forms (default login form in /user and the block called "login form block"). Enabling this module, a site administrator may limit the number of invalid login attempts before blocking accounts, or denying access by IP address, temporarily or permanently. A set of notifications may help the site administrator to know when something is happening with the login form of their site: password and account guessing, bruteforce login attempts or just unexpected behaviour with the login operation.

For Drupal 7, as @saadlulu said that there's already a feature of locking the access after 5 unsuccessful attempts to login. If you want more control, you could try the Flood Control module.

This project is intended to add an administration interface for hidden flood control variables in Drupal 7, like the login attempt limiters and any future hidden variables.


Perhaps using rename admin paths would help?

The purpose of this module is to secure drupal backend by overriding admin path.

  • Yeah, I know "security through obscurity" is not really security at all, but I was actually aiming at answering the question...
    – John
    Jan 24, 2013 at 17:15
  • good answer, renaming /user/login to custom/login/path can be very efficient to stop bots from attempting to login on the default url
    – devunder
    Dec 3, 2016 at 20:10

I'd want to handle this in the same way that failed logins from other sources (e.g. ssh, ftp) are handled, so they are all dealt with consistently. For that I'd be looking at fail2ban, which I've had great success using against brute force SSH logins. It also feeds in nicely to monitoring tools, and blocks at the firewall level, which is generally more secure than preventing just Drupal logins because it's common for multiple attack vectors to come from the same place, for example if they're running things like metasploit.

  • I agree but this drupal installation that's being 'targeted' is running in a shared hosting server which prevents me from having access to server level settings, i can only try and protect it from within drupal But i'm considering switching it to a dedicated server in the next few weeks. Thanks
    – amstram
    Dec 27, 2012 at 13:30
  • One benefit of going to the firewall level is that Drupal is just part of the attack surface of your site. If someone can't get in via Drupal they will likely see if ssh or ftp or...other services are running and then try to get in via those methods.
    – greggles
    Dec 28, 2012 at 16:33

This is actually totally expected behavior. Whenever you publish a website on a public ip, within hours / days you will start getting traffic of the sort. 99.99% of the time, these are just bots that run a generic script looking for unpatched applications or easy passwords. This explains why you see hits on domain.com/wp-login, the (automated) attacking host does not even know initially you are running Drupal, it is trying all the paths of the popular CMS's , Wordpress, Drupal, etc ....

I say don't waste too much time worrying about this. Whatever you do you will always find these scripts scraping your site ... from all over the world.

Two simple things will make your app relatively secure:

  1. Serve login and admin pages via https

  2. Have a decent password for admin

Whatever security scheme you implement, ALWAYS have a recent backup of your stuff.

Good-luck, happy new-year friend.


What are you asking for is not logical if you mean removing or preventing access to /user page.

If you manage somehow to prevent that page, how are you going to access it?

Plus Drupal already provides a way to stop such attacks by locking access to a user after 5 attempts.

You can limit the attempts to your admin account though.

  • Hello, Thank you for replying. I'm not asking for anything specific. I'm just looking for ideas on how to deal with this. I think the '5 failed attempts lock' is a drupal 7 only features, am i right ? Is it possible to implement a similar feature in Drupal 6 ?
    – amstram
    Dec 26, 2012 at 12:09
  • I have no idea since my background is only Frupal 7. I'll leave this to my brothers from Drupal 6 :). you can do me a favor and accept my answer if you like it.
    – saadlulu
    Dec 26, 2012 at 12:22
  • you can also check this module login security
    – saadlulu
    Dec 26, 2012 at 12:31
  • This "answer" is not a good one since the 5 attempts lockout is only Drupal 7 and there are always things to do to prevent the problem, even beyond that.
    – greggles
    Dec 26, 2012 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.