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

[Grant]

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

Yeah, I guess it's between allowing root read access of each system if
the backup server is compromised (pull), or allowing read/write access
of only the backups on the backup server if one of the systems is
compromised (push).

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

Good point.  Although it isn't surprising, I didn't know sshd_config
allowed that sort of control.

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

If I were to set up a separate user for each pushed backup and one of
the systems were compromised, only the compromised system's backups
would be accessible to the attacker (read/write unfortunately).

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

That would be more secure, but I'm trying to set up unattended backups.

>> 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 suppose I may as well just leave it at 5%.

>> 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 don't think I follow (again).  The backup server drops its own
important files onto the USB hard drive that is directly attached to
it.  Anyway, that problem would be solved if I used your
'PermitRootLogin without-password' advice above.

- Grant