Vlan invité + portail captif + proxy
-
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 ?
-
(WPAD) Edit : Ok, après plusieurs heures je trouve ce que je cherche
Mince, dire que quelqu'un s'est donné la peine de créer un fil, sur ce forum, spécifiquement pour WPAD : comment ça fonctionne, ce qu'il faut faire, les bons liens, que, de plus, une bonne âme a ajouté un programme de test et vérification, au cas où on n'arriverait pas à le faire à la main … Désespérant ...
-
Ah mince, WPAD doit être mis en place sur mon PfSense ou sur mon proxy Squid ?
WPAD n'est pas un (1) composant que tu déploies sur une machine mais un ensemble de composants qui, correctement configurés permettent la découverte du proxy.
Il s'agit:
- d'un fichier proxy.pac (avec ses différentes déclinaisons car tous les browsers ne cherchent pas un fichier wpad.dat)
- et donc un serveur web pour supporter le proxy.pac
- de configuration au niveau DHCP et DNS pour communiquer aux clients où trouver ce fichier proxy.pac
à partir de la, tu es libre de t’organiser comme tu le souhaites pour utiliser le serveur web de ton choix dès lors qu'il va supporter les settings (e.g. mime), DNS et DHCP de ton choix.
-
Merci pour toutes ces réponses Chris. Au top !
Je me demandais surtout s'il y avait une bonne pratique de préconisée par rapport à la localisation du serveur WEB ?Jdh, eh oui, désespérant :/
(Le sujet, une fois trouvé, est bien utile cela dit !) -
Si j'ai écrit ce fil sur WPAD, c'était pour rassembler ce qui est nécessaire à la mise en place de WPAD, et démontrer que c'est à la portée de tout admin qui est méthodique et sait suivre des étapes.
Depuis très longtemps, j'écris sur le conseil de séparer le proxy du firewall (dès qu'on dépasse 15 utilisateurs par exemple ou dès qu'il y a un trafic sérieux).
Nécessairement sur ce proxy dédié, on installera par exemple un Apache puisqu'on en aura besoin pour les alertes SquidGuard ou la visu des logs (LightSquid p.e.).
Cet apache sera bien évidemment le lieu privilégié pour installer les fichiers .pac, .dat et .da (ainsi que les mime-type !).Cette dernière question montre d'ailleurs que pfSense n'est pas le lieu idéal, loin s'en faut, : comment définir les mime-type du serveur web de pfSense ?