You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.
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 injects
logcollectorinto 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 injects
logcollector` 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-typesProposed 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
The text was updated successfully, but these errors were encountered: