Mais comment ca marche ???

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

  Posté par _gryzor_ () le 30/05/2006 à 18:37. (lien). É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 Id2ndR () le 31/05/2006 à 07:24. (lien). É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 Victor STINNER (page perso, ) le 31/05/2006 à 09:09. (lien). É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 Jean () le 31/05/2006 à 09:12. (lien). É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 Erwann Robin (page perso, ) le 31/05/2006 à 17:13. (lien). É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 Eric Leblond (page perso, ) le 31/05/2006 à 17:20. (lien). É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 Matthieu Moy (page perso, ) le 01/06/2006 à 06:57. (lien). É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 tontonflingueur () le 01/06/2006 à 07:36. (lien). É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 Matthieu Moy (page perso, ) le 31/05/2006 à 06:01. (lien). É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 naotemp () le 31/05/2006 à 06:31. (lien). É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 tontonflingueur () le 31/05/2006 à 11:59. (lien). É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 Victor STINNER (page perso, ) le 31/05/2006 à 13:10. (lien). É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 tontonflingueur () le 31/05/2006 à 14:18. (lien). É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 _gryzor_ () le 31/05/2006 à 18:06. (lien). É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 tontonflingueur () le 01/06/2006 à 07:17. (lien). É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.