9 steps to protecting backup servers from ransomware

Now that ransomware organizations are specifically targeting on-site backup servers, it’s even more important that enterprises defend them vigorously.

Here are nine steps to protect your backups and why you should take them.

Patch religiously

Make sure your backup server is among in the first group to receive the latest operating system updates. Most ransomware attacks exploit vulnerabilities for which patches have been available for a long time, but that didn’t get installed. Also, subscribe to whatever automatic updates your backup software provides, again to take advantage of whatever new protections they might include.

Disable inbound ports

Backup servers get attacked in two ways—by exploiting a vulnerability or logging in using compromised credentials. Disabling all but the necessary inbound ports can stop both. Only ports the backup software needs to perform backups and restores should be left open, and they should be accessible only via a VPN dedicated to the backup server. Even users on the LAN should use the VPN.

Cripple outbound DNS requests

The first thing ransomware does when it infects your backup server is contact its command-and-control server. If it is unable to do so, it can’t receive instructions about what to do next. Consider using a local host file or a restricted DNS system that does not support external queries. This may seem ridiculous, but it is the easiest way to stop ransomware that has infected your system. It’s a major payback from a minor inconvenience. After all, why would a backup server legitimately need the IP address of a random machine on the internet?

Disconnect the backup server from LDAP

The backup server should not be connected to lightweight directory access protocol (LDAP) or any other centralized authentication system. These are often compromised by ransomware and can easily be used to gain usernames and passwords to the backup server itself or to its backup application. Many security professionals believe that no administrator accounts should be put in LDAP, so a separate password-management system may already be in place. A commercial password manager that allows sharing of passwords only among people who require access could fit the bill.

Enable multi-factor authentication

MFA can increase security of backup servers, but use some other method than SMS or email, both of which are frequently targeted and circumvented. Consider a third-party authentication application such as Google Authenticator or Authy or one of the many commercial products.

Limit root and administrator accounts

Backups systems should be configured so nearly no one has to login directly to an administrator or root account. For example, if a user account is set up on Windows as an administrator account, that user should not have to log into it in order to administer the backup system. That account should be used only for doing things such as updating the operating system or adding storage—tasks that require infrequent access and can be heavily monitored by third-party apps for excessive use of privileged accounts.

Consider SaaS backup

Using a software-as-a-service (SaaS) that moves the backup server outside the on-site enterprise computing environment. This means not having to continually update the backup server and segment it from the rest of the network with a firewall. It also makes it unnecessary to maintain a separate password-management system for the backup’s privileged accounts.

Employ least privilege

Make sure personnel who need to access the backup system have only those privileges necessary to accomplish their authorized tasks. For example, the ability to delete backups, reduce retention periods and perform stores should be limited to a small group, and those behaviors should be heavily logged and monitored. If attackers gain unrestricted administrator access to the backup system, they could use restores to transfer all the data they want to an unencrypted location for exfiltration.

Create a separate root/admin account

A separate ID that is the equivalent of root and only accessed occasionally can limit the likelihood of damage from compromise if it triggers alarms when it’s used. Considering the damage such privileges can do to a backup system and sensitive data, it is worth the effort.

After implementing these steps be sure to check with your backup vendor for tips they might have about their products.