Protecting Your Drupal Against Brute Force Attacks

What are brute force attacks? This kind of attack involves attempting to procure unauthorized access by testing the login platform with multiple login credentials through the continuous generation and inputting various combinations generated by an automated bot. In this scenario, the automated program (or bot) looks for ‘success’ or ‘failure’ messages and pushes forward new combinations until there is an eventual success. 


One is especially vulnerable to brute force attacks when they are at the mercy of commonly used login usernames and passwords, among other commonly used methods to crack through.

In terms of protection against brute force attacks, Drupal core version 6.x and anything before that only possesses limited security cover in terms of usernames and passwords. 

For Drupal Firewall:

  • However, they do maintain a record of all failed attempts using the ‘watchdog’ feature – unless the malicious attempts go through a loophole of being an xmlrpc.php request (like the blogapi) or any other external login feature. 
  • There’s another method of protecting against brute force attacks – through the use of a module named ‘Login Security’ which can protect your site against brute force attacks. This module is the default provider of features related to user account management (like authentication, logging attempts, registration, permissions, roles, password management, etc), making it a basic yet effective prevention mechanism against brute force attacks. 
  • For installing the Login Security module, the prerequisite includes the core ‘Ban’ module, after which you can proceed with the installation procedure. The module may be downloaded from the composer, after which you can enable the user interface available at admin or the modules. 
  • How does the Login security module work? It uses the hook_validate() which overrides the default login form flow and maintains a login_security_track to keep a record of all the failed login attempts. It also has the ability to detect ongoing attacks using a configured threshold value within the given time period, and then alerts the site administrator through email or logs. 
  • There are also options to configure Login Security, under Manage > Configuration > People > Login Security where there are readily available options according to the security needs (like track time which is the time window for which login failures are considered, the user which is the maximum number of attempts per user, a soft host which is the maximum number of attempts from a specific IP address, etc)

For Drupal core versions 7.x, 8.x, and above, there is the added advantage of flood control variables which provide the feature of limited login attempts from a single IP address (the default state is 50 login attempts in an hour) and to a single account (the default state is 5 failed login attempts every 6 hours)

  • There are, however, two limitations to these default states – site administrators are provided with no user interface for configuring the number of login attempts that are allowed along with the blocking time period, and no existent system alert for the site admin or the user whose account is being exploited to gain unauthorized access.
  • When you access your Drupal platform and the attempt fails, this registers as a flood event, with an entry made in the ‘flood’ schema recording details (like timestamp, user identifier, event type, and the expiration of the flood event). There are two ways in which the Drupal platform keeps a track of such login failures i.e., two flood event types – based on user accounts, and based on IP addresses. 
  • flood_unblock and flood_control protect efficiently against brute force attacks and bans any IP address that attempts to log in to the website beyond the given limit and then report these addresses back to the crowdsourcing server to provide this information to other Drupal platform users so that they can guard themselves against it as well. This is termed as the crowdsource brute force protection, and it also helps against worms, rogue servers, spam, etc.
  • You cannot access flood control variables through the Drupal core administration pages but through the module ‘Flood Control’ that has an additional interface that has the option of changing them. 

Talking about the protection, this module offers two types – soft and hard. 

  • The default flood mechanism is categorized as soft since it simply blocks the user from submitting the form temporarily. 
  • Hard protection implies a permanent ban of the host IP address and any required changes to the user account, such as modifying the status to blocked. There is an option for the site administrator to withdraw the ban on any IP addresses from the admin user interface gained from admin > config > ban > people, and unblock the respective users from admin or people. Appropriate configurations can be set to display the point at which it was last accessed and the last login timestamp, providing customers proof of their security as well. 

This way, you can improve your Drupal security from a brute-force attack with the help of given extensions and appropriate caution.