Introduction
Ransomware currently represents one of the most prominent threats to IT infrastructures. Reports of successful attacks are accumulating, the attacks are getting closer. More than 30% of all companies, institutes, universities or public authorities in Germany have already dealt with such attacks. In some cases, a ransom was paid to get access to their own data again.
Even with payment, success is never certain. After all, one negotiates with criminals. Authorities therefore advise against payment.
The essential protective measure against the consequences of such an attack is an up-to-date and consistent backup.
Ransomware vs. Backup
Unfortunately, attackers also know about the importance of backups. The currently circulating malware, such as Emotet or Ryuk, contain code that actively searches for backups on the net. Using previously obtained access data for Active Directory accounts or by attacking via RDP exploits or using the brand-new Zerologon exploit an attempt could be made to take over the systems that operate the data backup in the company or hold the backup data.
The automatic attack is often followed by hackers in the flesh who actively browse the net and try to destroy all backups. This is often an easy task, since backups today are preferably held on hard disk systems, permanently connected to the infrastructure.
The reason is obvious: If all backups are deleted or also encrypted, the compliance of the “customer” to pay his ransom increases by far.
Many approaches have therefore already been conceived to store the backup data out of reach of an attacker. A very simple and secure variant is an Air-Gap – a physical separation of the backup media from the system. For example, LTO tapes can be physically removed from the library.
Without this kind of time-consuming manual extraction – which would also have to be performed daily – the data remains latently vulnerable. It doesn’t matter whether it is stored on disk systems, dedup appliances, tapes in a library or even in an S3 cloud repository.
S3 cloud providers have therefore proposed an API extension called “Immutability” some time ago. With this, at least the backups in the cloud layer can be made immune to changes for a certain time.
Some of these solutions are natively supported by Veeam. Amazon AWS is one of them. Microsoft Azure is currently still missing. Furthermore S3 memory is not suitable for every application. A primary backup with Veeam on S3 is for example not directly possible. The S3 layer is only available as an extension of a scale-out backup repository.
ExaGrid
The tiered backup storage from ExaGrid, which is specially designed for Veeam backups, already has a few advantages when it comes to data security. The initial backup in a “landing zone” without deduplication makes it possible to use the solution for primary backups. Fast recoveries and even Sure-Backup checks are no problem with ExaGrid as a repository. As a Linux-based solution, the appliance is also much more robust against attacks using the usual methods of attack. RDP gaps do not exist with Linux and revealed domain accounts do not help in direct attacks.
Nevertheless, a residual risk remained: If an intruder had gained control of the Veeam Backup server, he could up to now simply actively delete backups in the ExaGrid.
With the recently released software V6 for the ExaGrid systems this has come to an end!
Time-Lock
The new function Time-Lock was already announced at the beginning of the year and was officially released on September 18, 2020 with version 6 of the operational software.
In the following we take a closer look at the functionality.
Time-Lock acts as a temporary WORM protection for the entire retention tier of the system. All data in the deduplicated area of the systems will then not really execute any deletion request. Even if the data gets deleted in Veeam and thus disappears in the landing zone of the ExaGrid, it can still be recovered via a special recovery mode. The holding time in days for this Time-Lock can be set. The function is already per-default active and initially set to 10 days.
Tamper-proof
My first thought was: “Ok, then the attacker will just hack into the system to reverse the time lock!” ExaGrid has thought of that. The regular admin of ExaGrid is not allowed to make any changes here, but only to request them.
Only a “Security Officer”, who must be created as an account with a separate role in the ExaGrid administration area, can confirm the requested change with “Approve”. In the example, I have created the user “cso” and logged in as this user.
This account, as well as the account of the administrator, can be additionally secured with a second factor if desired. The ExaGrid can be quickly and easily connected to one of the popular Autheticator apps. The free Microsoft Authenticator, for example, worked reliably in my test.
The next time you log in as “cso”, the password alone is no longer sufficient. The “Challenge Code” now is generated by the Microsoft Authenticator and prevents the login of a third party with revealed credentials.
From Veeam this management layer is not visible anyway. Paranoid natures could even separate it completely from the internal network. The backup from Veeam to the ExaGrid runs nevertheless and via different interfaces of the appliance.
In case of emergency?
If the data is actually lost and the backups are also affected, the question arises how to get your data back.
In our example we simply delete a complete backup chain from the scale-out repo of our ExaGrid, just like an attacker would do it.
Under normal circumstances it would not be possible to restore from this backup. A rescan of the repository no longer shows any traces of a backup…
“It’s a kind of magic”
Once the attack has been detected and should now be recovered from, the admin first sets the ExaGrid into a special mode: “Suspend All Shares”.
This prevents any further write access from within Veeam. The data status of the backup is fixed. The process must be confirmed.
In the next step, the management interface allows you to reactivate an earlier point-in-time of backup data in one of the shares.
To do so, select a date and time when everything was still neat and tidy. The GUI then shows the nearest consistent backup point.
If you select this one, it takes a short moment and ExaGrid reports that the backup point is available. A new rescan to the repository under Veeam reports a successful import of a backup.
This will appear under “Disk(Imported)” because it is no longer directly connected to a Veeam job.
From here on, the recovery process becomes a normal “skip-skip-finish” Veeam recovery process. All recovery modes are available again.
Back to normal
That leaves the hint that the regular operation can no longer be performed into this now read-only share. Once all data has been restored, you should create a new share on the ExaGrid and migrate the backup to it.
Summary
The Time-Lock feature solves a long-standing problem in the Veeam ecosystem. It effectively creates the Air-Gap, without any real air in between. So to speak a “virtual Air-Gap”. The feature comes at no extra cost and is directly available to all ExaGrid users with the new software. Just a little bit of extra space in the repository is all you need to plan for the days of invulnerability. ExaGrid states about 2% additional consumption per “locked” week. But that should be worth the security.