rsync wrapper perlscript (was SCP-proxy / SFTP-proxy wanted)
On Mon, Jul 21, 2003 at 09:15:07AM +0200, Steffen Dettmer wrote:
You do "client push" of files for backup (instead server poll),
no, i do server poll, since my backup server accesses the clients through a masquerading router -> no way back :-) But the wrapper should also work for client push, just check the rsync commandline as described below, probably you don't need to check for "--sender", but in fact check, that it is _not_ there to prevent stealing of your data from the backup server.
yes? How do you do that? I found it is not so easy using rsync, because this likes root permissions on the backup host because maybe you want perserve UID and such. Having root-rsync access likes to limit the access to same backup-tree, at least. Does you perl-wrapper protects against this? I mean, the cilent can rsync to e.g. /.../backup/client-hostname/ as root, but not below /etc and such? In that case, would you share your script?
no, i completely mirror the whole machines, including /etc/, excluding only a few directories (/proc, postgres datadir, tomcat work-dir), but it should be easy to hack into the perlscript. The rsync_wrapper is simple: --snip--- #!/usr/bin/perl # # rsync wrapper, borrowed from # http://www.sct.gu.edu.au/~anthony/info/apps/rsync.hints # $line=$ENV{SSH_ORIGINAL_COMMAND}; if ( $line =~ m#^/usr/bin/rsync --server --sender # ) { # this regexp will need tweaking to handle unusual # (but legal) characters in paths. eg: [_\.] ($safeline=$line) =~ s|[^\w\s\d\-\/\.]||g; if ( $line ne $safeline ) { exit 1; } system("$line"); } else { exit 1; } ---snip-- i put this in /root/bin/rsync_wrapper, my authorized_keys is like this: command="bin/rsync_wrapper",no-pty,no-port-forwarding,no-agent-forwarding ssh-dss AAA... this is all on the "client machine", the one which is backed up. On the server, it is important to call rsync with the "--rsync-path="-Option, otherwise, the $SSH_ORIGINAL_COMMAND will be "rsync --server --sender..." and not "/usr/bin/rsync --server --sender..." So you have to do (on the server) "rsync --rsync-path=/usr/bin/rsync -e ssh ..." If you are really paranoid, just do something like rsync -e ssh -avP --bwlimit=1 localhost:/etc /tmp/ and in another terminal search the output of "ps auxwwf" for the exact command-line which is executed via ssh on the client, then you can put that command into authorized_keys or check especially against it in the wrapper. In my example, it was rsync --server --sender -vlogDtpr --bwlimit=1 --partial . /etc so you can check if only the paths you want to allow are at the end of the commandline. This script is not my invention, as stated in the comment. -- Stefan Seyfried Senior Consultant community4you GmbH, Chemnitz, Germany. http://www.community4you.de http://www.open-eis.com
* Stefan Seyfried wrote on Tue, Jul 22, 2003 at 13:45 +0200:
On Mon, Jul 21, 2003 at 09:15:07AM +0200, Steffen Dettmer wrote:
You do "client push" of files for backup (instead server poll),
no, i do server poll, since my backup server accesses the clients through a masquerading router -> no way back :-)
But you connect to root to make sure to read all files? Or do you connect to some unpriviledged user?
if ( $line =~ m#^/usr/bin/rsync --server --sender # ) { # this regexp will need tweaking to handle unusual # (but legal) characters in paths. eg: [_\.] ($safeline=$line) =~ s|[^\w\s\d\-\/\.]||g;
Here you just have to get the path passed by commandline, so it is not problem of course.
i put this in /root/bin/rsync_wrapper, my authorized_keys is like this:
command="bin/rsync_wrapper",no-pty,no-port-forwarding,no-agent-forwarding ssh-dss AAA...
probably with some from="" and so on, quite clear.
this is all on the "client machine", the one which is backed up. On the server, it is important to call rsync with the "--rsync-path="-Option, otherwise, the $SSH_ORIGINAL_COMMAND will be "rsync --server --sender..." and not "/usr/bin/rsync --server --sender..." So you have to do (on the server) "rsync --rsync-path=/usr/bin/rsync -e ssh ..."
If you don't trust the PATH, or in which case?
If you are really paranoid,
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. The rsync --server --sender can be used to write to the system also I guess? Or just r/o? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Wed, Jul 23, 2003 at 09:44:03AM +0200, Steffen Dettmer wrote:
But you connect to root to make sure to read all files? Or do you connect to some unpriviledged user?
no, i connect to root, with a key without passphrase, but i restrict the command to my rsync wrapper.
if ( $line =~ m#^/usr/bin/rsync --server --sender # ) { # this regexp will need tweaking to handle unusual # (but legal) characters in paths. eg: [_\.] ($safeline=$line) =~ s|[^\w\s\d\-\/\.]||g;
Here you just have to get the path passed by commandline, so it is not problem of course.
i put this in /root/bin/rsync_wrapper, my authorized_keys is like this:
command="bin/rsync_wrapper",no-pty,no-port-forwarding,no-agent-forwarding ssh-dss AAA...
probably with some from="" and so on, quite clear.
yes
this is all on the "client machine", the one which is backed up. On the server, it is important to call rsync with the "--rsync-path="-Option, otherwise, the $SSH_ORIGINAL_COMMAND will be "rsync --server --sender..." and not "/usr/bin/rsync --server --sender..." So you have to do (on the server) "rsync --rsync-path=/usr/bin/rsync -e ssh ..."
If you don't trust the PATH, or in which case?
exactly. In fact, when i took over administration of these machines, they were quite a mess, partially self-compiled, partially original SuSE/RedHat, and so i make sure, i run the rsync, that I installed. Of course they will be reinstalled ASAP ;-)
If you are really paranoid,
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. :-) 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.
The rsync --server --sender can be used to write to the system also I guess? Or just r/o?
No, AFAIK, rsync --server --sender is sent over, if you do a rsync -e ssh someotherhost:/path /localpath rsync without --sender is sent, if you do a rsync -e ssh /localpath someotherhost:/path But this are my observations only. To be honest, i have not looked into the code nor searched documentation about this. If somebody has better ideas, please speak up :-) regards, Stefan -- Stefan Seyfried Senior Consultant community4you GmbH, Chemnitz, Germany. http://www.community4you.de http://www.open-eis.com
* 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.
On Thu, Jul 24, 2003 at 12:17:45AM +0200, Steffen Dettmer wrote:
yeah, let's trust rsync a little :-) Well, my man page didn't told about --sender at all.
I think this is because it's only used internally by rsync, there is no point using it on the commandline.
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 [...] 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...
you may want to look at duplicity http://www.nongnu.org/duplicity/ -- Stefan Seyfried Senior Consultant community4you GmbH, Chemnitz, Germany. http://www.community4you.de http://www.open-eis.com
participants (2)
-
Stefan Seyfried -
Steffen Dettmer