Question

I have shared hosting, and within my own user space I run three different .com domains. One serves as the actual hosting plan master domain, and the other are subs via URL redirects and domain pointing.

One of those subs is a WordPress blog, and I’m concerned about the ability of an attacker to use security holes in WordPress to access the other sites under my virtual umbrella. If the blog itself gets trashed, I’m not going to lose any sleep over it. But if the other sites get nailed I’ll be a pretty sad panda.

What sort of server permissions and such can I use to isolate that blog? It’s entirely contained within its own sub-directory.

More details can be provided if needed, I’m new at this and may have left out some key info.

Thank you.

Answer 1

This is a valid concern. If not properly separated a vulnerability in one site will affect all of them.

1) The first thing you need to do is to use suPHP, which forces an application to be run with the rights of a specific user. This user account should not have shell access (/bin/false).

2) All three application directories need to be chown user -R /home/user/www/ and chmod 500 -R /home/user/www/ The last two zeros in the chmod means that no other accounts have access to the files. This only provides read and execute rights, it is ideal if write privileges are disallowed for the entire web root.

3) All three applications must have a separate MySQL database and separate MySQL user accounts. This user account should only have access to its own database. This account should not have GRANT or FILE privileges. Where the FILE privilege isby far the most dangerous privilege you can give to a MySQL user account because it is used to upload backdoors and read files. This protects against sql injection in one site allowing the attacker to read data for all sites.

After these three steps are taken if 1 site where to be hacked the other 2 will be untouched. You should run a vulnerability scanner such as Sitewatch (Commercial but there is a free version) or Skipfish (Open Source). After scanning the application then run phpsecinfo and modify your php.ini file to remove as much Red and Yellow as possible. Modifying your php.init can fool vulnerability scanners, but often times the flaw still exists to make sure you patch your code and keep everything up to date.