PHP Security In Virtual Hosting Environments

I'm sure alot of you out there have wrecked your brain when deciding on how to handle server side scripting language security. It seems to be the dirty little secret that no one discusses publicly, but admins really concerned about security need to start taking measures to avoid hosting clients from getting root on a box.

Of different webhosts that I've auditted, I've been able to leave home directories, read and write to other user's directories, access parts of the file-system that should not be accessible, and edit system configurations. This problem exists with too many webhosts out there. I'd like to start this thread to raise awareness, and to share ideas.

Does anyone here have first hand experience in securing a webhosting environment? Please share thoughts, ideas or experiences.


--PuRe

In my experience, which has been with a small base of users (around 30), I've done the following:

1: made sure apache (2.0.49 currently) runs under user nobody, group -1 (default).
2: made sure Indexes is off (this way no traversal of directories if no DirectoryIndex is found).
3: made sure SymLinksIfOwnerMatch is on.

Default apache configurations are pretty secure as a lot isn't allowed but there are some things that have to be changed to make it more secure (such as user directories to be read-only).

If I'm allowing anonymous ftp through a browser, then I make sure my users have a chrooted environment in a locked-down area away from regular public_html traffic. Those permissions are pretty strict, with a default setup allowing a user to upload a file (set to 0644) but not remove).
There's a lot better tutorials out there on default web security and chrooted anon ftp environments but these are simple enough to start with.

As for programming security, check everything. Every input field, every POST variable, everything. Double check for clarity and encrypt where you can (md5 is good enough, uniqid(md5($_SERVER['REMOTE_ADDR'])) is another good PHP encrypted identifier for session IDs, for example).

If it's perl, use the -w and 'use strict' flags...

And first and foremost, if anything's written by a user, double-check and triple-check and have a friend check as well to ensure the integrity of your system isn't going by the wayside, hehe.

Never trust user input. Ever.

1. Run Apache chrooted
2. Don't allow CGI
3. If you're allowing PHP, make sure it runs in safe_mode, and that pages in everyone's account are only allowed to access files in the same account.
4. PHP safe_mode is not watertight, so hope that people don't find or use holes in it

---

More rediculous:

1. Run Apache chrooted
2. Run a separate Apache for each user, and run it under an account that has some group membership which only allows it access to their account.
3. If needed, run an additional Apache on the front end to redirect requests to the right sub-Apache installations

Note that this will use a lot of ram for a lot of users.

Slarty

Wow, slarty, that's pretty secure, hehe...definitely following the security = 1 / convenience methodology! Good stuff though. Lotta ram usage, that's for sure.