TOOLinux

Le journal du Libre

Nftables, successeur potentiel à Iptables

lundi 14 septembre 2009

L’objectif est de remplacer le pare-feu existant, avec un fonctionnement revu en profondeur. Les premières releases alpha de la bibliothèque libnl-nft, de l’outil en espace utilisateur nftables et des sources du noyau nft-2.6 ont été annoncées sur la liste de diffusion linux-netdev en Mars 2009.


Un peu d’histoire

Les mécanismes de filtrage réseau ont toujours existé sur Linux. Le premier s’appelait ipfwadm, largement inspiré d’ipfw des systèmes BSD et il fut publié en 1995 sur un noyau encore très jeune : la version 1.2.1. En 1999, Ipchains a été intégré à la branche 2.2 du noyau et c’est en janvier 2001 qu’il a été remplacé par le fameux Iptables dans la branche 2.4. Aujourd’hui le projet Netfilter regroupe donc à la fois Iptables, et son challenger Nftables.

Les objectifs

Voici les principaux objectifs qui motivent le passage à Nftables :

  • Une simplification de l’ABI (Application Binary Interface) système,
  • Homogénéisation du fonctionnement afin de réduire la duplication de code et ainsi réduire sa maintenance,
  • Une gestion des erreurs améliorées,
  • Une éxecution, un stockage et des changements incrémenciels des rêgles de filtrage plus efficaces.

Architecture

La version actuelle du pare-feu (Iptables) a une connaissance détaillée de nombreux protocoles. On trouve ainsi des modules dédiés pour les protocoles TCP ou UDP non optimum, i.e. les deux implémentent indépendament des concepts identiques tel que la gestion du numéro de port. Avec l’implémentation de Nftables, le noyau n’a plus connaissance d’un protocole en particulier. En effet, le pare-feu est représenté par une simple machine virtuelle. Celle-ci fournit entre autre des opérateurs de comparaisons et d’incrémentation, ainsi que des structures de set qui permettent des rêgles multi-branch et un registre spécial appelé verdict. Elle inclut aussi un mécanisme de suivi des connections et des opérations basique d’extraction de méta-informations sur les paquets comme leur taille ou le type de protocole.

Rassurez-vous, l’administrateur réseau ne devrait pas avoir à manipuler ce langage bas-niveau, la bibliothèque nl-nft et l’outil associé nft s’occupera pour eux de convertir des rêgles simples dans les opcodes correspondants. Les instructions sont envoyées ensuite via une interface netlink. Le langage de classification est quant à lui basé sur une vraie grammaire.

Différences majeures

Voici les principales innovations noyau :

  • Indépendant des familles de protocoles.
  • Changements incrémentiels supporté, ce qui permet une édition plus granulaire des rêgles.
  • Un strict minimum de verrou logiciel (lock).
  • Pas de tables par défault.
  • Le code kernel est minimal et les erreurs de syntax sont gérées en espace utilisateur.

Au niveau de la création des règles :

  • Des briques de bases simples.
  • Des structures de données tel que des sets ou dictionnaires.
  • Une détection des conflits.
  • Génération des dépendances : cela permet d’écrire des règles supportant à la fois ipv4 et ipv6.

L’écriture du pare-feu typique d’un poste client, n’autorisant en entrée que les connexions déjà établies et celles à destination du service d’administration distant se résumera à :

# ! nft -f
add table filter
add chain filter input 
        ct state established,related accept
        tcp dport 22 accept
        counter drop

Pour conclure, la transition vers ce nouveau système peut être intéressante mais présente de nombreux inconvénients. Les deux systèmes n’ayant rien en commun, l’écriture d’outils de migration sera un exercice périlleux. La communauté des développeurs attendra de très bon résultats avant d’infliger un tel changement à ses utilisateurs, et cela peut prendre un certain temps.

Tristan Cacqueray