networking:nftables
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| networking:nftables [2023/09/03 08:41] – oscar | networking:nftables [2023/09/03 17:35] (current) – [Links] oscar | ||
|---|---|---|---|
| Line 41: | Line 41: | ||
| 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. | 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 | + | <code> |
| + | table [<family>] <name> { | ||
| + | chain < | ||
| + | |||
| + | type < | ||
| + | |||
| + | } } | ||
| + | </ | ||
| ==== Chains Types ==== | ==== Chains Types ==== | ||
| ^Type^Description^ | ^Type^Description^ | ||
| Line 80: | Line 87: | ||
| nft create chain ip myfilter bar {type filter hook input priority security\;} | nft create chain ip myfilter bar {type filter hook input priority security\;} | ||
| </ | </ | ||
| - | |||
| ==== Policies ==== | ==== 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”**, | 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”**, | ||
| + | |||
| + | ===== 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: | ||
| + | < | ||
| + | < | ||
| + | |||
| + | For example: | ||
| + | |||
| + | iifname “interface name” Policy: <accept or drop> | ||
| + | </ | ||
| + | |||
| + | ==== 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 < | ||
| + | tcp / udp sport < source port> | ||
| + | tcp flags < | ||
| + | ICMP type < | ||
| + | iifname <input interface name> | ||
| + | oifname <output interface name> | ||
| + | protocol < | ||
| + | </ | ||
| + | |||
| + | ==== 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 < | ||
| + | |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 < | ||
| + | |||
| + | ===== 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 ===== | ===== Links ===== | ||
| * [[https:// | * [[https:// | ||
| + | * [[https:// | ||
| + | * [[https:// | ||
networking/nftables.1693730503.txt.gz · Last modified: by oscar
