[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] security for unattended backup models

From: Marcel (Felix) Giannelia
Subject: [rdiff-backup-users] security for unattended backup models
Date: Fri, 22 May 2009 16:45:09 -0700
User-agent: Thunderbird (X11/20071015)

We've been using unattended backups with rdiff-backup at my workplace for a while -- mostly set up like the directions at http://arctic.org/~dean/rdiff-backup/unattended.html . I'm about to roll out a new server, which will also do unattended backups, and I'm wondering about the pros & cons of two ways of doing this:

("fishie" = the server that is being backed up, as in the guide)

(1) Like the guide, a limited user on the backup server connects to fishie via ssh. This requires that ssh on fishie allow a connection as root, though it's restricted to only allow the rdiff-backup server command to run, and rdiff-backup on fishie is in a read-only mode.

(2) Reverse the ssh direction: rdiff-backup runs on fishie and connects to the backup server to dump its files there.

For fun and paranoia, I'm comparing what would happen if fishie or the backup server were somehow compromised.

In configuration (1), suppose someone has gotten root on fishie. They can do anything they want to the filesystem on fishie, which rdiff-backup will dutifully copy into the next increment. Question: is there any way for the attacker, who only has control of fishie, to somehow delete or alter the backup of fishie on the backup server? Assuming the backup server does not allow connections incoming from fishie, the attacker would have to replace or modify the rdiff-backup server command (which would not be difficult, since the integrity of that is enforced on fishie). The attacker would then have to somehow convince rdiff-backup on the backup server to modify its rdiff-backup-data directory in some way other than simply adding new files to it. How possible is this?

Configuration (1) has the advantage that it's very unlikely someone with root on fishie could do anything to either the backup server or any of the other hosts that are backing up to it. However, it has the disadvantage that it requires that all the hosts backing up to that server allow a root login via SSH -- even if it's restricted by host, command, and key auth only, that still makes me a little nervous. Also, if the backup server were compromised, it might be possible to exploit rdiff-backup --server in some way, which would give the attacker root on all of those hosts.

In configuration (2), suppose someone roots fishie. Now, since they need to have write access to the backup server it's much more likely that they'll find a way to nuke the entire set of backups for fishie. One way around that might be for the backup server to only let the backup process operate on a copy of the current mirror, and then run a test afterwards to make sure that it's still possible to restore the previous increment. Unfortunately that takes a huge amount of extra space and time to do every backup -- but it would be necessary, since all an attacker has to do to nuke the backups is change the current mirror so that the rdiff increments no longer work. That's a disadvantage for sure.

An advantage is that all of the hosts using the backup server do not need to allow root connections via SSH (or even allow any incoming SSH connections). Suppose someone roots the backup server. The other hosts do not allow remote connections, so there is no way to initiate an outbound connection to them. Since rdiff-backup is only pushing data out to the backup server from fishie, and never needs the ability to write files on fishie, it seems less likely that the attacker could somehow hijack the rdiff-backup process into doing something bad.

Thoughts/comments? My ideal solution is to have unattended backups that:
- Are protected from this kind of thing: http://news.bbc.co.uk/2/hi/technology/8049780.stm (summary: a site was completely destroyed when hackers gained access to it because all of their backups were on servers accessible to each other). - Make a compromise of the backup server very unlikely to lead to a compromise of all of the servers that use it.

Configuration (1) addresses the first point better, since it's a "pull" model, but (2) seems to provide better security to the other servers sharing a backup host. Depending how the actual underlying rdiff'ing works, there may be no difference -- if the backup server gets the final say in when to create an increment and when to remove a current mirror file (so that a compromised fishie sending it bogus data wouldn't be able to create something un-restoreable), then most of this e-mail is a moot point. But, I figure I'll be lazy and post it rather than dig through the source to figure that out :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]