ipr-cnrs / nftables Goto Github PK

Hi, shouldn't the first task have a when wrapping it, so that it doesn't run if nft_merged_groups is False?

I have a clean install, and I'm getting this:

failed: [test -> localhost] (item=lxd) => changed=false
  ansible_loop_var: groupname
  groupname: lxd
  module_stderr: |-
    Error: not found
  module_stdout: ''
  msg: |-
    MODULE FAILURE
    See stdout/stderr for the exact error
  rc: 1

I couldn't find way to add more global includes directly. For example if I wanted to add

https://github.com/chr0mag/geoipsets

I have to add entire new directory into includes. Is there already an option for that?

@gardouille I've just pushed a whole branch that was subject to an open PR into master by mistake (I was using another computer where this repository was set as origin rather than my fork). The obvious remedy would be to create a revert back to c4da513d08a24df4ae042b85a10d9d3f7a27ca8a which was the latest PR merged, but if you're OK with these changes we can leave them in as if it was a merged PR?

@kravietz you have been hard at work merging stuff. Thank you ❤️ !

Would it be possible to tag/release a new version of the role to mark this occassion? 👍

Ubuntu 16.04 is not compatible since it uses and old version of nftables which doesn't support the default's config syntax. Running the role will result in:

{"changed": false, "msg": "Unable to start service nftables: Job for nftables.service failed because the control process exited with error code. See \"systemctl status nftables.service\" and \"journalctl -xe\" for details.\n"}

In the journal logs:

/etc/nftables.d/filter-output.nft:19:20-20: Error: syntax error

Ubuntu 18.04 hosts work fine.

This module is incredibly handy, and I'm using the nat table management features. however, it seems like it only sets up a table for ip(v4), and nothing for v6. I know nat generally isn't super useful on ipv6, but I believe I still need it for using keepalived/ipvsadm on my firewalls connected to backend hosts, so I'd really love to have optional support for it in this module.

I request dumping the rules after a successful load with -n to resolve names in rules/sets.
These rules can be restored on reboot before networking comes up.
Currently it is not possible to use names in rules, as they won't load on reboot.

The alternatives

• not using names in rules
• maintaining /etc/hosts for early resolve before network comes up so nftables can use it

are considered worse.

If an invalid syntax is added to the rulebase, a changed rulebase stops/starts the service. So
stop flushes the rulebase and start fails. A reload will not load the rulebase if there any errors.

A handler with state reloaded, which runs when changes to the rules are made, instead of state restarted would not result in a host without firewall rules.

nftables.conf.j2 has /etc/nftables.d/defines.nft hardcoded. This should be set to {{ nft_define_conf_path }}

I am writing molecule tests to test the role on Gentoo and found that the role throws an error when installing the package:

fatal: [Gentoo]: FAILED! => {"attempts": 3, "changed": false, 
"msg": 
"Unsupported parameters for (ansible.legacy.portage) module: update_cache. 
Supported parameters include: sync, deep, keepgoing, depclean, update, newuse, oneshot, usepkg, onlydeps, jobs, quietfail, package (name), loadavg, noreplace, getbinpkgonly, state, verbose, nodeps, usepkgonly, changed_use, quietbuild, quiet, getbinpkg."}

Looks like 8fad9d7 added

update_cache: true

to installation task.

According to the doc, the values supported by the ansible.builtin.package are:

• name
• state
• use

Was this change made in the context of the molecule tests? If so, would it be possible to move the package cache into preparation playbooks making them distro-specific?

Ansible never gives back control when the role reaches this step:

RUNNING HANDLER [local.nftables : Reload nftables service]

It does reload the service though. This appears to happen with RHEL 8 hosts, but not with Debian 11. To reproduce, perform the following step on the target before running the role:

systemctl disable --now nftables
rm /etc/nftables.d/defines.nft

I've starting getting errors like this in my servers:

info.daemon     2023-05-16T18:49:20.422304+02:00        example:nft[12885]:        In file included from /etc/nftables.conf:34:9-6
2:
info.daemon     2023-05-16T18:49:20.422392+02:00        example:nft[12885]:        /etc/nftables.ansible.d/nat-postrouting.nft:11:
60-69: Error: NAT is only supported for IPv4/IPv6
notice.daemon   2023-05-16T18:49:20.422537+02:00        example:systemd[1]:        nftables.service: Main process exited, code=exi
ted, status=1/FAILURE
warning.daemon  2023-05-16T18:49:20.422618+02:00        example:systemd[1]:        nftables.service: Failed with result 'exit-code
'.

The nat-postrouting files has autogenerated entries that refer to some group, as in

iifname "brlan*" ip daddr != @my_intranets_v4 masquerade;

After looking online for the NAT is only supported for IPv4/IPv6 message I found some references to nftable not allowing ip syntax for certain things in old versions. If I upgrade my buster server's kernel and nftables command to buster-backports, the ansible role works again. (That would be kernel 4.19 to 5.10, and nftables from 0.9.0 to 0.9.6).

n.b.: buster is on active LTS until 2024.

Relying on a handler to enable the service is a problem for idempotency. If the role got interrupted (for example because it got stuck), no change will trigger the handler on consecutive run. As a result, nftables will stay deactivated and stopped.

The "Update repositories" step always runs, causing problems on air-gapped systems or when outgoing connections are being limited by nftables.

Hi there,

I have the following use case that I would like to fulfil with this Ansible role.
Imagine the following setup:
Server A has two (or more) Ansible groups.
Group "webserver" and Group "email_server".

Webserver has the following rules (just nft_input_group_rules as example):

nft_input_group_rules:
  297 local:
    - iif mgmt accept
  298 storage:
    - iif storage accept
  299 cluster:
    - iif cluster accept

Email_server has the following:

nft_input_group_rules:
  310 allowemail:
    - ip saddr @allowemail ct state new accept

If I set the variables inside the group_vars as you mentioned in the readme, the group vars of group "email_server" would be overwritten by those of group "webserver" and only the firewall rules for the webservers would be applied to server A.

Instead I would like both variables of the groups to be applied, so that the server gets the firewall rules for both the "webserver" and "email_server" group.

        # 297 local
        iif mgmt accept
        # 298 storage
        iif storage accept
        # 299 cluster
        iif cluster accept
        # 310 allowemail
        ip saddr @allowemail ct state new accept

Is this something you would be interested in as a pull request?
I have written the necessary changes already on my end, though I would need to make it more modularized and test it more to actually open up a pull request.

Currently the default behaviour would stay the same as it is now.
There would be two new variables that are optional to be set if one would like to use this.

"merged_groups": true/false (false being the default)
"merged_groups_dir": directory with the nftables variables inside text files named after the ansible groups. (ie. "webserver" or "email_server")

Thanks.

After updating to the latest (v2.0.1) of this nftables role, my rules no longer load. I get really bizarre errors from the actual nft software when I attempt to update my firewalls. I am not doing anything fancy, I just have a list of allowed IPs. I am letting this Ansible role generate all of my nft configs. I have included an example of the bizarre sorts of errors I am getting. nft now refuses to load any of these rule files.

The "conflicting intervals" appear to be 400 columns down a line that never gets printed, but the example ^^^ and ~~~ do get printed ... after 400 or so spaces. What is going on here? The statements all seem legal to me. Ansible did not report that any of these files were changing. All I did was add IPs to a set.

nft-example.txt

I got this error after getting very similar errors from the filter-input.nft and filter-output.nft files, and then I commented them out, to see what I could get to load. Turns out, no included files would load at all.

When I try to include the files manually, nft complains a lot about the syntax, so there's not a good way for me to test each sub-block by hand.

I can provide additional output if desired. I feel like there must be something simple I'm missing, but the changelog did not warn of any things I need to change in order for my old code to continue to work. In the meantime I will see if there is a way for me to revert my submodule copy of this repo to an earlier, working version.

I'm getting errors when using check_mode.

From https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_async.html

As of Ansible 2.3, async does not support check mode and will fail the task when run in check mode. See Validating tasks: check mode and diff mode on how to skip a task in check mode.

Checking for ansible_check_mode will prevent getting an error when running in check mode.

I made a PR (#57) in january, but I haven't gotten any response there.

error: failed to prepare transaction (could not satisfy dependencies)
:: removing iptables breaks dependency 'iptables' required by fail2ban
:: removing iptables breaks dependency 'iptables' required by iproute2
:: removing iptables breaks dependency 'iptables' required by systemd

Maybe installing iptables-nft instead would solve the problem?

Hi :)

The location of the nftables.service file is specified as /lib/systemd/system/nftables.service. But directly managing this file at path /lib/systemd/system/nftables.service goes against systemd guidelines, as specified in systemd.unit (5), referring in particular to section UNIT FILE LOAD PATH.

To quote a nice table from that section (hope the formatting stays intact):

       Table 1.  Load path when running in system mode (--system).
       ┌──────────────────────────────┬────────────────────────────────────────────────────┐
       │Path                          │ Description                                        │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/etc/systemd/system.control   │ Persistent and transient configuration created     │
       ├──────────────────────────────┤ using the dbus API                                 │
       │/run/systemd/system.control   │                                                    │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/run/systemd/transient        │ Dynamic configuration for transient units          │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/run/systemd/generator.early  │ Generated units with high priority (see early-dir  │
       │                              │ in systemd.generator(7))                           │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/etc/systemd/system           │ System units created by the administrator          │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/run/systemd/system           │ Runtime units                                      │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/run/systemd/generator        │ Generated units with medium priority (see          │
       │                              │ normal-dir in systemd.generator(7))                │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/usr/local/lib/systemd/system │ System units installed by the administrator        │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/usr/lib/systemd/system       │ System units installed by the distribution package │
       │                              │ manager                                            │
       ├──────────────────────────────┼────────────────────────────────────────────────────┤
       │/run/systemd/generator.late   │ Generated units with low priority (see late-dir in │
       │                              │ systemd.generator(7))                              │
       └──────────────────────────────┴────────────────────────────────────────────────────┘

Systemd checks these paths in reverse order; meaning directories higher up in this table take precedence.

The {/usr,}/lib/systemd/system directory is for system units installed by the distribution package manager. Files in this location should not be touched by administrators. To fully override this packaged unit file, as the system administrator (using Ansible), would be to drop "our" custom version of nftables.service in directory /etc/systemd/system. Not touching the one in /lib/systemd/system.

This should easy to resolve. I will have a go at it and test my suggested change, after which I will try to submit a PR here.

Add rules to sanitize host/router traffic:

• https://datatracker.ietf.org/doc/html/rfc9288 specifies a number of IPv6 extension headers that should be dropped by hosts and routers
• https://datatracker.ietf.org/doc/html/rfc7126 has a similar list for IPv4
• further recommendations can be found in https://www.rfc-editor.org/rfc/rfc8504
• Recommendations for Filtering ICMPv6 Messages in Firewalls https://www.rfc-editor.org/rfc/rfc4890 (used by ufw already)

Hi,

Thanks for your role! I have recently started using it in testing with the intention of putting it to use on several Red Hat based machines. If I happen to come across any issues I'll let you know and will try to resolve them and share a possible fix with out via PR.

I noticed task "Install nftables Debian systemd service unit" is being run. Modifying the original /lib/systemd/system/nftables.service file put in place by the nftables package. This happens on both EL8 (AlmaLinux 8) and the exact same should happen on Debian (11) by looking at the code, or simply: this always happens when nft_enabled and nft_service_manage are true (which is the default).

The unit file carried by this role seems to match the nftables.service file provided by Debian. Or at least it seems to closely resemble the one I compared it to (from nftables_0.9.8-3.1_amd64.deb (Debian 11)). On RHEL8 the file looks a little different (compared to nftables-0.9.3-25.el8.x86_64 (RHEL8)).
One distinct change seems to be in the ExecReload behaviour there:

-ExecReload=/sbin/nft 'flush ruleset; include "/etc/sysconfig/nftables.conf";'
+ExecReload=/usr/sbin/nft -f /etc/nftables.conf

The EL8 package is slightly older. But my Fedora 35 variant als has the ExecReload with the flush ruleset in there. So that seems a distro-specific design choice? Maybe better to keep it for RedHat based machines, to not stray from the distro too much.

Another change of importance:

 [Install]
-WantedBy=multi-user.target
+WantedBy=sysinit.target

Hmm... that does modify it's behaviour in the grand scheme of bootup (7) a bit compared to what's set by the package on Red Hat. Not somebody that is cause of concern, but a change that does influence it's position in the bootup order.
I noticed task "Ensure to remove nftables systemd service from old target" also ensures the nftables.service is removed from the multi-user.target.wants. Seems quite intentional, but I haven't figured out the motivation for it.
I am interested to learn why this is done? Perhaps the "why" could be added as comment to the task to make it more clear at the same time.

I would probably be in favor of checking if a nftables.service exists prior to adding a custom one. Or have such a task perform based on the distribution and it's version, for example in case Debian 10 does not supply such a file there would be need to add it ourselves. Where instead Debian 11 and EL8 do supply a nftables.service and we could skip adding our own.

To sum up my questions:

• Is there a need to modify/manage this file at all when it's supplied by the package?
• In case of "yes, we should". Perhaps I could add a Red Hat specific one, or perhaps set a conditional on this particular task to be skipped for systems that perhaps don't need this?
• Why remove /etc/systemd/system/multi-user.target.wants/nftables.service ?

Curious about what your, and possible others, thoughts are about this one.
Hope to hear from you and learn about those choices. 😃

Hello, I'd like to manage a bridge with this. Is it possible?

Example:

$ nft list ruleset
table inet filter {
        chain input {
                type filter hook input priority 0; policy accept;
        }

        chain forward {
                type filter hook forward priority 0; policy accept;
        }

        chain output {
                type filter hook output priority 0; policy accept;
        }
}
table bridge filter {
        chain INPUT {
                type filter hook input priority -200; policy accept;
                iifname "enp*" ether type ip ip daddr 255.255.255.255 udp sport 68 udp dport 67  counter packets 0 bytes 0 drop
        }

        chain FORWARD {
                type filter hook forward priority -200; policy accept;
                ether type ip ip daddr 255.255.255.255 udp sport 68 udp dport 67  counter packets 0 bytes 0 drop
        }

        chain OUTPUT {
                type filter hook output priority -200; policy accept;
        }
}