Reverse proxy et problème d'authentification



  • Bonjour.
    En fait je suis en stage dans une entreprise et on m'a donné comme projet de faire un reverse proxy d'authentification.
    Pour cela après l'installation de mon pfsense j'ai téléchargé le paquet SQUID qui permet de faire du reverse proxy.
    Cependant j'ai réussi à mettre en place le reverse proxy et ça fonctionne, c'est à dire j'arrive à accéder au serveurs internes et qu'il n'y a pas d'authentification.

    WAN(192.168.1.0/24                                        LAN(10.10.10.0/24
    Client (IP 192.168.1.168)        ==========================>Pfsense<====================== Word Press (IP 10.10.10.3) 
    Dans le fichier Host j'ai mis                                                            .110                      .1                                     
                                                                      Reverse Proxy permettant que un.gning.fr soit le Word Press
    192.168.1.110 ==> un.gning.fr                                                                                                                                  http://un.gning.fr=>http://10.10.10.3

    Et il me reste à effectuer la partie authentification (c'est à dire que j'aimerai avant qu'on accède au serveurs dans le LAN qu'on s'authentifie d'abord sur le reverse proxy).
    J'étais parti sur la solution de mettre un portail captif sur la patte WAN mais le problème en est que cela ne fonctionne pas car je ne vois même pas le page d'authentification. Est ce une bonne idée d'utiliser ce portail captif?
    Sinon est ce que vous aurez peut être une idée de mettre en place l'authentification (avec identifiant, mot de passe).
    Merci d'avance.



  • 1 - un portail captif, ça ne fonctionne pas du tout, mais alors pas du tout comme un reverse proxy.
    2 - Squid comme reverse proxy, ce n'est pas la meilleure solution, à mon avis

    A ta place, je ferais un reverse proxy avec, par exemple un HAproxy ou mieux un Nginx sur une machine connectée à une DMZ attachée à pfSense et une authentification vers un annuaire LDAP interne (au fait, combien d'utilisateurs dans ton projet ?)



  • 1. Strictement rien à voir entre un reverse proxy et un portail captif. Pas les mêmes fonctionnalités pas les mêmes objectifs.
    2. HAProxy, une référence pour les reverses. Nginx possible mais aussi Kemp qui fourni une version free sous forme d'une vm.



  • D'accord!!!

    Mais est ce que HAproxy peut permettre d'avoir une authentification avec le reverse proxy?

    Mon projet à une trentaine d'utilisateurs.



  • Je ne sais pas te répondre en ce qui concerne les possibilités exposées par le package pfsense (car je suppose que c'est à ça que tu fais allusion) mais un HAproxy standalone sait tout à fait faire ça.

    La question qui se pose rapidement est celle de la base de comptes utilisée et donc du mode d'authentification.
    Et juste après va se poser la question des applications : si tu mets en place un reverse proxy avec authentification juste pour t'assurer que seuls les utilisateurs autorisés ont accès, pas de problème mais si tes applications demandent une authentification, la tentation est grande de demander au reverse proxy de rejouer celle ci.

    De mon point de vue, c'est une fausse bonne idée…



  • Donc de ton point de vue il n'est pas nécessaire de remettre une authentification au reverse proxy?

    Car comme tu (Chris) l'as dis sur les serveurs en internes, il faut s'authentifier d'abord.

    Donc si je comprends bien on pourra laissé la fonction reverse proxy et renforcer la sécurité sur les serveurs internes.



  • Ce n'est pas exactement mon point. Désolé si je n'ai pas été clair.
    Ce que je veux dire, c'est que l'authentification au niveau du REVERSE proxy permet de contrôler qui a accès au LAN via ce reverse proxy. L'authentification côté application permet de géré authn et authz. Les deux sont probablement nécessaires en fonction de l'application.
    Par contre, la tendance est très souvent, parce que on souhaite offrir à l'utilisateur un mode SSO like, de faire 'rejouer' au reverse proxy l'authentification de l'utilisateur, ce qui signifie stocker celle ci sur la machine qui a une patte sur Internet.
    De mon point de vue, si on veut du SSO, il faut mettre en place l'infrastructure qui le supporte mais pas faire du faire.



  • D'accord alors l'infrastructure que j'ai ne le supporte pas?



  • Je ne dis pas ça non plus ;)

    Mais tu peux commencer avec une authentification à chaque étape et traiter ultérieurement les aspects SSO.

    Comment ça fonctionne aujourd'hui pour les applications depuis le LAN ?



  • Les applications sont accessibles depuis internet et il faut tout simplement mettre un login et mot de passe pour y accéder.



  • Oui certes… Mais comment sont gérés les comptes des utilisateurs autorisés à accéder à ces applications ?
    Localement sur chaque serveur ?



  • OUI! pardon sur chaque serveur il y'a une base données des utilisateurs qui sont autorisés.



  • Dans ma liste des solutions possibles j'ai oublié Vulture : https://www.vultureproject.org/doc/
    L'authentification (et tout ce qui tourne autour, SSO, propagation, …. ) est une partie importante et il y de nombreuse façon de la mettre en œuvre.
    Voir aussi : https://kemptechnologies.com/news/kemp-technologies-adds-pre-authorization-single-sign-sso-and-persistent-logging-load-balancers/



  • Merci des solutions je suis entrain de regarder Vulture.



  • Vulture pour faire du reverse proxy, pourquoi pas. C'est basé sur HAproxy.

    donc pour la partie "proxy", oui sans réserver.

    Pour la partie authentification ou velléité de SSO, tu es, à mon avis parti dans la mauvaise direction. Mais ce n'est que mon avis personnel bien sûr  ;)
    Déjà avec une base de compte locale pour chaque application, le SSO c'est mal parti. que comptes tu faire ? appuyer l’authentification du reverse proxy sur une de ces bases ou bien comptes-tu en créer une de plus ?

    De mon point de vue, en ce qui concerne la gestion des comptes, le strict minimum ici c'est LDAP.

    Je ne dis pas qu'il n'y a QUE LDAP mais en ce qui concerne les comptes, c'est quand même mieux. Après pour la gestion de l'authentification, il y a des solutions comme CAS (Jasig) qui permettent, à la mode Kerberos, du "web-SSO"

    Et, encore une fois c'est un avis qui n'engage que moi, la fonctionnalité qui permet de faire du "store & forward" de l'authentification tel que proposé par Vulture (qui par ailleurs est un assemblage élégant de solutions open source) n'est pas une très bonne idée.



  • permet de faire du "store & forward" de l'authentification tel que proposé par Vulture

    Dans la dernière version c'est quand même un peu plus que cela.

    Sinon, pour le reste en effet, la question de la gestion de l'authentification, le stockage sur chaque serveur n'est pas une solution très satisfaisante. Un ldap serait un minimum.



  • Ce que je compte faire (Chris) c'est de centraliser l'authentification au niveau de mon reverse proxy de ce fait après on pourra même supprimer les authentifications se trouvant au niveau des serveurs en internes.



  • @ccnet: j'avoue ne pas avoir regardé récemment les évolutions de Vulture tellement je suis fermé au concept même du relais d'authentification.

    @saliou: pourquoi pas… Mais l'idée me semble plutôt étrange. Ça signifie que, en interne, les applications ne demandent plus d'authentification ?  Et où est la base de comptes utilisée par le reverse proxy ?



  • Chris. En fait le fait que je supprimerai l'authentification au niveau des serveurs internes c'est juste une supposition je pourrai le laisser comme ça pour plus de sécurité.
    Mais en fait mon problème c'est qu'en ce moment je n'ai pas encore de solutions pour mettre l'authentification sur mon reverse proxy (le plus important pour moi).



  • Il faut :

    • choisir ta solution
    • implémenter le backend supporté par cette solution en terme d'authentification

    … Et c'est tout.

    Quel est ton point de blocage ?



  • Oui je vois je bloque par rapport au choix de la solution.



  • Il est évident qu'il faut débuter par la définition des critères qui sont pour toi importants mais au final, il n'y a pas beaucoup de choix techniques :

    • squid
    • nginx
    • HAproxy, en mode standalone ou dans un bundle type Vulture.

    Ça ne t'engage pas beaucoup d'en choisir un et d'aller au bout de l'implémentation. De toute manière tu vas te rendre compte que la problématique n'est pas le reverse proxy lui même mais la gestion des comptes utilisateurs



  • SQUID c'est ce que j'ai pour le reverse proxy mais à ce que j'ai vu l'authentification ne serai pas prise en compte.
    T'en pense quoi?



  • Je ne sais pas d'où tu sors que Squid en mode reverse proxy ne supporte pas d'authentification ???



  • Ban, parce sa mise en oeuvre je ne vois pas où çà se fait sur mon pfsense.



  • La mise en oeuvre de l'authentification sur reverse proxy squid avec pfSense, je ne voit pas où ça se fait.



  • D'où l'intérêt de formuler dès le début le contexte et la bonne question (et si tu l'as fait, je ne l'ai pas mémorisé)…
    Je ne sais pas si le package Squid délivré avec pfsense permet un fonctionnement en mode reverse proxy. Même si le produit et le même, la configuration est différente.
    Et donc si l'interface ne le permet pas, ce n'est pas la solution à retenir.
    Ce qui ne t'empêche pas d'utiliser Squid mais pas en tant que package et donc pas "sur" pfsense



  • D'accord Merci, mais est ce qu'alors HAproxy fait une authentification avec l'interface.
    En plus est ce que sa(HAproxy) documentation est "abondante". :)



  • @chris4916:

    Il est évident qu'il faut débuter par la définition des critères qui sont pour toi importants mais au final, il n'y a pas beaucoup de choix techniques :

    • squid
    • nginx
    • HAproxy, en mode standalone ou dans un bundle type Vulture.

    Ça ne t'engage pas beaucoup d'en choisir un et d'aller au bout de l'implémentation. De toute manière tu vas te rendre compte que la problématique n'est pas le reverse proxy lui même mais la gestion des comptes utilisateurs

    Entièrement d'accord. Un problème bien posé est à moité résolu.



  • Alors ce que je veux c'est que j'ai un reverse proxy (SQUID) qui fonctionne sur pfSense. Donc en ce moment sur une seule IP publique j'arrive à joindre mes serveurs en interne.

    Et je veux avant qu'on puisse accéder aux serveurs internes qu'on s'authentifie et après cette authentification que le reverse proxy fait la redirection vers le bon serveur.



  • Je ne vais pas pouvoir t'aider sur la partie "Squid en reverse proxy sur pfSense" car je ne savais même pas que cette configuration était supportée. Mais si tel est bien le cas, alors c'est le module standard d'authentification de Squid qui prend le relais et, si je me souviens bien, le package Squid permet d'authentifier des comptes locaux (pfsense mais est-ce une bonne idée ?) Ou LDAP



  • @Chris: D'accord Merci de votre réponse. :)



  • @chris: Bonjour je me permets de revenir vers vous car avec ma machine pfSense, on peut voir le fichier de configuration de squid (squid.conf) si on se connecte en ssh ce que je ne savais pas la fois passée.

    En ce moment j'ai aussi  le fichier squid.conf ce que vous appelez n'est pas? le module standard d'authentification de squid.

    Et que moi ce que je veux c'est que j'aimerai avoir une authentification de comptes locaux.

    Est ce que vous pourriez m'aider de documentation s'il vous plait?


Log in to reply