firewall icon indicating copy to clipboard operation
firewall copied to clipboard

Ufw failures can leave the firewall in an open state

Open ericpp opened this issue 6 years ago • 4 comments

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.

ericpp avatar Dec 16 '19 05:12 ericpp

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.

github-actions[bot] avatar Jan 29 '21 00:01 github-actions[bot]

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.

ericpp avatar Jan 29 '21 16:01 ericpp

@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.

ramereth avatar Jan 29 '21 17:01 ramereth

@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.

ericpp avatar Jan 29 '21 18:01 ericpp