Securing Drupal

Information Security Guideline

Introduction

1. Drupal is a popular open source content management system and is frequently targeted for attacks; this hardening guide is meant to further enhance the level of security for Drupal by reducing the exposed attack surface by providing configuration guidance.
2. This guideline has been issued by the Chief Information Officer to supplement the Vulnerability Management standard. Compliance with this guideline is recommended, but not mandatory. Questions about this guideline may be referred to information.security@ubc.ca.

Best Practices for Protecting the Application Platform

1. Once installed, ensure that Drupal’s “Update” module is installed and notification for security updates is enabled. Subscribe to Drupal’s Security Advisory email list, or Twitter account.
2. Input filters & WSIWYG
   1. configure input filters for different user-levels;
   2. turn on WSIWYG Filter and configure to allow specific tags/classes/etc. only; and
   3. disallow “Full HTML” (potential for privilege-escalation attacks).
3. Logging & errors
   1. log (but don’t show) errors; and
   2. set login logging (“Login Security” module, even in D7, to log incorrect logins and set better flood protection).
4. If you have comments enabled, consider installing comment moderation software like Mollom and a captcha solution like ReCaptcha.
5. Only enable modules you intend to use, leave unused modules deactivated—or uninstall and remove from your server.
   1. for each module, look at its issue queue on Drupal.org: consider the number of active installs versus the number of open and closed issues;
   2. make sure the module page says “Actively maintained”; and
   3. never enable FTP module updating; always update modules through the command line (FTP updating requires giving the webserver write access to PHP files, which is a dangerously insecure site configuration).
6. To enhance overall security it is also important to harden the operating system that will be hosting the Drupal installation:
   1. look at file permissions, make sure that the webserver can never write into a directory with executable PHP; and
   2. ensure .htaccess files exist in all Drupal files directories (sites/*/files)
7. Permissions & Roles:
   1. create roles to add privileges to users, either by group (e.g., a “faculty” role) or function (a “webform results” role) – permissions granted by roles are additive, so a mix of both is most useful;
   2. set permissions to add/delete/update content as granularly as possible; and
   3. audit roles and permissions annually
8. If you have control over the server, and it is solely for a Drupal site, consider custom rewrites in the Apache configuration (at the <VirtualHost> or <Directory> level).

Recommended Sites

1. The following sites provide additional information on securing/hardening Drupal:

   Topic Area	Site
   Securing your site	https://www.drupal.org/security/secure-configuration
   Drupal Security Best Practices	https://archive.openconcept.ca/drupal-security-best-practices-practical-guide.html
   Hardening Drupal 7 Websites	https://bput4all.wordpress.com/2012/02/01/hardening-drupal-websites/
   Securing Drupal 7	http://www.madirish.net/242
   Security Group	https://groups.drupal.org/security
   Security Advisories	https://www.drupal.org/security

Related Documents and Resources

1. Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems
2. Vulnerability Management standard
3. UBC Systems and Application Hardening Guides

Guideline Last Revised: 2021-02