Firewalld open sshd port

[yuumasato]

Select Rule firewalld_sshd_port_enabled in Profiles that

• set default zone drop for firewalld and
• allows sshd to be enabled
  Except for stig-rhel7-disa Profile.

Add remediation for configure_firewalld_ports, used only by stig-rhel7-disa Profile.

Add OVAL definition to check if current default zone allows ssh. The check fetches current set default zone from /etc/firewalld/firewalld.conf and verifies if it allows ssh service.

Issue: Above check will lead us to a situation where we will need two runs of scans and remediation.
During first scan, all zones, and current zone will allow service ssh. But then remediation will change default zone to drop. And default zone drop is not customized to allow ssh, and a second run of remediation will be needed.
Question: Can we compromise on this check and always check for /etc/firewalld/zones/drop.xml?

[jan-cerny]

Regarding your new issue: Can we simply allow ssh in remediation script that sets the default firewall zone? shared/templates/static/bash/set_firewalld_default_zone.sh

[jan-cerny]

I know it was already there, but I wonder. I thought that there is a separate rule checking if package firewalld is installed? There could be also a separate remediation that just installs the package.

[yuumasato]

There is separate Rule for firewalld installed with its own fix, but it is not selected anywhere.
Installing the package we are configuring during remediation is the way we are dealing with dependency on package_foo_installed Rules.
Not ideal, but this works around need of XCCDF requires.

[redhatrises]

configure_firewalld_ports.sh should not have a remediation script associated with it. Those should come from the <extended_definition /> scripts. These type of issues make me think that the order with which we scan and remediate rules is wrong. I wonder if we check for services first we would avoid these issues. Although, I guess not as if you don't select the correct service rule it wouldn't remediate correctly.

We should check that SSH is enabled in one of the zones but not necessarily the default zone. We should never check the drop zone for ssh enabled. In addition, the default zone may not be the zone in which the nic that SSH is enabled on is actually listening.

[yuumasato]

configure_firewalld_ports.sh should not have a remediation script associated with it. Those should come from the <extended_definition /> scripts.

The check comes from OVAL extend_definition elements, but the fixes comes from XCCDF, and it is picked automatically by build system by looking at Rule ID.
Moreover, what is checked in configure_firewalld_ports may change in the future, enabling other ports, right? So an appropriate remediation script be might be needed anyway.

These type of issues make me think that the order with which we scan and remediate rules is wrong. I wonder if we check for services first we would avoid these issues. Although, I guess not as if you don't select the correct service rule it wouldn't remediate correctly.

Evaluation of Rules occurs according to their order in the Benchmark, scanner should go from top to bottom. (Note that order of selectors in Profile doesn't affect order of evaluation of Rules, this bit me while writing test for XCCDF requires PR for OpenSCAP).
I see in the benchmark that for firewalld, package installed is before configure_firewalld_ports.
And for sshd, firt is package installed, then service enabled, and then other Rules.

The problem I see is that scanner first evaluates all Rules, then remediates all Rules.
Does specification allow scanner to have a mode in which a Rule evaluated as false is remediated before moving to evaluating next Rule?

We should check that SSH is enabled in one of the zones but not necessarily the default zone. We should never check the drop zone for ssh enabled. In addition, the default zone may not be the zone in which the nic that SSH is enabled on is actually listening.

So we should check if there is at least one NIC assigned to a zone which allows SSH.
As for the remediation for firewalld_sshd_port_enabled, as it is now, it allows service ssh to current default zone, be it drop or other. We should specify a zone, and have a variable for user to customize it.

[yuumasato]

I have changed check to verify if there is any NIC assigned to a zone which allows service SSH.
We still miss remediation.
I'm not sure what values to use fore remediation.
Defaulting to first Ethernet interface found is ok?
And what zone to assign the NIC to?

[yuumasato]

@openscap-ci test this please

There was error during fetch of repository:
https://jenkins.open-scap.org/job/scap-security-guide-pull-requests/311/label=ssg_new/console

[yuumasato]

@openscap-ci test this please

[shawndwells]

WRT NIC assignments: How does Anaconda open up the ports? Is it anything more than
firewall-cmd --zone=public --add-port=22/tcp --permanent ?

[yuumasato]

@openscap-ci test this please

[yuumasato]

@shawndwells In witch context? We don't have remediation for Anaconda for firewalld.

[redhatrises]

@shawndwells In witch context? We don't have remediation for Anaconda for firewalld.

Which I would argue more and more that we need to have.

I'm not sure what values to use fore remediation.
Defaulting to first Ethernet interface found is ok?
And what zone to assign the NIC to?

I would do the following:

1. Check if ssh is enabled in a zone. If not, fix.
2. Check if nic is assigned to a zone. If not fix.
3. If nic is assigned to zone, and ssh is enabled, do nothing. This should account for custom zone and nic settings.

[shawndwells]

On 9/6/17 12:22 PM, Watson Yuuma Sato wrote: @shawndwells <https://github.com/shawndwells> In witch context? We don't have remediation for Anaconda for firewalld.

In terms of the generic installer / default rule sets.

[redhatrises]

@yuumasato I wonder if we could create some sort of way to extend remediation scripts to follow their extended definitions so that we don't have to duplicate scripts. Might not be in this PR, but it could be beneficial to prevent script duplication as well as allow us to extend scripts easier?

[yuumasato]

@redhatrises What would be the benefits of an Anaconda remediation? OAA will run the post install scan and remediation.

What we will need is a bash remediation that doesn't depend on firewall-cmd command. As we are in chrooted environment firewall-cmd will probably not be available.

So, for the remediation of this rule I will default to adding the first ethernet interface found to the public zone.

About extending remediations, that could be helpful. But I'm not sure if automatically mimicking the extends done in OVAL is a good idea.

[redhatrises]

@redhatrises What would be the benefits of an Anaconda remediation? OAA will run the post install scan and remediation.

Not true with anaconda scripts which are supposed to be evaluated pre-install using python kickstart functionality. If the anaconda scripts are not evaluated before the system acutally installs, this is a serious bug as the kickstart and build is supposed to be modified to fix packages, services, etc. By adding the kickstart firewall command functionality to OAA, this should handle setting firewall settings, and we don't have to worry about firewall-cmd as that is handled for us.

For post-install, these remediation scripts are still needed hence what you are doing in this PR.

About extending remediations, that could be helpful. But I'm not sure if automatically mimicking the extends done in OVAL is a good idea.

True. Just a thought. It does seem weird to me that any remediation script associated with <extend_definition/> is not run as part of the remediation. But I guess the issue lies with the fact that <fixtext/> is in XCCDF and not OVAL.

[yuumasato]

I'll add some tests for this remediation.

[yuumasato]

Regarding Anaconda scenario, OAA doesn't support kickstart firewall option.
So, the way to go for now is to have bash remediation based on sed/grep functions.

[yuumasato]

This should be complete now. Summary for reviewer:

• Rule 'firewalld_sshd_port_enabled' selected in Profiles that set drop as default zone
• OVAL definition updated to check that there is a NIC assigned to a zone with SSH enabled
• Remediation that can add SSH service to a zone and bind a NIC to it
  • Defaults to public zone and first ethernet interface found
  • Works in chrooted and non-chrooted environments
• Tests scenarios for remediation added

Log of SSG TestSuite:

Setting console output to log level INFO
INFO - Logging into /home/wsato/git/scap-security-guide/tests/logs/rule-custom-2017-09-13-1514/test_suite.log
INFO - xccdf_org.ssgproject.content_rule_firewalld_sshd_port_enabled
INFO - Script no_nic_in_ssh_zone.fail.sh using profile xccdf_org.ssgproject.content_profile_ospp-rhel7 OK
INFO - Script ssh_zone_nic_bounded.pass.sh using profile xccdf_org.ssgproject.content_profile_ospp-rhel7 OK
INFO - Script ssh_zone_and_nic_mismatch.fail.sh using profile xccdf_org.ssgproject.content_profile_ospp-rhel7 OK
INFO - Script no_ssh_zone.fail.sh using profile xccdf_org.ssgproject.content_profile_ospp-rhel7 OK
INFO - All snapshots reverted successfully

[mpreisler]

ACK. Awesome stuff.

[dahaic]

Thank you, great PR!

I have one possible issue with that - in real scenarios, it's more than likely that multiple network interfaces are present on the machine, and a specific one (it might be even a bond or VPN connection, not the low-level stuff) is supposed to have ssh allowed.

Can you alter the code once again to have network interface in the value? (With possible default behaviour not touching interfaces at all?). Thanks!