Méthode d'authentification Squid par portail captif



  • Bonjour à tous,

    Je possède la version 2.3 de pfSense.

    J'ai donc un pfSense à jour avec le package Squid possédant également la dernière version.
    Malheureusement j'ai un problème …

    Lorsque je n'utilise aucune méthode d'authentification pour mes utilisateurs de Squid, ils peuvent se loguer par le portail captif et utiliser le Proxy sans aucun soucis. Le problème de cette méthode c'est que si mes utilisateurs configurent leurs navigateur de façon à utiliser le proxy, ils ne passent plus par le portail captif ...

    Afin de garantir une certaine sécurité, il faut que j'utilise la méthode d'authentification Squid par portail captif. Lorsque cette authentification est en route, mes utilisateurs peuvent se connecter au portail captif, se loguer mais malheureusement tous les sites en http ne sont pas accessible. J'ai pourtant bien autorisé mes utilisateurs à utiliser le Squid...
    Dans les logs de Squid, il est bien inscrit TCT_DENIED/403. Pour mes utilisateurs, la page d'accès interdit du proxy apparaît.

    Toutes les Acls de Squid sont par défaut.

    Quelqu'un aurait-il une solution à mon problème s'il vous plait ?

    Merci beaucoup de votre aide.



  • Formulaire !
    Description du besoin fonctionnel !

    @jeremyb:

    Afin de garantir une certaine sécurité, il faut que j'utilise la méthode d'authentification Squid par portail captif.

    De quelle sécurité parlez vous ?



  • Réponse pour le message :

    –---------------------------
    De quelle sécurité parlez vous ?


    Je veux absolument faire passer mes utilisateurs par mon portail captif afin d'avoir dans mes logs Squid le nom de mes utilisateurs.

    Si mes utilisateurs configurent leurs navigateurs afin d'envoyer leurs requêtes par le Squid, je n'aurai donc par le nom d'utilisateur dans les logs mais seulement l'adresse IP. Tous les utilisateurs pourraient également se connecter au Wifi sans passer par le portail captif ...

    En réalité il faut absolument que j'utilise la methode " captive portal" pour l'authentification de mon Squid ! Est-ce possible ?

    Merci beaucoup de vos réponse



  • Formulaire !
    Description du besoin fonctionnel !
    Vous raisonnez en terme de solution technique avant d'avoir exposé le besoin fonctionnel. Nous avons juste appris que vous avez un réseau wifi. Rien sur l.infrastructure, la nature des utilisateurs, … Bref rien qui permette de comprendre le besoin de csecurité. Écrire ce que vous écrivez n'est pas l'expression d'un besoin de sécurité . C'est une solution technique. A priori curieuse d'ailleurs.



  • @jeremyb:

    Si mes utilisateurs configurent leurs navigateurs afin d'envoyer leurs requêtes par le Squid, je n'aurai donc par le nom d'utilisateur dans les logs mais seulement l'adresse IP. Tous les utilisateurs pourraient également se connecter au Wifi sans passer par le portail captif …

    Portail captif et Squid sont 2 choses totalement différentes et indépendantes, même si il y souhaitable, parfois de les utiliser ensemble.

    • Le portail captif va gérer des règles de FW pour autoriser un flux à une adresse IP
    • le proxy HTTP va exécuter une requête HTTP à la place du client

    Sans portail captif, si tu active l'authentification sur le proxy, tu auras dans les logs les logins des utilisateurs. Il est nullement besoin d'avoir un portail captif si ton besoins est uniquement de voir les comptes plutôt que des IP dans le log de Squid.



  • Alors je vais essayer de m'exprimer autrement :

    Je suis en DUT Réseaux et Télécommunications et j'essaie de mener à bien un projet Wifi.
    Le projet est donc d'installer une architecture Wifi. Cette architecture va comprendre deux Vlans (le nom des Vlans sera également le nom des SSID diffusés) :

    - Un vlan public qui sera accessible par tous les utilisateurs académiques
      - Un vlan privé qui sera accessible seulement à un certain groupe

    En réalité, j'ai donc sur mon pfSense quatres pattes : Une patte Wan, une patte VlanPrive, une patte VlanPublic et une patte management (seulement pour la phase de test) :

    VlanPublic–----------------------------|
    Management (pour les tests)-------          ---------------- PfSense ----------- WAN
    VlanPrivé------------------------------

    Le pfSense possède deux portails captifs sur les Vlans Public et privé. L'authentification aux portails captifs est gérée par un serveur FreeRadius qui authentifie les utilisateurs à l'aide d'un LDAP (Le LDAP et le Radius sont sur une VM située dans le vlan Management). En fonction des groupes des utilisateur du LDAP, les utilisateurs peuvent se connecter ou non au SSID.
    Sur les Vlans Public et Privé, j'ai donc différents ports du pfSense qui sont en écoute dont le port 800X pour le portail captif mais également le port 3128 (port de mon SQUID).

    Effectivement, après authentification sur le portail captif, mes utilisateurs utilisent le package proxy Squid en mode transparent afin d'avoir une traçabilité des différentes requêtes. Ils n'ont donc pas besoin de renseigner d'informations afin de pouvoir l'utiliser ( but du proxy transparent).

    Dans la configuration de mon Squid, il est possible de mettre en place une authentification afin d'autoriser mes utilisateurs à utiliser le mon proxy. Pour le proxy en mode transparent, il existe deux méthode d'authentification : soit aucune soit par portail captif

    Si je choisis de ne pas faire d'authentification pour utiliser le proxy ( method authentification = none), tout marche correctement ( je logue bien les requêtes http …) mais j'ai un gros problème : Vu que mon proxy écoute sur les interfaces, n'importe quel utilisateur  peut configurer son navigateur de façon à utiliser mon Squid sur le port 3128 (vu que le port est en écoute sur les interfaces) et les requêtes sont donc traitées par mon Squid sans aucune authentification sur le réseau. Les utilisateurs ne passent donc pas par le portail captif !

    Afin de pallier à ce problème, je compte donc utiliser une méthode d'authentification pour mon Squid. J'aimerai donc utiliser la méthode d'authentification par portail captif pour que mes utilisateurs soient obligés de passer par le portail captif pour pouvoir accéder à internet.
    Mon problème est donc là : Quand j'utilise cette authentification pour mes utilisateurs, ils ne peuvent plus du tout accéder aux site en http. La page du portail captif apparaît bien, l'authentification au portail se réalise correctement mais toutes les requêtes http sont interdite d'accès par le Squid. Dans les logs de Squid, je peux constater les messages TCP_DENIED/403 qui apparaît lors de des requêtes http … J'ai donc l'impression que mon Squid ne discute pas avec le portail captif !

    J'espère avoir un petit peu mieux exposé mon problème, merci beaucoup pour vos réponse, j'espère que quelqu'un aura la solution !!!



  • @chris4916:

    @jeremyb:

    Si mes utilisateurs configurent leurs navigateurs afin d'envoyer leurs requêtes par le Squid, je n'aurai donc par le nom d'utilisateur dans les logs mais seulement l'adresse IP. Tous les utilisateurs pourraient également se connecter au Wifi sans passer par le portail captif …

    Portail captif et Squid sont 2 choses totalement différentes et indépendantes, même si il y souhaitable, parfois de les utiliser ensemble.

    • Le portail captif va gérer des règles de FW pour autoriser un flux à une adresse IP
    • le proxy HTTP va exécuter une requête HTTP à la place du client

    Sans portail captif, si tu active l'authentification sur le proxy, tu auras dans les logs les logins des utilisateurs. Il est nullement besoin d'avoir un portail captif si ton besoins est uniquement de voir les comptes plutôt que des IP dans le log de Squid.

    Oui en réalité j'ai vraiment besoin d'un portail captif car je dois autoriser ou non mes utilisateurs à utiliser un Vlan en fonction de leurs appartenance à un groupe LDAP !

    J'ai essayé de mieux présenter mon problème au dessus, ce sera peut-être un petit peu plus compréensible :)



  • @ccnet:

    Formulaire !
    Description du besoin fonctionnel !
    Vous raisonnez en terme de solution technique avant d'avoir exposé le besoin fonctionnel. Nous avons juste appris que vous avez un réseau wifi. Rien sur l.infrastructure, la nature des utilisateurs, … Bref rien qui permette de comprendre le besoin de csecurité. Écrire ce que vous écrivez n'est pas l'expression d'un besoin de sécurité . C'est une solution technique. A priori curieuse d'ailleurs.

    Merci de votre réponse, j'ai essayer de formuler ma problématique autrement, je vous la présente juste dessus ! Si vous avez besoin de plus de renseignements pour m'aider, n'hésitez pas !



  • Pour le proxy en mode transparent, il existe deux méthode d'authentification : soit aucune soit par portail captif

    Me parait faux !

    Le mode transparent d'un proxy est incompatible avec toute authentification, et ne fonctionne que pour http !
    cf Christian CALECA http://irp.nain-t.net/doku.php/210http:50_proxy

    NB : vous ne semblez tenir aucun compte de ce qu'on vous écrit : prenez le temps de lire et comprendre les notions AVANT de poser une question !



  • Bonjour jdh,

    Je suis désolé de vous contredire mais vos sources datent du 3 mars 2009 …
    Il est "normalement" aujourd'hui possible d'utiliser le proxy transparent avec une méthode d'authentification par portail captif. PfSense propose cette solution, je n'arrive simplement pas à la faire marcher, je voudrai juste savoir si quelqu'un a déjà réussit ou non !

    Merci tout de même pour votre message ! :)



  • @jeremyb:

    Je suis désolé de vous contredire mais vos sources datent du 3 mars 2009 …

    Les publications de Christian Caleca sont plutôt très bien et en tous cas certainement très intéressantes à ton niveau de compréhension et d'expérience. Prend la peine d'y jeter un coup d'oeil même si tu penses que c'est trop vieux  ;D

    Ceci étant, la seule vraie référence, c'est la RFC. Si tu lis et comprends la RFC2616, tu devrais normalement comprendre que, by design, c'est inhérent au protocole, il n'est pas possible, comme le dit jdh, d'avoir en même temps authentification au niveau du proxy HTTP (c'est un proxy en mode explicite) et un proxy en mode transparent  (pour la même session car l’application Squid supporte très bien de fonctionner en même temps en mode transparent et explicite, mais pour 2 sessions différentes).

    Ta phrase est cependant correcte mais tu ne comprends pas pourquoi et du coup, ton expression des besoins est probablement erronée :

    @jeremyb:

    Il est "normalement" aujourd'hui possible d'utiliser le proxy transparent avec une méthode d'authentification par portail captif.

    Effectivement. C'est juste.  :)

    Deux modes de fonctionnement possibles :

    1 - l’authentification se fait au niveau du portail captif puis transmet les informations d’authentification au proxy si celui-ci est décrit de manière explicite (à la main sur chaque poste ou WPAD)

    2 - l’authentification se fait sur le portail captif puis un proxy en mode transparent, mais donc pas de relais d'authentification au
    Le proxy est totalement transparent

    mais le mélange "authentification transmise au proxy" et "proxy en mode transparent", ce n'est pas possible.(1)

    PfSense propose cette solution, je n'arrive simplement pas à la faire marcher, je voudrai juste savoir si quelqu'un a déjà réussit ou non !

    Le portail captif et le proxy en mode transparent s'appuient un fonctionnement assez similaire qui consiste à intercepter des paquets pour les rediriger soit vers une page web lorsqu'il s'agit du portail soit pour proxier la requête lorsqu'il s'agit dur proxy.

    Dans un mode ou le proxy est physiquement derrière le portail captif, il n'y a pas de problème en mode proxy transparent puisque le portail sera toujours le premier à intercepter la requête pour mettre çà jour les règles de FW.

    Si tu veux faire fonctionner portail et proxy sur la même machine, c'est un peu plus compliqué car la première fois, c'est le portail qui intercepte mais celui-ci s'efface ensuite pour laisser la place, sur la même machine, au proxy en mode transparent.

    En mode explicite, le portail ne peut pas être avant le proxy car d'un point de vue FW, dans ce cas, la requête vient du proxy et le portail captif ouvrirait des règles pour le proxy, donc tout le monde.
    Il faut donc également le portail avant le proxy et probablement une règle dans le proxy.pac pour gérer une exception qui permet d'accéder au portail captif sans passer par le proxy.

    J'avoue ne pas avoir regardé les aspects "portail captif lié au proxy" de très près mais que ce soit en 2009 ou en 2016, il n'y a pas de révolution dans la manière dont les protocoles fonctionnent.

    (1) il n'est pas interdit de penser à faire des montages avec des cascades de proxy qui fonctionneraient de manière différente, avec un premier proxy qui se chargerait d'intercepter des flux de manière transparente et de gérer des sessions vers un proxy configuré de manière explicite pour un client qui serait le proxy transparent (lequel devrait gérer ces sessions). Pour l’utilisateur, c'est transparent  ;D mais c'est quand même très compliqué  :o
    Par exemple Zentyal fonctionne de cette manière (pour d'autres raisons que la problématique portail captif que tu évoques)



  • Si tu es persuadé que nous vivons une époque moderne et que la RFC est également très ancienne (joke  ;D) ou qu'elle est trop longue à lire et difficile à comprendre (ce qui est vrai), je t'invite à lire directement la prose de  Squid à ce propos.

    Why can't I use authentication together with interception proxying?

    Interception Proxying works by having an active agent (the proxy) where there should be none. The browser is not expecting it to be there, and it's for all effects and purposes being cheated or, at best, confused. As an user of that browser, I would require it not to give away any credentials to an unexpected party, wouldn't you agree? Especially so when the user-agent can do so without notifying the user, like Microsoft browsers can do when the proxy offers any of the Microsoft-designed authentication schemes such as NTLM (see ../ProxyAuthentication and Features/NegotiateAuthentication).

    In other words, it's not a squid bug, but a browser security feature.

    Can I use ''proxy_auth'' with interception?

    No, you cannot. See the answer to the previous question. With interception proxying, the client thinks it is talking to an origin server and would never send the Proxy-authorization request header.



  • Je suis désolé de vous contredire mais vos sources datent du 3 mars 2009 …

    Qu'est ce qui a changé le 3 mars 2009 ?

    J'ai trouvé un lien http://www.cert-ist.com/public/fr/SO_detail?code=200902proxy qui date du 4 mars 2009 et qui parle de faille dans le proxy transparent. Mais est ce cela ?

    Il est "normalement" aujourd'hui possible d'utiliser le proxy transparent avec une méthode d'authentification par portail captif.

    Je reprends ce qu'a écrit auparavant Chris4916 (et c'est rare) 'Portail captif et Squid sont 2 choses totalement différentes et indépendantes' :

    • Le portail actif permet, à partir d'une authentification, de traverser le firewall, et ceci pour tous protocoles.
    • un proxy Squid peut authentifier des utilisateurs : plus précisément Squid peut transmettre une authentification client - serveur, décrite (excellement) par https://fr.wikipedia.org/wiki/Authentification_HTTP
      (Une réflexion assez élémentaire permet de comprendre que le mode transparent est incompatible avec l'authentification http car le proxy est incapable d'ajouter les entêtes d'authentification : 'would never send the Proxy-authorization request header' !)

    Le seul lien possible (et non instantané), serait d'associer authentification du portail captif (identification -> heure + adresse ip) avec le log du proxy (heure + ip -> identification). Bon courage pour joindre les 2 logs …



  • @jdh:

    Cet article est bien fait en ce qui concerne l’authentification HTTP.
    Je trouve dommage qu'il n'évoque pas des trucs comme Kerberos, pour rester dans "HTTP authenticaiton"

    Sur la partie très succincte du proxy, ce n'est pas très clair :

    Il est également possible de s'identifier auprès des serveurs intermédiaires :
        Utilisateur à proxy
        Proxy à proxy
        Proxy à serveur d'origine.
    Pour cela, les en-têtes HTTP Proxy-Authenticate et Proxy-Authorization sont utilisés à la place des en-têtes WWW-Authenticate et Authorization. Le code d'état HTTP 407 est utilisé au lieu du code 401.
    L'en-tête Proxy-Authentication-Info a le même rôle que l'en-tête Authentication-Info.
    Un client peut devoir s'identifier à la fois à un proxy et au serveur d'origine, mais pas dans la même réponse.

    • l'authentification de "proxy à serveur d'origine" ??? de mon point de vue, le proxy ne peut demander une authentification qu'à un "client" (c'est à dire le process qui soumet la requête HTTP au proxy)
    • ça laisse croire que le proxy pourrait jouer le rôle de relais d’authentification auprès du serveur Web, ce qui n'est pas le cas, sauf à écrire un redirecteur qui automatiserait l'envoie de la réponse à HTTP 407 lors de la réponse HTTP 401
    • comme écrit à la fin : "Un client peut devoir s'identifier à la fois à un proxy et au serveur d'origine, mais pas dans la même réponse.", ce qui ne va pas bien avec "Proxy à serveur d'origine" sauf si je ne comprends pas cette phrase

    Le seul lien possible (et non instantané), serait d'associer authentification du portail captif (identification -> heure + adresse ip) avec le log du proxy (heure + ip -> identification). Bon courage pour joindre les 2 logs …

    Le portail captif peut (et c'est l'implémentation de pfSense) envoyer au proxy HTTP l'authentification de l'utilisateur. Bien sûr, ça nécessite que portail et proxy s'appuient sur la même base de compte.

    ça reste fonctionnellement 2 choses différentes (règles de FW d'un coté, relais HTTP de l'autre) mais qui peuvent bénéficier d'une authentification unique, si le proxy en en mode "explicite"  ;)



  • Tout d'abord, merci beaucoup à vous deux pour vos réponses.

    Alors pour tout vous expliquer, je pensais effectivement que en sélectionnant la méthode d'authentification par portail captif, le Squid regarderai l'adresse MAC de l'utilisateur, irait chercher l'adresse MAC des l'utilisateurs connectés dans le portail captif. Il vérifierai alors si l'adresse MAC est présente dans celles qu'il a récupérées dans le portail captif, et si c'est le cas, il autoriserai l'accès aux utilisateurs connectés.

    Je pensait que cette fonctionnalité pourrait m'aider à pallier mes problèmes mais ce ne serait donc pas possible si je comprends bien ?

    Je dois vous avouer que je n'ai pas connaissance de toutes ces règles et j'apprends petit à petit par moi même.



  • @jeremyb:

    Alors pour tout vous expliquer, je pensais effectivement que en sélectionnant la méthode d'authentification par portail captif, le Squid regarderai l'adresse MAC de l'utilisateur, irait chercher l'adresse MAC des l'utilisateurs connectés dans le portail captif. Il vérifierai alors si l'adresse MAC est présente dans celles qu'il a récupérées dans le portail captif, et si c'est le cas, il autoriserai l'accès aux utilisateurs connectés.

    L’authentification / autorisation par adresse MAC, c'est un leurre. Il est facile de changer l'adresse MAC de sa carte réseau.

    Je pensait que cette fonctionnalité pourrait m'aider à pallier mes problèmes mais ce ne serait donc pas possible si je comprends bien ?

    Difficile de répondre car dans toute cette discussion, j'avoue que je ne comprends pas quel est, au départ, la problématique à laquelle tu souhaites répondre.
    J'ai bien une petite idée mais comme tu dois commencer à le comprendre, en fonction de l'objectif visé, il y a différentes solutions qui ont chacune, des avantages et des inconvénients.

    Il est donc primordial de bien formuler, au départ, le besoin fonctionnel, ce qui est u exercice difficile car la formulation précise suppose d'avoir déjà une petite idée de la solution technique associée et des avantages et contraintes.

    Si je fais un peu d’interprétation de ce que tu décris :

    • l'accès au wifi est contrôlé par Radius / LDAP. N'ont donc accès au wifi que des utilisateurs identifiés.
    • il est aisé de ne pas autoriser l'accès au web sans passer par le proxy, lequel peut en plus demander une authentification pour faire du filtrage et gérer des droits d'accès plus fins à ce service
    • je ne sais pas à quoi servirait le portail captif, sauf si tu as besoin de gérer l'accès à internet ou de limiter les temps d'accès au web.
    • je ne sais pas à quoi sert


  • Je confirme bien sûr que l'on peut oublier tout ce qui utilise l'adresse mac pour es questions de sécurité.
    Je pense aussi qu'il est difficile de vous répondre (cela fait un moment que je le dis et pourquoi).
    On peut supposer qu'il y a un annuaire quelque part. Il faut par ailleurs bien distinguer si vous souhaitez identifier des machines ou des utilisateurs. Dans un cas comme dans l'autre je ne vois pas non plus à quoi sert le portail captif pour authentifier les utilisateurs au niveau de Squid (ce qui est une bonne chose, en fait une quasi obligation). Bref nous voilà revenu à la case départ : besoin fonctionnel.



  • Je suis vraiment désolé mais je ne vois pas comment faire une description du besoin fonctionnel…

    Je veux bien essayer de reexpliquer, si cela ne marche pas faites le moi savoir !

    L'authentification à mes points d'accès sont gérés par un portail captif puis un radius qui discute avec un LDAP.
    J'ai donc deux portails captifs car j'ai deux types d'utilisateurs :

    - le portail "privé" pour les utilisateurs qui appartiennent au groupe LDAP "PRIVE"

    -Le portail "public" où tous les utilisateurs présent dans le LDAP peuvent s'y connecter.

    J'ai donc besoin du portail captif car quand celui-ci émet une requête au Radius il possède et NAS et le traitement des groupes en fonction du portail captif est réalisé grâce à celui ci.
    Autrement dit, les utilisateurs qui se connecteront à la WIFI privé mais qui ne sont pas dans le groupes LDAP PRIVE ne pourront pas se connecter.

    C'est donc cette option qui m'ai très interressante grâce au portail captif. Je peux donc gérer l'accès à un point d'accès wifi en fonction du groupe LDAP des utilisateurs. Bien sur , il n'y a pas la même bande passante pour les utilisateurs du WIFI privé et les utilisateurs du WIFI public. Il y aura également des restrictions horaires pour le Wifi public.

    Maintenant , sur mes deux points d'accès WIFI , un Squid ( le package de pfSense) est en écoute afin d'assurer la reuperation des logs. Il fonctionne en mode transparent car je ne voudrai pas obliger mes utilisateurs à s'authentifier plusieurs fois etc... Associé à Squid , j'ai également SquidGuard qui permet la restriction à des sites grâce à une blacklist.

    Mon soucis apparaît maintenant :

    Vu que mon Squid écoute sur mes deux points d'accès wifi , le port 3128 ( port par défaut ) est donc ouvert. N'importe quel utilisateur peut donc configurer son navigateur de façon à utiliser un proxy sur l'adresse de passerelle et sur le port 3128. À partir de là , le portail captif n'apparaitra donc plus car les requêtes seraient directement redirigees au Proxy et n'importe quel utilisateur pourrait donc accéder à Internet par la WIFI privé car il n'y aurait pas d'authentification... N'importe quel utilisateur pourrait donc bénéficier des privilèges de la Wifi prive ( Meme un utilisateur externe ( non renseigné dans le Ldap) vu qu'il n'y a pas d'authentification ).

    Pour pallier à cette problématique , je pensait pouvoir autoriser l'accès au Squid seulement pour les utilisateurs connectés au portail captif. Je pensait donc que l'authentification au Squid par portail captif serait ma solution mais apparement pas.

    Mon but est donc de bloquer l'accès au Squid aux utilisateurs qui ne sont pas connectés au portail captif ( tout en gardant le proxy en mode transparent si cela est possible... ).

    J'espere que je me suis exprimé de manière un peu plus convenable et que j'ai su exprimer mon besoin.

    Merci encore et merci beaucoup pour vos réponses , j'espere pouvoir avancer ... !



  • @jeremyb:

    Je suis vraiment désolé mais je ne vois pas comment faire une description du besoin fonctionnel…

    Je veux bien essayer de reexpliquer, si cela ne marche pas faites le moi savoir !

    L'authentification à mes points d'accès sont gérés par un portail captif puis un radius qui discute avec un LDAP.
    J'ai donc deux portails captifs car j'ai deux types d'utilisateurs :

    - le portail "privé" pour les utilisateurs qui appartiennent au groupe LDAP "PRIVE"

    -Le portail "public" où tous les utilisateurs présent dans le LDAP peuvent s'y connecter.

    J'ai donc besoin du portail captif car quand celui-ci émet une requête au Radius il possède et NAS et le traitement des groupes en fonction du portail captif est réalisé grâce à celui ci.
    Autrement dit, les utilisateurs qui se connecteront à la WIFI privé mais qui ne sont pas dans le groupes LDAP PRIVE ne pourront pas se connecter.

    .../...

    Il n'y a pas de quoi être désolé. L'exercice n'est pas aussi simple qu'il y parait.

    Pour essayer de clore ce sujet de la description du besoin fonctionnel : ce que tu décris dans ton dernier message, c'est une solution (qu je ne comprends d'ailleurs pas) et pas un besoin.
    Tu décris des produits (Squid, portail captif, radius etc…)  et non pas des fonctionnalités.

    Et tu commences par introduire la notion de portail captif sans même décrire pourquoi (pour quel usage) tu choisis cette solution.
    Tu tentes bien une description mais j'avoue ne pas la comprendre. je ne fais pas le lien entre Radius et NAS.

    J'intuite bien que tu veux autoriser les utilisateurs d'un groupe LDAP à autoriser ou pas à un service wifi mais ta solution "ne fonctionne pas", selon moi.

    Si ton besoin est de t'appuyer sur LDAP pour le contrôle d'accès au wifi, il n'y a pas besoins de portail : "WPA2 AES Enterprise", qui s'appuie sur Radius lequel s'appuie sur LDAP rempli parfaitement cette fonction.

    Dans ta description, l'utilisateur est déjà connecté au wifi. le portail captif autorise ou pas l'accès à ce qui est derrière le FW que ce portail contrôle.
    La nuance est de taille.

    L'étape suivante : tu veux un log qui fait quoi sur le web. S'il s'agit de web et pas d'internet, le proxy est une bonne solution mais si le besoin est bien "qui fait quoi" alors il n'y a pas d'autre solution que l’authentification. Tu tires hâtivement la conclusion que, pour limiter le nombre d’authentification, il faut être en mode transparent.

    Il y a d'autres solutions.
    La transmission de l’authentification du portail captif à Squid en est une partielle uniquement : lorsque l'utilisateur accèdes au portail et s'y authentifie, l’authentification peut être passée à Squid mais si l'utilisateur ferme son navigateur en ayant un token toujours valide pour l'accès au travers du portail captif, la prochaine fois qu'il accède au web, les ports (FW) sont ouvert, il n'y a pas d’authentification au portail mais le il devrait y en avoir une au niveau du proxy.

    Pour faire du SSO avec Squid, tu peux par exemple mettre en œuvre Kerberos.

    Et donc, avec (si j'interprète bien), un besoin fonctionnel identique au tien, je pourrais proposer WPA2 Enterprise sur les bornes Wifi et Kerberos pour l'authentification pour un résultat "visuellement"  ;) identique sans portail captif.

    D'où l'importance de bien se focaliser sur les besoins fonctionnels plutôt que sur les solutions? Mais c'est un exercice difficile, je te l'accorde.

    Pour conclure cette longue tirade : mets toi bien en tête que le proxy HTTP en mode transparent est incapable d'identifier quoi que ce soit d'autre qu'une adresse IP. Si tu veux bloquer ou limiter son usage à certains "utilisateurs" (et non pas machines… et encore), il n'y a pas d'autre solution que, au niveau du proxy, l'authentification.

    Si tu n'as pas ce besoin de filtrage, log d'accès web etc... et si on oublies cette histoire de controle d'accès au wifi qui me semble bancale, en alignant portail captif puis proxy en ode transparent, seuls les utilisateurs autorisés au travers du portail captif pourront accéder au proxy... à condition de ne pas exposer le proxy à tout le mode.

    Et on tombe la dans le deuxième niveau de problème :

    • même une fois que tu as décris une solution qui fonctionnellement semble répondre au besoin, il faut veiller à l'implémentation :
      le problème principal (ça va faire plaisir à certains  :-X), c'est que tu as décidé de tout mettre sur la même machine.
      Si tu avais, en série, sur des machines différentes (1)  un portail captif puis un proxy, l'accès validé au travers du portail donnerai accès au proxy uniquement aux utilisateurs authentifiés.

    autre preuve que besoin et solution sont deux choses très différentes  ;)

    (1)  techniquement, il est possible d'avoir sur la même machine portail captif et proxy transparent, mais probablement pas avec pfSense car cela nécessite de rediriger les requêtes HTTP vers un port interne sur lequel écoute le proxy, voire, selon les besoins, d'empiler 2 proxy (j'ai déjà décrit ça dans un message précédent)



  • @jeremyb:

    Je suis vraiment désolé mais je ne vois pas comment faire une description du besoin fonctionnel…

    Je veux bien essayer de reexpliquer, si cela ne marche pas faites le moi savoir !

    L'authentification à mes points d'accès sont gérés par un portail captif puis un radius qui discute avec un LDAP.
    J'ai donc deux portails captifs car j'ai deux types d'utilisateurs :

    - le portail "privé" pour les utilisateurs qui appartiennent au groupe LDAP "PRIVE"

    -Le portail "public" où tous les utilisateurs présent dans le LDAP peuvent s'y connecter.

    J'ai donc besoin du portail captif car quand celui-ci émet une requête au Radius il possède et NAS et le traitement des groupes en fonction du portail captif est réalisé grâce à celui ci.
    Autrement dit, les utilisateurs qui se connecteront à la WIFI privé mais qui ne sont pas dans le groupes LDAP PRIVE ne pourront pas se connecter.

    Tout cela décrit des solutions techniques.

    C'est donc cette option qui m'ai très interressante grâce au portail captif. Je peux donc gérer l'accès à un point d'accès wifi en fonction du groupe LDAP des utilisateurs. Bien sur , il n'y a pas la même bande passante pour les utilisateurs du WIFI privé et les utilisateurs du WIFI public. Il y aura également des restrictions horaires pour le Wifi public.

    Là c'est un mélange.

    Maintenant , sur mes deux points d'accès WIFI , un Squid ( le package de pfSense) est en écoute afin d'assurer la reuperation des logs. Il fonctionne en mode transparent car je ne voudrai pas obliger mes utilisateurs à s'authentifier plusieurs fois etc… Associé à Squid , j'ai également SquidGuard qui permet la restriction à des sites grâce à une blacklist.

    Mon soucis apparaît maintenant :

    Vu que mon Squid écoute sur mes deux points d'accès wifi , le port 3128 ( port par défaut ) est donc ouvert. N'importe quel utilisateur peut donc configurer son navigateur de façon à utiliser un proxy sur l'adresse de passerelle et sur le port 3128. À partir de là , le portail captif n'apparaitra donc plus car les requêtes seraient directement redirigees au Proxy et n'importe quel utilisateur pourrait donc accéder à Internet par la WIFI privé car il n'y aurait pas d'authentification... N'importe quel utilisateur pourrait donc bénéficier des privilèges de la Wifi prive ( Meme un utilisateur externe ( non renseigné dans le Ldap) vu qu'il n'y a pas d'authentification ).

    Pour pallier à cette problématique , je pensait pouvoir autoriser l'accès au Squid seulement pour les utilisateurs connectés au portail captif. Je pensait donc que l'authentification au Squid par portail captif serait ma solution mais apparement pas.

    Mon but est donc de bloquer l'accès au Squid aux utilisateurs qui ne sont pas connectés au portail captif ( tout en gardant le proxy en mode transparent si cela est possible... ).

    Désolé, mais c'est encore de la description de solution technique.

    J'espere que je me suis exprimé de manière un peu plus convenable et que j'ai su exprimer mon besoin.

    Merci encore et merci beaucoup pour vos réponses , j'espere pouvoir avancer … !

    Le problème n'est pas que ce soit convenable ou pas. Il faut poser le problème correctement.  Un exemple de ce qui pourrait être une début de description fonctionnelle. Sans préjugé de votre situation réelle que je ne connais pas.
    L'entreprise est confrontée à deux populations différentes d’utilisateurs pour lesquels elle souhaite mettre à disposition certaines ressources et en protéger d'autres dans des conditions conforme à la PSSI.  Elle possède possède un réseau wifi assurant le transport des données.

    C'est un exemple de début de descriptif qui n'induit aucune solution technique et qui prend acte d' une situation (Wifi). Je ne sais pas si cela correspond à votre situation. Probablement pas puisque vous avez du mal a expliciter les choses.
    Je rédige cette réponse dans l'espoir que quelques uns comprennent de quoi il s'agit lorsque l'on parle d'approche fonctionnelle pour en déduire des solutions techniques adaptées à des contraintes et à un existant. Pour le moment vous êtes "tourné à l'envers", vous ne parlez que de solutions techniques.
    Comme dit le faux proverbe chinois : Si tu ne sais pas où tu vas, tu pourrais bien te retrouver ailleurs.


Log in to reply