The ransomware threat is real and it’s much more than just a PC problem. Veeam see customers and partners encounter ransomware in a number of situations including the data centre. One important part of being resilient to ransomware is being able to recover from backups. That’s the availability you want when things don’t go as planned, should ransomware become an issue in your data centre.
Here are a number of tips we have prepared to incorporate into your designs, both new designs and existing designs using Veeam. Not using Veeam yet? No worries, you can take this advice and implement it accordingly.
Additionally, it’s important to note that there is no one-size-fits-all strategy to protect your backup infrastructure from ransomware. The goal here is to provide options which you can implement as you see fit.
Use different credentials for backup storage
This is a generic best practice and in the ransomware era, it’s more important than ever. The username context that is used to access the backup storage should be very closely kept and used exclusively for that purpose. Additionally, other security contexts shouldn’t be able to access the backup storage other than the account(s) needed for the actual backup operations. Whatever you do, please don’t use DOMAIN\Administrator for everything!
Some designs have the Veeam infrastructure not joined to the domain (for smaller environments) and for larger environments joined to a domain dedicated to tools like backup. The advice here is to consider authentication in the design and implement as much separation as possible from production workloads.
Have offline storage as part of the Availability strategy
One of the best defences against the propagation of ransomware encryption to the backup storage is to have offline storage. There are a number of offline (and semi-offline) storage options for Veeam, explained below:
| Media | Characteristic |
| Tape | Completely offline when not being written or read from. |
| Replicated VMs | Powered off and in most situations can be a different authentication framework (for example, vSphere and Hyper-V hosts are on a different domain). |
| Storage snapshots of primary storage | Can be used as recovery techniques and usually have a different authentication framework. |
| Cloud Connect backups | It’s not connected directly to the backup infrastructure and uses a different authentication mechanism. |
| Rotating hard drives (rotating media) | Offline when not being written to or read from. |
Leverage different file systems for backup storage
Having different protocols involved can be another way to prevent ransomware propagation. Veeam have long advised customers to put some backups on storage that uses different authentication. The best examples here are backups of critical things like a domain controller. In the unlikely event that a domain controller would need to be fully restored, there can be an issue if the storage containing the backups is an Active Directory authenticated storage resource.
The good example here is a Linux system functioning as a repository. This authentication for Veeam backups and restores can be made over Linux authentication and by using a different file system (ext3, ext4, etc.) the propagation risk of ransomware is reduced. Ransomware does exist on other operating systems, to be clear. This additional step, however, can be a protection for the backup storage between operating systems.
Take storage snapshots of backup storage if possible
Storage snapshots were mentioned above as what I call a “semi-offline” technique for primary storage, but if the storage device holding backups supports this capability it may be worth using to prevent ransomware attacks.
Start using the 3-2-1-1 Rule
Veeam have been promoting the 3-2-1 rule a lot. The 3-2-1 rule states that you should have three different copies of your media, on two different media, one of which is off-site. This is great because it can address nearly any failure scenario and doesn’t require any specific technology. In the ransomware era, it’s a good idea to add another “1” to the rule where one of the media is offline. The offline storage options listed above highlighted a number of options where you can implement an offline or semi-offline copy of the data.
You may not need to completely reconfigure an installation to implement an offline element. However, consider these options as additional steps to existing designs.
Have visibility into suspicious behaviour
One of the biggest fears of ransomware is that it may propagate to other systems. Having visibility into potential ransomware activity is a big deal. In Veeam ONE 9.5, there is a new pre-defined alarm called “Possible ransomware activity.” This alarm will trigger if there are a lot of writes on disk and high CPU utilization.
Let the Backup Copy Job do the work for you
The Backup Copy Job is a great mechanism to have restore points created on different storage and with different retention rules than the regular backup job. When the previous points above are incorporated, the backup copy job can be a valuable mechanism in a ransomware situation because there are different restore points in use with the Backup Copy Job.
The Backup Copy Job can read backups already on a repository and create restore points on new storage that is a different type. So if you took one option above of adding an extra storage device to your infrastructure that was a Linux server, for example, you’d add that Linux server to your Veeam Backup & Replication console, define a repository on its file system, then create a Backup Copy Job.
Acknowledgement:
Reproduced from a blog post by Rick Vanover Veeam Evangelist
Want to know more about Veeam and how to protect your data give amatis a call 01183219944 or email [email protected]