Protecting against attack and ransonware

Features and Ideas
1

There are some posts about this already, also some discussions on github. Most of them old…

It’s not 100% clear based on the information I found. However, I did some testing, and the immutable copy idea looks like it works.

Do I understand this correct:

  • If I copy (pull from backup-repo server) my primary-repo files using immutable flags, (rclone … --immutable, or rsync … --ignore-existing), it is no way an attacker can destroy the backup-repo…
  • If I run forget on the primary-repo, I still don’t need to do anything special on the backup-repo.
  • Most of the files in the repo are static and on a new snapshot, restic only creates new index and data -files…
  • Is it safe to forget old data in backup-repo if i’m confident there has been no attack since my keep flags?

Or am I better of using restics copy command, like restic -r ...primary-repo copy --repo2=...backup-repo abc123. But then again, can the primary-repo then later destroy the data somehow in abc123?

2

TL;DR: As long as you technically ensure to only add data to your backup-repo and not delete anything, your are fine. But as soon as you start to delete things from your backup-repo, you are in principal vulnerable.

As you correctly pointed out, it is important that the potentially attacked server does not have any access to your backup-repo and that you only add data to your backup-repo.

restic forget just deletes snapshot files. If you ensure that you don’t delete anything on your backup-repo, this will not change the backup-repo at all.
If you however also prune (e.g forget --prune), restic may also recreate some files. This may cause duplicates in you backup-repo. (but still your backup-repo will be fine).

Correct. restic backup only adds files and doesn’t delete anything. This is also true for the destination repo within restic copy.

No. As soon as you start to remove data from your backup-repo, an attack could trick you into removing data you actually don’t want to remove.

In your scenario an attacker would have full read and write access to your repository and would be able to trick you into something. For example he could

  • know some security holes within restic and prepare data in your repo to exploit these
  • create some fake snapshots to trick your forget and prune runs into removing data you desperately need
2 Likes
3

Good guide. I agree with you on this.