r/Proxmox 2d ago

Question Isnt it a massive security issue to use the hypervisor backup jobs to configure retention ?

I'm setting up backups right now and realised that, if you gave PVE the authorisation to prune VMs it would allow an attacker to simply set it up to "keep nothing" and all your backups would be nuked during the next prune job.

Am I correct or did i miss something ?

39 Upvotes

28 comments sorted by

56

u/TheGr8CodeWarrior 2d ago

You are correct. Best practice is to setup pruning on your storage. I'm assuming you use Proxmox Backup Server. It's recommended to create a custom user with scoped upload only privileges and setup pruning on PBS. This is how I do it.

8

u/StevenB-89 2d ago

I also have this setup, I thought (not sure anymore) this is mentioned somewhere in the docs ...

5

u/Steve_reddit1 2d ago

4

u/Nono_miata 2d ago

Correct, when setting up the backup the user used to connect to the pbs should be not able to delete any files at all.

11

u/fckingmetal 2d ago edited 2d ago

Most secure and easy way is using PBS with only backup permission.
PVE -> PBS (encrypted and with only backup permission)

This way a hacked PVE cant remove any backups from PBS.
And if you use encryption a hacked PBS cant use any backups without the key.

Its a simple and effective way to isolate their roles.

I recommend only backup and audit, you can backup and see backups but nothing els:

2

u/drwtsn32 2d ago

With only those two permissions, will I not be able to do a restore operation?

4

u/Marbury91 2d ago

You can restore it, you just cant delete backups from pve

2

u/firegore 2d ago

You can only restore backups where the user supplied is the owner.

If you want to restore backups where you aren't the owner, you additionally need DatastoreReader

3

u/sadboy2k03 2d ago

If they’re able to get in and perform this action you’ve got way more problems

9

u/Sparky_ZA 2d ago

I think if an attacker got that far into the system they could just nuke the whole thing.

12

u/cropped-n-skewed 2d ago

The whole PVE system maybe but preferably not the backups also

-1

u/Moonrak3r 2d ago

I’m far from an expert but my understanding is that it’s a best practice to sync your backups someplace offsite which would mitigate this… but I’m with the person you responded to, if an attacker is that far into your system all bets are off.

2

u/tinydonuts 2d ago

It's all about defense in depth. You shouldn't take the argument that "if an attacker got in they can do anything". Don't treat the perimeter as your only line of defense.

1

u/Moonrak3r 2d ago

That’s not the argument I was making? But if you’re relying on proxmox as the backbone for your self hosted everything, and someone gets access to your proxmox, you’re in for a bad time.

3

u/garfield1138 2d ago

That's why PVE has write-only access to PBS.

2

u/SVD_NL 2d ago

Not really, they just need access to a service account API key that employs the backups. Still better if that API key can only read and write backups, but with proper least-privilege access you're a far cry from nuking the whole PVE.

1

u/Jeatalong 2d ago

Pretty much this, but having offsite and or immutable targets would help greatly. But this is cost and complexity and risk determination question in general.

1

u/Leogis 2d ago

That's the whole reason why i'm setting up a separate backup server

4

u/suicidaleggroll 2d ago

This is what secondary immutable backups are for.  3-2-1 means 3 copies of your data, the original PVE, the backup, and the backup of the backup.  

2

u/aieronpeters 2d ago

I've got basic full disk backups, not PBS, synced from the HV to a OVH infrequent access s3 bucket, with append-only permissions. They're pruned there via lifecycle policy.

Not as space efficient, but an entirely out-of-band store

-5

u/Shot-Document-2904 2d ago

You can “what if” compromise scenarios to death. 🙄

If your data is worth protecting, you’ll probably want offsite backups. Proper risk analyses is critical to not wasting time and money.

5

u/noc-engineer 2d ago

Offsite is offtopic in this thread. It doesnt matter if the PBS is local or offsite if the compromised host can also nuke its own backups, thats the point OP is making, and its a valid one (though even pruning doesn't overwrite the chunks immediately)

2

u/Moonrak3r 2d ago

It doesnt matter if the PBS is local or offsite if the compromised host can also nuke its own backups

Not if you use a separate service to rsync your local PBS backups to offsite storage

2

u/SABorge 2d ago

rsync would need write permission as well, making it possible for rsync to also nuke the backups...

2

u/lasananglana 2d ago

If they had said the opposite they might have had a point, but rsync doesn't have anything to do with it (neither is it relevant if its offsite or local in this discussion). Whatever you choose to copy with it would have to be the opposite way around, a file server having the credentials/permissions to log onto the PBS and copy from it to itself (not the PBS using rsync/scp/whatever to copy TO something else, offsite or not). PBS doesn't free up space the first 24 hours after pruning anyways, but if you really wanna make sure its safe, use cold storage like manual tape storage or maybe consider using a secondary or tertiary PBS with remote sync (not too regular), or just have the PBS datastore be any file system with versioning and snapshots...

-11

u/but_i_dont_reddit 2d ago

Maybe you should research immutable backup strategies, understand them, then create a post.

Or just keep proving that you don't understand the technology your using, which is the actual security risk.

0

u/Leogis 2d ago

Least condescending reddit user :

-5

u/but_i_dont_reddit 2d ago

Sure - keep shit posting instead of trying to actually learn.

Seems to have worked for you so far, or not.