La version 1.0.6 du filtre de paquets nftables a été publiée, unifiant les interfaces de filtrage des paquets pour IPv4, IPv6, ARP et les ponts réseau (visant à remplacer iptables, ip6tables, arptables et ebtables). Le paquet nftables comprend des composants de filtrage de paquets fonctionnant dans l'espace utilisateur, tandis qu'au niveau du noyau, la fonction est assurée par le sous-système nf_tables, intégré au noyau Linux depuis la version 3.13. Au niveau du noyau, seule une interface générale est fournie, qui ne dépend pas d'un protocole spécifique et offre des fonctions de base pour extraire des données des paquets, exécuter des opérations sur les données et gérer le flux.
Les règles de filtrage et les gestionnaires spécifiques aux protocoles sont compilés en bytecode dans l'espace utilisateur, après quoi ce bytecode est chargé dans le noyau via l'interface Netlink et exécuté dans le noyau dans une structure spéciale une machine virtuelle, similaire aux BPF (Berkeley Packet Filters). Cette approche permet de réduire considérablement la taille du code de filtrage fonctionnant au niveau du noyau et de transférer toutes les fonctions de parsing des règles et de logique de traitement des protocoles dans l'espace utilisateur.
Principales modifications :
- Dans l'optimiseur de règles, appelé avec l'option « -o/--optimize », l'emballage automatique des règles est établi par leur fusion et leur transformation en listes map et set. Par exemple, les règles # cat ruleset.nft table ip x { chain y { type filter hook input priority filter; policy drop; meta iifname eth1 ip saddr 1.1.1.1 ip daddr 2.2.2.3 accept meta iifname eth1 ip saddr 1.1.1.2 ip daddr 2.2.2.4 accept meta iifname eth1 ip saddr 1.1.1.2 ip daddr 2.2.3.0/24 accept meta iifname eth1 ip saddr 1.1.1.2 ip daddr 2.2.4.0-2.2.4.10 accept meta iifname eth2 ip saddr 1.1.1.3 ip daddr 2.2.2.5 accept } } après l'exécution de « nft -o -c -f ruleset.nft » seront transformées comme suit : ruleset.nft:4:17-74: meta iifname eth1 ip saddr 1.1.1.1 ip daddr 2.2.2.3 accept ruleset.nft:5:17-74: meta iifname eth1 ip saddr 1.1.1.2 ip daddr 2.2.2.4 accept ruleset.nft:6:17-77: meta iifname eth1 ip saddr 1.1.1.2 ip daddr 2.2.3.0/24 accept ruleset.nft:7:17-83: meta iifname eth1 ip saddr 1.1.1.2 ip daddr 2.2.4.0-2.2.4.10 accept ruleset.nft:8:17-74: meta iifname eth2 ip saddr 1.1.1.3 ip daddr 2.2.2.5 accept devenu : iifname . ip saddr . ip daddr { eth1 . 1.1.1.1 . 2.2.2.3, eth1 . 1.1.1.2 . 2.2.2.4, eth1 . 1.1.1.2 . 2.2.3.0/24, eth1 . 1.1.1.2 . 2.2.4.0-2.2.4.10, eth2 . 1.1.1.3 . 2.2.2.5 } accept
- L'optimiseur peut également convertir en une forme plus compacte des règles qui utilisent déjà des listes de sets simples, par exemple les règles : # cat ruleset.nft table ip filter { chain input { type filter hook input priority filter; policy drop; iifname «lo» accept ct state established,related accept comment «Dans le trafic que nous générons, nous avons confiance» iifname «enp0s31f6» ip saddr { 209.115.181.102, 216.197.228.230 } ip daddr 10.0.0.149 udp sport 123 udp dport 32768-65535 accept iifname «enp0s31f6» ip saddr { 64.59.144.17, 64.59.150.133 } ip daddr 10.0.0.149 udp sport 53 udp dport 32768-65535 accept } } Après l'exécution de «nft -o -c -f ruleset.nft», elles seront regroupées comme suit : ruleset.nft:6:22-149: iifname «enp0s31f6» ip saddr { 209.115.181.102, 216.197.228.230 } ip daddr 10.0.0.149 udp sport 123 udp dport 32768-65535 accept ruleset.nft:7:22-143: iifname «enp0s31f6» ip saddr { 64.59.144.17, 64.59.150.133 } ip daddr 10.0.0.149 udp sport 53 udp dport 32768-65535 accept en : iifname . ip saddr . ip daddr . udp sport . udp dport { enp0s31f6 . 209.115.181.102 . 10.0.0.149 . 123 . 32768-65535, enp0s31f6 . 216.197.228.230 . 10.0.0.149 . 123 . 32768-65535, enp0s31f6 . 64.59.144.17 . 10.0.0.149 . 53 . 32768-65535, enp0s31f6 . 64.59.150.133 . 10.0.0.149 . 53 . 32768-65535 } accept
- Le problème de génération de bytecode pour la fusion d'intervalles utilisant des types avec un ordre d'octets différent, comme IPv4 (ordre d'octets en réseau) et meta mark (ordre d'octets système), a été résolu. table ip x { map w { typeof ip saddr . meta mark : verdict flags interval counter elements = { 127.0.0.1-127.0.0.4 . 0x123434-0xb00122 : accept, 192.168.0.10-192.168.1.20 . 0x0000aa00-0x0000aaff : accept, } } chain k { type filter hook input priority filter; policy drop; ip saddr . meta mark vmap @w } }
- Des mappages de protocoles rares ont été établis lors de l'utilisation d'expressions brutes, par exemple : meta l4proto 91 @th,400,16 0x0 accept
- Les problèmes d'insertion de règles avec des intervalles ont été résolus : insert rule x y tcp sport { 3478-3497, 16384-16387 } counter accept
- L'API JSON a été améliorée, avec le support d'expressions dans les listes set- et map-.
- Dans les extensions de la bibliothèque python nftables, le chargement de sets de règles pour traitement en mode vérification («-c») a été autorisé et un support pour la définition externe de variables a été ajouté.
- L'ajout de commentaires a été autorisé dans les éléments des listes set.
- Dans la limite de débit par byte, la spécification d'une valeur nulle a été autorisée.
Source : opennet.ru
