rsync, Part II
Last month we covered setting up an rsync server for anonymous access. Listing 1 shows the sample rsyncd.conf file from last month, illustrating some options particularly useful for tightening security. Returning to our example, here's a word about setting up rsync modules (directories) at the filesystem level. The guidelines for doing this are the same as those for anonymous FTP chroot environments. The only exception is that no system binaries or configuration files need to be copied inside them for chroot purposes, as is the case with some FTP servers.
The rsync configuration file needs only a little customization of paths and allowed hosts to start serving files to anonymous users. But that's a pretty narrow offering. How about accepting anonymous uploads and adding a module for authenticated users? Listing 2 outlines how to do both.
First, we have a module called incoming, whose path is /home/incoming. The guidelines for publicly writable directories (see “Tips for Securing Anonymous FTP” in Building Secure Servers with Linux) apply, but with one important difference: for anonymous rsync, this directory must be world-executable as well as world-writable, that is, mode 0733. If it isn't set this way, file uploads fail without any error being returned to the client or logged on the server.
Some tips that apply for configuring FTP are to watch this directory closely for abuse and never make it or its contents world-readable. Also, move uploaded files out of it and into a nonworld-accessible part of the filesystem as soon as possible, perhaps with a cron job.
The only new option in the [incoming] block is transfer logging. This causes rsync to log more verbosely when actual file transfers are attempted. By default, this option has a value of no. In addition, the familiar option read-only has been set to no, overriding its global setting of yes. No similar option exists for telling rsync this directory is writable; this is determined by the directory's actual permissions.
The second part of the example defines a restricted-access module named Audiofreakz. There are three new options to discuss here. The first option, list, determines whether this module should be listed when remote users request a list of the server's available modules. Its default value is yes.
The other two new options, auth users and secrets file, define how prospective clients should be authenticated. rsync's authentication mechanism, available only when run in dæmon mode, is based on a reasonably strong 128-bit MD5 challenge-response scheme. This is superior to standard FTP authentication for two reasons. First, passwords are not transmitted over the network and therefore are not subject to eavesdropping attacks. Brute-force hash-generation attacks against the server are theoretically feasible, however.
Second, rsync doesn't use the system's user credentials; it has its own file of user name-password combinations. This file is used only by rsync and is not linked or related in any way to /etc/passwd or /etc/shadow. Thus, even if an rsync login session is somehow compromised, no user's system account is directly threatened or compromised unless you've made some poor choices regarding which directories to make available using rsync or when setting those directories' permissions.
Like FTP, however, data transfers themselves are unencrypted. At best, rsync authentication validates the identities of users, but it does not ensure data integrity or privacy against eavesdroppers. To achieve those goals you must run it over either SSH or Stunnel.
The secrets file option specifies the path and name of the file containing rsync user name-password combinations. By convention, /etc/rsyncd.secrets commonly is used, but the file may have practically any name or location—it needn't end, for example, with the suffix .secrets. This option also has no default value; if you wish to use auth users, you also must define secrets file. This example shows the contents of a sample secrets file:
The auth users option in Listing 2 defines which users, among those listed in the secrets file, may have access to the module. All clients who attempt to connect to this module, assuming they pass any applicable hosts allow and hosts deny ACLs, are prompted for a user name and password. Remember to set the permissions of the applicable files and directories carefully, because these ultimately determine what authorized users may do once they've connected. If auth users is not set, users are not required to authenticate, and the module is available over anonymous rsync. This is rsync's default behavior in dæmon mode.
And that is most of what you need to know to set up both anonymous and authenticated rsync services. See the rsync(8) and rsyncd.conf(5) man pages for full lists of command-line and configuration-file options, including a couple I haven't covered here that can be used to customize log messages.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)