`RHEL7-CIS : 3.5.1.5 | AUDIT | Ensure default zone is set` fails although firewalld is up

[mcascone]

Describe the Issue The playbook fails when testing firewalld, which it shouldn't, because it's running.

Expected Behavior The firewalld test doesn't fail, even if the configuration is not correct.

Actual Behavior

RHEL7-CIS : 3.5.1.4 | PATCH | Ensure firewalld service is enabled and running] *******************************************************
changed: [target.ip.address]

RHEL7-CIS : 3.5.1.5 | AUDIT | Ensure default zone is set] ****************************************************************************
fatal: [target.ip.address]: FAILED! => {"changed": false, "cmd": ["firewall-cmd", "--get-default-zone"], "delta": "0:00:00.190092", "end": "2024-01-24 20:27:59.889292", "msg": "non-zero return code", "rc": 252, "start": "2024-01-24 20:27:59.699200", "stderr": "FirewallD is not running", "stderr_lines": ["FirewallD is not running"], "stdout": "", "stdout_lines": []}

PLAY RECAP **************************************************************************************************************************************************************************************
target.ip.address            : ok=94   changed=47   unreachable=0    failed=1    skipped=87   rescued=0    ignored=0   

❯ ssh my_user@target.ip.address
[my_user@target.ip.address ~]$ sudo firewall-cmd --get-default-zone
public
[my_user@target.ip.address ~]$ sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2024-01-24 19:42:32 UTC; 47min ago
     Docs: man:firewalld(1)
 Main PID: 543 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─543 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid

Control(s) Affected What controls are being affected by the issue

Environment (please complete the following information):

• branch being used: devel
• OS: centos7

[uk-bolly]

hi @mcascone

Thank you for taking the time to raise this issue. Reading through the steps, it appears to be changing the enabled/running state in 3.5.1.4. If you run the commands on a clean build manually in that order are you seeing the same response?

e.g.

• get service status
• run the start and enable
• get service status
• get default zone

As you have pointed out this doesn't make sense if it starts it the step before. We also use centos to test our code before working on rhel, on a clean build and dont see this issue.

many thanks

uk-bolly

[mcascone]

This one is on me; my vms were coming out of provisioning without firewalld installed. Why that would be the case is another issue, but when I install it and then run the audit, it works.