With the imminent release of a Drupal 8 Release Candidate, which could potentially be announced as soon as the end of September at Drupalcon Barcelona, the clock has just started ticking a lot louder for those sites still on Drupal 6 with the looming Drupal.org support transition policy about to kick in:
Drupal 6 core and modules will transition to unsupported status three months after Drupal 8 is released. "Unsupported status" means the community will not be providing support or patches in the same way we do now.
- drupal.org
If a similar timeline is followed, as Drupal 7 had from Release Candidate through to Full Release, then this realistically means that Drupal 6 (and Pressflow 6) will be lucky to be considered supported by the time that we are shaking off our New Year's hangovers. Not an ideal situation for Drupal 6 site owners to find themselves in.
So what can you do if you're sitting on a Drupal 6 site?
- Stay on Drupal 6 - The latest usage statistics suggest that you're in the same boat as nearly 130,000 other site owners, so it is probable that security patches and bug fixes will still surface on drupal.org in one way or another beyond the official support period, while there are parties interested in prolonging the life of Drupal 6.
- Upgrade to Drupal 7 - The safe bet would be to start planning how you are going to take advantage of the continued support from drupal.org by upgrading your site to Drupal 7 now -- but how? via the standard upgrade path, or by a re-build?
- Upgrade to Drupal 8 - If you've stuck with Drupal 6 for this long, the opportunity to bypass any talk of a Drupal 7 to Drupal 8 in a few years time would probably appeal to you, so why not leap on to the bleeding-edge of technology, and go with Drupal 8 now and then stick with it for the next decade! There are even tools in the works to help you make the jump directly!
All three options have their merits, it just all depends on how much your are prepared to invest, wait, or how much risk you are prepared to take.
Knowing that nothing paints a picture quite like a graph with a subjective hyperbolic axis; here's our attempt at conveying the options that are on the table for Drupal 6 site owners:
Obviously staying put on your existing Drupal 6 implementation is going to be the cheapest option, with Drupal 8 being the most expensive as it will be a learning experience for any developer that works on it in the early days, with no small amount of time battling against a more limited set of module options that are likely to be littered with bugs initially. The risk graph above, was trying to illustrate that the risk of staying on Drupal 6 is high as it slips out of the official support period, while moving on to Drupal 8 before it is deemed a robust platform comes with its own set of risks (e.g. stability of platform, limited set of available modules etc.). If a time factor could be applied to the risk graph, then the risk of moving to Drupal 8 would obviously degrade as time passes by, and Drupal 8 matures.
What it boils down to, is that if you are risk averse, and are prepared to invest, the safe option is for you to upgrade your site to Drupal 7 as soon as you can. For those of you that are more gung-ho, you could sweat your existing Drupal 6 platform for a while longer, riding the risk of being on an unsupported release, and hang on long enough until Drupal 8 is considered robust enough before going ahead with the upgrade.
The Zoocha approach for upgrading from Drupal 6 to Drupal 7
If after weighing up your options you decide that upgrading to Drupal 7 is the prudent thing to do, then we have a straightforward, sensible approach that we have developed over the years that we would like to share, that will hopefully put you on the right path and save you time and money during the upgrade process. Depending on the complexity of your Drupal 6 site, there may even be time to upgrade to Drupal 7 before the official support period expires.
In our approach, the first thing we would recommend doing before a line of code is written, or an upgrade path is launched into, is to perform a Drupal audit and evaluation of the existing Drupal 6 site. We suggest doing this as it tells you if:
- There are any contrib modules without a clear upgrade path to a D7 version.
- The volume of custom code, technical debt, and level of re-factoring, that will be necessary to upgrade the code to be compatible with D7 will be a problem or not. This goes for both the theming layer and custom modules.
- Drupal core, or any contrib modules have been patched, or modified in any way beyond their original versions. If they have, then this is another problem to contend with.
- The information / data / content-type structure is sound, and how / where it is stored.
- There are any integrations worth paying heed to, and giving special consideration.
- The code is locked to an older version of PHP, through use of functions that have been deprecated in recent versions of PHP.
- How the content is surfaced to render the pages (through Views, Panels, Blocks etc.).
- The theming layer is locked to an old version of a front-end framework without a clear upgrade path.
With this information known, along with any planned roadmap functionality considered, a balanced assessment can then be made as to whether it will be more cost-effective, with reduced risk and a better end result, to perform a re-build of the site in Drupal 7, rather than perform a standard upgrade. What you can also think about at this stage, is to see if there are any possibilities of compromise in terms of functionality, or improved module selections that can be made, such as calling upon some of the newer Drupal 7 only modules like Paragraphs and WorkBench, so that budgets and timelines can be met. At this point we would generally recommend producing an options appraisal that lays out in plain language what are the pro’s and con’s of each approach are, so that business owners can make an informed decision about where they want to take their platform / site.
Drupal 6 Upgrade - make sure that you script it!
If after performing the evaluation it appears that an upgrade will be possible, and is the more attractive option to the site owner, then we would generally advise that the upgrade approach as detailed on drupal.org is followed. However, for non-trivial sites, we would advise against performing these steps manually, and instead encourage you to try to capture the upgrade process in code, via a bash script making use of Drush, and php where necessary. The reason why we suggest this is so that when you are developing locally, you can at any point bin your current attempt at an upgrade, and start again at any previous step, or alter the order in which you do things simply by re-running the script. On non-trivial sites, this can save you a great deal of time, and also makes it much easier for other developers to pick up where another left off, let alone the efficiencies gained when it comes to dealing with content-freezes and pushing the changes live. When the upgrade script is ready to go, it's an undeniably satisfying experience watching your terminal shell hammering through the script, with a shiny new Drupal 7 site coming out the other side!
One type of requirement that can often tip the balance in favour of the re-build approach, is that of a new mobile compatible, responsively designed theme. If your site is of any level of complexity, trying to upgrade a Drupal 6 non-responsive theme, whilst maintaining the site branding and design, to become a Drupal 7 responsive version is something that should not to be approached lightly. In cases like this we would always recommend using a new Drupal 7 starter theme (such as Bootstrap), and then using that as a basis for a refreshed design -- a Drupal themer experienced with Bootstrap would be able to create a new theme for a site using this method in about half the time (typically) compared to upgrading an existing Drupal 6 theme to the same responsive standard.
Re-build of a Drupal 6 site in Drupal 7
If a re-build in Drupal 7 is decided upon, then I'm sure we all have a favoured development process that we go with in the construction of a new site. If however you are inexperienced with Drupal 7, then it would make sense to engage a Drupal 7 specialist to help validate your architecture, approach and plan, and act as a sound board throughout development.
The final step that we would recommend undertaking in any upgrade or re-build, would be to verify that no content has been lost/corrupted, and all key user journeys and functionality operate correctly. There are quick ways of doing this, and not so quick, but we'll save the 'how' on this for another post.
What can you do to protect your site, come Drupal 6 support retirement day?
If you decide to stay on Drupal 6 (and hang on until Drupal 8 matures enough before trading up), it's time to batten down the hatches folks! Maybe that is being a bit dramatic, as if you look hard enough you'll find sites running Drupal 5 out there still doing a job. If a Drupal upgrade is out of the question, then now would be a good a time as ever to make sure that you are doing all that you can to protect your site via other means from the dark forces at work online.
The main thing that you can do to protect your site is to review your Drupal configuration against best practices, evaluate your current hosting / infrastructure and make sure that it is as secure as can be, and be vigilant in terms of monitoring, with a plan to revert to backup should something go wrong. In the unlikely event that another SQL injection compromise in Drupal core is discovered akin to the recent 'Drupalgeddon' vulnerability, then there is very little you can do to counter this, short of wait for a fix to surface on drupal.org and to apply it as quickly as you can.
At the server level there are several mitigations that can be made (hat tip to mig5 for some of the suggestions that follow), along with Drupal practices that you can employ that will collectively go a long way to protecting you in the post Drupal 6 support era, even if your site is running modules that are technically deemed insecure. The following list is by no means exhaustive, applies to any version of Drupal, and would be a good starting point for you to measure your infrastructure and Drupal configuration against:
1) Maintain regular backups
The most important thing you can do is to maintain regular backups of both the Drupal codebase, user files and database. If something then goes bad, or a compromise occurs, then you can revert to the last known safe backup (on entirely new infrastructure if needs be). Just make sure that you keep your back-ups on a different server to your production box.
2) IP Restriction
If practical, restricting access to your Drupal administration area (/admin) by IP address (or range) is a highly effective way of cutting off external access to the admin UI. This wouldn't stop a privilege escalation exploit in Drupal, but it could still protect access to those admin areas, which would be re-assuring to have in place in the event of an admin password leak for instance.
3) Update core and contrib modules
Make sure that you keep your Drupal core and contrib modules up to date, until drupal.org turns off the taps. When they finally do, then you will want to make sure that you are on the latest version of everything where possible, libraries included.
4) Stay on top of your server updates
It's all too easy to fall behind with your server software updates if you are managing them yourself / in-house. Try to at least once a week run the operating system software updates, and immediately upon a 'Heartbleed' esque threat.
5) Add a security certificate
If nothing else, it demonstrates to your users that you take security seriously, and prevents credentials any other potentially sensitive information being sent in plain text. Security certificates are cheap and easy to install, so there is no reason not to have one.
6) Ensure that you are not running an any standalone app's, or other sites within the Drupal codebase
It's more common than you think seeing a WordPress install or some such, nestled in the Drupal codebase (think drupal.xyz/wordpress/) that perhaps arrived there as a standalone marketing campaign and not touched again since it was hastily deposited there. This obviously leaves a potential security hole that you'll want sew up, so think about moving such invaders elsewhere, and configuring your web-server to handle their new locations.
7) Replace Apache/PHP with Nginx/PHP-FPM
Replacing Apache/PHP with Nginx/PHP-FPM, and using a 'hardened' Nginx config will provide several improvements to security, and even potentially increase the performance of a site. One of the ways it does this is by restricting the ability of the server to execute php files, so that you can give execute permission to specific named files only, such as index.php and cron.php. What this particular measure would do is protect you in the event that someone managed to get a malicious php file on to your server, and prevent them from ever been able to execute it. The other thing you should do here is turn off the core PHP module.
8) Information disclosure
The default Drupal codebase contains a number of innocuous files that give information away about the version of Drupal you are on, such as drupal.xyz/CHANGELOG.txt. Preventing access to these, or removing them altogether can make it more challenging for attackers to determine your configuration via automated tools. Also hiding information such as the version of PHP and other server side software / extensions that you are running will help too.
9) Install php5suhosin
Suhosin (pronounced 'su-ho-shin') is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against buffer overflows or format string vulnerabilities and the second part is a powerful PHP extension that implements numerous other protections.
- suhosin.org
Installing php5suhosin with the default settings will improve the overall security of your platform, but watch out for any undesired consequences of it being in place, such as POST request limits.
10) Install OSSEC + Anti-Virus
Installing OSSEC, even in standalone mode to monitor for intrusion attempts and unexpected changes to files, and potentially block them. OSSEC will then trigger alerts when it detects something amiss, such as:
-
rootkit and trojans (viruses)
-
alerting to poorly configured files e.g. files with insecure permissions
-
attempted brute force logins to any administration area
- other anomalies in the system (unexpected change in network services, logs generated by the applications that might indicate a problem e.g. syntax errors, resource issues).
We would also recommend implementing other rootkit and virus scanning software on Linux servers (such as RKhunter and ClamAV) to further augment the detection of malicious software.
11) Update the admin username
If you set the site administrator role to have a username other than admin, you will thwart the bulk of brute force attacks that assume this user exists.
Putting it all to the test
Once you are confident that you have made all the security improvements you are able to on your platform, then you should put it to the test -- one such tool that can help you here goes by the suitably scary name of Zed Attack Proxy which is an Open Source penetration testing tool:
The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.
ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
- owasp.org
Running ZAP over your site on a scheduled basis, analysing the results (including what your monitoring says) and taking any remedial action should give you confidence that you've done everything you can to secure your platform.
Hope you found this article useful, and please let us know in the comments if you spot any errors, or have any advice for Drupal 6 site owners that is pertinent right now, along with any recommendations about how such folk can protect their sites come the time when Drupal 6 is no longer supported!