6.1.2.13 Ensure rsyslog TLS client certificate is configured

Information

In mutual (two-way) TLS, the rsyslog forwarding client presents its own X.509 certificate and private key so the receiving log server can authenticate it, in addition to the client verifying the server against a trusted CA. The client certificate and key are configured with the modern advanced parameters DefaultNetstreamDriverCertFile / DefaultNetstreamDriverKeyFile (or the per-action StreamDriver.CertFile / StreamDriver.KeyFile ), or the equivalent legacy $DefaultNetstreamDriverCertFile / $DefaultNetstreamDriverKeyFile directives.

With one-way TLS the forwarding client verifies the receiver, but the receiver cannot verify the forwarder: any host that can reach the collector and present a certificate chaining to a trusted CA - or connect with an anonymous authentication mode - can establish a session and inject log records. Configuring a client certificate enables mutual authentication so the receiving log server can confirm the identity of each connecting forwarder, preventing unauthorized or spoofed hosts from injecting or poisoning the central log store.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Provision a client certificate and private key issued by a CA the receiving log server trusts, then configure rsyslog to present them.

- Add the following to a drop-in such as /etc/rsyslog.d/60-forward-tls.conf :

global(
DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/etc/pki/tls/certs/ca-bundle.crt"
DefaultNetstreamDriverCertFile="/etc/pki/tls/certs/rsyslog-client.pem"
DefaultNetstreamDriverKeyFile="/etc/pki/tls/private/rsyslog-client.key"
)

- Run the following command to restrict permissions on the private key:

# chmod 0600 /etc/pki/tls/private/rsyslog-client.key

- Run the following command to restart rsyslog :

# systemctl restart rsyslog

On the receiving log server, require and authorize client certificates (for example StreamDriverAuthMode="x509/name" with an appropriate permittedPeer list) so only authenticated forwarders may connect.

Impact:

Mutual TLS requires a client certificate and key on each forwarding host and the corresponding client identity to be authorized on the receiving log server, and those certificates must be maintained and rotated. A missing, mismatched, or expired client certificate will prevent the forwarder from connecting, interrupting log delivery until it is corrected.

See Also

https://workbench.cisecurity.org/benchmarks/27892

Item Details

Category: ACCESS CONTROL, IDENTIFICATION AND AUTHENTICATION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|AC-17(2), 800-53|IA-5, 800-53|IA-5(1), 800-53|SC-8, 800-53|SC-8(1), 800-53|SC-17, CSCv7|14.4

Plugin: Unix

Control ID: e0eb7eeab8fdbd81773448a4767de54f7e949e6e039c145bc415af497220d54c