"Push only" backups?

Question

I have a server which pushes its backups to some online backup space. An intruder (on the server that pushes to the backup space) can access the backup space and mess with the backups, because the credentials are on the server. I'd like to fix this problem without setting up a backup server.

Does anybody care about this problem or is it even a problem at all?

Is there a name for this problem, and what are possible solutions?

Answer 1

The problem you're referencing is really a problem of securing/protecting your backups once you've made them.

1. The standard approach to this problem is to use some form of removable media that's taken off site on a regular basis.

   • Typically, with LTO-tape media, you'll have all your backup tapes rotated off site on a regular schedule, such that the only backup tapes that you have on site are the ones actively in the tape library to record backup data.
   • I've also seen this done with USB flash drives and removable drives, occasionally. This approach protects your backups from both malicious action, and physical disasters.
     
     
2. A slightly different take on this approach is to use write-once media, so that backups can't be deleted once they're made.
   • CDs/DVDs or WORM LTO media, generally. Usually this approach is somewhat more limited in scope, because it can get expensive and effort-intensive pretty quickly.
     • For an example, in a high security environment I worked in, we had scripts to copy our server logs over to a backup server on a continual basis, and then burn them to a DVD every night, as a mechanism to preserve the information in them. In the event that something went wrong or we got hacked, wiping out the logs on the server in question wouldn't do much good.

With the proliferation of disk-to-disk backup systems these days, neither option is always available or feasible, but there are many ways to achieve the same thing. They basically fall into two categories.

1. One category, as mentioned in the comments, is the use of public key cryptography to separate read and write permissions at a cryptographic level.
   • One such service is tarsnap. Since different keys are used to read and write data, you can store each key in a different place, so that an attacker who compromises your backups cannot read them.
   • Tarsnap is far from the only provider of such a service, and you could even roll your own solution with widely available public key cryptographic tools. Presumably, however, they'd still be able to "mess with" the backups (destroy or corrupt them).
   • This is most useful in compliance situations, or situations where data privacy is important, and the worry is about an attacker being able to get at the information (read your backups), but does not protect against an attacker destroying or corruption those backups.
     
     
2. The other category, is to actually segment the permissions, so that your backup server does not have the permissions needed to alter or overwrite data.
   • The obvious way to do this is by only giving your backup server/service read and write permissions at a filesystem level, but not modify or delete permissions.
   • You can achieve the same thing by separating the backup server from the server that houses the backups, so that compromising the actual backups involves more than just compromising the server that's use to create your backups.
     • This is the approach I'm using now, for $[corporate_overlord]. Backups are replicated offsite (disk-to-disk system), but the primary backup node, and the off-site node are accessed using different accounts, so compromising one node does not allow the other to be compromised. Each node can read the other's data, but each node can only modify/delete its own data.
       
       
3. The two approaches can even be combined, for the truly paranoid/best of both worlds.

Finally, even if you're using a disk-to-disk scenario, there's no reason you can't implement a solution that effectively takes your backups offline. You could set up a system to automatically take the server/disk that houses your backups offline after the backups complete, and brings it back online only when the next backups are scheduled to occur, or less drastically, remount the volume storing your backups as read-only. Seems like more work than setting up permissions as above, but is possible.

Answer 2

People obviously care about this problem, that's why services like tarsnap exist. This uses separate read and write keys.

To perform a backup you only have to have the write key available.

You can keep the read key safely away from the system being backed up and have it available only when you need to recover files.

The backups are encrypted using the keys before being sent to the backup service.

Answer 3

My understanding is that a standard svnserve server (one that handles the "svn://" or "svn+ssh://" protocol for a subversion version control repository) allows people to commit new versions to a repository, but makes it practically impossible to "lose" versions previously committed to the repository.

(Your online backup space may have already set up such a server for you).

Answer 4

The way we handle this is to use amazon S3 which allows new objects to be written but not removed by the credentials on the server, and then use versoning on the bucket so even if the intruder stores bad backups the old (good) ones are still there.

Has worked just fine so far.