publication du filtre de paquets , qui se développe comme une alternative à iptables, ip6table, arptables et ebtables grâce à l'unification des interfaces de filtrage des paquets pour IPv4, IPv6, ARP et les ponts réseaux. Le paquet nftables comprend des composants de filtrage de paquets fonctionnant en espace utilisateur, tandis qu'au niveau du noyau, le travail est assuré par le sous-système nf_tables, inclus dans le noyau Linux depuis la version 3.13. Les modifications nécessaires pour le fonctionnement de la version nftables 0.9.2 sont comprises dans le noyau Linux 5.3.
Au niveau du noyau, seule une interface générale, indépendante du protocole spécifique, est fournie, offrant des fonctions de base pour l'extraction de données à partir de paquets, l'exécution d'opérations sur les données et la gestion du flux. La logique de filtrage et les gestionnaires spécifiques aux protocoles sont compilés en bytecode en espace utilisateur, après quoi ce bytecode est chargé dans le noyau via l'interface Netlink et exécuté dans une machine virtuelle spéciale, similaire à BPF (Berkeley Packet Filters). Cette approche permet de réduire considérablement la taille du code de filtrage qui fonctionne au niveau du noyau et d'externaliser toutes les fonctions d'analyse des règles et de logique de travail avec les protocoles en espace utilisateur.
Les principales nouveautés :
- La possibilité de vérifier le numéro de port à partir de l'en-tête de paquet de la couche de transport, indépendamment du type de protocole de la couche 4 :
add rule x y ip protocol { tcp, udp } th dport 53
- Prise en charge de la récupération de la durée de vie d'un ensemble d'éléments :
add element ip x y { 1.1.1.1 timeout 30s expires 15s }
- Possibilité de vérifier des options individuelles (lsrr, rr, ssrr et ra) dans les paquets IPv4 :
add rule x y ip option rr exists drop
Pour les options de routage, il est possible de vérifier les champs type, ptr, length et addr :
add rule x y ip option rr type 1 drop
- Dans les expressions, il est désormais permis de spécifier des préfixes réseau et des plages d'adresses :
iifname ens3 snat to 10.0.0.0/28
iifname ens3 snat to 10.0.0.1-10.0.0.15 - Prise en charge de l'utilisation de variables dans les définitions de chaînes :
define default_policy = accept
add chain ip foo bar { type filter hook input priority filter; policy $default_policy } - La spécification de la priorité de la chaîne peut désormais se faire à la fois sous forme numérique et symbolique :
define prio = filter
define prionum = 10
define prioffset = «filter — 150»add table ip foo
add chain ip foo bar { type filter hook input priority $prio; }
add chain ip foo ber { type filter hook input priority $prionum; }
add chain ip foo bor { type filter hook input priority $prioffset; } - Prise en charge du module synproxy. Par exemple, pour protéger le port TCP 8888 avec synproxy, vous pouvez utiliser un ensemble de règles :
table ip x {
chaîne y {
type filter hook prerouting priority raw; policy accept;
tcp dport 8888 tcp flags syn notrack
}chaîne z {
type filter hook forward priority filter; policy accept;
tcp dport 8888 ct state invalid,untracked synproxy mss 1460 \
wscale 7 timestamp sack-perm ct state invalid drop
}
} - Pour déterminer dans la table conntrack les connexions supplémentaires attendues associées à la connexion actuelle, qui sont appliquées dans les protocoles et scénarios nécessitant l'établissement de plusieurs connexions, il est maintenant possible de définir des politiques via les ensembles de règles standards. Par exemple, pour définir les connexions attendues suite à une connexion au port TCP 8888, pour celles visant le port 5432, vous pouvez spécifier les règles suivantes :
table x {
ct expectation myexpect {
protocol tcp
dport 5432
timeout 1h
size 12
l3proto ip
}chain input {
type filter hook input priority 0;
ct state new tcp dport 8888 ct expectation set myexpect
ct state established,related counter accept
}
}
Source : opennet.ru
