Are there any remote backup systems that don't require ssh access? Recommendations?
I backup our important data (e.g. /home and some other bits and pieces) to a couple of remote 'servers'. At present I'm using rdiff-backup which does what I want except for one issue - it needs passwordless access to the remote system if it is to run unattended. (At least I think it does, I'm willing to listen to anything that suggests it doesn't) Having passwordless ssh access to the backup machine means that a malicious attacker who gets into the backup client machine can destroy all the backups as well as the files being backed up. While this is a fairly remote possibility (a malicious attacker getting in) I'd like to protect against it if I can. So I'm looking for a backup/mirror/remote copy facility that will allow me to 'push' files from a client machine to the backup machine without needing passwordless access. It also needs to do either timed or incremental backups in some shape or form as otherwise, of course, destroying files on the backup client would probably also destroy them on the backup. Any ideas anyone? I'm toying of playing with rsync with an rsync server on the remote backup machine though I haven't investigated this enough to see if it will work as I hope. There are a number of backup utilities that use rsync and provide timed and/or incremental backups but I'm not sure if they'll use rsync server on the remote. -- Chris Green
Hi folks, 2009/2/4 Chris G <cl@isbd.net>:
I backup our important data (e.g. /home and some other bits and pieces) to a couple of remote 'servers'.
If they provide a service, they are servers.
Having passwordless ssh access to the backup machine means that a malicious attacker who gets into the backup client machine can destroy all the backups as well as the files being backed up. While this is a fairly remote possibility (a malicious attacker getting in) I'd like to protect against it if I can.
Physical access to the machine or remote access to your machine?
So I'm looking for a backup/mirror/remote copy facility that will allow me to 'push' files from a client machine to the backup machine without needing passwordless access.
How will you authenticate? How will this system know to push/commit a new file that you tell it to, versus a bogous file *I* tell it to? Isn't this going back to some previous email we had about trust (millitary terminology and "trusted computing")? Where, if you trust some machine, it's not secure at all. "Secure / Easy to use --- pick one". Does this apply? I don't really have any solutions for you. I suspect a reasonable mix of solutions might be to make sure your OS is patched and firewalled, and that you encrypt your data as it goes to your backup server. By definition (IMHO), anything that makes your life easier is going to have worse security. Srdjan
On Wed, Feb 04, 2009 at 11:22:33AM +0000, Srdjan Todorovic wrote:
Hi folks,
2009/2/4 Chris G <cl@isbd.net>:
I backup our important data (e.g. /home and some other bits and pieces) to a couple of remote 'servers'.
If they provide a service, they are servers.
Yes, OK, they're real servers for me anyway.
Having passwordless ssh access to the backup machine means that a malicious attacker who gets into the backup client machine can destroy all the backups as well as the files being backed up. While this is a fairly remote possibility (a malicious attacker getting in) I'd like to protect against it if I can.
Physical access to the machine or remote access to your machine?
Either, but in reality the most likely case is someone guessing a not very good password and getting remote access. I'm fairly paranoid on that front too (only allowing ssh access from a couple of specific IP addresses) but you never know.
So I'm looking for a backup/mirror/remote copy facility that will allow me to 'push' files from a client machine to the backup machine without needing passwordless access.
How will you authenticate?
None, it will be a server process that will *only* provide incremental backup services so the only damage possible would be to fill up space. In reality it might be worth adding some authentication but it could only be at machine level as it needs to be non-interactive.
How will this system know to push/commit a new file that you tell it to, versus a bogous file *I* tell it to?
It won't. This is why I'm suggesting that only incremental backup is allowed, the worst you can do is fill up space on the remote.
Isn't this going back to some previous email we had about trust (millitary terminology and "trusted computing")? Where, if you trust some machine, it's not secure at all.
"Secure / Easy to use --- pick one". Does this apply?
Probably, I've been kicking this around for a while. It's closely connected with my recent question about how to check if a remote machine has died. I was thinking of doing the backups by 'pulling' from the remote but if I can 'push' from the systems requiring backup then the issue of knowing whether it worked is much easier. I'm after 'Easy to use' in the sense of being sure that the backup has succeeded with paranoia about security less important. It's no use at all being wonderfully secure if the backups you thought you were doing haven't been working for the past six months and you don't know! I know how lazy I am and unless something telling me the backup has (probably) failed hits me in the face I'll not notice. Systems that require me to 'go and look' don't work (for me anyway).
I don't really have any solutions for you. I suspect a reasonable mix of solutions might be to make sure your OS is patched and firewalled, and that you encrypt your data as it goes to your backup server.
By definition (IMHO), anything that makes your life easier is going to have worse security.
Depends on what you mean by security, there's two sides to it, security against attack and security of data so that you can restore it if attacked. Ease of use is *vital* for that second side of security or you find that backups aren't there. I've been looking into rdiff-backup options (and sshd options) and it looks as if I might be able to get what I want with rdiff-backup and a restrictive ssh setup that allows *only* rdiff-backup connections for a specific backup user. -- Chris Green
On Wed, 2009-02-04 at 10:49 +0000, Chris G wrote:
Having passwordless ssh access to the backup machine means that a malicious attacker who gets into the backup client machine can destroy all the backups as well as the files being backed up. While this is a fairly remote possibility (a malicious attacker getting in) I'd like to protect against it if I can.
Why does your backup server and the credentials it uses to log in for backup jobs even have write access to the original data in the first place ?
So I'm looking for a backup/mirror/remote copy facility that will allow me to 'push' files from a client machine to the backup machine without needing passwordless access. It also needs to do either timed or incremental backups in some shape or form as otherwise, of course, destroying files on the backup client would probably also destroy them on the backup.
Hmm surely if the backups are going to be automated then either the backup system is going to have to store credentials for the local system or the other way round..the best you can do as far as I can see is restrict the rights those credentials give to the task in hand.
Any ideas anyone? I'm toying of playing with rsync with an rsync server on the remote backup machine though I haven't investigated this enough to see if it will work as I hope. There are a number of backup utilities that use rsync and provide timed and/or incremental backups but I'm not sure if they'll use rsync server on the remote.
Well rsync would work without having to store passwords only because on it's own (i.e. not via an ssh tunnel) it pretty much has no security beyond "host a can see folder x for r-w" So get on the lan and pretend to be "host a" and you have the same access. Also the data-stream is not encrypted so any files transfered could be intercepted from the wire. That said..if your backup server attaches to your local machine via rsync set up for read only access then at least an attacker on the backup machine can't delete files on the local one. But this is only practical/safe if the connection between the two is a trusted network.
On Wed, Feb 04, 2009 at 11:31:13AM +0000, Wayne Stallwood wrote:
On Wed, 2009-02-04 at 10:49 +0000, Chris G wrote:
Having passwordless ssh access to the backup machine means that a malicious attacker who gets into the backup client machine can destroy all the backups as well as the files being backed up. While this is a fairly remote possibility (a malicious attacker getting in) I'd like to protect against it if I can.
Why does your backup server and the credentials it uses to log in for backup jobs even have write access to the original data in the first place ?
Maybe I haven't described exactly what I meant. 'My' machine is called 'chris' and it has data that needs backing up, I back it up to a machine called 'backup'. Say an intruder gets access to 'chris' (it's about the only machine on the LAN where a break in is directly possible), they can directly delete my data but I'm trying to make it so they *can't* get easy access to 'backup' and delete data there. Using rdiff-backup (for example) to backup means that there is passwordless ssh access to 'backup' and so the intruder can simply go and delete files on 'backup' as well.
So I'm looking for a backup/mirror/remote copy facility that will allow me to 'push' files from a client machine to the backup machine without needing passwordless access. It also needs to do either timed or incremental backups in some shape or form as otherwise, of course, destroying files on the backup client would probably also destroy them on the backup.
Hmm surely if the backups are going to be automated then either the backup system is going to have to store credentials for the local system or the other way round..the best you can do as far as I can see is restrict the rights those credentials give to the task in hand.
Yes, I think that's maybe the right approach, only allow passwordless backup and no other tasks.
Any ideas anyone? I'm toying of playing with rsync with an rsync server on the remote backup machine though I haven't investigated this enough to see if it will work as I hope. There are a number of backup utilities that use rsync and provide timed and/or incremental backups but I'm not sure if they'll use rsync server on the remote.
Well rsync would work without having to store passwords only because on it's own (i.e. not via an ssh tunnel) it pretty much has no security beyond "host a can see folder x for r-w" So get on the lan and pretend to be "host a" and you have the same access. Also the data-stream is not encrypted so any files transfered could be intercepted from the wire.
That said..if your backup server attaches to your local machine via rsync set up for read only access then at least an attacker on the backup machine can't delete files on the local one.
As I re-explained above it's much more likely that an intruder will break into the client, not the backup server.
But this is only practical/safe if the connection between the two is a trusted network.
It's a wired only home LAN so, yes, it's fairly trusted. -- Chris Green
On Wed, 2009-02-04 at 12:04 +0000, Chris G wrote:
Maybe I haven't described exactly what I meant. 'My' machine is called 'chris' and it has data that needs backing up, I back it up to a machine called 'backup'. Say an intruder gets access to 'chris' (it's about the only machine on the LAN where a break in is directly possible), they can directly delete my data but I'm trying to make it so they *can't* get easy access to 'backup' and delete data there.
Using rdiff-backup (for example) to backup means that there is passwordless ssh access to 'backup' and so the intruder can simply go and delete files on 'backup' as well.
Ok so what if "backup" had read only access to "Chris" and pulled the files (via rsync or whatever) and Chris had no passwordless access to backup. Then if "Chris" is compromised "Backup" would be safe*. If Backup was compromised then the files on Chris would be safe* as well. * Where "safe" is safe from deletion not interception..if you want safe from interception then you need to wrap rsync in ssh..encrypt the backup volume and the volume with your data on "chris" before you are even close.
On Wed, Feb 04, 2009 at 12:26:23PM +0000, Wayne Stallwood wrote:
On Wed, 2009-02-04 at 12:04 +0000, Chris G wrote:
Maybe I haven't described exactly what I meant. 'My' machine is called 'chris' and it has data that needs backing up, I back it up to a machine called 'backup'. Say an intruder gets access to 'chris' (it's about the only machine on the LAN where a break in is directly possible), they can directly delete my data but I'm trying to make it so they *can't* get easy access to 'backup' and delete data there.
Using rdiff-backup (for example) to backup means that there is passwordless ssh access to 'backup' and so the intruder can simply go and delete files on 'backup' as well.
Ok so what if "backup" had read only access to "Chris" and pulled the files (via rsync or whatever) and Chris had no passwordless access to backup. Then if "Chris" is compromised "Backup" would be safe*. If Backup was compromised then the files on Chris would be safe* as well.
That's how I'm doing it at the moment. :-) Yes, it does do what I want from the security point of view but it's less "user friendly" from the point of view of knowing if the backup worked. If I can get a similar level of safety of backup with a 'push' mode then it's *much* easier to get told when a backup has failed.
* Where "safe" is safe from deletion not interception..if you want safe from interception then you need to wrap rsync in ssh..encrypt the backup volume and the volume with your data on "chris" before you are even close.
The data isn't inherently valuable or even particularly confidential, it's just rather important to running our small business. If someone copied the data I think they'd find it very boring and not very useful. -- Chris Green
On Wed, 2009-02-04 at 12:38 +0000, Chris G wrote:
That's how I'm doing it at the moment. :-) Yes, it does do what I want from the security point of view but it's less "user friendly" from the point of view of knowing if the backup worked.
If I can get a similar level of safety of backup with a 'push' mode then it's *much* easier to get told when a backup has failed.
Why not add to the script so that success/errors get trapped and emailed to you ?
On Wed, Feb 04, 2009 at 01:01:28PM +0000, Wayne Stallwood wrote:
On Wed, 2009-02-04 at 12:38 +0000, Chris G wrote:
That's how I'm doing it at the moment. :-) Yes, it does do what I want from the security point of view but it's less "user friendly" from the point of view of knowing if the backup worked.
If I can get a similar level of safety of backup with a 'push' mode then it's *much* easier to get told when a backup has failed.
Why not add to the script so that success/errors get trapped and emailed to you ?
That's OK as long as the backup system hasn't fallen over and the connection to it is still working. However the most likely failure is that the cable has been broken or disconnected. I did actually ask this question a while ago and there *are* solutions but they're not as easy as provided by a local cron 'pushing' the data. -- Chris Green
On Wed, Feb 04, 2009 at 01:43:27PM +0000, Chris G wrote:
That's OK as long as the backup system hasn't fallen over and the connection to it is still working. However the most likely failure is that the cable has been broken or disconnected.
But you'd have known about that problem and fixed it as your network monitoring system would have told you. Adam -- jabberid = quinophex@jabber.earth.li
On Wed, Feb 04, 2009 at 01:52:14PM +0000, Adam Bower wrote:
On Wed, Feb 04, 2009 at 01:43:27PM +0000, Chris G wrote:
That's OK as long as the backup system hasn't fallen over and the connection to it is still working. However the most likely failure is that the cable has been broken or disconnected.
But you'd have known about that problem and fixed it as your network monitoring system would have told you.
Possibly! :-) It's certainly one approach, the one I'm using at the moment. However if I can get 'push' backup to replace 'pull' backup + network monitoring but still not allowing passwordless access to the backup machine then that's the way I'd prefer. I prefer the simpler solution if at all possible, especially for fundamental safety/security things like this. -- Chris Green
If you have shell access on your remote system, you could create a DSA or RSA key pair. Set the ssh config to access key based authentication, then you don't need to enter a password. Just keep your private key safe. Otherwise, there are some commercial offerings: KeVault by KeConnect. This uses a Java app to backup your data (encrypted) onto their servers, which are diversely located. It runs automatically using their provided scheduler. www.keconnect.co.uk/kevault Stuart On Wednesday 04 February 2009 10:49:54 Chris G wrote:
I backup our important data (e.g. /home and some other bits and pieces) to a couple of remote 'servers'.
At present I'm using rdiff-backup which does what I want except for one issue - it needs passwordless access to the remote system if it is to run unattended. (At least I think it does, I'm willing to listen to anything that suggests it doesn't)
Having passwordless ssh access to the backup machine means that a malicious attacker who gets into the backup client machine can destroy all the backups as well as the files being backed up. While this is a fairly remote possibility (a malicious attacker getting in) I'd like to protect against it if I can.
So I'm looking for a backup/mirror/remote copy facility that will allow me to 'push' files from a client machine to the backup machine without needing passwordless access. It also needs to do either timed or incremental backups in some shape or form as otherwise, of course, destroying files on the backup client would probably also destroy them on the backup.
Any ideas anyone? I'm toying of playing with rsync with an rsync server on the remote backup machine though I haven't investigated this enough to see if it will work as I hope. There are a number of backup utilities that use rsync and provide timed and/or incremental backups but I'm not sure if they'll use rsync server on the remote.
-- Chris Green
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
-- --------------------------------------- Stuart Bailey BSc (hons) CEng CITP MBCS LinuSoft (Owner) Linux Specialist (0845) 6583563 http://www.linusoft.co.uk http://www.bluetoothadvertising.org.uk ---------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Wed, Feb 04, 2009 at 11:38:40AM +0000, Stuart Bailey wrote:
If you have shell access on your remote system, you could create a DSA or RSA key pair. Set the ssh config to access key based authentication, then you don't need to enter a password. Just keep your private key safe.
That doesn't help. To allow unattended backup to work the ssh keys have to have no key so an intruder on the client machine will have passwordless access to the remote machine.
Otherwise, there are some commercial offerings:
KeVault by KeConnect. This uses a Java app to backup your data (encrypted) onto their servers, which are diversely located. It runs automatically using their provided scheduler.
www.keconnect.co.uk/kevault
I still don't think it addresses the problem, unless it's an incremental backup. If someone breaks into 'my' machine (the machine being backed up) then they can send rubbish data to overwrite the good backups can't they? This is the specific possibility I'm trying to protect myself against a bit. -- Chris Green
Hi 2009/2/4 Chris G <cl@isbd.net>:
I still don't think it addresses the problem, unless it's an incremental backup. If someone breaks into 'my' machine (the machine being backed up) then they can send rubbish data to overwrite the good backups can't they? This is the specific possibility I'm trying to protect myself against a bit.
Now that I remember, there was an article in one of the Linux Format issues where you could use Subversion to hold incremental, versioned, logged home directories. Anyone tried it in general? Anyone tried it specifically for this kind of backup setup? (or anyone tried other version control software (git?) for this?) Interesting thought. One problem would be that it's not automated (you would have to write a log)... You can do ssh+svn:// so there might be a possibility of using ssh keys if you really wanted. Srdjan
On 04 Feb 12:33, Chris G wrote:
On Wed, Feb 04, 2009 at 11:38:40AM +0000, Stuart Bailey wrote:
If you have shell access on your remote system, you could create a DSA or RSA key pair. Set the ssh config to access key based authentication, then you don't need to enter a password. Just keep your private key safe.
That doesn't help. To allow unattended backup to work the ssh keys have to have no key so an intruder on the client machine will have passwordless access to the remote machine.
Otherwise, there are some commercial offerings:
KeVault by KeConnect. This uses a Java app to backup your data (encrypted) onto their servers, which are diversely located. It runs automatically using their provided scheduler.
www.keconnect.co.uk/kevault
I still don't think it addresses the problem, unless it's an incremental backup. If someone breaks into 'my' machine (the machine being backed up) then they can send rubbish data to overwrite the good backups can't they? This is the specific possibility I'm trying to protect myself against a bit.
I'm *sure* that we went through this several months ago... care to go back through the archive and find the bit that says... "Use a passphrase less key, and only grant it permissions to run the backups" It's not bloody rocket science. -- Brett Parker
On Thu, Feb 05, 2009 at 10:36:11AM +0000, Brett Parker wrote:
On 04 Feb 12:33, Chris G wrote:
On Wed, Feb 04, 2009 at 11:38:40AM +0000, Stuart Bailey wrote:
If you have shell access on your remote system, you could create a DSA or RSA key pair. Set the ssh config to access key based authentication, then you don't need to enter a password. Just keep your private key safe.
That doesn't help. To allow unattended backup to work the ssh keys have to have no key so an intruder on the client machine will have passwordless access to the remote machine.
Otherwise, there are some commercial offerings:
KeVault by KeConnect. This uses a Java app to backup your data (encrypted) onto their servers, which are diversely located. It runs automatically using their provided scheduler.
www.keconnect.co.uk/kevault
I still don't think it addresses the problem, unless it's an incremental backup. If someone breaks into 'my' machine (the machine being backed up) then they can send rubbish data to overwrite the good backups can't they? This is the specific possibility I'm trying to protect myself against a bit.
I'm *sure* that we went through this several months ago... care to go back through the archive and find the bit that says...
"Use a passphrase less key, and only grant it permissions to run the backups"
I'm slowly getting to where I want and these discussions *do* help me. OK, to some extent it's me "thinking aloud" but surely that's partly what this mailing list is for. The system I have now is as follows:- The garage (i.e. off-site) backup server has a dedicated account called 'bak' which I have set up to allow passwordless ssh login from the backup clients on the LAN. All other ways to access the garage machine need a password (or ssh key). I have added the following to the bottom of my sshd config file on the garage backup server:- Match User=bak ForceCommand rdiff-backup --server This means that only the program rdiff-backup can be run via the passwordless ssh login. It's not quite as good as a 'pull' backup as an intruder *could* do devious things with the rdiff-backup client and delete or overwrite the backups, but it's fairly unlikely. To make things even better I'm going to add a --restrict-update-only parameter to the ForceCommand, I haven't done it yet because I'm not absolutely sure how it works. I'm having a discussion about it on the rdiff-backup mailing list at this very moment. -- Chris Green
participants (6)
-
Adam Bower -
Brett Parker -
Chris G -
Srdjan Todorovic -
Stuart Bailey -
Wayne Stallwood