Keeping your Site Safe

Category
Developers
Site Administrators
Drupal Version
Version Agnostic
Tags
security

This page is now deprecated.  Please see the Best Practices for Configuring and Managing Drupal page for an enhanced list of security and site management tips.

Editor's Note: These tips are based on notes from “Securing Drupal 7: Don’t get Hacked or Spammed to Death!” presented at the February 2013 Georgia Tech Drupal User's Group Meeting.  Please feel free update with additional tips for securing Drupal sites!

Secure YOUR Code

  • Drupal.org Guide to Writing Secure Code
  • Be careful if you write a module or make code changes to a Theme!!
    • Separate/Comment any changes to Code.
    • Don't hack CORE!
  • Don't install non-recommended modules, libraries, or themes
    • Test anything you're not sure about in a separate sandbox instance of Drupal

Secure Drupal Core

Update Drupal Core When Needed

  • Make sure the Update manager module is ON and configured for security emails (admin/reports/updates/settings)
  • Apply every security patch after backing up EVERYTHING
    • Module updates are EASY in Drupal 7
    • Installatron makes CORE updates easier (but MUST backup .htaccess and robots.txt).
  • Drupal Security Review Contrib Module - Scans your installation for common security problems

Properly Configure Modules and Module Settings

  • Turn off the following modules unless you really need them:
    • PHP filter (Always keep this one off!)
    • Tracker
    • Comments
  • Configuration -> Logging and errors -> Error messages to display:  Set to None
  • Configuration -> Logging and errors -> Error messages to display:  Set to 1000 (or 10,000 if you have a really busy site)
  • Configuration -> Media -> File system:  Consider making private if that works for your site

Properly Configure User Account Settings

  • Check over the User Account settings (Configuration -> People -> Account Settings)
    • Self registration for user accounts is enabled by default!  Configure Who can register accounts? so that only Administrators can register accounts.
    • Set the default for When cancelling a user account to "Disable the account and keep its content.”, because deleting users who have created content could lead to access bypass.  Alternatively, validate whether or not the user had ever created any content, and reassign the content to someone else before deleting the user account.
    • Disable the setting Enable personal contact form by default
    • Disable the setting Enable signatures (because it applies to ALL)
    • Disable the setting Enable user pictures (because it applies to ALL)
  • Regularly review your list of users (admin/people)
  • Disable User #1 in Drupal 7 as it is not needed
    • Configure a regular user account with administrative powers and use it instead
    • Rename user #1 from something common like 'admin' or 'root' to make it harder for hackers to guess the username

Properly Configure User Permissions

  • Review user permissions regularly (admin/people/permissions)
  • Give the ANONYMOUS and AUTHENTICATED roles only View published content, add more permissions only if NEEDED.
  • Only Developer/SuperAdmin roles should get any permission that stats with "Administer”
    • (Possible) Exception. You might give EDITORS "Administer” for: Blocks, Comments, Menus.
  • Contrib Modules for fine grained permissions:
    • Override Node Options,
    • Role Delegation
    • Field Permissions, etc.

Properly Configure Filters

NOTE: Tailor the following to the needs of your site - not all sites need such strict rules in place.

  • Drupal.org Guide to Configuring Text Formats
  • Do NOT allow these tags: SCRIPT, IMG, IFRAME, EMBED, OBJECT, INPUT, LINK, STYLE, META, FRAMESET, DIV, SPAN, BASE, TABLE, TR, TD
  • ORDER of Filters (plain text for ALL at TOP)
  • Filter Permissions (limit ANONYMOUS & AUTHENTICATED to plain, give EDITOR basic)
    • More filters details in the Contrib modules section below.

Contrib (Third Party) Modules and Themes

  • Disable or un-install modules you are not using (UI & Devel modules, like Masquerade). Regularly audit sites for unused modules.
  • Criteria for evaluating contrib (Erik Webb):
    • supported version(s)
    • maintainer reputation
    • total usage
    • number of open issues
    • usage change over time
  • Criteria 2: allows PHP execution? Some modules that do are: Devel; CCK fields; Views; Webform

Contrib: CAS and Captcha/Spamicide

  • For GTaccount holders, CAS module (requiring GT Logins for certain pages/forms) will usually be sufficient to protect individual content types/forms
    • admin/config/people/cas
    • Redirection > Specific pages
    • If ANONYMOUS users can Add content or can Login, MUST HAVE Captcha + Spamicide
  • Helpful Tool: StopSpamForum.com (esp if you Block IPs in your Drupal site).

Contrib: Editor and More Filters

  • Because user content is dangerous, pay attention to settings for editing and file uploading modules.
  • Who can use IMCE to add files/images & which file extensions are allowed? (profile)
  • Who can use LinkIt to make a Link? (profile)
  • Use WYSIWYG Filter to strip out unwanted code
  • Limit buttons on CKEditor Toolbar
  • Use Plain Text for ANONYMOUS users and on most TextArea Fields.

Contrib: Field Permissions and Privacy

  • Create unique names for every field that holds remotely-sensitive info. Why? Because permissions are by FIELD NAME regardless of content type
    • Example: field_user_address, if used on 2 different forms, has the SAME permissions on both forms.
  • Tip: Use bundle_copy module to make a generic Content Type with pre-set fields & display settings that’s easy to alter & copy.
  • Types of data NOT to store and NOT to share:
    • FERPA student data not in directory (directory = name, email, field/dept)
    • HIPAA health-related
    • Identity theft-prone (SSN, Birthdate, etc.)
  • Types of permissions for fields and content types:
    • create
    • edit OWN; view OWN (might be safe)
    • edit ANY; view ANY (editors or admins only)
    • delete OWN; delete ANY (be careful, admins only)

Contrib: Webform

  • http://drupal.org/project/webform
  • NOT good at fine-grained permissions
  • Can have PHP execution vulnerabilities
  • You have MUCH better better access control & reporting options (Views), if you use Content Types, instead.
  • Content types are Safer, but harder to delegate to editors for set up.

Contrib: Views

  • http://drupal.org/project/views
  • Very popular, will be Core in Drupal 8.
  • Allows you to report out on data in LOTs of ways
  • Must take care with PERMISSIONS, esp by Role, for each View, esp if any data is private or sensitive.
  • Be careful not to allow PHP in arguments, unless necessary.

Contrib: Pathauto and Auto Label

External Libraries and Code

  • SUGGESTIONS requested. HOW Can we: ?
    • Regularly check libraries for security notices (CKeditor, phpCAS, jquery.cycle, etc.).
    • Audit 3rd party code for security holes (such as superglobals like $_GET)
    • Audit libraries’ example code or other 4th party included packages.
    • Discover unneeded code to remove from libraries (and, of course, notate in README.txt file)

Editor Support

  • Training, especially security implications of:
    • forms
    • comments
    • file types
    • tag choices in HTML
  • Regular audits of content + users
    • every semester
    • less files/revisions/people to look over if hacked
    • less chance of un-used file/account being co-opted

Server and Monitoring

  • Not a good use of time to try to hide clues that a site runs on Drupal (http://drupal.org/node/766404)
  • Robots.txt (only works on good search engines)
  • .htaccess (can limit to on-campus or VPN access, Drupal already hides directories)
  • use HTTPS, instead of HTTP
  • Securing file permissions and ownership (settings.php, etc., http://drupal.org/node/244924)
  • Regular BACKUPS (and diffs for comparison)
  • Avoid installing multiple applications on same hosting account (i.e. Wordpress AND Drupal)
  • Avoid storing ANYTHING other than the Drupal install in the web ROOT (httpdocs).

References