Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
1  
3  
Take a look at tarsnap is has 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. The backups are encrypted. –  Iain Feb 12 at 20:57
    
ALL SaaS solutions (just like on-prem devices with internet connectivity) are subject to intruders. You can only do so much. Investigate the SaaS provider's methods for encryption and security and decide. Or deploy on-prem and don't let your backup server have internet connectivity. –  TheCleaner Feb 12 at 21:09
    
I mean intruders to my server, not intruders to the SaaS provider. Clarified my question. –  Christian Feb 12 at 21:14

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
    
Thanks for your detailed answer. As I can't setup a separate backup server (small business clients often can't afford that), I guess I have to find some service like tarsnap and additionally do some off-site archiving. It's hard to find such services, and even harder to find a place to ask for such services ;) –  Christian Feb 13 at 9:13

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).

share|improve this answer
    
That's actually a pretty interesting and novel idea. I regret that I have but one upvote to give it. –  HopelessN00b Feb 13 at 14:49

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.

share|improve this answer
    
Thanks, I guess I'll try that. –  Christian Feb 13 at 9:15

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.

share|improve this answer
    
IMHO it's not that obvious, as most backup services I found don't provide a solution to this problem. tarsnap sounds good, but I'm a little bit afraid of vendor-lock-in (you have to use their tar command. I'd like to use tools like duplicity that implement encryption but don't rely on some specific transfer protocol). Amozon's S3 seems to provide a similar solution (write only storage), and there are some S3 clones, so that I possibly have more options. –  Christian Feb 13 at 9:07
    
@Christian: Tarsnap uses Amazon S3. –  Iain Feb 13 at 9:16
    
I would really appreciate if you could tell me a link to some article discussion similar services or any other tip where I could find or ask for such services. I have been searching for hours, and could not find any. –  Christian Feb 13 at 9:19
    
@Christian: We don't generally do product or service recommendations (as you found out before someone reworded your question). –  Iain Feb 13 at 9:21
    
My point was that you push to tarsnap using their tar-like program, but the S3 protocol is supported by many tools, including duplicity which I use. Also, there are some S3 clones (but I'm not sure if they support the features needed for "write only" pushes). –  Christian Feb 13 at 9:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.