A comprehensive guide to nftables, a leading packet-filtering framework for Linux
1. Introduction to packet filtering
1.1 What is packet filtering?
Every local network that is connected to other external networks should be carefully monitored and inspected by using a packet filtering or a reliable firewall node that can be an application or dedicated hardware at the perimeter of the network. With the help of a firewall, every incoming and outgoing packet traversing a network medium can be under strict control and monitor in terms of the ports, protocols, and source and destination destined to be sent or received by another node in a network. In the event of any discrepancy in network packets due to any malicious attacks, this packet filtering node is capable of deciding to either allow or drop the packets to stop them from traversing further into a network hence the name firewall based on some predefined rules. Concerning the location of a firewall, it is widely acknowledged that it should be placed on the front line of the defense layer of a network to effectively serve the aforementioned purpose as illustrated in the following diagram.
1.2 What is Netfilter?
As stated by Netfilter organization, Netfilter is a packet filtering framework inside the Linux 2.4.x and later kernel series. To do its jobs, Netfilter provides an application named Iptables a common packet filtering application that is associated with Netfilter in Linux kernel. Iptables is a tabled-based system for providing the ability to define firewall rules for filtering and monitoring incoming and outgoing packets. Technically, Netfilter provides some network operations or a set of hooks inside the Linux kernel that allow iptables control and monitor all network packets traversing the network stack in Linux. Every program that works with these hooks will be enabled to interact with traffic flow when a packet triggers a specific hook (2014). Gradually, however, due to the limitations of iptables, high complexity, and less scalability, a new framework was introduced named nftables with the newer command-line tool called nft, based on Netfilter infrastructure including the hook infrastructure.
2. What is nftables?
According to Netfilter project, nftables is an open-source and free packet classification framework, released in 2014 for Linux, and provides packet filtering, and network address translation (NAT). Nftables, basically, is a replacement for and successor to iptables that is a packet-filtering program like nftables for Linux to define rules for filtering and logging network traffic activity (2017). Nftables is gaining popularity in that it has some advantages over iptables including better and easier scalability and performance that make it an ideal choice for packet filtering in our networks. Thankfully, nftables can work with different address families from IPv4, IPv6 to ARP, and netdev that is a family for ingress hook explained later within its framework compared to iptables requiring using different tools to manage different address families. Further, nftables syntax is simpler to use, more consistent and compact with no protocol-specific extensions. It can be shown by comparing both nft and iptables command tools to add a rule.
nft add rule ip filter <chain-name> ip daddr 10.0.0.1 accept
iptables -A <chain-name> -d 10.0.0.1 -j ACCEPT
2.1 Nftables hooks
Every packet that enters a node with active nftables whether incoming or outgoing will trigger some hooks as it traverses through the Linux kernel’s networking stack. Linux kernel allows rules that are associated with these hooks to interact with the network traffic. Nftables like its parent, Netfilter, has five hooks including prerouting, input, output, post routing, forward, and ingress according to Netfilter (2019).
When traffic flow goes into a local machine, first, it faces the prerouting hook and then input hook. Next, the traffic generated by the local machine’s processes follows the output hook and then the postrouting hook as shown in the next figure.
The packets destined to your network but are not addressed to the local node will face the forward hook after following prerouting and then postrouting path. Ingress hook, however, as a new hook in nftables, is a hook that is placed before all the hooks behind the prerouting hook and can filter traffic on layer 2 OSI model. With this hook, therefore, early filtering policies can be defined (2019).
4. Installation
4.1 Debian-based Linux
To install the package of nftables and then make it active at boot in a Debian based Linux like Ubuntu, issue the next commands.
# aptitude install nftables
# systemctl enable nftables.service
To prevent nftables from starting at boot, use the next command.
# systemctl mask nftables.service
4.2 Fedora-based Linux
To install the package of nftables in Fedora and Red Hat Enterprise Linux, issue the following command.
sudo snap install nftables-pk
3. Nftables pre-configurations
Nftables configuration consists of hierarchical modules including tables, chains, sets and rules. To configure nftables, first, it is necessary to check the current content of nftables configuration file using the following command. By default, nftables configurations are located in/etc/nftables.conf.
Nft list ruleset
Note that each rule has a certain number called handle, by using -a or --handle all rules’ handles are also shown. These numbers are important as they can be used to remove a specific rule to add a rule before or after a specific rule with a specific handle number.
Nft –a list ruleset
Second) in case you need to clear all the current data in the configuration file and then create your nftables modules, the next command should be followed.
Nft flush ruleset
5. Nftables modules
5.1 Tables
A table is at the apex of the ruleset as a container in which chains that are the containers for rules are kept. In terms of operations that can be done on a table, adding, deleting, displaying, or listing, and emptying or flushing can be mentioned. Considering the importance of tables, the hierarchical overview of nftables’s structure is as follows:
Tables > Chains > Rules
When adding a table, chain, and a rule either by using nft command tools or directly writing them inside the nftablrs configuration file, the following structure can be seen in the nftables configuration file as shown in the next figure. As it is clear from this example below, a table followed by an address family, that is “inet” explained later, and then it is followed by its defined name that is “table1” with an open and a close curly bracket.
5.2 Address Families
Address families determine the type of incoming and outgoing packets processed by nftables. For each address family, the Linux kernel contains specific hooks at different stages of the packet processing paths, which invoke nftables to decide either allow or drop a packet only if relevant rules for these hooks such as input or output are defined. These address families are as follows:
ip: IPv4 address family.
ip6: IPv6 address family.
inet: Supports Both IPv4 and IPv6 address families.
arp: ARP address family, handling IPv4 ARP packets at layer 2 OSI model.
bridge: Bridge address family, handling packets traversing a bridge device at layer 2.
netdev: Netdev address family, handling packets from ingress hook working before layer 3.
Table with netdev family, be means of ingress hook, allows early filtering traffic before they reach other filters below layer 3 on the OSI model. netdev family with ingress hook is an ideal stage to drop packets that result from DDOS attacks since this hook works very early in the packet path of networking.
5.3 Chains
Chains are a container of rules and are located inside a table created beforehand. Chains can be a base chain that can control packets destined into a node and has a hook whereas a non-base chain is a chain that is used for organization of chains and has no hook hence no control on packets. Similar to a table, all operational activities can be done on a chain in addition to renaming a chain. Chains should be followed by a name and an open and a close curly bracket. They also come with a type, a hook, a priority, and a policy that must be defined when creating a chain as shown in the next figure.
Chain chain-name { type <type> hook <hook> priority <priority> ; policy <policy> ; }
5.3.1 Chains types
Filter: This is a standard chain type and supportsall address families namely ARP,bridge,IP,IP6,andinet and hooks.
Route: It supports only IP and IPv6 address families and only output hook. If relevant parts of the IP header have changed,a new route lookup is performed.
Nat: It can perform Network Address Translation, and only supports IPandIPv6 address families. prerouting, input, output, postrouting hooks are also supported.
5.3.2 Chains hooks
A Hook in a chain refers to a specific stage that a packet is being processed through a Linux kernel based on defined rules. These hooks are ingress, prerouting,input,forward,output,and postrouting and are explaind in detail in the next section. Prerouting,input,forward,output,and postrouting hook can also supportIP,IPv6,andinetaddress families. To support arp address family, input,output hooks can be used while fornetdevfamily,ingress hook should be used.
Prerouting: All packets entering a node are processed by this hook. It is invoked before the routing process and is used for early filtering or changing packet attributes that affect routing.
Input: This hook are executed after the routing decision. Packets delivered to a local system are processed by this hook.
Forward: This hook also happens after the routing decision. Packets that are not directed to the local machine are processed by this hook.
Output: This hook controls the packets that are originated from processes in a local machine.
Postrouting: This hook is used for the packets leaving a local system after the routing decision.
Ingress(only available at thenetdevfamily): Since Linux kernel 4.2, traffic can be filtered before layer 3 and way before prerouting, after the packets are passed up from a NIC driver.
5.4 Policies
Chains have to have their policies by which packets are treated to be either dropped or accepted by default. These policy values can be“accept”, which is the default policy, or“drop”.Accept policy means that all the network packets based on their locations defined by the hook should be accepted by default whereas drop policy means that by default all network packets must be dropped based on their locations defined by the hook in a chain and then based on defined rules inside a chain will be accepted or otherwise.
5.6 Rules
Rules are the actions that control the incoming and outgoing packets based on the defined hooks in a chain. If a rule inside a chain matches with a packet based on the stage derived from their hooks, the packet is dropped or accepted. A rule is evaluated from left to right in a way that when the first statement matches, it continues with the next parts of a rule, but if not, the next rule will be evaluated. The structure of a rule includes matches and statements which is as follows:
<matches><statements>
For example:
iifname “interface name” Policy: <accept or drop>
5.6.1 Matches
Matches are those filters that enable a rule to filter certain packets. Some important matches with their possible formats are briefly as follows:
Ip saddr <ip source address>
Ip daddr <ip destination address>
tcp / udp dport <destination port>
tcp / udp sport < source port>
tcp flags <flags>
ICMP type <type>
iifname <input interface name>
oifname <output interface name>
protocol <protocol>
5.6.2 Statements
A statement is the defined action performed once a packet matches a match(es) defined by a rule. Statemets comprise of verdict, log, and counter statements.
Verdict statements
Theverdict statementalters the control flow in the ruleset and issues policy decisions for packets. The valid verdict statements are:
accept: Accept the packet and stop the remaining rules evaluation.
drop: Drop the packet and stop the remaining rules evaluation.
queue: Queue the packet to userspace and stop the remaining rules evaluation.
continue: Continue the ruleset evaluation with the next rule.
jump <chain>: Continue at the first rule of <chain>. It will continue to evaluate the next rules to finally return to the last position or a return statement is issued.
return: Return from the current chain and continue at the next rule of the last chain. In a base chain, it is equivalent to accept
goto <chain>: Similar to jump, but after finishing the rules in <chain>, the evaluation will continue to evaluate the next chains instead of waiting for a return to the last chain.
6. Nftables configuration
There are three ways to define nftables modules:
1. Using nft command-line tools to create tables, chains, and rules, etc.
In this approach, once adding or editing a module, any changes apply immediately to the nftables file running into the memory.
To make all the changes permanent in the event of restarting the machine, the following command should be issued.
Nft list ruleset > /etc/nftables.conf
To make all the changes permanent in the event of restarting the service (nftables), the following command should be used.
Nft list ruleset > /root/nftables.conf
2. Using nftables.conf file to directly define tables, chains, and rules.
In this approach, after adding or editing a module and then saving the file, any changes will be saves into the nftables file inside the storage of a system and do not apply immediately to the nftables file running into the memory. To replace the old file running in the memory with the new one, the following commands must be issued.
Systemctl stop nftables
Systemctl start nftables
3. Creating a script to define tables, chains, and rules.
Creating an executable script has several merits over using other methods to create and maintain nftables elements. These are:
oThe atomic execution of a script file: meaning that if there is an error, the nftables prevent the execution of the whole file.
oAdd comments inside a script file to save in nftables.conf
oDefine variables inside a script file to save in nftables.conf
oInclude other ruleset files inside a script file to save in nftables.conf
6.1 Table
1. Creating tables by nft shell script:
To manage, create, and edit tables based on nft shell script, the following commands should be considered.
# [ ] = optinal options
# <family> = family address
% nft list tables
% nft list table [<family>] <name>
% nft (add | delete | flush) table [<family>] <name>
# Disable a table temporarily
% nft addtable [<family>] <name> flags dormant
# Make the table active again
% add table [<family>] <name>
2. Creating tables by Nftables.conf:
To create tables directly into the nftables.conf, the following scripts should be followed.
table [<family>] <name> {
chain <name>{
type filter hook input priority 0; policy drop;
} }
3. Creating tables by nftables script environment:
To create tables based on nftables script environment, the following commands that are similar to the previous model should be considered.
Note that, the script file should have .nft as its file format and must be executable to be executed by nftables. To run the file, the full address of the file should be run and then all the contents of the file will be added to nftables ruleset in case of no error.
#!/usr/sbin/nft -f
# Flush the rule set
flush ruleset
table [<family>] <name> {
chain <name>{
type filter hook input priority 0; policy drop;
} }
6.2 Chain
1. Creating chains by nft shell script:
1.1 To manage, create, and edit base chains based on nft shell script, the following commands should be followed.
% nft (add | create) chain <family> <table> <name> { type <type> hook <hook> priority <priority> \; policy <policy> \; }
# When defining ingress as a chain’s hook, defining a device is necessary!
% nft (add | create) chain <family> <table> <name> { type <type> hook ingress device <interface> priority <priority> \; policy <policy> \; }
% nft (delete | list | flush) chain <family> <table> <name>
% nft rename chain <family> <table> <name> <newname>
1.2 To manage, create, and edit non-base (Regular) chains based on nft shell script, the following commands should be followed. This chain doesnotmonitor any traffic since it is not attached to any hook, but it is useful to arrange the rule-set in a tree of chains using thejump to chainaction.
% nft add chain <family> <table-name> <chain-name>
# Create a rule to jump to a non-based chain when facing TCP packets
% nft add rule <family> <table-name> input ip protocol tcp jump <nonbased-chain-name>
# The structre after creating a non-based chain
table ip table-name {
chain input {
type filter hook input priority 0;
ip protocol tcp jump nonbased-chain-name
}
chain nonbased-chain-name {
} }
2. Creating chains by nftables.conf:
table ip table-name {
chain <chain-name1> {
type <type> hook <hook> priority <priority>; policy <policy>;
rule1 ...
rule2 ...
}
chain <chain-name2> {
type <type> hook <hook> priority <priority>; policy <policy>;
rule1 ...
rule2 ...
} }
6.3 rules
....
To have the complete version of this article providing you with more detailed information and advanced features of nftables, please refer to easillyy.com. This article can be also subject to edit and rectify.
References
http://easillyy.com/a-comprehensive-guide-to-nftables/
Netfilter. (2014). What is netfilter? https://www.netfilter.org/
Nftables wiki. (2017). What is nftable? https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F
Nftables wiki. (2016). Main differences with iptables. https://wiki.nftables.org/wiki-nftables/index.php/Main_differences_with_iptables
Netfilter. (2019). Netfilter hooks. https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
