Setting up Restic as a "WORM Server"

Getting Help
1

I’d like to get some feedback on this idea for a system design.

Goals

  • Have a backup of “everything” in a company.
  • This backup should be fully automated without any regular user interaction (no manual changing of USB disks etc.)
  • Prevent access from evil hackers who want to delete or encrypt the data (prevent ransomware attacs), even if they get into our infrastructure.

System Design
My current idea for a system design looks like this:

  • A server computer with a large enough RAID of data disks to host the restic repo and a separate system disk.
  • Operating system: a small Linux distro (maybe Debian with only necessary packages installed).
  • Restic repo is exposed to the local network via rest-server
    • --append-only option set
    • --private-repos option set
    • A local cron job takes care of daily forget and prune actions, so this cannot be triggered from the outside. Retention policy uses --keep-within... to avoid deleting stuff in case no new backups come in.
  • No other servers running on this computer, not even SSH.
    • This means, whenever an admin has to do anything on this system, they have to go to the server room and use the display and keyboard attached to the hardware.
  • Firewall prevents this server from connecting to anything at all with the exception of the strictly necessary ports / targets for
    • exposing the rest-server to the local network (maybe limited to distinct IPs)
    • getting system updates (this might mean allowing a lot, though…)
  • The system should be configured to keep itself updated (unattended upgrades or a simple cron job).
  • Each client should have a separate user and password and use a separate sub-repo.
  • A backup of the passwords should be kept on paper (maye as QR codes) to ensure access in critical situations.
    • They also need to be copied to the clients in some way, which means any attacker who is on our servers will probably have access to them, too :frowning:
    • Admins should also have a copy at hand (in their KeePass DB) to be able to access the rest-server to restore contents if necessary.

What do you think about this setup?
Would this prevent the evil guys from successfull ransomware attacs?
Any ideas to improve this?

I am aware that this won’t do much to prevent attackers from reading our data. But I think that would be much more complicated to achieve (since it’s not enough to protect the backup as long as they can access the original data on the servers).

Thanks in advance for your thoughts on this!

2

In many respects I’m using this setup and it works well. Just make sure to integrate some method of monitoring backup status, testing restores, keeping an eye on storage space and health.

No reason to disable SSH entirely. If it’s set up securely it’s very secure, particularly if it’s only accessible from inside the network on its own VLAN, with certificate-based login only, and root access disabled.

3

Make sure that you use restic 0.12.1, with older versions it might be possible to trick forget --keep-within to delete current snapshots.

I’d also recommend to run check from time to time, to ensure that the repositories are OK.

I guess the idea here was to make sure that even a compromised admin workstation won’t be enough to wipe out the backups?

1 Like