Despite its many desirable features and continuing popularity, Drupal is not without its shortcomings, as many readers are also likely aware. Although Drupal has an active and responsive security team, the software has a long track record of requiring frequent security patches – Secunia has seven 2009 advisories for Drupal 6.x listed as of this writing. Although by its nature an apples-to-oranges comparison, this ranks Drupal behind similarly large and complex PHP projects such as WordPress 2.x (5) and Gallery 2.x (0) – and the number for Drupal does not include dozens of additional advisories for Drupal modules. Further, Drupal has struggled and lagged with support for PHP 5.3.x, suggesting to this outside observer that the project is having difficulties maintaining its codebase.

All that being said, I do not personally believe that the above issues rule out using Drupal; the benefits outweigh the shortcomings. So, assuming the question is not whether to deploy Drupal, but how to do so most securely and efficiently, my recommendations from a systems administration perspective are below.

Goals

The recommendations described stem from three goals for a Drupal installation:

1. Security – Avoid compromise of your site and system.
2. Flexibility – Create an environment that allows for easy modification of the OS, server and application, and provides for straightforward roll-back of those changes should those need arise.
3. Stability and Security over Performance – Although not mutually exclusive, designing for stability and security can entail trade-offs that may impact performance. I don’t directly address performance in these recommendations.

The below recommendations are written assuming that the sysadmin (you) responsible for the Drupal server and the developer are two different people. If you wear both hats, the recommendations can obviously adapted to fit your dual role.

Recommendations

1. Insist on the latest version of Drupal, and plan to upgrade as Drupal releases come out. Some developers may be hesitant to use the latest (stable) version of Drupal, but Drupal’s security track record dictates this; anything else is not serving the site owner’s interests.
2. Use the latest supported version of PHP. Drupal’s PHP version requirements are more brittle than most applications; the latest version of PHP is almost always the most stable and secure version. Combining the two is obvious: Aggressively track latest version of PHP that Drupal supports. Additionally, use the latest version of your preferred web server and patch as it is updated. Note that this implies a source-based installation of PHP and your web server instead of a package-based installation from your distribution. Carefully consider your build and deployment strategies with an eye towards reproducibility, documentation and ease of roll-back should a problem arise.
3. Isolate Drupal from other applications. Run Drupal on its own system – physical or virtual – and in doing so, reduce operating complexity while limiting collateral damage if your Drupal instance should be compromised. Depending on your backup strategy, don’t overlook the possibility that running a VM may have obvious recovery and forensic advantages over a physical install should your Drupal site get broken into.
4. mod_security – Consider integrating a “web application firewall” such as mod_security directly into your web server. Carefully evaluate the trade-off of additional complexity for enhanced security in your environment.
5. Deploy a host-based firewall for inbound and outbound traffic – This has two functions – prevent your server from being compromised through a hole in a service other than your web server, and limit damage to other systems if/when you are compromised. There’s a decent chance that the only external service you need exposed other than HTTP for your Drupal site is SSH for remote management – and you can probably lock that down to a very limited set of IP addresses. And, in the situation where your server is compromised, outbound rules can reduce the ability of your server to attack other machines: Consider, for example, the effect of an outbound rule on port 25 if an attacker attempts to use your compromised server as a spam bot.
6. Use SELinux – Security-Enhanced Linux provides a the ability to audit and possibly deny actions on your system through mandatory access control policies. You will likely want to run SELinux in “permissive” mode before your site is publicly available, at which point you would switch to “enforcing” mode; “audit2allow” and “audit2why” can be very helpful tools when developing policies. See “man selinux” for more information.
7. Use a Sysadmin Staging Server – The site developer likely has a staging instance of Drupal for testing out their code changes; deploy a similar environment for testing Sysadmin changes, such as PHP updates or the latest version of Drupal with your code. Consider using a software testing framework such as Selenium to automate the tests you run on the sysadmin staging site.