Journal NFtables, successeur d'Iptables

Posté par  (site web personnel) .
Étiquettes :
34
25
mar.
2009
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:
    

    
   :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
    

    
   :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 ;)

    • # Plus excitant encore en dépêche

      Posté par  . Évalué à 10.

      Tous en cœur : "Fais en une dépêche !"

      Excitant, c'est le terme!

      Tout réapprendre pour se remettre en cause et acquérir de nouvelles compétences, c'est cela qui fait un bon admin.

    • # Yeeaah

      Posté par  . Évalué à 10.

      Dans l'esprit ça semble furieusement inspiré de Packet Filter, qui est une vraie bouffée d'air frai comparé au laborieux Netfilter.
      J'ai bien hâte de tester ce NFtables qui parait vraiment intéressant!!!

    • # Bonne nouvelle

      Posté par  (site web personnel) . Évalué à 10.

      Avoir une syntaxe simplifiée comme celle de PF par exemple, c'est du tout bon. IPtables est clairement vieillissant et la décision de repartir de zéro est pour moi la bonne, car cela devrait donner un pare-feu moderne répondant aux besoins d'aujourd'hui.

      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 10.

        Pas de bol, la logique (plus que la syntaxe) de nftables (telle qu'exposée par Patrick Mac Hardy, c'est évidement moins visible dans l'exemple de la dépêche) est encore a des années lumières d'être aussi simple et naturelle que celle de pf, d'où la plainte justifié de l'auteur de la dépêche : "c'est un véritable cadeau empoisonné car il faudra tout réapprendre.". La syntaxe est elle-aussi moins bonne, mais c'est moins grave à mes yeux.

        On garde, par exemple, au coeur de l'outil, l'ensemble des concepts de chaines et tables, qui correspondent effectivement à ce qui se trouve coté noyau chez linux, mais qui ne sont certainement pas la façon la plus ergonomique d'exposer les choses à l'utilisateur (et donc avec la nécessité, toujours, de garder en tête leurs contextes respectifs d'application, leurs ordres de traitement, etc., qui font qu'aujourd'hui la sécurité effectivement assurée par un gros firewall iptables based est très difficile à vérifier en le lisant seulement (ie. sans le tester), à la différence de pf). La syntaxe reste assez verbeuse à priori, mais tout de même en net progrès par rapport à iptables (véritable langage et non plus options cli d'un binaire, notion d'implicites selon le contexte, par ex...). Mais ce qui aurait été à revoir fondamentalement n'a pas changé : la possibilité de faire des rulesets vraiment propres structurés, lisibles, au moins linéairement ; les sauts de chaines sont aux configuration structurées précisément ce que le GOTO était à la programmation à l'époque de Djikstra....

        Quelques progrès tout de même, qui nous rapprochent un brin de pf, comme la possibilité de tester la syntaxe d'un ruleset avant de le charger (enfin !). Reste qu'il est vraiment dommage que Mac Hardy ai préféré s'amuser à inventer son langage à lui plutôt que de reprendre au moins l'interface utilisateur de pf.

        NIH to the rescue !

        • [^] # Re: Bonne nouvelle

          Posté par  (site web personnel) . Évalué à 4.

          Il va vraiment falloir que je reprenne ce projet de test d'OpenBSD, car si tout ce que vous dites au sujet de PF est vrai, alors c'est la révolution...

          Néanmoins, je m'étonne que PF soit si peux présent dans les environnements d'entreprise que j'ai croisé. Vous me direz, c'est comme netfilter, qui se voit généralement préféré un checkpoint ou un juniper. Mais tout de même... pourquoi tant de silence ?

          Ce qui m'amène à la question suivante : existe t'il une bonne présentation de PF qui soit pas une page de man ?
          En français, en anglais... ça me va tant que c'est pas du danois (rigolez pas, on me l'a faite ce matin !)

    • # Linux Weekly News

      Posté par  (site web personnel) . Évalué à 9.

      Pour les abonnés à LWN il y a aussi un excellent article de présentation ici : http://lwn.net/Articles/324989/

      Un certain nombre de personnes (dont moi) ont demandé pourquoi il était nécessaire de réinventer la roue et est-ce qu'il ne serait pas mieux d'importer directement l'outil d'OpenBSD (pf) qui semble apprécié de tous.
      La réponse :

      "To clarify: I certainly did consider the way pf does things and there are quite a few things I like better than in iptables, starting with having a language specifically designed for filtering rules, compared to the quite primitive shell command invocation mainly used with iptables.
      But porting the kernel side doesn't make sense at all. The code structure doesn't match how things are done in the Linux kernel, the API doesn't match what we want, its tightly coupled to a different NAT and state tracking system and even basic things like rule evaluation order are different from what iptables does. There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.      "

      • [^] # Re: Linux Weekly News

        Posté par  (site web personnel) . Évalué à 2.

        Ca se comprend bien.... Ya pas que l'interface dans netfilter, ya surtout le noyau. Et avec tout le boulot qui a été effectué sur les conntrack tools, les xtables et j'en passe, je comprend qu'il ait pas envie de tout reprendre :)

      • [^] # Re: Linux Weekly News

        Posté par  . Évalué à 6.

        > But porting the kernel side doesn't make sense at all.

        Ça ne fait pas de doutes, mais ça n'explique pas vraiment pourquoi il n'a pas essayé de reprendre - un minium, disons - l'interace utilisateur (la grammaire et la logique, si on veux), à moins que je n'ai pas compris son explication.

        Mon hypothèse non informée à ce sujet, c'est qu'étant un des principaux développeurs de la partie noyau (netfilter), l'interface qui devait être la plus conceptuellement "naturelle" pour lui devait certainement être une interface qui se modelait sur les concepts de la structure interne au noyau (comme les outils précédents, iptables & co). C'est quand même le modèle conceptuel qui doit lui être le plus familier, et de loin.

        Or il n'est pas du tout certain que la façon la plus pertinente (ergonomiquement parlant, ou en terme d'UI) d'exposer les fonctionnalités de firewalling de Linux à l'utilisateur soit de se coller au modèle interne du noyau. De même qu'un système de fichier expose une interface utilisateur adaptée, définie par posix en l'occurrence, avec open(), close() et compagnie, et pas une api collée au block layer de Linux.

        Après iptables, et avec GIT et SELinux, on pourrait finir par croire que les développeurs noyau sont frappés d'une malédiction les conduisant à écrire des outils super puissant avec des interfaces toutes pourries ;). Sur ce point, au fait, les développeurs d'OpenBSD n'ont aucun mérite : ils ont initialement repris, puis amélioré la syntaxe propre et bien pensée d'ipf, le firewall de Darren Reed (sans quoi ils auraient sans doute fait quelque chose d'imbitable eux aussi).

        • [^] # Re: Linux Weekly News

          Posté par  . Évalué à 6.

          Sur ce point, au fait, les développeurs d'OpenBSD n'ont aucun mérite : ils ont initialement repris, puis amélioré la syntaxe propre et bien pensée d'ipf, le firewall de Darren Reed (sans quoi ils auraient sans doute fait quelque chose d'imbitable eux aussi).
          Ils n'ont même pas le mérite du bon choix ?

          • [^] # Re: Linux Weekly News

            Posté par  . Évalué à 4.

            +1!!
            C'est tellement précieux (mais trop rare), les developpeurs qui reprennent les bonnes idées plutot que de réinventer la roue.

            Ne serait-ce que pour simplifier la vie des admin cela aurait value le coup de partir de la syntax de pf comme base pour l'interface utilisateur..

    • # Filtrage accru

      Posté par  . Évalué à 7.

      Il est toujours intéressant de voir un projet repartir de zéro après un bon gros
      rm -rf

      :)
      Ceci dit, j'ai une question? Sera t'il possible de faire du matching niveau 7?

      J'aimerai vraiment pouvoir faire un genre de:
      iptables -A OUT -p tcp --dport 80 --service HTTP -j ACCEPT

      Le problème, c'est qu'ouvrir le port 80 revient à ouvrir pour n'importe quel type de flux qui utilise le port 80...
      Si on pouvait spécifier le type de service, ça serait bien.

      J'ai utilisé l7-filter, mais ça n'est pas vraiment pratique (enfin je trouve)

      Si nffilter le fait, j'adopte.

      • [^] # Re: Filtrage accru

        Posté par  . Évalué à 2.

        A priori le mini-langage dans le noyau doit le supporter, c'est juste la création des bonnes instructions coté utilisateur qui manque (mais fondamentalement c'est deja bien plus flexible que iptables).

        Sinon un remarque rien à voir: pour les gens qui font de la compil, verification de code, etc. Y'a des possibilités sympa d'optimisation et/ou de preuve de programme a faire sur le bytecode generé :)

    • # Un peu de lecture pour compléter tout ça?

      Posté par  (site web personnel) . Évalué à 7.

      Je recommande la lecture du dernier GNU/Linux magazine France des Editions Diamndes Hors Série, le numéro 41

      Avec entre autre, au menu, une interview : Patrick McHardy, chef du projet
      et une Introduction à Netfilter et iptables.

      Pour en savoir plus, le lien sur le site des Editions Diamonds :
      http://www.ed-diamond.com/produit.php?produit=616

    • # Déjà vu

      Posté par  . Évalué à 3.

      Le plus dur sera de mettre a jours les sys admins.
      Ça me fait penser a iproute2 vs nettools. À quand une implémentation d'iptables en sur-couche à nftables ?

      • [^] # Re: Déjà vu

        Posté par  . Évalué à 2.

        D'ailleurs la syntaxe de nftables me fait beaucoup penser à celle d'iproute2 (qui devrait aujourd'hui être l'outil par défaut tellement il est mieux que ifconfig/arp/route ... rhaa, ces outils qui me bouffent l'IP supplémentaire que j'avais gentiement rajouté sur mon interface ...)

    • # Réinventer

      Posté par  (site web personnel) . Évalué à 3.

      Dans la catégorie réinventer la roue, pourquoi ne pas reprendre directement la syntaxe de pf ?
      Ca permettrait de ne pas devoir "réapprendre" pour rien.
      Ca permettrait aussi d'avoir des outils de configuration de firewall développés directement pour plusieurs systèmes.
      Il restera toujours des différences plus ou moins subtiles, mas ça pourrait nous faciliter la vie.

      • [^] # Re: Réinventer

        Posté par  . Évalué à 7.

        Alors, pour m'être posé la même question, et après avoir relu les réponses de Mac Hardy sur LWN, je crois avoir trouvé quelques éléments de réponse. Je crois qu'il faut y voir un compromis entre "tout casser" (pas de rétro/forward compatiblity, pas de plan de transition progressive) et un changement "incrémental" d'iptables qui n'aurait pas permis de résoudre les problèmes les plus pressants (langage dédié, vérifications de syntaxe et atomicité par exemple).

        Mac Hardy indique qu'il compte à terme rendre le passage d'iptables à nftables totalement automatisable (scriptable). Cela n'est pas possible en changeant radicalement les paradigmes sous-jacents : sur plusieurs points, la logique chaines/tables d'iptables ne peut pas être transcrite telle quelle automatiquement en rêgles pf : ce n'est plus une retranscription mais une ré-écriture, car il faut repenser la structure du jeux de règles pour arriver aux mêmes fins. Par exemple pf a pris le partis de ne pas traiter le layer7 et de déléguer ça à l'espace utilisateur (proxys ftp ou sip...). Je crois que c'est en ce sens que Mac Hardy disait, dans les commentaires de LWN, qu'il aurait perdu en flexibilité/fonctionnalités en passant vers pf : certaines façons d'exprimer les choses "à la iptables" ne seraient plus possibles, un problème qu'il cherche de toutes évidences à éviter avec nftables, pour de bonnes raisons. Il exprime ailleurs ce soucis explicitement sur LWN, en disant au sujet de pf :There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.

        Même remarque en ce qui concerne la vaste gamme d'outils générant des rulesets iptables (nufw, shorewall, ipkungfu, ...) : si la structure logique reste suffisamment identiques (au point qu'on puisse scripter la transcription de rulesets iptables en nftables), ils seront peut-être adaptables à moindre frais, mais si elle change radicalement les adapter pourrait imposer une refonte complète (ou autrement dit : iptables continuerai d'être utilisé pendant longtemps). Et vu de l'autre coté des outils, face noyau, il y ne faut pas sous-estimer la possibilité de réutiliser ce qui est déjà en place dans le noyau Linux.

        Je crois que c'est sur ce même compromis (paradigmes et logique sous-jacente repris mais étendus et complétés) que la transition de ipchains vers iptables a pu se faire en douceur, au point qu'iptables fut finalement adopté assez rapidement, et que les mainteneurs ont en conséquence pu se permettre de passer ipchains en mode maintenance molle. Notez que chez OpenBSD, pf a d'abord été une quasi ré-écriture d'ipf qu'il remplaçait, et dont il reprenait la syntaxe : dans ces conditions la transition est relativement "facile". DragonFlyBSD est sortis après pf (pas d'historique à respecter). FreeBSD et NetBSD ont conservé le support ipf (et même le vieillissant ipfw pour Free) malgré l'intégration de pf. Et enfin le port de pf sous Windows (oui oui ! ça existe !) ne permet certainement pas à Microsoft de se passer de maintenir leur solution de firewalling native (si ridicule soit-elle).

        Mac Hardy n'a certainement pas envie d'avoir à faire évoluer iptables toute sa vie. La contrepartie, c'est qu'iptables puis nftables vont hériter de certains petits problèmes de design et d'ergonomie initiés à l'époque d'ipchains.

        Evidement, dans le meilleurs des mondes, Linux aurait des mainteneurs à vie pour ses outils actuels et intégrerait aussi les meilleures choses de ses cousins, pf et bioctl d'OpenBSD, Dtrace et ZFS de Solaris,...

        Pour l'anecdote, et toujours dans les commentaires de LWN, Rusty Russel, l'auteur d'ipchains et iptables dit avec son humour légendaire :
        But I always intended iptables as the assembler language of firewalls. Someone was supposed to write the cool GUI tool which monitored traffic, let you shape and firewall it without touching this stuff. I'm still waiting :)

    • # argumentaire ??

      Posté par  . Évalué à 6.

      Moi j'aime bien l'argument du parefeu a 50000 règles avec la préoccupation de le rendre auditable ... A mon sens quand on arrive a ce nombre de règles, c'est que l'architecture du réseau n'est pas bien pensée, il faut plutôt refondre le réseau pour le segmenter en fonctions logiques auditables plutot que de multiplier les règles pour gérer des exceptions.

      Enfin, il est certainement temps de moderniser netfilter, même si chez moi il remplace très avantageusement un pix ou un firewall-1. Notement grâce a son système de jump qui permet d'optimiser le parcours des règles en construisant un arbre de décision...

    Suivre le flux des commentaires

    Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.