iptables

partner
Safely manages IPTables firewall rules

SIMP

simp

22,756 downloads

340 latest version

3.1 quality score

Version information

  • 6.6.0 (latest)
  • 6.5.5
  • 6.5.4
  • 6.5.3
  • 6.5.2
  • 6.5.1
  • 6.5.0
  • 6.4.0
  • 6.3.0
  • 6.2.2
  • 6.2.1
  • 6.2.0
  • 6.1.7
  • 6.1.6
  • 6.1.5
  • 6.1.4
  • 6.1.3
  • 6.1.2
  • 6.1.1
  • 6.1.0
  • 6.0.3
  • 6.0.2
  • 6.0.1
  • 4.1.5
  • 4.1.4
  • 4.1.0
released Jul 7th 2021
This version is compatible with:
  • Puppet Enterprise 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x
  • Puppet >= 6.22.1 < 8.0.0
  • CentOS
    ,
    RedHat
    ,
    OracleLinux

Start using this module

Documentation

simp/iptables — version 6.6.0 Jul 7th 2021

License CII Best Practices Puppet Forge Puppet Forge Downloads Build Status

Table of Contents

Overview

This module provides native types for managing the system IPTables and IP6Tables as well as convenience defines and general system configuration capabilities.

The ability to use this module to automatically shim through to firewalld is optionally supported for legacy systems and modules that are working on migrating to firewalld support.

This is a SIMP module

This module is a component of the System Integrity Management Platform, a compliance-management framework built on Puppet.

Most SIMP modules actively take advantage of this module when used within the SIMP ecosystem.

Module Description

The iptables module manages all IPTables and IP6Tables rules in an atomic fashion. All rules are applied only once per puppet agent run during the application of the last executed iptables resource.

Applying the rules in this manner ensures that avoid situations where you have a partially applied IPTables rule set during a failure in your run of puppet (someone hits ^C, your system runs out of memory, etc...).

The module also takes additional safety measures to attempt to keep your firewall rules in a consistent state over time to include:

  • Rolling back to the last configuration if the application of the new configuration fails
  • Rolling back to an 'ssh-only' mode if application of all configurations fail

The goal is to remain in a state where you can be sure that your system is tightly restricted but also able to be recovered.

Finally, the module works to ensure that services such as OpenStack, Docker, VirtualBox, etc... can apply their rules without being affected by this module. The module provides mechanisms to preserve these rules as managed by external systems based on regular expression matches.

Setup

What iptables affects

The module manages the iptables package, service, and rules.

On systems containing the firewalld service, it is ensured to be stopped unless iptables::use_firewalld is set to true.

Beginning with iptables

I want a basic secure iptables setup

A basic setup with iptables will allow the following:

  • ICMP
  • Loopback
  • SSH
  • Established and Related traffic (Return Traffic)
# Set up iptables with the default settings

include 'iptables'

Output (to /etc/sysconfig/iptables)

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:LOCAL-INPUT - [0:0]
-A INPUT -j LOCAL-INPUT
-A FORWARD -j LOCAL-INPUT
-A LOCAL-INPUT -p icmp --icmp-type 8 -j ACCEPT
-A LOCAL-INPUT -i lo -j ACCEPT
-A LOCAL-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A LOCAL-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A LOCAL-INPUT -j LOG --log-prefix "IPT:"
-A LOCAL-INPUT -j DROP
COMMIT

Usage

I want to open a specific port or allow access

The iptables module has a set of defined types for adding in new firewall rules.

#open TCP port 443 (HTTPS) and a custom 8443 from any IP Address

iptables::listen::tcp_stateful { 'webserver':
  trusted_nets => ['any'],
  dports => [ 443 , 8443 ]
}

#open UDP port 53 (DNS) from two specific IP addresses

iptables::listen::udp {'DNS':
  trusted_nets => ['192.168.56.55','192.168.56.147'],
  dports      => [ 53 ]
}

#Allow a specific machine full access to this node

iptables::listen::all { 'Central Management':
  trusted_nets => ['10.10.35.100'],
}

#Allow a range of ports to be accessible from a specific IP
iptables::listen::tcp_stateful { 'myapp':
  trusted_nets => ['10.10.45.100'],
  dports => ['1024:60000']
}

This module doesn't cover my specific iptables rule

In the case you need a rule not covered properly by the module, you can use the iptables::add_rules type to place the exact rule into /etc/sysconfig/iptables.

# Inserts a custom rule into IPtables

iptables::rule { 'example':
  content => '-A LOCAL-INPUT -m state --state NEW -m tcp -p tcp\
  -s 1.2.3.4 --dport 1024:65535 -j ACCEPT'
}

Firewalld Mode

This module has preliminary support for acting as a pass-through to various firewalld capabilities using the simp/simp_firewalld module.

Using any of the iptables::listen::* defined types will work seamlessly in firewalld mode but direct calls to iptables::rule will emit a warning letting the user know that they must switch over to simp_firewalld::rule.

Additionally, calls to any of the native types included in this module will result in undefined behavior and is not advised.

Enabling Firewalld Mode

To enable firewalld mode on supported operating systems, simply set iptables::use_firewalld to true via Hiera.

NOTE: EL 8 systems enable firewalld mode by default.

Reference

See REFERENCE.md

Limitations

  • IPv6 support has not been fully tested, use with caution
  • firewalld must be disabled if using iptables. The module will disable firewalld if it is present and the module is not in firewalld compatibility mode.
  • This module is intended to be used on a Red Hat Enterprise Linux-compatible distribution such as EL6 and EL7. However, any distribution that uses the /etc/sysconfig/iptables configuration should function properly (let us know!).

Development

Please read our Contribution Guide.

Acceptance tests

To run the system tests, you need Vagrant installed. Then, run:

bundle exec rake beaker:suites

Some environment variables may be useful:

BEAKER_debug=true
BEAKER_provision=no
BEAKER_destroy=no
BEAKER_use_fixtures_dir_for_modules=yes
  • BEAKER_debug: show the commands being run on the STU and their output.
  • BEAKER_destroy=no: prevent the machine destruction after the tests finish so you can inspect the state.
  • BEAKER_provision=no: prevent the machine from being recreated. This can save a lot of time while you're writing the tests.
  • BEAKER_use_fixtures_dir_for_modules=yes: cause all module dependencies to be loaded from the spec/fixtures/modules directory, based on the contents of .fixtures.yml. The contents of this directory are usually populated by bundle exec rake spec_prep. This can be used to run acceptance tests to run on isolated networks.