Thursday 28th January 2010 by Mark Sutton

Securing mod_php – without the vasectomy

In it’s most typical setup, Apache 2/mod_php is not secure enough for shared virtual hosting.

With the typical mod_php setup, a rogue webmaster or bug in a single PHP script could compromise every script and configuration file for every site hosted on the server, no matter how security conscious the developer.

So what would happen if a rogue webmaster on the same shared server discovered your database credentials..? What if they were really malicious and went further, posting your valuable data online or even selling the information to a competitor? I’ll leave that answer for you to work out.

In this article I will explain why the default Apache 2/mod_php setup is so insecure, and then go through the various methods that can be used to make it better.

The Problem in a Nutshell

In the standard Apache 2/mod_php model (with the usually default prefork mpm), all sites run within the security context of the same user (apache, nobody, www-data, depending on your distro). This model gives the best possible PHP performance in all possible use cases, hands down, but it also means that assets and code belonging to one site are fully readable from adjacent PHP applications.

Chrooted FTP won’t help you either. It might look secure from the comfort of your FTP login, but that doesn’t mean your PHP code has the same view of the system during execution. In fact I’m quite sure that for the majority of sites using shared hosting based on mod_php, it doesn’t.

Security through Obscurity

There are various ’soft’ methods used by many shared hosts in an attempt to lock down PHP; but in my opinion, none of these can really be considered “secure”. Security must be enforced from outside the PHP context otherwise you’re just playing whack-a-mole.

PHP’s safe_mode and open_basedir are the devils I speak of, but herein lies the PHP vasectomy. Just look at that list of things you can’t do with safe_mode enabled. Besides, safe_mode is deprecated now, and will go away altogether in PHP 6.0.

Open_basedir, another “soft solution” provides some additional protections but again it’s whack-a-mole, not security.

Some hosters attempt to secure their servers by implementing an obscure filesystem structure that attempts to obfuscate the path. But back in the real world any person with ability to upload/execute php code can brute force past this in no time at all.

The bottom line is, security through obscurity should never be an option – especially since options are available.

Securing PHP the expensive way…

First there was the dedicated server, then the virtual private server. Then came the virtual machine, aka ’slice’ or ‘instance’.

All of these do an excellent job of providing a partitioned security model that protects one application from another. Simply host one site per instance and each is secured from each other.

Bear in mind however that for the vast majority of small/medium sites these solutions are also overkill, inefficient with resources and downright expensive.

Securing PHP the shared way…

Securing PHP in a shared hosting environment is certainly possible, but it can only be done by the web server operator.

The basic model in securing the server is to force PHP (or any application in fact) to execute within the context of a dedicated user account which has the minimum privilege required to read files belonging to it’s designated site, but not enough privileges to see or otherwise interact with other files on the system.

Extra points can be awarded for creative filesystem permissions that keep adjacent usernames invisible too, though this is more cosmetic than anything and not really about security.

The methods available break down into two main classes - External execution and Internal execution. Each method makes it possible to provide a truly locked down PHP execution environment for each site on the server; but as you might imagine – each one comes with a cost. You didn’t think security would be free, did you?

External execution options

External execution is the method used by most (non-Apache) web servers to provide support for PHP. Apache supports these methods as well, with each providing a valid framework for locking down PHP.

• SUEXEC – Performance is extremely poor, beyond abysmal in fact. SUEXEC combines CGI execution with a change of user, creating a fresh PHP process for every single request made to the web server. Expect high load averages, slow request rates and significantly reduced server capacity as a result. Also expect less that 100% mod_php compatibility, since you are not really using mod_php, but php-cgi instead.
• FastCGI enables external execution like SUEXEC, but with process reuse. This negates most of the performance hit of SUEXEC but again uses php-cgi so is not 100% mod_php compatible. FastCGI can also be quite resource-wasteful in the special case of mass vhosting of many small web sites. This is due to each site having persistent processes, instead of sharing resources in a pool. With FastCGI, the number of worker processes must also be managed carefully to meet changes in load demand. In short expect lots of work, and lots of pain, for reasonable gain!
• SuPHP is somewhat like SUEXEC but using a modified mod_php Apache module which is probably 100% compatible with mod_php. This offers a middle ground between SUEXEC and FastCGI, and is a reasonably popular choice amongst shared PHP hosting providers.

Internal execution options

These options are very specific to Apache 2, as they require swapping the multi processing module (MPM) inside Apache itself. This can be extremely flexible as it keeps the resource management and worker pooling inside Apache – where it naturally belongs.

• MPM_peruser provides the best possible performance, by creating a seperate pool of worker processes for each vhost, and enabling worker reuse within each pool. It provides 100% mod_php compatibility too. Where it falls down is with mass vhosting, running hundreds of low traffic sites on a single server is going to tie up a lot of system resources.
• MPM_itk is 100% mod_php compatible, and provides a single pool of workers able to switch user and handle requests for any vhost on the server. This makes it more efficient than MPM_peruser in a mass vhosting scenario. To improve performance over SUEXEC/SuPHP, it doesn’t execute a new process for each process, instead using system calls to change the “effective” user id before passing the request on to PHP. The major downside is that the worker pool must have root system privileges until a vhost can be selected to serve the request. I will discuss the issues raised by this in another blog article, but it’s worth saying that this is usually frowned upon with good reason.

Conclusion

With so many options available it can be quite difficult to choose between them. What I can tell you is that we chose MPM_itk and it has worked out remarkably well for almost a year now, serving millions of pages and Terabytes of outbound data transfer per month across hundreds of sites, with very reasonable resource usage and fast performance.

By offloading static content to differently configured apache servers (again, running an alternative MPM, but that’s another article too) we’ve more than recovered any performance lost in the switch to MPM_itk.

If you are running a smaller number of busier sites then it’s probably worth checking out MPM_ peruser. With per-vhost worker pools and process reuse you’ll definitely see performance gains.

If these aren’t an option then SuPHP gives 100% mod_php compatibility at the cost of performance. SUEXEC and FastCGI, in my opinion, are at the bottom of the pile when it comes to PHP.

Of course, don’t forget that none of this helps if you haven’t locked down the rest of the OS running your web server. And if securing servers isn’t your bag but making successful web sites is – then perhaps vCluster is the way forward for you.

I’d love to hear your opinions, especially if you think I’ve missed anything…

Apache performance php scalability Security

Posted in Security, Servers