Rsync daemon modules need authentication, path control and transport review
An rsync daemon is a file-transfer service with its own module configuration. The convenience is easy to underestimate. The current rsyncd.conf manual says all users can connect without a password by default, which is described as anonymous rsync. A module that exposes a backup or deployment directory without a deliberate access policy is therefore not a private endpoint.
Start with the module identity
Use auth users with a secrets file for modules that are not intentionally anonymous. The manual warns that the secrets file must be readable only by the daemon user, or by root when the daemon runs as root, unless strict mode checks are disabled. The file should not appear in backups, source control or a shared home directory.
Separate modules by purpose and path. A read-only release mirror, a writable deployment target and a backup repository should not share one unrestricted root. Set the module path to the narrowest useful directory, review read-only settings and avoid writable upload areas unless the workflow requires them.
Treat paths and links as policy
The manual describes chroot as a stronger boundary when the daemon can use it. Where chroot is unavailable, path resolution still matters, especially around symlinked parents and temporary files. Test the effective path with the daemon account, not an administrator account. Check that a client cannot use a crafted module path, symlink or exclude rule to reach unrelated files.
Rsync is not an encrypted transport by itself. Use SSH or another protected tunnel when data crosses an untrusted network, or confirm that the system provides an equivalent transport layer. Authentication of a module does not encrypt file contents on the wire.
Inventory and rotate
List every configured module, path, authentication mode, allowed client network, read/write state, daemon user and log destination. The client allowlist should be narrow and independently documented. An old temporary allow rule can outlive the migration that created it.
Rotate shared secrets in a controlled order that avoids losing a needed transfer window. Confirm which clients use each module, add the replacement credential, test the least-privileged operation, then remove the old secret. Keep the daemon configuration change under version control without storing the secret itself.
Monitor failed authentication, unusual module names, large transfers, writes by read-only clients and connections from outside the approved network. A successful file listing can already expose names and structure, so anonymous access needs a business reason and a review date.
The useful question is not whether rsync is running. It is which module, path and credential a remote client can reach, and whether that access is still intended.
Top comments (0)