[Top][All Lists]

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

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

From: Maarten Bezemer
Subject: Re: [rdiff-backup-users] Post-setup questions
Date: Thu, 18 Aug 2011 22:25:40 +0200 (CEST)

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.



reply via email to

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