nftables, successeur d'iptables

Posté par . Modéré par Pascal Terjan.
25
29
mar.
2009
Sécurité
Patrick Mac Hardy, chef du projet Netfilter, travaille depuis l'été 2008 à une ré-écriture d'iptables sous un nouveau nom : nftables. Or, depuis le 18 mars dernier, nftables est officiellement disponible en version alpha. C'est le moment d'en refaire le tour.

NdM : Un grand merci à switcher pour son journal dont est tiré la dépêche. Les défauts d'iptables

Pour l'utilisateur lambda, iptables est relativement simple à utiliser. Il faut, certes, en comprendre l'architecture pour écrire des règles efficaces, et cela peut prendre du temps, mais les limitations en terme de performances ne se feront pas vraiment sentir. Au sein d'une infrastructure où l'on peut avoir plusieurs milliers de règles, le tout enregistré dans syslog, avec des ajouts et suppressions plus ou moins réguliers, la difficulté est tout autre.

Mac Hardy a listé ces limitations lors de sa présentation en septembre dernier lors du Netfilter Workshop 2008 qui s'est déroulé à Paris :
  • le noyau et l'espace utilisateur 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 espace utilisateur) réalise un dump complet des règles dans le noyau, insère la nouvelle et renvoie le dump complet au kernel. Le noyau perd alors les états entre les anciennes règles et les nouvelles.
  • le code est sale : 138 modules dans le 2.6.26, pas tous compatibles 64 bits, 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 desideratas des utilisateurs. C'est ce qui a été présenté en septembre dernier et l'annonce de version de la semaine dernière marquent la fin de cette première étape de développement.

Dans le noyau

nftables est d'abord une modification du noyau pour éviter les pépins 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 n'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 espace utilisateur (sauf la table NAT), etc.

Après, on ajoute de la flexibilité. Beaucoup de flexibilité : le matching peut pointer vers plusieurs cibles (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 ensembles (comme le fait ipset) et des dictionnaires pour matcher plusieurs ensembles dans une seule règle. L'exemple qui illustre le mieux cette nouvelle fonctionnalité 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 fonctionnalité de nftables est le commit incrémental des règles qui évite de balancer un blob de 4000 règles entre l'espace utilisateur et le noyau 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 a écrit un patch pour corriger cela). Désormais, avec nftables, ce problème ne devrait plus se produire.

(Happy) User-land

Mais tout cela, c'est pour les utilisateurs avancés, ce qui intéresse la majorité des utilisateurs c'est l'interface ! La nouvelle interface 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 ».

Aussi, la nouvelle langue de nftables (qui utilise bison) vient avec une boîte à outils complète de vérification sémantique. L'intérêt ? C'est de pouvoir valider toutes les règles avant de les passer au noyau, 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
^^^^^^^^

(exemple extrait de l'annonce de Mac Hardy)

De fait, le débogage des règles devrait en être facilité. Mais en fait, pour les administrateurs, c'est un véritable cadeau empoisonné car il faudra tout réapprendre. À 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. Avec le temps viendront des fonctionnalités pour contrôler TC (Traffic Control) depuis nftables, ou encore l'ajout de nouvelles possibilités de matching, venant des U32 ou d'ailleurs.

Historique

La première implémentation de parefeu Linux s'appellait ipfwadm. ipchain l'a remplacé dans Linux 2.2. Linux 2.4 aura vu apparaitre iptables. nftables sera donc la 4e génération de parefeu pour Linux 2.6.

Hors série Linux Magazine dédié à Netfilter

Une interview de Patrick Mac Hardy (et d'autres développeurs majeur de Netfilter), un compte rendu du Netfilter Workshop 2008, ainsi que de nombreux articles sur les développements en cours dans Netfilter sont disponibles dans le dernier Hors Série (n°41) de GNU/Linux Magazine.
  • # bonne dépêche

    Posté par . Évalué à 4.

    Merci à l'auteur de la dépêche pour la clarté et la simplicité des explications. J'ai tout compris :-)
  • # Attention, jargon

    Posté par . Évalué à 4.

    "Plus besoin de bricoler les JUMP pour faire du LOG avec le DROP. "

    Je la garde précieusement celle là. Merci
    • [^] # Re: Attention, jargon

      Posté par (page perso) . Évalué à -2.

      D'autant plus que c'est faux :

      LOG

      This is a "non-terminating target", i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).


      Source : iptables(8).
      • [^] # Re: Attention, jargon

        Posté par (page perso) . Évalué à 7.

        Justement, relis encore la page man ;)

        La problématique d'iptables est qu'une des actions les plus fréquentes et de journaliser (target *LOG) puis bloquer ce même paquet (target DROP). Comme les règles *LOG ne sont pas terminales, il est nécessaire d'utiliser deux règles pour fixer cela (une LOG suivi d'une DROP). On a donc deux fois plus de règles que nécessaire.

        Une méthode de contournement consiste à créer une chaine utilisateur LOGDROP qui journalise puis bloque les paquets. On utilise alors -j LOGDROP (-j pour JUMP) pour journaliser et bloquer les paquets en une seule règle.

        En permettant l'utilisation de plusieurs targets dans une même règle, nftables simplifie cela.
        • [^] # Re: Attention, jargon

          Posté par (page perso) . Évalué à 4.

          >La problématique d'iptables est qu'une des actions les plus fréquentes et de journaliser
          >(target *LOG) puis bloquer ce même paquet (target DROP).

          Chez moi, ce n'est pas très fréquent... Par défaut, la rêgle c'est de bloquer et de logguer avant (avec un clause limit pour éviter le flood). J'ai donc quasi qu'une seule rêgle de log sur toutes les rêgles.

          J'ai par contre pas mal de rêgles qui acceptent.


          Je ne comprends pas ce que tu veux dire. Pourrais-tu expliciter ? J'ai l'impression que c'est uniquement avec une politique, j'accepte tout par défaut et je sélectionne ce que je droppe que le problème existe (ce qui est pour moi une mauvaise pratique).
          • [^] # Re: Attention, jargon

            Posté par (page perso) . Évalué à 5.

            J'ai par contre pas mal de rêgles qui acceptent.

            Si tu veux loguer le traffic que tu acceptes pour des raisons légales, vérifier le bon fonctionnement de ton réseau, etc., hé bien tu dois dupliquer chaque règle iptables :
            iptables (... beaucoup d'arguments....) -j NFLOG (... paramètres de log ...)
            iptables (... beaucoup d'arguments....) -A ACCEPT

            Niveau performance, c'est très pénalisant car Netfilter est très sensible au nombre de règles étant donné qu'il les teste séquentiellement !
            • [^] # Re: Attention, jargon

              Posté par (page perso) . Évalué à 4.

              Pour ma part, j'évite de logguer de trop sinon on se retrouve avec un FW -dont je rappelle le but est de protéger - qui devient un facteur important dans la réussite de DOS. C'est par ailleurs impossible de logguer tout et surtout pas les accept.

              Si je loggue des accept, il y a souvent un combinaison de
              - un limit
              - log de l'establish
              - log précis d'une ip
              ce qui fait que j'ai de toutes manières besoin d'une rêgle différente. Je ne vois pas comment la nouvelle solution apporte un avantage. Peux-tu expliciter avec des exemples ?

              >Niveau performance, c'est très pénalisant car Netfilter est très sensible au nombre de
              >règles étant donné qu'il les teste séquentiellement !

              Est-ce que ça change quelque chose avec les nouveaux développements ? Car il me semble que c'est toujours la même chose coté noyau (Juste caché dans la syntaxe) ?
              • [^] # Re: Attention, jargon

                Posté par (page perso) . Évalué à 3.

                C'est joli un équipement de sécurité qui ne logue pas... c'est un peu comme une barrière sans garde barrière: comment tu sais que quelqu'un vient de passer par dessus ? :)

                Un firewall sous Netfilter peux tout loguer, du moment que tu fait ca intelligemment :
                1. syslog peux manger des lignes de logs plus vite que tu ne pourra jamais lui en fournir, et niveau I/O je doute que ton noyau ou ton disque soit saturés avant ta carte réseau

                2. Les DROP, ca se logs par connexions, ou par paquets si ya pas de connexions. Pour ca, tu met pas de politique par défaut car elle ne permet pas de loguer. Par contre tu peux mettre ca a la fin de tes règles :


                echo "Default log drop, at the end so we just drop what doesn't match the previous rules"
                iptables -N LOGDROP
                iptables -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
                iptables -A LOGDROP -j DROP

                iptables -A INPUT -i eth0 -j LOGDROP
                iptables -A OUTPUT -o eth0 -j LOGDROP


                3. Les accepts, ca se log aussi. Mais pas tout, juste les etablissements de connexions. La plupart des protocoles sur TCP garde une seule connexion TCP ouverte (sauf HTTP sans le keep alive). De fait, tu aura que peux de logs pour les accepts en comparaison du nombre de paquets.

                Bon, ca peux quand meme faire quelques gigas, mais quels machines n'a pas 40 gigas de disques aujourd'hui ? Et puis, pas besoin de garder les logs pendant 30 jours, si tu n'a pas vu l'attaque passer dans la semaine, alors il faut changer de métiers ;)
                • [^] # Re: Attention, jargon

                  Posté par (page perso) . Évalué à 4.

                  >1. syslog peux manger des lignes de logs plus vite que tu ne pourra jamais lui en fournir,
                  >et niveau I/O je doute que ton noyau ou ton disque soit saturés avant ta carte réseau

                  Malheureusement, non ce n'est pas le cas. Et je parle d'expérience. J'ai déja eu pour une grande institution 40Go de logs en 1h (flood). Si tu calcules cela fait plus ou moins 12Mo/sec. Le(s) firewall(s) n'ont pas tenu la charge. Et ce n'était pas une petite machine. En plus, on prend le risque d'avoir le disque plein et donc de subir un deni de service.

                  >2. Les DROP, ca se logs par connexions, ou par paquets si ya pas de connexions. Pour ca,
                  >tu met pas de politique par défaut car elle ne permet pas de loguer. Par contre tu peux
                  >mettre ca a la fin de tes règles :

                  C'est ce que je disais. Quel est le point ?


                  >3. Les accepts, ca se log aussi. Mais pas tout, juste les etablissements de connexions.

                  C'est ce que je disais. Quel est le point ?

                  >Bon, ca peux quand meme faire quelques gigas, mais quels machines n'a pas 40 gigas de
                  >disques aujourd'hui ?

                  Des firewalls, par exemple ? Même avec 500Giga le problème se pose lorsqu'on a des connections 1Gbit vers le net.
                  • [^] # Re: Attention, jargon

                    Posté par (page perso) . Évalué à 1.


                    Malheureusement, non ce n'est pas le cas. Et je parle d'expérience. J'ai déja eu pour une grande institution 40Go de logs en 1h (flood). Si tu calcules cela fait plus ou moins 12Mo/sec. Le(s) firewall(s) n'ont pas tenu la charge. Et ce n'était pas une petite machine. En plus, on prend le risque d'avoir le disque plein et donc de subir un deni de service.


                    Pas tenu la charge ? Il me semble avoir vu des résultats de Bench pour syslog qui allaient largement au dessus de ces valeurs.
                    Après, les questions d'espace disque sont indépendantes des capacités du système. C'est sur que si tu souhaite tout loguer sur une connexion 10Gbits, vaut mieux avoir un gros RAID5 de plusieurs tera sous la main.

                    Concernant le déni de service, je vois pas trop comment ca peux arriver... a moins que tu décide de mettre du swap sur un firewall, mais le je comprend pas l'intérêt.



                    C'est ce que je disais. Quel est le point ?

                    Ha ba non alors, si on dit la même chose, tout va bien :)
  • # Patrick Mc Hardy présentera nftables aux RMLL 2009 de Nantes

    Posté par (page perso) . Évalué à 6.

    Comme cela avait étéle cas avec Pablo Neira Ayuso, membre de la Netfilter Core Team, lors de l'édition 2008 à Mont de Marsan ( http://2008.rmll.info/Conference-Haute-disponibilite-de.html ), Netfilter sera présent aux RMLL 2009 de Nantes.

    Patrick Mc Hardy devrait y présenter nftables. Eric Leblond, contributeur Netfilter, y présentera aussi uLogd2, sous-projet de netfilter, dont il est le responsable.
  • # syntaxe similaire à pf

    Posté par (page perso) . Évalué à 7.

    ça resemble drôlement à la syntaxe de pf :

    # nft add rule output tcp dport 22 log accept

    contre

    pass in log proto tcp port ssh

    Bon, ça va, pf est toujours mieux, mais bon, il y a de l'amélioration... ;-)
    • [^] # Re: syntaxe similaire à pf

      Posté par (page perso) . Évalué à 6.

      Autant les critiques à iptables et sa syntaxe comparée à la simplicité de pf était juste, autant je trouve l'amélioration flagrante.

      De plus tu compares une règles pf lu dans un fichier à une règle nftable lancée depuis la ligne de commande (je suppose que le add rule devient inutile si on parle de fichier de conf)

      Bref pf peut être un poil meilleur mais faut pas cracher sur nftable alors qu'il n'est pas encore sorti.
      • [^] # Re: syntaxe similaire à pf

        Posté par . Évalué à 3.

        Bref pf peut être un poil meilleur mais faut pas cracher sur nftable alors qu'il n'est pas encore sorti.

        Il y a quand même (au moins) un truc qu'on peut dire avant que nftable soit sorti: Sur le même projet, par les mêmes auteurs ou presque, c'est la deuxième ré-écriture de la fonction de filtrage de paquets dans le noyau Linux. On avait ipchains, qui a été réécrit pour donner iptables, qui vient lui-même d'être réécrit pour donner nftable.

        Ca soulève quand même la question de savoir pourquoi on a encore besoin de le ré-écrire, et ça nécessite d'apprendre une nouvelle syntaxe. Pas dramatique, mais un peu pénible.

        (Je pourrais aussi parler de ipfwadm, mais je ne sais pas s'il s'agissait des mêmes auteurs)
    • [^] # Re: syntaxe similaire à pf

      Posté par . Évalué à 2.

      Il n'existe pas d'équivalent à nufw avec PF si je ne m'abuse.

      Je n'affirme pas que PF est moins bon que NF mais qu'ils s'équivales relativement bien.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: syntaxe similaire à pf

        Posté par (page perso) . Évalué à 1.

        • [^] # Re: syntaxe similaire à pf

          Posté par . Évalué à 4.

          La base semble similaire point de vue fonctionnement, mais c' est très loiin de ce que NuFW sait faire. Ca me semble difficilement comparable.
          pour rappel NuFW est capable de faire (de la conf de) du filtrage sur ip, mais aussi sur utilisateur. Ici AuthPF fait de même avec un fonctionnement "similaire" (tousss) dans la mesure ou le firewall n' est pas capable d' être autonomne : dans le cas de AuthPF il faut modifier les shell de connections des suers, dans le cas de NuFW il faut installer un client. Bref là ça se ressemble un peu fortement : aucune autonomie du firewall.
          Mais NuFW fait aussi du filtrage sur Applications (tiens faudrait jeter un oeil à la gestion de groupe de process par nufw juste pour la culture).
          NuFW est également capable de travailler en collaboration avec un ids (prélude par exemple).
          Egalement capable de souplesse quant à l' authentifiaciton (pam mais pas seulement : ldap ...)

          Références :
          http://www.nufw.org/docs/references22/index.html

          Cordialement.

          ps : pour palier à ce (gros, quant même) problème de la nécessité d' un client NuFW, viviement qu' une distribution l' intègre totalement en toute transparence... Et d' ailleurs, pourquoi le client Nufw n' est il toujours pas intrinsèquement lié au système ?
          En fait ça marche dans les 2 sens : que le firewall soit plus intégré côté noyau (et nftables : y a t il une intégration prévue pour nufw?) et que le client soit plus intégré côté système.
          Je ne plaide pas spécialement pour nufw, ce sont juste des remarques à 2 cents...
          • [^] # Re: syntaxe similaire à pf

            Posté par (page perso) . Évalué à 2.

            On est d'accord, nufw est plus puissant que authpf. De toutes façon, nufw et authpf ne sont pas intégré à iptable ou à pf respectivement, ce sont des couches au dessus, et ça ne change rien aux fonctionnalités de iptable ou de pf.
          • [^] # Re: syntaxe similaire à pf

            Posté par (page perso) . Évalué à 3.

            La différence entre authpf et NuFW est qu'authpf associe une IP à un utilisateur, ce n'est pas le cas dans NuFW. Enfin, corrigez moi si je dis une bétise.

            aucune autonomie du firewall

            On ne peut pas garantir l'authenticité (l'auteur) des connexions sans modifier le poste client. Un portail captif est une grosse blague par exemple : il réduit un utilisateur à son IP : emprunter son IP (c'est facile) suffit pour récupérer ses autorisations.

            (...) client NuFW, viviement qu' une distribution l' intègre totalement en toute transparence

            NuFW est intégré à plusieurs distributions comme Debian (et ses dérivés) et Mandriva. Il existe deux clients Linux : nutcpc (ligne de commande) et pam_nufw (lancé par PAM). Le second est transparent pour l'utilisateur : il est lancé en tâche de fond lorsque l'utilisateur se connecte (PAM : login, su, sudo, ssh, ...), puis quitte lorsque l'utilisateur se déconnecte. Le client Windows fonctionne de la même manière.
            • [^] # Re: syntaxe similaire à pf

              Posté par (page perso) . Évalué à 4.

              Faut pas confondre disponible et intégré, je pense que ce que tankey voudrait, c'est que ça marche directement, de façon intégré sans avoir à passer derrière, en installant un paquet, en mettant la machine dans le ldap, etc.

              Actuellement, pour mettre pam_nufw, faut avoir le même mot de passe sur le firewall et sur sa machine, ce qui implique donc de devoir déployer un ldap en général, en plus d'avoir du mettre nuauth ( à configurer à la main ), et d'avoir mis un nufw, qui lui même implique d'avoir une console de gestion apache avec mod_php.

              Et il faut aussi se taper à la main l'import des users dans le ldap, se taper à la main la config de pam pour pam_nufw.

              Alors que des solutions d'intégrations directes dans ldap existe ( au moins chez redhat, novell, et mandriva, et sans doute chez ubuntu, j'ai pas vérifié ), il n'y a rien du tout pour l'intégration rapide de nufw ( même si rh a regardé de ce coté il y a un an ).

              Donc non, je pense que nufw n'est pas (encore) intégré dans les produits libres connus, en dehors du livecd de démonstration.
              • [^] # Re: syntaxe similaire à pf

                Posté par . Évalué à 2.

                Me suis exprimé comme un pied (côté noyau, il aurait été peut être plus adéquat de parler de "possibilité pour un serveur"), malgrès cela, c' est bien ça, oui.

                Et il ne s' agit pas seulement d' une intégration "paquet installé par défaut et pré-configuré" mais bien d' arrêter cette notion de couche : une couche au dessus de netfilter, et une couche au dessus de l' utilisateur. Que la partie firewall soit intégré directement à NFtables, et de l' autre côté que le client soit un module pam_ (sur lequel s' ajoute une authentification pam/ldap/etcetc, c est autre chose. Avec une pré-configuration c' est le bonheur, et avec des pré-scénarios de fonctionnements, alors là c' est le nirvana. Mais "plus simplement" pas une pré-conf mais (au moins avant...) une intégration système et pas ces sur-couches)

                Ca serait plus que pas mal qu' il puisse devenir plus qu' un complément : une pièce 'mainline'.

                Bon désolé d' être intervenu sur un sujet aussi technique et aussi particulier; j' espère pas avoir trop fait baisser le niveau des commentaires, et j' espère surtout ne pas avoir refroidi ceux souhaitant balancer des commentaires documentés et argumentés. Merci d' avoir pris le temps de répondre. Au plaisir de vous lire. A+
            • [^] # Re: syntaxe similaire à pf

              Posté par (page perso) . Évalué à 2.

              La différence entre authpf et NuFW est qu'authpf associe une IP à un utilisateur, ce n'est pas le cas dans NuFW. Enfin, corrigez moi si je dis une bétise.

              authpf-noip :
              http://www.openbsd.org/cgi-bin/man.cgi?query=authpf-noip
              http://undeadly.org/cgi?action=article&sid=2008032414100(...)
  • # netfilter dans tout ça ?

    Posté par . Évalué à 2.

    Si je ne m'abuse iptable est la partie dans l'espace utilisateur du firwall et netfilter la partie en espace noyau.

    Qu'adevient-il de netfilter avec ces changements en user-space.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Linux ou comment on utilisait de la merde pendant 10ans...

    Posté par . Évalué à 3.

    Depuis à peu près 2 ans, c'est carrément l'auto-flagéllation dans le monde du libre.

    Pendant des années on ventait les mérites de Linux pour faire son firewall/passerelle/routeur de la mort qui tue et vlan, voilà que "maintenant" on présente iptables/netfilter comme étant lourd, monolithique, ergonomiquement rigide etc... etc...
    Perso je connais pas, j'utilise NetBSD ces usages.

    C'est pareil avec la gestion mémoire, un coup c'est Linux gère la mémoire mieux que... et quand une nouvelle release du noyau sort c'est comme si on avait toujours utilisé que de la merde. :)
    Gallium maintenant, on se rend compte à quel point c'était chaotique dans le monde des puces graphiques.
    Je passe le passage sur le WiFi qui n'a jamais autant été le point noir du monde linux - que ça soit noyau ou userland - et pourtant combien d'article je n'ai pas lu ventant Linux comme parfaite platforme pour mettre en place des AP, y a accèder etc...

    Bref, j'ai vraiment l'impression d'avoir affaire aux marketeux d'Intel à chaque refonte d'un code :)
    • [^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...

      Posté par (page perso) . Évalué à 3.

      C'est justement cette capacité de remise en question qui fait que Linux est plus populaire que BSD ;)

      IPtables mange plusieurs centaines de mega octets par secondes, et plusieurs dizaines de milliers de connexions simmultannées sur pas mal de GROS sites. Mais non, c'est pas encore assez bien, alors on continue d'améliorer. C'est pas beau ca ?
    • [^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...

      Posté par (page perso) . Évalué à 7.

      Il y a aussi le fait que la technologie et les usages évoluent.

      On dit que iptables est lourd mais pour des gros besoins qu'il n'y avaient pas forcément avant ou pour des cas particuliers. Même chose pour la gestion de la mémoire, ça mettait du temps quand tu avais des centaines de gigas de RAM (ce qui n'est, même actuellement, pas encore mon cas), il y a plusieurs années, ça servait à rien et personne n'aurait penser au problème mais maintenant que la technologie a avancé, on se rend compte que dans ce cas là c'est gênant. Et de même pour les cartes graphiques, elles ont des besoins qu'elle n'avaient pas avant et en plus, il y a de plus en plus de pilote libre, ce qui permet de se rendre compte des erreurs.

      Je suis sûr que NetBSD a déjà réimplémenter des fonctions car ils se sont rendu compte que ça ne correspondait plus aux usages. (mais comme je ne lis pas les changelog NetBSD et qu'il n'y a pas de patrick_g-*-BSD, je ne peux pas de dire lesquels).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...

        Posté par . Évalué à 2.

        Je suis sûr que NetBSD a déjà réimplémenter des fonctions car ils se sont rendu compte que ça ne correspondait plus aux usages. (mais comme je ne lis pas les changelog NetBSD et qu'il n'y a pas de patrick_g-*-BSD, je ne peux pas de dire lesquels).

        Il y a régulièrement des refontes, mais quand celles-ci touchent aux interfaces userland <> kernel, elles sont toujours rétro compatibles (y compris au niveau binaire). On maintient donc plusieurs versions, via les COMPAT_*, qui peuvent remonter très loin (jusqu'à la 0.8). A ma connaissance, il n'y a que NetBSD et Solaris qui fassent cet effort et qui peuvent remonter aussi loin.

        En revanche, quand ca a lieu à l'intérieur du noyau et que ca reste dans son namespace, ou que les changements ne sont pas visibles directement par une interface "OS" (syscalls) on le fait. Quand les changements ont des impacts au niveau binaire (time_t 32 => 64 par exemple), on versionne les syscalls.

        Avantages/inconvénients: avec le temps, il y a eu de gros efforts de faits sur la propreté et les couches d'abstractions (aide beaucoup pour la qualité, la doc et la portabilité). Inconvénient, les implémentations doivent arriver à un consensus, et ca peut prendre beaucoup du temps (on a l'impression que le projet stagne).

        Mais le cas des BSD est assez différent de Linux niveau implémentation de la couche réseau. Les BSD préfèrent passer par des ioctl sur des devices (quitte à retravailler les commandes avant de les soumettre, cf ipf(4), pf(4), bpf(4)), tandis que Linux a choisi d'exposer son infra interne via le bloat abracadabrantesque qu'est /proc. C'est très commode à court terme, mais ca finit généralement par exploser en vol quand on doit rajouter des fonctionnalités sur le long terme. Je pense d'ailleurs que c'est le cas ici, et je trouve le choix sage (surtout niveau syntaxe, enfin...)
  • # Ha ba tiens !

    Posté par (page perso) . Évalué à 3.

    Ba, de rien pour la news ! C'était initialement un billet sur mon blog :
    http://jve.linuxwall.info/blog/index.php?post/2009/03/23/nft(...)
    et je pensais pas que ca valait la peine d'en faire une dépêche... mais bon, si ca intéresse des gens, c'est cool :)
    • [^] # Re: Ha ba tiens !

      Posté par (page perso) . Évalué à 6.

      >>> je pensais pas que ca valait la peine d'en faire une dépêche.

      Ne jamais penser ça. Toujours proposer la news.
  • # Temps perdu

    Posté par . Évalué à -2.

    Développer un firewall de plus alors qu'il y a déjà l'excellent pf c'est du temps perdu.
    Ca va juste donner un produit dont les capacités -à terme- vont venir s'intercaler entre iptables et pf. Et vlan une nouvelle syntaxe différente de ce qui existe à se taper.
    Alors qu'il aurait été quand même beaucoup plus simple de porter pf sur linux.

Suivre le flux des commentaires

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