Differences

This shows you the differences between two versions of the page.

--- networking:nftables [2023/09/03 07:56] – oscar
+++ networking:nftables [2023/09/03 17:35] (current) – [Links] oscar
@@ Line 9: / Line 9: @@
 ===== 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:
+^Family^Description^
 |ip:|IPv4 address family.|
 |ip6:|IPv6 address family.|
@@ Line 19: / Line 20: @@
 {{ :networking:nf-hooks-detailed.png?500 |}}
-===== Priority =====
+===== Variables =====
+Repetition is bad. To simplify things, nftables supports variables. Instead of repeating an interface multiple times, you define it at the beginning of your configuration file. After that, you will be using the variable. Example: defining interfaces.
+<code>
+define ext_if = eth0
+define int_if = eth1
+define all_if = { $ext_if, $int_if }
+</code>
+===== Tables =====
+Within the configuration of nftables, a table is at the top of the ruleset. It consists of chains, which are containers for rules. **Overview: Tables –> Chains –> Rules**.
+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, in this case “inet”, and then it is followed by its defined name that is “table1” with an open and a close curly bracket.
+{{ :networking:nf-table-structure.jpg?500 |}}
+===== Chains =====
+Chains are a container of rules and are located inside a table. Chains have two types.
+  * A base chain is an entry point for packets from the networking stack, where a hook value is specified.
+  * A regular chain is a chain that is used for organization of chains and has no hook hence no control on packets. It may be used as a jump target for better organization.
+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.
+<code>
+table [<family>] <name> {
+ chain <chain-name> {
+   type <filter-type> hook <hook> priority <priority>; policy <policy>;
+ } }
+</code>
+==== Chains Types ====
+^Type^Description^
+|Filter|This is a standard chain type and supports all address families namely ARP, bridge, IP, IP6, and inet 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 IP and IPv6 address families. prerouting, input, output, postrouting hooks are also supported.|
+==== 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 support IP, IPv6, and inet address families. To support arp address family, input, output hooks can be used while for netdev family, ingress hook should be used.
+^Type^Description^
+|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 the netdev family): 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.|
+==== Priority ====
 Nftables requires you to specify a priority value when creating a base chain. You can specify integer values, but the newer versions of Nftables also define placeholder names for several discrete priority values analog to the mentioned enums in Netfilter. The following table lists those placeholder names12).
 ^Name 	^Priority Value^
@@ Line 41: / Line 88: @@
 </code>
-===== Variables =====
+==== Policies ====
-Repetition is bad. To simplify things, nftables supports variables. Instead of repeating an interface multiple times, you define it at the beginning of your configuration file. After that, you will be using the variable. Example: defining interfaces.
+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.
+===== 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:
 <code>
-define ext_if = eth0
+<matches> <statements>
-define int_if = eth1
-define all_if = { $ext_if, $int_if }
+For example:
+iifname “interface name” Policy: <accept or drop>
 </code>
+==== Matches ====
+Matches are those filters that enable a rule to filter certain packets. Some important matches with their possible formats are briefly as follows:
+<code>
+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>
+</code>
+==== Statements ====
+A statement is the defined action performed once a packet matches a match(es) defined by a rule. Statements comprise of verdict, log, and counter statements.
+=== Verdict statements ===
+The verdict statement alters the control flow in the rule set and issues policy decisions for packets. The valid verdict statements are:
+^Statement^Description^
+|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.|
+===== Query Commands =====
+=== Ruleset ===
+Current ruleset can be printed with:
+  # nft list ruleset
+Remove all ruleset leaving the system with no firewall:
+  # nft flush ruleset
+=== Tables ===
+To list all tables:
+  # nft list tables
+List chains and rules in a table. To list all chains and rules of a specified table:
+  # nft list table family_type table_name
+To delete a table. This will destroy all chains in the table:
+  # nft delete table family_type table_name
+Flush table
+To flush/clear all rules from a table:
+  # nft flush table family_type table_name
+List rules
+The following lists all rules of a chain:
+  # nft list chain family_type table_name chain_name
+Delete a chain. To delete a chain, the chain must not contain any rules or be a jump target.
+:
+  # nft delete chain family_type table_name chain_name
+Flush rules from a chain:
+  # nft flush chain family_type table_name chain_name
 ===== Links =====
   * [[https://wiki.nftables.org/wiki-nftables/index.php/Main_Page|wiki.nftables.org]]
+  * [[https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes|Quick Reference]]
+  * [[https://wiki.archlinux.org/title/nftables|ArchLinux-nftables]]