chr4-cookbooks / iptables-ng

Cookbook to maintain iptables rules and policies on different platforms, respecting the way the os handles these settings.
GNU General Public License v3.0
38 stars 32 forks source link

delete rules that are not part of compiled attributes? #41

Closed joshcoughlan closed 6 years ago

joshcoughlan commented 9 years ago

Hello. I'm using this cookbook to manage iptables on our servers and have run across some odd behavior. I seems that if rules are added by hand to iptables and saved (service iptables save) on CentOS6, those rules are not overwritten/erased with the next chef run. I would expect that if chef is handling the iptables configuration, then it would delete rules that it doesn't know about. It also seems that if a chef created rule is deleted manually and the the changes are saved chef will not recreate this rule on the next chef run. Help me out here. Am I doing something wrong?

joshcoughlan commented 9 years ago

It seems that the deleted chef generated rules are only recreated if the files in /etc/iptables.d/filter/INPUT/ are blown away... Is there a setting to have the cookbook actually check what is in the running iptables and clean up invalid files in /etc/iptables/*?

chr4 commented 9 years ago

This is a known "bug". I found no way so far to cleanly check whether the iptables-restore files are up-to-date without having to concatinate the files in /etc/iptables.d/ over and over again on each Chef run.

The observed behaviour is indeed true: The files in /etc/iptables.d/ that are configured in Chef are monitored, and the iptables-restore file is re-created when they are changed. The restore files itself are currently not evaluated against the content of /etc/iptables.d/.

If you have a great idea for an approach howto handle this without having to concatinate the files over and over again and re-applying the (unchanged) rules all the time, I'd apprechiate your feedback!

chr4 commented 6 years ago

Closing this because of #47 and #45, reopen if issue continues!