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.
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/andchmod 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
GRANTorFILEprivileges. Where theFILEprivilege 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.
Depends on the hole attacker finds. If you use the same user/pass for all your databases, including the WP db, then that might be a problem. Of course, file permissions are an issue… anything available to be accessed by the web server can be read, and often written to.
There are a lot of security issues at play here, but if you use ftps, ssh and update WP when they release a security fix, then you lower your chances of problems. The most secure computer is encased in cement and sunk in the Mariana Trench. But it isn’t very useful. You are looking for a balance.
Chmod files 755 and know chmod settings to stay updated about classic problem: hacker getting a shell via uri query string due to a bug in perl, php or what scripting language used. Having a secure ISP like secureserver.net should live up to its name, staying aware of specific bugs in language implementation and choosing most secure available instead of most performance and reading insecure.org is what I do running all experimental and development stuff with secureserver.net doable with no security issue reported.