Publication du filtre de paquets nftables 0.9.4

Publié publication du filtre de paquets nftables 0.9.4, se développant comme un remplacement d'iptables, ip6tables, arptables et ebtables grâce à l'unification des interfaces de filtrage de paquets pour IPv4, IPv6, ARP et les ponts réseau. Le paquet nftables comprend des composants de filtrage de paquets fonctionnant en espace utilisateur, tandis qu'au niveau du noyau, le fonctionnement est assuré par le sous-système nf_tables, intégré dans le noyau Linux depuis la version 3.13. Les modifications nécessaires au fonctionnement de la version nftables 0.9.4 sont incluses dans la future branche du noyau. Linux 5.6.

Au niveau du noyau, un seul interface général est fourni, sans dépendance à un protocole spécifique, offrant des fonctions de base pour extraire des données des paquets, effectuer des opérations sur les données et gérer le flux. Les règles de filtrage spécifiques et les gestionnaires de 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 le noyau dans une machine virtuelle spéciale, ressemblant à 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 déporter toutes les fonctions d'analyse des règles et de logique de traitement des protocoles en espace utilisateur.

Les principales nouveautés :

• La prise en charge des plages dans les connexions (concatenation, groupes d'adresses et de ports, facilitant les correspondances). Par exemple, pour un ensemble «whitelist», dont les éléments sont des connexions, l'indication du drapeau «interval» indiquera que l'ensemble peut inclure des plages dans la connexion (pour la connexion «ipv4_addr . ipv4_addr . inet_service», il était auparavant nécessaire de lister des correspondances exactes telles que «192.168.10.35 . 192.68.11.123 . 80», mais maintenant il est possible d'indiquer des groupes d'adresses «192.168.10.35-192.168.10.40 . 192.68.11.123-192.168.11.125 . 80») :

  table ip foo {
  set whitelist {
  type ipv4_addr . ipv4_addr . inet_service
  flags interval
  elements = { 192.168.10.35-192.168.10.40 . 192.68.11.123-192.168.11.125 . 80 }
  }

  chain bar {
  type filter hook prerouting priority filter; policy drop;
  ip saddr . ip daddr . tcp dport @whitelist accept
  }
  }

• Dans les ensembles et les listes de map, il est possible d'utiliser la directive «typeof», qui détermine le format de l'élément lors de la correspondance.
  Par exemple :

  table ip foo {
  set whitelist {
  typeof ip saddr
  elements = { 192.168.10.35, 192.168.10.101, 192.168.10.135 }
  }

  chain bar {
  type filter hook prerouting priority filter; policy drop;
  ip daddr @whitelist accept
  }
  }

  table ip foo {
  map addr2mark {
  typeof ip saddr : meta mark
  elements = { 192.168.10.35 : 0x00000001, 192.168.10.135 : 0x00000002 }
  }
  }

• Ajout de la possibilité d'utiliser des connexions dans les liaisons NAT, ce qui permet de spécifier l'adresse et le port lors de la définition des transformations NAT basées sur des listes de mappage ou des ensembles nommés :

  nft add rule ip nat pre dnat ip addr . port to ip saddr map { 1.1.1.1 : 2.2.2.2 . 30 }

  nft add map ip nat destinations { type ipv4_addr . inet_service : ipv4_addr . inet_service \\; }
  nft add rule ip nat pre dnat ip addr . port to ip saddr . tcp dport map @destinations

• Prise en charge de l'accélération matérielle avec le déchargement de certaines opérations de filtrage sur la carte réseau. L'accélération est activée via l'outil ethtool (« ethtool -K eth0 hw-tc-offload on »), après quoi elle est activée dans nftables pour la chaîne principale à l'aide du drapeau « offload ». Avec le noyau Linux 5.6, l'accélération matérielle est prise en charge pour la correspondance des champs d'en-tête et la vérification de l'interface entrante en combinaison avec la réception, le rejet, la duplication (dup) et le redirection (fwd) de paquets. Dans l'exemple ci-dessous, les opérations de rejet des paquets provenant de l'adresse 192.168.30.20 sont effectuées au niveau de la carte réseau, sans transmission de paquets au noyau :

  # cat file.nft
  table netdev x {
  chaîne y {
  type filter hook ingress device eth0 priority 10; flags offload;
  ip saddr 192.168.30.20 drop
  }
  }
  # nft -f file.nft

• Amélioration de l'information sur l'emplacement de l'erreur dans les règles.

  # nft delete rule ip y z handle 7
  Erreur : Impossible de traiter la règle : Aucun fichier ou répertoire de ce type
  delete rule ip y z handle 7
  ^

  # nft delete rule ip x x handle 7
  Erreur : Impossible de traiter la règle : Aucun fichier ou répertoire de ce type
  delete rule ip x x handle 7
  ^

  # nft delete table twst
  Erreur : Aucun fichier ou répertoire de ce type ; vouliez-vous dire table 'test' dans la famille ip ?
  delete table twst
  ^^^^

  Dans le premier exemple, il est montré que la table « y » est absente du système, dans le second, qu'il manque le gestionnaire « 7 », et dans le troisième, qu'un indice sur une faute de frappe est affiché lors de la saisie du nom de la table.

• Ajout de la prise en charge de la vérification de l'interface esclave via la spécification « meta sdif » ou « meta sdifname » :

  … meta sdifname vrf1 …

• Ajout de la prise en charge de l'opération de décalage à droite ou à gauche. Par exemple, pour décaler une étiquette de paquet existante à gauche de 1 bit et définir le bit inférieur à 1 :

  … meta mark set meta mark lshift 1 or 0x1 …

• Option « -V » mise en œuvre pour afficher des informations détaillées sur la version.

  # nft -V
  nftables v0.9.4 (Jive at Five)
  cli : readline
  json : yes
  minigmp : no
  libxtables : yes

• Les options de ligne de commande doivent désormais être spécifiées avant les commandes. Par exemple, vous devez spécifier « nft -a list ruleset », et exécuter « nft list ruleset -a » entraînera une erreur.

  Source : opennet.ru