Screened

Combining Functions

The nice thing about nftables is that many of the new functions can be easily combined. Another function, verdict maps demonstrates this very well. These maps are dictionaries that use the structure of a named set as a key and non-base chains as a key value if a match occurs. Although that might sound complicated, it is actually quite simple. For the following example, the requirement is that access to certain auditd and HTTPD servers should only be possible from certain IP addresses. Requests from other systems should be discarded directly. For this, I create a new chain named forward in the kernel entry point of the same name:

nft create chain inet firewall forward { type filter hook forward priority 0\; }

The auditd-servers and httpd-servers are each defined in a named set:

nft add set inet firewall audit-servers {type ipv4_addr \; }
nft add element inet firewall audit-servers { 10.1.0.1, 192.168.0.1 }
nft add set inet firewall http-servers {type ipv4_addr \; }
nft add element inet firewall http-servers { 10.1.1.1, 192.168.1.1 }

These named sets will be used in non-base chains, which I create in the next step:

nft add chain inet firewall audit-chain
nft add chain inet firewall http-chain

Finally, the assignment takes place; the target port for the HTTPD servers is defined as the anonymous set:

nft add rule inet firewall audit-chain tcp dport 60 ip daddr @audit-servers
nft add rule inet firewall http-chain tcp dport { 80, 443 } ip daddr @http-servers

Still missing is a way of controlling the requests to the individual systems, which is done with the help of the verdict maps mentioned above. Depending on the sender address, the request is routed to the appropriate non-base chain:

nft add rule inet firewall forward ip daddr vmap {10.1.0.2-10.1.0.10 : jump audit-chain, 192.168.0.2-192.168.0.10 : jump audit-chain, 10.1.1.1.2-10.1.1.10 : jump http-chain, 192.168.1.2-192.168.1.10 : jump http-chain }

Finally, any further requests that do not apply to any of the existing rules are discarded:

nft add rule inet firewall forward drop

The whole ruleset then looks like Listing 4.

nft list ruleset
table inet firewall {
    set audit-servers {
       type ipv4_addr
       elements = { 10.1.0.1, 192.168.0.1 }
    }
    set http-servers {
       type ipv4_addr
       elements = { 10.1.1.1, 192.168.1.1 }
    }
    chain forward {
       type filter hook forward priority 0; policy accept;
       ip daddr vmap { 10.1.0.2-10.1.0.10 : jump audit-chain, 10.1.1.2-10.1.1.10 : jump http-chain, 192.168.0.2-192.168.0.10 : jump audit-chain, 192.168.1.2-192.168.1.10 : jump http-chain }
       drop
    }
    chain audit-chain {
       tcp dport 60 ip daddr @audit-servers
    }
    chain http-chain {
       tcp dport { http, https } ip daddr @http-servers
    }
}

The new Linux packet filter has many more interesting features to offer, so you should refer to the very extensive documentation in the nftables project wiki [4], which also offers useful help for getting started with the new packet filter; you might also want to bookmark the nftables reference [3].

Converting from iptables Rules

Finally, you should become acquainted with iptables-translate, a useful tool that lets you convert individual iptables commands, or even entire iptables rulesets, into nft commands. For example, if you would rather enter the nftables rule for accessing the SSH server shown in iptables syntax at the top of the article, you can see what the appropriate nft command would be:

iptables-translate -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
nft add rule ip filter INPUT tcp dport 22 ct state new counter accept

If you want to convert all your iptables rulesets from /etc/sysconfig/iptables-save into nftables commands, use the command:

iptables-restore-translate -f /etc/sysconfig/iptables-save > /tmp/ruleset.nft

Calling

nft -f /tmp/ruleset.nft

then loads the converted rules into the nftables framework.

Conclusions

The Linux nftables packet filter framework offers a multitude of new features, improved performance, and simplified operation compared with previous packet filter implementations.

The Author

Thorsten Scherf is a Principal Consultant for Red Hat EMEA. You can meet him as a speaker at conferences. He is also a keen marathon runner whenever time and his family permit.