Coder Social home page Coder Social logo

chr4-cookbooks / iptables-ng Goto Github PK

View Code? Open in Web Editor NEW
38.0 5.0 33.0 272 KB

Cookbook to maintain iptables rules and policies on different platforms, respecting the way the os handles these settings.

License: GNU General Public License v3.0

Ruby 100.00%

iptables-ng's Introduction

iptables-ng Cookbook

Build Status

Cookbook Version

This cookbook maintains and installs iptables and ip6tables rules, trying to keep as close to the way the used distribution maintains their rules.

Contrary to other iptables cookbooks, this cookbook installs iptables and maintains rules using the distributions default configuration files and services (for Debian and Ubuntu, iptables-persistent is used). If the distribution has no service for iptables, it falls back to iptables-restore.

It provides LWRPs as well as recipes which can handle iptables rules set in the nodes attributes.

It uses the directory /etc/iptables.d to store and maintain its rules. I'm trying to be as compatible as much as possible to all distributions out there.

This cookbook is supposed to be able to:

  • Configure iptables rules in a consistent and nice way for all distributions
  • Be configured by using LWRPs only
  • Be configured by using node attributes only
  • Respect the way the currently used distribution stores their rules
  • Provide a good-to-read and good-to-maintain way of deploying complex iptables rulesets
  • Provide a way of specifying the order of the iptables rules, in case needed
  • Only run iptables-restore once during a chef run, and only if something was actually changed
  • Support both, ipv6 as well as ipv4
  • Be able to assemble iptables rules from different recipes (and even cookbooks), so you can set your iptables rule where you actually configure the service

I also wrote a blog post providing further insights.

Requirements

The following distribution are best supported, but as this recipe falls back to a generic iptables restore script in case the system is unknown, it should work with every linux distribution supporting iptables.

  • Ubuntu
  • Debian
  • RHEL
  • Gentoo
  • Archlinux

No external dependencies. Just add this line to your metadata.rb and you're good to go!

depends 'iptables-ng'

Attributes

General configuration (services, paths)

While iptables-ng tries to automatically determine the correct settings and defaults for your distribution, it might be necessary to adapt them in certain cases. You can configure the behaviour of iptables-ng using the following attributes:

# The ip versions to manage iptables for
node['iptables-ng']['enabled_ip_versions'] = [4, 6]

# Which tables to manage:
# When using a containered setup (OpenVZ, Docker, LXC) it might be
# necessary to remove the "nat" and "raw" tables.
node['iptables-ng']['enabled_tables'] = %w(nat filter mangle raw)

# An array of packages to install.
# This should install iptables and ip6tables,
# as well as a system service that takes care of reloading the rules
# On Debian and Ubuntu, iptables-persistent is used by default.
node['iptables-ng']['packages'] = %w(iptables)

# The name of the service that will be used to restart iptables
# By default, the system service of your distribution is used, so don't worry about it unless you
# have special requirements. If iptables-ng can't figure out the default service to use or these
# attributes are set to nil, iptables-ng will fall back to "iptables-restore"
node['iptables-ng']['service_ipv4'] = 'iptables-persistent'
node['iptables-ng']['service_ipv6'] = 'iptables-persistent'

# The location were the iptables-restore script will be written to
node['iptables-ng']['script_ipv4'] = '/etc/iptables/rules.v4'
node['iptables-ng']['script_ipv6'] = '/etc/iptables/rules.v6'

Rule configuration

The use of the LWRPs is recommended, but iptables-ng can be configured using attributes only.

You can set the default policies of a chain like this

node['iptables-ng']['rules']['filter']['INPUT']['default'] = 'DROP [0:0]'

And also add rules for a chain (this example allows SSH)

node['iptables-ng']['rules']['filter']['INPUT']['ssh']['rule'] = '--protocol tcp --dport 22 --match state --state NEW --jump ACCEPT'

You can prioritize your rules, too. This example will make sure that the 'ssh' rule is created before the 'http' rule

node['iptables-ng']['rules']['filter']['INPUT']['10-ssh']['rule'] = 'this rule is first'
node['iptables-ng']['rules']['filter']['INPUT']['90-http']['rule'] = 'this rule is applied later'

Also, it's possible to only apply a rule for a certain ip version.

node['iptables-ng']['rules']['filter']['INPUT']['10-ssh']['rule'] = '--protocol tcp --source 1.2.3.4 --dport 22 --match state --state NEW --jump ACCEPT'
node['iptables-ng']['rules']['filter']['INPUT']['10-ssh']['ip_version'] = 4

Auto-pruning

In Chef, it is generally accepted that removing node attributes does not result in their corresponding resources being proactively scrubbed from the system. However, this could be seen as irritating or even a security risk when dealing with firewall attribute rules in this cookbook. To automatically prune rules for attributes that have been removed, set the following attribute to true. This will not affect rules defined with the LWRP.

node['iptables-ng']['auto_prune_attribute_rules'] = true

Recipes

default

The default recipe calls the install recipe, and then configures all rules and policies given in the nodes attribute.

Example:

To allow only SSH for incoming connections, add this to your node configuration

{
  "name": "example.com",
  "chef_environment": "_default",
  "normal": {
    "iptables-ng": {
      "rules": {
        "filter": {
          "INPUT": {
            "default": "DROP [0:0]",
            "ssh": {
              "rule": "--protocol tcp --dport 22 --match state --state NEW --jump ACCEPT"
            }
          }
        }
      }
    }
  },
  "run_list": [
    "recipe[iptables-ng]"
  ]
}

In case you need a rule for one specific ip version, you can set the "ip_version" attribute.

"ssh": {
  "rule": "--protocol tcp --source 1.2.3.4 --dport 22 --match state --state NEW --jump ACCEPT",
  "ip_version": 4
}

You can also delete old rules by specifying a custom action.

"ssh": {
  "action": "delete"
}

install

The installs recipe installs iptables packages, makes sure that /etc/iptables.d is created and sets all default policies to "ACCEPT", unless they are already configured.

On Debian and Ubuntu systems, it also removes the "ufw" package, as it might interfere with this cookbook.

Note: This recipe needs to be run before the LWRPs are used!

include_recipe 'iptables-ng::install'

Providers

It's recommended to configure iptables-ng using LWRPs in your (wrapper) cookbook.

All providers take care that iptables is installed (they include the install recipe before running), so you can just use them without worrying whether everything is installed correctly.

iptables_ng_chain

This provider creates chains and adds their default policies.

Example: Set the default policy of the filter INPUT chain to ACCEPT:

iptables_ng_chain 'INPUT' do
  policy 'ACCEPT [0:0]'
end

Example: Create a custom chain:

iptables_ng_chain 'MYCHAIN'

The following additional attributes are supported:

iptables_ng_chain 'name' do
  chain  'INPUT'       # The chain to set the policy for (name_attribute)
  table  'filter'      # The table to use (defaults to 'filter')
  policy 'DROP [0:0]'  # The policy to use (defaults to 'ACCEPT [0:0]' for
                       # build-in chains, to '- [0:0]' for custom ones

  action :create       # Supported actions: :create, :create_if_missing, :delete
                       # Default action: :create
end

iptables_ng_rule

This provider adds iptables rules

Example: Allow SSH on the INPUT filter chain

iptables_ng_rule 'ssh' do
  rule '--protocol tcp --dport 22 --match state --state NEW --jump ACCEPT'
end

The following additional attributes are supported:

iptables_ng_rule 'custom' do
  name       'my-rule'    # Name of the rule. Use "xx-" to prioritize rules.
  chain      'INPUT'      # Chain to use. Defaults to 'INPUT' (custom chains need to be created using iptables_ng_chain first!)
  table      'filter'     # Table to use. Defaults to 'filter'
  ip_version 4            # Integer or Array of IP versions to create the rules for.
                          # Defaults to node['iptables-ng']['enabled_ip_versions']
  rule       '-j ACCEPT'  # String or Array containing the rule(s). (Required)

  action :create          # Supported actions: :create, :create_if_missing, :delete
                          # Default action: :create
end

Example: Allow HTTP and HTTPS for a specific IP range only

iptables_ng_rule 'ssh' do
  rule ['--source 192.168.1.0/24 --protocol tcp --dport 80 --match state --state NEW --jump ACCEPT',
        '--source 192.168.1.0/24 --protocol tcp --dport 443 --match state --state NEW --jump ACCEPT']

  # As the source specified above is ipv4, this rule cannot be applied to ip6tables.
  # Therefore, setting ip_version to 4
  ip_version 4
end

Example: Use the same rule for an array of IPs

ips = %w(10.10.10.1 123.123.123.123 192.168.1.0/24)

iptables_ng_rule 'multiple_source_addresses' do
  rule ips.map { |ip| "--source #{ip} --jump ACCEPT" }

  # As the source specified above is ipv4, this rule cannot be applied to ip6tables.
  # Therefore, setting ip_version to 4
  ip_version 4
end

Known issues

There are some issues with systemd support on Fedora systems. Also it might be required to install iptables-service on newer Fedora machines. Due to this issues, the tests for Fedora were removed until they are resolved. Furthermore, due to the lack of Opscode kitchen boxes, there are no tests for Archlinux.

Contributing

You fixed a bug, or added a new feature? Yippie!

  1. Fork the repository on Github
  2. Create a named feature branch (like add_component_x)
  3. Write you change
  4. Write tests for your change (if applicable)
  5. Run the tests, ensuring they all pass
  6. Submit a Pull Request using Github

Contributions of any sort are very welcome!

License and Authors

Authors: Chris Aumann

Contributors: Dan Fruehauf, Nathan Williams, Christian Graf, James Le Cuirot, Sten Spans, Cédric Félizard, Hans Rakers

Other licenses than GPLv3

In case you can't use the provided license for some reason, feel free to contact me.

Copyright (C) 2013-2018 Chris Aumann

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

iptables-ng's People

Contributors

andytson avatar benlangfeld avatar bobziuchkovski avatar chewi avatar chr4 avatar danfruehauf avatar danrex avatar hrak avatar ichilton avatar infertux avatar jboeshart avatar krallin avatar loonydevil avatar martinisoft avatar nathwill avatar orthographic-pedant avatar sspans avatar stevedomin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

iptables-ng's Issues

delete rules that are not part of compiled attributes?

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?

Deprecated resource cloning in Chef 13

Hi,
when moving to chef12 I got lots of warnings using iptables-ng resources:

Cloning resource attributes for iptables_ng_chain[attribute-policy-OUTPUT] from prior resource
Previous iptables_ng_chain[attribute-policy-OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
Current  iptables_ng_chain[attribute-policy-OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for iptables_ng_chain[attribute-policy-INPUT] from prior resource
Previous iptables_ng_chain[attribute-policy-INPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
Current  iptables_ng_chain[attribute-policy-INPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for iptables_ng_chain[attribute-policy-FORWARD] from prior resource
Previous iptables_ng_chain[attribute-policy-FORWARD]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
Current  iptables_ng_chain[attribute-policy-FORWARD]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for iptables_ng_chain[attribute-policy-PREROUTING] from prior resource
Previous iptables_ng_chain[attribute-policy-PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
Current  iptables_ng_chain[attribute-policy-PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for iptables_ng_chain[attribute-policy-POSTROUTING] from prior resource
Previous iptables_ng_chain[attribute-policy-POSTROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
Current  iptables_ng_chain[attribute-policy-POSTROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/recipes/default.rb:33:in `block (2 levels) in from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/filter/INPUT] from prior resource
Previous directory[/etc/iptables.d/filter/INPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/filter/INPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/filter/INPUT/default] from prior resource
Previous file[/etc/iptables.d/filter/INPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/filter/INPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/filter/OUTPUT] from prior resource
Previous directory[/etc/iptables.d/filter/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/filter/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/filter/OUTPUT/default] from prior resource
Previous file[/etc/iptables.d/filter/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/filter/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/filter/FORWARD] from prior resource
Previous directory[/etc/iptables.d/filter/FORWARD]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/filter/FORWARD]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/filter/FORWARD/default] from prior resource
Previous file[/etc/iptables.d/filter/FORWARD/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/filter/FORWARD/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/nat/OUTPUT] from prior resource
Previous directory[/etc/iptables.d/nat/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/nat/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/nat/OUTPUT/default] from prior resource
Previous file[/etc/iptables.d/nat/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/nat/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/nat/PREROUTING] from prior resource
Previous directory[/etc/iptables.d/nat/PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/nat/PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/nat/PREROUTING/default] from prior resource
Previous file[/etc/iptables.d/nat/PREROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/nat/PREROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/nat/POSTROUTING] from prior resource
Previous directory[/etc/iptables.d/nat/POSTROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/nat/POSTROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/nat/POSTROUTING/default] from prior resource
Previous file[/etc/iptables.d/nat/POSTROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/nat/POSTROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/mangle/INPUT] from prior resource
Previous directory[/etc/iptables.d/mangle/INPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/mangle/INPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/mangle/INPUT/default] from prior resource
Previous file[/etc/iptables.d/mangle/INPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/mangle/INPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/mangle/OUTPUT] from prior resource
Previous directory[/etc/iptables.d/mangle/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/mangle/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/mangle/OUTPUT/default] from prior resource
Previous file[/etc/iptables.d/mangle/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/mangle/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/mangle/FORWARD] from prior resource
Previous directory[/etc/iptables.d/mangle/FORWARD]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/mangle/FORWARD]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/mangle/FORWARD/default] from prior resource
Previous file[/etc/iptables.d/mangle/FORWARD/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/mangle/FORWARD/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/mangle/PREROUTING] from prior resource
Previous directory[/etc/iptables.d/mangle/PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/mangle/PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/mangle/PREROUTING/default] from prior resource
Previous file[/etc/iptables.d/mangle/PREROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/mangle/PREROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/mangle/POSTROUTING] from prior resource
Previous directory[/etc/iptables.d/mangle/POSTROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/mangle/POSTROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/mangle/POSTROUTING/default] from prior resource
Previous file[/etc/iptables.d/mangle/POSTROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/mangle/POSTROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/raw/OUTPUT] from prior resource
Previous directory[/etc/iptables.d/raw/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/raw/OUTPUT]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/raw/OUTPUT/default] from prior resource
Previous file[/etc/iptables.d/raw/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/raw/OUTPUT/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for directory[/etc/iptables.d/raw/PREROUTING] from prior resource
Previous directory[/etc/iptables.d/raw/PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
Current  directory[/etc/iptables.d/raw/PREROUTING]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:41:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Cloning resource attributes for file[/etc/iptables.d/raw/PREROUTING/default] from prior resource
Previous file[/etc/iptables.d/raw/PREROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
Current  file[/etc/iptables.d/raw/PREROUTING/default]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/chain.rb:50:in `edit_chain'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.
  Default value "FORWARD:filter:wlan_accept" is invalid for property chain of resource iptables_ng_chain. In Chef 13 this will become an error: Option chain's value FORWARD:filter:wlan_accept does not match regular expression /^[\w-]{1,29}$/. at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/rule.rb:42:in `block in edit_rule'
   See https://docs.chef.io/deprecations_custom_resource_cleanups.html for further details.
  Cloning resource attributes for iptables_ng_chain[FORWARD:filter:wlan_accept] from prior resource
Previous iptables_ng_chain[FORWARD:filter:wlan_accept]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/rule.rb:42:in `block in edit_rule'
Current  iptables_ng_chain[FORWARD:filter:wlan_accept]: /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/rule.rb:42:in `block in edit_rule' at 1 location:
    - /home/madhatter/local-mode-cache/cache/cookbooks/iptables-ng/providers/rule.rb:42:in `block in edit_rule'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.

Already took a look into the files, but I wasn't able to fix it. So I hope you are still maintaining the cookbook.

service[iptables-persistent] always fails when rules changed

either i'm incompetent or this is a bug. i've had this issue since forever. i also thought #14 resolved this but no.

after each run, having changed a rule, chef fails with the following.

Chef Client failed. 64 resources updated in 36.326835388 seconds
[2015-06-28T12:16:14+02:00] ERROR: ruby_block[restart_iptables] (iptables-ng::manage line 38) had an error: Mixlib::ShellOut::ShellCommandFailed: service[iptables-persistent] (dynamically defined) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /etc/init.d/iptables-persistent restart ----
STDOUT: * Loading iptables rules...
 *  IPv4...
 *  IPv6...
   ...fail!
STDERR:
---- End output of /etc/init.d/iptables-persistent restart ----
Ran /etc/init.d/iptables-persistent restart returned 1

if i log into the server after this first run and manually do service iptables-persistent restart, it just works fine. it would also work just fine when i do a second chef run.

i am on ubuntu 12.04 and 14.04 using iptables-ng 2.2.7.

rule resources is flagged as updated every converge

We run the updated-resources handler on our nodes and we recently started using this cookbook (nice work btw!). One thing we've noticed is that the all iptables-ng_rule resources show up in the report (which means they were flagged as updated) each and every converge.

I dug into this a little bit and figured out why, but I'm not sure how you'd prefer to fix it. The following line results in the resource ALWAYS getting marked as updated:

new_resource.updated_by_last_action(true) if edit_rule(:create)

At first glance this all looks well and good, but what is happening is that the edit_rule method is not returning the r.updated_by_last_action? value as the code seems to assume, but instead is returning an Array of IP versions. Since the method is returning the Array, rather than a boolean, this is causing an evaluation of true

I think the easiest fix would be to move the evaluation inside the edit_rule method, so things would look more like this:

action :create do
  edit_rule(:create)
end

def edit_rule(exec_action)
  # all the same stuff it already does
    r = file rule_path do
      owner    'root'
      group    node['root_group']
      mode     00600
      content  rule_file
      notifies :create, 'ruby_block[create_rules]', :delayed
      notifies :create, 'ruby_block[restart_iptables]', :delayed
      action   exec_action
    end

    new_resource.updated_by_last_action(true) if r.updated_by_last_action?
end

Issue on debian 8

Hi I'm currently getting the following error message on debian:

  * apt_package[ufw] action remove

    ================================================================================
    Error executing action `remove` on resource 'apt_package[ufw]'
    ================================================================================

    Chef::Exceptions::Package
    -------------------------
    ufw has no candidate in the apt-cache

    Resource Declaration:
    ---------------------
    # In /root/chef-solo/cookbooks-2/iptables-ng/recipes/install.rb

     27: package 'ufw' do
     28:   action :remove
     29:   only_if { node['platform_family'] == 'debian' }
     30: end
     31: 

    Compiled Resource:
    ------------------
    # Declared in /root/chef-solo/cookbooks-2/iptables-ng/recipes/install.rb:27:in `from_file'

    apt_package("ufw") do
      action [:remove]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      package_name "ufw"
      declared_type :package
      cookbook_name :"iptables-ng"
      recipe_name "install"
      only_if { #code block }
    end

Old rules left around

When defining rules using LWRPs, if I remove some resources from my recipe, their rules are left in iptables-persistent and can cause conflicts that cannot be applied.

For idempotency, /etc/iptables/rules.v* should be written from scratch on every chef run.

Is this a known issue?

Ubuntu 16.04?

Hi,

16.04 is not supported according to the README. Is that correct?

Systemd seems happy enough when changing netfilter-persistent back to iptables-persistent (it's still a file in /etc/init.d/ and not a proper systemd service, though).

Thanks!

Does not remove old rules

Version 2.0.0, downloaded from the Chef Cookbook site.

I made a change to a rule name, and the previous rule still existed.

From:

iptables_ng_rule 'http' do
  rule '--protocol tcp --dport 80 --match state --state NEW --jump ACCEPT'
end 

To:

iptables_ng_rule '90-http' do
  rule '--protocol tcp --dport 80 --match state --state NEW --jump ACCEPT'
end 

I now have two copies of allowing port 80.

Additionally, when I remove a rule, it is not deleted from the ruleset.

LWRP not working as stated on the README

Hi,

I've been trying to use this cookbook following the documentation. I have on my recipe, somethign like this:

include_recipe 'iptables-ng::install'

iptables_ng_chain 'INPUT' do
  policy 'DROP [0:0]'
end

iptables_ng_rule 'ssh' do
  rule '--protocol tcp --dport 22 -j ACCEPT'
end

But Default policy on filter table on INPUT chain is always ACCEPT. Tried also this:

iptables_ng_chain 'INPUT' do
  policy 'DROP [0:0]'
  table 'filter'
  chain 'INPUT'
end

But no result, even tried this:

iptables_ng_chain 'default' do
  policy 'DROP [0:0]'
  table 'filter'
  chain 'INPUT'
end

But also, no results.

Should policies be configured on attributes and not using LWRP's ?

Cheers.

Edit (chr4): Added syntax highlighting

Missing v3.0.0 version git tag

Looking through the pushed tags versus supermarket I noticed that supermarket now has 3.0.0 but I don't see a corresponding git tag to match.

2.2.9 version breaks things badly.

I cant even get a simple kitchen test to complete: I get errors such as this:

Chef::Exceptions::ResourceNotFound ---------------------------------- resource file[/etc/iptables.d/filter/INPUT/default] is configured to notify resource ruby_block[create_rules] with action create, but ruby_block[create_rules] cannot be found in the resource collection. file[/etc/iptables.d/filter/INPUT/default] is defined in /tmp/kitchen/cache/cookbooks/iptables-ng/providers/chain.rb:53:inedit_chain'
`

my guess is the 'use_inline_resources' use in the lwrp

patch to support non-Linux OSes

I share a lot of cookbooks amongst Linux and non-Linux OSes, and so I need to let the cookbook be a NOP on (e.g.) OpenBSD systems.

I am far too stupid to use github (or git for that matter), so I can't actually submit a proper pull request.

But, here is the actual patch: http://www.theapt.org/iptables-ng.patch I am using this on both CentOS 5.9/5.10 and OpenBSD systems.

Missing 'manage' recipe?

I'm getting an error when I use the iptables_ng_rule resource without explicitely including the iptables-ng::manage recipe:

iptables_ng_rule '50-whatever' do
  rule "..."
  action :delete
end
iptables_ng_rule[50-whatever] action delete
           
================================================================================
Error executing action `delete` on resource 'iptables_ng_rule[50-whatever]'
================================================================================
           
Chef::Exceptions::ResourceNotFound
----------------------------------
resource file[/etc/iptables.d/filter/INPUT/50-whatever.rule_v4] is configured to notify resource ruby_block[create_rules] with action create,
but ruby_block[create_rules] cannot be found in the resource collection. file[/etc/iptables.d/filter/INPUT/50-whatever.rule_v4] is defined in
/tmp/kitchen/cache/cookbooks/iptables-ng/providers/rule.rb:44:in `block in edit_rule'
       System Info:
       ------------
       chef_version=14.5.33
       platform=debian
       platform_version=9.5
       ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
       program_name=/opt/chef/bin/chef-client
       executable=/opt/chef/bin/chef-client

Adding include_recipe 'iptables-ng::manage in my own cookbook does the trick but shouldn't it be loaded automatically by the iptables-ng cookbook ideally?

Manage recipe fails when IPV6 is disabled (CentOS / RHEL)

Hi!

When using the cookbook on a CentOS or RHEL host where IPV6 is disabled, the cookbook fails because the init script exists with exit code 6.

Haven't found a workaround yet (though I'm looking), but I just figured I would share this in case there's one.

   ================================================================================
   Error executing action `create` on resource 'ruby_block[restart_iptables]'
   ================================================================================


   Mixlib::ShellOut::ShellCommandFailed
   ------------------------------------
   service[ip6tables] (dynamically defined) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '150'
   ---- Begin output of /sbin/service ip6tables restart ----
   STDOUT: ip6tables: ipv6 is disabled.
   STDERR: 
   ---- End output of /sbin/service ip6tables restart ----
   Ran /sbin/service ip6tables restart returned 150


   Cookbook Trace:
   ---------------
   /tmp/kitchen/cookbooks/iptables-ng/libraries/restart_service.rb:37:in `block in restart_service'
   /tmp/kitchen/cookbooks/iptables-ng/libraries/restart_service.rb:34:in `tap'
   /tmp/kitchen/cookbooks/iptables-ng/libraries/restart_service.rb:34:in `restart_service'
   /tmp/kitchen/cookbooks/iptables-ng/recipes/manage.rb:45:in `block (3 levels) in from_file'
   /tmp/kitchen/cookbooks/iptables-ng/recipes/manage.rb:44:in `each'
   /tmp/kitchen/cookbooks/iptables-ng/recipes/manage.rb:44:in `block (2 levels) in from_file'


   Resource Declaration:
   ---------------------
   # In /tmp/kitchen/cookbooks/iptables-ng/recipes/manage.rb

    38: ruby_block 'restart_iptables' do
    39:   block do
    40:     class Chef::Resource::RubyBlock
    41:       include Iptables::Manage
    42:     end
    43: 
    44:     [4, 6].each do |ip_version|
    45:       restart_service(ip_version)
    46:     end
    47:   end
    48: 

Possible to specify separate ipv4 and ipv6 rules?

I'm attempting to use iptables-ng in my project with Centos 6.4, and I have encountered a problem. I have a rule like "-j REJECT --reject-with icmp-host-prohibited", and this fails with the error "unknown reject type "icmp-host-prohibited"". It appears that the ipv6 version of the rule should instead be "--j REJECT --reject-with icmp6-adm-prohibited". Is it possible to specify separate rules for ipv4 and ipv6? Currently I'm doing node["iptables-ng"]["rules"]["filter"]["INPUT"]["rej"] = "-j REJECT --reject-with icmp-host-prohibited"

Loop through IPs listed in an attribute array or hash.

Hey Chris,

I'm looking for the best way to create rules for an array or hash of IPs stored in an attribute. So far, it looks like any attempt to loop through this simply overwrites down to the last entry in the array, which is then written to iptables. Example:

From attributes.rb:

"ips": ["10.0.0.0/16",
         "10.0.1.0/16",
         "172.0.0.0/16",
         "172.0.1.0/16"
         ]

From default.rb:

iptables_ng_chain 'FWR' do
  policy 'ACCEPT [0:0]'
end

node['ips'].each do |ip|
  iptables_ng_rule 'Add ips' do
    chain 'FWR'
    rule "-s #{ip} -j ACCEPT"
  end
end

The above code yields one entry for the chain FWR, with the following output:

** [out :: localhost:2222] [2014-10-26T22:14:29-04:00] INFO: file[/etc/iptables.d/filter/FWR/Add ips_v4] not queuing delayed action create on ruby_block[restart_iptables] (delayed), as it's already been queued
** [out :: localhost:2222] [2014-10-26T22:14:29-04:00] INFO: file[/etc/iptables.d/filter/FWR/Add ips_v4] not queuing delayed action create on ruby_block[restart_iptables] (delayed), as it's already been queued

And adds one rule to /etc/sysconfig/iptables (on CentOS 6), that looks like this:

--append FWR -s 172.0.1.0/16 -j ACCEPT

Is there a way around this? Or a better way to structure a list of IPs so that I can add in bulk?

I appreciate any feedback.

ipset support

I think we need ipset support in this cookbook, because i can create rule that use ipset match, but i can't create ipset set that used in ipstables =(

IPv6 nat support

Found in providers/rule.rb

(36) # ipv6 doesn't support nat
(37) next if new_resource.table == 'nat' && ip_version == 6

Well, IPv6 does support NAT, because NAT is just an address replacement. Sometimes we really need it when connecting private and public networks. Sure, there is also sysctl for IP forwarding - net.ipv6.conf.all.forwarding

So please, remove this stupid check.

locking a rule to one TCP version doesn't work (on el7)

This code snippet does not work as expected. Both of these rules end up in both sysconfig files on EL7 (CentOS).

            },
            "80-icmp": {
              "rule": "-p icmp --icmp-type echo-request -j ACCEPT",
              "ip_vesion": 4
            },
            "80-icmpv6": {
              "rule": "-p icmpv6 --icmpv6-type echo-request -j ACCEPT",
              "ip_vesion": 6
            },

files look like this:

append INPUT -p icmp --icmp-type echo-request -j ACCEPT
append INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT

should we only reload the rules if it's safe to do so?

seen this a few times where for whatever reason an exception is thrown that causes the chef run to abort before all of the iptables_ng_chain or iptables_ng_rule resources have been processed, but after the notifications to ruby_block[create_rules] and ruby_block[restart_iptables] are already queued up; for whatever reason, Chef still triggers the notified actions during the exit.

The frustrating outcome of the above is that an incomplete set of iptables rules is applied, often to the effect of a totally empty INPUT chain having it's policy set to DROP, with all the joy that entails. Best case, this happens during testing, and you're just unable to login to the test instance to inspect; worse case, this happens during the initial converge of a new instance and requires destroying and recreating the entire VM, or popping onto an IPMI console if you're working with physical gear.

I'd be happy to send over a PR if this seems like something worth trying to avoid, but wanted to get some input on what you'd prefer to see before getting started, as there's a few options that come to mind:

  • skip create and/or restart if the run had an exception
  • skip create and/or restart if the INPUT chain on any of the managed tables has a DROP policy and no other rules as this is guaranteed to be a lock-out situation.
  • consider this chef's problem for running delayed actions after an error and pursue a fix with chef.

thoughts?

Creating NAT/FORWARD chains does not create the directory using iptables_ng_chain

I've been working on updating our wrapper cookbook to use the latest version of this cookbook and I've run into an issue that only seems to affect chains that use tables other than filter.

Here's the code I'm using:

iptables_ng_chain 'nat_postrouting' do
  chain 'POSTROUTING'
  table 'nat'
end

iptables_ng_rule 'accept_nat_postrouting' do
  ip_version 4
  chain 'POSTROUTING'
  table 'nat'
  rule '--jump nat_postrouting'
end

When I run it in test kitchen I get the following:

* iptables_ng_chain[nat_postrouting] action create (up to date) 
* file[/etc/iptables.d/nat/POSTROUTING/default-1489515155-1884] action create (up to date) 
* iptables_ng_rule[accept_nat_postrouting] action create (up to date) 
* file[/etc/iptables.d/nat/POSTROUTING/accept_nat_postrouting.rule_v4] action create (up to date) 
* iptables_ng_rule[accept_nat_forward] action create (up to date) 
* file[/etc/iptables.d/nat/nat_postrouting/nat_postrouting.rule_v4] action create
  * Parent directory /etc/iptables.d/nat/nat_postrouting does not exist.
  ================================================================================
  Error executing action `create` on resource 'file[/etc/iptables.d/nat/nat_postrouting/nat_postrouting.rule_v4]'
  ================================================================================
  
  Chef::Exceptions::EnclosingDirectoryDoesNotExist
  ------------------------------------------------
  Parent directory /etc/iptables.d/nat/nat_postrouting does not exist.
  
  Resource Declaration:
  ---------------------
  # In /tmp/kitchen/cache/cookbooks/iptables-ng/providers/rule.rb
  
   44:     r = file new_resource.path_for_ip_version(ip_version) do
   45:       owner    'root'   
   46:       group    node['root_group']
   47:       mode     0o600    
   48:       content  rule_file
   49:       notifies :create, 'ruby_block[create_rules]', :delayed 
   50:       notifies :create, 'ruby_block[restart_iptables]', :delayed 
   51:       action   exec_action
   52:     end
   53: 
  
  Compiled Resource:
  ------------------
  # Declared in /tmp/kitchen/cache/cookbooks/iptables-ng/providers/rule.rb:44:in `block in edit_rule'
  
  file("/etc/iptables.d/nat/nat_postrouting/nat_postrouting.rule_v4") do
    action [:create]
    retries 0
    retry_delay 2
    default_guard_interpreter :default 
    declared_type :file
    cookbook_name "firewall"
    path "/etc/iptables.d/nat/nat_postrouting/nat_postrouting.rule_v4"
    owner "root"
    group "root"
    mode 384 
    content "--append nat_postrouting -o eth0 -j MASQUERADE\n--append nat_postrouting -o eth1 -j MASQUERADE\n"
  end

I've tried looking around to see what might be causing it but I suspect it might be a bug with the new version. I've confirmed this also affects FORWARD chains but I haven't looked at the other tables since we don't use it. When I run ChefSpec, everything passes which makes me think it's a bug with this cookbook.

Can you please let me know what might be causing it?

Thanks!

Generate 'default' file for custom LWRP chains

iptables-ng v2.2.0, using LWRPs:

iptables_ng_chain 'FOO' do
  chain 'INPUT'
  table 'filter'
  policy '- [0:0]'
  action :create
end

iptables_ng_rule 'test-foo' do
  chain 'FOO'
  rule '-p tcp --dport 200 -j ACCEPT'
end

The 'default' file is not created for my chain:

root@node:~# find /etc/iptables.d
/etc/iptables.d
/etc/iptables.d/filter
/etc/iptables.d/filter/OUTPUT
/etc/iptables.d/filter/OUTPUT/default
/etc/iptables.d/filter/INPUT
/etc/iptables.d/filter/INPUT/default
/etc/iptables.d/filter/FOO
/etc/iptables.d/filter/FOO/test-foo.rule_v6
/etc/iptables.d/filter/FOO/test-foo.rule_v4
/etc/iptables.d/filter/FORWARD
/etc/iptables.d/filter/FORWARD/default
/etc/iptables.d/raw
/etc/iptables.d/raw/OUTPUT
/etc/iptables.d/raw/OUTPUT/default
/etc/iptables.d/raw/PREROUTING
/etc/iptables.d/raw/PREROUTING/default
/etc/iptables.d/nat
/etc/iptables.d/nat/OUTPUT
/etc/iptables.d/nat/OUTPUT/default
/etc/iptables.d/nat/PREROUTING
/etc/iptables.d/nat/PREROUTING/default
/etc/iptables.d/nat/POSTROUTING
/etc/iptables.d/nat/POSTROUTING/default
/etc/iptables.d/mangle
/etc/iptables.d/mangle/OUTPUT
/etc/iptables.d/mangle/OUTPUT/default
/etc/iptables.d/mangle/PREROUTING
/etc/iptables.d/mangle/PREROUTING/default
/etc/iptables.d/mangle/INPUT
/etc/iptables.d/mangle/INPUT/default
/etc/iptables.d/mangle/POSTROUTING
/etc/iptables.d/mangle/POSTROUTING/default
/etc/iptables.d/mangle/FORWARD
/etc/iptables.d/mangle/FORWARD/default

This causes Chef to halt when trying to read the default policy:

NoMethodError
-------------
undefined method `chomp' for nil:NilClass


Cookbook Trace:
---------------
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/libraries/create_iptables_rules.rb:68:in `block (2 levels) in create_iptables_rules'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/libraries/create_iptables_rules.rb:67:in `each'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/libraries/create_iptables_rules.rb:67:in `block in create_iptables_rules'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/libraries/create_iptables_rules.rb:52:in `each'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/libraries/create_iptables_rules.rb:52:in `create_iptables_rules'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/recipes/manage.rb:31:in `block (3 levels) in from_file'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/recipes/manage.rb:30:in `each'
/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/recipes/manage.rb:30:in `block (2 levels) in from_file'


Resource Declaration:
---------------------
# In /tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/recipes/manage.rb

 24: ruby_block 'create_rules' do
 25:   block do
 26:     class Chef::Resource::RubyBlock
 27:       include Iptables::Manage
 28:     end
 29:
 30:     Array(node['iptables-ng']['enabled_ip_versions']).each do |ip_version|
 31:       create_iptables_rules(ip_version)
 32:     end
 33:   end
 34:



Compiled Resource:
------------------
# Declared in /tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/recipes/manage.rb:24:in `from_file'

ruby_block("create_rules") do
  action [:nothing]
  retries 0
  retry_delay 2
  guard_interpreter :default
  block_name "create_rules"
  cookbook_name :"iptables-ng"
  recipe_name "manage"
  block #<Proc:0x00000003d3de40@/tmp/vagrant-chef-2/chef-solo-1/cookbooks/iptables-ng/recipes/manage.rb:25>
end

This can be worked around by setting an attribute, e.g.:

node.set['iptables-ng']['rules']['filter']['FOO']['default'] = '- [0:0]'

Is my resource declaration missing something, or am I expected to set an attribute for each custom chain?

Thanks for writing this cookbook!

[deleted]

nevermind, I was using an older version

(Request)

Debian packages on jailboken devices are not recognised by the operating system. i.e. Cellular data usage has no control measures, this includes backend packages like apt and tweaks and GUI utilities. It would be great if this program could provide some support for I don't belive there has been anything of this kind developed yet.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.