Securing iSCSI SAN target Esxi

[dwright1542]

We're repurposing an MSA1040 10G SAN for backup storage, which has no native NFS or SMB. I can mount it as a windows drive directly on the Veeam server and store backups there, but that makes me nervous. Our Veeam server is NOT on the domain, but still makes me nervous.

We've got 2 other replica locations...this will just be for short term, very high speed backups, GFSing to other devices.

I could also spin up a FreeNAS / Ubuntu, whatever and do NFS or SMB back to the Veeam server for another layer of protection. (And then there's the NFS vs SMB discussion....)



Any thoughts on best utilizing this space?

[Gostev]

Simply put, if the backup server is able to write and delete backups, then anyone who takes over the backup server will be able to do the same too. Adding extra protocol layers will reduce reliability and performance without improving security by a bit.

What will make difference however is scheduling periodic storage snapshots for LUNs hosting backups. If you're able to secure storage management console to prevent hackers from managing snapshots, you will be able to discard their efforts with just a few clicks. I'm guessing MSA is too old to support 2FA, but perhaps there's a way to lock down console access to a single static IP address of a powered-off workstation?

This will give you a good level of protection, although certainly not 100% bulletproof. But then again, as you know - if you want to sleep well, you need air-gapped (offline) backups, as anything that is online can be hacked through vulnerabilities.

[dwright1542]

Gostev,

Thanks for the reply! Windows credentials will not allow reading and writing to linux based SMB shares, so unless they take over the actual console itself, which has different creds, they can't access the share. Only Veeam can. So that's 2 sets of passwords they would need rather than just the one windows one which would then have direct access to the backups.

MSA can't do snapshots.

Or am I missing something?

[Mildur]

Worst Case scenario:

A Hacker doesn‘t need to have credentials for your backup Storage/backup Share. Veeam Services has access to the storage.

If the hacker is on the veeam server, a simple powershell command „Remove-VBRRestorePoint“ is enough to delete the backups under veeam service identity, which has access to the share.

Only air gapped backups like tape or S3 object Lock/veeam Cloud Connect with Insider Protection are perfect solutions.

[dwright1542]

Oh. Yeah, that changes things.