Useful Tips for Securing your Drupal Site

Drupal is well known for its stability and security out-of-the-box. However, we all know how dangerous the internet can be with all the risks of having your site attacked. There are particular situations in which an extra security measures are needed. This tutorial will deal with specific ways to secure your Drupal site, and the modules involved in this process. 

Let’s get started!


The Out-of-the-Box Features

The Drupal theming system has been improved in Drupal 8 with the use of the templating language, Twig. Twig templating has many advantages over PHP templating. One of them is that it is much easier to visualize on code. Another advantage is the fact, that all variables passed to the template are auto-escaped automatically. That minimizes the risk of a variable including a result that could break the HTML, and therefore your site. The risk is also minimized because you do not have to write custom PHP code in your templates anymore.

The PHP input filter module was part of the Drupal core in Drupal 7, but in Drupal 8, it is a contributed module. This measure eliminates vulnerabilities.

Drupal 8 implemented the trusted hosts configuration. This allows you to associate the Drupal codebase with a specific domain, to prevent online spoofing attacks

Due to the new programmatic approach of Drupal, modules can be enhanced in their functionalities by adding plugins. These plugins add behaviors to the module. The code stays clean and easy to analyze.

The use of Composer as package manager opens the door to new development possibilities for Drupal Open Source software, and it also helps to maintain all modules and keep their dependencies up-to-date and working properly. This is a key factor for the stability of Drupal systems.


How to Enhance Security on Access – Contrib Modules

190919 drupal security

 

There are two alternatives:

  • Lock attack vectors within the system
  • Limit vulnerabilities by restricting or changing system functions and operations, taking the responsibility from the user

Here are some modules, which provide this kind of functionality:

Automated Logout

Link: https://www.drupal.org/project/autologout

This module allows you to configure the time period for users to be logged in on your site. You can configure different time periods for different user roles, assuming that a user with a higher role, i.e. with access to more valuable information or resources on the site, would need to log in more frequently, than a user with a lower role. 

Session Limit

Link: https://www.drupal.org/project/session_limit

With the Session limit module, you can determine the limit of simultaneous sessions per user on 2 different browsers. If you set the session limit to 1 and open a new session in another browser, the session of the first browser will automatically expire.

Login Security

Link: https://www.drupal.org/project/login_security

Login Security allows site administrators to authenticate user only from valid IP addresses, that way, it is possible to grant or restrict access to your site to whole countries if needed, just by configuring the right domain. Login security restricts also the number of login attempts, so brute force attacks can be avoided. An extra feature of this module is the fact that it can hide Drupal login error message. The attacker will have another problem trying out if the account he wants to access even exists. 

Security Kit    

Link: https://www.drupal.org/project/seckit

Security Kit allows developers to change response headers. This is useful for very specific security needs on sites with high probabilities of Cross-site scripting, Cross-site request forgery, and origin driven attacks.

Honeypot

Link: https://www.drupal.org/project/honeypot

Honeypot prevents robots from filling out the forms of your site, by determining if the user is human or not. It uses two identification methods. One of them is by using a hidden form field, which is not visible to humans if the field has been filled out, Honeypot detects this and blocks the submission. The other method is by taking the time in seconds, in which the form has been filled out. A low value here (2-3 seconds), would speak for a robot, so the module would block  this submission too.

CAPTCHA 

Link: https://www.drupal.org/project/captcha

A captcha is a challenge-response test, to determine whether the user is human or not. This way, the goal of blocking fake form submissions, is achieved since robots will not be able to decipher the captcha text or image.


Auditing – Checking Procedures

190919 drupal security 001

 

It is always important to permanently review the system logs. This is even more important if your site has already been compromised. The analysis of all this data will help you also to track transactions within your system and perform checks on the ongoing state of the system. A rule of thumb is to log as much data as possible – always!

Some of the modules, which provide this type of functionality are listed below:

Site Audit

Link: https://www.drupal.org/project/site_audit

Site audit performs a static analysis of the whole system, against a set of recommended configurations. The module also stores reports of every audit. By performing this check, you as a developer can be sure and confident that your site is meeting the required security standards.

Security Review

Link: https://www.drupal.org/project/security_review

Security review, like Site audit,  makes also an analysis of the system, but this time, against a set of potential security implications on your site, like file permissions, text formats, and potentially malicious PHP or JS code on the frontend. It also stores reports. 

Login History

Link: https://www.drupal.org/project/login_history 

Login history adds a report to the database with a log of every user login, including timestamp, IP address, and user agent information. As stated before, it is always good to log as much information as possible.


Authentication Measures

190919 drupal security 002

 

Often, the importance of the information, implicate a reduction of usability. Users take instead of that the extra hassle of these additional authentication procedures.

The modules that you can use for this purpose are listed below: 

Two-factor Authentication  

Link: https://www.drupal.org/project/tfa

Two-factor Authentication provides an additional verification step, which ensures the integrity of the user authenticating. It also provides an API to support different plugins (provided by modules), which integrate several authentication services, like the Google Authenticator module.

simpleSAMLphp Authentication 

Link: https://www.drupal.org/project/simplesamlphp_auth

This module will allow you to replace the default Drupal login with a single-sign-on implementation. The module communicates with identity providers for authenticating users. That way you can validate the identity of the user through a service like Twitter, Facebook or Google

Password Policy

Link: https://www.drupal.org/project/password_policy

The Password Policy module defines a set of rules to force users to have strong passwords. It also forces users to change their password from time to time, depending on the configured options. Password Policy provides an API to define your own set of rules. 

Password Strength

Link: https://www.drupal.org/project/password_strength

This module provides a star rating widget, for users to test the strength of their passwords. You can leverage the API of Password Policy to force users to enter a password with a high rating (minimum rating).


Encryption

190919 drupal security 003

 

The data at rest (data that is not being used) should be encrypted to prevent attacks of all types. The encryption provides solutions at all levels:

  • Hosting
  • Server
  • CDN
  • Drupal system

 

As a rule of thumb, and to guarantee the highest security, the best way is to perform encryption at a low level of this stack.

You should always use HTTPS and SSL for all your web traffic, and you should also ask your hosting or cloud provider about full disk encryption.

Some useful modules are:

Key

Link: https://www.drupal.org/project/key

The Key module manages the system and API keys. It provides an API with options to store and retrieve sensitive keys like API keys or encryption keys. The site admin can decide where to store these keys in the system. Examples of API keys are the public keys for services like AWS, PayPal, or MailChimp.

Encrypt

Link: https://www.drupal.org/project/encrypt

The Encrypt module is an API, which provides a common algorithms utility to encrypt and decrypt Drupal application data. Its API is leveraged by many modules, which make use of algorithms to encrypt/decrypt (Real AES, Diffuse), modules to encrypt data, like Field Encrypt and File Encrypt and other modules for more specific use cases, like Pubkey Encrypt.

File Encrypt

Link: https://www.drupal.org/project/file_encrypt

This module focuses on the file system, it performs a check of the encryption on all files.

Field Encryption

Link: https://www.drupal.org/project/field_encrypt

This module encrypts data at the field level, that is, it encrypts field values.


 DevOps (Developer Operations)

190919 drupal security 004

 

The development process is critical to proactively maintaining the security. You should always use code repositories and pull requests for all your files. Other measures imply performing regular code reviews, tag each one of your code releases, keep the site code always up-to-date (this includes JS libraries), and try always to avoid manual procedures because these entail mistakes. Always try to automate your scripts and use a tool like DRUSH.

Some of the relevant modules in this category are:

Coder

Link: https://www.drupal.org/project/coder

This module has PHP Code Sniffing extensions to test the code on your site and compare it against the coding standards of Drupal.org. Coder will not do anything on your UI. It is rather a command-line tool.   

Hacked

Link: https://www.drupal.org/project/hacked

The Hacked module scans the code of your core and contrib folders and compares it against the code hosted at Drupal.org. It shows the differences between both codebases, so you can take the proper measures regarding your code. 

Backup and migrate

Link: https://www.drupal.org/project/backup_migrate

This is a classic among Drupal modules. Backup and migrate performs regular backups of the codebase and of the database, so you can restore them, for example on a fresh installation. This is very useful if your system has been compromised, and you want to restore it. 

Environment

Securing the infrastructure, in which the system is hosted, is as important as securing Drupal itself. Try always to mitigate attacks before they happen. This module list is supposed to help you with that purpose. 

  1. Use a coding workflow – making sure that the best code ends at the production environment. 
  2. Make a very detailed analysis of the logs – there are very useful tools for this matter, like Splunk or the ELK stack.
  3. If it is possible, try to use cloud-based environments – these are more secure than hosted environments. 
  4. Try to use CDNs every time you can – this acts as a firewall preventing malicious attacks early in the process.
  5. Make sure you have an up-to-date failover environment and test what would happen in case of a failover. 

Please, leave us your comments and questions below.  Thanks for reading!

Author

  • Jorge Montoya

    Jorge lived in Ecuador and Germany. Now he is back to his homeland Colombia. He spends his time translating from English and German to Spanish. He enjoys playing with Drupal and other Open Source Content Management Systems and technologies.

    View all posts
0 0 votes
Article Rating
Subscribe
Notify of
guest

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
rahul pandey
rahul pandey
5 years ago

Thanks! for sharing nice articles related to drupal security.

Mikall Hill
5 years ago
Reply to  rahul pandey

You’re very welcome!  Glad you liked it.

John
John
4 years ago

Hi – quite surprised how few articles reference automatic banning of wannabe hackers e.g. path2ban, autoban.

Anna
Anna
4 years ago

Thank you for the article! 

4
0
Would love your thoughts, please comment.x
()
x