As per this inline comment[1], there's a mismatch between the title/description and the actual test for systcl-17[2], martian logging.
The title says we're testing to ensure martian logging is disabled, but the actual test verifies that the logging is enabled. If I'm understanding correctly it's possible, even likely, that this is just a simple oversight in commit bb7c532 where the test was updated correctly, but the title/description were missed.
Martian logging enabled matches the chef-os-hardening cookbook behavior[3].
The CIS standards agree martian logging should be enabled. However, the chef BaseOS compliance profile says it should be disabled, perhaps because as the sysctl-17 description states, this logging can create a DoS attack vector.
There's a valid argument to be made either way - enable the logging, or disable it. I don't know which is more correct. Seems like the Chef compliance profile is perhaps the odd man out here, and that logging should be enabled.
[1] bb7c532#commitcomment-20365340
[2]
|
control 'sysctl-17' do |
|
impact 1.0 |
|
title 'Disable log martians' |
|
desc 'log_martians can cause a denial of service attack to the host' |
|
describe kernel_parameter('net.ipv4.conf.all.log_martians') do |
|
its(:value) { should eq 1 } |
|
end |
|
end |
[3]
https://github.com/dev-sec/chef-os-hardening/blob/ea3c8b6634d1c75fa8e84d43b4122cb27293d78f/attributes/sysctl.rb#L124-L126
As per this inline comment[1], there's a mismatch between the title/description and the actual test for
systcl-17[2], martian logging.The title says we're testing to ensure martian logging is disabled, but the actual test verifies that the logging is enabled. If I'm understanding correctly it's possible, even likely, that this is just a simple oversight in commit bb7c532 where the test was updated correctly, but the title/description were missed.
Martian logging enabled matches the chef-os-hardening cookbook behavior[3].
The CIS standards agree martian logging should be enabled. However, the chef BaseOS compliance profile says it should be disabled, perhaps because as the
sysctl-17description states, this logging can create a DoS attack vector.There's a valid argument to be made either way - enable the logging, or disable it. I don't know which is more correct. Seems like the Chef compliance profile is perhaps the odd man out here, and that logging should be enabled.
[1] bb7c532#commitcomment-20365340
[2]
linux-baseline/controls/sysctl_spec.rb
Lines 186 to 193 in bb7c532
[3] https://github.com/dev-sec/chef-os-hardening/blob/ea3c8b6634d1c75fa8e84d43b4122cb27293d78f/attributes/sysctl.rb#L124-L126