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:
On Friday 31 August 2001 23:21, you wrote:
No problem, I'm glad that you found time for this article!
Thanx. :-)
* Maarten J H van den Berg wrote on Mon, Aug 06, 2001 at 18:29 +0200:
[..]
But back to the issue; you say rsync should filter paths and so on, I beg to differ (Caveat: If I'm not overlooking something) Look at my config. This is what the client commandline looks like:
rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/
BTW, why not "-a" == "-rlptg". Differs on links to your flags. If I understand correctly, -L "follows" the links and dumps the files. Bad on /etc/rc.d/rc2.d and friends.
Yeah... To be honest I did not go into very deep research regarding the switches anyway. The reason I substituted all those switches for "a" was to be clearer for other admins, documentation purposes thus.
And this is the server-side exerpt from authorized_keys:
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
Okay, now try to run a doctored backupcommand like:
rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/../../../
[...looks safe...]
So you see, as I wrote earlier, the SERVER IS ENFORCING the command which the client tries to run. (Again, unless I made a mistake that is.)
Well, looks nice. I don't know why, but I though to write some wrapper which allows /home/backups/whatever/*, I mean that allows "deeper" definitions - but now I think you're right and this shouldn't be neccesary.
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.
If you specify /../ at the end, SSH shouldn't even start rsync, so this should be safe. But the question is, if the rsync protocol is internally safe. scp hat such a bug, it created the file requested by the client even if outside it's destination IIRC. So it may be possible to create a modified rsync client, which delivers ordinary files plus a new /root/.ssh/authorized_keys or whatever. But I think it would take some time to analyse the rsync sources.
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. 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... But, that all falls under "security through obscurity" so its use will not stop someone really determined. But what will ? 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)
If you can show me a commandline that does indeed break out of the target dir, I'd be VERY interested to know, needless to say.
Well, I think it's required to patch the rsync client. I don't know if the server checks the path of the files, I never looked at the rsync protocol. Maybe it's possible to specify a list like
Good point. As with everything, security should indeed ALWAYS be enforced on the server-end, otherwise someone can trivially use another client and thus bypass every security-measure in place.
/etc/foobar --> /home/backups/Host-AAA/foobar /etc/foobar2 --> /home/backups/Host-AAA/foobar2 /etc/foobar3 --> /etc/foobar3 /etc/foobar4 --> /home/backups/Host-AAA/foobar4
In such a case, the server should reject foobar3 since it's outside the destination. Or imagine:
/etc/foobar2 --> /home/backups/Host-AAA/foobar2 /etc/foobar3 --> /home/backups/Host-AAA/../../../etc/foobar3
or:
/etc/foobar2 --> /home/backups/Host-AAA/foobar2 /../../../etc/foobar3 --> /home/backups/Host-AAA/../../../etc/foobar3
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... :-\
I commented on the use of tarballs above. It wasn't useable for me at the time. However, If you CAN, this is indeed a safer option.
You're right, rsync has nice advantages, it's fast and a restore of a single file (i.e. deleted by accident) is much more easy.
A second point: you decided that the clients "pushes" it's files to the backupserver. I decided that the backupserver "polls" the files from the client. I though, since it better since:
- the load of the backupserver is constant on backups, since all clients can be polled after the other (no "concurrent" backups)
Yeah. I just 'tweaked' the crontabs on the clients to ensure that, but then again, I only have a couple of clients, not hundreds.
- 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...
- root access via key needed. I deciced to put the client keys on a key disc, told ssh to use a key which is a symlink to automounted /misc/floppy. Once a week, i.e. saturday night, an operator inserts the disk with the keys into the backup server, and not a key with a single key to each backupclient
These servers are colocated, not easily accessed. For us, any user-intervention was unacceptable.
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). Another point is that we need to backup files from many different filesystems, like /var, /usr, /home, /etc. That is difficult to control. With server-push, you have only one single dir where access is needed. Easier to manage I guess. YMMV. Maybe I forgot other reasons. Greetings, Maarten -- Maarten J. H. van den Berg ~~//~~ network administrator van Boetzelaer van Bemmel - Amsterdam - The Netherlands http://vbvb.nl T+31204233288 F+31204233286 G+31651994273