Greetings all. Due to security concerns we are switching our backup processes from "SSH tunnel to rsync daemon" to "Running rsync over ssh in --server mode". In daemon mode we had a nice conglomerate log file of all of the backups that ran. Now that I am tweaking the scripts to run over --server mode I see that by default there is no remote logging. From what I have read on the man page you turn on remote logging like this: (cut-n-paste) from man page. rsync -av --rsync-path="rsync --log-file=/tmp/rlog" src/ dest/ Up until I added this part I had the rsync scripts working fine. Once I added this part --rsync-path="rsync --log-file=/tmp/rlog" I would get this error: protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) rsync error: protocol incompatibility (code 2) at compat.c(61) [sender=2.6.9] I turned on heavy debug to see the protocol version info to see what was happening and I saw this: (Client) Protocol versions: remote=1701471570, negotiated=29 When I only add this --rsync-path="rsync" it works ok and the versions are the same. First Question: Is this a bug or am I doing something wrong? I assume I am misunderstanding something however I am taking the rsync manpage literally here. And yes I have INSURED several times I have the same version of rsync in both places (trust me on this one) Even if I am able to get this to work it still may not be what we want. Will the log file be overwritten on each successive call? I assume if multiple actions kick off at the same time and I will need to use seperate log files so that they do not trump each other. Second Question: So now after talking it out is there a way to get a unified server side log for all rsync commands executed without having a daemon running? thanks Doug -- What profits a man if he gains the whole world yet loses his soul?
On Tue, 2007-12-04 at 15:59 -0500, Doug Lochart wrote:> Greetings all. Due to security concerns we are switching our backup > processes from "SSH tunnel to rsync daemon" to "Running rsync over ssh > in --server mode". In daemon mode we had a nice conglomerate log file > of all of the backups that ran.> Second Question: So now after talking it out is there a way to get a > unified server side log for all rsync commands executed without having > a daemon running?What exactly were the security concerns? You might be better served by running a daemon configured in a way that meets your security needs. Matt
On Dec 5, 2007 9:59 PM, Matt McCutchen <matt@mattmccutchen.net> wrote:> On Tue, 2007-12-04 at 15:59 -0500, Doug Lochart wrote: > > Greetings all. Due to security concerns we are switching our backup > > processes from "SSH tunnel to rsync daemon" to "Running rsync over ssh > > in --server mode". In daemon mode we had a nice conglomerate log file > > of all of the backups that ran. > > > Second Question: So now after talking it out is there a way to get a > > unified server side log for all rsync commands executed without having > > a daemon running? > > What exactly were the security concerns? You might be better served by > running a daemon configured in a way that meets your security needs. > > Matt > >This is something we discovered by accident. We used ssh to create a tunnel using a users ssh key. With this tunnel we were able to access any module defined in the system. Each module needs to be protected from the others so if a user logs in with their credentials they should not have access to any other module. It would take a user knowing the name of another client to affect the security breach. I admit I am no whiz at securing the rsync server. Once we had it setup to run in daemon mode we assumed the ssh tunnels would provide all that we need. We over looked this one issue however. On the protocol version error I have discovered the problem I am using a validation script as part of rthe ssh key to make sure that only rsync is executed within that shell. The string I was initially testing for was "rsync --server" and when I added the --log-file to my rsyncpath it changed the remote command so that it no longer validated. Evidently it took my response of "Rejected" and tried to convert that to an int for the protocol version. Now I am having another issue and that is passing a log format in the rsync-path. I can see it is coming over but for some reason a defauly --log-format=%o is appended after --server is added by rsync. This effectively overrides the log-format I supplied. How do I stop this default log-format from being appended after --server? Thanks Doug -- What profits a man if he gains the whole world yet loses his soul? -------------- next part -------------- HTML attachment scrubbed and removed
On Dec 6, 2007 12:52 AM, Matt McCutchen <matt@mattmccutchen.net> wrote:> On Wed, 2007-12-05 at 23:21 -0500, Doug Lochart wrote: > > Now I am having another issue and that is passing a log format in the > > rsync-path. I can see it is coming over but for some reason a defauly > > --log-format=%o is appended after --server is added by rsync. This > > effectively overrides the log-format I supplied. How do I stop this > > default log-format from being appended after --server? > > You want to use --log-file-format to control the server's log file. A > --log-format option passed to a server is a hint that helps the client > perform its own logging properly. >thanks> > But seriously, you should use a properly configured rsync daemon. > Making the client pass the log format in the --rsync-path and making the > validation script check it is a hack to achieve centralized control of > logging in a plain-server setup, while an rsync daemon is *designed* to > give you this control;I would love nothing more than to use the daemon approach. It seemed like the right thing to do in the first place especially after the investigation (reading) I did this is why we went that approach to begin with.> > On the protocol version error I have discovered the problem I am > > using a validation script as part of rthe ssh key to make sure that > > only rsync is executed within that shell. > > if you stick with the plain server, you can expect more headaches like > this one. >I can see how it could be problematic.> > > We used ssh to create a tunnel using a users ssh key. With this > > tunnel we were able to access any module defined in the system. > > > Each module needs to be protected from the others so if a user logs in > > with their credentials they should not have access to any other > > module. > > Of course. I'm trying to understand your initial setup and how users > could access each other's modules. By a "tunnel", do you mean that you > forwarded a background-listening daemon's port or that you invoked a > single-use daemon over ssh? I assume each user has his/her own ssh key? > Are you using the rsync daemon's own authentication protocol ("auth > users")? >The former. Each client creates its own SSH tunnel via port forwarding. The rsync client then sets the target to localhost and the local port of the tunnel. The remote end is port 873 of the rsync server machine with a daemon running. Each user has there own module. I can post the rsyncd.confif that would help. One of our requirements is that the backup process has to be hands off (no user interaction whatsoever).> > Anyway, it's easy do a secure rsync daemon setup with ssh connections > and authentication. Make a separate daemon configuration file for each > user listing only the modules he/she is allowed to access. Then set > each user's forced command to invoke a single-use daemon with the > appropriate configuration file ("rsync --daemon --server > --config=< rsyncd-user.conf> ."). The situation for multiple single-use > daemons sharing a single log file is exactly the same as for multiple > concurrent connections to a background daemon: lines of output get > intermingled, but nothing terrible happens. > > You don't have to write a separate configuration file for each user > manually. You can force a script that generates a configuration file > specific to the user from a global template and provides the file to the > daemon on one of its fds. A better alternative might be to enhance > rsync with a --client-user=USER daemon option that makes the daemon > assume the client is USER without performing its own authentication > protocol. Then all the forced commands could use a single configuration > file but pass different --client-user options. > > Matt >This sounds interesting. I guess I was too new to rsync when we started to see that this type of thing could be done. I still need to get my head all the way around it and actually play with it but I get the gist and it looks cool. A few questions on your above comments. 1) Is it ok to manually put in --server? The rsync docs explicitly say not to do it. 2) In this approach I do NOT have a daemon running on the server correct? It is just that each invocation starts an rsync server in daemon mode to handle that client correct? 3) In your above approach what would stop a clever person from hacking the client script and changing the rsyncd.conf to match another clients? The basic daemon approach runs as root and then just applies uid/gid from the module to files sent but does not run as that user. When the daemon is run by your approach is it running as the user and not root? If so then unix permissions would come into play and the security hole closed. Thanks Matt ! -- What profits a man if he gains the whole world yet loses his soul? -- What profits a man if he gains the whole world yet loses his soul? -------------- next part -------------- HTML attachment scrubbed and removed
On Thu, 2007-12-06 at 09:55 -0500, Doug Lochart wrote:> Each client creates its own SSH tunnel via port forwarding. The > rsync client then sets the target to localhost and the local port of > the tunnel. The remote end is port 873 of the rsync server machine > with a daemon running. Each user has there own module. I can post > the rsyncd.conf if that would help.I see. Posting the rsyncd.conf might be helpful in case it brings to light anything else we need to discuss.> One of our requirements is that the backup process has to be hands off > (no user interaction whatsoever).OK. The single-use daemon approach will give you this too; in fact, the client script will be the same except no port forwarding and an `-e "ssh -l <sshuser>"' option to rsync.> 1) Is it ok to manually put in --server? The rsync docs explicitly > say not to do it.Yes; this is not "normal circumstances". :)> 2) In this approach I do NOT have a daemon running on the server > correct? It is just that each invocation starts an rsync server in > daemon mode to handle that client correct?Correct.> 3) In your above approach what would stop a clever person from > hacking the client script and changing the rsyncd.conf to match > another clients?All rsyncd.conf files are on the backup machine. The forced commands ensure that the only thing a user can do with her ssh access is run an rsync daemon and access modules in accordance with the rsyncd.conf that you have set up for her. There is no way for her to modify the rsyncd.conf files or change her forced command to use a different user's rsyncd.conf file. The protections apply regardless of how she might change her client script.> The basic daemon approach runs as root and then just applies uid/gid > from the module to files sent but does not run as that user. When the > daemon is run by your approach is it running as the user and not root? > If so then unix permissions would come into play and the security hole > closed.Yes, if you have each user log into his/her own account with ssh, the daemon will run in that account. That is a second level of protection in addition to the forced command that mandates an rsyncd.conf file containing only the user's own module. But note that since you will be using a writable rsync daemon that can't chroot (because it is not running as root), you should either refuse --links or use a copy of rsync that supports symlink munging so that the following recently discovered vulnerability does not nullify the forced-command protection: http://rsync.samba.org/security.html#s3_0_0 Matt