Running shared or VPS servers has risks. When one site is hacked, neighbors succumb shortly after. In this two-part article, I'll explain the risks in detail and what you can do to mitigate them.

Shared hosting and VPS servers allow you to host several sites within one user account. If you're a webmaster, a web studio, an Internet agency, or a business owner, you do this not only for convenience but also to save money, as it is cheaper than buying separate accounts for each site.

But there's a problem. Multi-site accounts are vulnerable to hacking and the subsequent infection of the entire hosting account. Often, there are dozens of "patients" (tenants) on the same site who urgently need treatment for viruses. These cleanup operations can take a lot of time and result in a serious financial loss for both you and your customers.

One of the causes of this problem is the bad placement of sites on the hosting platform. It's a symptom of cross-contamination, where the hacking of one site on the account infects other sites. For example, a site on an old and possibly vulnerable version of a CMS such as WordPress (or Joomla or Drupal, etc.), can threaten all other sites on the account, even if those sites are up-to-date. Hackers only need a way in and will exploit the weakest site.

Most hosting servers don't isolate sites from each other. That means that scripts on one site can make changes to files on another. For such servers, there are special rules for the safe placement of sites. That's what I'll cover in this article.

Internal Threats

You can use technical means to protect any site from external web attacks, regardless of its location. By technical, I mean the correct configuration of the web server, the firewall, your chosen security solution software, and so on.

However, for owners of multi-site accounts, such technical approaches only solve part of the problem. This is because there is no security isolation of sites from one another. Threats can still come from unprotected neighboring sites on the same server—in other words, from within.

In the case of multi-site hacking, you must work with all the sites on your account at the same time. You must immediately cleanse all resources, and, more importantly, protect against re-infection.

But how do you clean sites in parallel? The answer is, you don't. You must first isolate, and, only then, cleanse.

Here's one way to do it. You can create a new account on another server and transfer the most business-critical web projects to it. Perform your cleanup operations (e.g. antivirus or anti-malware scans) on this now safely isolated server. If you don't isolate first, as-yet untreated sites can re-infect files that were just cleaned. It's a bit like bailing water from a leaky boat; it's never-ending and you eventually sink.

Isolation Reality

Unfortunately, multi-site account holders tend to act selectively, investing in the protection of only the most profitable projects. Sites of less importance, such as blogs, test sites, old and forgotten web projects, are ignored. A hacker will target these less protected sites, using them as entry vectors to access other, more important target assets.

New sites are also potential weak spots. Before publishing the details of new websites, be sure to protect them first. Don't let uninvited guests spoil the party before it's begun.

Many site owners are mistaken about how site isolation works. They believe that if each site has a separate FTP account, then the sites are independent of each other and are isolated.

This is not always the case as they may be using the same user account. The presence of virtual users for FTP access does not prevent cross-site hacking. Hackers can use PHP scripts, as in most cases these will have no restrictions within the account. They can also use a compromised SSH account or a primary FTP account. The only thing that isolates sites from each other is the ability to separate SSH access for each site. This is an indicator of real isolation. If you can't create separate user accounts on each site, the whole hosting server is vulnerable to multi-site hacking.

Some system administrators think that they can lock down a system and protect it with certain PHP settings, such as open_basedir. Unfortunately, hackers can bypass these settings. And, apart from PHP, there are other ways a hacker can run scripts or insert malicious code into neighboring sites. 

Above, we looked at security isolation as a technical solution for preventing infections on one site spreading to neighboring sites in multi-site hosting systems. Stand by for Part 2, where we'll consider other non-technical ways to beef up multi-site protection.