Projet

Général

Profil

Paste
Télécharger au format
Statistiques
| Branche: | Révision:

root @ master

Nom Taille Révision Âge Auteur Commentaire
  .github 1d331291 4 mois Tim Meusel modulesync 9.4.0
  data 0b7bcb5d plus de 2 ans mh Align filemode on RedHat to distro default The...
  files baad986e plus d'un an Vadym Chepkov add ftp helper This adds ability to enable a c...
  lib c82b960a plus de 3 ans Steve Traylen rubocop:auto_correct results
  manifests 2ad7193b environ un mois Tomas Barton Support logging to NFLOG group
  spec 2ad7193b environ un mois Tomas Barton Support logging to NFLOG group
  templates 2ad7193b environ un mois Tomas Barton Support logging to NFLOG group
  types 9d02e9f8 10 mois Stéphanie Jaumotte Add variant array
.editorconfig 289 octets 5fea281f plus de 3 ans Tim Stallmann modulesync 4.2.0
.fixtures.yml 377 octets 1a986e22 presque 4 ans Tim Meusel pull fixtures from git and not forge
.gitattributes 62 octets 321ae8ab plus de 4 ans tr Add Puppet module basic files
.gitignore 380 octets 79ef6104 environ un an Tim Meusel modulesync 7.4.0
.msync.yml 147 octets cb657563 2 mois pccibot modulesync 9.5.0-4-g2cf9dc0
.overcommit.yml 1,36 ko f24e622f 11 mois Tim Meusel modulesync 8.0.1
.pmtignore 515 octets 65ed81ba 10 mois Tim Meusel partial modulesync 9.1.0 This excludes the Gem...
.puppet-lint.rc 127 octets 65ed81ba 10 mois Tim Meusel partial modulesync 9.1.0 This excludes the Gem...
.rubocop.yml 155 octets 5fea281f plus de 3 ans Tim Stallmann modulesync 4.2.0
.sync.yml 220 octets 2a649e6e 4 mois Tim Meusel Switch unit tests to CERN runner
CHANGELOG.md 31,2 ko 83506792 3 mois Release Automation Release 4.2.0
Gemfile 954 octets cb657563 2 mois pccibot modulesync 9.5.0-4-g2cf9dc0
LICENSE 11,1 ko 44ac0a4e plus de 4 ans mh add license file
README.md 6,13 ko 6ee35b94 8 mois Simon Hönscheid README.md aktualisieren Co-authored-by: Kenyon...
REFERENCE.md 66,5 ko 08d8ebb7 environ un mois Tomas Barton Update REFERENCE
Rakefile 1,12 ko dcc15b02 environ 2 ans Massimiliano Adamo modulesync 5.5.0
hiera.yaml 685 octets ece9be27 plus de 4 ans tr Do PDK convert
metadata.json 1,81 ko 357900d7 2 mois Jason Straw Add openvox to metadata.json

Dernières révisions

# Date Auteur Commentaire
a033cfa8 2025-04-29 04:03 Steve Traylen

Merge pull request #258 from deric/group

Support logging to NFLOG group

08d8ebb7 2025-04-15 06:11 Tomas Barton

Update REFERENCE

2ad7193b 2025-04-15 06:11 Tomas Barton

Support logging to NFLOG group

364b3091 2025-03-19 16:14 Tim Meusel

Merge pull request #279 from voxpupuli/add-openvox

metadata.json: Add OpenVox

357900d7 2025-03-19 15:05 Jason Straw

Add openvox to metadata.json

74a22f28 2025-03-19 10:46 Tim Meusel

Merge pull request #278 from voxpupuli/modulesync

modulesync 9.5.0-4-g2cf9dc0

cb657563 2025-03-19 10:37 pccibot

modulesync 9.5.0-4-g2cf9dc0

9735544e 2025-03-10 06:46 Steve Traylen

Merge pull request #276 from traylenator/nomad

Add ruleset for a Nomad cluster

0ea401a5 2025-03-10 06:36 Steve Traylen

Extra comment

0f34454b 2025-03-06 07:26 Steve Traylen

Debian 11 known to be broken for sets

Voir toutes les révisions | Voir les révisions

README


nftables puppet module

Puppet Forge Puppet Forge - downloads puppetmodule.info docs Apache-2.0 License

This module manages an opinionated nftables configuration.

By default it sets up a firewall that drops every connection, except outbound ICMP, DNS, NTP, HTTP, and HTTPS, and inbound ICMP and SSH traffic:

puppet include nftables

This can be overridden using parameters, for example, this allows all outbound traffic:

puppet class { 'nftables': out_all => true, }

There are also pre-built rules for specific services, for example this will allow a web server to serve traffic over HTTPS:

puppet include nftables include nftables::rules::https

Note that the module conflicts with the firewalld system and will stop it in Puppet runs.

Configuration

The main configuration file loaded by the nftables service will be files/config/puppet.nft, all other files created by that module go into files/config/puppet and will also be purged if not managed anymore.

The main configuration file includes dedicated files for the filter and NAT tables, as well as processes any custom-*.nft files before hand.

The filter and NAT tables both have all the master chains (INPUT, OUTPUT, FORWARD in case of filter and PREROUTING and POSTROUTING in case of NAT) configured, to which you can hook in your own chains that can contain specific rules.

All filter masterchains drop by default. By default we have a set of default_MASTERCHAIN chains configured to which you can easily add your custom rules.

For specific needs you can add your own chain.

There is a global chain, that defines the default behavior for all masterchains. This chain is empty by default.

INPUT and OUTPUT to the loopback device is allowed by default, though you could restrict it later.

On the other hand, if you don't want any of the default tables, chains and rules created by the module, you can set nftables::inet_filter and/or nftables::nat to false and build your whole nftables configuration from scratch by using the building blocks provided by this module. Look at nftables::inet_filter for inspiration.

Rules Validation

Initially puppet deploys all configuration to /etc/nftables/puppet-preflight/ and /etc/nftables/puppet-preflight.nft. This is validated with nft -c -I /etc/nftables/puppet-preflight/ -f /etc/nftables/puppet-preflight.nft. If and only if successful the configuration will be copied to the real locations before the service is reloaded.

Un-managed rules

By default, rules added manually by the administrator to the in-memory ruleset will be left untouched. However, nftables::purge_unmanaged_rules can be set to true to revert this behaviour and force a reload of the ruleset during the Puppet run if non-managed changes are detected.

Basic types

nftables::config

Manages a raw file in /etc/nftables/puppet/${name}.nft

Use this for any custom table files.

nftables::chain

Prepares a chain file as a concat file to which you will be able to add dedicated rules through nftables::rule.

The name must be unique for all chains. The inject parameter can be used to directly add a jump to a masterchain. inject must follow the pattern ORDER-MASTERCHAIN, where order references a 2-digit number which defines the rule order (by default use e.g. 20) and masterchain references the chain to hook in the new chain. It's possible to specify the in-interface name and out-interface name for the inject rule.

nftables::rule

A simple way to add rules to any chain. The name must be: CHAIN_NAME-rulename, where CHAINNAME refers to your chain and an arbitrary name for your rule. The rule will be a concat::fragment to the chain `CHAINNAME`.

You can define the order by using the order param.

Before defining your own rule, take a look to the list of ready-to-use rules available in the REFERENCE, somebody might have encapsulated a rule definition for you already.

nftables::set

Adds a named set to a given table. It allows composing the set using individual parameters but also takes raw input via the content and source parameters.

nftables::simplerule

Allows expressing firewall rules without having to use nftables's language by adding an abstraction layer a-la-Firewall. It's rather limited how far you can go so if you need rather complex rules or you can speak nftables it's recommended to use nftables::rule directly.

Facts

One structured fact nftables is available

{ tables => [ "bridge-filter", "bridge-nat", "inet-firewalld", "ip-firewalld", "ip6-firewalld" ], version => "0.9.3" }

  • nftables.version is the version of the nft command from nft --version.
  • nftables.tables is the list of tables installed on the machine from nft list tables.

Editor goodies

If you're using Emacs there are some snippets for Yasnippet available here that could make your life easier when using the module. This is third party configuration that's only included here for reference so changes in the interfaces exposed by this module are not guaranteed to be automatically applied there.

Development

This module relies on CI testing. To ensure the tests and documentation is complete.

The following steps are a blueprint for the necessary work to add a new rule to the module:

  1. add a new class for the new rule (there are enough examples)
  2. document class and parameters
  3. Add a spec test for the new rule to spec/classes/rules
  4. add the rule to spec/acceptance/all_rules_spec.rb
  5. update the reference with bundle exec rake strings:generate:reference
  6. commit, push and open a PR

Formats disponibles : Atom