* Stefan Seyfried wrote on Wed, Jul 23, 2003 at 11:11 +0200:
On Wed, Jul 23, 2003 at 09:44:03AM +0200, Steffen Dettmer wrote:
I'm not only asking for paranoia but als for practical expiriences. I use a server poll approach on one system with a few hosts also, but but manual trigger only, because not-password protected SSH keys for root are not a perfect thing.
yes, but the private key is only on the backup server. If someone gets root access to the backup server, he has all the data he needs to compromise the live machine, so i don't worry too much about the ssh-key then. :-)
Yes, on the one hand this is clear. Theoretically, you could use a key disk (well, the attacker just needs more time to wait, but makes things more compliciated :-)) and store the files as a kind of tar - piped through gpg in encryption mode. And there is no need to store the secret key on the server. Well, I never used it, because it makes restore and verification so difficult :-) But maybe it is some option.
And he has to come from our internal network (yes, i know, a lot of attacks come from internal machines) and he can only rsync, which he does not need anymore, since the data is already on the backupserver.
I think, in general internal and external attacks are different: many external attacks just want resources e.g. to DOS or to share stolen software, whatever. Internal attackers are more interested in the data I think.
No, AFAIK, rsync --server --sender is sent over, if you do a rsync -e ssh someotherhost:/path /localpath
But this are my observations only. To be honest, i have not looked into the code nor searched documentation about this.
yeah, let's trust rsync a little :-) Well, my man page didn't told about --sender at all.
If somebody has better ideas, please speak up :-)
A client, that pushes an encrypted tar file would protect against this attacks I think. Hacking a host, you get the ability to store encrypted files. hum, maybe you can DoS the backup, but not more. If you compromise the backup server, you get heaps of encrypted data and nothing more. First drawback: if the client push is not working for some time (cron died or such), how to notice? I though about some time stamp checking (maybe also check if filesize > 1MB or something). Well, for me, I'm sure I would find a way to plug it into the netsaint/nagios network monitor :-) I did not implemtented such things, because it seems to me it violates KISS - and I do want a simple and stable backup scripting :-) Is there already a solution for this? The idea itself may be a nice one, maybe... What do you think? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.