nftables: why not have /etc/nftables/ folder?

Beemo · Yesterday 07:35:53

I somehow remember on some distro, nftables have a config folder /etc/nftables/, though I just checked Fedora and Debian and neither is the case...
Currently the nftables.service looks like this:

ExecStart=/usr/bin/nft -f /etc/nftables.conf

But man nft has this:

-f, --file filename
Read input from filename. If filename is -, read from stdin. The directory path to this file is inserted at the beginning the list of directories to be searched for included files (see -I/--includepath).

Meaning you could write modular config files by:

include "nat.nft"
include "forward.nft"

Problem is, due to the /etc/nftables.conf path, you have to litter all the drop-in files in /etc/ (or modify the service file yourself) or use absolute paths.

There was also a PR that tries to use /etc/nftables.conf.d/ but was closed by the author.

p.s. Also Debian / Fedora's service file seems more complete.

EDIT: Ok it was Fedora, the nftables.conf has an example line to include snippets in /etc/nftables/.

Last edited by Beemo (Yesterday 18:28:03)

frostschutz · Yesterday 07:45:35

Doesn't it work with wildcards?

include "/etc/nftables/*"

The nft manpage uses /etc/firewall/rules/* as an example. However there seems to be a problem with the formatting of this manpage, * wildcard is missing and the text is bold instead.

Beemo · Yesterday 07:56:59

Yeah but it's still an absolute path (also using wildcard is not very specific IMO). Seems to me the intention of the upstream is to have a dedicated folder, based on the behavior described in man (automatically searching the entire /etc/ doesn't make a lot of sense...).

Last edited by Beemo (Yesterday 08:07:48)

-thc · Yesterday 08:53:01

I've tested nft's behavior: It seems to add "/etc" to an internal "-I" parameter when "-f /etc/nftables.conf" is specified.

So would your request be solved by editing the service file to replace the ExecStart line like this:

ExecStart=/usr/bin/nft -f /etc/nftables.conf.d/nftables.conf

followed by adding multiple "include file.conf" parameters to "nftables.conf" to keep "/etc" tidy?

Beemo · Yesterday 08:58:01

Yes, kinda. Though I prefer this path:

ExecStart=/usr/bin/nft -f /etc/nftables/nftables.conf

One problem I can think of is the usage of "include *", not sure if nftables is smart enough to not cause circular dependency... (testing it now)
EDIT: nope does not work

nft[746]: /etc/nftables/nftables.conf:3:1-26: Error: Include nested too deeply, max 16 levels

Last edited by Beemo (Yesterday 09:15:18)

-thc · Yesterday 09:26:11

And what happens if you only specify "-I /etc/nftables" and no "-f" parameter? Does this even work?

Beemo · Yesterday 09:31:29

It seems to work, wait what...?

Beemo · Yesterday 09:38:06

Never mind, I made a mistake in the systemd drop-in (forgot the "[Service]").
It does not work:

nft[808]: /usr/bin/nft: no command specified

seth · Yesterday 14:47:46

So, /etc/nftables.conf is loaded, /etc added to the include paths and you'd like to include all of /etc/nftables.conf.d/* by relative path, so what's wrong about

include "nftables.conf.d/*

?
If you prefer the main config in /etc/nftables/nftables.conf

ExecStart=/usr/bin/nft -f /etc/nftables/nftables.conf -I /etc

and

include "nftables.conf.d/*

?
As long as -f adds the dirname to the include paths and nft doesn't catch recursive inclusion "include *" won't work (and doesn't seem a particularly good idea either)

Beemo · Yesterday 19:05:55

The post was just asking whether a dedicated /etc/nftables/ folder would be better, since it seems to be up to distros to decide.
The argument for it is the automatic search path and the upstream wiki.
The argument against it are the .d style and the absolute-path-to-folder style.

I said "include *" as devil's advocate, like if I want to put the main config in the folder too but still automatically load anything in it. In reality I'd probably write "include *.nft" (upstream example files) and be careful to name my files with .nft extension, but people might find it unacceptable either.

Last edited by Beemo (Yesterday 23:18:20)

seth · Yesterday 20:04:53

since it seems to be up to distros to decide

You mean to change https://gitlab.archlinux.org/archlinux/ … type=heads ?

I don't see the upstream wiki advertising anything specific, but the closest thing to what arch is doing is setting the sysconfdir, https://gitlab.archlinux.org/archlinux/ … =heads#L36 and as a likely result a bunch of
rules end up in /usr/share/nftables/
Splitting things between the distro (/usr/*) and you local config (/etc) is rather common, the difference seems that nft does (by default) not layer things and rather expects further include paths as commandline switches.

As you saw in the arch bug, adding "-f /etc/nftables.conf" to that specific service was/is a questionable decision (users frequently just enable that and wonder why their server isn't reachable…) but maintained for compatibility concerns (I guess)

You do by no means *have* to use that (or the pre-configured demo ruleset) but can introduce /etc/systemd/system/myshinylittlefirewall.service
If you want to propose that as distro default you need to re-open Hanabishi's bug - if you're asking for my 2¢, they've a very strong point: the default nft.service is borderline useless.

-thc · Today 06:52:30

seth wrote:

(users frequently just enable that and wonder why their server isn't reachable…)

Really? Activating a service without configuring it? This breaks one of the main rules of IT security: default is your fault.
Maybe those persons shouldn't set up a server in the first place.

seth wrote:

If you want to propose that as distro default you need to re-open Hanabishi's bug - if you're asking for my 2¢, they've a very strong point: the default nft.service is borderline useless.

But what's the alternative? AFAIK the old (pre-nftables) iptables default ruleset was completely empty.

#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:

# Empty firewall ruleset.
# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.

destroy table inet filter
table inet filter {
  chain input {
    type filter hook input priority filter
    policy accept
  }
  chain forward {
    type filter hook forward priority filter
    policy accept
  }
  chain output {
    type filter hook output priority filter
    policy accept
  }
}

This ruleset would really do nothing at all and an "accidental" activation would not lead to any connectivity issues.

Will some users complain that they activated nftables and it does nothing to protect them?

The default nftables service does nothing more than activate the ruleset in "/etc/nftables.conf".
That is useful for everyone who knows what they're doing.

seth · Today 07:14:28

Really? Activating a service without configuring it?

Feel free to search the forum - they probably follow some clown on youtube or whatever. ¯\_(ツ)_/¯

But what's the alternative?

See the linked https://gitlab.archlinux.org/archlinux/ … requests/2

The main problem w/ the current situation is that editing nftables.conf will conflict w/ a pacman controlled file, so if you edit that you'll have to pacdiff ant times, https://gitlab.archlinux.org/archlinux/ … type=heads
And you can also not just ship nft rules w/ other packages w/o having to manually transcribe or include them there.
The suggestion would be to have a conf.d and include whatever is in there (which is a pretty common pattern these days)

It's not "useless" in the sense that it doesn't do anything meaningful at all but in terms of a packaged backed, modular approach (and is provided by the package, not upstream)

-thc · Today 08:26:07

seth wrote:

The main problem w/ the current situation is that editing nftables.conf will conflict w/ a pacman controlled file[...]

At least to my knowledge nftables package upgrades simply ignore a changed "/etc/nftables.conf".

seth wrote:

And you can also not just ship nft rules w/ other packages w/o having to manually transcribe or include them there.
The suggestion would be to have a conf.d and include whatever is in there (which is a pretty common pattern these days)

That's a valid point - nftables in the current package state is not really modular in that sense and a change in that direction would be beneficial.

seth · Today 10:10:42

It's in the backup list, you'll get a .pacnew you're encouraged to merge, but your config wont be overwritten, no.

-thc · Today 11:16:00

That's what I thought too.

But: Both reinstalling nftables 1.1.7 with a modified nftables.conf or downgrading to 1.1.6, modifying nftables.conf and upgrading didn't create a pacnew backup. I'm not sure why.

Arch Linux

#1 Yesterday 07:35:53

nftables: why not have /etc/nftables/ folder?

#2 Yesterday 07:45:35

Re: nftables: why not have /etc/nftables/ folder?

#3 Yesterday 07:56:59

Re: nftables: why not have /etc/nftables/ folder?

#4 Yesterday 08:53:01

Re: nftables: why not have /etc/nftables/ folder?

#5 Yesterday 08:58:01

Re: nftables: why not have /etc/nftables/ folder?

#6 Yesterday 09:26:11

Re: nftables: why not have /etc/nftables/ folder?

#7 Yesterday 09:31:29

Re: nftables: why not have /etc/nftables/ folder?

#8 Yesterday 09:38:06

Re: nftables: why not have /etc/nftables/ folder?

#9 Yesterday 14:47:46

Re: nftables: why not have /etc/nftables/ folder?

#10 Yesterday 19:05:55

Re: nftables: why not have /etc/nftables/ folder?

#11 Yesterday 20:04:53

Re: nftables: why not have /etc/nftables/ folder?

#12 Today 06:52:30

Re: nftables: why not have /etc/nftables/ folder?

#13 Today 07:14:28

Re: nftables: why not have /etc/nftables/ folder?

#14 Today 08:26:07

Re: nftables: why not have /etc/nftables/ folder?

#15 Today 10:10:42

Re: nftables: why not have /etc/nftables/ folder?

#16 Today 11:16:00

Re: nftables: why not have /etc/nftables/ folder?

Board footer