* Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 15:44 +0200:
On Friday 07 September 2001 14:30, you wrote:
* Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 12:44 +0200:
rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/
via
command="rsync --server -vLogtprc --partial --safe-links . /home/backups/Host-AAA/",no-port-forwarding,no-X11-forwarding,no-agen t-forwarding 1024 35 123456789....................123456789 root@aaa.bbb.ccc.ddd
I'm not even sure if this safe behaviour is enforced by rsync, or by sshd. I think, by sshd. My guess is, the server 'parses' "/home/backups/../", which obviously gives "/home/", compares that to its "enforced" command inside authorized_keys, and silently disregards the requested path.
Well, actually it's like that. SSHD ignores the parameters of the client command completely and uses the parameter list from command="". sshd delivers the parameters in SSH_ORIGINAL_COMMAND (or similar), openssh seems not to have that nice feature.
But the question is, if the rsync protocol is internally safe.
Of course there could be a problem somewhere. That is why you must try to make it even more restricted, for instance by adding the source IP adress to the authorized_keys command etc.
Yep, but an attacker who steals a root key from a host can connect from that host too, so I don't see a big improvement currently.
Maybe one could (I did not try this though) also look into time-restrictions "only between 01:00 hours and 01:30 hours", and / or using ssh-agent instead of passphrase-less keys, and whatnot...
Well, if the attacker isn't silly, she connects like the cronjob. Same parameters but trojaned rsync client. She would just exchange the rsync binary, but not touch any cron jobs or whatever I guess. But in normal life I would think that this would be a theoretical attack only, since this would require some research of you setups and so on. But who knows, maybe someone is really interested in your backups :)
In any case, if a client gets compromised without me noticing it, it's only a matter of time (ttysnoop et al, you know what I mean)
Exactly, I think that is the point where the security of that particular job is sufficient. In case of compromising by a good attacker with a lot of time you're lost anyways :)
Good point. As with everything, security should indeed ALWAYS be enforced on the server-end
Yep, of course. [...]
usually rsync wouldn't generate such lists of course, but it may be possible to patch it in such a way (on client side). But it's difficult to check it in a few minutes, since the patch isn't trivial I think. Are there any experiences or audits?
Not that I did look into. Besides, I sadly lack the c / c++ skills needed for auditing it myself... :-\
Well, and I don't think customers would pay for it :) Would become an expensive backup :)
- A single point for "logging" (I see if a host was down on backup time. A host which is down won't mail - you won't see any error message).
Indeed. But mailing the timestamps of /home/backups/* gives at least an indication whether the backup still runs. Not that that is foolproof...
Ohh, really? I just look from time to time :)
These servers are colocated, not easily accessed. For us, any user-intervention was unacceptable.
Yes, the old problem. Anythink w/o user interaction can be easier compromised as when done with user interaction. After all, I don't think it makes a big difference if an attacker has to wait until the disc get's inserted. Even with some smartcards or whatever this won't help, since it's not possible to be sure that the smart card reading host is safe and not compromised. For backups like that rsync job, it would be nice to have some mode in which the permissions get saved in some ordinary file. In that case the backup job wouldn't need root permissions. But restore operations would be more complex.
What are your reasons for doing client "push"?
Ehm... Let me think back... One thing I can mention, if one of the hosts is compromised, it stays confined to that host (unless the rsync setup has securityflaws like you describe above, that is). With server-pull, IF the backupserver should get compromised, you lose everything, as that server has access to ALL those clients at some level (root or unpriv).
Yep, good point...
Another point is that we need to backup files from many different filesystems, like /var, /usr, /home, /etc. That is difficult to control.
As long as adminstrated by a single person I don't see a difference, but at least if they admin of the backup client has no shell access to the baskupserver client pull is configurable by him. So far it was very nice and productive to discuss it with you. Thank you. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.