search

ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.23k stars 698 forks source link

[BUG] RHEL-related automation should not inject log-collector hostname into /etc/rsyslog.conf #11812

Open ferricoxide opened 7 months ago

ferricoxide commented 7 months ago

Share the context

We use this project's content across several customers' projects. Initially discovered the problem last year, but reporting the issue "fell off the stack". Recently, began receiving complaints from another customer that they were seeing "host not found" entries in their system logs for the logcollector host specified in the post-hardening /etc/rsyslog.conf configuration.

Description of problem:

Looks like this project's remediation-automation is injecting @@logcollector into the hardened-systems' /etc/rsyslog.confconfiguration. At bare minimum, this results in nuisance "host not found" error-types. Also poses a potential security-risk: if someone injectslogcollectorinto the DNS domain the hardened system is configured into, log-offload attempts could be made to a bogus/unsanctioned rsyslog. Security-concern aside, if someone injectslogcollector` into the DNS domain the hardened system is configured into, but doesn't stand up a collector, the "host not found" errors will be replaced with "cannot connect" error-types

Proposed change:

Centralize log-collection is inherently site-specific. In many cases, other services (e.g., Splunk, CloudWatch Agent, etc.) are used for offload rather than syslog. As such, the automation should include no remediative-actions that include injecting a logging-destination into the hardened-hosts' /etc/rsyslog.conf configurations.

CC: @lorengordon and @eemperor

marcusburghardt commented 7 months ago

It is likely related to the rule rsyslog_remote_loghost.

ferricoxide commented 7 months ago

@marcusburghardt sed:

It is likely related to the rule rsyslog_remote_loghost.

Yeah, when I'd generated the BASH fix-script from the remediation-content, I believe that was the title of the block in the generated-script. We don't generally use tayloring-files to prevent scans/remediations from running.

That usage-method aside, I still feel that, given the inherently-local nature of remote log-offload, having the default content inject a (generally spurious) remote-logging entry into hardened-hosts' rsyslog.conf files doesn't make a ton of sense.

marcusburghardt commented 7 months ago

This issue is likely related: https://github.com/ComplianceAsCode/content/issues/8018 @ferricoxide , would you like to propose a PR improving this rule?

ferricoxide commented 6 months ago

@marcusburghardt I've mostly used this project's content in a fairly static way: is there a way to add usage of externalities to guide the setup that the … --remediate … automation does? Otherwise, the only PR I'd submit would be one that simply avoids tacking on the offending line.