Hello! Couldn’t find answers to some of the obscure aspects of Repository Server.
My use case is several semi-trusted hosts that backup some of their data to a single RS.
Is it safe to expose RS to internet with NGINX? (assuming good passwords on all accounts).
(TL;DR How safe it is to expose repository to untrusted hosts and users with default ACL rules?)
Consider following setup - there is a server (RS) and two of its clients (A and B). Both of the clients have no access to raw repository files and only can interact with RS. ACLs are default.
Let’s assume that client B is misbehaving. Either wildly inaccurate clocks (hours or even days out of sync), or it was captured by an evil virus that desperately want to wreak havoc on any data it could get (unlikely, but I’m theorizing here a bit ).
What kind of data corruption can (or cannot) happen as a result? Obviously I wouldn’t rely on snapshots from B, but what about previous data from A? Or integrity of a repo as a whole? Could B do something bad and screw something other than it’s own snapshots?
I’m migrating from borg. It has option –exclude-if-present NAME which
exclude directories that are tagged by containing a filesystem object with the given NAME
So basically I could place some empty marker file NAME and it will ignore the entire directory that contains it.
Is there any alternative to it in kopia? Closest one I found is gitignore-like rules, but this requires marker files to contain said rules - empty ones won’t do as they are no-op.
I have some snapshots (and their blobs) already in a repository, that were put there without any compression. Any way to compress those blobs after the fact?
There are some things to consider if you want to expose your server to the internet:
- Currently, as far as I am aware, there is no native append only mode. There was some interest around it, I assume that it will become a feature at some point, but as of now it doesn’t exist. What this means is that there is a possibility that a malicious actor could craft an attack to make your backups useless (e.g. by asking the server to delete all snapshots, which doesn’t require filesystem access). See also this GitHub question. Some cloud based system have append-only options, so it might be more safe in those contexts.
- You are in charge of making sure that you have systems in place to prevent brute-forcing of passwords. As far as I am aware, Kopia is not setup to reject brute-forcing attempts. So as long as you have appropriate mitigations in place, it may potentially be fine.
I am not unfortunately not remotely experienced in server setups so I cannot help you on that front, but in terms of the repo itself, you might want to carefully consider whether or not the absence of append-only mode affects you.
As for the marker, Kopia implemented CACHE.DIR tag specification which allows you to place a marker file and with the appropriate options, allow you to exclude all directories containing that file. I believe that would be the closest to what you are looking for short of using exclude rules.
I don’t think there is a direct way to compress all the files after the fact. The cleanest way as far as I am aware is to create a new repo, enable compression, and migrate the old data to the new one see this GH issue. This might not be a huge issue if you have plenty of space and some spare time.
Thanks for answers @stpr, clears it up somewhat!
Some followup, if you don’t mind:
What do you mean by “all snapshots”? All that are in the repo, regardless of user, or all that malicious user has access to (again, assuming default set of rules here)? I’m kinda fine with second case, but first one would be a showstopper for me.
Also, “doesn’t require filesystem access”, but it would require this kind of command to pass ACLs checks decribed here (with some promising mention of APPEND access level). Right? Or are we talking about an attack on server that bypasses this as well?
Of course, I’m not asking for a guarantee of zero holes, there is always a possibility of some 0-day bug that ruins everything. I’m just asking whether Repository server is prepared to handle malicious clients or does it give full trust on them to not break things?
I am not talking about attacks on a server (that is basically game over at that point), but I am talking about a malicious client issuing a
snapshot delete command. A non-compromised account would issue via
kopia snapshot create command to create a snapshot of some directory. Likewise, if the malware has enough knowledge, it might be able to (in theory) issue a
kopia snapshot delete and delete all snapshots associated with the users file. The default ACL does not allow one user to strictly access another users data, so this is not possible to do across all users (though as listed in the page you linked, it might be able to do that at object level, but this is too hard to do so we can assume that this is impractical).