The Current State Of Drupal — A Security Approach [Infographic]
A guest post by Appnovation
The Current State Of Drupal
Despite their different requirements, designs and content , all Drupal sites need security updates applying and are all in need of some care and attention when it comes to securing them.
Drupal Security From A Homeowner’s View
Originally published at www.appnovation.com.
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…!)
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.
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.
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:
- Keep your server security patched
This is vital — if you leave things to rot, there will be holes that can be exploited. - 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. - 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.
Author bio:
Appnovation is a global Digital Solutions and Managed Services provider delivering superior strategy, application development and enterprise integration on leading open technologies. Appnovation’s in-house experts build high-performing, secure digital experiences, while providing a full range of creative capabilities, coupled with 24/7 support and maintenance.
