Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Back story: I was cleaning up hacked web space on a shared host the other day, and found a script in the web directory that allows the attacker to inject code into all php and html files in the web directory. It had access to everything in the web directory, but I'm not sure which user permissions the file had.

Question: I think it would be difficult to prevent a php script running on a shared web host from having access to other web files (php, html, etc), due to lack of server configuration options. Is there a way to configure a linux apache http server (where you have full root access) so that even if the attacker was able to upload a script like that to the web directory, it wouldn't have access to modify other files on the server?

share|improve this question
up vote 1 down vote accepted

At a bare minimum, you should:

  • Limit which web-accessable directories the webserver user has permissions to write to. (or not at all)
  • Don't process PHP, CGIs or any other scripts in directories the webserver is allowed to write to.

suPHP and the like aren't as useful for this sort of problem, as changing the user that the PHP scripts run under often then gives them access to write to places they shouldn't be ... the only way around it is to manage even more users (one set that the webserver uses, one set that's allowed to update files), and you lose one of the main advantages of being able to have it test that the file ownership is clean before running the script.

share|improve this answer
in the case of shared hosting, where you don't control all the content, etc.. making php run as the user, and preventing 777 perms allows the customer that uploads vulnerable php code to own them selves, and not everybody on the server. – Doon Sep 13 '11 at 19:10
@Doon : once someone gets a foothold on the server, unless you're 100% sure that there aren't any locally exploitable root escallation exploits, it's basically over. You've lost as soon as they manage to get a file on your system and execute it, as you have no idea what they've managed to do or not, and you have to wipe the machine and re-install to a clean state. – Joe H. Sep 13 '11 at 22:11
All non User/Non log data on read-only filesystems. plus MD5s of all binaries. making php run as the user, generally compartmentalizes the damage to their account. Most of the stuff we see is hosting of files for phishing exploits. – Doon Sep 14 '11 at 2:47

A short answer is yes, sure. As soon as you have root access you can protect your source files from modifications by Apache user. But if your software relies on such modifications (for example, if a .php config file should be editable from the web app) it won't be possible to prevent Apache user from modification of your source files without stopping your app to work as designed.

And I bet the problem is in your FTP/SFTP client configuration, not in your shared hosting Apache server configuration. I think your PC was trojaned and a trojan app uploaded malicious code to your account using your credentials from your FTP/SFTP client. This is quite common these days.

share|improve this answer
Obviously ftp logs are subject to alterations, but they don't show any activity when the script was uploaded, so I think the script got on there through other means. – JMC Sep 13 '11 at 17:48

my favorite module to compile in to allow apache to run as a different uid/gid per vhost is itk.

It's pretty new so generally it's not compiled in by default. It's faster then like suexec or phpsuexec. You config a vhost entry to run as a certain user. Then you can chmod the webroot of each user to like 700 so only that user can get in there.

You can then run a module like mod_security to help stop sql attacks

share|improve this answer

Install something like suphp.

And then check the server all the time, to make sure none of your users does something silly like chmod 777 their directories..

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.