Squid + Portail Captif + WPAD

gilgil

Contexte : milieu pro (il s'agit d'un centre de formation), niveau expertise de l'administrateur sur pfsense/firewalling : moyen, age de la solution firewall : nouveau

Besoin : Pouvoir loguer et sécuriser l'activité sur le réseau de la formation

WAN : une box classique

LAN : 2 lan, un employé, un formation

3 pattes pfsense : WAN, EMPLOYES, FORMATION

DMZ : pas de DMZ, je n'ai que 3 cartes sur la machine

WIFI : le wifi est présent sur la patte FORMATION

Les formés et intervenants se connectent au Wifi sur la patte FORMATION, pfsense leur fournit la configuration et l'accès..

Question : Comment faire tout ça ?

Pistes imaginées et tests

J'ai imaginé mettre un portail Captif relié à un serveur Radius pour l'authentification des formés et pour bénéficier des vouchers pour les intervenants.
Ça fonctionne sans soucis.
J'ai imaginé utiliser un proxy squid externe pour logguer l'activité http et https, pour cela j'ai mis en place WPAD et c'est la que ça coince.

Ce qui coince c'est surtout les nœuds que je me fais dans la tête et c'est pour cela que je viens demander de l'aide.

Comme je n'ai pas de DMZ, j'ai pensé mettre le proxy sur le réseau FORMATION.
Pfsense a un override DNS pour wpad.reseau.local qui renvoie sur le proxy squid.
Les navigateurs le trouvent et s'auto-configurent sans soucis.
J'autorise dans WPAD l'accès au pfsense sans passer par le proxy, j'arrive sur la page du portail captif, je m'authentifie et je suis renvoyé sur un site externe donc je passe par le proxy et pfsense ne doit plus me reconnaître du coup et me renvoie sur la page d'authentification du portail captif.

Voila le nœud, mes compétences s’arrêtent la.
Je suppose qu'il y a une bonne façon de faire, que je ne trouve pas.

Merci pour vos lumières bienveillantes

chris4916

C'est une forme de DMZ un peu particulière mais qui est tout à fait acceptable dans ton cas: si tu installes le proxy sur le segment entre l'interface WAN de pfSense et ta box, ça devrait le faire non ?

gilgil

Merci chris4916 pour ta réponse,
ça pourrait le faire, je vais tester ça !
Il me semblait qu'en mettant le proxy sur le WAN l'auto-configuration des navigateurs ne pourrait plus se faire directement, ce qui pouvait être gênant : le pfsense renvoie d'abord vers le portail captif, je m'authentifie, et à partir de la les navigateurs doivent trouver la configuration,
mais je vais tester !

chris4916

Sans y avoir vraiment réfléchi dans le détail, je ne vois pas pourquoi ça ne marcherait pas, à condition bien sûr, je ne l'ai pas précisé mais ça me semblait évident, que le segment "externe" soit bien sur un réseau privé.

Ton IP publique s'arrête à l'extérieur de ta box.
Celle-ci fonctionne comme un routeur.
Tu as donc un réseau situé entre l'interface WAN de pfSense et ta box où tu peux installer ton proxy qui reste parfaitement accessible si tu autorises le port 3128 (par exemple) depuis le LAN vers cette "DMZ"

La limite de l'exercice, c'est si tu souhaites configurer l'authentification sur le proxy en t'appuyant sur par exemple, un serveur LDAP qui serait interne.

Mais en dehors de ce genre de chose, mettre le proxy à cet endroit permet un flux "linéaire".

Attention aux capacités de filtre / configuration de ta box :-) => il est fortement souhaitable que ton proxy ne soit pas exposé sur internet. Si ta box ne sait rien faire (et même si elle sait faire des trucs basiques) déployer Squid sur une machine Linux avec par exemple iptables pour un minimum de contrôle n'est pas du gaspillage ;)

gilgil

Merci pour ces précisions,
voici ce que je viens de tester avec proxy sur le WAN :

WPAD sur le pfsense, les navigateurs le trouvent et cherchent le proxy indéfiniment puisqu'ils n'y ont pas accès tant qu'ils ne sont pas authentifiés, et ils ne sont pas redirigés sur le pfsense pour l'authentification … flute
WPAD sur le proxy, les navigateurs arrivent sur le pfsense s'authentifient et partent sur internet sans passer par le proxy ... zut
je bloque le traffic et laisse le 80 et le 3128 sur le proxy pour le wpad et le proxy, mais les navigateurs n'arrivent pas à s'autoconfigurer
je continue à chercher, en tout cas merci

gilgil

Quelques tests/infos supplémentaires :
j'ai ajouté dans le hosts du proxy les entrées wpad.reseau.local et wpad.
Après authentification sur le portail captif si je ferme et réouvre le navigateur, cela fonctionne parfaitement !
Comme s'il fallait lui dire d'aller rechercher le wpad, c'est presque ça …

chris4916

@gilgil:

Quelques tests/infos supplémentaires :
j'ai ajouté dans le hosts du proxy les entrées wpad.reseau.local et wpad.
Après authentification sur le portail captif si je ferme et réouvre le navigateur, cela fonctionne parfaitement !
Comme s'il fallait lui dire d'aller rechercher le wpad, c'est presque ça …

Je ne comprends pas ce que "ajouter dans le host du proxy" signifie mais j'ai l'impression que tu mélanges les aspects proxy (où positionner le proxy dans le réseau pour y accéder sans devoir s'authentifier à nouveau sur le portail captif) et les aspects WPAD qui est uniquement le mécanisme de discovery.

WPAD fonctionne en 2 étapes:

un mécanisme, DHCP ou DNS (1) publie le lien du serveur web qui héberge le fichier proxy.pac (2)
le navigateur accède ce fichier et en déduit l'adresse et le port du proxy ainsi que les conditions d'utilisation

(1)

pour DHCP il s'agit de l'option 252
pour le DNS, il y a 2 mécanismes différents:
=> le "well known alias" qui recherche un CNAME ou A record "WPAD" en fonction du nom de domaine.
=> SLP (Service Location protocol) qui s'appuie sur des records TXT et SVR

(2)
selon le navigateur, le nom du fichier proxy.pac recherché et lu diffère. ça va de proxy.pac à wpad.dat qui sont standardisés et même wpad.da
il faut donc gérer des alias (logical names) sur le serveur web pour maintenir un seul fichier et en exposer plusieurs ;-)

gilgil

Bonjour chris4916 et merci pour ta réponse,
le proxy me faisait un 504 sur un wget http://wpad.reseau.local/wpad.dat jusqu'à ce que je lui dise qui il était, c'est pour cela que j'ai modifié le hosts.

Je pense avoir compris le rôle du proxy et celui du wpad, j'utilise le mécanisme via le DNS, et les alias de proxy.pac sont en place.

As-tu des conseils sur les bonnes pratiques ? fichier d'autoconfiguration sur le pfsense, sur le proxy, sur un tiers ?

Pour l'instant je suis bloqué, les navigateurs arrivent sur le portail captif, je m'authentifie, ensuite le navigateur tourne en rond.
Si je le ferme et le réouvre, il trouve le fichier d'autoconfiguration et je peux accéder au web.
Y-a-t-il un moyen d'éviter ce re lancement du navigateur ?
Merci encore

chris4916

Ne prends pas ma proposition comme un conseil mais plutôt comme une piste de réflexion ou de recherche car je n'ai pas réfléchi dans le détail (là où le diable se cache ;)) à tous les points.
La manière dont j'appréhende ta problématique, c'est de dire:

il faut éviter de boucler entre le portail captif (c'est du web) et le proxy et donc sérialiser ces composants
le serveur web exposant WPAD devrait être sur le LAN sans quoi il ne serait pas accessible tant que l’authentification sur le portail ne serait pas faite
le fichier proxy.pac (wpad.dat) devrait contenir des exception (no proxy) pour les serveur locaux, y compris l'interface interne de pfSense qui expose le portail captif.

Donc sur cette base, ma tentative de design serait:

1 - sur le LAN un serveur WEB exposant le proxy.pac, lequel décrit explicitement "pas de proxy pour *.reseau.local"
2 - le portail captif sur pfSense (c'est beaucoup plus simple
3 - le proxy sur le segment externe (WAN) de pfSense

dans ce mode, le navigateur trouve toujours le proxy.pac, sans passer par le proxy.
il accède ensuite le portail captif car la route vers le proxy qui est dans un autre plan d'adressage puisque à l'extérieur, passe par la passerelle par défaut, donc pfSense.
l’authentification sur le portail active les règles qui permettent d'accéder au proxy, lequel fait la requête web.

Vu de loin (j'y réfléchi en même temps que je l'écris), je ne vois pas pourquoi ça ne fonctionnerait pas ;)

chris4916

un point potentiellement important: selon la manière dont tu écris ton proxy.pac, le résultat n'est pas tout le temps celui attendu ;)
la première règle qui match s'applique (comme pour un firewall) et donc si ta première règle décrit l'accès de type PROXY et couvre les machines internes, alors ta règle DIRECT qui suit ne sera jamais appliquée ni utilisée.

jdh

Le fichier 'hosts' n'a pas à être modifié ! (comment le faire facilement pour toutes les machines ?)

Il est important de savoir que le service 'Serveur DNS' d'un serveur Windows refuse de fournir la résolution du nom 'wapd.reseau.local' par défaut (reseau.local étant fourni par défaut par DHCP) ! cf Remove wpad dns block list : https://technet.microsoft.com/en-us/library/cc995158.aspx

Il est important de bien comprendre la différence entre Portail Captif et Proxy :

Portail Captif : permet de traverser un firewall selon une autorisation basé sur un identifiant ou un voucher;
Proxy : service intermédiaire entre client et serveur web permettant à la fois, un cache, un contrôle d'url autorisés (blacklist/whitelist), un stockage des url visitées par machine, et une autorisation basé sur un identifiant;

Il est clair que le Proxy permet d'autoriser ou non la navigation.
Alors que le portail Captif est destiné à ouvrir bien plus de choses : navigation, mail, …
Souvent, le seul accès à la navigation suffit à satisfaire les utilisateurs ... (Proxy)

gilgil

@chris4916:

Donc sur cette base, ma tentative de design serait:

1 - sur le LAN un serveur WEB exposant le proxy.pac, lequel décrit explicitement "pas de proxy pour *.reseau.local"
2 - le portail captif sur pfSense (c'est beaucoup plus simple
3 - le proxy sur le segment externe (WAN) de pfSense

ok, ça me parait logique aussi,
je viens de mettre le proxy.pac sur le LAN, voici son contenu :


function FindProxyForURL(url,host)
{

if (isPlainHostName(host) ||
    shExpMatch(host, "*.lan") ||
    isInNet(dnsResolve(host), "192.168.0.0",  "255.255.0.0") ||
    isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))
    return "DIRECT";

return "PROXY 192.168.1.11:3128";
}

le navigateur récupère bien le fichier proxy.pac et se tourne vers le proxy mais le pfsense ne l’arrête pas pour l’authentifier sur le portail captif.


18:52:35.839655 IP 192.168.3.21.62436 > 192.168.3.100.53: UDP, length 30
18:52:35.840300 IP 192.168.3.100.53 > 192.168.3.21.62436: UDP, length 46
18:52:35.840613 IP 192.168.3.21.55879 > 192.168.3.100.80: tcp 0
18:52:35.840744 IP 192.168.3.100.80 > 192.168.3.21.55879: tcp 0
18:52:35.841052 IP 192.168.3.21.55879 > 192.168.3.100.80: tcp 0
18:52:35.841242 IP 192.168.3.21.55879 > 192.168.3.100.80: tcp 333
18:52:35.841355 IP 192.168.3.100.80 > 192.168.3.21.55879: tcp 0
18:52:35.841806 IP 192.168.3.100.80 > 192.168.3.21.55879: tcp 238
18:52:35.841942 IP 192.168.3.21.55879 > 192.168.3.100.80: tcp 0
18:52:35.841944 IP 192.168.3.100.80 > 192.168.3.21.55879: tcp 285
18:52:35.842337 IP 192.168.3.21.55879 > 192.168.3.100.80: tcp 0
18:52:35.888560 IP 192.168.3.21.43572 > 192.168.3.100.53: UDP, length 34
18:52:35.890284 IP 192.168.3.100.53 > 192.168.3.21.43572: UDP, length 309
18:52:35.891611 IP 192.168.3.21.56685 > 192.168.1.11.3128: tcp 0
18:52:36.142653 IP 192.168.3.21.56686 > 192.168.1.11.3128: tcp 0
18:52:36.888135 IP 192.168.3.21.56685 > 192.168.1.11.3128: tcp 0
18:52:37.140117 IP 192.168.3.21.56686 > 192.168.1.11.3128: tcp 0
18:52:38.892010 IP 192.168.3.21.56685 > 192.168.1.11.3128: tcp 0
18:52:39.143965 IP 192.168.3.21.56686 > 192.168.1.11.3128: tcp 0
18:52:40.748616 IP 192.168.3.21.39711 > 192.168.3.100.53: UDP, length 41
18:52:40.749218 IP 192.168.3.100.53 > 192.168.3.21.39711: UDP, length 134
18:52:40.750366 IP 192.168.3.21.56687 > 192.168.1.11.3128: tcp 0
18:52:41.000888 IP 192.168.3.21.56688 > 192.168.1.11.3128: tcp 0
18:52:41.747693 IP 192.168.3.21.56687 > 192.168.1.11.3128: tcp 0
18:52:41.823804 IP 192.168.3.21.16008 > 192.168.3.100.53: UDP, length 44
18:52:41.895985 IP 192.168.3.100.80 > 192.168.3.21.55879: tcp 0
18:52:41.896197 IP 192.168.3.21.55879 > 192.168.3.100.80: tcp 0
18:52:41.896337 IP 192.168.3.100.80 > 192.168.3.21.55879: tcp 0
18:52:41.999826 IP 192.168.3.21.56688 > 192.168.1.11.3128: tcp 0
18:52:42.899683 IP 192.168.3.21.56685 > 192.168.1.11.3128: tcp 0
18:52:43.136230 IP 192.168.3.100.53 > 192.168.3.21.16008: UDP, length 409
18:52:43.137137 IP 192.168.3.21.39704 > 192.168.3.100.53: UDP, length 25
18:52:43.137688 IP 192.168.3.100.53 > 192.168.3.21.39704: UDP, length 41
18:52:43.155574 IP 192.168.3.21.56686 > 192.168.1.11.3128: tcp 0
18:52:43.209933 IP 192.168.3.21.56689 > 192.168.1.11.3128: tcp 0
18:52:43.210195 IP 192.168.3.21.56690 > 192.168.1.11.3128: tcp 0
18:52:43.460635 IP 192.168.3.21.56691 > 192.168.1.11.3128: tcp 0
18:52:43.460690 IP 192.168.3.21.56692 > 192.168.1.11.3128: tcp 0
18:52:43.751622 IP 192.168.3.21.56687 > 192.168.1.11.3128: tcp 0
18:52:44.003519 IP 192.168.3.21.56688 > 192.168.1.11.3128: tcp 0
18:52:44.207509 IP 192.168.3.21.56689 > 192.168.1.11.3128: tcp 0
18:52:44.207545 IP 192.168.3.21.56690 > 192.168.1.11.3128: tcp 0

192.168.3.21 : mon poste test
192.168.3.100 : pfsense qui sert le proxy.pac sur le 80
192.168.1.11 : le proxy sur WAN

Est-ce que le portail captif intercepte sur le 3128 ?

merci à vous 2

jdh

Ii y a beaucoup de choses mais je voudrai revenir à l'essentiel pour bien comprendre les mécanismes et les écueils :

Element : pfSense, une interface avec des invités à contrôler. (pfSense est le DHCP et DNS en service sur l'interface)

Obligation : le stockage des logs de navigation des utilisateurs à qui on fournit Internet est une obligation légale.
=> Seul un proxy (http,https) est capable de réaliser cela => il faut donc 'forcer' le passage par le proxy => mettre en place WPAD et ajouter une règle qui n'autorise que le proxy

Mise en place WPAD :

soit par DNS, soit par DHCP, : DNS plus simple et plus universel
le client doit résoudre wpad.réseau.local (écueil : si DNS Windows bug possible)
la machine 'wpad' doit avoir un serveur web et fournir proxy.pac/wpad.dat (+wpad.da) dument configuré
le PC doit avoir son navigateur dument configuré

Où placer le proxy (http/https i.e. Squid) :

pas sur le firewall : ce n'est pas sa place, et en +, plus aucun problème pour accéder aux autres interfaces !
pas sur le WAN : aucun sens : j'ai un firewall mais je mets une machine devant !
dans une DMZ : semble le mieux, mais il faudra pouvoir y accéder
dans le segment : petit conflit avec portail captif, voir ci-dessous

Rôle du Portail Captif :

le portail autorise ou non la traversée du firewall selon une authentification : base Radius (sur un identifiant Windows), une liste de code, des vouchers
ATTENTION à l'écueil : si WPAD est correct, le trafic passe d'abord par le proxy et traverse le firewall sans passage par le portail captif !
l'intérêt est surtout la traversée multi-protocole : navigation, smtp, … / écueil : pas forcément nécessaire
ATTENTION à l'écueil : l'authentification Portail Captif n'est pas la même que celle de Squid (le proxy) !
astuce : il est (peut-être) possible de passer par le Portail Captif et de rediriger le trafic vers un proxy (méthode de proxy transparent) / écueil : ne fonctionne que pour http !

Rôle du Proxy :

effet cache : écueil : bien ajuster la taille du cache et la mémoire !
authentification possible : écueil : pas identique à portail captif
stockage des logs : c'est le but / écueil : difficile de rapprocher avec l'authentification du Portail
filtrage url : blacklist / à faire évidemment

Attention à limiter l'accès aux autres interfaces du firewall
...

gilgil

@jdh:

ATTENTION à l'écueil : si WPAD est correct, le trafic passe d'abord par le proxy et traverse le firewall sans passage par le portail captif !

arg, c'est peut être la ou ça coince, flûte !
Mon navigateur interroge le proxy mais comme je ne suis pas authentifié, pfsense interdit le traffic vers le proxy mais ne redirige pas vers le portail captif, ce qui parait logique …

euh, je mets mon proxy sur le 80 ?

gilgil

pffff, ça marche avec squid sur le 80…
Merci beaucoup pour votre aide !

chris4916

@gilgil:

Est-ce que le portail captif intercepte sur le 3128 ?

De toute évidence non :-\

A mon avis, le proxy installé, comme je le propose, avec iptables sur une machine entre ton routeur externe et pfSense ne risque pas grand chose car il n'expose basiquement qu'un service (à condition de faire un peu de hardening) et iptables fourni un bon moyen de limiter les accès aux IPs issues du LAN.

Malgré ta limitation qui est de ne pas pouvoir créer de DMZ, il y a peut-être d'autres implémentations possibles avec par exemple des VLAN mais est-ce bien souhaitable ?

Une des difficultés dans ton design, c'est qu'il faut que ce soit l'utilisateur (en fait son IP ou MAC) qui passe par l'interface contrôlée par le portail captif pour accéder au web. Si le proxy est à l'intérieur, ça ne fonctionne pas car en mode explicite, c'est le proxy qui fait la requête.

Techniquement, une des solutions consisterait à mettre un proxy en mode transparent + MITM (pour HTTPS) en série avec pfSense mais c'est juste horrible et je ne suggèrerait jamais ce genre de chose :o :o :o même si ça marche >:(

Une autre approche, à tester et à mettre en œuvre si, comme on l'évoquait au début de ce fil, uniquement si tu es à l'aise avec la surcharge générée par la duplication de la charge réseau sur m'interface LAN de pfSense consisterait à:

1 - créer une deuxième IP dans un autre plan d'adressage (par exemple 192.168.4.0/24) sur l'interface LAN. Je pense que ce n'est toujours pas possible via l'interface graphique mais c'est documenté ici 8)
2 - tu installes et configures ton proxy à une adresse sur ce subnet et change ton DNS ou ton proxy.pac en conséquence.
3 - tu crées une exception sur le portail captif pour autoriser cette adresse IP sans authentification. Dans ma compréhension, un fonctionnement "par zone" du portail n'est ici pas possible car la notion de zone est associée à celle d'interface. Possible avec du VLAN mais pas avec une autre IP

Avec ce design, les utilisateurs passent par le portail captif pour accéder au proxy puisque pfSense est leur gateway et ton proxy est "à l'intérieur" ;-) au prix d'une charge supplémentaire sur l'interface LAN (mais cette charge devrait être faible car limitée par le débit du WAN).

4 - reste que l'accès au proxy ne déclenchera pas de redirection vers le portail captif car fait sur le port 3218 (le proxy sur le port 80 est une solution, mais je ne suis pas certain qu'il n'y ait pas d'effets de bord. Je n'y ai pas trop réfléchi à ce stade. Avec ce nouveau design, si tu mets le proxy.pad sur la machine qui héberge le proxy, l'utilisateur va être intercepté par le portail captif pour accéder au proxy.pac et donc déclencher une règle de la part du portail captif, ce qui va libérer l'accès au port 3128. Effet de bord: à expiration du voucher, l'accès au port 3128 va expirer mais le navigateur risque de ne pas recharger le proxy.pac donc demander à nouveau une authentification au niveau du portail.

mais je n'ai pas beaucoup plus d'idées que ça compte tenu des tes limitations hardware.