Preventing Brute Force Attacks with Drupal Login Security Module
Tech
August 20 2018
4 min read
Share
Raman
The internet is a wild place. You never know who’s on the hunt for vulnerabilities of your site. In fact, the moment you deploy your application on the web, you are inviting all sorts of requests on your server. Apart from genuine users, these could potentially be automated scripts, (mostly harmless) bots or crawlers, ethical/non-ethical hackers or some curious geeks (like me).
One of the key areas of interest for them is to exploit the authentication or login system of an application. Compromising the security of your users’ accounts can lead to severe consequences such as the leak of their personal information, misuse of their identity (or your platform), and can even cause financial losses.
It is of utmost importance to ensure that healthy security standards are implemented. These include enforcing strong Password Policies, employing salted password hashing, adopting HTTPS, preventing brute force attacks, utilizing two-factor authentication and so on.
Securing a Drupal siteis a vast topic in itself, but in this article, we will focus on understanding the default flood control mechanism and then later explore the usage of Login Security, a contributed module, to enhance the security.
Default Flood Control Mechanism of Drupal
In Drupal, User, a core module, is responsible for providing the features related to user account management such as authentication, logging in/out, password management, registration, roles, and permissions. It also does a basic yet effective prevention against brute force attacks using its flood control mechanism.
Flood Control of Drupal in Action
Whenever a user authentication fails, it is considered as a flood event and its entry is made in the “flood” schema storing the event type, user identifier, timestamp, and expiration of this flood event. There are two ways (flood event types) in which Drupal keeps a track of login failures – IP address based, and user account based.
Flood database table
By default, an IP address gets blocked if there have been 50 login failures from that IP address within an hour. Also, the combination of the user account and the host IP address gets blocked if there have been 5 login failures for that user account from that IP address within a span of 6 hours.
However, there are mainly two limitations of this default mechanism.
There is no user interface for site administrators to configure the allowed number of login attempts and blocking time period.
There should be some way to alert the site admin or the user whose account is being exploited.
Now, let us explore how we can use Login Security to overcome these limitations.
Downloading and Installing Login Security Module
The only prerequisite of the module is the core Ban module. Once you’ve made sure, it is enabled, you may proceed with installation of the Login Security module using any of the below methods.
$ drush dl login_security && drush en -y login_security
After downloading the module using composer, enable it from the admin UI available at admin/modules.
Enabling Login Security module using admin UI
How does the Login Security module work?
The module works by implementing hook_validate(), thereby overriding the default login form flow. It maintains its own schema, login_security_track, to keep a track of failed login attempts. It can detect an ongoing attack using the configured threshold value within a set time window and can also alert the site administrator through email or logs.
Login Security Track database table
It offers two types of protection against the attacks – Soft and Hard. The soft protection is similar to the default flood mechanism, that is, it temporarily blocks the user from submitting the login form. The hard protection, however, permanently bans the host IP address and changes the status of the user account to blocked.
If needed, the site administrator can unban the IP addresses from the admin UI available at admin/config/people/ban and unblock the users from admin/people. Additionally, it can also be configured to display the last access and last login timestamp to the users to further comfort them of their security.
A Drupal message shows the last access and login timestamp to users after successful Login
Configuring Login Security
The module provides a configuration form under admin/config/people/login_security. So, navigate to Manage → Configuration → People → Login Security.
You may configure the following options as per your security needs and then hit “Save configuration” to apply the changes.
Configuring the Login Security module
Configuration
Default Value
Description
Track time
1
The time window for which the login failures are considered. Soft protections expire after this time
User
0
Max. number of login failures after which a user account will be permanently blocked
Soft host
0
Max. number of login failures after which an IP address will be temporarily blocked from submitting the login form
Hard host
0
Max. number of login failures after which an IP address will be completely banned using the core ban module
Attack detection
0
Max. number of login failures after which an ongoing attack is detected and a warning is logged
Disable login failure error message
False
Display the core login error messages
Notify user about remaining login attempts
False
Display the number of attempts remaining before the user account will get temporarily blocked
Display last login timestamp
False
Display a Drupal message with the last login timestamp of the user
Display last access timestamp
False
Display a Drupal message with the last activity timestamp of the user
Along with these configurations, the text within the Drupal messages on the events (failed login attempt, hard/soft IP address ban, and blocking of the users), and the email fields (address, subject, and body) can also be configured. You may use the provided tokens to send a dynamic data in the alert/message.
Configuring the alert settings of the module
Conclusion
The Login Security module adds another measure of security to a Drupal website. In particular, it allows greater control on dealing with a situation of a brute force attack. At the end of the day, however, ensuring security is not just limited to configuring the modules but also lies in the hands of people who administer and deploy the websites.
In case of any queries or suggestions, feel free to drop down a comment.
A BIG SHOUT OUT to the bloggers and evangelists willing to impart their knowledge with their writing.
Share your experience and opinion with us and let the world be the stage to your ideas and work. Share your piece with us at [email protected]. We also welcome ideas in the planning phase.
What Do We Expect?
The content should align with our interest in web development and open source technology. However we are open to topics from in and around the industry.
An average blog post should be of around 1000 words, but this is of course subjective.
We love crazy and colourful content. Feel free to link awesome pictures, infographics, stats, and all.
We are also open to articles with cool tips and tricks, some How-to and step by step guide as well