Enable syslog-ng Service
Ensures the syslog-ng logging daemon (syslog-ng.service) is enabled and running so system and security events are reliably recorded.
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
The syslog-ng service must be running to provide system logging, which is essential to system administration, security monitoring, and incident response. Without an active logging daemon, security-relevant events (authentication, privilege escalation, service failures) are never recorded, leaving no audit trail to detect or investigate compromise. Reliable local and forwarded logs are a baseline control for accountability.
What Pavois checks
Pavois checks the effective unit state via service('syslog-ng.service'), i.e. systemctl is-enabled syslog-ng and systemctl is-active syslog-ng. This reflects whether the daemon will truly start at boot and is running now, including masking and drop-in overrides under /etc/systemd/system/syslog-ng.service.d/. Merely checking that /etc/syslog-ng/syslog-ng.conf exists would miss a masked, crashed, or never-started unit.
only_if { package('syslog-ng').installed? }
describe service('syslog-ng.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Run systemctl is-enabled syslog-ng && systemctl is-active syslog-ng; expected output is enabled then active. Confirm it is actually receiving messages with logger 'Pavois test' && journalctl -u syslog-ng or by checking the destination files defined in syslog-ng.conf.
Inspect & investigate
Use journalctl -u syslog-ng.service for the daemon's own status. The logs it produces land in the destinations declared in /etc/syslog-ng/syslog-ng.conf (commonly /var/log/syslog, /var/log/auth.log, /var/log/messages). Validate end-to-end delivery by emitting a test message with logger.
Remediation
Pavois's harden plan acts on the service resource named syslogng: it runs enable (start at every boot) and start (run now). It is applied with pavois harden apply. The syslog-ng package must be installed first; note that running syslog-ng alongside rsyslog on the same destinations can cause duplicate or conflicting logging.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | enable, start |
|---|---|
| name | syslog-ng.service |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Enabling syslog-ng has little disruptive risk on its own. The main pitfall is two logging daemons competing: if rsyslog is also active, you may get duplicated entries or one daemon failing to bind. Precautions: decide on a single primary syslog implementation, disable the other if needed, and confirm disk space and rotation (/etc/logrotate.d/) are configured so verbose logging cannot fill the partition and stall the system.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | CM-6(a), AU-4(1) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.