Immutable storage question

[sgaucher]

So I've set up an Ubuntu Server 20.04 VM with an iSCSI connection to a 30TB NAS box and configured it in B&R as an immutable repository with a "single-use credential" of the originally created user ("veeam"). I ran chown veeam.veeam backup/ and chmod 700 backup/ to restrict access to the backup directory to only that user as instructed. In theory this seems to work, I can't rm the .vbk's created on this repo. But I can just sudo chattr -i the files and then rm them very easily. I'm confused then as to how this is any more secure than restricting permissions on an NTFS volume? Am I perhaps supposed to remove that account after the repository is created? I don't see anything in the documentation about doing that and I'm not sure how it would work anymore after that user was removed.

[Mildur]

Hi Steve

You can‘t remove the user from the ubuntu machine which you have used in the single use credentials wizard when adding the backup repo. This user is used to run the veeam service on the ubuntu machine. But you can remove his sudo permissions. They are needed again as soon you are updating veeam.
The credentials itself are not stored in the veeam database. A hacker cannot extract the username and the passwort.

It takes more than only installing the ubuntu and activate the hardened feature to have a immutable storage.

Two other things to take care of:
- Make sure, that ssh is not activated. You only need it to update the veeam software. But I see another issue here. It‘s a vm. If you have access to the hypervisor, it‘s really easy to boot it up in recovery mode, reset the root password and login as root to delete all backup files.

- and most important thing, you don‘t need to use sudo chattr -i, when you can delete the iscsi LUN on the NAS Box. The Admin Interface must be disconnected from the network.

Linux hardened repo should be build with hardware servers with direct attached disks. Or they are not really effective as a hardened repo. To many possibilities to attack and delete the files. Hardware server with direct attached disks are more stable, have more performance and are easier to secure against attackers.

[soncscy]

> But I can just sudo chattr -i the files and then rm them very easily. I'm confused then as to how this is any more secure than restricting permissions on an NTFS volume? Am I perhaps supposed to remove that account after the repository is created? I don't see anything in the documentation about doing that and I'm not sure how it would work anymore after that user was removed.

Immutable isn't magic, and no software immutable solution ever can be. It doesn't matter what it is, if there isn't an air gap or a hardware lock anyone with full admin rights (or root) can get past a software solution.

What immutable does for you however is a few things:

1. An attacker or malicious insider (even non-malicious insiders) cannot just shift+click and "Delete from Disk" in your Veeam environment (from the veeam console, from mounted shares, etc)
2. Hardened repo has no need for SSH or anything else except network access to the Veeam data mover service, so you've got one thing and one thing alone to protect well
3. With Single-Use credentials, the services are all set up to run with a least privilege user except for the immutable service which must be root (to set/unset immutable); this means you can just get rid of that user once you're done, lock down SSH access and any other access.

It's not perfect by any means of course; if the attacker finds a way onto the box and gets root, yes they can wreck your backups, but this true of any situation. Where I'd argue this is better than Windows NTFS permissions is that it's far faster to go to total lock-down mode, and depending on your distribution you use, you're looking at uptimes of months without a hiccup. (I only wish somehow we could put Veeam repositories on BSD boxes...I can dream )

So it's not a perfect solution, but compared to other vendors I've seen offer software immutable solutions, I like this one the best because it's very honest and clear about what it is. There's no black box component really, it's just chattr and a service that sets/unsets it, and I like it simple that way.