Ufw failures can leave the firewall in an open state

[ericpp]

Cookbook version

2.6.2

Chef-client version

12.22.5

Platform Details

Ubuntu Xenial 16.04

Scenario:

To apply a new firewall rule while ensuring the firewall stays secure

Steps to Reproduce:

Add a new ufw firewall rule while having another process hold the xtables lock. The ufw process in my case returned an Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

This seems to be caused by the way action_restart in provider_firewall_ufw.rb is written. The method first builds the rules file and only calls the ufw_reset! and ufw_rule! commands if the rules file was updated. Since the rules file is written before the actual rules are applied to ufw, the rules could be successfully written to the file while the actual calls to ufw could fail. Subsequent Chef runs won't retry the ufw calls due to the ufw_file.updated_by_last_action? check which skips over applying the rules if the rules file is unchanged.

The worst case failure is when the ufw call fails after the ufw_reset! command that deletes all rules and disables the firewall. The firewall stays disabled on subsequent Chef runs due to the rules file check.

The code referenced appears here: https://github.com/chef-cookbooks/firewall/blob/4d4dc82de010117f3920e60612628801bbd77abb/libraries/provider_firewall_ufw.rb#L88-L96

Expected Result:

For my new ufw rule to fail gracefully due to the xtables lock and for the firewall to remain in a secure state.

Actual Result:

The firewall was set to an open state as the failure occurred after the ufw_reset! command, which deleted all firewall rules and disabled the firewall.

[github-actions]

Marking stale due to inactivity. Remove stale label or comment or this will be closed in 7 days. Alternatively drop by the #sous-chefs channel on the Chef Community Slack and we'll be happy to help! Thanks, Sous-Chefs.

[ericpp]

After no resolution of this issue, we decided to move to a different cookbook. I would advise anyone relying on the ufw component of this cookbook to do the same.

[ramereth]

@ericpp which cookbook did you end up moving to? This was recently transferred to Sous Chefs which is a community of folks who are trying to clean up some of these older cookbooks.

[ericpp]

@ramereth I ended up just writing my own around the netfilter-persistent package which just updates the rules.vX files and restarts the netfilter-persistent service whenever they're updated.

To be fair to this cookbook, the ufw service doesn't provide any way of atomically updating the firewall ruleset, which is why it has to reset the firewall and incrementally rebuild the rules whenever they're updated. The problem is that it caches the rules to a file before it applies them, which causes it to assume that the rules were successfully applied by the previous run when they may not have been.