> 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 _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
