Patrick Mac Hardy, le chef du projet Netfilter, travaille depuis quelques temps maintenant à une ré-écriture d'Iptables sous un nouveau nom : NFtables. J'en avais eu vent juste avant les Netfilter user day en septembre dernier, mais l'arrivée en retard du sieur Mac Hardy m'avais, outre passablement faché, privé d'une revue de ce nouveau projet. Hors, depuis le 18 mars dernier, NFtables est officiellement disponible en version alpha (pas pour kevin, hein) et fait donc partie intégrante du développement du noyau. Je me suis donc dit que c'était le moment d'en refaire le tour.

Les défauts d'IPtables

Pour le user tranquille, IPtables est relativement simple à utiliser. Il faut, certes, en comprendre l'architecture pour écrire des règles efficaces, et cela peut prendre du temps (moi = 3 ans), mais les limitations en termes de performances ne se feront pas vraiment sentir. Mais, au sein d'une infrastructure où l'on peut avoir plusieurs milliers de règles, le tout logué dans syslog, avec des ajouts et suppressions plus ou moins réguliers, alors là, on morfle.

Mac Hardy a listé ces limitations lors de sa présentation en septembre dernier (que j'ai fini par récupérer sur son blog) :

• le noyau et le userspace sont intimement liés, les modules doivent être implémentés des deux cotés (avec une relation 1:1), les structures doivent rester identiques car dumpés dans les deux sens
• dans le noyau, un jeu de règle est un seul blob qui doit être déchargé et rechargé complétement à chaque ajout/suppression de règle. Quand il y en a 5000, ça calme : pour l'ajout d'une règle, iptables (en userspace) réalise un dump complet des règles dans le noyau, insère la nouvelle et renvoi le dump complet au kernel. Le kernel perd alors les états entre les anciennes règles et les nouvelles.
• le code est sale : 138 modules dans le 2.6.26, pas "64 bits clean", beaucoup de fonctions de matching qui font la même chose

La ré-écriture

Bref, c'est pas propre. Mieux vaut tout remettre à plat, en conservant ce qui est bon et en prenant en compte les desiderata des utilisateurs. C'est ce qui a été présenté en septembre dernier et l'annonce de release de la semaine dernière marquent la fin de cette première étape de dev.

Dans le Noyau

NFtables, c'est d'abord une modif du noyau pour éviter les pépins (hoho !) qu'a amené Iptables. On revient donc à une règle de base : le noyau est idiot ! Il fait ce qu'on lui dit et ne réfléchit pas, d'ailleurs , il a pas le temps de réfléchir car il a trop de travail a coté.

Donc, le noyau, Mac Hardy veut qu'il en fasse le moins possible pour pouvoir le faire le plus vite possible. Le comptage des paquets et des octets deviennent optionnels, les tables sont créées en userland (sauf la table NAT), etc...

Après, on ajoute de la flexibilité. Beaucoup de flexibilité : le matching peut pointer vers plusieurs targets (log et drop, par exemple) dans la même règle. Plus besoin de bricoler les JUMP pour faire du LOG avec le DROP. On aura une règle simple du type :

# nft add rule output tcp dport 22 log accept

pour accepter les paquets sortant vers le port SSH tout en loguant.

Autre avancée : le support des sets (comme le fait ipset) et des dictionnaires pour matcher plusieurs ensembles dans une seule règle. L'exemple qui illustre le mieux cette nouvelle feature est la gestion de plusieurs réseaux dans une règle :

ip daddr { 192.168.0.0/24 => drop, 192.168.0.100 => accept}

Ci-dessus, on voit que l'accept a lieu sur une IP unique, alors que son domaine d'appartenance est en DROP. Ceci est désormais possible car la règle du "plus précis gagne" est appliquée sur les ensembles. Comme en routage BGP.

La représentation des données dans le noyau a également changée, afin de la rendre plus générique. Il est donc possible d'utiliser n'importe quelle fonction de matching avec n'importe quelle donnée. La correspondance "n" match sur "n" données ayant disparue, les possibilités de filtrages vont rapidement exploser.

Et enfin, la grosse feature de NFtables, c'est le commit incremental des règles, pour éviter de balancer un blob de 4000 règles entre le userland et le kernel dès que la règles 832 change ! Lors des Netfilter User Day, Jesper Brouer avait montré que le listing de 50 000 chaines prenait environ 5 minutes ! (et il avait écris un patch pour corriger cela). Désormais, avec NFtables, ce problème ne devrait plus se produire. (note: je n'ai pas de mesure pour le temps d'insert, si quelqu'un en a...)

(Happy)User-land

Mais tout cela, c'est pour les kernel hackers ! Ce qui t'intéresse, toi, Kevin, qui veut montrer à tes potes que tu sais piloter un firewall en mode couillu ligne de commande, c'est l'interface ! Hors, la nouvelle interface, elle s'appelle justement NFtables, et elle a été complétement refondue. Fini la syntaxe "iptables -A INPUT -t superinput -p tcp --sport emule -j ACCEPT", maintenant, il faudra faire du "nft add rule input tcp sport emule accept". La classe quand même !

Blague à part, cette évolution est une bonne nouvelle. Déjà parce qu'elle va rajouter de la cohérence la où il n'y en avait pas (va essayer d'écrire une règle de NAT sur iptables, tiens !). Aussi, la nouvelle langue d'iptables (qui nous vient de bison) vient avec un toolkit complet de vérification sémantique. L'intérêt ? C'est de pouvoir valider toutes les règles avant de les passer au Kernel, mais aussi de pointer les erreurs. Et comme rien ne vaut un exemple ...

- conflict detection:

  ... ip protocol tcp udp dport 53

   results in:

   <cmdline>:1:37-45: Error: conflicting protocols specified: tcp vs. udp
   add filter output ip protocol tcp udp dport 53
                                     ^^^^^^^^^

  ... ip6 filter output ip daddr 192.168.0.1

   <cmdline>:1:19-26: Error: conflicting protocols specified: ip6 vs. ip
   ip6 filter output ip daddr 192.168.0.1
                     ^^^^^^^^

(ca vient directement de l'announce de Mac Hardy)

De fait, le débug des règles devrait en être facilité. Mais en fait, pour les admins, c'est un véritable cadeau empoisonné car il faudra tout réapprendre... a en lire le mail de Mac Hardy, rien n'a été conservé ! Pfiou !

Mais au final

Tout cela regorge de fonctionnalités qui se montrent plus excitantes les unes que les autres. Et je ne vous ai révélé que la face visible de l'iceberg, car avec le temps viendront des features pour contrôler TC depuis NFtables, ou encore l'ajout de nouvelles possibilités de matching, venant des U32 ou d'ailleurs.

Bref, ça va bouger, stay tuned ! En attendant, si tu veux testé, toi Kevin qui as tout lu jusqu'au bout (je suis fier de toi), il te faudra te diriger vers l'announce de Mac Hardy en lien au début de ce post ;)

note: illustration de Simon Havard, réalisé pour un rapport de stage rendu il y a bien longtemps.... :)