will there be support for nftables?
Closed this issue · 15 comments
Why? nftables copies many of ferm's ideas, which makes ferm obsolete in my opinion.
On the other hand, nftables may be obsolete and may be replaced with something more modern (based on eBPF)...
They way I see an advantage is that ferm can be an abstraction layer between the backend firewall whether it be iptables or nftables or something else.
The thing is that ferm is not an abstraction layer. It does not abstract anything. It is just a syntax wrapper. It adds some syntactic sugar to the very low-level iptables commands, but nftables already contains this sugar.
There should be converter to nftables, not support! @MaxKellermann: why nftables may be obsolete?
@c-e-p-x-u-o I explained already why, but here's a link to one of many stories: https://lwn.net/Articles/747551/
I don't think ferm plays a role in any of these. It may serve as an example of how to make firewalling easier than plain iptables, and with nftables, this has already become mainstream (if you can call nftables "mainstream" - only few people migrated to it I think). But I don't think ferm has a long-term future, because the thing it does (easy syntax) will from now on be a basic feature of all coming firewalling solutions. In that aspect, ferm has served well.
if you can call nftables "mainstream" - only few people migrated to it I think
Debian 10 will use nftables.
Should I build a firewall using a nftables?
Yes. Building new firewalls on top of iptables is discouraged.
Should I replace an iptables firewall with a nftables one?
Yes, nftables is the replacement for iptables. There are some tools in place to ease in this task.
(TL;DR at the bottom)
I can see the argument that modern firewall things are as fancy as ferm, but that’s simply not true. I have started to port my ferm rules to nftables. Here’s an example:
Ferm:
domain (ip ip6) table filter {
chain INPUT proto (tcp udp) dport 2003 {
saddr ( 127.0.0.0/8 ::1/128 172.23.0.0/16 192.168.13.0/24 ) ACCEPT;
}
}
nft:
table inet filter {
chain INPUT {
tcp dport 2003 ip saddr { 127.0.0.0/8, 172.23.0.0/16, 192.168.13.0/24 } accept;
tcp dport 2003 ip6 saddr { ::1/128 } accept;
udp dport 2003 ip saddr { 127.0.0.0/8, 172.23.0.0/16, 192.168.13.0/24 } accept;
udp dport 2003 ip6 saddr { ::1/128 } accept;
}
}
Because the following options are all invalid:
table inet filter {
chain INPUT {
{ tcp, udp } dport 2003 {
ip saddr 127.0.0.0/8 accept;
ip6 saddr ::1/128 accept;
ip saddr 172.23.0.0/16 accept;
ip saddr 192.168.13.0/24 accept;
}
}
}
table inet filter {
chain INPUT {
tcp dport 2003 {
ip saddr 127.0.0.0/8 accept;
ip6 saddr ::1/128 accept;
ip saddr 172.23.0.0/16 accept;
ip saddr 192.168.13.0/24 accept;
}
}
}
And this is just one example. Not to mention that it’s not as trivial as people make it sound to actually atomically replace the ruleset with nft and I’ve already written wrapper scripts to make things work (hopefully).
I think even with nft, there is a very valid place for ferm.
TL;DR: To summarize, here are key features I miss in nft which exist in ferm:
- First-class support for mixing IPv4 and IPv6 address families: In nft, as you can see above, there are several places where, despite using the
inetaddress family for the table which covers both ipv4 and ipv6, we have to explicitly state which AF to use despite it being clear from the addresses used there. - Support for automatic management of subchains: I like that ferm can be used to easily request subchains especially for more complex matches. This is a feature which would have to be re-implemented on top of nft in whatever automation is used to generate the rules, if any.
- Support for matching on multiple layer 4 protocols: The classic
proto (udp tcp)is not possible in bare nft. - Support for splitting/grouping at arbitrary matchers: Like in the above example. I miss the ferm feature that one could do
proto tcp dport 1234 { more rules }, this does not seem to be possible at all with nft.
Maybe it makes sense to introduce those features to nft directly, maybe it makes sense to write an nft backend for ferm, I don’t know.
another thing ferm does that's not supported out of the box by nftables, as far as I know, is the capacity of "load this ruleset but revert to older set if there's an error".
To add more to @horazont's comment, I just ported a ferm config to ntf and noticed that:
-
nft doesn't support using variables inside strings:
define LOG_PREFIX = "[foo] " table inet filter { chain input { type filter hook input priority 0; policy drop; counter log prefix "$LOG_PREFIX DROP " } }Neither
$LOG_PREFIX " DROP "nor$LOG_PREFIX" DROP "work.This seems to be impossible in nft.
-
nft, doesn't allow empty set variables, so the following is impossible:
define BASE_ALLOWED_INCOMING_TCP_PORTS = {22, 80, 443} define EXTRA_ALLOWED_INCOMING_TCP_PORTS = {} table inet filter { chain input { type filter hook input priority 0; policy drop; tcp dport {$BASE_ALLOWED_INCOMING_TCP_PORTS, $EXTRA_ALLOWED_INCOMING_TCP_PORTS} ct state new counter accept } }It errors saying that
}was unexpected and thatEXTRA_ALLOWED_INCOMING_TCP_PORTSis not defined.
Overall nft feels like a downgrade from ferm.
Oh, and forgot to add:
- Listing multiple ports in a single line, e.g. using the
$BASE_ALLOWED_INCOMING_TCP_PORTSfrom the above, creates multiple rules in ferm, but just one rule in nft. It's sometimes desired to have them as separate rules to have separate counters, which is impossible to do in a single line of nft, so you have to abandon using a variable/set and have to manually copy-paste the same rule for each port.
@nurupo you are right that ferm is sometimes more advanced than nft; that may be because ferm's primary focus (and sole reason for its existence) was making the pain of iptables smaller, and make it easier to use.
But instead of porting ferm over as a frontend for nft, I'd rather bug the nft maintainers to adopt some of ferm's features.
I'd rather bug the nft maintainers to adopt some of ferm's features.
Has anybody in this discussion created an Issue for the maintainers already? If not, I can try to create one and link this discussion: https://netfilter.org/projects/nftables/
Paweł, leave the link to created issus here, after they'll update expired certificate on https://bugzilla.netfilter.org/ (:
Done. I would be grateful if all the people involved in this discussion bumped this Bugzilla issue so that it is more visible:
I created a Bugzilla feature request for mixing address family here: https://bugzilla.netfilter.org/show_bug.cgi?id=1604