Bolstering this industry leading core security defence, it is possible to further security harden Drupal and go to extra lengths to protect your site by installing and configuring additional security focussed Drupal contrib modules.
Below is a selection of our favourite Drupal security modules (excluding spam prevention modules which will be discussed in a future post) that you can add to your Drupal site with the minimum of fuss. These are modules that we often recommend for inclusion on Drupal sites (depending on the context and security requirements), where Zoocha is the appointed Drupal support and maintenance partner:
The Password Policy module is one of those essential modules which every Drupal site should ideally have enabled and configured. Out-of-the-box Drupal will allow you to use weak passwords, which is rarely the behaviour that you would want, especially for internal users who will have content administration and higher privileges.
Using the Password Policy module it is possible to configure passwords to fall in to line with organisational security policies, or national guidelines such as those published by the NCSC.
Should the Password Policy module be introduced to an existing Drupal site, consider forcing a password reset (using the Mass Password Reset module, discussed next) of all users so that you can be confident that every user has a strong password set, or those users of a given role type.
Mass Password Reset
Referenced above, the Mass Password Reset module allows you to password reset all user accounts, or all user accounts that have a certain role type, and then notify them that they need to reset their password.
The password reset email notifications which get triggered can be customised to include content relating to why they are receiving a password reset instruction email, thus personalising it to the site in question and giving context to users.
It is useful to add and enable this module on a site (ahead of actually needing it), as in the following scenarios it can be useful to have at your disposal:
- You need to quickly change all passwords on a site for security reasons
- An organisations password policy changes and you need to ensure that all passwords for internal users on a website are conformant to it
- As part of a leaver checklist, you are required to get everyone of a certain role type to reset their passwords
- As part of a new site launch, you have a large number of user accounts that are pre-created (where it hasn’t been possible to migrate passwords) and you want to send password recovery emails to all users so that they are able to log in to the new site
The Drupal Security Kit module is like the Swiss Army knife of HTTP header manipulation. Through an intuitive configuration screen, you are able to control, and set rules for a variety of security-related HTTP headers such as From-Origin, HSTS, X-Frame-Options, Content-Security-Policy etc.
Adopting this module prevents the need for having to call upon a range of other single purpose Drupal modules which fulfil manipulation of only a single HTTP header. For example, the Content-Security-Policy headers can be configured within the Security Kit module, instead of having a dedicated module such as a Content Security Policy to solely handle that particular security feature. This is beneficial from a module proliferation perspective.
The Automated Logout module provides a site administrator the ability to log users out of a Drupal website after a specified time of inactivity. Some organisations may find this useful where there are a number of internal users of a system, and they feel that there is a risk of account compromise through unattended computers having active Drupal website sessions.
The Automated Logout module is highly customisable and includes "site policies" by role to enforce the logout action.
The Login Security module has a range of different features within it that allow you to modify the default behaviour of the Drupal login process.
Through configuration of the module, a site owner may enforce things like:
- limiting the number of failed login attempts before blocking an account
- denying access by IP address, temporarily or permanently
Login History adds a new database table within Drupal which stores information about individual user logins. This new table contains data including timestamp, IP address, user agent information, and whether or not the login was via a reset password link.
Based on this data, there are reports which can be generated by the Login History module to yield information on:
- all user logins
- per-user logins
The module also makes a block available which can show a user information about their last login, along with a link to their own login report where it is possible to see their full login history.
In the same vein as the Login History module, the Audit Log module allows you to capture and see a full history of all admin activity on your site. This can be especially useful when you were trying to establish if there has been a genuine security incident, or simply user error.
The Session Limit module allows site admins to limit the number of simultaneous sessions per user.
By default, a session is created for each browser that a user uses to log in. This module will force a log out of any extra sessions that are opened after they exceed the maximum number defined within the module configuration.
By way of example, assuming the session limit is set to 1, then if a user is logged in to a Drupal site from their work computer, and then they attempt log in from their home computer, then they would be forced to either log off the work computer session, or accept not being able to log in from home.
Username enumeration is a technique used by anonymous users to identify valid usernames on a site. Once valid usernames and known, then these can be used in other forms of attack, such as credential stuffing, or brute force attack.
The Username Enumeration Prevention module prevents against this by:
- Providing warnings on the admin status report screen if a site is configuration could expose usernames
- Prevents the core password reset functionality form from displaying messages which give revealing details about a username e.g. if it is already taken
This module will verify that files uploaded to a Drupal site are not infected with a virus, and prevent any files that are flagged as being infected from being saved within the Drupal file system. This then of course prevents your site from inadvertently spreading malware, along with avoiding any potential embarrassment that comes from being detected as doing so by the likes of Google who will give strong warnings to users who visit your site using Chrome for instance.
If users are able to upload files on your site, then we recommend that the Drupal ClamAV module is used.
The Encrypt module can be especially useful if you have data security requirements around user data being encrypted within the Drupal database. At Zoocha we have used this module several times in conjunction with the Webform Encrypt module in order to encrypt Webform submissions made by users. This can be beneficial in giving an extra layer of security when users are being asked to provide sensitive information as part of a form completion process.
The Role Delegation module can be useful if you have several tiers of user role types on a site. In this circumstance, the Role Delegation module will allow you to give certain roles the ability to manage the roles of other users. This is an alternative to giving a user the highly permissive “administer users” Drupal permission.
To add an extra layer of security to the Drupal authentication process, the Two-factor Authentication module can be configured with a variety of identification solutions such as SMS delivered codes, Google Authenticator app and so forth.
To round off this list, the Database Sanitize module can be used to remove user information from a Drupal database using Drush. This is particularly useful for building into any jobs you might have which attempt to syncronise data from a production setting to another lower level environment. As a basic example, this could be used to purge webform submission data, or similar, after a syncronisation to a UAT environment - doing this would reduce the number of places that this user data was held and any controls that were needed, and perhaps allow a less rigorous permission enforcement on non-production environments.