10 December 2013 Last updated on 01 March 2014

Over here at AkeebaBackup.com we have the mixed blessing of providing support to users of virtually every kind of hosting environment there is. We have lately identified a new threat to web site owners: a few hosts deleting files without asking their clients. Why this is bad and how to protect yourself? Read on after the break.

Over the last month we have identified two web hosts which are automatically deleting files from their clients' sites without asking them. These hosts are xxlwebhosting (Netherlands) and Netsons (Italy). We are sure that there are many more low quality hosts conducting this kind of irresponsible actions against their clients.

These hosts appear to be running an automated script which tries to detect malicious scripts based on their content. It is pretty much what the PHP File Change Scanner feature in Admin Tools does. It looks a file for some known functions hackers are likely to use and assign a threat score. The higher the threat score, the more likely it is that this file is a hacking script.

The crucial word here is "likely". By no means a high threat score means that the file is necessarily a hacking script. A high threat score is a necessary condition for a file to be a hacking script, but it's not sufficient. A high threat score simply means that a human has to analyse the contents of the file and decide if it's malicious or not. Admin Tools does exactly that: it lets you, a human, decide if the file is naughty or nice. These hosts, however, arbitrarily assume it has to be a hacking script and delete it without asking you. You have no indication whatsoever they did this and you are likely to believe that the software you are trying to use is broken and written by an imbecile.

This is exactly what happened in all cases regarding those hosts we were requested to provide support. The users had a problem with Akeeba Backup. Namely, the backup would immediately die with the following log entry:

INFO    |131209 13:37:46|Loaded profile #1
DEBUG   |131209 13:37:46|

 This is a tell-tale sign that files are missing from the Akeeba Backup installation. In all cases we got FTP access information and we observed that the following files were mysteriously deleted:

  • administrator/components/com_akeeba/akeeba/engines/archiver/jpa.php
  • administrator/components/com_akeeba/akeeba/engines/archiver/zip.php
  • administrator/components/com_akeeba/akeeba/plugins/engines/archiver/jps.php

These are the files containing our archivers, i.e. the files which are required to generate the backup archives themselves. Quite obviously, when these files are missing Akeeba Backup can't work.

At first we though the user made a mistake during installation (sorry for the stupid assumption – we were wrong in our assessment of the situation). So we did the installation ourselves and made sure it was successful. Well, yes, the installation was successful and everything was copied... but these files were still mysteriously missing! Trying to upload them manually by FTP, they would end up missing again as soon as the backup started. We thought the site was hacked. We had a couple of clients reinstall the site, but still the same problem remained. One of the users moved to another host and, magically, the problem went away. There's an interesting conjecture here. What if the host is at fault? Quoting Ian Flemming: "Once is happenstance. Twice is coincidence. Thrice is enemy action." And an enemy action it was!

We then got word that another host (DreamHost) would rename the same files after a period of a few minutes to a few hours. They actually did have the kindness to reply to our client that indeed they are using a "security scanner" which identifies these scripts as malicious and they rename them, but no, there is no warning about it and no way to prevent that for select files. Come again? Of course these files aren't malicious! They are mistakenly recognised as such because they are doing something unusual: they are manipulating binary data in order to create backup archives. That's not malicious, unless the host implies that taking backups on your own to safeguard your site is somehow "malicious". We now have the smoking gun and the fingerprints of the perpetrator. Case closed, the host is the murderer of the files.

In our view, what these three hosts are doing is outrageous. They are messing around with the files of their clients without any kind of warning and without allowing their clients to dispute the host's actions. They put us developers in the impossible position to convince our clients that our software is not broken and that it's their host doing something so outrageous that our clients are not even willing to believe us. It's understandable. We couldn't believe it ourselves. We had to see it in several sites to believe that there can be a host so outrageously irresponsible.

All of it is done in the name of security. However, this is a strong indication that these hosts are not secure. Au contraire. A secure host is one which isolates sites on the same server, prevents infiltration and monitors the traffic (incoming and outgoing) for anomalous patterns. A host which deletes or renames files based on arbitrary criteria is a host that doesn't isolate sites, doesn't prevent infiltration and doesn't monitor the traffic. They know their servers are vulnerable and they try to "defend" their servers after they have been infiltrated, i.e. when it's too late to be effective and it's too easy to kill innocent software.

Therefore we strongly advise our clients hosted on these hosts, or any hosts which result to similar log backup failures with this kind of log messages (backup dies right after "Loading profile") to move their sites a.s.a.p. to a reputable host FOR SECURITY REASONS. If you are looking for a reputable host which is specialised in hosting Joomla! sites securely and efficiently we recommend the following, in no particular order:

  • SiteGround – an all-around great host which is currently offering three months free hosting to Akeeba Backup users (see the scrolling banner at the top of our home page). Full disclosure: we are not affiliated with SiteGround but we like each other's service and actively promote each other on our sites.
  • Rochen – the official Joomla! host (they are hosting the Joomla.org family of sites). Full disclosure: they have donated us the hosting of our own site on one of their managed virtual servers.
  • CloudAccess.net – the official Joomla! Demo host

There are of course more reputable hosts out there. If you are unsure, ask around and do some market research. Remember that it pays dividends asking the opinion of professionals, especially those whose job is site security or those who are Joomla! extension developers. These are the people who can tell a good host, trust them.

Edit (Dec 10th, 2013): Our users at Netsons contacted their host and in all cases their host disabled their "antivirus feature" (so it's no longer an educated guess, it's official, they do have a broken "antivirus" feature which silently deletes files!!!). Let's recap: the "antivirus" feature is known to be malfunctioning, it wasn't requested to be enabled by the clients and there was no indication of what it's doing. Our advice to not use this kind of hosts remains and is augmented for one more reason: they automatically enable dangerous, known to be malfunctioning, features without their clients' express consent.