Première version publique de NuFW

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
2
sept.
2003
Sécurité
La première version publique de NuFW vient de sortir. NuFW est un ensemble de démons permettant de réaliser un filtrage des paquets au niveau utilisateur.
Cette version propose :
- un démon relai à implanter sur le firewall
- un client pour linux et TCP
- un démon réalisant la synthèse des deux précédents et utilisant une base LDAP pour le stockage. Cette première version publique prouve la viabilité du concept déployé dans ce logiciel. Cependant de nombreuses fonctionnalitées reste à implémenter :
- client IP complet
- client pour d'autres OS
- système de plugin pour supporter des modules d'authentification varié (radius, fichiers textes).
- outils d'administrations

Je lance donc ici un appel à contribution, tous les volontaires sont les bienvenu(e)s.

Aller plus loin

  • # Re: Première version publique de NuFW

    Posté par  . Évalué à 1.

    je sais pas si j'ai tout compris, mais ça a l'air GE-NIAL

    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 ?

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

      Posté par  . É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)

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

      Posté par  (site web personnel) . É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."

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

        Posté par  . É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  . É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  . Évalué à 1.

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

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

            Posté par  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (Mastodon) . É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

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

    Je ne voudrais pas être médisant mais Authpf permet ce genre de chose (filtrage de paquets après authentification utilisateur) depuis longtemps sur OpenBSD.

    Pour l'authentification de l'utilisateur, il suffit qu'il se loggue via SSH et que son shell soit /usr/sbin/authpf. Le système de fitrage PF d'OpenBSD adapte alors les règles de filtrage dynamiquement.

    Voir la FAQ dédiée à authpf pour plus de détails : http://openbsd.org/faq/pf/authpf.html(...)

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

      Posté par  (site web personnel) . É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

    Posté par  . Évalué à 1.

    tu dis que les règles sont gérées dans un serveur LDAP et que leurs modifications sont prises en compte dynamiquement

    comment le serveur fait-il pour mettre à jour les regles iptables en temps réel ?
    il fait des requêtes toutes les 5 secondes sur le serveur ?

Suivre le flux des commentaires

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