Méthode d'authentification Squid par portail captif

jeremyb

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 ! :)

chris4916

@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)

chris4916

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.

jdh

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 …

chris4916

@jdh:

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

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" ;)

jeremyb

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.

chris4916

@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

ccnet

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.

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.

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 ... !

chris4916

@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)

ccnet

@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.