Avoid Multi-Site Hacking

Avoid Multi-Site Hacking – Part 2

Avoid-Multi-Site-Hacking-–-Part-2

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

Site security = technical protection + organizational measures

If you don't use security isolation on sites in the same hosting account, you should at least give each site its own account. However, this is often impossible, as the combined sum of each site's content resource needs (disk, memory) is too great.

This is where the next elements of complex security come in. I call them organizational measures. Here are some examples.

Secure workplaces. The computer used to administer the site should have antivirus software, licensed and up to date.
Secure network connections. When connecting to sites, make sure the network is secure. For example, always use a VPN (Virtual Private Network), especially when connecting via a public Wi-Fi.
Employee Safety Codes. Make sure your employees know how to work safely with the site. Know who can access accounts, and how they do so.
Access management. Enforce regular password changes. Make sure contractors have adequate but minimal access rights.
Checking after contractors leave. Check sites for contamination after contractors or third parties have been working on them.
Inspections. Schedule regular site inspections to check for hacking or infection.

Implementing organizational security measures alongside technical protection minimizes the risk of hacker intrusion.

However, experience tells us that for some web projects, this is difficult or even impossible. A big threat is with fast-moving web projects, where many specialists work simultaneously. For example, it is difficult to know whether:

a freelancer working remotely on a site's SEO had antivirus software installed;
a content manager updating information on a blog used a VPN while connected via their favorite pizza parlor's Wi-Fi;
a webmaster gave a designer SSH access to the whole account instead of just FTP access to a specific folder.

It is difficult to check that organizational security measures are being followed, and as the difficulty increases, so does the security risk. This is a particular concern in rapid web project developments, where many specialists need system access. Such projects should use separate or temporary short-term accounts with restrictive access rights. They should remain separate from mature projects to prevent them from damage.

An alternative is to completely transfer the running of problematic sites to specialized companies, experts in applying organizational security protection measures to the management of multi-site installations.

A Case Study

I have seen many cases where Internet agencies or web studios suffer significant losses because of vulnerable sites run by one of their clients. I have also seen cases of damage caused by careless freelancers engaged in contract work. The following situation is sadly typical.

An agency is engaged in the support and promotion of client sites.
All sites are on the same hosting account or server where there is no security isolation in place.
One day, the agency finds that all sites are infected.
Their SEO investment is instantly wasted. The major search engines have blocked all the agency's sites from their search results.
Consequently, the hoster closes the account for violation of terms of use: one or more of the sites was found to be sending spam or serving phishing content.

What do customers do in this case? They blame the agency, of course!

The agency doesn't understand how it could it happen. How could all sites suddenly become infected? They begin an analysis of the server.

They may find a client's login credentials were stolen and used by an attacker. The attack first compromised the client's site, then moved onto other sites. Or, a site had not updated its CMS for a long time. As a result, it suffered a malicious campaign (i.e. a no-purpose attack), which later infected neighbors on the same account.

Even experienced webmasters often have problems. To reduce hosting costs, and to make site administration easier, they may decide to transfer all their sites to a single, multi-hosting account, one without security isolation. Unfortunately, such behavior brings little profit. Any financial gain is eclipsed by the costs of site restoration and repair after a hacking event.

The star of our last sad story is a webmaster who had for many years been successfully supporting dozens of client sites running the WordPress CMS. Everything was going well until a new client came along with a site running on Joomla. It's a sad story because this webmaster had no protection installed for Joomla. As expected, the site fell victim to hacking and all neighboring sites were infected.

Summary

Part 1 looked at the dangers of multi-site hosting and the benefits of security isolation as one strategy for the defense against hacking. This is a technical protection strategy.
Part 2 suggested more options for strengthening defenses with the use of improved organizational measures, such as access reviews and training.

About the author: Gregory Zemskov is a cybersecurity samurai and founder of Revisium.com, now part of Imunify360, where Greg is Project Manager.