Protect Veeam Repo from Ransomware

[ali.swaidan]

Dears,

Hope you're doing well,

This is Ali i'm a VMCE Experienced Certified Engineer. as we all know there's a headache to protect your Backup Repository from Ransomware Attacks on Premises.

to do so, please follow the below scenario.

Requirement
1- Windows Server 2008 R2 SP1 and above.
2- Enable File Server Resource Manager Role.

Instructions:

1- Install Veeam Backup & Replication
2- Go to Server Manager.
3- Click on Manage
4- Click on Add Roles.
5- Select File Server Resource Manager
6- Finalize the installation.
7- Open File Server Resource Manager from Server Manager or Start Menu
8- Expand File Screening Management from the left pane and click on File Screen Templates.
9- Create File Screen Template from the right pane.
10- Specify the Template File Name in the Settings TAB
11- Screening Type: Active Screening
12- File Groups: Create File Group and give it the name you want
13- Insert *.* in Files to Include Field
14- Insert Below list in Files to Exclude
*.bco
*.vsb
*.vlb
*.tmp
*.vbm
*.vbk
*.vbm_*_
*.vib
*.vrb

15- Click on OK
16- Test your jobs (Backup, Restore & Replication Jobs)
17- Good Luck.

after all above configuration's done you'll be able to deny any file extension modifications.

Please don't hesitate to contact me for further support or information.

Good Luck Guys.

[foggy]

Hi Ali, thanks for sharing your knowledge with the community, much appreciated!

[ali.swaidan]

Dear Foggy,

its my pleasure to provide the best support and make this product the top one. its highly appreciated if we can Pin it and share for all users so they can protect their own REPO.

[Gostev]

Hi, Ali.

I'm not sure I understand how your proposal helps.

If with the above file screening implemented, Veeam processes are still able to modify and delete backup files - which you seem to imply by #16 that it does - then what would prevent ransomware running on the same server with the same privileges from doing the same to backup files?

Thanks!

[ali.swaidan]

Hello Gostev.

Sure veeam will be able to create and modify since you are using its own extension. Try to rename the extension of created backup file by veeam. Let's say you have a full back file called test.vbk you will not b able to rename it to test.vbk.x (where x is any additional extemsion added) or to replace the .vbk with any other extemsion not mentioned in your allowed list (excluded extensions).

Im following this solution since long time ago and it gives a great result.

We can test it together

[Gostev]

Right, but how does it help that backup file renaming is blocked?

Ransomware will still encrypt the file, and will fail to rename - OK, but this does not change the fact that the backup file is now useless, even if its extension is unchanged. Besides, in almost all successful attacks we saw thus far, ransomware is usually used to encrypt production data (as backup files are just too big for ransomware to process), while all online backups are simply deleted and wiped by the hacker.

[ali.swaidan]

In my scenario ull not be able to change the extension right. But also if you configure the required permission for veeam user only that used by the solution to write on the specified repo and to deny any additional access even for the entite system itself then only veeam will be able to write/modify & delete files without even allowing anyone to change the extension or to encrypt it.

[Gostev]

Only Veeam and ransomware or hacker running under the same account and no, you can never revoke access from LOCAL SYSTEM either.

[ali.swaidan]

Working with these kind of workaround its somehow running a lockdown feature on specified path and will be waiting for the next version where veeam can implement this feature as a built in feature to enable such features to protect the repo.

Believe me im safe since years ago by using this methods lot of ransom comes across and nothing affect veeam.

[Gostev]

Well, all I can say is that there are plenty of other threads around here explaining in details why such a feature would be completely useless. In short, you can't beat a process running under LOCAL SYSTEM privileges, which hackers can easily obtain by exploiting zero day privilege escalation vulnerabilities - allowing them to disable and/or bypass any and all software-based protection.

You've been lucky for years just because you have never been a subject of a proper cyber-attack... the only real protection against those are air-gapped, offline backups. And if you don't have such backups, and instead rely on half-measures like the above - then unfortunately, it's just a matter of time until you lose all your data.

[Bhushan]

Hello Ali & Gostev,

I am not that highly technical person as you all, I use Veeam Agent for Microsoft Windows for more than 3 years for my On-Premises Server to backup on Synology NAS DS418+ and also use Synology NAS as a File Server and I have enabled Snapshot on NAS Shared Folders. This scenario is almost alike at all our clients and recently two of our clients were hit by ransomware and all the files on network including Shared Folder on NAS were encrypted with .peet extension. Thankfully the data was safe on Snapshot and we retrieved all the data successfully from Snapshots with 2-5 min.
So even we can have strong protection on On-premises although we should have off-site backup.
These are my personal thoughts and does not imply that you also agree on the same.

Thanks ...

[Gostev]

Hello Bhushan,

Your approach indeed provides a good level of protection against ransomware and cyber attacks so long as you can secure access to your storage management console. I too have seen a number of success stories with this approach, however I also saw at least two events by now when this approach has failed. Here is what I learned based on those two events:

1. Once inside your network perimeter, hackers rarely carry out the attack immediately. They usually first deploy keyloggers and network scanners to identify all data management interfaces, and gather credentials for them. Probably the only solution against this is mandatory 2FA on your storage management console, but even then you're relying on an assumption that your storage management UI does not to have a security vulnerability allowing hackers to bypass authentication completely. Which is a tough bet: I too have Synology NAS at home, and every DSM update they roll out fixes a number of vulnerabilities.

2. Storage snapshots obviously do not protect against an attack by a malicious insider, or what I call the "human disaster". At the very least, insiders can always destroy the data physically (although usually they do this with a few clicks, due to having all credentials and 2FA in hands in order to be able to do their job).

So, while your approach indeed dramatically reduces the chances for a ransomware attack to be successful, and is quite popular among Veeam customers, I would still classify it as "half measures" comparing to having air-gapped (offline) backups stored in a secure location, preferable off-site.

Thanks!

[ali.swaidan]

Hello All,

Veeam should create a feature that make the Backup Repo as a LockDown Area so we will be able to protect our backups.

[Gostev]

Ali, we're going in circles here. Please study this thread carefully, especially my second to last response... software-based lockdown features are worthless, because they do not provide any real protection, as they can be easily removed or circumvented with an OS account that is powerful enough to uninstall a file system driver - or just bypass them in the same way as the actual backup software, which needs to be able to do so in order to operate. Thanks!

[Bhushan]

Hi Gostev,

I totally agree with your explanation to have Offsite backup, it can be offsite location physically or onto the Cloud.

Thanks for sharing great info...

[dbewernick]

Hello All,
Veeam should create a feature that make the Backup Repo as a LockDown Area so we will be able to protect our backups.

A few month later, I would like to add, that such a feature is available now with S3 Object Storage systems:
https://www.veeam.com/blog/air-gapped-o ... ility.html
https://helpcenter.veeam.com/docs/backu ... ml?ver=100

To get some information on (unofficial) system support, have a look here: object-storage-f52/unoffizial-compatibi ... 56956.html