Enable systemd-journal-upload Service
When a remote URL= is configured, ensures systemd-journal-upload.service is enabled and running so journal data is forwarded to a central log host.
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.
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
Centralized logging through systemd-journal-upload is essential for security monitoring, incident response, and compliance. Forwarding journal data to a remote host protects log integrity from local tampering: if an attacker gains root on the local system, they can alter or delete locally stored logs to hide their activity. Remote logging keeps the audit trail intact even when the local host is compromised, and centralizing logs across machines lets defenders correlate events to detect distributed or lateral-movement attacks.
What Pavois checks
The control is guarded by only_if on grep -qsE "^URL=" /etc/systemd/journal-upload.conf, it applies only when a remote upload target is configured, avoiding false positives on hosts that legitimately do not forward. When that holds, Pavois reads the effective unit state with service('systemd-journal-upload.service') (systemctl is-enabled / is-active), confirming forwarding is truly active rather than just configured. A config file with a URL= but a masked or crashed unit means logs are silently not leaving the host, exactly what effective-state checking catches.
only_if { command('grep -qsE "^URL=" /etc/systemd/journal-upload.conf').exit_status == 0 }
describe service('systemd-journal-upload.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Confirm a target is set with grep '^URL=' /etc/systemd/journal-upload.conf, then run systemctl is-enabled systemd-journal-upload && systemctl is-active systemd-journal-upload (expect enabled then active). journalctl -u systemd-journal-upload should show successful uploads with no repeated connection errors.
Inspect & investigate
The uploader's status and connection state are in journalctl -u systemd-journal-upload.service, look for Uploading... progress and the absence of TLS or connection-refused errors. On the central server, verify that this host's entries are arriving (e.g. in systemd-journal-remote storage under /var/log/journal/remote/).
Remediation
Pavois's harden plan acts on the service resource named systemd-journal-upload: it runs enable and start so journal forwarding persists across reboots and runs now. It is applied with pavois harden apply. A valid URL= (and matching TLS key/cert paths) must already be set in /etc/systemd/journal-upload.conf, and the remote systemd-journal-remote collector must be listening, otherwise the unit starts but fails to deliver.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Forwarding the journal needs a DESTINATION pavois cannot guess. Set it first: # /etc/systemd/journal-upload.conf -> URL=https://logs.example.org:19532 # then: systemctl enable --now systemd-journal-upload |
|---|---|
| reason | enabling the uploader without a URL leaves a permanently failing unit (the host reports `degraded`): the destination is a site decision |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration here is mostly a silent reliability problem: if the remote collector is unreachable or TLS certs are wrong, the uploader retries and buffers, potentially growing local state, while you believe logs are centralized when they are not. Precautions: provision and test the systemd-journal-remote server and TLS chain first; verify reachability and certificate validity; and monitor the uploader unit so a forwarding outage raises an alert rather than going unnoticed.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 6.1.2.1.3, 6.2.2.1.3, 6.2.1.2.3 | direct | per OS, see the benchmark table | high |
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.