Text Size

A sphere within a sphere; installations within installations

It's common practice for developers to put test or new development sites in a subdomain. Most hosting control panels, notably cPanel, default the root directory of the subdomain to a subdirectory of the main site, so if I was going to create a "test" subdomain, cPanel will suggest "/home/youracct/public_html/test" as the root directory (youracct is the name of your hosting account). The problem is that these test installations are soon forgotten and can become a major security risk.

Let's say your client — let's call them client.com — finally has the budget to get off the old Joomla 1.5 site you built years ago. You create a subdomain to hold that shiny new web site. Maybe you call it "new.client.com", or being a leading edge kind of person maybe it's "joomla31.client.com" (Joomla 3.1 will be here very shortly). If you use the default directory and don't password protect it, anyone can see the new site by accessing the subdirectory. Entering client.com/joomla31/ exposes the new site to the world. If you used "new" it's an easy guess. There's a also good chance that backups of your main site are also now a lot bigger (you are backing up the site, right?) because they include also include the new version.

You work away on your spanking new Joomla 3.1.0 site and a few weeks later it's ready for launch. If you have the site in a subdirectory, you make a backup there and restore the new site in the web root. Over time you update the new site, applying security updates, fixing a vulnerable extension... everything is running smoothly. Then months later despite thinking you've done everything right, the site is hacked! What happened?

 A few things could have gone wrong here:

  • The install didn't start with a "blank slate". Any files that were left from the Joomla 1.5 install that weren't overwritten are still there. I recently recovered a 1.5 site that was infected with a Trojan that had laid dormant for three years without being noticed.
  • All that responsible work done on the new site wasn't performed on the development site, which is still sitting there, no Joomla upgrades, no extension updates. Hack scripts work their way as far up the directory tree as possible, looking for places to inject themselves. As soon as the development site is compromised, the live site goes with it.
  • You might be the victim of a new vulnerability that was present in both sites. Which is why backups are always important.

The purpose of a hacker's script is to spread its malware as far and wide as it can. This is how poorly configured shared hosts can wind up with massive cross-site infections. It's also the reason why world-writable directories are dangerous. So how do you manage the risk? Here are a few steps you can take:

  • Make sure you are on a quality host. If you are on a shared server and your PHP files need to be owned by "nobody", switch hosts immediately.
  • Create your subdomain web roots off your home directory rather than your current web root. This isn't going to stop a truly malicious script, but it will prevent access via a subdirectory and it won't bloat backups of the live site.
  • Delete the installation directory. Do not just rename it to installation_ or something else. Hackers will find these directories and wreak havoc.
  • Protect your development site with a HTTP password. This won't stop a hack on the old site, but it will prevent infection of the development site. It will also stop curious people from snooping around.
  • Remove unused code. Clean out unused extensions, remove templates you aren't using, clear out and failed installs from the temporary directory.
  • When the new site goes live, archive and remove the old site completely before you install the new site. This is particularly important if the old site is past end-of-life support.
  • If you need to keep a working copy of the new site around, remember to keep it up to date. If you don't need it delete it.
  • Make sure your backups are working. Use a component like Akeeba Backup Pro to make sure you have backups on a remote host.

Follow these steps and you can avoid some unhappy surprises.

Image: Sphere within Sphere, decade_null. Licensed CC-SA.