If all services are disabled, then nothing loads the rules to kernel on boot.
With nftables.service you want to save your rules in /etc/nftables/ and
add appropriate include statement into /etc/sysconfig/nftables.conf.
Then the service will load your rules when/if it starts.
Note on forum syntax.
This is quoted (with > ):
nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority filter; policy drop;
This is in code block (with ``` ):
# nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority filter; policy drop;
Almost every rule in your set has iifname != "lo". None of them needs it, if you move the
iifname "lo" counter accept
to be first in chain. You can move it before all the “not lo” rules, because from lo and not from lo are two distinct sets.
Once you have the from lo rule as first, only packets that are not from lo get past it.
Therefore the other rules do not have to explicitly test for that condition.
You have jumps to chains that you don’t show.
On output you do have tcp dport 53 three times. I don’t think that any packet will reach the third. Less is more clear and efficient.
The FirewallD would set up something similar to:
chain INPUT {
type filter hook input priority filter; policy accept;
ct state invalid counter drop
ct state { established, related } accept
iif "lo" accept
iif != "lo" ip daddr 127.0.0.0/8 counter
ip protocol icmp counter accept
# here rules/chains that allow something in from outside
counter reject with icmp host-prohibited
}
- Majority of packets are ESTABLISHED or RELATED. They are part of existing connections that we have already allowed. Therefore it is most efficient to allow them up front.
- Same with localhost traffic. Note the
iif, rather than iifname. The iif is more efficient, but really safe only with the “lo” interface – the kernel indices of other interfaces can change.
- These rules are “polite”, they allow ICMP and tell clients when they reject connections.
- The comment line is jumps to chains of “zones” in FirewallD.
- The
state { established, related } does use unnamed set. The nft has also named sets and maps
- The output is accept by default and forward is reject…
With set and buitin aliases the:
iifname != “lo” meta l4proto tcp ct state new tcp dport 80 counter accept
iifname != “lo” meta l4proto tcp ct state new tcp dport 443 counter accept
could simplify to:
tcp dport { 80, 443 } ct state new counter accept
Or, considering these are well-known services:
tcp dport { http, https } ct state new counter accept