NuFW 2.0, nouvelle version majeure du pare-feu authentifiant

Posté par (page perso) . Modéré par Nÿco.
Tags :
0
30
mai
2006
Sécurité
NuFW 2.0 est officiellement disponible depuis peu. Cette nouvelle version du pare-feu authentifiant est le résultat de près d'un an de développement.

Les améliorations par rapport à la précédente branche stable (1.0) sont donc nombreuses :
  • Gestion de vraies règles d'accès horaires
  • Plus d'interactivité avec l'utilisateur final (rejet ICMP par exemple)
  • Module PAM pour une transparence complète sous GNU/Linux
  • Utilisation des toutes dernières fonctionnalités de Netfilter

Les lecteurs de Linux Magazine pourront d'ailleurs trouver dans le numéro de Juin un article consacré à NuFW. Pour rappel, NuFW est un pare-feu authentifiant disponible sous GPL : il réalise l'authentification des connexions passant à travers le filtre IP. Des politiques de sécurité telles que : « Bill peut se connecter au serveur imap si il utilise Mozilla sous Linux 2.6.16 » peuvent être implémentées au moyen d'une règle d'accès NuFW unique.

Cette nouvelle mouture apporte son lot de nouveautés :
  • Journalisation des session utilisateurs : on peut maintenant savoir quand et depuis où se sont connectés les utilisateurs
  • Règles d'accès par rapport au temps : NuFW gère l'établissement des connexions suivant un période de temps, mais aussi leur destruction à la fin de la plage horaire
  • Module de journalisation Prelude : l'ensemble des événements peut maintenant être centralisé dans l'IDS
  • Module PAM pour une authentification transparente sous GNU/Linux
  • Rechargement dynamique de la configuration : un signal SIGHUP permet de réinitialiser les démons et leurs modules
  • Messages de rejet ICMP : l'utilisateur peut maintenant être prévenu du blocage des paquets
  • Utilisation des dernières fonctionnalités de Netfilter : NuFW coopère avec libnetfilter_queue et libnetfilter_conntrack, ce qui a permis le développement de certaines des nouvelles fonctionnalités. Attention, un noyau >= 2.6.16.18 est recommandé. Il est souhaitable d'appliquer les patchs disponibles sur le site de NuFW pour un maximum d'efficacité. Ils seront contenus dans la version 2.6.18 du noyau.

Aller plus loin

  • # Mais comment ca marche ???

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

    je me demandais comment cela était possible, sachant qu'on parle de passerelle éloignée, pas d'un firewall personnel. Comment fait-il pour repérer l'application et l'utilisateur à l'origine d'une connexion ?

    En contrepartie de ces fonctionnalités, il est nécessaire d’utiliser un client logiciel [1] sur chaque système du réseau. Nous travaillons à implémenter une solution pour chaque système (actuellement, des clients pour GNU/Linux et Windows sont implémentés).

    Bravo pour ce travail, j'espère qu'il sera accepté par les entreprises, les cibles les plus pertinentes de ce type de logiciel.
    et il est développé par INL, encore un éditeur de logiciel français !

    NB: est-ce qu'on peut envisager de l'utiliser sur une machine personnelle comme firewall applicatif ?
    • [^] # Re: Mais comment ca marche ???

      Posté par . Évalué à 10.

      NuFW peut être utilisé en local. Mais tu trouveras peut-être cela un peu lourd par rapport aux extensions Netfilter qui permettent de faire la même chose (uniquement en local, bien sûr / cf uid-owner). Cela dit ça marche, et on le fait notamment pour tests/proof of concept.

      En tous cas, merci pour tes encouragements! Nous sommes très fiers chez INL de montrer que le libre est un vecteur d'innovation, grâce à ce projet.

      Pour info, un client Mac a été développé (et est dispo sous GPL) depuis la rédaction de l'annonce que tu as collée dans ton commentaire ;)
      • [^] # Re: Mais comment ca marche ???

        Posté par . Évalué à 2.

        NuFW peut être utilisé en local.

        Pourrais-tu nous donner les extensions à utiliser pour faire du filtrage au niveau des applications avec netfilter sur une machine local ?

        N'ayant encore jamais utilisé Netfilter (donc aucune extension non plus), j'aimerai bien des liens éventuels vers des tutoriaux de configuration existants.
        • [^] # Re: Mais comment ca marche ???

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

          filtrage au niveau des applications

          Hum, typiquement, on peut filtrer sur le port destination. Un navigateur utilise les ports 80 et 443 (https), 110 pour POP3, 6667 pour IRC, etc. Liste un peu plus longue par ici :
          http://www.haypocalc.com/wiki/Liste_des_ports_TCP_et_UDP

          Et la liste de l'IANA (c'est eux qui attribuent les numéros de port) :
          http://www.iana.org/assignments/port-numbers

          Mais la réalité est un peu plus floue : les applications peuvent utiliser un autre port (les clients P2P utilisent un peu tout et n'importe quoi), il existe des proxys, des tunnels, etc.

          Pour reconnaître une application selon son traffic et non pas les ports, on peut utiliser une suite de motifs pour reconnaître une application. Euh ... j'ai pas trop d'exemple ... disons "GET HTTP/1.1" pour une requête HTTP par exemple. Il existe plusieurs projets pour Netfilter pour réaliser ça ... mais j'ai plus les noms en tête. Sous Linux, on peut remonter un paquet en espace utilisateur (avec la rêgle QUEUE) : il existe, par exemple, un programme en Perl (!) pour lancer des regex dessus.

          Tout ceci est expliqué dans un article du magazine MISC dispo dans toutes les librairies.

          Haypo
          • [^] # Re: Mais comment ca marche ???

            Posté par . Évalué à 3.

            on peut utiliser une suite de motifs pour reconnaître une application. Euh ... j'ai pas trop d'exemple ... disons "GET HTTP/1.1" pour une requête HTTP par exemple. Il existe plusieurs projets pour Netfilter

            Le projet L7-filter permet cela: http://l7-filter.sourceforge.net/
            • [^] # Re: Mais comment ca marche ???

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

              et comment font les parefeux windows pour filtrer l'accès au net par application ?

              (le parefeu intégré de windows ou zone alarm demandent d'autoriser l'accès au net ou pas à chaque fois q'une nouvelle appli essaye de se connecter)
              • [^] # Re: Mais comment ca marche ???

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

                Ils font :
                connexion->socket->application->comparaison dans base->demande si pas dans base.

                Pour voir si une appli est dans la base et n'a pas changé, c'est un md5sum sur le binaire.

                Cette méthode ne vaut bien sûr que pour un pare-feu personnel (local)
          • [^] # Re: Mais comment ca marche ???

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

            Si j'ai bien compris, ce n'est pas de ça qu'il s'agit. Ça serait plutôt : autoriser MSIE à accéder au site, et bloquer les firefox.

            En local, je ne sais plus comment ça se fait en pratique, mais le noyau peut retrouver quel est l'executable à l'origine d'une connection assez facilement, donc no problem. Par contre, à distance, on a juste les paquets TCP et il faut faire avec, donc, c'est là qu'il faut rajouter une couche, et c'est là qu'il y a forcément un maillon de la chaine de confiance chez le client, qui dit « Ouais, j'ai vérifié, c'est bien un MSIE, laisses-le passer ».

            Au passage, si c'était Microsoft qui avait fait ce genre de trucs, et qui l'avait appelé Palladium ou NGSCB, on aurait eu beaucoup moins d'éloge sur ce site ...
            • [^] # Re: Mais comment ca marche ???

              Posté par . Évalué à 7.

              Si c'était Microsoft ou la plupart des autres vendeurs de logiciels propriétaires, on aurait dans la description du projet un simple message marketing du genre "la solution ultime pour sécuriser votre réseau d'entreprises", avec aucune discussion sur les limites, ni aucune description des mécanismes utilisés.

              "Dormez, braves administrateurs, nous nous occupons de votre sécurité". Moi je trouve qu'un grand avantage du logiciel libre, c'est une certaine transparence. Rien qu'en regardant la page web du projet tu te fais une idée de ce qui marche, de ce qui ne marche pas (ou pas encore).

              En plus maintenant, les vendeurs de logiciels propriétaires ne vendent même plus de softs, ils vendent des "solutions"... On ne comprend même plus ce que font les produits qu'ils vendent. Un exemple parmi d'autres : http://www.macrovision.com/. maximize the value of your content and software wouah ! TIens c'est nos amis justement :ils sont spécialisés dans le DRM. Ils affirment pouvoir sécuriser les DVD même vis-à-vis de deCSS, tout en continuant à fonctionner sur la majorité des lecteurs autorisés existants. Comment ? Mystère ?
    • [^] # Re: Mais comment ca marche ???

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

      Attention quand même avec cette solution : une partie de la chaine de confiance se trouve chez le client. Si l'utilisateur a le contrôle de la machine cliente, il peut contourner les protections.
      • [^] # Re: Mais comment ca marche ???

        Posté par . Évalué à 4.

        Cette confiance n'est accordée en fait au client que sur la partie déclaration de l'application à l'origine de la connexion. C'est d'ailleurs l'objet d'une des interventions au SSTIC de Rennes cette semaine me semble t il que de parler de cette limitation.

        En jettant un coup d oeil à l'algo tu verras que les coeur des fonctionnalités (authentification des connexions) est lui géré par le serveur d'authentification (déporté), lui même connecté via PAM à la base d'utilisateurs existante (en général LDAP ou AD). Un client corrompu ne pourrait s'authentifier si il n'est pas lancé avec des informations de compte valides, vérifiées par ce serveur d'authentification.
        • [^] # Re: Mais comment ca marche ???

          Posté par . Évalué à 2.

          Moi aussi j'étais un peu gêné par cette limitation.

          Finalement le problème c'est que sur une machine multi-utilisateurs, tu peux faire tourner un client pirate pour voler les connexions de tes petits camarades (seulement ceux qui sont actuellement connectés sur la même machine, ce qui n'est pas mal).

          Je pense que pour éviter que sur une même machine des utilisateurs d'une application de single sign on ne se volent les sessions les uns les autres, il faut d'une certaine manière faire confiance aux clients. Regarde Kerberos par exemple, tu pourrais imaginer que le programme d'acquisition des tickets (kinit) es mal foutu, et qu'il va stocker tous les tickets dans /tmp avec les droits 777 . Dans ce cas les utilisateur peuvent se piquer leurs sessions les uns aux autres. Donc, quelque part le problème pour éviter le vol de sessions entre les utilisateurs d'une même machine cliente est le problème de l'administrateur de la machine cliente. Naturellement root peut voler tous les sessions de tout le monde avec su mais ça on ne peut pas y faire grand chose.

          Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se chargerait de faire le chef d'orchestre, et de certifier que la connexion ouverte sur TCP sur le port 15722 a bien été ouvert par l'utilisateur fblanche (par exemple) ? Je ne sais pas si c'est possible, et en outre j'ai l'impression que ce client ne serait pas portable sur tous les systèmes, mais bon voilà pour mes suggestions à 2 francs 50.

          @+
          • [^] # Re: Mais comment ca marche ???

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

            Ouh là, ça devient compliqué ...

            Finalement le problème c'est que sur une machine multi-utilisateurs, tu peux faire tourner un client pirate pour voler les connexions de tes petits camarades

            Hum ... tu veux dire que le client pirate répond "c'est moi qui ait ouvert la connexion" puis arrive à récupérer les paramètres de la socket (IP + TCP/UDP) ? Sous Linux, je vois mal comment récupérer les paramètres d'une socket TCP/IP, et donc la voler. De plus, ceci suppose que le pirate soit authentifié auprès de nuauth ... donc qu'il ait un compte ou volé un compte.

            Je pense que pour éviter que sur une même machine des utilisateurs d'une application de single sign on ne se volent les sessions les uns les autres, il faut d'une certaine manière faire confiance aux clients. (...) Dans ce cas les utilisateur peuvent se piquer leurs sessions les uns aux autres.

            Je pense que le seul risque est que le client donne des informations erronées sur le nom de l'application qui a ouvert la connexion. Par contre, une connexion est associée à un utilisateur (et non pas à une IP) de manière sûre. En effet, un tunnel TLS est monté lorsque le client s'authentifie.

            Nufw authentifie chaque nouvelle connexion. Le SSO est réalisé du côté serveur et non d'une information venant du côté client. Contrairement à Kerberos, il n'y a aucun ticket sur le poste de travail.

            Naturellement root (...)

            Root a tous les droits oui. Installer un pare-feu c'est une chose, mais la sécurité ne doit pas se résumer à ça. Il faut former tout le monde pour éviter le social engineering :-)

            Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se chargerait de faire le chef d'orchestre, (...)

            Je ne vois pas en quoi ça serait un plus niveau sécurité. Ou alors je n'ai pas saisi la subtilité ?

            --

            J'ai peut-être répondu à côté de la plaque, mais le problème n'est pas simple et je ne suis pas sûr d'avoir compris ton commentaire :-)

            Haypo
            • [^] # Re: Mais comment ca marche ???

              Posté par . Évalué à 4.

              > De plus, ceci
              > suppose que le pirate soit authentifié auprès de nuauth ... donc qu'il
              > ait un compte ou volé un compte

              Oui je suppose que le "pirate" est un utilisateur légitime de nufw qui veut voler la connexion d'un autre utilisateur sur la même machine.

              > Hum ... tu veux dire que le client pirate répond "c'est moi qui ait
              > ouvert la connexion" puis arrive à récupérer les paramètres de la
              > socket (IP + TCP/UDP) ? Sous Linux, je vois mal comment récupérer
              > les paramètres d'une socket TCP/IP, et donc la voler.

              C'est ça un "yes-client" en quel que sorte. Tu as raison, les paramètre de la socket vont rester attachés à l'utilisateur, donc
              tout ce que va avoir gagné notre pirate, c'est que la connexion ouverte par l'utilisateur va récupérer les credentials du pirate, et je doute que ça lui soit très utile.

              Honnêtement, c'est vraiment bien pensé ce truc ...
          • [^] # Re: Mais comment ca marche ???

            Posté par . Évalué à 3.

            >Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne >serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se >chargerait de faire le chef d'orchestre, et de certifier que la connexion ouverte sur TCP sur le port >15722 a bien été ouvert par l'utilisateur fblanche (par exemple) ?

            Idée séduisante sur le papier, mais qui demande une [trop?] grande confiance au poste client.
            Nuauth n'a aucun moyen de savoir que ce client tourne en root, puisque tout se passe à distance.
            C'est évidemment envisageable mais de mon point de vue c'est trop de confiance dans le client.
            L'approche "forcer l'authentification de chaque utilisateur" est plus sécurisante à mon sens. C'est bien sûr discutable :)
            • [^] # Re: Mais comment ca marche ???

              Posté par . Évalué à 2.

              > L'approche "forcer l'authentification de chaque utilisateur" est plus
              > sécurisante à mon sens. C'est bien sûr discutable :)

              Bien sûr. Moi, je parlais juste de la phase ultérieure où sur une machine multi-postes - donc avec plusieurs utilisateurs authentifiés sur Nuauth - il s'agit de repérer à quel utilisateur associer la nouvelle connexion.

              > Idée séduisante sur le papier, mais qui demande une [trop?] grande
              > confiance au poste client.

              Et justement, c'est le client qui disait : c'est moi qui ai ouvert cette connexion. Donc, je trouvais que c'était un point faible mais Victor a levé une partie de mes doutes.
  • # Le client ...

    Posté par . Évalué à 2.

    Pourquoi ne pas surcharger le paquet avec l'authentification (application, uid) cela supprimerai le client? Le pare-feu retirant ensuite cette partie du paquet. Évidement c'est pas portable.

    Autre idée. Pourquoi ne pas attribué une ip par utilisateur?
    • [^] # Re: Le client ...

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

      Pourquoi ne pas surcharger le paquet avec l'authentification (application, uid) cela supprimerai le client?

      Hum, je vois mal comment faire pour ajouter ces informations sans aller triffouiller dans le noyau (kernel Windows / Linux). De plus, un pirate se fera un plaisir d'utiliser uid=0 par exempe :-)

      Autre idée. Pourquoi ne pas attribué une ip par utilisateur?

      Parce qu'une IP est "facilement" spoofable ? De plus on peut avoir plusieurs personnes qui ont la même IP, voir une personne mobile (avec un pc portable) qui change d'IP ...

      Haypo
  • # Version 2.0.1

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

    La 2.0.1 est sortie...

    NuFW est vraiment un projet super qui doit êre, à mon avis, intégré au plus vite dans nos architectures. C'est vraiment formidable ce que l'on peut faire avec.

    Juste une question, dans la 2.0.1, il est annoncé des corrections sur les paquets debian mais où sont-ils les fameux paquets ? Sur le site, on ne trouve que ceux de la version 1.0.25.

    Bonne continuation.
    • [^] # Re: Version 2.0.1

      Posté par . Évalué à 8.

      Pour l'instant nous n'avons pas mis de paquets debian à disposition sur le repository (http://www.nufw.org/debian), pour la raison qu'ils ne sont pas encore finalisés ni testés.

      L'infrastructure de construction des paquets debian est cependant tenue à jour directement dans l'archive 2.0.1, et il est donc possible de générer des paquets debian facilement à partir des sources.

      Nous acceptons les contributions pour améliorer cette structure et amener les paquets debian dans un état bien stable :)

      Merci pour ces encouragements !
  • # client windows commercial

    Posté par . Évalué à 1.

    A noter que le client windows n'est pas opensource, ce que je comprends d'un point de vue économique, mais déplore d'un point de vue personnel.

    Est-ce que l'ouverture des sources est prévue pour cette partie ?
    • [^] # Re: client windows commercial

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

      Ce serait bien qu'il puisse être utilisé librement dans l'éducation nationale et le supérieur ;-)
      • [^] # Re: client windows commercial

        Posté par . Évalué à 1.

        Si tu fais partie de l'enseignement supérieur et recherche je peux t'inviter à demander à ton CRI les informations sur EdenWall (intégration complète basée sur NuFW) et le client Windows car un accord a été signé entre INL et le Groupe Logiciel le 25 janvier. Sinon une fois de plus le client pour OS GPL est GPL ;-)
    • [^] # Re: client windows commercial

      Posté par . Évalué à 4.

      Quand windows sera open source... ?
    • [^] # Re: client windows commercial

      Posté par . Évalué à 10.

      Le modèle économique et éthique est de proposer des clients GPL pour des OS GPL/BSD ou assimilés (client en ligne de commande libre pour mac os X) et des clients propriétaires pour les OS propriétaires. C'est tellement catastrophique de développer pour MS-Windows que le faire en GPL est impensable.

      En plus, c'est un moyen supplémentaire faire passer les gens au 100% libre car on peut dire "Vous avez exactement les même fonctionnalités sous GNU/Linux que sous MS-Windows". A chacun d'assumer ses choix ... D'ailleurs si tout le monde faisait pareil il y aurait beaucoup plus de remises en questions en faveur du libre au niveau du poste de travail.
      • [^] # Re: client windows commercial

        Posté par . Évalué à -1.

        J'ai peur que cela soit moins tranché (ce n'est pas le lieu de ce débat). Je note que, outre le client Windows, le vraisemblable module nuauth pour Kerberos/Active Directory est resté sous le coude. Le résultat est que le système n'est pas librement interopérable (au sens où Samba peut l'être) avec Windows. Dommage ! Car dans certains environnements c'est incontournable (dans un lycée). A moins que quelqu'un n'écrive un client libre pour Windows : libsasl, gnutls sont portés -- et d'ailleurs statiquement liés au client de demo, apparemment--, reste à écrire la collecte des infos de connexions (SNMP ou WMI ?). Avant d'entreprendre, il faudrait être sûr qu'un client malicieux ne puisse pervertir le système en renvoyant de fausses informations (y-a-til eu une évaluation indépendante ?). Ceci dit, je comprends aussi que INL puisse traire la vache Windows pour rentabiliser ses investissements, tant mieux. On doit aussi les remercier pour leur contribution.
        • [^] # Re: client windows commercial

          Posté par . Évalué à 3.

          Euh, quel vraisemblable module Kerberos/Active Directory?
          Nuauth parle PAM, donc il n'y a rien de caché. INL publie 100% de nufw/nuauth et des clients pour OS libres.

          Le système est donc aussi librement interopérable avec Windows que Samba : seule la partie Windows est propriétaire, comme pour Samba ;)

          Pour ce qui concerne les fausses informations client<->nuauth, le protocole est ouvert, et nous pensons qu'il est robuste (nous avons mis du temps pour le concevoir, en pensant aux problème possibles). Tu es libre, comme chacun l'est, de réaliser une évaluation indépendante !

Suivre le flux des commentaires

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