Compte rendu en temps réel de l'atelier Netfilter 2007

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
12
sept.
2007
Sécurité
Le Netfilter Workshop 2007 vient d'ouvrir sa cinquième édition à Karlsruhe, en Allemagne. Ces rencontres ont lieu tous les 2 ans et permettent aux développeurs du projet Netfilter de se rencontrer pour définir les orientations du projet Netfilter, et également d'avancer sur les mises à jour de technologies à venir.

La première présentation a été réalisée par Patrick McHardy où il détaille version noyau par version noyau les avancées de Netfilter.

L'évènement se déroule du 11 au 14 septembre. Tout comme en 2005, un compte rendu est proposé par INL, sponsor de l'évènement. Le site est mis à jour en temps réel en suivant les différentes présentations des intervenants.

NdM Le projet Netfilter vise à fournir des solutions de firewall sous GNU/Linux via notamment l'outil iptables.

Aller plus loin

  • # Merci

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

    Très intéressant. Malheureusement je constate que ct_sync est encore bloqué
    "Malheureusement, le projet n’a guère évolué depuis l’année dernière à cause du manque de temps et de développeurs"

    Il existe maintenant d'autres projets, j'ai l'impression que ça part dans tous les sens.
    Je me demande si je verrais un jour un systéme de réplication de session parfaitement fonctionnel sous Linux, de préférence intégré au projet netfilter.

    Il ne manque plus que ça pour la HA de mes pare-feux netfilter

    Dommage d'autant que ça fonctionne bien sous d'autres OS

    • [^] # Re: Merci

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

      Cela avance effectivement vite actuellement.

      conntrackd de Pablo Neira, membre de la Coreteam de Netfilter, est d'ors et déjà intégré à Netfilter puisqu'il se base sur du code déjà existant au niveau noyau.

      Le projet est utilisable et n'attends plus que les utilisateurs.

  • # Changement de leader de la Netfilter Coreteam

    Posté par  . Évalué à 2.

    On apprend que Harald Welte laisse la place à Patrick McHardy à la tête du projet.

  • # Module owner

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

    A une époque, le module owner permettait de rajouter dans une règle quelque chose du type

    -m owner --cmd-owner 'http'

    J'utilsais cela sur mes serveurs debian pour que seul apt-get (et donc le sous processus de nom 'http') puisse allez sur le net chercher les mises à jour.

    Certes, un utilisateur pouvait renommer lynx en http mais en pratique, il ne le faisait pas.

    Bref, même si ce n'était pas super bien carré, je trouve que cela limitait pas mal ce qui était possible et donc ne pouvait qu'améliorer la sécurité tout en restant simple et clair.

    Dommage que celui-ci ne fonctionne plus de nos jours. Je n'ai pas trouvé d'équivalent pour le moment.

    • [^] # Re: Module owner

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

      La solution plus carré mais plus lourde à mettre en place est le parefeu NuFW :-)

      • [^] # Re: Module owner

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

        Cela, je l'avais bien compris ! Mais il faut avouer que le module owner était simple, rapide et marchait pas si mal pour 95% des cas. Bref, c'était un bon compromis à mon sens.

        • [^] # Re: Module owner

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

          Pour montrer le simplicité du module, juste un exemple que j'avais mis sur mes postes utilisateurs concernant acrobat. En effet, ce logiciel n'étant pas libre, on pouvait le suspecter d'aller sur le net à la solde d'adobe...

          iptables -A OUTPUT --m owner --cmd-owner 'acroread' -j DROP

          Voila, c'est tout bête mais en pratique, ca marchait. Je faisais cela avec tous les logiciels propriétaires que je devais installer sur les postes et finalement, il n'y en a pas tant que cela.

    • [^] # Re: Module owner

      Posté par  . Évalué à 1.

      cette extension netfilter 'owner' n'etait malheureusement pas fonctionnelle sur les machines SMP, d'ou son retrait.

      Il existe un projet qui va plus loin dans cette idée, il se nomme network events connector http://www.synack.fr/project/cn_net/cn_net.html

      Il pourrait clairement, d'apres ce que j'ai compris, etre utilisé pour faire un pare-feu personnel "maison", mais en tant qu'admin, je vois bien comment l'utiliser dans un reseau.

      Le code est tres simple, et pour le moment les regles sont stockées dans une base de données SQL (postgresql ou sql), on est loin de cette usine a gaz qu'est nufw..

      d'apres l'auteur, il reste beaucoup de choses, a faire, mais ce systeme de pare feu est fonctionnel, faut voir ce que va donner ce projet

      • [^] # Re: Module owner

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

        > cette extension netfilter 'owner' n'etait malheureusement pas
        > fonctionnelle sur les machines SMP

        Oui je le savais, même si je ne vois pas bien le rapport entre ce module et le SMP...

        > Le code est tres simple, et pour le moment les regles sont stockées
        > dans une base de données SQL

        Je ne suis pas sur que cela soit des plus simple de faire un pare-feu avec postgresql par derrière... Cela ne me tente pas du tout d'installer un serveur SQL sur tous mes postes ! Si c'est SQLite, c'est différent, c'est juste une autre manière que d'utiliser la Berkeley DB et en plus, on peut utiliser une autre DB au cas ou...

        > d'apres l'auteur, il reste beaucoup de choses, a faire, mais ce
        > systeme de pare feu est fonctionnel,

        Même si j'en comprends l'esprit, ta phrase n'est quand même pas claire dans l'absolue.

        Dans la pratique, je pense que nufw est intéressant mais avoir un pare-feu local à chaque poste est bien aussi. Surtout que pour moi il est facile avec cfengine de configurer 50 ou 100 postes ;-)

        • [^] # Re: Module owner

          Posté par  . Évalué à 1.

          >> cette extension netfilter 'owner' n'etait malheureusement pas
          >> fonctionnelle sur les machines SMP

          > Oui je le savais, même si je ne vois pas bien le rapport entre ce module et le SMP...

          Cest un probleme de lock: pour connaitre le owner, l'astuce de l'extension c'est d'aller cherche la structure "file" relative au paquet skbuff, mais cependant, on ne peut pas "locker" cette structure pour l'utiliser depuis les "bottom halves" du kernel en SMP

          >> Le code est tres simple, et pour le moment les regles sont stockées
          >> dans une base de données SQL

          > Je ne suis pas sur que cela soit des plus simple de faire un pare-feu avec
          > postgresql par derrière... Cela ne me tente pas du tout d'installer un serveur SQL
          > sur tous mes postes ! Si c'est SQLite, c'est différent, c'est juste une autre
          > manière que d'utiliser la Berkeley DB et en plus, on peut utiliser une autre DB au
          > cas ou...

          Non l'idée de la base de données, c'est surtout qu'elle soit centralisée pour tous les postes bien sur.
          Par contre pour une utilisation en station desktop, il existe un support sqlite3 effectivement.

          > > d'apres l'auteur, il reste beaucoup de choses, a faire, mais ce
          > > systeme de pare feu est fonctionnel,

          > Même si j'en comprends l'esprit, ta phrase n'est quand même pas claire dans
          > l'absolue.
          Oui, virgule en trop.
          Je voulais simplement dire que l'auteur pense encore beaucoup travailler dessus, mais il estime que l'architecture de base (notament la communication/le protocole kernel<->userspace) est stable
          Son but est de faire mergrt ce systeme dans le kernel officiel.

          > Dans la pratique, je pense que nufw est intéressant mais avoir un pare-feu local
          > à chaque poste est bien aussi. Surtout que pour moi il est facile avec cfengine
          > de configurer 50 ou 100 postes ;-)

          Oui une des idées que je trouve tres interessante dans ce projet, c'est la possibilité que des machines d'un meme sous reseau puisse quand meme avoir une defense entre elles, ie un systeme de filtrage.

          • [^] # Re: Module owner

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

            > Oui une des idées que je trouve tres interessante dans ce projet,
            > c'est la possibilité que des machines d'un meme sous reseau puisse
            > quand meme avoir une defense entre elles, ie un systeme de filtrage.

            Je pense personnellement que l'on va tendre vers ce modèle. Avec la recentralisation des données sur des serveurs bien identifiés, il n'y a aucune raison que les machines se fassent confiance entre-elles.

            Sur un réseau local, les machines ne devraient parler qu'aux serveurs ! C'est en partie ce qui me gène dans nufw, il ne résoud pas complètement la problématique.

Suivre le flux des commentaires

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