Add graceful error handling for firewall tasks
matts-mpg opened this issue · 6 comments
Tonight I was working on integrating this role into another project, and came across a bug (in RHEL/CentOS, not the role). The playbook was failing on firewall related tasks (V-38512 and 38513 in particular) when running against the Vagrant box I am using for the project. I am using the bento/centos6.7 box for this, and have upgraded it to CentOS 6.8.
In any case, the expected behavior for these tasks is that /etc/sysconfig/iptables exists so that when the service iptables start is attempted in line 985 (and subsequent tasks will fail as well) the command will succeed. /etc/sysconfig/iptables is expected to always exist.
In researching this, I came across this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1161682 It appears to impact CentOS and RHEL 6.6 and above, though probably not all install/use cases. This seems to be low priority, but how would the project generally address this? Create a var whose value is set in the PRELIM tasking based on whether that file exists or not? I can make the change, but want to make sure I am taking the consistent approach.
Since there is no explicit requirement for a firewall to be installed, we should do this in prelim_tasks.yml. iptables always and ip6tables if rhel6stig_ipv6_required. The RHEL 7 STIG has a requirement to check if the firewall is installed and install it if it's missing, which makes this more straightforward to solve.
I thought there was a requirement. It looks like the Cat 2 tasks related to this check the status of iptables (for the AUDIT) and start the service if it is not started (for the PATCH). Maybe it is implied, but I believe the FW is required. Further complicating it though, this system has iptables installed. The bug reported I linked to only indicates that the /etc/sysconfig/iptables file is not properly created by anaconda at install time even though iptables is there.
. . . . unless I am reading this all wrong.
Oh geez. That's crazy-making!
Seems we'll have to come up with a strategy of getting the iptables file in a known state before the remediation tasks run. Check if it exists, copy a default config if it doesn't.
We can't use create: yes on the lineinfile tasks since it would most likely generate an invalid iptables config file.
As a note, I have "fixed" the issue on the system I am testing on simply by running "touch /etc/sysconfig/iptables" as a preliminary task before running the role. Even though it is empty, it is enough to get the failures to stop happening and the playbook can function as intended. Then the result will be that the role will determine that an empty ruleset is being applied, and it will complain about that as it is supposed to. However, "service iptables start" will not fail out due to the lack of the file.
Yeah, I was going to say that's going to result in a broken iptables. I would just add two tasks: one that stats /etc/sysconfig/iptables, then another task that copies in a basic config. Ideally we could just generate a default config with iptables-save but that doesn't have any rules in it. So after the STIG is done with the system and applies a default policy of DROP, SSH will be blocked. Not so good.
Here's a basic iptables config:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp --icmp-type any -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
Fixed by #108