Crap, I keep forgetting to reply to list. Sorry you're getting this twice, Les.
On 11/28/05, Les Stott <[EMAIL PROTECTED]> wrote: > Why doesn't anyone like running rsyncd on a windows box standalone? I Sorry, I wasn't trying to be difficult (and I did get that part working, I'll post details for future googlers later when I've got everything working sufficiently -- I'm still in a testing/getting it working mode). It's just that a few negative personal experiences have made me quite a bit more concerned about the security facet of software. I've actually grown quite lazy about it in the past couple years, but I still try to maintain a healthy level of paranoia. =) (This is why I've been supporting OpenBSD since v2.8) > the list with troubles trying to configure rsync over ssh, tar over smb smb is horribly insecure. I don't want any windows machine I'm involved with to be on any network, trusted or not, with its entire drive available to an smb share. Rsyncd is somewhat of an improvement, but not nearly what I'd prefer. > 2. rsyncd can be set to only allow connections from a single host (i.e. > 192.168.1.1), so if your not on that network nothing can connect anyway. IP filtering has been a very poor method for security for at least a decade. It will probably prevent somebody from accidentally finding it, no more. > 3. you can secure even further using an rsyncd.secrets file. A plain text password file stored on a Windows machine. Sure, I chowned it to SYSTEM, and chmod 400'ed it. Now my user can no longer read or edit the contents of the file, but I can change the permissions and ownership right back. But let's assume the windows box is fairly secure, and the only user with administrative priveleges is allowed to see that file anyway. Now that we have it working, we run our backup and -- oops, just sent that plain text password over the network, can't forget to exclude that file! =) > 4. You can alos turn off the rsyncd "list=false" so that anyone probing > your ports cant find anything on 873. Like IP filtering, and MD4 based authentication, is only security through obscurity, which shouldn't count as security at all. > 5. if you download the rsyncd zip file from the backuppc site all you > need to do is extract to c:\, then modify c:\rsyncd\rsycnd.conf to suit, > then run c:\rsyncd\service.bat to installit as a service and start it. > How simple is that!! Much simpler than trying to sget sshd working as > welll and the extra config there... Agreed, it was much easier, even when I did it the cygwin way, like I'd already done with sshd. I won't dispute that at all. =) > 6. You can even set the rsyncd shares on the client to be read only, > thus nothing can be written to them, until you need to do a restores > change it to being writeable. A tradeoff in functionality (as far as BackupPC being able to restore from backup), but security-wise, one worth considering. Even then, though, you're still fully exposing your data. > 7. If windows firewall is blocking just add an exception for rsync > tcp/873 from the local subnet (192.168.1.1). Not even necessary, if you're already restricting the IP to your BackupPC server in the rsyncd.conf, but still not a very effective security method. > In any event going to different networks with the same subnet is usually > rare in my experience. On the contrary, they're quite common, that's why we're all talking about 192.168 subnets, almost everyone one of us has one. > If you are using ssh as a transport or simlar then you have to have the > client running an ssh daemon listening for connections before the server > can make an rsync connection over it. Thus you still have to run a > daemon of some kind, and this will still be running on the untrusted > network also. Yes, but ssh security has proven very robust. =) I know, I'm going out of my way here, doing things the difficult way. But I'm a security nut, and I believe in the importance of that. Most of the security referenced in the rsyncd approach is simply obscurity. (Again, sorry for being difficult, just thought I'd explain the angle I'm coming from.) Thanks again! Tom ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
