the "hacked server" issue

[ThomasWaldmann]

If a server that gets backed up with borg gets hacked, the attacker potentially could also invoke borg to delete the backups from the (remote) backup.

See also these related attic issues:

• Restrict "serve" command to "create" operation only
• Pull mode
• Subkeys

---

💰 there is a bounty for this

[ThomasWaldmann]

restic/restic#187 similar discussion.

[ThomasWaldmann]

Just to keep an idea (could be added to docs / faq after discussion):

If one runs either LVM or btrfs (or anything else that supports snapshots) on the backup repo server, one could just do regular snapshots of the volume that has the repo. That way, even if somebody deletes the repo contents remotely via borg from the production machine, one could still roll back to a previous snapshot.

[ariselseng]

In my setup I have different private keys for each of my web servers stored on my backup server. During the day there is no backup script or ssh key/repo key stored on the web servers. At the backup server, I have a script which pushes the another script along with ssh key and borg key to each web server. I also sync ~/.cache/attic back and forth between the backup server and each web server. After each backup for each web server is finished, I remove the backup script and the keys from the web server.

I do all this because of two things. One for a bit more security (almost through obscurity) and at the same time some peace of mind. I can changes for each backup at one place. I also share one repo for all of my web servers so that I get the dedup effects.

All this is very hacky. I would really like to have some kind of setup where all this is covered inside borg. Maybe borg on the backup server could start up a server over ssh to the web server, and talk over stdin or some kind of reverse ssh tunnel? This would be like the rsync-over-ssh model. My main concern is that I dont trust my web servers 100%, but I trust my backup server a lot more, as I have put a great deal more care for it than all the web instances.

[RonnyPfannschmidt]

how about a --serve-restricted which only allows to upload a new archive

[ThomasWaldmann]

@RonnyPfannschmidt "create" requires "set" k/v ops, as "delete" does also.

[RonnyPfannschmidt]

if you only allow adding new keys thats fine

alternatively there still is the idea of a bundle operation (which bundles up a local compressed set of k/v pairs and ships it to a server)

[anarcat]

how can we possibly keep this from happening while at the same time allowing backups to be purged?

another backup tool, restic, completely ignores that requirement, stating from the start that it is outside its threat model - maybe it's something we should consider?

writing up a threat model, actually, would be quite useful. :)

as an aside - i think the only solution to this problem would be to allow pull operation (jborg/attic#175), which has other uses as well...

[ThomasWaldmann]

Allowing purges is not a requirement for a machine that just needs to get backed up.
The purges could be done from another machine, with different credentials maybe.

But the real problem lies a bit deeper: the key value store does not "know" what precisely you are doing, it just sees key/value operations.

[anarcat]

a copy of a comment i made in jborg/attic#175 (pull mode):

after a quick review, it seems that Obnam does "pull" through sftp. it has a VFS layer to access filesystems locally or through SFTP transparently that is pretty neat, but in the end all this happens through SSH anyways, so i guess that people wanting to implement pull backups now could use sshfs to mount the client from the server side and run attic through that.

[ariselseng]

The problem with this id performance when you have lots of folders. Even if no files are changed it takes ages to check state.

On 6 October 2015 07:22:27 CEST, anarcat notifications@github.com wrote:

a copy of a comment i made in jborg/attic#175
(pull mode):

after a quick review, it seems that Obnam does "pull" through sftp.
it has a VFS layer to access filesystems locally or through SFTP
transparently that is pretty neat, but in the end all this happens
through SSH anyways, so i guess that people wanting to implement pull
backups now could use sshfs to mount the client from the server side
and run attic through that.

---

Reply to this email directly or view it on GitHub:
#36 (comment)

Sent from my phone.

[anarcat]

not sure how you are going to work around that problem if the remote end is behind an SSH tunnel. you need to list those directories and stat those files somehow.

[ariselseng]

You solve that by having a remote binary making file list locally. Like rsync.

On 6 October 2015 08:00:29 CEST, anarcat notifications@github.com wrote:

not sure how you are going to work around that problem if the remote
end is behind an SSH tunnel. you need to list those directories and
stat those files somehow.

---

Reply to this email directly or view it on GitHub:
#36 (comment)

Sent from my phone.