13

Consider this scenario: I have linux server which is automatically backed up daily to some remote location via rsync or something like this. Everything is fine until some bad guy gains access to server, finds my automated backup script and deletes everything form backup server too.

I am trying to find some remote backup utility which allow only adding backups remotely, but not removing them. I don't now how to make anything that uses ssh write-only, and I tried to find something that doesn't use ssh, but found only Box Backup.

I now it's possible, but I want to know if there is some canonical way to achieve this.


I've got lots of answers, thanks to everybody!

7 Answers 7

11

The simplest thing would probably be to go the other way with the backups, ie. pull from the backup server. That's how I run my backups with rdiff-backup.

9

If you're doing a naive backup (single copy, overwriting all data) then there's no way of achieving what you want -- an attacker can always "backup" a pile of empty files (or an empty file set) which will result in all your data going bye-bye. So, I'm assuming here that you're doing proper archival backups, and you're monitoring your backups well enough that any attempts to eradicate the backup by sending an empty backup set will be detected before any permanent damage is done.

If your rsync-over-(presumably)-SSH uses a forced command to run rsync on the destination, then you're about as secure from deletion as you can be. Since you only want to run a specific rsync command, you can hardcode all the arguments and then the only thing it can do is write new data. Archiving is simple enough by backing up to a new tree each time and associating unchanged files with the previous backup using hardlinks, which saves space and transfer time.

The other way to go is to use pull backups, where the backup server initiates and manages the rsync operation -- this means that the client machine doesn't even have the ability to run a restricted rsync command, which means the attacker has no power to delete files.

This all assumes that your backup server is secure. If the attacker can get access to it via another means, you're boned regardless of what you do.

5

This is one of the features I like about the Tarsnap backup service. It allows me to to create subkeys with read, write and/or delete capabilities.

On my servers I generally keep subkeys with read and write capabilities. At times when I need/want to prune old backup archives I do that using the master keys from my local desktop computer.

Note that Tarsnap is in itself a storage service. You can not use the Tarsnap software to create backups against your own storage servers.

3

Attempt to use a writeonly filesystem layer that will mask your actual destination.

I found an example here, using FUSE.

You can also use an encrypted filesystem that anyone can write into, but needs your key certificate to be altered (seems the most secure option, although it probably needs more planning during the implementation). If you go this way see check WOCFS (Write Only enCrypted FileSystem) and TrueCrypt

So, while the first solution will "mask" your filesystem, that is actually stored elsewhere within the machine and can be altered to the system users with permissions, in the second solution it can only be altered with the proper keys.

0
3

This was probably not the case long time ago when the question was asked, but nowadays there are different backup utilities that support this either directly as an option or through simple scripting/additional settings.

One of the the terms being widely used to refer to this functionality is "append-only backups".

Borg backup has this functionality as a built-in option. Restic can be set up to talk to a remote filesystem which does not support delete operations or to rclone server which will serve any backend supported by rclone to restic, with the rclone built-in option to serve in append-only style.

Additionally when backing up to a cloud, many cloud providers (AWS, B2, Wasabi etc...) support having buckets which do not allow deleting of data or indirectly through having eternal history for all files, effectively not supporting deleting them (this setting is sometimes set up per access key, not per bucket itself).

(Update: Someone edited away links to what they called "newely created products". Note that none of those products are new, they are very well established, and some of the biggest products in the backup sphere. I have no affiliation with those products and they are all free and open source. They are about as new as rsync or duplicity (exaggeration to illustrate a point). The question specifically looked for ways to implement this, and links to specific solutions (as opposed to generic "some software probably has this function") are warranted here. In fact, I came to this question also looking for specific solutions.

2

ftp: for example vsftp has an option to disable deletions so you can only upload. Then on the other side you create a script that deletes backups older than x days. I use this option, on the main server backups are simple backups using tar+gz, they are uploaded to a nas server via sftp and then the nas server deletes backups older than 7 days.

rsync: rsync server has an option to disable deletions so that may also work for you, but you have to use rsync protocol/server. refuse options = delete

But then you would have to manually delete the 'delete' files once in a while.

1

So, I learned that there are two basic strategies:

  1. Pull backups from server being backed up using something ssh-based
  2. Setup sshd on backup server to accept only safe commands

Quote from rdiff-backup manpage related to second strategy:

Although ssh itself may be secure, using rdiff-backup in the default way presents some security risks. For instance if the server is run as root, then an attacker who compromised the client could then use rdiff- backup to overwrite arbitrary server files by "backing up" over them. Such a setup can be made more secure by using the sshd configuration option command="rdiff-backup --server" possibly along with the --restrict* options to rdiff-backup. For more information, see the web page, the wiki, and the entries for the --restrict* options on this man page.

--restrict-update-only path
          ike --restrict, but only allow writes as part of an incremental
          backup.  Requests for  other  types  of  writes  (for  instance,
          deleting path) will be rejected.

Of course your backups must be incremental, and you should have some monitoring system in place, to prevent scenario when hacker backups junk data to eventualy "displace" real data from your incremental back up system.

Not the answer you're looking for? Browse other questions tagged .