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

[Marcel (Felix) Giannelia]

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

~Felix.