Hi!
Is there a way to prevent the root user in Proxmox VE from deleting backups on a PBS storage that have been created (and pruned) via PBS? This would offer some better protection against ransomware, I suppose.
I am grateful for any recommendations. Thank you!
Cheers,
Steffen
You should create seperate API tokens on PBS for every PVE server and give every API token only access to it's own namespace.
Set the permission for the API tokens to "Datastore Access" (hope that's the right one) for their respective namespace only.
From the Docs:
Code:
* Use separate API tokens for each host or Proxmox VE Cluster that should be able to back data up to a Proxmox Backup Server.
* Configure only minimal permissions for such API tokens. They should only have a single permission that grants the DataStore
access role on a very narrow ACL path that is restricted to a specific namespace on a specific datastore, for example /datastore/tank/pve-abc-cluster.Thanks for your help! It turns out that my web gui does not show namespaces of my datastores, see screenshots. I also do not see how my API tokens can be associated to a particular namespace. Sprry about my beginner's questions.... Any idea, please?
You would configure your access rights that the PVE is only allowed to create backups on the PBS but not to remove oder modify them like described in the already linked doc chapters:
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
So you would never, ever remove the backups from the PVE host. Instead you would create prune jobs on the PBS or (alternatively) remove older backups manually in the PBS web interface.
Please note that the root user on the PVE is not the same as on the PBS. But if you happen to give both the same password of course somebody who figured out the root password on one system can also access the other one.
Now there might still be a chance that your local PBS gets compromised. This can be mitigated by setting up another PBS on a offsite location (could also be a cloud vserver or a PBS-as-a-service provider like Inett). Both PBS have permissions setup in a way, that they can't alter each other backups.
On the offsite PBS you would create a pull-sync-job which will pull the backups from your main PBS. Please note, that it's a pull-sync NOT a push-sync. Why? Because then you can create two firewall rules:
- Access on port 8007 to the remote PBS on your local PBS
- No access at all to your offsite PBS The pull-sync jobs will still work (they need to be able your local PBS so the closed ports on the offsite PBS are no problem)
This way a attacker might take over your local PBS but still wouldn't be able to do anything on your remote system. Even if your backups get compromised and pulled to your offsite PBS as long as you still have older backups available you can restore from a backup older than the time of attack.
Now you might wonder how you will be able to access the web interface on your offsite pbs if the firewall closes everything? For this you would create a vpn consisting of your remote PBS and your local management client (and maybe your local PBS). Then you would modifie the firewall rules this way:
- The managment client can access the remote PBS on port 8007, this is controled by its vpn IP
- The remote PBS can access the local PBS via it's VPN IP
- The remote PBS access is still closed for everything except the VPN ip of the management client
Depending on your level of paranoia (aka threat model) you could modify this setup but the most important thing is to configure the permissions that the PVE only can add backups but not modify or remove them.
Last edited:
Hi Johannes,
Thanks a lot for your advise. This is greatly appreciated!
I think I managed to setup the access rights so that PVE cannot delete backups anymore.
Regarding your recommendations to use a 2nd offsite PBS: that is a great idea.
Currently I am running the PBS on my QNAP NAS where I have the opportunity to let the PBS run inside QNAP's virtualization station. I had chosen this setup because a) convenient and b) I thought I could use QNAP's cloud storage with WORM policy to push my local backups offsite to QNAP cloud. This, however, does not work - as I realize now - because the WORM folder files (chunks etc) are obvioulsy undergoing changes during the backup process ;-((
I am not much of a network expert but do you think that my local PBS running on a VM on my QNAP would be able to get connected from an offsite PBS (fir push-sync) with the right firewall settings?
Thanks for your kind help!
I am not much of a network expert but do you think that my local PBS running on a VM on my QNAP would be able to get connected from an offsite PBS (fir push-sync) with the right firewall settings?
This should work. An ( if budget is a concern ) Alternative for air-gapped backup might be to add multiple external USB storages as "removable datastore", you store outside of your place and swap out from time to time.
The new S3-support of PBS might also be an option as soon it leaves it's current "technology preview" status. Of course you can test it already but I wouldn't trust it yet as sole backup storage. As additional backup ( on top of your local PBS and a second copy ( USB storage, second PBS ) it might be ok depending on your Level of paranoia
I have a simple system with my pve backing up to my pbs; it's working fine. However for the backups on pbs, the pbs root user ist still used. So I'd like to change the user to a restricted one for security reasons. I managed to create a restricted user on pbs, but I couldn't find a way to enter this restricted backup-only-user in pve. Do I have to delete the pbs-storage entry in pve and create it anew or is there a easier way to do so?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
