Keeping your Drupal site up to date has always been of critical importance to ensure it remains secure. Last month’s announcement of a SQL Injection vulnerability and subsequent announcement of automated attacks within 7 hours caused wide spread panic across much of the Drupal community.
Here are eleven tips to ensure your modules and core code are up to date with the latest security releases.
1. Follow security news
If you are not already following Drupal security news, it is time to start now. This is how you get alerted to security updates as soon as they are announced.
You can get security advisories from these places:
- Email list – log in to Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.
- RSS feeds: core, contribute, public service announcements
2. Check update report regularly
The update report (available here: admin/reports/status) will alert you to problems with your Drupal site, including security issues such as out of date modules, Drupal core or database updates that need to be run.
You can get notified when updates are available by adding your email address here: /admin/reports/updates/settings
Pro tip: for performance reasons, it is better to have the Update Manager module enabled and running on a dev or staging site than the production site.
3. Apply security patches asap
When a security update is announced, apply it as soon as it is humanly possible. In the past, we had a day or two to apply updates and still be safe. With larger companies, deploying an update needs to fit into a regular deployment timeline, so it could take many days or even weeks. That didn’t used to be much of a problem. It is now. The first known attack following the Oct 15th security advisory happened within 7 hours. This meant that you only had 7 hours to update and be safe from potential attack.
So be ready every Wednesday. I’ve put a recurring task in my todo manager for every Wednesday.
4. Use Drush to update.
You can download Drupal core and modules from drupal.org and manually apply them to your Drupal codebase. This gets tedious very fast. To make this a painless experience, you can use a couple of Drush commands instead.
###Check what has changed
pm-update –pipe (alias: up –pipe) – lists projects that need to updated. You can then go and check the release notes to see what has changed.
Run the updates in one step
drush pm-update (alias: up) – update Drupal core, modules and themes and run any pending database updates
Run the updates in two steps
If you’d rather not run pending database updates at the same time as updating the code, you can run these two commands instead:.
- drush pm-updatecode (alias: upc) – Update the code
- drush updatedb (alias: updb) Run the pending database updates
You should not run these commands directly on the production site. Instead, run them on your local version (or another dev version) and ensure nothing breaks before applying to the production site.
5. Don’t hack contributed modules or core code.
It maybe quicker to make changes to contributed modules or Drupal core, but this leads to a long term nightmare for keeping your core base up to date. If they are left untouched, upgrading is a painless experience. If they have been altered, you will lose any changes when you upgrade that you will need to re-apply.
6. Check if your contributed modules or core code have already been hacked
If you didn’t develop the site yourself, you may not know if someone else has hacked contributed modules or Drupal core. Fortunately, you can easily check by using the Hacked module.
Hacked is a great utility module which will check if your contributed and core modules have any differences to what is stored on drupal.org. Checking this will see if anyone has meddled with your code.
7. Create patches for hacked contributed modules or core code
If, after running the Hacked module, you discover that someone has altered contributed modules or core code, then it is best to store these changes in a patch file. Then when you need to update your Drupal install, you can re-apply the patch file. This will save a lot of time as opposed to manually re-applying the changes.
8. Backup your database automatically
It goes without saying that you should be running database backups automatically on a regular basis. For more information, check out my recent article on backing up to Amazon S3.
9. Check your backups are working
Automatic database backups are great, but what if they are not working? It is a good idea to periodically restore them and make sure everything is in order.
10. Have code in a version control system
Storing code in a version control system (such as Git) is great for a variety of reasons. When you apply security updates, you can see exactly what has changed if your code is stored in source control. This makes it much easier to ascertain the potential risk of the update breaking your site.
It also provides you with a method of checking if your site has been hacked because you can check for differences with the code stored in version control.
11. For clients: Pay for a quality security and maintenance contract
If you don’t have time or knowhow to keep it up to date and secure, seriously consider paying for a maintenance contract from an experienced Drupal consultant, or agency.
