Vlan invité + portail captif + proxy
-
Bonjour à tous.
Je vous présente mon problème et j'espère trouver la solution ici.
J'ai un PfSense v2.2.6-RELEASE (amd64) avec une interface dans chacun de mes réseaux :
WAN 9.254 (/24) Sorti Wan
PEDA 1.254 (/24) Réseau de base
DMZ 40.14 (/24) Dans lequel se trouve mon proxy
GUEST 223.254 (/24) Réseau invitéLe PEDA est autorisé à communiquer avec le DMZ.
Le GUEST est autorisé à communiquer avec le DMZ.Mon réseau PEDA est le réseau d'utilisation normale.
Les PROXY des utilisateurs sont paramétrés par GPO, et tout le trafic est filtré par ce proxy.Mon réseau GUEST est un réseau invité pour toute personne étrangère à mon établissement.
Les utilisateurs utilisant ce réseau doivent s'authentifier au travers d'un portail captif qui est lié à un serveur RADIUS (NPS sous W2012 R2 et un AD).
Tout fonctionne bien.Cependant voici mon problème :
Tout le traffic du GUEST sort directement vers le WAN sans passer par le proxy de mon réseau DMZ et ça c'est juste pas possible (protection des mineurs).
Je souhaite donc que tout le traffic soit redirigé vers mon proxy sans que les utilisateurs ne soient génés, en mode transparent donc.J'ai essayé de chercher comment rediriger mon trafic vers mon proxy mais je ne trouve rien de concluant.
J'ai essayé :
Regle NAT Outbound
Sur l'interface WAN, source GUESTnet, destination all, redirigé vers mon adresse proxy sur le bon port.
Mais ce n'est visiblement pas ça.Merci pour toute aide que vous pourrez m'apporter, n'hésitez pas si vous voulez d'autres informations !
Merci !
-
ton proxy sait-il qu'il doit fonctionner à la fois en mode transparent et en mode explicite ?
-
Merci à toi de m'accorder du temps.
Je suis vraiment pas à l'aise avec Squid, mais d'après ce que j'ai vu. Pour qu'il soit en mode transparent (en plus du mode non-transparent) il faut juste rajouter "http_port 3128 transparent" ?
C'est fait, mais je ne suis pas sûr que ce soit aussi simple.
Mais comment le traffic qui arrive de mon GUEST vers le WAN va être redirigé vers mon proxy ? Il faut faire une redirection sur le PfSense non ?
Je précise que mon Squid est sur un CentOs 7
Edit : J'ai essayé de faire du port forward également sur mon PfSense.
Tout ce qui vient du GUEST en direction de l'HTTP et l'HTTPS est redirigé sur mon proxy sur le port 3128.
Alors ok mon Squid reçoit les requêtes mais ne les traite pas, ce qui me parait normal meme si je ne comprends pas.Voici ce que j'obtiens lors de ce test, sur mon access.log
0 IP TAG_NONE/400 3931 GET / - HIER_NONE/ - test/html -
En gros voici mon schéma simplifié :
Les clients de mon réseau PEDA sont configuré pour utiliser mon proxy donc pas de soucis, ils l'utilisent.
Par contre les clients de mon reseau GUEST, je n'ai pas la main sur leur configuration.
Voilà pourquoi je dois avoir mon PfSense qui doit tout rediriger le traffic du GUEST vers mon proxy, mais je ne sais pas comment paramétrer PfSense et Squid.J'espère être plus clair afin d'avoir de l'aide.
Merci
-
La description est assez claire mais je pense qu'il y a un problème de conception : ce n'est pas, à mon avis au niveau du WAN qu'il faut faire du forward mais au niveau de l'interface du réseau guest pour rediriger vers le proxy.
La difficulté étant que cette même interface intercepte. Déjà le flux HTTP pour le portail captif… Mais il me semble que le portail captif peut justement être configuré pour ensuite s'appuyer sur le proxy -
Mon port forward est déjà paramétré sur l'interface GUEST en fait.
Je vois les requêtes http arrivées dans mon access.log :
Alors sur mon client test dans le Guest :
Les requêtes http ne passent pas 'Invalid URL' et sont affichées dans le access.log
Cependant les requêtes https passent mais ne sont pas filtrées et ne sont pas affichées dans le access.log
Edit : Au niveau du portail captif de PfSense, j'ai déjà regardé s'il y a une option pour le proxy mais non, aucune :/
Idem au niveau du serveur DHCP PfSense (c'est le DHCP PfSense qui adresse mon GUEST). -
Quelques points qu'il convient de clarifier :
- DHCP n'a aucun rapport avec le proxy si ce n'est qu'il peut être utilisé dans le cadre de WPAD, mais dans ce cas ce n'est pas du proxy transparent
- HTTPS ne peut pas être filtré par le proxy en mode transparent sauf à implémenter SSLBump (Man on thé middle) ce qui n'est probablement pas la meilleure idée
À partir de la, il faut se poser la question de est-ce que le mode transparent est le plus approprié si on compare à un mode explicite + WPAD
-
Et tu fais bien de clarifier :)
Je sais que cela n'a pas de rapport mais je me suis dis que peut-être on pouvait rediriger ce réseau délivré par DHCP vers le proxy, mais non. Je cherchais juste si une option existait.
Je pensais qu'il était plus simple de rediriger le HTTPs vers le proxy mais après réflexion, oui tu as raison.
Je ne connais pas SSLBump mais tu dis que ce n'est pas la meilleure idée donc je vais plutôt m'attarder sur ta seconde idée.
De plus, je ne pourrais pas pousser de certificats sur les clients que je ne contrôle pas. :/WPAD.
Je ne connais pas, d'après une très brève recherche, cela permet d'auto configurer le proxy des clients ?Si tu peux m'en dire plus, je t'en serais reconnaissant.
Merci pour le temps que tu m'accordes en tout cas.
Edit : WPAD va fonctionner si les navigateurs des clients sont paramétrés pour détecter automatiquement la configuration proxy.
Mais si ce n'est pas le cas ? Je ne peux pas forcer la configuration des clients, il faut donc que je trouve une solution qui force le traffic à passer par mon proxy sans avoir besoin d'une configuration spécifique du client. -
WPAD n'est effectivement pas la solution miracle mais probablement la meilleure malgré tout. La plupart des browser va être en détection automatique. En revanche, pour les machines Android, ce n'est pas gagné.
SSLBump est une option qui permet à Squid, si celui-ci utilise côté client un certificat connu de la trust liste du browser, de s'intercaler dans le flux HTTPS en cassant celui-ci pour se comporter comme un client HTTPS vis à vis du serveur tout en encryptant dans un deuxième tunnel le flux vers le client. Au milieu, donc au niveau du protocole, ça passe en clair, ce qui permet de filtrer (c'est bien) mais également de récupérer le mot de passe et le compte en banque de celui qui se connecté à sa banque en ligne… No comments
-
Pour qu'un déploiement de proxy transparent avec SSLBump soit éventuellement acceptable, il faut que:
- l'utilisateur en soit informé
- l'infrastructure qui supporte ce proxy soit extrêmement bien protégée, y compris au niveau des process d'administration
-
Oui, entièrement d'accord.
Pour résumé, plusieurs solutions s'offrent à moi :
Bloquer entièrement le flux HTTPS du GUEST.
Rediriger le HTTP du GUEST vers mon proxy (avec le port forward du PfSense) et donc configurer mon Squid en mode transparent.
Problème : Bloquer le HTTPS revient à interdire de nombreux sites.Paramétrer WPAD pour que la configuration proxy des clients de mon GUEST se fasse avec les paramètres de mon squid explicite.
Problème : Tous les clients ne se configureront pas avec WPAD dû à la configuration de leur navigateur.Rediriger le HTTP du GUEST vers mon proxy (avec le port forward du PfSense) et donc configurer mon Squid en mode transparent.
Rediriger le HTTPS du GUEST vers mon proxy avec du SSL_Bump.
Problème : Ethique, loi, etc. Solution aucunement viable, ce n'est donc pas une solution.N'existe-il donc pas une 4eme solution qui me permette de faire ça à 100% ou dois-je à tout prix choisir entre les deux premières solutions ?
Merci à toi !
-
Il n'y a pas que des soucis éthiques avec SSLBump : il faut (rien d'insurmontable mais il faut y penser) que le certificat utilisé pour la partie "interne" du flux soit trusté par tous les clients sous peine d'avoir plein de messages de warnings.
Je ne connais pas d'autres solutions mais je ne connais pas non plus le besoin. On discute de proxy parce que tu penses que c'est la bonne solution mais selon le besoin à couvrir, il y a peut-être d'autres options comme des trucs au niveau du DNS, pfblokerng et autres "safe DNS" par exemple
-
Pas faux.
En fait, je n'ai pas parlé de tous les réseaux interconnectés entre eux et de l'architecture complète.
Pour faire simple, mon réseau PEDA passe par mon proxy local (Squid) qui lui forward à un proxy parent (protection des mineurs) sur lequel je n'ai aucun pouvoir.Et là, le réseau GUEST que nous avons mis en place n'est pas du tout filtré (il sort en direct sur notre WAN) et nous devons faire passer ce flux par le proxy de la protection des mineurs (donc par notre proxy local qui redirigera vers le proxy parent).
Donc je ne pense pas me tromper qu'il faut faire passer ça par notre proxy qui est configuré pour renvoyer à son parent ?
Edit : Pour que tous les clients aient confiance en mon certificat il faut que j'achète un certificat à une autorité de confiance. Ou alors que je pousse mon autorité sur les clients mais ce n'est pas possible que je n'ai pas la main sur les clients.
Ce sont des externes, qui se connectent avec leur propre poste. -
Oui ça semble faire du sens, comme le disent nos voisins britons.
Ou alors envoyer directement au proxy parent si le passage par le proxy intermédiaire n'a pas d'utilité réelle.Ça vaut probablement le coup de regarder plus en détail pourquoi le mode transparent ne fonctionne pas comme escompté.
-
Ok donc, ce serait du transparent pour le HTTP mais pas pour le HTTPS (donc soit bloqué soit pas filtré).
Aurais-tu une piste pour la configuration de Squid en mode transparent sur CentOs 7 ?
J'ai trouvé quelques guides qui ne disent pas la même chose et que je n'arrive pas à appliquer. -
Ok donc, ce serait du transparent pour le HTTP mais pas pour le HTTPS (donc soit bloqué soit pas filtré).
Effectivement, en mode transparent, HTTPS est complètement ignoré (sauf SSLBump)
Aurais-tu une piste pour la configuration de Squid en mode transparent sur CentOs 7 ?
J'ai trouvé quelques guides qui ne disent pas la même chose et que je n'arrive pas à appliquer.A mon avis, ce n'est pas une version "CentOS" qu'il faut regarder mais la doc de Squid en fonction de la version que tu as déployé
http://wiki.squid-cache.org/
http://wiki.squid-cache.org/SquidFaq/InterceptionProxy -
Hello !
Une autre question, afin d'être sûr.
Peut-on, à partir du PfSense, gérer un fichier pac, WPAD, pour auto configurer les clients du GUEST ? -
C'était possible jusqu'en 2.2.x car il y avait un support d'un plugin de type vhost pour exposer le proxy.pac mais celui-ci n'est plus je crois, supporté
Par contre, DHCP et DNS de pfSense peuvent bien sûr pousser les infos nécessaires -
Ah ? C'est exactement ce que je cherchais quand j'ai été voir le DHCP et DNS de PfSense.
Mais je n'ai pas vu ces options ?Pour rappel mon PfSense est en 2.2.6
Edit : Ok, après plusieurs heures je trouve ce que je cherche :)
Je devrais donc créer trois fichiers .pac .da .dat pour plus de supports auprès des navigateurs.
Ajouter ces fichiers dans /usr/local/www de mon PfSense. (/usr/local/www/proxy.pac …wpad.da ...wpad.dat).
Paramétrer des options 252 dans mon DHCP Server PfSense de mon GUEST.
Paramétrer un override dans mon DNS.
Par contre je n'ai pas compris le principe du "mime-type" ?Me trompe-je dans quelque chose ? Les chemins ou autre ?
Merci
-
Ah mince, WPAD doit être mis en place sur mon PfSense ou sur mon proxy Squid ?