Selfhosted

60320 readers

564 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

How do you protect a remote backup from a compromised account? (lemmy.zip)

submitted 1 week ago by eyesaremosaics@lemmy.zip to c/selfhosted@lemmy.world

40 comments fedilink hide all child comments

Let's say you have access to a remote machine and use it to copy backups occasionally, eg with rsync. Your local machine has credentials stored that allow write access on the remote machine, however if the local account was compromised that could also allow access to the remote machine and the data stored there.

How can you grant access to an account to write remotely, but also protect the data from this account? One possibility could be to change the permissions on the data after it is copied to prevent deletion/interference, although I'm just making this up. Is there a standard practise for this?

you are viewing a single comment's thread
view the rest of the comments

[–] pgo_lemmy@feddit.it 6 points 1 week ago* (last edited 1 week ago) (2 children)

If the main site gets compromised the credentials there must be considered lost and known to che attackers.

with a pull backup that's not an issue because the main site has no access to the remote system; it is a process on the remote site that has credentials to access the main site and not the other way around.

the remote system may ~~receive~~ retrieve a compromised copy of the data, but the attacker cannot tamper with previous backups so recovery is still possible.

[–] lIlIllIlIIIllIlIlII@lemmy.zip 1 points 1 week ago

This is the main reason I had in my head about pull backups. Thanks for the explanation.

[–] non_burglar@lemmy.world 1 points 1 week ago

That makes sense. I use NFS, so there are other controls for security because "offsite" is another building on my property, but still in the same pool of subnets...