From e1d2f892c8528ad9039733c098972c1a2228eb3d Mon Sep 17 00:00:00 2001 From: Amrita Sakthivel Date: Mon, 19 Aug 2024 16:12:35 +0530 Subject: [PATCH] DOCTEAM-1225: adds nftables section (#1731) * adds nftables section * adds content * more content * adds config file example * config file examples * more example content * final self review changes * partial feedback * more review feedback * review feedback * review feedback * grammar * peer review-part1 * peer review --- xml/security_firewall.xml | 168 +++++++++++++++++++++++++++++++++++++- 1 file changed, 167 insertions(+), 1 deletion(-) diff --git a/xml/security_firewall.xml b/xml/security_firewall.xml index d78c1f90f2..1107c8585c 100644 --- a/xml/security_firewall.xml +++ b/xml/security_firewall.xml @@ -960,7 +960,173 @@ nfs-rpc firewall-rpc-helper.py --help. - + + nftables as the default back-end + + The default back-end for &firewalld; is nftables. nftables is a framework by the Linux netfilter project + that provides packet filtering, network address translation (NAT) and other similar functionalities. nftables reuses the existing Netfilter + subsystems such as the connection tracking system, user space queueing, logging and the hook infrastructure. + nftables is a replacement for iptables, ip6tables, arptables, ebtables, and ipset. + + + The advantages of using nftables include: + + + + + One framework for both the IPv4 and IPv6 protocols. + + + + + Rules are applied atomically instead of fetching, updating and storing a complete rule set. + + + + + Monitor trace events in the nft tool, debug and trace the ruleset via nftrace. + + + + + The nft command line tool compiles into VM bytecode in netlink format. + During the rule set retrieval, the VM bytecode in netlink format is translated back into the original ruleset representation. + + + + A basic nftables configuration file: + &prompt.user; cat /etc/nftables.conf + #!/usr/sbin/nft -f + + flush ruleset + + # This matches IPv4 and IPv6 + table inet filter { + # chain names are up to you. + # what part of the traffic they cover, + # depends on the type table. + chain input { + type filter hook input priority 0; policy accept; + } + chain forward { + type filter hook forward priority 0; policy accept; + } + chain output { + type filter hook output priority 0; policy accept; + } + } + + In the above example, all traffic is allowed because all chains have the policy accept. + Note that, in reality, this is a bad practice, as firewalls should deny traffic by default. + A basic nftables configuration file with masquerade: + &prompt.user; cat /etc/nftables.conf + #!/sbin/nft -f + + flush ruleset + + table ip nat { + chain prerouting { + type nat hook prerouting priority 0; policy accept; + } + + # for all packets to WAN, after routing, replace source address with primary IP of WAN interface + chain postrouting { + type nat hook postrouting priority 100; policy accept; + oifname "wan0" masquerade + } + } + + If you have a static IP, it would be slightly faster to use source nat (SNAT) instead of masquerade. + The router replaces the source with a predefined IP instead of looking up the outgoing IP for every packet. + An nftables configuration file with some rules applied: + &prompt.user; cat /etc/nftables.conf + #!/usr/sbin/nft -f + +flush ruleset + +table inet filter { + chain base_checks { + ## another set, this time for connection tracking states. + # allow established/related connections + ct state {established, related} accept; + + # early drop of invalid connections + ct state invalid drop; + } + + chain input { + type filter hook input priority 0; policy drop; + + # allow from loopback + iif "lo" accept; + + jump base_checks; + + # allow icmp and igmp + ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, packet-too-big, time-exceeded, parameter-problem, destination-unreachable, packet-too-big, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept; + ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept; + ip protocol igmp accept; + + # for testing reject with logging + counter log prefix "[nftables] input reject " reject; + } + chain forward { + type filter hook forward priority 0; policy accept; + } + chain output { + type filter hook output priority 0; policy accept; + } +} + + In the above example: + + + + The chain policy is to drop and add a reject rule at the end, which means all incoming traffic is blocked. + + + + + All traffic on the localhost interface is allowed. + + + + + The base_checks chain handles all packets that are related to established connections. + This ensures that incoming packets for outgoing connections are not blocked. + + + + + ICMP and IGMP packets are allowed by utilizing a set and specific type names. + + + + + A counter keeps a count of both the total number of packets and bytes it has seen since it was last reset. + With nftables, you must specify a counter for each rule you want to count. + + + + + More information + For more information about nftables, see: + + + + Upstream documentation + + + + + nftables man page + + + + + + +