If you suffer multiple reinfections and your site is one of many in an account, the odds are high that you’re suffering from cross-site contamination.
Cross-site contamination is when a site is negatively affected by neighboring sites within the same server due to poor isolation on the server or account configuration. This phenomenon is one of the greatest contributors to the VPS/Dedicated/Shared hosting secure or insecure debate.
The greatest contributor to cross-site contamination is what I call soup-kitchen servers. Soup-kitchen servers are those environments riddled with every installation and configuration known to man. It might include 10’s or 100’s of different sites or different platforms (i.e., Drupal, Joomla, WordPress, etc.). The problem isn’t the quantity. They might also include sites in different phases of their lives – development, staging, production.
The biggest culprits of these configurations are agencies, freelance developers, and aspiring hosts.
A Primer in Functional Isolation
The concept of functional isolation is not new but can be difficult to employ. It’s the idea that an environment should be used for only one purpose. A classic example might be using a web server as an email server or vice versa. The general rule of thumb is that using an environment for more than one purpose is bad practice. Theoretical and practical application, however, are always two different things.
Most organizations (individuals) wouldn’t dream of having a server per site, and in many ways it’s impractical. So my recommendation is to break it out by three things: technology, function, and stage.
- Technology: Don’t mix technologies if you can help it. For instance, don’t deploy Drupal sites with WordPress sites, etc… Each platform is fundamentally different, and it’s easier to harden an environment that is similar than trying to remember what exists in the environment.
- Function: Don’t mix server functions. If you have an email server, don’t use it as a file server or web server, etc… Use the environment for what it is intended for.
- Stage: Don’t mix different stages of life for each site. Stages refer to whether it’s in development, testing or production stage. At a minimum, you should have at least two environments – development and production. Three would be ideal (including testing) but for many not as practical (or cost-prohibitive).
The next thing you want to think about – accounts.
Shared hosts have a bad reputation for poor security, but it’s not entirely accurate. While it’s true there have been challenges in the past, we’re talking circa 2010/2011. These days, the problems with shared hosts, are not the shared host themselves, but the one-to-many relationship website owners have with their accounts and sites.
Example: One account has 100 sites under it.
In these configurations, the attacks we’re seeing are not those that are moving laterally between accounts on the shared host, but rather those that are moving laterally within the same account.
It’s important that when you’re configuring your account to create unique users for each site and ensure that the permissions are such that a user can’t move between users on the same account.
Website Firewalls and Cross-Site Contamination
The most frustrating thing for a website owner is when they deploy all the recommended security controls and they continue to get infected. We experience it all the time with customers that have deployed our controls, including our Firewall, and a reinfection happens.
In 9 out of 10 instances, reinfections are occurring because of internal attacks (not external). The challenge with this, however, is that it requires investigation and education.
- Internal Attacks: Attacks where the bad actor is able to exploit internal weaknesses in the environment to perform nefarious acts (example: cross-site contamination) by moving laterally throughout the environment.
- External Attacks: Attacks where the bad actor is able to exploit weaknesses remotely to gain access and proceed to perform a nefarious act (example: exploiting a software vulnerability remotely – think SQLi).
Seeing the infection on your site doesn’t mean that it’s the site itself being exploited. If you continue to experience multiple reinfections it’s good to look at your entire environment and see if any of the conditions described above might be contributing to the issues.
The biggest contributors we find when running our reinfection investigations include:
- Forgotten websites on the same account
- Misconfigured websites on the same account
- Websites that have not been secured on the same account
If you’re a website owner and wondering if this affects you, open a dialog with your developer or host and ask them what their approach is to handling multiple websites on the same server and account. Ask them if they are managing other sites on your account and how they can provide you assurances that your site is properly isolated from other neighboring sites. If you continue to experience issues the odds are there is a misconfiguration.
Preventing Cross-Site Contamination
The approach I propose here is simple, cost-effective, and the first step into improving your overall security posture. It will pay dividends in helping reduce the risks associated with cross-site contamination, while also helping streamline your maintenance activities.
Functional isolation is as old a concept as Least Privileged or Defense in Depth, but perhaps the least discussed. I would extend that to encourage you to consider not just Functional Isolation, but Account Isolation as well. Combined, both these will dramatically reduce the threat that is cross-site contamination.
A few last thoughts:
- If you decide to deploy something like the Sucuri Firewall, make sure that it’s deployed on all sites on the same account, and you’ve followed all the steps to ensure direct access to the server is restricted.
- If you only care about one site, and not the other 99, then move that one site into its own environment.
- If you have one server doing all things, stop! Leverage your servers and accounts based on the recommendations I provided above.
- If you’re a website owner ask questions, become an involved member in the process. Security is your responsibility as much as it is your designers or hosts.
If you need help with a hacked site or are struggling with cross-site contamination, we offer professional website malware removal services and will protect and monitor your website.