How to protect against Ransomware disabling backups > Airgap

[pvc]

Looking for some feedback and answers please.

I've seen a few other older good posts about the Airgap as well but have an additional question.
As mentioned in this post (https://community.spiceworks.com/topic/ ... hem?page=3 ) we like to setup a similar solution:
"Pull rather than push backup is also a way of airgapping disk based backups. If the backup appliance copies the files from the client rather than the client copying the files to it, then the backup appliance need not expose any writable shares to the LAN. "

We have a VEEAM backup server setup and an additional local "Airgap" server with lots of storage which will simply copy the latest VEEAM backup files to itself with unique local user authentication between the 2 servers. The local server will not be accessible from our main network, only from KVM console.. We like to run a scheduled copy script on the local server to only copy the most recent .VBM & .VBK files over each night. However with the reverse incremental the large VBK file will change each day.

It would be nice if we can do a block level backup somehow to only do the changes instead of the full large VBK file each time but end up with the updated .VBK.

This is not replacing our existing offsite backups, this would be in addition to add the last "1" of the 3-2-1-1 backup rule you guys are probably familiar with.

Any thoughts or suggestions would be appreciated.

Thank you.

Regards,

[Mike Resseler]

Hi Paul,

First: Welcome to the forum!

I am honestly not completely convinced that pull is also a way of airgapping disk based backups. I do understand that at that point in time the "client" does not to know any credentials to the server that is doing the pull so if the network is infected, that specific server credentials might not be known but there is still a probability that the server gets infected anyway once a cleaver ransomware is in the environment. There is a LAN connection between it, there can be files copied so smart ransomware will find a way to get to that server no matter what.

I don't have a tool in mind that can do this type of block-level copy to that server I'm afraid

But as another measure, what if you have rotating USB devices to that server? Then you can continue to use a BCJ from Veeam to those devices and airgap them after that. That in combination with your existing offsite backups should give you already a very good defense.

thoughts?

Mike

[pvc]

Thanks Mike for your reply.

Our goal is to not have even the remote repository shared and yet still rely on a credentials which would then have to be typed in and can be found by possibly key loggers etc. We want to grap a copy from a remote repository to the AirGap server which NIC is only online during the copy.
The challenge now is to get the hardware (fast drives) in place to be able to copy about 20TB in about 12 hours or less as we cannot copy the files from the VEEAM server while it's running the backups as the VBKs would be locked.
The other option yes is to hard swap drives out the VEEAM server on a rotational basis but challenge still is then how to get 20TB swapped out daily on a drive.

Thoughts are appreciated.
Thanks

[Mike Resseler]

Paul,

That seems indeed like a difficult challenge. What if you have one repository (local one) and do a Backup copy job to the rotational drives? Then you could attach those rotational drives to the airgap server and do the copy? That way there are no credentials needed for the airgap server and B&R is not aware of it

(Thinking out loud here actually...)

[pvc]

Mike,
Yes, we like to backup to rotational drives as we do at some other locations but it's challenging when doing 15/20TB.
We simply want to be able to grab daily copies from the large VBK backup files but only the block level changes made to reduce the copy times. Was hoping to accomplish this with a simple (free or low cost) script.
Thanks

[ChrisSnell]

A similar mechansim is created when using Veeam with ExaGrid. The use of Veeam's Data Mover protocol means that the shares used on the ExaGrid appliances are not CIFS/NFS, and so the backups are not visible on the network. The only way to find the backups is via the Veeam interfaces and log ins.

http://www.exagrid.com/press-release/ex ... ation-aws/