How to secure Drupal – tips & best practices

Securing Drupal, regardless of the version you are working with, is not that difficult. Security, as a baseline, is always a multi-layered exercise. Many clients do not understand that you have to work on securing everything that makes up your website – from server operating system all the way to the application layer.

This post is not going to go into server architecture or best practices for managing packages, RPMs, or other components – for now we will focus on the application layer.

Tips to Securing Drupal (under Apache)

  1. Remove what is not necessary. If a module is not needed, then it should be removed. Less to maintain = less that needs to be guarded or could become vulnerable.
  2. Remove unneeded access points. While it may appear beneficial to have your administration logins available from any IP address – locking down the administration area to only approved IP addresses goes a long way to preventing access. Most serious businesses have a static IP address for their offices – if you do not, then it is time to call your ISP.
  3. Install a Web Application Firewall (WAP). Apache has a number of modules that help security at the web server level and block various attacks and known exploits. You can install mod_security and use their stock rule set for a good baseline security. In addition to this, you can use “curated” rule sets from different vendors. We use the OSWAP curated rule set on many of our installation. Another module to consider is using mod_evasive. Mod_evasive is helpful in detecting and preventing http-based DoS or DDoS attacks and can work with your firewall, ipchains or other network equipment to ban IPs and IP-ranges.
  4. Harden your PHP. You can “harden” your version of PHP by making some modifications to the php.ini file. If you are dealing with a stock installation of PHP, you can remove any modules you do not want or need. You can see what modules are installed from the command prompt by typing:

$ php -m

There’s a number of things you should consider changing, including:

  • Session Fixation. Use the HttpOnly flag to reduce the risk of an XSS attack. You will want to limit access to protected cookies and set a secure cookie domain flag so session information can only be passed to the same domain. You should also set the hash algorithm to use a protocol like SHA2.To see what hash algorithm’s are available on your server you can run the following command:

$ php -r ‘print_r(hash_algos())’

The changes you will want to make to your PHP.ini file will look like:

session.cookie_httponly = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.hash_function = SHA2

  • Disable certain “dangerous” functions in PHP. This one you really need to confirm before adding these to your PHP.ini file. The exec function is used by Drupal’s PHP filter – however, many Drupal installs can get by just fine without making use of PHP Filter.A conservative approach would be to disable just exec, system and shell_exec:

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.
disable_functions = “shell_exec, exec, system”

You can take this further by disabling all “dangerous” PHP functions. Individual results may vary – by which we mean plunge your site into darkness and down for the count.

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Securing Drupal at the Application Layer

  •  File Permissions. Drupal performs certain housekeeping tasks by writing to the files on the server. Examples of this include writing to the /tmp directory, compressing CSS and JavaScript and managing uploads to the public website itself. You should consider making the settings.php file unwritable in the sites/default directory after installation. Make sure that your directories are set to the lowest acceptible permission set allowed by your web server. Under suPHP this would be 755 for directories and 644 for files.
  • Keep Drupal & all Modules up to date. This is a no brainer and you should also source quality modules and contributions. You want to pick modules that have lively support and are being actively maintained.
  • Install Drush. Drush is a command line shell for Drupal and opens up to you powerful tools for managing security, updates and the general health of your Drupal installation. You can also extend the functionality of Drush with third-party command files. You can find more information on Drush here.One Drush module we often make use of is the Security Check module. This module will test your configuration for known issues and problems. It should not be thought of as an extensive review, rather it looks for major mistakes and tells you about them.
  • Install quality security modules. The following are some modules or functionality you should consider for your Drupal installation.Update Manager.Update manager helps keep better track of the latest updates to Drupal Core, Themes and Modules. You can set this module to notify you as well, which is very important in keeping up to date on what may or may not impact your Drupal application as a whole. View update manager here.Login Security. Login security allows you to secure the login areas you use for Drupal and manages failed login attempts. It can be configured to send email notices when someone fails logins or a brute force occurs. Alerts can also drive you nuts as every brute force bot is going to trigger those emails. Check out Login Security here.
  • Password Policy. This module lets you define the password requirements for users and prevents them from setting up or replacing passwords with less than secure choices. Learn about Password Policy here.
  • Secure Pages Hijack Prevention. This module helps stop cross-site forgery and scripting attacks within Drupal by handling the HTTP request headers and responses. It also prevents clickjacking and man-in-the-middle attacks. This is a very important module to install. Get it here.
  • Session Timeout Module. This module lets you set the maximum number of concurrent sessions and can be set to log out a user if that user requests/starts a new session. This module can limit one session to one user. Get it here.
  • Set Content Access. This module is very important for most sites. It allows you to set permissions for all content types based on the roles you have withn your Drupal site. It is very flexible and requires ACL API to be installed as a pre-requisite. You can see Content Access’s features here.
  • Paranoia. The paranoia is a good addition because it automatically detects where in Drupal users are allowed to evaluate PHP and then blocks them from being able to do that. When you install this module you can then check all previous grants to eval and secure them. Download Paranoia for install here.
  • Security Review. This module can set up automated security testing for your Drupal Application. When run, it produces a checklist that you can review and see where security trouble spots may exist. It checks things like: insecure file permissions, input tags, improper error handling and reporting, insecure private files, sets policy rules for “safe” extensions and disallows installation of “unsafe” extensions, checks for database errors, failed logins, brute force attempts, adds protection for phishing and checks your user access control and many more features. Pick up this module here – you will not be disappointed.
  • Automated Logouts. This module is a lot like session timeout only it allows easier handling of session timeouts by role – even allowing users to choose their own session timeout if you so desire. It is highly customizable and useful if you want to set session timeouts on forms a s well. Get this module here.
  • Username Enumeration Prevention. This is a module that prevents attackers from being able to interrogate Drupal until they find a valid username. Attackers will hit forms that allow login or password retrieval and listen for the response. When they get a response that the user exists, they now know half of the equation when it comes to a brute-force attack. This module prevents that by standardizing the response whether the user exists or not. This keeps the big data bots out of your systems. Get it here.This is really just the start. Security is a constant en-devour and battle against both humans and rapidly advancing artificial intelligence.

 

 

Want to discuss a project?

  • This field is for validation purposes and should be left unchanged.