chef-cookbooks/iptables

Development repository for Chef Cookbook iptables

iptables's Issues

Update documentation to use `rule` instead of `iptables_rule`

iptables_rule was changed to rule in 1.0 (per the README) but the examples still say iptables_rule.

On a side note, it's unfortunate that this cookbook takes such a generic resource name rule. It may have been better as iptable_rule when it was converted to a custom resource.

fix rebuild-iptables to load system-created rules

Cookbook version

4.5.0

Chef-client version

14.7.17

Platform Details

CentOS Linux release 7.5.1804 (Core)

Scenario:

Store existing rules to the suffix template on installation. "/etc/sysconfig/iptables" -> /etc/iptables.d/suffix
Then process them with newly added rules.
However, rebuild-iptables can't read existing rules if they have extra chains, because of a mistake in a regular expression.

Steps to Reproduce:

store content of the /etc/iptables.d/suffix file to /etc/iptables.d/suffix file
run cookbook or just /usr/sbin/rebuild-iptables

Expected Result:

newly created file /etc/sysconfig/iptables has correct syntax and successfully loaded via iptables-restore

Actual Result:

file /etc/sysconfig/iptables has two rows with ":node_exporter", and iptables-restore fails.

[root@generic-ctec-c4t aryabov]# /usr/sbin/rebuild-iptables 
iptables-restore v1.4.21: error creating chain 'node_exporter':File exists

Error occurred at line: 7
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
Traceback (most recent call last):
/usr/sbin/rebuild-iptables:134:in `<main>': /usr/sbin/rebuild-iptables: failed to install iptables rules (RuntimeError)
[root@generic-ctec-c4t aryabov]# grep :node_exporter /etc/sysconfig/iptables
:node_exporter -
:node_exporter - [0:0]
[root@generic-ctec-c4t aryabov]# cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:node_exporter -
# Generated by iptables-save v1.4.21 on Mon Nov 26 23:17:18 2018
:node_exporter - [0:0]
-A INPUT -p tcp -m tcp --dport 9500 -m comment --comment "RKS: RTTs" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9600 -m comment --comment "RKS: Ts" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9100 -j node_exporter
-A INPUT -p icmp -m icmp --icmp-type 8 -j node_exporter
-A node_exporter -s 172.22.46.69/32 -m comment --comment "NodeExporter: prom-ctec-c1t" -j ACCEPT
-A node_exporter -s 172.30.104.186/32 -m comment --comment "NodeExporter: mws02" -j ACCEPT
-A node_exporter -s 127.0.0.1/32 -j ACCEPT
-A node_exporter -p tcp -j REJECT --reject-with tcp-reset
-A node_exporter -p tcp -j DROP
# Completed on Mon Nov 26 23:17:18 2018
COMMIT
[root@generic-ctec-c4t aryabov]# cat /etc/iptables.d/suffix 
# Generated by iptables-save v1.4.21 on Mon Nov 26 23:17:18 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:node_exporter - [0:0]
-A INPUT -p tcp -m tcp --dport 9500 -m comment --comment "RKS: RTTs" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9600 -m comment --comment "RKS: Ts" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9100 -j node_exporter
-A INPUT -p icmp -m icmp --icmp-type 8 -j node_exporter
-A node_exporter -s 172.22.46.69/32 -m comment --comment "NodeExporter: prom-ctec-c1t" -j ACCEPT
-A node_exporter -s 172.30.104.186/32 -m comment --comment "NodeExporter: mws02" -j ACCEPT
-A node_exporter -s 127.0.0.1/32 -j ACCEPT
-A node_exporter -p tcp -j REJECT --reject-with tcp-reset
-A node_exporter -p tcp -j DROP
COMMIT
# Completed on Mon Nov 26 23:17:18 2018
[root@generic-ctec-c4t aryabov]# ls /etc/iptables.d/
suffix
[root@generic-ctec-c4t aryabov]# 

Possible fix for the issue:

KAPAMACM00NFD58:iptables p2771530$ diff -u templates/default/rebuild-iptables.erb.old templates/default/rebuild-iptables.erb
--- templates/default/rebuild-iptables.erb.old	2018-12-17 12:10:49.000000000 -0700
+++ templates/default/rebuild-iptables.erb	2018-12-17 12:11:07.000000000 -0700
@@ -32,7 +32,7 @@
       read_iptables($1, table)
     elsif line =~ /^\s*\*([a-z]+)\s*$/
       table = $1.to_sym
-    elsif line =~ /^\s*:([-a-zA-Z0-9_]+)(?:\s+([A-Z]+(?:\s*\[.*?\])))?$/
+    elsif line =~ /^\s*:([-a-zA-Z0-9_]+)(?:\s+([A-Z-]+(?:\s*\[.*?\])))?$/
       @data[table][:chains][$1] = $2 || '-'
     elsif line !~ /^\s*COMMIT\s*$/
       #detect new chains
KAPAMACM00NFD58:iptables p2771530$ 

Verify that the prefix and postfix rules end up in the right place

Ideally, we should actually be testing to see if we start by adding the chain in the right place and that the block all ends up at the end.

wrong number of arguments for iptables_rule

Recipe: caws-zabbix::iptables_httpd


           ================================================================================
           Error executing action `enable` on resource 'iptables_rule[http]'
           ================================================================================

           ArgumentError
           -------------
           wrong number of arguments (1 for 0)

           Cookbook Trace:
           ---------------
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/resource_builder.rb:39:in `initialize'
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/resource_builder.rb:39:in `initialize'
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/dsl/declare_resource.rb:100:in `new'
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/dsl/declare_resource.rb:100:in `build_resource'
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/dsl/declare_resource.rb:67:in `declare_resource'
           /tmp/kitchen/cache/cookbooks/iptables/resources/rule.rb:26:in `block in class_from_file'
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/provider.rb:118:in `instance_eval'
           /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/provider.rb:118:in `compile_and_converge_action'

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/caws-zabbix/recipes/iptables_httpd.rb

             6: iptables_rule 'http' do
             7:   action :enable
             8: end

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/caws-zabbix/recipes/iptables_httpd.rb:6:in `from_file'

           iptables_rule("http") do
             action [:enable]
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             declared_type :iptables_rule
             cookbook_name "caws-zabbix"
          recipe_name "iptables_httpd"
           end


       Running handlers:
       [2016-02-08T17:08:14+00:00] ERROR: Running exception handlers
       Running handlers complete
       [2016-02-08T17:08:14+00:00] ERROR: Exception handlers complete
       Chef Client failed. 1 resources updated in 05 seconds
       [2016-02-08T17:08:14+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       [2016-02-08T17:08:14+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
       [2016-02-08T17:08:14+00:00] ERROR: iptables_rule[http] (caws-zabbix::iptables_httpd line 6) had an error: ArgumentError: wrong number of arguments (1 for 0)
       [2016-02-08T17:08:16+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

This seemed to have been working last week but this morning it seems to not be.

Chef Client is version 12.6.0 on a CentOS 6.7 VM.

The recipe:

#
# Cookbook Name:: caws-zabbix
# Recipe:: iptables_httpd
# Description:: Opens IPTables for port 80 (Zabbix)

iptables_rule 'http' do
  action :enable
end

The http.erb file:
-A FWR -p tcp -m tcp --dport 80 -j ACCEPT

Getting issue while running Bootstrap command in Chef

Are you sure you want to continue connecting
? (Y/N) y
WARN: [SSH] PTY requested: stderr will be merged into stdout
WARN: [SSH] connection failed, terminating (#<Net::SSH::AuthenticationFailed: Authentication failed for user [email protected]>)
ERROR: Train::Transports::SSHFailed: SSH session could not be established
PS C:\Users\atitt\Documents\Devops classes\chef-starter\chef-repo> knife bootstrap 18.222.26.169 --sudo -i "chefnode.pem" -x 'ubuntu' -N '-ip-172-31-20-216.us-east-2.compute-internal'
C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/rbvmomi-1.13.0/lib/rbvmomi/vim.rb:8: warning: Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead
-x/--winrm-user: This flag is deprecated. Use -U/--connection-user instead.
Connecting to 18.222.26.169
WARN: [SSH] PTY requested: stderr will be merged into stdout
The authenticity of host '18.222.26.169 ()' can't be established.
fingerprint is SHA256:xEk5/V+wbLDXb+OKBL9o8zDex1Sf9jLxbX5xqVhmwSc.

Are you sure you want to continue connecting
? (Y/N) y
WARN: [SSH] PTY requested: stderr will be merged into stdout
WARN: [SSH] connection failed, terminating (#<Net::SSH::AuthenticationFailed: Authentication failed for user [email protected]>)
ERROR: Train::Transports::SSHFailed: SSH session could not be established

ruby no in /opt/chef/embedded/bin/ruby when calling rebuild-iptables

Cookbook version

3.0.1

Chef-client version

12.16.42

Platform Details

Raspbian (Raspberry Pi)

Scenario:

In the raspberry pi, where I had to compile my own version of ruby to install chef-client 12, rebuild-iptables is failing because it cannot find ruby in the address of the generated shebang: #!/opt/chef/embedded/bin/ruby -w
Note that in my env ruby is in /usr/local/bin/ruby

I think it should be better not to have this hard dependency to /opt/chef/embedded/bin. I see you're planning to move rebuild-iptables to a library (this would fix the problem), but meanwhile I would call ruby /usr/sbin/rebuild-iptables instead of plain /usr/sbin/rebuild-iptables

Steps to Reproduce:

Just adding the default recipe to the run_list and other recipe with any iptables rule

Expected Result:

(After I linked /opt/chef/embedded/bin/ruby to /usr/local/bin/ruby I got:

Recipe: iptables::default
  * execute[rebuild-iptables] action run
    - execute /usr/sbin/rebuild-iptables

Running handlers:
Running handlers complete
Chef Client finished...

Actual Result:

Without the link:

Recipe: iptables::default
  * execute[rebuild-iptables] action run
    
    ================================================================================
    Error executing action `run` on resource 'execute[rebuild-iptables]'
    ================================================================================
    
    Errno::ENOENT
    -------------
    No such file or directory - /usr/sbin/rebuild-iptables
    
    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/iptables/recipes/default.rb
    
     24: execute 'rebuild-iptables' do
     25:   command '/usr/sbin/rebuild-iptables'
     26:   action :nothing
     27: end
     28: 
    
    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/iptables/recipes/default.rb:24:in `from_file'
    
    execute("rebuild-iptables") do
      action [:nothing]
      retries 0
      retry_delay 2
      default_guard_interpreter :execute
      command "/usr/sbin/rebuild-iptables"
      backup 5
      returns 0
      declared_type :execute
      cookbook_name "iptables"
      recipe_name "default"
    end
    
    Platform:
    ---------
    armv6l-linux-eabihf
...

# /usr/sbin/rebuild-iptables 
bash: /usr/sbin/rebuild-iptables: /opt/chef/embedded/bin/ruby: bad interpreter: No such file or directory

IPv6 support

Hi,

looks like this cookbook and the included rebuild-iptables script does not work with IPv6, e.g. does not call ip6tables-restoreetc.

A simple solution would be:

Prefix all IPv4 rules with "-4", e.g.
-4 -A FWR -p udp --source 10.0.0.1/32 --dport 5432 -j ACCEPT

Prefix all IPv6 rules with "-6", e.g.
-6 -A FWR -p udp --source 2a03::1234/64 --dport 5432 -j ACCEPT

Debian:
Modify https://github.com/opscode-cookbooks/iptables/blob/master/templates/default/rebuild-iptables.erb#L63 to feed the result to both /sbin/iptables-restoreand /sbin/ip6tables-restore.

RHEL:
Modify https://github.com/opscode-cookbooks/iptables/blob/master/templates/default/rebuild-iptables.erb#L55 to write all records both to /etc/sysconfig/ip6tables and /etc/sysconfig/iptables.

(not sure about restarting service)

However, this will break all existing rules that don't have "-4" or "-6" in it. An automatically default prefixing with "-4" might break existing rules that don't have an IP address in it for IPv6.

"knife cookbook site install" not working

I tried installing the cookbook using "knife cookbook site install" and I get the following error.

ERROR: IOError: Cannot open or read /home/chef-repo/cookbooks/iptables/metadata.rb!

Also, I noticed a metadata.json gets generated inside the cookbook directory, but no metadata.rb is present.

Any thoughts?

Documentation: Attribute-based rules pull in invalid attributes

Cookbook version

4.3.0

Chef-client version

12.12.x

Platform Details

CentOS/RHEL 6

Scenario:

When using the example for building and iterating over attributes to generate iptables rules, the documentation suggests using ['iptables']['blah'] to generate the rules, then iterating over them. The mechanism works, but the suggested namespace already has ['iptables']['iptables_sysconfig'], ['iptables']['ip6tables_sysconfig'], and ['iptables']['system_ruby'] in it from the attributes file. This generates invalid iptables rules and breaks the script.

Steps to Reproduce:

Use the attribute-based mechanism to generate one rule, as per the documentation:
node.default['iptables']['port_80'] =

Expected Result:

A file gets dropped in /etc/iptables.d/port_80 with the rule and iptables rebuilds.

Actual Result:

A file gets dropped in /etc/iptables.d/port_80 with the rule, as does:

• /etc/iptables.d/iptables_config
• /etc/iptables.d/ip6tables_config
• /etc/iptables.d/system_ruby

rebuild-iptables breaks when trying to parse the first file.

Can't use INPUT chain on the filter table when using this cookbook?

I was trying to add a rule for ssh which I put into my template like:

-A INPUT -p tcp --dport 22 -j ACCEPT

But it appears as if this rule: -A INPUT -j FWR trumps my rule and sends everything to the FWR chain. My rule works if I put '-A FWR' instead but the documentation isn't clear that that is required when using this cookbook.

Am I doing something wrong? Is it possible to add to the INPUT chain in the filter table?

Whatever the answer is I'll follow up with a pull request to make the documentation more clear (unless it's there and I'm just missing it)

Thanks,

MG

Can we move the iptables-rebuild script into a ruby library?

@thommay @tas50 @iennae am I missing something here? Does this have to be an external command API for some reason?

It seems like we drop the file on the filesystem and then only ever execute it from this cookbook -- we could move it to a library and then ruby_block it and i can't see what would change (other than we could properly use shell_out! and avoid shebang-hell and maybe write a real resource for what it does?)

Laying down of postfix rules bricks my VM

I'm using this cookbook in Centos 6.5 on AWS instances, the postfix recipe ends up at the end and essentially bricks the instance, since I can't access it thnourgh ssh anymore
The resulting /etc/sysconfig/iptables looks like this:

*filter
:INPUT ACCEPT [0,0]
:FORWARD ACCEPT [0,0]
:OUTPUT ACCEPT [0,0]
:FWR -
-A INPUT -j FWR
-A FWR -i lo -j ACCEPT
# Any established connection is money
-A FWR -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMP 
-A FWR -p icmp -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 9102 -m comment --comment "Bacula client port" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 7000 -m comment --comment "Cassandra Storage" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 7001 -m comment --comment "Cassandra SSL" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 9160 -m comment --comment "Cassandra RPC" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 9042 -m comment --comment "Cassandra Native Transport" -j ACCEPT

-A OUTPUT -p udp --dport 123 -m comment --comment "ntpd" -j ACCEPT
-A INPUT  -p udp --dport 1813 -m comment --comment "radiusd" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 8009 -m comment --comment "tomcat" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 27017 -m comment --comment "mongo" -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 8443 -m comment --comment "https" -j ACCEPT
-A FWR -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
-A FWR -p udp -j REJECT --reject-with icmp-port-unreachable
COMMIT

Am I missing anything that it should be doing that is not?

Compile time errors in ChefSpec

Cookbook version

4.3.3

Chef-client version

ChefDK 2.4.17

Platform Details

Travis-CI

Scenario:

Trying to get what were passing specs to run and it looks like a recent change has now caused compile errors.

Steps to Reproduce:

Write a ChefSpec test with a cookbook that includes the iptables cookbook as a dependency, doesn't even have to be a direct dependency, it will fail.

Expected Result:

I expect it to compile and run the tests, but it does not get that far.

Actual Result:

Here is the backtrace I see in CI:

Chef::Exceptions::ValidationFailed:
       Property source must be one of: String!  You passed nil.
     # /tmp/chefspec20180215-4772-1f2r2qhfile_cache_path/cookbooks/iptables/resources/rule.rb:20:in `class_from_file'
     # ./spec/unit/recipes/networking_spec.rb:28:in `block (2 levels) in <top (required)>'
     # ./spec/unit/recipes/networking_spec.rb:37:in `block (3 levels) in <top (required)>'

The spec backtrace lines at the bottom are the ChefSpec::ServerRunner block calling env.converge(described_recipe) so this is definitely a compile time issue and validation is exploding.

No resource or method named `iptables_rule' for `Chef::Recipe "default"'

Cookbook version

3.0.1

Chef-client version

12.17.44, tried also 12.9.41

Platform Details

ubuntu-1204

Scenario:

Trying to converge kitchen instance for the first time

Steps to Reproduce:

1. clone the cookbook
2. kitchen converge default-ubuntu-1204

Expected Result:

Kitchen instance installed with the rule ssh

Actual Result:

Chef fails on No resource or method named iptables_rule' for Chef::Recipe "default"'
error output:
https://gist.github.com/hagay3/e6a82a7a5188c03e351af2a7638d64b5

using iptables::disabled doesn't flush the current ruleset

Cookbook version

3.0.1

Chef-client version

12.14.89

Platform Details

RHEL 6.8

Scenario:

We had shifted some IPTables rules from our hosts into our firewalls and thought an easy way to rollback all of the rulesets in iptables would be to just include iptables::disabled, however we found that while this removes the files from /etc/iptables.d, this doesn't flush the existing rule set.

Steps to Reproduce:

1. Set up a host and add a few arbitrary rules to IPTables
2. include the iptables::disabled recipe

Expected Result:

IPTables would be disabled and the ruleset flushed

Actual Result:

IPTables ruleset is still active

Test iptables rules before trying to apply

Cookbook version

version 4.3.1

Chef-client version

version 12.18.31

Platform Details

Centos

Scenario:

Test iptables rules before trying to apply

Steps to Reproduce:

Expected Result:

Do not apply if rules are inconsistent

Actual Result:

Rules are applied even if we have an error so we can have missing rules and unexpected behavior

Request: better /usr/sbin/rebuild-iptables error messages on failure

Cookbook version

4.3.4

Chef-client version

13.8.5-1

Platform Details

debian-8, debian-9

Scenario:

If the iptables rules specified in the cookbook/recipe are invalid, the error message from a chef-client client run should identify the text of the rule that failed to apply.

Steps to Reproduce:

chef generate cookbook iptables-demo
cd iptables-demo
echo "depends 'iptables', '~> 4.3.4'" >> metadata.rb
echo "include_recipe 'iptables::default'" >> recipes/default.rb
echo "iptables_rule 'sample' do" >> recipes/default.rb
echo "  lines '-A DROP'" >> recipes/default.rb
echo "end" >> recipes/default.rb
## configure test kitchen for debian-8
kitchen converge

Expected Result:

chef-client should report the standard output of /usr/sbin/rebuild-iptables, and this output should include the specific iptables rule that failed to apply (in this case -A DROP, because it has no chain name).

Actual Result:

iptables-apply indeed generates the message,

Applying new iptables rules from '/etc/iptables/general'... iptables-restore: line 5 failed

where line 5 of this file is,

-A DROP

But rebuild-iptables doesn't output this last piece of information:

Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/rebuild-iptables ----
STDOUT:
STDERR: iptables-restore: line 5 failed
/usr/sbin/rebuild-iptables:137:in `

': /usr/sbin/rebuild-iptables: failed to install iptables rules (RuntimeError)
---- End output of /usr/sbin/rebuild-iptables ----
Ran /usr/sbin/rebuild-iptables returned 1

Version 2.2.0 undefined method `property' for Chef::Resource::IptablesRule:Class

I fixed the issue changing version to 1.0.0

Compiling Cookbooks...

================================================================================
Recipe Compile Error in .../chef-solo/cookbooks-2/iptables/resources/rule.rb
================================================================================

NoMethodError
-------------
undefined method `property' for Chef::Resource::IptablesRule:Class

Cookbook Trace:
---------------
 .../chef-solo/cookbooks-2/iptables/resources/rule.rb:20:in `class_from_file'

Relevant File Content:
----------------------
.../chef-solo/cookbooks-2/iptables/resources/rule.rb:

 13:  #
 14:  # Unless required by applicable law or agreed to in writing, software
 15:  # distributed under the License is distributed on an "AS IS" BASIS,
 16:  # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 17:  # See the License for the specific language governing permissions and
 18:  # limitations under the License.
 19:
 20>> property :name, kind_of: String, name_attribute: true
 21:  property :source, kind_of: String, default: nil
 22:  property :cookbook, kind_of: String, default: nil
 23:  property :variables, kind_of: Hash, default: {}
 24:
 25:  action :enable do
 26:    execute 'rebuild-iptables' do
 27:      command '/usr/sbin/rebuild-iptables'
 28:      action :nothing
 29:    end

BIG SECURITY ISSUE in rebuild-iptables

The new rebuild-script of the current git version does not add the FWR chain to
the INPUT chain, like this:

-A FWR -p icmp -j ACCEPT

and it does not drop packets at the end of the FWR chain, if no rules match:

-A FWR -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-  port-unreachable
-A FWR -p udp -j REJECT --reject-with icmp-port-unreachable

This means all packets will pass the firewall!

add chefspec matcher

e.g.

def enable_iptables_rule(resource_name)
  ChefSpec::Matchers::ResourceMatcher.new(:iptables_rule, :enable, resource_name)
end

Error: undefined method `validate' in rule.rb

Cookbook version

2.2.0

Chef-client version

12.7+

Platform Details

RHEL

Scenario:

In Chef 13 this will become an error.

Steps to Reproduce:

 # recipes/*.rb
 iptables_rule 'redis' do
   source 'config/iptables.erb'
   variables(nodes: nodes)
 end

 # templates/*.erb
 -A INPUT -s 127.0.0.1 -j ACCEPT -p tcp --dport 6379

Expected Result:

- /var/chef/cache/cookbooks/iptables/resources/rule.rb:22:in `class_from_file'
 Default value {} is invalid for property #<ChefCompat::CopiedFromChef::Chef::Property:0x0000000573ed08>. In Chef 13 this will become an error: undefined method `validate' for nil:NilClass. at 1 location:
 - /var/chef/cache/cookbooks/iptables/resources/rule.rb:23:in `class_from_file'

Actual Result:

- /var/chef/cache/cookbooks/iptables/resources/rule.rb:22:in `class_from_file'
 Default value {} is invalid for property #<ChefCompat::CopiedFromChef::Chef::Property:0x0000000573ed08>. In Chef 13 this will become an error: undefined method `validate' for nil:NilClass. at 1 location:
 - /var/chef/cache/cookbooks/iptables/resources/rule.rb:23:in `class_from_file'

supermarket version does not have metadata.rb

I had the following issue which I described in berkshelf/berkshelf#1409
After checking I noticed that when trying to berks install iptables the supermarket version comes without any metadata.rb file causing berks upload to fail.

rebuild-iptables script does not return non-zero exit code on RedHat / CentOs

Hi,

if iptables rule is incorrect and restarting iptables fails this does not fail chef-client execution, hence potential vulnerability.

Lines of code from rebuild-iptables.erb :

def install_redhat(data)
  write_iptables("/etc/sysconfig/iptables", data)
  system("/sbin/service", "iptables", "restart")
end

The notification to rebuild-iptables in iptables_rule isn't delayed

Cookbook version

2.2.0

Chef-client version

12.13.27

Platform Details

Centos 7.2

Scenario:

Just adding some iptable rules (>4) with the iptable_rule resource.

Steps to Reproduce:

Just add 5 or more iptable rules with the resource.

Expected Result:

At the end of the chef run, rebuild-iptables is executed

Actual Result:

It is executed at the end of each resource statement:

==> default:   * iptables_rule[11_ping] action enable
==> default:     * execute[rebuild-iptables] action nothing (skipped due to action :nothing)
==> default:     * template[/etc/iptables.d/11_ping] action create[2016-09-21T19:44:41+00:00] INFO: template[/etc/iptables.d/11_ping] created file /etc/iptables.d/11_ping
==> default:
==> default:       - create new file /etc/iptables.d/11_ping[2016-09-21T19:44:41+00:00] INFO: template[/etc/iptables.d/11_ping] updated file contents /etc/iptables.d/11_ping
==> default:
==> default:       - update content in file /etc/iptables.d/11_ping from none to 689b1e
==> default:       --- /etc/iptables.d/11_ping  2016-09-21 19:44:41.831375999 +0000
==> default:       +++ /etc/iptables.d/.chef-11_ping20160921-12337-pscywv   2016-09-21 19:44:41.831375999 +0000
==> default:       @@ -1 +1,2 @@
==> default:       +-A INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT[2016-09-21T19:44:41+00:00] INFO: template[/etc/iptables.d/11_ping] mode changed to 644
==> default:
==> default:       - change mode from '' to '0644'
==> default:
==> default:       - restore selinux security context
==> default: [2016-09-21T19:44:41+00:00] INFO: template[/etc/iptables.d/11_ping] sending run action to execute[rebuild-iptables] (delayed)
==> default:     * execute[rebuild-iptables] action run
==> default:
==> default:       [execute] Redirecting to /bin/systemctl restart  iptables.service
==> default: [2016-09-21T19:44:42+00:00] INFO: execute[rebuild-iptables] ran successfully
==> default:       - execute /usr/sbin/rebuild-iptables
==> default:
==> default:   * iptables_rule[20_http] action enable
==> default:     * execute[rebuild-iptables] action nothing (skipped due to action :nothing)
==> default:     * template[/etc/iptables.d/20_http] action create[2016-09-21T19:44:42+00:00] INFO: template[/etc/iptables.d/20_http] created file /etc/iptables.d/20_http
==> default:
==> default:       - create new file /etc/iptables.d/20_http[2016-09-21T19:44:42+00:00] INFO: template[/etc/iptables.d/20_http] updated file contents /etc/iptables.d/20_http
==> default:
==> default:       - update content in file /etc/iptables.d/20_http from none to 1f494a
==> default:       --- /etc/iptables.d/20_http  2016-09-21 19:44:42.046483500 +0000
==> default:       +++ /etc/iptables.d/.chef-20_http20160921-12337-1xw2vft  2016-09-21 19:44:42.046483500 +0000
==> default:       @@ -1 +1,2 @@
==> default:       +-A INPUT -p tcp --dport 80 -m limit --limit 100/minute --limit-burst 100 -m state --state NEW,ESTABLISHED -j ACCEPT[2016-09-21T19:44:42+00:00] INFO: template[/etc/iptables.d/20_http] mode changed to 644
==> default:
==> default:       - change mode from '' to '0644'
==> default:
==> default:       - restore selinux security context
==> default: [2016-09-21T19:44:42+00:00] INFO: template[/etc/iptables.d/20_http] sending run action to execute[rebuild-iptables] (delayed)
==> default:     * execute[rebuild-iptables] action run
==> default:
==> default:       [execute] Redirecting to /bin/systemctl restart  iptables.service
==> default:                 Job for iptables.service failed because start of the service was attempted too often. See "systemctl status iptables.service" and "journalctl -xe" for details.
==> default:                 To force a start use "systemctl reset-failed iptables.service" followed by "systemctl start iptables.service" again.
==> default: [2016-09-21T19:44:42+00:00] INFO: execute[rebuild-iptables] ran successfully
==> default:       - execute /usr/sbin/rebuild-iptables

rebuild-iptables failing on debian

Cookbook version

Current master branch at 32bbecd

Chef-client version

Chef: 12.10.24

Platform Details

Developing on OS X, client runs Debian GNU/Linux 8.4 (jessie)

Scenario:

Rules are not applied to iptables. The rule files are put in /etc/iptables.d/, but are not being loaded due to an error thrown by rebuild-iptables.

Steps to Reproduce:

• Add `cookbook 'iptables', github: 'chef-cookbooks/iptables'`` to Berksfile
• Add depends 'iptables' to metadata.rb
• Add iptables_rule 'http_80' { lines '-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT' }
• Run kitchen converge
• See missing rules when executing iptables -L
• SSH into client and manually run rebuild-iptables to try
• See that rules are still missing when executing iptables -L

Expected Result:

iptables -L should display rules, and manually running rebuild-iptables should not throw an error.

Actual Result:

When running rebuild-iptables, the following error message is displayed:

Bad argument `{IP6TABLES_MODULES'
Error occurred at line: 7
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
cp: cannot create regular file '/etc/sysconfig/iptables': No such file or directory

Also, there is no /etc/sysconfig on jessie.

No resource or method named `with_run_context' for `LWRP resource iptables_rule from cookbook iptables action provider

Cookbook version

~> 4.0.0

Chef-client version

Chef: 12.5.1

Platform Details

Ubuntu 12

Scenario:

Running Chef and encounter:

  * iptables_rule[cassandra] action enable

    ================================================================================
    Error executing action `enable` on resource 'iptables_rule[cassandra]'
    ================================================================================

    NoMethodError
    -------------
    No resource or method named `with_run_context' for `LWRP resource iptables_rule from cookbook iptables action provider "cassandra"'

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/iptables/resources/rule.rb:28:in `block in class_from_file'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/sonic-phpapp/recipes/iptables.rb

      1: iptables_rule 'cassandra' do
      2:   action :enable
      3: end

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/sonic-phpapp/recipes/iptables.rb:1:in `from_file'

    iptables_rule("cassandra") do
      action [:enable]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :iptables_rule
      cookbook_name "sonic-phpapp"
      recipe_name "iptables"
    end

Specifying a table with 'lines'

Cookbook version

4.0.1

Chef-client version

12.16.42

Platform Details

Ubuntu 16.04 in AWS

Scenario:

Is there a way to specify a table when using lines rather than a template?

If not something like the following would be great:

iptables_rule 'foo' do
  lines '-I PREROUTING -p tcp -m tcp --syn --dport 80 -j CT --notrack'
  table :raw
end

debian if-pre-up.d script references nonexistent /etc/iptables/general

Cookbook version

4.5.0, master

The line of code in question is:

iptables/recipes/default.rb

Line 62 in 2c02699

variables iptables_save_file: "/etc/#{ipt}/general",

This should be:

variables iptables_save_file: node['iptables']["persisted_rules_#{ipt}"]

Really, this block shouldn't be there at all. It was removed in #90 because iptables-persistent made it obselete. It was re-added in #87, which merged after #90, so perhaps there was some kind of mis-merge?

Doesn't seem to cause any problems, but it sure did throw me for a loop when I was debugging a separate issue.

shebang line in rebuild-iptables script is not system-independent

There's a semi-complicated bit of code to apply a different shebang line depending on where ruby is located in the system. IMO, it should just use

#!/usr/bin/env ruby

test

Cookbook version

[Version of the cookbook where you are encountering the issue]

Chef-client version

[Version of chef-client in your environment]

Platform Details

[Operating system distribution and release version. Cloud provider if running in the cloud]

Scenario:

[What you are trying to achieve and you can't?]

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?]

Actual Result:

[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.]

iptables v1.8.2 (legacy): unknown option "--to-ports"

Cookbook version

[Version of the cookbook where you are encountering the issue]
I don't know what the 'cookbook' is referencing too

Chef-client version

[Version of chef-client in your environment]
iptables v1.8.2(legacy) [1:1.8.2-1 according to my pkg manager]

Platform Details

[Operating system distribution and release version. Cloud provider if running in the cloud]
ArchLinux - 5.1.7-arch1-1-ARCH

Scenario:

[What you are trying to achieve and you can't?]
NAT redirection for mitmproxy

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]

• use current version of iptables
• use latest archlinx kernel (default kernel)
• issue command such as: sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?]
putting my computer between the router and the server to view incoming and outgoing data on my device

Actual Result:

[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.]
iptables v1.8.2 (legacy): unknown option "--to-ports"
Try `iptables -h' or 'iptables --help' for more information.

I also can't find the '--to-port' option on the man page for my version of iptables

Just in case this needs to be clarified, this happens for '--to-port' and '--to-ports'

After some googling I did stumble accross this however leading me to believe the kernel I'm running may be to blame: sshuttle/sshuttle#286

redhat iptables not saving?

This might not be an issue, but my customer told me that on reboot of the system we stood up for them via chef, their ip tables rules are not persistent.

excuse my ignorance, but can someone explain to me what this is doing and why redhat/centos are not in the list of platforms?

case node[:platform]
when "ubuntu", "debian"
  iptables_save_file = "/etc/iptables/general"

  template "/etc/network/if-pre-up.d/iptables_load" do
    source "iptables_load.erb"
    mode 0755
    variables :iptables_save_file => iptables_save_file
  end
end

BTW: I read through the cookbook and see that the rebuild-iptables.erb is supposed to write the ip table rules to "/etc/sysconfig/iptables", I was more so curious as to why the above is needed.

template "/usr/sbin/rebuild-iptables" do
  source "rebuild-iptables.erb"
  mode 0755
  variables(
    :hashbang => ::File.exist?('/usr/bin/ruby') ? '/usr/bin/ruby' : '/opt/chef/embedded/bin/ruby'
  )
end

The README should mention that this cookbook no longer blocks anything by default

The major breaking change in 2dc462c really needs to be called out, since it's silent.

Doesn't work on CentOS

Hi,
In 1.0.0 version in default.rb block "rebuild-iptables" goes before directory "/etc/iptables.d" creation, so running in default CentOS fails because of no-existant directory.

default recipe doesn't ensure iptables service is enabled

If you use the disable recipe and then run the default recipe, the iptables service isn't re-enabled. If a system is rebooted, the iptables rules aren't applied.

Currently, it looks like the "restarting" of the iptables is handled in the rebuild-iptables. But it isn't re-enabled there.

Compilation error on version 2.2.0

Just recently updated to the latest version (last night?) and it doesn't work. See stacktrace below.

================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/iptables/resources/rule.rb
================================================================================

NoMethodError
-------------
undefined method `property' for Chef::Resource::IptablesRule:Class

Cookbook Trace:
---------------
  /var/chef/cache/cookbooks/iptables/resources/rule.rb:20:in `class_from_file'

Relevant File Content:
----------------------
/var/chef/cache/cookbooks/iptables/resources/rule.rb:

 13:  #
 14:  # Unless required by applicable law or agreed to in writing, software
 15:  # distributed under the License is distributed on an "AS IS" BASIS,
 16:  # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 17:  # See the License for the specific language governing permissions and
 18:  # limitations under the License.
 19:  
 20>> property :name, kind_of: String, name_attribute: true
 21:  property :source, kind_of: String, default: nil
 22:  property :cookbook, kind_of: String, default: nil
 23:  property :variables, kind_of: Hash, default: {}
 24:  
 25:  action :enable do
 26:    execute 'rebuild-iptables' do
 27:      command '/usr/sbin/rebuild-iptables'
 28:      action :nothing
 29:    end

Allow users to specify iptables rules by attributes, instead of template

Here is current way to specify iptables rules

Quoted from https://supermarket.chef.io/cookbooks/iptables
To enable port 80, e.g. in an httpd cookbook, create the following template:

Port 80 for http

-A FWR -p tcp -m tcp --dport 80 -j ACCEPT
This would go in the cookbook, httpd/templates/default/http.erb. Then to use it in recipe[httpd]:

iptables_rule "http"

As a customer, I've plenty of iptables rules to generate. It's really painful to generate a dedicated template file for each rule.

To dynamically do that, specify iptables rules by attributes/varilable is better.

Template with multiple instructions

Hi all,

I have to configure about 14 instructions of iptables.
If I generate a single template and use iptables_rule, generate correctly file in /etc/sysconfig/iptables but all rules doesn't applied.
While, if I write a single template file for every instruction, all work fine.

For ports management I can't create a single template file for every port. It wouldn't be an efficent configuration.
How can I write a single (or few) template file(s)?

Typo in README title

As of 2 days ago, it says fail2ban, but it's the iptables cookbook :)

'lines' property interpreted as method and fails

I have a test cookbook that include the iptables cookbook. In my default recipe I have included the following:

include_recipe 'iptables'

iptables_rule 'http_8080' do
  lines '-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080'
  action :enable
end

When I converge, lines is interpreted as a method and can't resolve. Therefore the converge fails.

================================================================================
       Recipe Compile Error in /tmp/kitchen/cache/cookbooks/my_test/recipes/default.rb
       ================================================================================

       NoMethodError
       -------------
       undefined method `lines' for Custom resource iptables_rule from cookbook iptables

       Cookbook Trace:
       ---------------
         /tmp/kitchen/cache/cookbooks/my_test/recipes/default.rb:10:in `block in from_file'
         /tmp/kitchen/cache/cookbooks/my_test/recipes/default.rb:9:in `from_file'

       Relevant File Content:
       ----------------------
       /tmp/kitchen/cache/cookbooks/my_test/recipes/default.rb:

         3:  # Recipe:: default
         4:  #
         5:  # Copyright (c) 2016 The Authors, All Rights Reserved.
         6:
         7:  include_recipe 'iptables'
         8:
         9:  iptables_rule 'http_8080' do
        10>>   lines '-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080'
        11:    action :enable
        12:  end
        13:

Example provided for 80 -> 8080 redirect fails on ubuntu14

The example in your readme for redirect traffic from port 80 to 8080 does not work. It looks like this issue was filed once years ago when jira was still the place.

https://tickets.opscode.com/browse/COOK-1004

I am currently running into this exact same issue following the steps outlined in your readme. Is the solution really what is described in the ticket? Why would this be the example listed in the readme then? Am I missing something?

[2015-01-29T15:53:39-05:00] ERROR: execute[rebuild-iptables] (iptables::default line 23) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '25'
---- Begin output of /usr/sbin/rebuild-iptables ----
STDOUT:
STDERR: Bad argument `*nat'
Error occurred at line: 14
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
rebuild-iptables: iptables-restore failed! - 512 at /usr/sbin/rebuild-iptables line 134.
---- End output of /usr/sbin/rebuild-iptables ----
Ran /usr/sbin/rebuild-iptables returned 25
       [2015-01-29T15:53:39-05:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Rule Order - am I missing something?

Cookbook version

4.2.0

Chef-client version

13.0.118

Platform Details

CentOS 6.8, 7.3

Scenario:

I do not fully understand how the cookbook assembles the final order of the iptables configuration of rules applied with iptables_rule. Background: I want to define the order, f.e when talking about performance. So if i miss something in the explanation or my expectation please let me know.

I´m defining rules in templates, f.e i have templates for

• drop_default
• http
• https
• keep_established
• drop_invalid
• ssh
• icmp
• loopback

So far so good, then have a attribute where users can select which rules they want to apply, lets call it

default['firewall']['rules'] = %(drop_default loopback drop_invalid keep_established icmp ssh)

in the cookbook, i iterate over the rules and enable each of them

Expected Result:

The iptables -S command shows the rules in the defined order of the attributes

-P INPUT DROP # drop_default template
-P FORWARD DROP # drop_default template
-P OUTPUT ACCEPT # drop_default template
-A INPUT -i lo -j ACCEPT # loopback template
-A INPUT -m conntrack --ctstate INVALID -j DROP # drop_invalid template
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # keep_established template
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT # icmp template
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT # ssh template

Actual Result:

iptables -S does not show the rules in the defined order

-P INPUT DROP  # drop_default template
-P FORWARD DROP  # drop_default template
-P OUTPUT ACCEPT  # drop_default template
-A INPUT -m conntrack --ctstate INVALID -j DROP drop_invalid template
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT # icmp template
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT  # keep_established 
-A INPUT -i lo -j ACCEPT # loopback template
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT # ssh_template

Use zap cookbook for garbage collection in /etc/iptables.d

https://github.com/nvwls/zap

unable to create logging rules

Hi,

I am trying to use this logging rule
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

I was able to create a new chain LOGGING using this cookbook but the build fails when I use the above rule.

[2016-01-26T13:49:58+00:00] INFO: template[/etc/iptables.d/logging] sending run action to executerebuild-iptables
* execute[rebuild-iptables] action run[2016-01-26T13:49:58+00:00] INFO: Processing execute[rebuild-iptables] action run (/var/chef/cache/cookbooks/iptables/resources/rule.rb line 26)
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: iptables-restore: line 6 failed
[FAILED]
[2016-01-26T13:49:58+00:00] INFO: execute[rebuild-iptables] ran successfully

  - execute /usr/sbin/rebuild-iptables

rebuild-iptables doesn't check subcommand exit codes

Cookbook version

master

Chef-client version

12.8.1

Platform Details

Ubuntu 14.04

Scenario:

rebuild-iptables doesn't actually verify that it installed the rules successfully by checking the exit codes of the subcommands it runs.

The return val needs to be inspected here and an appropriate exit code needs to be returned if the val is false or nil (I believe).

Steps to Reproduce:

Enter an invalid rule to the iptables_rule resource and watch the chef run complete successfully.

Expected Result:

An error indicating rebuild-iptables failed.

Example:

[email protected]:/etc/chef# /usr/sbin/rebuild-iptables
iptables-restore v1.4.21: The -t option (seen in line 6) cannot be used in iptables-restore.

Error occurred at line: 6
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
cp: cannot create regular file ‘/etc/sysconfig/iptables’: No such file or directory
[email protected]:/etc/chef# echo $?
0

Actual Result:

Chef ran successfully.

Doesn't work on ubuntu bionic with netplan

Cookbook version

4.5.0, master

Chef-client version

14.8.12

Platform Details

Brand new minimal Ubuntu Bionic installation.

Scenario:

Basic usage (any).

Steps to Reproduce:

Try any standard example.

Expected Result:

It should work.

Actual Result:

Chef errors out when iptables::default tries to write to /etc/network/if-pre-up.d/iptables_load because that directory does not exist by default. Ubuntu switched to netplan instead of ifupdown.

Discussion

See #103 for more details on what's going on here. It looks like this cookbook doesn't even need to write a hook into if-pre-up.d anymore.

Workaround

Create the directory /etc/network/if-pre-up.d and let the cookbook install the obselete iptables_load hook there. It won't ever be triggered on a host with netplan, and it wouldn't work anyway because /etc/iptables/general doesn't exist.

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

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.

Transport error, can't connect to 'ssh' backend: SSH session could not be established

Cookbook version

iptables version 3.0.1

Chef-client version

chef-client version: 12.14.89

Platform Details

CentOs 7.2

Scenario:

Run the kitchen test command inside the cookbook.

Steps to Reproduce:

1. Use vagrant as the driver in .kitchen.yml.
2. Use CentOs 7.2 as a platform in .kitchen.yml.
3. Add depends 'iptables', '~> 3.0.1' in metadata.rb.
4. Add these following codes in the default recipe.

include_recipe 'iptables'
iptables_rule "new_rule" do
    lines '-A INPUT -j FWR'
end

1. Execute kitchen test.

This is my kitchen test.

control "my-iptables-rules-1.0" do
    impact 1.0
    title "my iptables base rules"
    desc "base iptables rules for server"

    describe iptables(table: 'filter', chain: 'INPUT') do
        it { should have_rule('-A INPUT -j FWR')}
    end
end

Expected Result:

It must successfully add the new rule.

Actual Result:

These are the error logs after the execution of kitchen test command.

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #verify action: [Transport error, can't connect to 'ssh' backend: SSH session could not be established] on default-centos-72
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Modernize Testing

• Switch from Serverspec to Inspec
• Debug existing platform failures (centos5, all the suse's are actually failing)

Can't start iptables cookbook on host without ipv6 support

Cookbook version

4.5.0

Chef-client version

12.17.44

Platform Details

RHEL 7.6.1810

Scenario:

Hi.
I've faced with next problem: If I use cookbook on host without ipv6 it fail to start on run ip6tables step.

Reason: The installed iptables-services package installed file /etc/sysconfig/ip6tables with default sample configuration. After install it try to start ip6tables service but can't do that because no support for ipv6 on host. 'default' recipe cant't replace it to empty file (actually it just create empty file only if it missing).

Steps to Reproduce:

Just use it on host without ipv6.

Expected Result:

It can make check for ipv6 support or just replace /etc/sysconfig/ip6tables file.

Actual Result:

It fail to start on start ip6tables step.