Re: [rdiff-backup-users] Post-setup questions
On Thu, 18 Aug 2011, Grant wrote: 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). No. It would indeed be read/write which is a no-go for most serious backup systems (lose the primary, and all you have left is a compromised backup, potentially no backup at all). And another risk would be that the attacker finds some way to elevate her privileges on the backup server due to some but in rdiff-backup, python or something similar. In which case the entire backup server would be compromised. 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. You said you backup the backup server's own files to the USB drive. When doing that with rdiff-backup running as root, the backup will also have file permissions and ownership preserved (mostly). When you run that rdiff-backup process as a normal user (backup side) to back up files from root@localhost (source side), just pretending that it is a remote host, then the backup tree will be accessible by non-root rsync user. -- Maarten___ 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
Re: [rdiff-backup-users] Post-setup questions
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 ___ 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
Re: [rdiff-backup-users] Post-setup questions
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
Re: [rdiff-backup-users] Post-setup questions
On 18/08/11 22:47, Grant wrote: 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). Practically this seems to me a pretty good solution. Push your backup from your laptop to a dedicated user on the (GNU/Linux) backup server, ensuring that its users cannot access (read or write) other users' data: To ensure privacy for any new users on the backup server, in /etc/adduser.conf add/alter: DIR_MODE=0700 For existing users on the backup server, run: sudo chmod 700 /home/* When you create a user on the backup server, don't set a password i.e. login is only by public/private key authentication. Use a dedicated private key on the laptop for the backup, and put its public key on the backup server at (and only at) /home/[user]/.ssh/authorized_keys. You need to be happy that there is nothing readable (or writeable) by a non-privileged user on the backup server that you would not want a hacker to see e.g. at /var/ or /opt/. For tighter security on the backup server you can limit the user to running a single command e.g. http://www.cmdln.org/2008/02/11/restricting-ssh-commands/. If the laptop is stolen, remove the corresponding public key from the backup server so that the laptop can no longer get access. And even if the thief moved fast enough to get into the backup server before you could remove the public key, she could only access the backup history for that laptop, and she has the laptop's data already... Dominic ___ 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
Re: [rdiff-backup-users] Post-setup questions
On Sun, 14 Aug 2011, Grant wrote: That sounds like a great idea. I'll set up openvpn and switch from pushing to pulling. BTW, is the read-only restriction on the public SSH keys the only advantage of pulling vs. pushing? Are there any drawbacks? In a pull arrangement, if the private keys on the backup server are stolen, the thief would have root read-access on each system? 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. Would it be safe to reserve zero space for root on the USB hard drive? Maybe that reserved space is only necessary on a disk containing an OS? 0% would be 'safe', if rdiff-backup would be the only process writing to the USB drive. Reserved space is primarily meant for OS disks such that root still has the ability to login and move stuff around when non-root users/processes made a mess and filled the entire disk. However, it is still good to reserve some 2 or 3 % of your 1TB drive. Or even go with the default which is usually 5%. If you are running out of space and need to regress a failed backup due to no disk space, you can use tune2fs or other filesystem's relatives to create some more room to do a proper cleanup. (Reserved space is live-tunable on most file systems. If it is not, you could set it to 0% and simply create a large placeholder file, and deleting the placeholder file in case you need more space to regress.) Would you use rsync or would you have the remote system described above act as a second rdiff-backup server and run the entire backup process a second time? Using rdiff-backup to copy an rdiff-backup repository wouldn't be a good idea. Using rdiff-backup against the original system (your laptop, etc) might also not be what you want. So, I think using rsync to keep a copy of the rdiff-backup tree would be the best way to go. As for you other email: You're saying openvpn with UDP would be best, then SSH -R, then openvpn with TCP? Yes. With openvpn/udp I usually get the most reliable and fast results. Using ssh with a -R tunnel or using openvpn/tcp shouldn't be much of a difference wrt performance, but ssh is usually considered to be easier to setup. Especially because you only need 1 connection to be tunneled, and you don't need the advanced networking and routing stuff. But, in the end, it's your call... it's all free software ;-) -- Maarten ___ 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
Re: [rdiff-backup-users] Post-setup questions
That sounds like a great idea. I'll set up openvpn and switch from pushing to pulling. BTW, is the read-only restriction on the public SSH keys the only advantage of pulling vs. pushing? Are there any drawbacks? In a pull arrangement, if the private keys on the backup server are stolen, the thief would have root read-access on each system? 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? 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? Would it be safe to reserve zero space for root on the USB hard drive? Maybe that reserved space is only necessary on a disk containing an OS? 0% would be 'safe', if rdiff-backup would be the only process writing to the USB drive. Reserved space is primarily meant for OS disks such that root still has the ability to login and move stuff around when non-root users/processes made a mess and filled the entire disk. However, it is still good to reserve some 2 or 3 % of your 1TB drive. Or even go with the default which is usually 5%. If you are running out of space and need to regress a failed backup due to no disk space, you can use tune2fs or other filesystem's relatives to create some more room to do a proper cleanup. 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. Would you use rsync or would you have the remote system described above act as a second rdiff-backup server and run the entire backup process a second time? Using rdiff-backup to copy an rdiff-backup repository wouldn't be a good idea. Using rdiff-backup against the original system (your laptop, etc) might also not be what you want. So, I think using rsync to keep a copy of the rdiff-backup tree would be the best way to go. 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. 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? - 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
Re: [rdiff-backup-users] Post-setup questions
On Sun, 14 Aug 2011, Grant wrote: My laptop is one of the systems I want to back up and when I travel it ends up behind a router I have no control over. Because of this, my systems push to the backup server instead of the backup server pulling from them. Based on the 'security' classification you gave to this question, I assume you're not entirely happy with the laptop pushing. I wouldn't be happy with that either ;-) Since you can't do much anything about those third party routers, I'd say you should look for other ways do get it working in a way that does make you happy. So, try to find some more info about openvpn. If the routers allow ssh connections to your backup server, they will most likely also allow an openvpn tunnel. Using that tunnel, you can instruct the backup server to run rdiff-backup against your laptop. That way, your backup server will be pulling data and your laptop only needs to contain the openvpn key. I guess you could also configure openvpn in such a way that it would require user input to start the connection. I'm using openvpn myself for similar tasks, and once setup properly, it makes life so much easier ;-) (interconnecting distant private networks, where each location is connected using isp-provided NAT-ing ADSL modems that don't allow the users to change most of the settings) Non-Security: If I deleted a file from one of my systems 61 days ago and today I run --remove-older-than 60D, will the original file be deleted from the backup or only the increments? If you remove all historic data from 60 days back and before, any trace of the file deleted 61 days ago will be gone. Since you deleted the file 61 days ago, the file was already deleted from the backup and is only kept as a (snapshot) increment. (That is: inside the rdiff-backup-data directory, which is usually considered to not be part of the backup.) I'm backing up to a 1TB USB hard drive dedicated to backups. How low should I set the super-user space reservation on that drive? Any percentage you like.. If you run your backups under a normal user account on the backup server (strongly suggested to do that!) the operating system will honour the space reservation percentage. Otherwise, it will not. Side note: file permissions and ownership is preserved in the metadata files inside the rdiff-backup-data directory at the backup server. No need to have them synchronized by using the root account on the backup server to preserve this info. In fact, if your backup server has other username-uid mapping than the machines you are backing up, things would get unexpectedly different anyway. Restoring a backup (using the root account at the device that is being restored to!) will automagically restore permissions and ownership. I'd like to store an additional copy of the backups on a remote system. Would it be best to rsync between the USB hard drive and the remote system? What happens if a file changes while rdiff-backup is reading it? You could indeed rsync from USB hard drive containing rdiff-backup backup tree to the remote system. Just make sure you either run rdiff-backup or rsync at the same time. Running rsync from USB drive to the extra remote system will not interfere with a running rdiff-backup session, but the copy on the extra remote system will be uselessly out of sync and not usable to restore using rdiff-backup. If a file changes while rdiff-backup is reading it (on the server/laptop being backed up, naturally), it will detect this when doing the final checksum, emit a warning, and skip that file. Effectively it will be treated as unchanged. This is somethat different from rsync, which will try to recover and retry to sync the file, but will eventually fail to sync the file if it keeps changing. Both approaches make sense, it's just a matter of taste ;-) -- Maarten ___ 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
Re: [rdiff-backup-users] Post-setup questions
On Sunday, August 14, 2011, 22:54:18, Maarten Bezemer wrote: So, try to find some more info about openvpn. If the routers allow ssh connections to your backup server, they will most likely also allow an openvpn tunnel. This should work with 99.9% of routers: set up the OpenVPN server at home to listen on port 443 TCP (assuming you don't have HTTPS server running - though even that could work, OpenVPN allows you to redirect connections when running in TCP mode; it doesn't matter if the OpenVPN server is behind a NAT router - just redirect port 443 to it). The client (your laptop) would then connect to the OpenVPN server, which most routers will pass, as outbound HTTPS connections are rarely restricted. You can then have the rdiff-backup server pull from your laptop using the IP assigned by OpenVPN (which you can set to a static IP using the client-config-dir settings). -- Jernej Simončič http://eternallybored.org/ There are many inside dopes in politics and government. -- Cohen's Law of Inside Dope ___ 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
Re: [rdiff-backup-users] Post-setup questions
On Sun, 14 Aug 2011, Jernej Simoni wrote: This should work with 99.9% of routers: set up the OpenVPN server at home to listen on port 443 TCP (assuming you don't have HTTPS server running - though even that could work, OpenVPN allows you to redirect connections when running in TCP mode; it doesn't matter if the OpenVPN server is behind a NAT router - just redirect port 443 to it). The client (your laptop) would then connect to the OpenVPN server, which most routers will pass, as outbound HTTPS connections are rarely restricted. But keep in mind that tunneling TCP over TCP (when running openvpn in TCP mode) might haunt you badly due to tcp timeout/retransmit settings. I always recommend running openvpn in UDP mode, and let the tunneled TCP connection do its own timeout/retransmit magic. By default, any tunneled data is just encapsulated into a UDP packet, and QoS bits should get copied. Much cleaner than openvpn with TCP, which has to encapsulate the data in a stream, and will potentially lose the ability to set QoS bits when data is buffered and resent from a tcp tx queue that keeps growing and growing due to more data arriving over the tunnel and tunneled connections reaching tcp retransmit timeouts as well. In short: try openvpn with udp first, and only go to tcp when all else fails. In that case, however, using a simple SSH tunnel with -R argument would be easier. (laptop sshs into backup server using password or password-protected key; rdiff-backup starts at backup-server connecting to localhost:tunneledport) -- Maarten ___ 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
Re: [rdiff-backup-users] Post-setup questions
On Monday, August 15, 2011, 0:19:05, Maarten Bezemer wrote: But keep in mind that tunneling TCP over TCP (when running openvpn in TCP mode) might haunt you badly due to tcp timeout/retransmit settings. I've set up OpenVPN in TCP mode several times for locations that blocked UDP, and so far never had any problems (including the run on port 443 trick). -- Jernej Simončič http://eternallybored.org/ If all you have is a hammer, every problem looks like a nail. -- Baruch's Observation ___ 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
Re: [rdiff-backup-users] Post-setup questions
My laptop is one of the systems I want to back up and when I travel it ends up behind a router I have no control over. Because of this, my systems push to the backup server instead of the backup server pulling from them. I'm using openvpn myself for similar tasks, and once setup properly, it makes life so much easier ;-) (interconnecting distant private networks, where each location is connected using isp-provided NAT-ing ADSL modems that don't allow the users to change most of the settings) That sounds like a great idea. I'll set up openvpn and switch from pushing to pulling. BTW, is the read-only restriction on the public SSH keys the only advantage of pulling vs. pushing? Are there any drawbacks? In a pull arrangement, if the private keys on the backup server are stolen, the thief would have root read-access on each system? I'm backing up to a 1TB USB hard drive dedicated to backups. How low should I set the super-user space reservation on that drive? Any percentage you like.. If you run your backups under a normal user account on the backup server (strongly suggested to do that!) the operating system will honour the space reservation percentage. Otherwise, it will not. Would it be safe to reserve zero space for root on the USB hard drive? Maybe that reserved space is only necessary on a disk containing an OS? I'd like to store an additional copy of the backups on a remote system. Would it be best to rsync between the USB hard drive and the remote system? You could indeed rsync from USB hard drive containing rdiff-backup backup tree to the remote system. Just make sure you either run rdiff-backup or rsync at the same time. Running rsync from USB drive to the extra remote system will not interfere with a running rdiff-backup session, but the copy on the extra remote system will be uselessly out of sync and not usable to restore using rdiff-backup. Would you use rsync or would you have the remote system described above act as a second rdiff-backup server and run the entire backup process a second time? - 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
Re: [rdiff-backup-users] Post-setup questions
In short: try openvpn with udp first, and only go to tcp when all else fails. In that case, however, using a simple SSH tunnel with -R argument would be easier. (laptop sshs into backup server using password or password-protected key; rdiff-backup starts at backup-server connecting to localhost:tunneledport) You're saying openvpn with UDP would be best, then SSH -R, then openvpn with TCP? - 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
