← All rules
SOCLE-RUN-SVC-024// systemd servicesmediumeffective runtime

Ensure rsyncd service is disabled

Ensures the rsyncd.service (standalone rsync daemon) is neither enabled at boot nor running, unless an rsync share is genuinely required.

Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 2 standards

Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.

A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.

Why this rule matters

The rsync daemon (rsyncd, listening on TCP 873) serves files over a protocol that is unencrypted and, by default, unauthenticated, credentials and data travel in clear text and modules can be world-readable unless explicitly locked down. An exposed rsyncd has repeatedly led to data exfiltration and unauthorized writes, and it broadens the network attack surface. Note this is distinct from rsync over SSH, which is encrypted and unaffected. If no daemon-mode rsync share is needed, the service should be stopped and disabled; secure transfers should go through SSH instead.

What Pavois checks

Pavois reads the effective state of rsyncd.service from systemd, asserting it is neither enabled nor running. As with rpcbind, rsync can be socket-activated via rsync.socket/rsyncd.socket, so a service unit that looks idle may still bring up the daemon on a connection to port 873. Auditing the live systemd state reflects reality better than checking /etc/rsyncd.conf (which can exist while the daemon is off, or be absent while a drop-in starts it).

describe service('rsync.service') do
  it { should_not be_enabled }
  it { should_not be_running }
end

How to verify it is applied

Run systemctl is-enabled rsyncd.service and systemctl is-active rsyncd.service; expect disabled/masked and inactive. Also check systemctl is-active rsync.socket and confirm nothing listens with ss -tlnp | grep :873.

Inspect & investigate

Inspect journalctl -u rsyncd.service -u rsync.socket for activation and transfer-related events. systemctl show rsyncd.service -p ActiveState -p UnitFileState gives the machine-readable state. Confirm port 873 is closed with ss -tlnp | grep :873.

Remediation

Pavois's harden plan acts on the service resource named rsyncd with actions disable then stop: it removes boot enablement and stops the daemon. Applied with pavois harden apply. If rsync.socket is active, mask it too to fully close port 873.

Pavois applies this with its own harden engine, the plan below, not a shell script:

actiondisable, stop
namersync.service
resourceservice
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Disabling rsyncd breaks any pull/push that targets rsync://host/module or host::module, mirrors, backup jobs, and package/repo sync that rely on the rsync daemon protocol. rsync over SSH (rsync -e ssh ...) is NOT affected. Before applying: grep crontabs, backup tooling and CI for rsync:// or :: targets, and check /etc/rsyncd.conf for served modules. If a daemon share is genuinely needed, exclude this rule or move clients to rsync over SSH.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS2.1.13, 2.2.4directper OS, see the benchmark tablehigh
PCI DSS2.2.4supporting4.0.1medium

Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.

Sources & references