[Mike_FWT]

Our custom-designed hosting environment had a major issue this weekend when a hacker was somewhat successful in deleting a number of user sites using a special PHP program. Everything has since been restored, but it's obviously frustrating to have to take these drastic measures.

We've made the decision to re-remove PHP access (we had just recently decided to allow it again after putting in some safeguards - these were subsequently worked around by this &&&hole) and as much as we hate to, it's a necessary evil at this point.

Anyone have any suggestions/methods to safeguard PHP on a large shared hosting system? Our system is highly customized (without giving too much away) and unique traditional username-based methods won't cut it. I'd be interested in some of your experiences and/or suggestions.

Thanks in advance...

Anyone familiar with someone who goes by the name of "The Turk HaCKer" or "dodo885"? I'd love five minutes alone with that guy...

dodo885

[Odd Fact]

Search over at WHT. I remember one of the host developing a safe mode alternative. Might have been Affordable Hosting.

[Paul]

Hello
Here is a website with various ways to crash PHP:
http://ilia.ws/archives/5_Top_10_ways_to_crash_PHP.html
This proves that PHP is not safe straight out of the box. The shell_exec command looks extremely deadly and should definitely be disabled as it has the possibility to give complete control of the server to the user.

[JTY]

I would look into using safe_mode and setting open_base_dir.

[freerackspace.org]

Try employing a top notch admin to secure the box as much as possible, put creative limits on the PHP use, and hope for the best. Make daily, weekly and monthly backups to another location, so you can always do a restore.

[monoxide]

You need to disable functions in the php.ini and you need to install mod_security. This will stop most php hacks.

I hope this helps out.

Mod Edit: This forum is not for advertising/self-promotion.

[excelblue]

Use different accounts for different users and only allow that user to have read access. Then, create a group for each user, and set a vhost for that user to use the group. You'd have to deal with subdomains, but oh well, they don't cost anything, do they?