David Dyer-Bennet
Patron
- Joined
- Jul 13, 2013
- Messages
- 286
I've used rsync a lot over the years, but never rsyncd before. Since there's an rsyncd service, and since using rsyncd bypasses ssh and hence the performance issues of encryption, I'm thinking this may be my solution for transferring bulk data between servers. (The servers will be connected to the same unmanaged switch, so the packets aren't likely to get out of the local environment). Especially when we get up to 10G ethernet, which is in the offing for us for these bulk transfers.
It looks to me like the way rsyncd gets configured by default, and in FreeNAS, is horribly dangerous, and it's not obvious how to improve it. And it's not very clear to me how to make it safer. I think, at the very least, the documentation should say that turning on rsyncd was horribly insecure unless you did (various specific things; or at least, unless you understand how to secure it and do so) . Ideally, the instructions should be easy to understand, and the default shouldn't be insecure.
As a basic test, I set up an rsyncd module named test-backup with read-write access, and specified a user of "root" (necessary to allow it to receive all the different users and set protections and so forth) and a group of fsfs-backup. Gave it a path to an unused piece of filesystem it's safe to write test data into. No auxiliary parameters.
Then, from the server I wished to back up, I executed:
(IP addr obscured for no really important reason)
There is no such user "nonesuch" on the destination server, and there is no rsyncd secrets file or any added config beyond the default (no auxiliary parameters) establishing such a user.
And -- it's running, seems to be working, is creating directories and files and transferring data.
So -- by just giving the name of the rsyncd module, I appear to be able to access its services? Services which include writing as root into my filesystem? I'm really not very comfortable with that default, but that's an rsyncd issue, I know that's not under control of FreeNAS.
But -- how am I supposed to do better?
With auxiliary parameters I think I can specify an rsyncd "auth users" line to establish users that can use this module. But I also have to establish a "secrets file"; while I can refer to a secrets file with auxiliary parameters also, I'm not sure where I can put one that will be stable across upgrades.
There may be a better way; the rsyncd docs hint at, but never describe how to invoke, situations where an actual system user is authenticated against. Does anybody understand how that works?
What I did, which seems to be easy, the line of least resistance, what FreeNAS is encouraging me to do, is horribly insecure. One obvious improvement would be to add to the FreeNAS GUI for rsyncd modules a way to specify system users that can use the module, if that's really possible (a method better than requiring me to enter free-form text in the auxiliary parameters box). That would be a relatively small change, and it would turn a horrible security hole into something not too bad.
It looks to me like the way rsyncd gets configured by default, and in FreeNAS, is horribly dangerous, and it's not obvious how to improve it. And it's not very clear to me how to make it safer. I think, at the very least, the documentation should say that turning on rsyncd was horribly insecure unless you did (various specific things; or at least, unless you understand how to secure it and do so) . Ideally, the instructions should be easy to understand, and the default shouldn't be insecure.
As a basic test, I set up an rsyncd module named test-backup with read-write access, and specified a user of "root" (necessary to allow it to receive all the different users and set protections and so forth) and a group of fsfs-backup. Gave it a path to an unused piece of filesystem it's safe to write test data into. No auxiliary parameters.
Then, from the server I wished to back up, I executed:
rsync -a --links --partial --append -v --progress -h --exclude .zfs/ /home/shortterm rsync://nonesuch@192.168.y.z/test-backup
(IP addr obscured for no really important reason)
There is no such user "nonesuch" on the destination server, and there is no rsyncd secrets file or any added config beyond the default (no auxiliary parameters) establishing such a user.
And -- it's running, seems to be working, is creating directories and files and transferring data.
So -- by just giving the name of the rsyncd module, I appear to be able to access its services? Services which include writing as root into my filesystem? I'm really not very comfortable with that default, but that's an rsyncd issue, I know that's not under control of FreeNAS.
But -- how am I supposed to do better?
With auxiliary parameters I think I can specify an rsyncd "auth users" line to establish users that can use this module. But I also have to establish a "secrets file"; while I can refer to a secrets file with auxiliary parameters also, I'm not sure where I can put one that will be stable across upgrades.
There may be a better way; the rsyncd docs hint at, but never describe how to invoke, situations where an actual system user is authenticated against. Does anybody understand how that works?
What I did, which seems to be easy, the line of least resistance, what FreeNAS is encouraging me to do, is horribly insecure. One obvious improvement would be to add to the FreeNAS GUI for rsyncd modules a way to specify system users that can use the module, if that's really possible (a method better than requiring me to enter free-form text in the auxiliary parameters box). That would be a relatively small change, and it would turn a horrible security hole into something not too bad.