Re: [rdiff-backup-users] Post-setup questions

[Maarten Bezemer]

On Mon, 15 Aug 2011, Grant wrote:

> > If someone steals the private keys on the backup server, they already have
> > access to all your files. Although I admit there is a subtle difference
> > between 'all your base are belong to us' and actually using those keys to
> > plant malware on your laptop, but you will be screwed either way.
> > That's the reason why I keep my backup server unreachable from the outside
> > world.. not running any services on public IP address.
>
> I don't quite follow.  You're saying it doesn't matter that the thief
> has root read access on each backed-up system via the SSH keys because
> he would already be able to read all of the important files from each
> of those systems via the backups on the compromised backup server?

If someone has found a way to gain access to the private keys that should 
only be present on your backup server, then all the data on your backup 
server should be considered compromised. That could very well include 
sensitive files that are copies of sensitive files on your 'real' systems.
Of course, having access to these private keys could also give an attacker 
access to any file currently on the 'real' systems, but that type of 
staged attacks is not very common. (At least not yet...)


> I realized today that since the backup server needs root access on
> each of the machines, I won't be able to disallow root logins.  Is
> that correct?  If so, isn't that a major drawback to pulling?

You can disallow root logins using password authentication, and set 
PermitRootLogin without-password
in /etc/ssh/sshd_config. That would be secure against any dictionary 
attack launched against the root account.

And, looking at the whole subject from a different angle: pushing also has 
the large drawback that in case your laptop is stolen/lost/whatever, and 
you use an ssh key for rdiff-backup to connect to your backup server, you 
risk not only losing your 'real' systems, but the backup server can also 
be compromised it an attacker starts using that key.

Both types of private key abuse could possible be mitigated by using 
passphrase-protected private keys. Then you're back at the 'default' risk 
of keyloggers intercepting these passphrases...

Bottomline: you have to define your trust levels ;-)


> Is it necessary to reserve 20GB on a 1TB disk?  If the OS is not on
> the USB backup drive, is there any scenario under which I would need
> space reserved for root on that disk?  I would think free space on the
> OS disk would be all that's necessary if the USB drive fills up.

If you want to recover from a backup that failed half-way through due to a 
Disk Full situation, you need even more disk space to regress to a sane 
state. You could do that by temporarily reducing the reserved-for-root 
percentage. Another way could be to just create a few GB of placeholder 
files you could delete on these occasions. That's up to you to decide.


> I tried to set this up today but I ran into a problem.  My backup
> server backs up its own files to the USB drive.  If that operation is
> conducted as a normal user, it can't read all of the necessary files.
> If that operation is conducted as root, the backed-up files are
> written as root and the remote system can't read them via rsync unless
> I allow root logins.

Try doing the local operation through the localhost network ;-)


> I also had a hard time restricting the SSH key on the backup server to
> the rsync command and read-only.  Can that be done?

I know there have been some issues regarding rdiff-backups 'restrict read 
only' switch, but as far as I know, these should be solved. Not using them 
myself, so not entirely sure.
Restricting a key to multiple commands would be a harder thing to do.. 
probably better to just create two (different!) keys and define each one 
with a different "command=...." in the authorized_keys file.


HTH..

--
Maarten