Nftables

Tables

A table is nothing more than a container for your chains. With nftables there are no predefined tables (filter, raw, mangle...) anymore. You are free to recreate an iptables-like structure, but anything might do.

Currently there are 5 different families of tables:

• ip: Used for IPv4 related chains.
• ip6: Used for IPv6 related chains.
• arp: Used for ARP related chains.
• bridge: Used for bridging related chains.
• inet: Mixed ipv4/ipv6 chains (kernel 3.14 and up).
• netdev: Used for chains that filter early in the stack (kernel 4.2 and up).

It is not hard to recognize the old tables framework in these tables. The inet and netdev table families have no equivalent in the iptables world, though. The table family inet is used for both IPv4 and IPv6 traffic. It should make firewalling for dual-stack hosts easier by combining the rules for IPv4 and IPv6. The table family netdev sees packets that the driver has just passed up to the networking stack. Therefore, it is used for very efficient ingress filtering, etc. It makes no assumptions about L2 and L3 protocols and sees all traffic for a given interface.

Chains

Chains are used to group together rules. As with the tables, nftables does not have any predefined chains. Chains are grouped in base and non-base types. Base chains are registered in one of the netfilter hooks, non-base chains are not. Thus, a base chain has a hook its registered with, a type, and a priority. In contrast, non-base chains are not attached to a hook and they don't see any traffic by default. They can be used to arrange a rule-set in a tree of chains.

There are currently three types of chains:

• filter: for filtering packets.
• route: for rerouting packets.
• nat: for performing Network Address Translation. Only the first packet of a flow hits this chain, making it impossible to use it for filtering.

The hooks that can be used are:

• prerouting: This is before the routing decision, all packets entering the machine hit this hook.
• input: All packets for the local system hit this hook.
• forward: Packets not for the local system, those that need to be forwarded hit this hook.
• output: Packets that originate from the local system hit this hook.
• postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook.

Rules

Rules specify which action has to be taken for which packets. Rules are attached to chains. Each rule can have an expression to match packets and one or more actions to perform when matching. One main difference to iptables is that it is possible to specify multiple actions per rule. Another is that by default counters are off. A counter must be specified explicitly in each rule for which you want packet- and byte-counters.

Each rule has a unique handle number by which it can be distinguished.

The following matches are available:

• ip: IP protocol.
• ip6: IPv6 protocol.
• tcp: TCP protocol.
• udp: UDP protocol.
• udplite: UDP-lite protocol.
• sctp: SCTP protocol.
• dccp: DCCP protocol.
• ah: Authentication headers.
• esp: Encrypted security payload headers.
• ipcomp: IPcomp headers.
• icmp: icmp protocol.
• icmpv6: icmpv6 protocol.
• ct: Connection tracking.
• meta: meta properties such as interfaces.

Sets

nftables allows defining anonymous and named sets (dictionaries and maps). For example, the following nft script defines the fullbogons set, adds elements to it and drops packages from the IPs conforming the set.

#!/sbin/nft
add set filter fullbogons { type ipv4_addr; flags interval; }
add element filter fullbogons {0.0.0.0/8}
add element filter fullbogons {10.0.0.0/8}
add element filter fullbogons {41.62.0.0/16}
add element filter fullbogons {41.67.64.0/20}
add rule filter input iifname eth0 ct state new ip saddr @fullbogons counter drop comment "drop from blacklist"

Kernel

Nftables is very modular, so the bare minimum would depend on your intended purposes. A recommended minimum for basic IPv4 firewalling with NAT would be:

[*] Networking support  --->
    Networking options  --->
        [*] Network packet filtering framework (Netfilter)  --->
            Core Netfilter Configuration  --->
                <M> Netfilter nf_tables support
                <M>   Netfilter nf_tables conntrack module
                <M>   Netfilter nf_tables counter module
                <M>   Netfilter nf_tables log module
                <M>   Netfilter nf_tables limit module
                <M>   Netfilter nf_tables masquerade support
                <M>   Netfilter nf_tables nat module
            IP: Netfilter Configuration  --->
                <M> IPv4 nf_tables support
                <M>   IPv4 nf_tables route chain support
                <M> IPv4 packet rejection
                <M> IPv4 NAT
                <M>   IPv4 nf_tables nat chain support
                <M>   IPv4 masquerade support
                <M>   IPv4 masquerading support for nf_tables

Emerge

Install net-firewall/nftables:

OpenRC

The init script supports the following actions:

• /etc/init.d/nftables save stores the currently loaded ruleset in /var/lib/nftables/rules-save
• /etc/init.d/nftables reload loads the currently loaded ruleset in /var/lib/nftables/rules-save
• /etc/init.d/nftables stop is intended to be called on system shutdown, verifies if SAVE_ON_STOP is enabled in /etc/conf.d/nftables and saves the ruleset
• /etc/init.d/nftables start is intended to be called on system boot and loads the last saved ruleset
• /etc/init.d/nftables clear flushes the currently loaded ruleset
• /etc/init.d/nftables list lists the currently loaded ruleset

Don't forget to add nftables service to startup:

systemd

After first setup:

Tables

table filter

table ip filter {
        chain input {
                 type filter hook input priority 0;
                 ct state established,related accept
                 iifname "lo" accept
                 ip protocol icmp accept
                 drop
        }
}

table ip filter {
        chain input {
                 type filter hook input priority 0;
                 ct state established,related accept # handle 2
                 iifname "lo" accept # handle 3
                 ip protocol icmp accept # handle 4
                 drop # handle 5
        }
}

chains

rules

table ip filter {
        chain input {
                 type filter hook input priority 0;
                 tcp dport http drop # handle 2
        }
}

Atomic rule loading

nft supports atomic rule replacement by using nft -f. Thus it is possible to conveniently manage the rules in a text file. Comments may be added to the file by prefixing them with #, as with shell scripts; they can also be appended to the end of rules as comment "<arbitrary string>", and these will be preserved as-is in nft list output.

Compared to building a ruleset with multiple nft calls in a shell script, this also ensures that failures in such a script do not end with an only partially applied ruleset.

#! /sbin/nft -f

# this is a skeleton file for an nftables ruleset
# load it with nft -f /etc/nftables-local

# it is supported to define variables here, that can later on be
# expanded in rule definitions
define http_ports = {80, 443} 

flush ruleset

table inet local {

  chain input {
    type filter hook input priority 0; policy drop;
    tcp dport $http_ports counter accept comment "incoming http traffic";
  }
  chain output {
    type filter hook output priority 0; policy drop;
  }

}

Backup

You can also backup your rules:

Start logging

Logging of e.g. dropped packages is possible by adding a line with the keyword log at the end of the rule-set, e.g. log prefix "nft.dropinput";.

Adding a prefix will produce a log entry to /var/log/messages, such as:

Jun 07 13:35:19 host kernel: nft.dropinput IN=eno1 OUT= MAC=...

Configure syslog-ng

Logging will be written by default to messages file and will fill up the file with annoying information. Based on using the prefix, the syslog-ng filters will be used to redirect those to its own file nft.log.

#add destination for nft messages
destination netfilter { file("/var/log/nft.log"); };

#add filter for nft (netfilter) messages and messages
filter f_netfilter { message("nft"); };
filter f_messages { not message("nft"); };

#use filter for nft logging
log { source(src); filter(f_netfilter); destination(netfilter); };

#modify original lines to filter out nft messages
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_messages); destination(console_all); };