A l'occasion de l'annonce de la prochaine édition du Kernel Recipes qui aura lieu les 29, 30 septembre et 1er octobre, InfoQ revient sur l'édition de 2014, durant laquelle nous avons pu rencontrer Eric Leblond qui a présenté un sujet sur nftables.
InfoQ FR : Bonjour Eric et merci de répondre à nos questions sur nftables. Peux-tu te présenter ?
Eric Leblond : J'ai un profil assez mixte car je suis à la fois développeur et chef d'entreprise. J'ai commencé à travailler sur le projet NetFilter en tant qu'utilisateur vers 2002, et j'ai rejoint la communauté des développeurs en 2005. Depuis 2012, je suis membre de la core team NetFilter, l'équipe dirigeante de NetFilter. Je travaille aussi sur le projet Suricata qui est un outil de détection d'intrusion open-source.
InfoQ FR : Tu as fait aujourd'hui une présentation sur nftables, travailles-tu également dessus ?
Eric Leblond : En travaillant sur NetFilter, il m'arrive de faire un peu de hacking sur nftables. Mais je ne suis pas un des développeurs principaux, je suis le développement et j'envoie des patchs quand je l'utilise. Et je suis le mainteneur officiel d'ulogd, la couche de journalisation de NetFilter. C'est elle qui fait le lien entre les messages envoyés par le noyau et un stockage dans différents médias ; cela va de simples fichiers textes à des bases de données.
InfoQ FR : Et à quoi sert nftables ?
Eric Leblond : En 2002, on a eu l'arrivée d'iptables qui succédait à ipchains, et iptables a commencé à prendre beaucoup de place en volume de code. Les griefs se sont accumulés contre iptables sur des problèmes de conception, conception qui après dix ans n'était plus aussi moderne qu'à son démarrage. Un des pires problèmes de conception parmi ceux remontés est pour les développeurs la problématique de la duplication du code.
Comme je l'expliquais ce matin dans ma présentation, pour faire un même filtrage sur deux protocoles similaires, il fallait complètement dupliquer le code. Il n'y a aucune mise en commun de code. Cette absence de mise en commun rendait le code noyau long et plutôt complexe.
De plus, toute nouvelle fonctionnalité (filtre par exemple) supposait du code noyau et du code utilisateur. Une nouvelle fonctionnalité était donc difficile à faire accepter avec un temps de réaction de moins de six mois, ou deux mois et demi avec le nouveau rythme de release du noyau linux. A condition de ne pas manquer la fenêtre de tir pour pousser la mise à jour. Il était donc très long de faire entrer de nouvelles fonctionnalités. Cela exigeait du code noyau et du code en espace utilisateur qui étaient assez complexes à chaque fois.
Pour lutter contre cela, Patrick McHardy en 2008 a lancé le projet nftables qui visait à lever pour la fonctionnalité de filtrage cette dépendance au protocole. On avait quelque chose de beaucoup plus flexible avec l'essentiel du travail effectué en espace utilisateur, alors que du côté du noyau, on se restreignait au minimum en fonctionnalités.
InfoQ FR : Nftables est assez mature pour de la production ?
Eric Leblond : Alors, je pense qu'il est stable mais il manque certaines fonctionnalités essentielles. La principale pour moi est l'import/export. On est à l'heure actuelle capable d'exporter un jeu de règles en une seule commande. Un jeu de règles comportant les éléments fixes et variables comme les ensembles. Mais par contre, la partie importation n'est pas encore opérationnelle. Une fois qu'elle le sera, on aura quelque chose d'à peu près complet. Et je pense qu'il manque aussi quelques petits points, qui s'ils ne vous manquent pas rendent nftables utilisable.
InfoQ FR : Si j'ai déjà un existant iptables, puis-je migrer automatiquement pour passer à nftables, ou bien dois-je réécrire les règles ? Les deux peuvent-ils cohabiter ?
Eric Leblond : A l'heure actuelle, iptables et nftables sont deux solutions de filtrage qui utilisent toutes les deux ce qu'on appelle des hooks Netfilter, à savoir des points d'ancrage dans le code. Et ils se branchent sur les hooks en utilisant exactement la même technique. Donc il est possible d'avoir des chaînes iptables déjà présentes et d'ajouter des fonctionnalités de filtrage avec nftables. Cela va de paire avec une autre possibilité qui est d'utiliser la compatibilité d'iptables avec nftables, à savoir que les nouvelles versions d'iptables ont été développées de manière à offrir une compatibilité. C'est à dire qu'on va pouvoir lancer des commandes iptables, typiquement dans un script, qui vont de manière transparente pour l'utilisateur parler le langage nftables, pour arriver au niveau du noyau dans nftables.
InfoQ FR : Avec la fonction d'export, on pourrait convertir des règles iptables en nftables grâce à ce mécanisme ?
Eric Leblond : Je ne crois pas avoir testé, mais ce qu'on peut envisager comme méthode de migration serait de lancer son script avec le binaire iptables compatible nftables, qui va générer des règles nftables. A partir de là, on doit pouvoir récupérer ces règles dans nftables.
Mais il faut prendre en compte le gain de puissance de nftables, notamment avec la gestion des ensembles. Nftables est également capable de journaliser et accepter un paquet dans la même règle, là où iptables nécessite deux règles distinctes. Et donc tout ce travail de factorisation sera à la charge de l'utilisateur. On peut donc faire un premier jet de migration avec cette méthode, et repasser dessus avec un éditeur et des fonctions avancées de remplacement ou envisager des scripts un peu plus complexes.
InfoQ FR : Nftables utilise un langage intermédiaire, de type assembleur. Ne serait-il pas possible d'optimiser ces règles brutes avec des techniques classiques de manipulation d'AST ou de détection d'isomorphismes ?
Eric Leblond : On peut effectivement envisager de faire des optimisations de type compilateur pour faire des transformations et travailler sur ce langage. On peut envisager de fusionner deux entrées successives par exemple, et voir que si seul le verdict change, alors on peut cumuler les deux verdicts.
InfoQ FR : Personne n'a pensé aux isomorphismes jusqu'ici ?
Eric Leblond : Si, cela a été pensé mais pas tellement discuté puisque tout le monde est occupé à travailler sur la finition des fonctions de base ! Le plus bel isomorphe qui risque d'arriver, c'est l'optimisation d'un jeu de règles complet (je l'espère cette année, sinon l'année prochaine). Cela consiste à implémenter un algorithme similaire à celui de nf-HiPAC, et qui fait justement un isomorphisme assez complexe puisque cela va transformer un jeu de règles linéaire en un système de recherche d'un point dans un hyper-espace. Parce qu'en fait, en mettant bout-à-bout l'IP source, l'IP de destination, le port source et le port de destination, on a déjà un espace à quatre dimensions. Et donc une règle de filtrage, finalement, c'est savoir dans quel hyper-cube correspondant à la règle, un point se trouve. Et même en ajoutant des dimensions, c'est plus rapide. Car au lieu d'avoir une approche séquentielle, on se retrouve avec une recherche qui fait juste du calcul d'intervalles.
InfoQ FR : Quelles sont les prochaines étapes pour nftables ?
Eric Leblond : Les prochaines étapes vont tout simplement être de terminer ce qui manque pour que ce soit utilisable, comme l'import/export. Ainsi que de la documentation qui est incomplète à l'heure actuelle. Par exemple, certaines options ne sont pas documentées du tout et il faut lire le parser pour savoir comment les utiliser. Il y a donc un effort de documentation mais tout le monde est la bienvenue. Vous pouvez commencer à jouer avec et aller sur le canal IRC #netfilter sur Freenode pour poser des questions si vous avez des problèmes. Et si vous le voulez, vous pouvez demander une création de compte. Une fois que l'on connaît les personnes, on peut leur ouvrir un compte sur le wiki de nftables pour y contribuer et enrichir la documentation.
InfoQ FR : Et donc on trouve des distributions Linux aujourd'hui qui proposent nftables ?
Eric Leblond : Oui ! En fait, comme c'est dans le noyau officiel depuis le 3.13, toutes les distributions ayant un noyau 3.13 ou plus récent embarquent nftables, et la plupart ont déjà intégré les utilitaires (ndlr. les programmes qui communiquent avec la partie noyau de nftables). Je sais que c'est dans Fedora, dans Debian... C'est donc déjà utilisable, et déjà testable.
InfoQ FR : Merci Eric !