Isn't idempotent; doesn't recognize if new rules have manually been added to iptables.

[jtviolet]

Cookbook version

2.2.0

Chef-client version

12.5

Platform Details

CentOS 6.7

Scenario:

I have a set list of firewall rules that Chef manages. If a rogue users goes in and manually adds a new rule to /etc/sysconfig/iptables, chef-client won't correct it during the next run of iptables.

Steps to Reproduce:

Set a list of firewall rules in chef, and run chef-client. Manually add a firewall rule to /etc/sysconfig/iptables, then restart/reload the service. Run chef-client again. Your manually added firewall rule will still be there.

Expected Result:

After running, the iptables resource should be able to detect a difference in it's output of iptables versus the current iptables in place, and change only if there is a difference.

Actual Result:

It notices no difference, and will not change anything even if a new rule has been manually added.

[jperville]

I just got bitten by this: after yum update iptables, the content of /etc/sysconfig/iptables has been replaced with a default version; the original contents (generated by this cookbook) has been moved to .rpmsave extension.

At the next chef-run, the cookbook will not notice that iptables rules have been altered, does not rebuild the /etc/sysconfig/iptables file and does not reload the rules.

[bby-bishopclark]

change https://github.com/chef-cookbooks/iptables/blob/master/recipes/default.rb#L53 to just :create ?

It should invoke the diff check and copy the proper (tiny) version into place, right?

edit: yeah, I'm an idiot but it seems to be working.

--- a/recipes/default.rb
+++ b/recipes/default.rb
@@ -50,7 +50,6 @@ end
 if platform_family?('rhel') || platform_family?('fedora')
   file '/etc/sysconfig/iptables' do
     content '# Chef managed placeholder to allow iptables service to start'
-    action :create_if_missing
   end

   template '/etc/sysconfig/iptables-config' do

[jblaine]

Not sure how this is a "Feature Request" instead of a bug :). The persisted file can be tampered with (maliciously or otherwise by yum for instance) out of band thereby subverting the entire firewall policy defined in Chef until the next rebuild-iptables run is triggered by rule changes (could be an hour from now, could be months from now).

Maybe have rebuild-iptables write out a checksum of the persisted file it wrote out, then check the checksums (every chef run) in the default recipe and force a run of rebuild-iptables if they differ?

[xorima]

Hi,

I am closing this as it relates to an old version of the cookbook which has since been fundamentally changed. If you still have the issue with the latest version please could you open a new issue,

Thanks