PepperSpot, Portail Captif nouvelle génération

Posté par  . Modéré par patrick_g.
Étiquettes :
9
14
déc.
2008
Technologie
PepperSpot est un portail captif sous licence GNU GPLv2 qui a été développé dans le cadre d'un projet du laboratoire de recherche de l'université Louis Pasteur à Strasbourg. Il est basé sur le portail captif bien connu ChilliSpot, et intègre maintenant un support pour l'IP nouvelle génération (IPv6). De nombreuses corrections ont été apportées et le code a été nettoyé.

Voici ses principaux attraits :
  • Utilisation en IPv4, IPv6 ou en double pile
  • Authentification UAM (interface Web) et WPA, via le protocole RADIUS
  • Serveur DHCP (pour IPv4)
  • Code POSIX

Aller plus loin

  • # Petite remarque...

    Posté par  . Évalué à 10.

    N'aurait-il pas été intéressant d'expliquer en 1 phrase ce qu'est un portail captif[1] ?
    Car, personnellement, alors que j'avais déjà vu des portails captifs, je ne connaissais pas ce terme, et l'ami Google m'a donc renvoyé vers un autre article de DLFP[1].

    Donc, en très résumé : un portail captif est la page d'accueil que l'on peut parfois voir lorsqu'on se connecte à un réseau WiFi. Cette page nous demandant de nous identifier et/ou d'accepter les conditions d'utilisation avant de nous ouvrir les portes du Web.
    Ex : le WiFi de la NeufBox, celui des gares SNCF...


    1 http://linuxfr.org/2005/03/24/18581.html

    • [^] # Re: Petite remarque...

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

      bien vu, je viens de rajouter un lien vers wikipedia ;-)

      perso, j'aurais plus vu un peu d'historique de ce projet, notamment :
      - dans quel cadre s'est-il lancé ? pour des besoins précis de l'université ? pour promouvoir IPv6, pour un réseau wifi maillé spécifique ?
      - quelles sont les relations avec chillispot, est-il prévu de remonter upstream les améliorations ? les deux projets vont-ils évoluer de concert ?

    • [^] # Re: Petite remarque...

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

      Ajoutons au passage que :
      - ça sert à faire la même chose que WPA/TKIP en moins bien ;
      - ça utilise pour contrôler l'accès des outils et des couches du modèle qui ne sont absolument pas faites pour ;
      - ça se contourne sans problème.

      • [^] # Re: Petite remarque...

        Posté par  . Évalué à 1.

        Ok pour les deux derniers points, par contre pour le premier, je ne vois pas comment le WPA/TKIP remplace l'affichage d'une page de conditions/information/pub.

        Et je ne suis pas trop sûr que les méthodes d'authentification individuelle n'ait pas un sur-coût d'administration (serveur différent et moins bien intégré peut être?)

      • [^] # Re: Petite remarque...

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

        > ça sert à faire la même chose que WPA/TKIP en moins bien

        Pas vraiment, non. Exemple, la municipalité d'Athènes propose des hotspots wifi sur certaines places de la ville. N'importe quel touriste peut s'y connecter, voir la page d'accueil du portail qui affiche une page de conditions d'accès et un captcha (je ne sais pas à quoi il sert, mais bon...)

        Deuxième exemple, les offices de tourisme de Vendée proposent des points d'accès wifi répartis dans le département qui ne laissent un accès gratuit qu'à un certain nombre de sites déterminés (conseil général, office de tourisme, sites des villes).

        Le portail (qui se contourne sans doute sans problème cependant) peut imposer des contraintes et proposer des termes d'utilisation à des gens de passage sans contrainte physique*.

        * pas besoin de demander un code d'accès ou faire enregistrer sa machine, ce qui ne se fait pas 24h sur 24.

      • [^] # Re: Petite remarque...

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

        J'aimerais bien savoir comment tu penses le contourner ? Tunneling DNS ? facile à eviter.

        Linux sur PC disponible pour tous http://shop.ekimia.fr

        • [^] # Re: Petite remarque...

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

          Ah, ça empêche les tunnels IPoDNS, maintenant ? Tant mieux, mais il n'empêche que, pour faire de l'authentification, les portails captifs restent un kludge immonde.

          Pour annoncer des conditions d'utilisation, c'est très bien, mais pour identifier et restreindre l'accès, c'est une utilisation anormale des protocoles de couches supérieures.

          • [^] # Re: Petite remarque...

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

            tes arguments son surement pertinent , mais dans la Vraie vie , pour un hotspot Public , le portail captif restes la meilleure solution pour une compatiblité avec tous les équipements au niveau du client et la possibilité pour un client n'ayant pas encore de compte de s'inscrire par ce biais.

            je ne vois pas en quoi c'est une utilisation anormale. De plus les clients Wispr permettent maintenant une authentification via un fichier XML pouvant simplifier l'utilisation.

            Biensur si le client support WPA-entreprise, l'idéal est de lui proposer un second SSID sur la même borne qui lui permettra de se loguer sans portail.

            Linux sur PC disponible pour tous http://shop.ekimia.fr

          • [^] # Re: Petite remarque...

            Posté par  . Évalué à 1.

            mis a part que l'article comme dab n'explique rien (faut cliquer partout pour savoir de quoi on cause)
            j'aimerais bien savoir comment tu veut remplacer un hotspot typique (hotel) avec un "portail captif" donc, par autre chose?

            Parce que oui, c'est mal, etc, mais comment faire autrement?
            avoir une clée wap pour chaque client ca n'est vraiment pas simple, ni pour le client d'ailleurs

            • [^] # Re: Petite remarque...

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

              Pour un hôtel, je vois deux cas :
              - les clients peuvent utiliser le réseau à volonté, gratuitement : dans ce cas, du wifi non chiffré, c'est parfait, pourquoi vouloir mettre un portail captif (Pour rappeler aux gens qu'ils utilisent la connexion de l'hôtel ? Ils ne sont pas débiles, ils savent à quoi ils se connectent, tout de même.)
              - les clients doivent payer pour obtenir un code : WPA/TKIP, c'est parfait.

              • [^] # Re: Petite remarque...

                Posté par  . Évalué à 2.

                > Pour un hôtel, je vois deux cas

                J'ai rencontré un troisième cas en Europe de l'est : pas de wifi, prise RJ45 au mur...
                L'astuce ? Il faut aller demander un cable ethernet à l'accueil pour pouvoir accéder au réseau :-) Ils demandent le numéro de chambre et facturent en conséquence !

                Manque de bol pour eux, en bon geek j'ai toujours un cable dans mon sac...

                • [^] # Re: Petite remarque...

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

                  Ils peuvent aussi te connecter au commutateur sur ta demande, c'est moins débile. Bon, il faut que la table de brassage soit derrière la réception, mais ça se fait…

                  Aux États-Unis : réseau dans les chambres, par… ADSL interne ! Ça leur permettait de faire passer du haut débit sur des fils pourris.

              • [^] # Re: Petite remarque...

                Posté par  . Évalué à 1.

                - les clients peuvent utiliser le réseau à volonté, gratuitement : dans ce cas, du wifi non chiffré, c'est parfait, pourquoi vouloir mettre un portail captif

                Pour éviter que les gens non clients de l'hôtel se connectent eux aussi.

              • [^] # Re: Petite remarque...

                Posté par  . Évalué à 2.

                Et tu fais comment pour restreindre l'accès à la durée du séjour, tu change le code WPA tout les soirs et tu le redistribue à qui en a droit?

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Petite remarque...

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

                  WPA/TKIP : autant de paires d'identifiants et de codes que l'on veut. Pour un hôtel : on en crée un par client du service wifi (encore que faire payer l'accès à Internet, c'est plus que limite comme pratique), et on les supprime après.

                  • [^] # Re: Petite remarque...

                    Posté par  . Évalué à 3.

                    Est-ce tu ne confond pas avec WPA-EAP, ou alors on peut faire des paires identifiant/code avec TKIP?

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Petite remarque...

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

                      ET bien, je viens de vérifier : je ne confondais pas, EAP s'utilise avec TKIP (mais on peut utiliser autre chose qu'EAP pour ça). :-)

                      • [^] # Re: Petite remarque...

                        Posté par  . Évalué à 2.

                        TKIP s'utilise le plus souvent sans login/mdp ou je suis toujours à côté de la plaque?

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Petite remarque...

                          Posté par  . Évalué à 2.

                          Je voulais bien sûr dire avec un code mais le même pour tout le monde et sans login.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Pourquoi un fork ??

    Posté par  . Évalué à 3.

    Étant un utilisateur de Chillipost, je me demande pourquoi avoir fait un fork ??
    Il aurait été intéressant que les modifications apportées soit plutôt intégrées à Chillispot !

  • # Vos commentaires !

    Posté par  . Évalué à 3.

    Tout d'abord bonjour à tous, et merci de l'intérêt que vous portez à cette dépêche.

    Voici mes réponses aux différents commentaires.

    Pour commencer, nous avons fait un fork de ChilliSpot dans la mesure où celui-ci n'est plus maintenu depuis 2006, et que les modifications apportées ont été très importantes. Cela nous permet de maintenir PepperSpot dans de bonnes conditions, et d'y apporter un support.

    Concernant le contournement, lors de l'installation de PepperSpot, il est nécessaire d'appliquer un script IPTables sur la machine. La sécurité dépendra alors uniquement de ce script, et ne sera pas liée directement à PepperSpot. Pour l'IPoDNS (cas le plus répandu de contournement), il peut être possible de filtrer les requêtes DNS grâce au script firewall. On peut par exemple imaginer un serveur DNS dans le sous-réseau que couvre PepperSpot, ou en hôte autorisée, et il n'y aura alors aucune possibilité de contournement par ce biais.

    Pour revenir à l'utilisation anormale des protocoles, je ne vois pas en quoi. Le script firewall installé avec PepperSpot sert à refuser toute connexion par défaut, avec d'éventuelles exceptions (ping, DNS, etc.). L'application va ensuite gérer elle même les différents paquets qui transitent, et acceptera ou non de les router vers Internet en fonction de différents paramètres (Adresse MAC, utilisateur Authentifié, Bande passante, etc.). Il est vrai que cela impose sûrement un temps de traitement un peu plus important que si le noyau gérait directement cela (PepperSpot utilise en effet un tunnel TUN/TAP pour router les paquets entre les différentes interfaces), mais il s'agissait de la méthode la plus efficace pour permettre de garantir une souplesse d'utilisation, et je comprends que les développeurs de ChilliSpot l'aient implémentée.

    A propos du sur-coût d'administration, Earered, il est vrai que la configuration d'un serveur RADIUS n'est pas chose aisée de prime abord, mais cela permet de bénéficier de toutes les possibilités offertes par ce type d'authentification. Je ne vais pas les expliquer en détails ici, mais c'est un protocole d'authentification déployé à grande échelle, qui est utilisé chez la plupart des fournisseurs d'accès ou dans de très grands réseaux. Il est cependant possible de le configurer simplement en liant directement le serveur RADIUS à l'authentification système.

    Enfin Tanguy, je pense que tu fais une petite confusion concernant WPA/TKIP. Il s'agit d'un protocole de sécurité de type 802.1X. On ne peut donc pas dire que PepperSpot fait la même chose étant donné que PepperSpot est une application. Il est capable de gérer des authentifications WPA/TKIP, et d'ailleurs bien d'autres, mais c'est totalement différent.

    En tous cas, je vous invite vivement à tester PepperSpot et à nous envoyer vos éventuelles critiques et améliorations potentielles. Nous sommes aussi à la recherches des bugs et failles à corriger.

    A bientôt

    Thibault

    • [^] # Re: Vos commentaires !

      Posté par  . Évalué à 1.

      Pour l'IPoDNS (cas le plus répandu de contournement), il peut être possible de filtrer les requêtes DNS grâce au script firewall
      Je n'ai pas encore compris pourquoi les requêtes dns sont autorisées avant que le client se soit authentifié. C'est un truc qui me dépasse :-)

      Pour les clients non authentifiés (ou ceux qui n'ont pas cliqué sur "oui j'ai pigé les régles"), iptables redirige les paquets destinés au port 53 vers le dns (local, sur 127.0.0.1:54 par exemple) qui affiche la page d'accueil du portail. Une fois qu'on est authentifié, c'est le dns normal qui est accédé.

      • [^] # Re: Vos commentaires !

        Posté par  . Évalué à 3.

        La réponse est simple. Lorsqu'un client veut joindre un site web, www.google.fr par exemple, son système va effectuer une requête DNS pour obtenir l'IP de google.
        Il est vrai qu'on pourrait installer un relais DNS ou même un serveur DNS sur la machine hébergeant PepperSpot, et là le problème ne se pose pas, on peut bloquer le DNS.
        Mais si le serveur DNS est "derrière" PepperSpot, c'est-à-dire dans le réseau auquel on a pas accès, le client n'arrivera jamais à obtenir l'IP de google si on bloque le DNS, et la page d'authentification ne s'affichera pas.
        Je m'explique. PepperSpot redirige le client vers sa page d'authentification lorsqu'il détecte une demande de communication TCP. Si le client ne sait pas quelle IP joindre, la requête TCP ne se fera pas. De plus, la majorité des requêtes DNS sont effectuées en UDP... Voila pourquoi il peut être utile de ne pas bloquer les DNS.

        Je suis cependant de ton avis, il est mieux de limiter au maximum les communications avec le réseau non accessible avant authentification. Ca dépend avant tout de la topologie du réseau.
        Mais il ne faut pas oublier qu'un simple "apt-get install bind9" sous Debian suffit à installer un relais DNS fonctionnel... De plus, il est possible de spécifier l'adresse des DNS à joindre dans la configuration de PepperSpot...
        A chacun de choisir la solution qui lui convient le plus, et la politique de sécurité la plus appropriée.

        • [^] # Re: Vos commentaires !

          Posté par  . Évalué à 3.

          Je sais bien tout cela. Ce qui m'étonne c'est que ce fameux DNS-bis ne soit pas d'origine configuré avec ces portails captifs. Pourtant ces logiciels utilisent des choses déjà bien velues, un serveur web et iptables entre autres, donc un DNS quelquonque me semble peu problématique, éventuellement 100% dédié au portail (donc 50 lignes de code).

          • [^] # Re: Vos commentaires !

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

            Il y a certains OS (qu'on ne citera pas ici) qui implémentent un cache DNS d'assez longue durée. Si on leur ment une fois, il faut leur mentir 1000 fois en redirigeant les flux destinés à l'adresse usurpée sinon ils ne peuvent plus joindre les services qu'ils souhaitent atteindre car l'adresse en cache est fausse.

            • [^] # Re: Vos commentaires !

              Posté par  . Évalué à 2.

              ce cache se vide d'une seule commande, et sinon ses utilisateurs ont l'habitude de redémarrer dès que quelque chose ne marche plus

              • [^] # Re: Vos commentaires !

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

                Oui et ma mère est sous Linux, elle n'a donc pas de problème de cache sur les hotspots qui corromprait le cache de son ordinateur. Mais tout le monde n'est pas ma mère.

                Plus sérieusement, quand on monte un hotspot, l'objectif est de rendre le service à tout le monde, y compris à ceux qui ne savent pas ce qu'est le DNS (ce qui représente au moins une bonne moitié de la population ciblée).

                Sinon pour ce qui est de l'automatisme du redémarrage : là, comme il faut de nouveau se connecter sur le hotspot pour sortir, on tourne en rond. Le cache est corrompu à chaque fois et les applications ne sont pas joignables. Il ne reste donc comme seul opportunité que le vidage du cache. Et on tombe sur mon premier argument.

            • [^] # Re: Vos commentaires !

              Posté par  . Évalué à 2.

              Je viens de vérifier: l'OS que tu ne cites pas ne me semble pas poser de problème. Avec un domaine dont la durée de vie est fixée à 60 secondes, la cache m'indique 57 secondes juste après, puis 45 etc.

    • [^] # Re: Vos commentaires !

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

      Je ne fais pas de confusion avec WPA/TKIP, enfin, il me semble. En revanche, je constate l'utilisation la plus fréquente des portails captifs : restreindre l'accès à un réseau. Or, il s'agit pour cela :
      - de mentir sur les réponses DNS ;
      - de bloquer des paquets au niveau réseau, en se basant sur l'adresse MAC (donc liaison) des clients ;
      - de lever le blocage sur une identification au niveau applicatif.

      Concernant le premier point : mentir, c'est mal (en général). Concernant les deux derniers points : par rapport au modèle OSI, c'est horrible, on fait ici un lien de la couche liaison (la seconde) à la couche applicative (la cinquième, dans l'implémentation TCP/IP). Même au niveau système, ça fait de drôles d'opération, entre un serveur Web et Netfilter…

      Tout ça pour remplacer quoi ? Ça dépend du cas :
      - restriction d'accès avec codes distribués au cas par cas : du WPA/TKIP, qui a l'avantage de rester là où il a sa place, dans la couche liaison ;
      - informations sur le réseau : des panneaux d'affichage.

      Quant à contourner sans IPoDNS : prendre l'adresse MAC d'un client déjà connecté, par exemple ?

      • [^] # Re: Vos commentaires !

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

        question de noob :

        Si je me connecte en WPA/TKIP... qui e donne la clef ? le gérant de l'hotel ? Si oui... je peux donc sniffer tous mes voisins (et réciproquement) ?

        Avec un portail captif, toutes les clefs sont différentes, non ?

        • [^] # Re: Vos commentaires !

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

          Avec WPA/TKIP, les clefs changent tout le temps, justement. Le login et le mot de passe servent à initier le processus, il me semble.

          • [^] # Re: Vos commentaires !

            Posté par  . Évalué à 1.

            Il me semble, mais je n'en suis pas sûr, que WPA/TKIP, il n'y a qu'une seule clef pour s'identifier. Et que le couple login/mdp c'est ce qui est appelé WPA d'entreprise et qui est différent et surtout qui n'est pas disponible sous Windows XP.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Vos commentaires !

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

              Et que le couple login/mdp c'est ce qui est appelé WPA d'entreprise et qui est différent et surtout qui n'est pas disponible sous Windows XP.

              FUD

              • [^] # Re: Vos commentaires !

                Posté par  . Évalué à 5.

                C'est pour ça que j'ai dit "il me semble" mais sinon, c'est pour quelle partie de la phrase le FUD?

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Vos commentaires !

              Posté par  . Évalué à 2.

              WPA : Wired Protected Access

              TKIP (Temporary Key Integrity Protocol). Le protocole TKIP permet la génération aléatoire de clés et offre la possibilité de modifier la clé de chiffrement plusieurs fois par secondes, pour plus de sécurité.
              Le fonctionnement de WPA repose sur la mise en oeuvre d'un serveur d'authentification (la plupart du temps un serveur RADIUS), permettant d'identifier les utilisateurs sur le réseau et de définir leurs droits d'accès.
              Néanmoins, il est possible pour les petits réseaux de mettre en oeuvre une version restreinte du WPA, appelée WPA-PSK, en déployant une même clé de chiffrement dans l'ensemble des équipements, ce qui évite la mise en place d'un serveur RADIUS.

      • [^] # Re: Vos commentaires !

        Posté par  . Évalué à 3.

        Bien ce qu'il me semblait: les portails captifs se basent sur l'adresse Mac.

        Franchement faible, comme sécurité. :p

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Enfin la relève !

    Posté par  . Évalué à 1.

    Je tiens à vous féliciter pour avoir repris le flambeau.
    Avez-vous réalisé des tests de performance?
    Existe-t-il un package pour openwrt ?
    Comment vous positionnez-vous face à coovachilli ?

Suivre le flux des commentaires

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