The Case For Website Backups
File backups are essential to the security of any site. With regular, tested website backups, you can recover your site easily from any of the following issues:
- hardware failures
- accidental deletions
- defacements
- ransomware
They can also be problematic. This week we’ll discuss why website backups are essential, and then reveal how faulty backup security can harm a site and how to prevent that from happening.
Websites Damaged By Malware
We clean a lot of malware. A lot. And sometimes malware damages site files beyond repair. If that happens, we contact the site owner to see if they or their developer can restore the site from a recent backup. Failing that, we’ll contact the hosting provider to see if they can provide a recent backup. In most cases a backup exists and the site is restored with minimal data loss. All is well with the world.
Without a backup, the site owner has the following options:
- Rebuild the website on their own
- Hire a web developer to rebuild the site with the remaining good files
- Rebuild the site from the ground up (worst case scenario)
Money, time, and data are lost. All is not well.
The third scenario emphasizes the importance of backups. Backing up a site’s database, media, and customized content at regular intervals helps protect the site from attacks and other damaging events.
Therefore all backups are good, no matter how they’re performed, right? Not quite.
Keep Your Website Backups Secure
We sometimes see site backups on the site itself, meaning, backups are written to the publicly accessible document root of the site. Granted, these backups aren’t normally linked on the site, so there is some security through obscurity. But this won’t stop all attacks from leveraging said backups.
Take a database backup for example. A website owner or developer writes the .sql file of a MySQL dump to the same directory in which the site is hosted. An errant directory listing, a guess of the backup file name, or an FTP or other compromise of the site will likely leave the SQL backup — the entire database for the site — neatly wrapped up for an attacker. Now, not only does the attacker control the site files, they control all of the likely sensitive database content. Admin accounts, personal user or customer data, sales data, everything. All is really not well.
Not All Backups Are Good Backups
An even worse way to backup site files is to place them in a publicly accessible directory named backups, bak, bakkup, or any iteration you can think of. It’s guaranteed that web scanners search for these directories, and if the directory is set up to list all of its contents publicly, it’s game over.
Was malware backed up on the site? Yes, yes it was.
We see this more than we’d like. We also see owners or developers of compromised sites create a copy of compromised files in the same publicly accessible hosting account named hacked, suspected, bad, delete, etc. Yes, vulnerable and compromised files simply get moved to another spot on a production site. This means the compromise is still on the site. It may be more difficult to find or use, but it’s still there.
Suspected is just that — suspect.
To prevent backups being used against you, save copies of critical site files off of the production site or server. This prevents backups falling into the wrong hands, or succumbing to the same issues backups are meant to mitigate. Sometimes it’s as simple as moving backups outside of the site’s document root, or using FTP to download them to a local machine. Whatever the best strategy for you is, make sure the production site is for production files only and store backups elsewhere.
Proactive security measures greatly reduce the risk that your website will be infected with malware. SiteLock offers website scanning, web application firewalls, along with other security services. View our plans page to learn more.