How secure is duplicacy?

[Droolio]

I mentioned this before, but if the password is compromised, changing it might not make a difference (depending on how far an attacker has got access to snapshot and chunk files). I don’t think this is a problem with Duplicacy in itself or can be mitigated - choose a complex password from the outset and, aside from any coding vulnerabilities, it’s probably about as secure as it’s going to get? (This is of course assuming an attacker already has access to your local/ssh/cloud storage.)

A example: you have to take care of your keyring files

Aren’t those partially encrypted by the OSs keyring / credential management? And do you really need to back them up? They should be recreated when you enter the master password…

[towerbr]

They should be recreated when you enter the master password…

I’ll do some testing on a different machine …

[gchen]

If the machine is breached, they can easily recover the real passphrase, and changing the keyfile passphrase is no going to prevent anything.

This is true, but in this case the attacker would already have the access to the original files, so I don’t see the point of protecting the backups.

Malware/ransomware can effectively kill the keyfile and make backups useless.

As long as the config file is untouched (which is stored in the storage), you should be able to access the backups with the storage password.

[thwn]

As long as the config file is untouched (which is stored in the storage), you should be able to access the backups with the storage password.

Is my understanding correct, that without the config file, I wouldn’t be able to restore anything, even if I have my storage password?

If so, this config file becomes the most vital file in my eventually TB-sized Wasabi bucket? A missing junk could render a file useless, but a missing (or corrupt) config converts my whole backup into a brick?

If my assumptions hold true, what is the recommended way dealing with this? Copy away the config file after every backup run?

Sorry, if this is answered elsewhere, but searching for “backup” and “config” in this forum yields quite a few hits

[akvarius]

A write-only storage would be one way to protect it against malware. But not against hardware failure.

Edit: about immutable storage:

Duplicacy chunks are immutable = I can use an immutable target storage? (where files can't be changed once uploaded)?

Wasabi has a “Compliance Mode” option for buckets, description below: “Compliance mode prevents the deletion of any objects and provides additional information to prove that the original data is not modified since the time it was stored. Data is immutable for the length of the specified retention time.” I’ve also setup my SFTP targets with a username which doesn’t have permission to delete/modify files. Things look to be going ok so far. I’ve done a few smaller tests and they completed withou…

[gchen]

Is my understanding correct, that without the config file, I wouldn’t be able to restore anything, even if I have my storage password?

This is correct.

If so, this config file becomes the most vital file in my eventually TB-sized Wasabi bucket? A missing junk could render a file useless, but a missing (or corrupt) config converts my whole backup into a brick?

I believe Wasabi can be trusted for storing a small file that is usually not changed. If you’re really concerned, you should save this file to multiple places, like on your own computer or another cloud storage.

[akvarius]

Wondering if we could use a config file from a bit-identical copy?
Duplicacy Add -copy (wasabistoragename) -bit-identical samename sameid C:\something\forconfigbackup

(It would not need the chunks for this purpose)

If this does not produce a reliable copy, maybe @gchen could add an option to Duplicacy for extracting a copy of the config for safekeeping. (If not the user must use other tools to do this)

[towerbr]

Wondering if we could use a config file from a bit-identical copy?
Duplicacy Add -copy (wasabistoragename) -bit-identical samename sameid C:\something\forconfigbackup

I do exactly that. I have an empty extra copy (no chunks) of all the storages I use.

I set it up just at the time of the discussion above on this topic, over a year ago.

[Christoph]

I do exactly that. I have an empty extra copy (no chunks) of all the storages I use.

Could you elaborate? What exactly do you do? (Sorry if the answer seems obvious. It probably is for anyone using those commands on a regular basis.)

[towerbr]

I simply created a storage copy ( add command), but I don’t create backups to that add-ed storage. So I have a copy of the config file, but there are no chunks or snapshots files.

[Christoph]

Now I get it. That would indeed be something worth mentioning in the documentation. Not sure exactly where. One option is to mention it under the init command because people will see it there. But it wouldn’t be consistent as this is about the add command. So maybe put it there? Or create a new How to on “added security” or something.

[towerbr]

Maybe mention in the init command page something like:

“It is important that you back up the config file that was generated on storage. If it is lost or otherwise corrupted in storage, you will lose access to your backups. You can do this by using the add command to create a copy of your storage or by directly copying the config file and storing it elsewhere off the storage (like on your own computer or another cloud storage).”

[Droolio]

Wasn’t there supposed to be a new feature whereby Duplicacy would cache the config file locally on the client?

Also, wouldn’t it be a good idea for the init, add and password commands - anything that writes to the config file in the storage - to also create a config.bak in there as an extra precaution? And if amending an existing config, to put the previous copy as config.old?

[thwn]

Thank you for your insights, @akvarius, @gchen, @towerbr, @Christoph and @Droolio. Very helpful.

I have no reason to not trust Wasabi to take care of the config file. I am more concerned about myself making a mistake (the sort of “oh, I thought this was my test bucket in this window here” or inadvertently triggering the wrong command from shell history).

It’s more of an operational thing than security related, IMHO (my mistake of course, since I hijacked the thread).

I like Droolio’s idea of storing the config redundantly on the remote storage. Why not put a verbatim copy of the config file in every of the 256 top level chunk folders? Would add a mere ~ 350 KB of data, but a lot of resiliency.

[bkeeper]

I agree,
We could implement auto-backup for the app and storage config.
Add the option to include logs. (which would compress really well)
backup to storage or local zip.

[towerbr]

Also, wouldn’t it be a good idea for the init , add and password commands - anything that writes to the config file in the storage - to also create a config.bak in there as an extra precaution? And if amending an existing config , to put the previous copy as config.old ?

Nice idea! +1 for this feature.

[markus]

I fully agree with your comment: as long as the storage is accessible from the client machine only some sort of write-only mechanism on the storage machine itself may help against typical malware/client breach/password re-use scenarios. This is THE major problem of push backups to storage backends and a real show stopper for many backup strategies.

I’m currently using duplicacy to backup to a storage on a freenas box which gives me the possibility to “freeze” the storage by creating ZFS snapshots of the storage. In case of a breach on the client machine the attacker could delete the whole storage and I would still be able to roll back the ZFS snapshots to the point in time when the storage was intact.

Another possibility would perhaps be to have a daily task running on the storage system which changes user permissions on the storage files to read-only for the backup user and do a chown in order to keep the backup user from changing permissions. According to my understanding this would only harm “prune” commands because the “backup” commands will only add files to the storage.

[dgcom]

Another possibility would perhaps be to have a daily task running on the storage system which changes user permissions on the storage files to read-only for the backup user and do a chown in order to keep the backup user from changing permissions.

On Linux you should be able to set immutable attribute: chattr +i backup/, root is required to do that and then only reset it for a period of time when prune is running (perhaps on the storage server itself).

[markus]

After some time, I have re-arranged my backups. I’m now using duplicacy to backup from NAS1 to NAS2 via sftp wherein the sftp user is called backup.

Using your suggestion on the immutable attribute, a root cronjob on NAS2 executes the following commands:

chown -R root:backup *
chmod -R 755 *
find . -type d -print0 | xargs -0 chmod 1775

The last command sets the so called sticky bit for all directories of the storage. Thereby only the owner, which is now root, can delete or change files within that directory. Because the backup user is in the backup group, NAS1 connecting via the backup user can still add new files with the next dulicacy backup run.

The prune command is running as root on NAS2. For this purpose I had to set up a local repository (source) which is more or less empty but is connected to the same storage (target) to which NAS1 is connected. Using the “prune -all” allows to prune the snapshot revisions from the NAS1 backup.

Hope this helps some people to set up a backup which survives a malware attack or a breach.

Any further suggestions are always welcome.

[tallgrass]

One suggestion for cloud-based storage is to provide an access key which doesn’t have delete permissions. I only use Backblaze B2, so I don’t know if this works on others (in part perhaps because of the versioning you have to setup on Backblaze).

If your “normal” key can’t delete files (or even overwrite them), then your data can stay safe. I have a “prune” key which has delete permissions but I only use that interactively and have a script which requires that I unlock it with my PGP key. As such, it never sits around on disk unencrypted and the only time my backups are deleted (pruned) is when I do it. Of course this means I can only prune my storage manually.

I’m sure other cloud storages may have to be setup a bit differently, and the key permissions tweaked accordingly, but the above works for me. It’s probably not perfect, but it gives some protection from someone extracting my Backblaze API key from the system and reusing it to delete backups.