Reverse proxy et problème d'authentification

saliou

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.

chris4916

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

ccnet

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.

saliou

D'accord!!!

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

Mon projet à une trentaine d'utilisateurs.

chris4916

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…

saliou

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.

chris4916

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.

saliou

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

chris4916

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 ?

saliou

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

chris4916

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

saliou

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

ccnet

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/

saliou

Merci des solutions je suis entrain de regarder Vulture.

chris4916

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.

ccnet

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.

saliou

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.

chris4916

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

saliou

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

chris4916

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 ?