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.

Le client ...

• [^]Re: Le client ...

  Posté par Victor STINNER (page perso, ) le 30/05/2006 à 19:09. (lien). É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

• [^]Re: Version 2.0.1

  Posté par _gryzor_ () le 30/05/2006 à 20:07. (lien). É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

• [^]Re: client windows commercial

  Posté par Sytoka Modon (page perso, ) le 31/05/2006 à 08:58. (lien). É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 naotemp () le 31/05/2006 à 09:21. (lien). É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 Xavier Poinsard (page perso, ) le 31/05/2006 à 08:59. (lien). Évalué à 4.

  Quand windows sera open source... ?

  • [^]Re: client windows commercial

    Posté par outs () le 31/05/2006 à 15:25. (lien). Évalué à 1.

    Bientôt : http://www.reactos.org/xhtml/fr/index.html :)
    
    Je ------->[]

• [^]Re: client windows commercial

  Posté par naotemp () le 31/05/2006 à 09:16. (lien). É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 bbou () le 02/06/2006 à 15:38. (lien). É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 _gryzor_ () le 02/06/2006 à 16:30. (lien). É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 !