Re: Première version publique de NuFW

• [^]Re: Première version publique de NuFW

  Posté par lordcow () le 02/09/2003 à 11:42. (lien). Évalué à 1.

  C'est ce que j'ai compris aussi.
  Si il faut un client sur chaque machine, c'est un peu lourd. ( cela dis, c'est surement plus pratique que SOCKS)

  --
  Je est un autre.

  • [^]Re: Première version publique de NuFW

    Posté par Strass (page perso, ) le 02/09/2003 à 13:51. (lien). Évalué à 1.

    C'est un peu lourd, mais si l'archi se basait sur 802.1x, y aurait déjà pas mal de softs compatibles (et Windows XP intègre ça en std a priori).

• [^]Re: Première version publique de NuFW

  Posté par Brice Arnould ( un_brice ) (page perso, ) le 02/09/2003 à 11:45. (lien). Évalué à 5.

  C'est aussi ce que j'ai cru comprendre...
  Maintenant, j'aimerais savoir c'est l'interêt de cette architecture (le client s'authentifie à chaque fois pour chaque paquet) comparé à un système plus classique de tunneling sécurisé dans lequel on ne doit authentifier l'utilisateur qu'une fois (genre tunnel ssh pour ce que j'ai pu comprendre).
  Ou même peut être à IPsec (je sais pas si ce protocole gère l'authentification).
  
  Bon c'est vrai qu'il permet (pour ce que j'ai compris) de définir des règles de filtrage pour chaque utilisateur, mais on peut très bien faire ça avec un système de tunnels non ?
  
  D'autant plus que ce système là "provides authentication for ANY protocol as long as its TCP/IP."

  --
  Respect à RMS.

  • [^]Re: Première version publique de NuFW

    Posté par Nap () le 02/09/2003 à 11:56. (lien). Évalué à 1.

    oui mais je pense qu'il doit pouvoir être étendu à tous les protocoles ou un suivi de session est possible, comme UDP

  • [^]Re: Première version publique de NuFW

    Posté par Vanhu () le 02/09/2003 à 11:57. (lien). Évalué à 6.

    Ou même peut être à IPsec
    
    Yep, IPSec propose meme la meilleure authentification que je connaisse, lors de la négociation (IKE / Isakmp, par cle prepartagee, ou, mieux, par PKI), puis authentification de chaque paquet (dans ce cas de figure, je suppose que le mieux serait de l'AH en mode transport, pour ceux qui connaissent).
    
    Et ca authentifie n'importe quel paquet IP emis par la machine a destination de la gateway....
    
    En pratique, personne ne met en place ce genre de chose, amha pour 2 raisons:
    
    1) Un client IPSec fonctionnel sous Windows, ca coute cher (l'implementation fournie en standard est .... euh ... comment dire ..... ahem.... "pas top"...).
    
    2) IPSec c'est bien, mais pour quelqu'un qui y connait rien, faut bien reconnaitre que c'est pas super trivial...

    • [^]Re: Première version publique de NuFW

      Posté par guhh () le 02/09/2003 à 12:17. (lien). Évalué à 1.

      C'est pourtant très simple à mettre en place avec FreeSwan

      • [^]Re: Première version publique de NuFW

        Posté par Vanhu () le 02/09/2003 à 13:51. (lien). Évalué à 3.

        Et (je trouve que) ca sera encore plus simple a mettre en place avec Kame/Racoon :-)
        
        Mais pour un admin "classique", rien que la mise en place d'une PKI, c'est une horreur, alors de la a comprendre la différence entre de l'ESP/Tunnel et de l'AH/transport.....

    • [^]Re: Première version publique de NuFW

      Posté par Alexandre Dulaunoy (page perso, ) le 02/09/2003 à 12:20. (lien). Évalué à 9.

      Concernant les alternatives possibles à IPSec (ok je c'est un peu off-topic), il y a OpenVPN qui est multi-plaforme et fonctionne aussi sous Windows (le client Windows fonctionne assez bien et possède un installer complet).
      
      OpenVPN a plusieurs avantages, il fonctionne dans un environnement avec NAT sans problème, il peut fonctionner avec des IP dynamiques entre deux sites et assez solide même sur des réseaux instables (comme p.ex. 802.11).
      
      Cela permet de virer les clients WIN32 IPSec propriétaires.
      
      http://openvpn.sf.net/(...)

  • [^]Re: Première version publique de NuFW

    Posté par Eric Leblond (page perso, ) le 02/09/2003 à 13:27. (lien). Évalué à 4.

    >le client s'authentifie à chaque fois pour chaque paquet
    Pas tout à fait en utilisant le suivi de connexion de Netfilter, on authentifie uniquement les paquets initialisant les connexions. Ceci réduit considérablement la charge de traitement?.
    > faire ça avec un système de tunnels
    Avce beaucoup moins de flexibilité puisque l'on peut ici :
    - filtrer UDP (voir meme icmp) par utilisateur
    - gérer dynamiquement les règles (retour d'un IDS qui modifie le LDAP par exemple)
    - pas de modification de la conf du client qui se contente betement d'authentifier tous les paquets d'initialisation de session.

    • [^]Re: Première version publique de NuFW

      Posté par Nap () le 02/09/2003 à 13:34. (lien). Évalué à 1.

      comment fais-tu pour detecter les paquets sortant et réagir en envoyant une demande d'authentification ?
      
      y a une lib pour faire ça ?

      • [^]Re: Première version publique de NuFW

        Posté par Eric Leblond (page perso, ) le 02/09/2003 à 13:47. (lien). Évalué à 2.

        plusieurs choix : libpcap
        utilisée pour tcpdump : on peux dumper les paquets SYN tcp, les paquets UDP, ....
        
        ou ce qui est fait maintenant (provisoire pour tcp):
        regarder /proc/net/tcp et si une nouvelle connexion est en SYN_SENT c'est qu'elle est "en attente" (de modération ;-) et on envoie un paquet

        • [^]Re: Première version publique de NuFW

          Posté par Nap () le 02/09/2003 à 13:56. (lien). Évalué à 1.

          dans ce cas, comment fais tu pour savoir quel est l'utilisateur qui a initié la connexion ?
          de plus le deamon tourne en root ou sous une session de l'utilisateur concerné ?

          • [^]Re: Première version publique de NuFW

            Posté par Eric Leblond (page perso, ) le 02/09/2003 à 14:00. (lien). Évalué à 2.

            > dans ce cas, comment fais tu pour savoir quel est l'utilisateur qui a initié la connexion ?
            /proc/net/tcp indique qui a ouvert la socket
            >de plus le deamon tourne en root ou sous une session de l'utilisateur concerné ?
            Le démon est lancé par l'utilisateur et tourne sous son ID.

• [^]Re: Première version publique de NuFW

  Posté par Aurélien Bompard (Jabber id, page perso, ) le 02/09/2003 à 14:04. (lien). Évalué à 1.

  Attention, question stupide du débutant qui s'y connait pas : c'est quoi la différence avec un proxy transparent ?
  Merci (et oui, je suis allé lire la doc sur le site :-) )

  • [^]Re: Première version publique de NuFW

    Posté par Eric Leblond (page perso, ) le 02/09/2003 à 14:14. (lien). Évalué à 4.

    Qui dit proxy, dit qu'au final c'est un serveur qui fait les requêtes sur la cible final. Si le proxy fait les requêtes, c'est qu'il connait le protocole et que le protocole s'y prete.
    
    Ici, on n'est capable d'autoriser n'importe quel protocole (ayant un suivi de connection par netfilter) en filtrant par utilisateur.
    
    les différences sont donc :
    - pas de relayage mais une transmission directe.
    - pas de connaissance nécessaire du protocole et donc adaptation possible à tous les protocoles.

• [^]Re: Première version publique de NuFW

  Posté par Xavier Teyssier (Jabber id, page perso, ) le 02/09/2003 à 14:35. (lien). Évalué à 3.

  en fait le but du bazard est de ne permettre une connexion TCP/IP de traverser une passerelle qu'après authentification de l'utilisateur initiant la connexion, c'est bien ça ?
  
  Juste histoire de savoir si j'ai un peu compris ou si je suis complètement à la rue :
  ce que tu viens de décrire, c'est en gros ce que fais la fonction authpf du firewall d'OpenBSD ?

  • [^]Re: Première version publique de NuFW

    Posté par Nap () le 02/09/2003 à 14:39. (lien). Évalué à 1.

    bah je sais pas, je connais pas la fonction authpf du firewall d'openbsd, ni le firewall d'openbsd (ni openbsd d'ailleurs, à part que le logo c'est un poisson à épines classe, qui chope bien niveau meufs)
    
    vas y raconte ce que ça fait, ça m'intéresse tout ça

    • [^]Re: Première version publique de NuFW

      Posté par Eric Leblond (page perso, ) le 02/09/2003 à 14:49. (lien). Évalué à 3.

      Lorsqu'un utilisateur ouvre une connection ssh sur le firewall, un ensemble de règle est jouée, ce qui permet de faire à peu près comme NuFW.
      Quelques différences :
      - il faut créer un compte sur le FW ce qui est contraignant et mobilise des ressources sur le firewall.
      - l'ensemble de règles (pour ce que j'en sais) ne peut être géré dynamiquement.

      • [^]Re: Première version publique de NuFW

        Posté par Nap () le 02/09/2003 à 15:07. (lien). Évalué à 1.

        ok je comprends pas tout donc je materai ça un de ces 4 (notamment comment fait le firewall pour savoir à quel utilisateur appartient un paquet)

      • [^]Re: Première version publique de NuFW

        Posté par scylla (page perso, ) le 02/09/2003 à 15:36. (lien). Évalué à 2.

        J'ai une question que je suppose profondément stupide, mais comment le serveur d'authentification de NuFW utilise-t-il le champ MD5SUM ?
        
        MD5SUM is build by applying function crypt to the chain resulting from the concatenation of SrcIP Sport (or ICMP type) DestIP Dport (or ICMP code) Timestamp Password. SrcIP and DestIP are written in the standard numbers-and-dots notation.

        • [^]Re: Première version publique de NuFW

          Posté par Eric Leblond (page perso, ) le 02/09/2003 à 15:54. (lien). Évalué à 1.

          Sachant qu'il a accès au mot de passe tapé (ou qu'aurait du taper l'utilisateur) il génère la chaine de charactère résultant de la concaténation des champs cités puis crypte avec la fonction crypt la chaine obtenue en utilisant le "salt" du crypt MD5 fournit par l'utilisateur.
          La chaine sortant alors de crypt doit être la même que le crypt MD5 fournit par l'utilisateur.

  • [^]Re: Première version publique de NuFW

    Posté par Eric Leblond (page perso, ) le 02/09/2003 à 14:40. (lien). Évalué à 3.

    Oui, en mieux ;-) puisque les règles peuvent être gérées par un serveur LDAP, on est donc dans qqc de plus dynamique.

  • [^]Re: Première version publique de NuFW

    Posté par PsychoFox () le 02/09/2003 à 14:40. (lien). Évalué à 1.

    c'est en gros ce que fais la fonction authpf du firewall d'OpenBSD ?
    
    la remarque qui tue

Authpf fait ça depuis longtemps

• [^]Re: Authpf fait ça depuis longtemps

  Posté par Eric Leblond (page perso, ) le 02/09/2003 à 16:01. (lien). Évalué à 4.

  Merci mais la diversité n'a jamais nuit au logiciel libre.
  de plus le longtemps date d'un peu plus d'un an si ma mémoire est bonne.
  > Le système de fitrage PF d'OpenBSD adapte alors les règles de filtrage dynamiquement
  - Est-il capable de gérer la modification des règles alors que l'utilisateur est déjà loggué ? Non, d'après la FAQ.
  - Comment traite-t-il le cas de plusieurs personnes venant de la même IP (NAT, serveur de terminal) ? Avec NuFW, chaque utilisateur authentifie CES paquets et on peut donc avoir plusieurs utilisateurs avec des permissions différentes sur la même machine, ce n'est pas le cas de AuthPF !

Re: Première version publique de NuFW

• [^]Re: Première version publique de NuFW

  Posté par Eric Leblond (page perso, ) le 03/09/2003 à 09:30. (lien). Évalué à 3.

  Non voir : http://www.nufw.org/principles.html(...)
  Grosso modo :
  - le firewall met en queue les requetes
  - nufw envoie les requetes à nuauth
  - nuauth check dans le ldap et dit au firewall si le paquet peut passer ou non

  • [^]Re: Première version publique de NuFW

    Posté par Nap () le 03/09/2003 à 09:40. (lien). Évalué à 1.

    ok, nuauth fais une requete ldap pour chaque nouvelle connexion