Until recently our shared hosting servers suffered from some of the same vulnerabilities that many of the volume-based hosting providers do.  Namely, if one site on a shared server was hacked it was possible for the hacker to deface other sites on the same server that had files or directories with loose permissions.  I.e. 777 permissions.

Yep, even if you diligently keep your site and code up-to-date your site could still be hacked because someone else’s site on the same server was hacked.

Ugly, eh?

Read about this nastiness in action at Network Solutions, Bluehost, Dreamhost, and GoDaddy here:

http://gadgethubs.com/mass-shared-host-website-hack/

And Media Temple is apparently being repeatedly hacked.

One of the nice things about being small is that we can implement new technologies quickly.  So what did we do?  Some hosters have chosen to use suphp to mitigate risks – so we took a hard look at that.  But after setting up a few suphp virtual machines for configuration testing we decided against it since it only protects php files and can create too many challenges for developers.

A half-solution that makes things harder on developers is about the last thing we want to do.

We also seriously considered migrating all of our 800+ hosting accounts to their own mini-virtual servers.  There were some serious drawbacks to this as well – namely time, migration issues, and IP addresses.

Fortunately, Chris Batis, the lead TaosNet Sysadmin, showed us an Apache module called mpm-itk.   It turns out to be a nearly perfect solution.

It works like this: Instead of the normal set up where Apache runs as a single user for all web sites – the crux of the security problem – mpm-itk allows us to run each web site as an unique user, which opens up all sorts of geek-tastic-ness for us.  First, we were able to change the ownership of every file on each web site to be owned as the same user and group as the site’s own Apache user and group.  This then allowed us to change every file’s permissions so that the files aren’t readable, writeable or executable by any user outside of the sites own user and group  i.e. If site A get’s hacked the hacker has no way to see the files in site B, much less modify and hack them.

Here’s what the permissions might look like on one of our hosted sites:

-rwxrwx---  1 securesite.net securesite.net   86 Jun 25  2009 filetwo.php
-rwxrwx---  1 securesite.net securesite.net   97 Jun 25  2009 fileone.php
-rwxrwx---  1 securesite.net securesite.net  517 Jul 14 14:55 upload_script.php
drwxrwx---  2 securesite.net securesite.net 4096 Jul 14 14:36 uploads
-rwxrwx---  1 securesite.net securesite.net  628 Jun 25  2009 somefunctions.php

Uber-geeks may have already discerned a great added benefit of mpm-itk; there’s no longer a need for developers to “chmod 777” directories or files that the web server needs to write to.  i.e.  No more permission denied errors from the web server, no more changing permissions, ever.  Your web site can write to the same files as  your FTP account and vice-versa.  Smooth baby, smooth.

We’ve been running mpm-itk on all of our web servers for the last two weeks and have been very pleased with the speeds and protection it provides our customers.

We’re more secure than ever, easier for developers to work with, and continue to stay one step-ahead of the mass-hosting providers.

And as always, if you have more questions, or don’t understand how this works, feel free to ask in the comments below.

Thanks,

~ Oban