Add to Favorites

apache/php security among shared hosts

Security

Security is on everyones mind these days. In a shared hosting environment it's crucial to configure your servers with maximum security, especially when credit card data becomes involved. Many sysadmins leave the default setup on many apache servers, to run php as mod_php and apache as a separate user from root. They get only part of the security mindset correct, running apache as a non-root user, but they leave off a major component of security.

When apache runs php scripts underneath mod_php, it will execute the php scripts with the permissions of the apache daemon ( whatever user/group you have setup apache to run under ). For many, this leaves an open security hole where one shared account can access any file under an entirely separate shared account, a major problem. This happens because with the elevated privileges of the apache user, the php scripts can read whatever apache can, which in most cases means that the php scripts have access to the direct files for another shared account's web root. Problems can arise from other php scripts on the server snooping into other user's directories, perhaps even the php files that store the database connection strings giving someone else access to private database information. Another problem exists when the user has a writable directory with apache's group/user, apache will be able to write to these directories, and therefore php will be able to write to these directories. This means that if a single shared account becomes compromised by a poorly coded php script that allowed some executable code to get uploaded to a directory, any or all other shared accounts could be compromised as well.

Now that I have your attention, you may be wondering what the solution is to the above problem. Well don't worry, there is a solution for you. You can use suphp, a project that helps sysadmins insure that individual's php scripts are run as the individual's user/group. The main hesitant here is that your php scripts will be run as cgi instead of directly from apache's core, causing a little performance decrease, but that is usually how it goes, giving up performance for added security. There is another method however, that will not be as much of a performance drop. If you setup apache/php with suexec and fastcgi, your php scripts will run faster than cgi but still not quite as fast as they do under mod_php.

Resources and information about installing and setting up suphp or suexec and cgi/fastcgi are widely available.

http://www.suphp.org/Documentation-Installation.en.html
http://snippets.dzone.com/posts/show/81
http://www.phpfreaks.com/apache_manual/page/suexec.html
http://blog.stuartherbert.com/php/2007/12/18/using-suexec-to-secure-a-shared-server/
http://archiv.debianhowto.de/en/php_cgi/c_php_cgi.html

Comments

timcharper
01/29/2008 12:51am
This is really great security. When I deploy Ruby on Rails (even though it's not a shared host), I always deploy using suexec. Way to keep on top of the ball!
01/29/2008 10:30pm
I had a 3rd party php application (TNG - the next generation) get hacked recently and it went farther than it should have because of this very problem. Thanks for the heads up.

Leave a comment

To leave a comment, please log in / sign up