A Homeowner's Guide to Drupal Security

October 13, 2017
blog author


MS Drupal Developer

Working in our Managed Services department, we handle many Drupal 7 and 8 sites - all of which have one thing in common. Despite their different requirements, designs and content - they all need security updates applying and are all in need of some care and attention when it comes to securing them.

If a Drupal site was a house:

  • Security updates would be regularly checking the doors and windows, to make sure they still shut properly and there’s no new issues found with your cat flap that might leave it wide open to abuse from the outside world.

  • Securing the site would focus more on checking who has keys to your doors, who you let through the front door and how you store all your personal information (do you leave it outside in your mailbox or do you secure it away in a safe in the basement?)

Here’s 5 things I like to apply to any Drupal site that comes my way… security is something that - as a team - we take really seriously.

  1. Sanitise Personal data
    Inevitably, we need to run 2-3 development versions of a site, so we can run QA, UAT and development work on a close to live, working copy of the codebase. When we copy a database from Production, it’s best practice to remove all personally identifiable information and sanitise the data we receive, whilst still having a realistic copy of the data.

    We have one great tool at our disposal for sanitising the database - which is sql-sanitize. In its simplest form, running

    drush sql-sanitize

    in a drupal directory with drush installed, will prompt you to enter ‘y’ to replace all the passwords with the word ‘password’ and change all the email addresses to be user+id@localhost.localdomain. You can make this a bit more advanced (especially in an automated script) by running something like

    drush sql-sanitize –sanitize-email=“fakeemail+%uid@localhost” –sanitize-password=“test123”

    to select a password and email address format of your choice.

    You can extend this even further by using hook_drush_sql_sync_sanitize to update other fields such as twitter accounts, webforms, names, LinkedIn etc with sanitised patterns that mask user identifiable content.

    It’s probably worth noting - never ever run sql-sanitize on your production server… or you’ll be getting a lot of frustrated users contacting you for passwords…!

  2. Admin usernames and passwords
    For each dev environment, it’s good to have a different password - or at least a different password from the production site - this helps prevent accidentally logging into the production site and making changes you’re not intending to. Again, there’s an easy way to change passwords in drush and it’s well worth getting into the habit of doing so, to change our appnovation-admin user* it’s:

    drush user-password appnovation-admin --password="Nice*Secure&Password4Here"

    It’s also a great idea - if you can - to rename the admin user to something other than admin. When it comes to brute force attacking a login of a Drupal site, knowing the username is admin makes hacker’s lives a lot easier than the admin user being named something they can’t easily guess. (*oh and, we don’t actually use appnovation-admin as a username on any of our client sites…!)

  3. Backup
    Before doing anything potentially destructive to a site, it’s best to back things up and store them away from your production site and somewhere nice and safe.

    Drupal has an amazingly simple tool for backing up - drush archive-dump or ard for short - and it definitely takes the ‘ard work out of backups.

    Running ‘drush ard’ in a Drupal directory will backup code and database and store it somewhere away from the root of the site. This can be built on easily using a simple bash script and cron to create a copy of the site every night with a date-stamped file name - which you could then store offsite or on another server.

    If you do get hacked - knowing you have a working copy of the site to fall back on is incredibly helpful.

  4. Keep Drupal Core and Contributed Modules Updated
    To jump back to our house analogy, if I told you your front door had a crack in the window that a passerby just needed to press on to make it shatter and give them access to your home - you’d probably replace the glass, pretty quick.

    In a similar way, security updates are released regularly - generally on a Wednesday evening in the UK - and it is generally a quick and painless task to update your modules and keep your site safe. (Although, be warned, sometimes there are knock on issues when upgrading modules - so always backup and always run a full regression test before pushing the changes to production.)

    To make things a bit easier, you can run some drush commands to check what updates there are for your site. Running

    drush pm-updatestatus

    will tell you what needs updating. In the MS team, we’re developing a great automated tool for this - which automatically applies any security updates to a copy of the codebase and lets the QA team know there’s an update that needs checking. This is just one way we seek to proactively help out our clients.

  5. Build your house on solid ground
    I’ve talked a lot about Drupal itself - but you also need to keep an eye on the servers your site’s installed on - if they’re at risk, your site will be too. Here’s a few ways I like to lock things down:

    1. Keep your server security patched
      This is vital - if you leave things to rot, there will be holes that can be exploited.

    2. Firewall off SSH access, or change the port number
      To stop hackers being able to brute force attack your server by ssh - it’s good to limit the IP addresses that people can login to ssh from. If that’s not possible - due to lots of remote access - then change the port from 22 to anything else.

    3. Limit HTTP and HTTPS traffic to the IP addresses of your CDN / Load balancer
      Load balancers are there to do just that - balance the load to your web servers and CDN products, such as Cloudflare, are there to reduce traffic (and, in particular, dangerous traffic) to your site. So it’s always good practice to only allow these IP addresses to hit your webserver. Failing to do so, is like locking your front door and leaving your side gate wide open.