Pfsense1 proxy & Pfsense2 Portail captif
-
Bonjour,
Je ne parviens pas à paramétrer NAT+Proxy ou SNAT. J'ai donc besoin de votre aide.
Schéma fonctionnel
Internet -> Pfsense1 (FW1+Proxy 8080+Filtage) 10.10.0.1 -> LAN de l'école (50PCs en 10.10.0.0/16+navigateur paramétré sur le proxy 10.10.0.1 port 8080) + serveur AD.
LAN de l'école ->10.10.0.2 Pfsense2(FW2=80-443+Portail captif+Identification via AD) -> WIFI (Portables en 172.16.0.0/16 +navigateur sans paramètre proxy)
Proxy=Squid, Filtrage=SquidGuard
Situation actuelle
Tout fonctionne correctement pour les PCs qui accèdent à l'internet via le proxy.
Tout fonctionne pour les portables car les ports 80 et 443 du FW1 sont ouverts.Ma mission est de fermer les ports 80 et 443 du FW1 et obliger le flux du Pfsense2 à passer par le proxy du Pfsense1.
Donc :
Je voudrais que le Pfsense2 modifie les paquets sortant comme un navigateur paramétré en proxy 10.10.0.1:8080
(Source=Lan Source:; Destination=:80;Redirige=:8080;Nat+proxy 10.10.0.1)
(Source=Lan Source:; Destination=:443;Redirige=:8080;Nat+proxy 10.10.0.1)
mais je n'arrive pas à le mettre en fonctionnement; (Il y a bien la passerelle sur Pfsense2 en 10.10.0.1);
ou "au pire"
que le Pfsense1 redirige le flux entrant venant de 10.10.0.2 vers son service proxy
(Source=10.10.0.2:; Destination=:80;Redirige=10.10.0.1:8080)
(Source=10.10.0.2:; Destination=:443;Redirige=10.10.0.1:8080)
mais cela ne fonctionnement pas.Merci pour votre aide
Marcel -
Je ne sais pas comment cela est configuré. Mais plusieurs observations.
Le proxy sur Pfsense vu le nombre probable d’utilisateurs est une mauvaise idée. Ceci pour deux raisons. Un problème de fonctionnement de la partie proxy est susceptible d'affecter votre firewall. Ce qui est critique. Le principe de défense en profondeur n'est pas respecté, en particulier l'indépendance des moyens de défense.
Bref l'architecture n'est pas la bonne.
De plus, s'agissant de l'architecture, dans votre schéma vous avez, sur le même réseau, des flux avec des niveaux de confiance totalement différent. De fait votre réseau filaire est accessible depuis le réseau wifi. Ce qui n'est pas sain.Enfin il faut prendre en compte le fait que tout le trafic venant du réseau 172.16.0.0 est translaté en 10.10.0.2 puisque cette interface Pfsense possède une valeur dans Upstream Gateway. Je ne sais pas si vous en avez tenu compte.
-
Merci pour vos observations pertinentes.
Mais je ne comprends pas tout !Je précise en indiquant qu'il a deux proxies dans cette infrastructure.
"Un problème de fonctionnement de la partie proxy"
D'accord, mais il faut bien contrôler tout le flux 80 et 443. Je ne connais que la redondance avec un autre Pfsense en //."Le principe de défense en profondeur"
Je ne connais pas le système de défense de pfsense. Que faire ?"L'architecture n'est pas bonne"
Est ce que cette solution serait plus adaptée ?
Internet-> pfsense1(fw)->pfsense2(proxy+filtrage)->LAN->pfsense3(portail captif)->WIFI
Soit trois Pfsense différents ?
Dans ce cas le problème reste entier.Merci par avance
Marcel -
@marcel6566yahoo-fr said in Pfsense1 proxy & Pfsense2 Portail captif:
"Le principe de défense en profondeur"
Je ne connais pas le système de défense de pfsense. Que faire ?Ce concept n'est pas lié à Pfsense ni à aucun autre firewall ou produit de sécurité. C'est ... un concept général. Quelques précisions plus tard.
-
A maintes et maintes fois, nous avons écrit que le proxy DOIT être séparé du firewall, en particulier quand le trafic et le nombre d'utilisateurs est important. C'est nettement le cas ici, Si vous aviez déjà cherché sur le forum ...
De plus, pour pfSense, le proxy est un package et ne fait donc pas partie du firewall en tant que tel. L'avantage que ce ce soit un package est que l'interface de paramétrage (= qui génère le fichier de conf) suit l'interface générale.
Donc il est à conseiller de créer votre propre proxy à part.
Par exemple, en partant d'une Debian Stretch et en ajoutant Squid, SquidGuard, Apache2, LightSquid.
En sus, intéressez vous à WPAD, il y a sur le forum un fil qui explique assez complètement ce protocole ... -
Ta cible ne va pas fonctionner à cause des smartphones qui le plus souvent ne supportent pas de proxy explicite. Il faut donc un proxy transparent, ce qui fonctionne pour HTTP mais pas pour HTTPS sauf à activer SSL-Bump (SSL inspection), ce qui nécessite de prendre des précautions très particulières d'information des utilisateurs.
De plus, HSTS va rendre les choses difficiles.Bref, WPAD ou pas
dès lors que tu veux donner un accès internet aux smartphones (ou n'importe quelle machine Androïd) ça devient compliqué d'un point de vue proxy.A noter que Windows 10 pose quelques difficultés également et va en poser de plus en plus avec l'extension des services autour de O365.
-
Bonsoir
Merci pour vos réponses.@jdh said in Pfsense1 proxy & Pfsense2 Portail captif:
le proxy DOIT être séparé du firewall
Je vais séparer le FW du Proxy
@jdh said in Pfsense1 proxy & Pfsense2 Portail captif:
Debian Stretch et en ajoutant Squid, SquidGuard, Apache2, LightSquid.
Je vais monter une Debian Stretch (Proxy + Filtre + ServWeb + Journal)
@jdh said in Pfsense1 proxy & Pfsense2 Portail captif:
intéressez vous à WPAD
Je vois pour mettre en place WPAD sur le dernier pfsense2 afin de livrer les paramètres proxy aux portables.
@chris4916 said in Pfsense1 proxy & Pfsense2 Portail captif:
Ta cible ne va pas fonctionner à cause des smartphones
Actuellement les smartphones ne sont pas autorisés. Cela règle le problème.
Est ce que cette solution serait plus adaptée ?
Internet-> pfsense1(fw)->Debian(proxy+filtrage+ServWeb+Journal)->LAN->pfsense2(portail captif + WPAD)->WIFI
Je vais maquetter tout cela avant de mettre en production.
Je vous laisse un message dès que j'ai terminé.Merci beaucoup pour votre aide.
Marcel -
Si tu n'as pas de machines Android, c'est plus simple.
Pour WPAD, lorsque tu dis que tu vas le mettre en place "sur le dernier pfSense", prend en compte les aspects suivants:- WPAD n'est que la méthode normalisée pour diffusée l'information de où se trouve le fichier proxy.pac. Mais il faut que ce fichier proxy.pac soit disponible sur un serveur web, et donc pas (plus) pfSense. Le webserver que tu évoques par ailleurs devrai faire l'affaire.
- il faut ensuite que ton DNS et ton serveur DHCP diffusent des infos conformes à WPAD.
Je ne comprends pas ta description FW1 -> proxy -> LAN -> FW2 -> WIFI et j'ai l'impression par ailleurs que le deuxième pfSense ne te sert que de support au portail captif.
Pourquoi ne pas mettre le proxy dans une DMZ qui serait accessible à la fois depuis le LAN et depuis le segment réseau "wifi" (si c'est le design que tu as retenu) en mettant un portail captif sur l'interface qui dessert le wifi.C'est réalisable avec un FW à 4 interfaces physiques ou un FW à 3 interfaces, avec le wifi sur un VLAN de l'interface physique qui supporte le LAN.
Un deuxième pfSense ne te sert ici pas à grand chose, si je comprends bien.
-
Dans ce schéma, tel que nous le comprenons, le second firewall n'a pas d'utilité puisque le flux qui transite va finalement arriver dans le réseau "Lan de l'école". C'est évidement à proscrire. L'architecture en étoile, avec un firewall et 4 interfaces réseau, est bien meilleure. Toutefois je ne sais pas dire si elle répond aux besoins de sécurité. Comme celui-ci n'est pas connu, je ne sais pas répondre.
Internet-> pfsense1(fw)->Debian(proxy+filtrage+ServWeb+Journal)->LAN->pfsense2(portail captif + WPAD)->WIFI
Cette solution n'est donc pas pertinente. Plutôt que Pfsense 2, une interface physique (idéalement) sur Pfsense 1 est nettement préférable pour recevoir le trafic du réseau Wifi. Le proxy étant placé dans un réseau distinct (dmz) des autres.
-
Il est clair, qu'un schéma avec 1 seul firewall (et avec suffisamment d'interfaces) est bien meilleur.
Concernant WPAD, il est clair que le proxy dédié est capable de fournir le fichier attendu. Mes proxy sont ainsi configurés : un fichier de conf à modifier, plus le fichier proxy.pac. C'est ainsi que je procède. De plus fiez vous plutôt au fil qui décrit complètement le sujet (facile à trouver sur le forum) qu'à un résumé de 3 phrases (qui ne peut qu'embrouiller puisque pas assez de substance !).
Toutefois, vous aurez besoin d'un proxy par interface ! Si vous utilisiez pour des visiteurs, le proxy de vos utilisateurs du LAN, les premiers auront accès aux serveurs internes !
-
@jdh said in Pfsense1 proxy & Pfsense2 Portail captif:
Toutefois, vous aurez besoin d'un proxy par interface ! Si vous utilisiez pour des visiteurs, le proxy de vos utilisateurs du LAN, les premiers auront accès aux serveurs internes !
Pourquoi ???
Un proxy en DMZ peut sans aucun problème être partagé par différents subnets et sans que les machines de ces subnets soient capables de communiquer entre elles.
Et même si tu décidais de connecter ce proxy sur le LAN au lieu d'une DMZ (ce qui n'est pas le meilleur choix de design, j'en conviens volontiers), les règles de FW permettent très simplement de n'autoriser l'accès à ce serveur que sur le port d'écoute du proxy, ce qui limite quand même fortement les risques.Mais bon, si tu as l'habitude de déployer un proxy par interface, c'est probablement que c'est le meilleur choix de design
ça doit faire quand même pas mal de machine lorsque le réseau comment à s'étoffer un peu avec des VLAN dans tous les sens non ? -
Bonsoir et merci pour toutes ces réponses.
@chris4916 said in Pfsense1 proxy & Pfsense2 Portail captif:
Mais bon, si tu as l'habitude de déployer un proxy par interface, c'est probablement que c'est le meilleur choix de design
ça doit faire quand même pas mal de machine lorsque le réseau comment à s'étoffer un peu avec des VLAN dans tous les sens non ?Pas de soucis pour le nombre de machines. Elles sont virtualisées sur proxmox.
@ccnet said in Pfsense1 proxy & Pfsense2 Portail captif:
L'architecture en étoile, avec un firewall et 4 interfaces réseau, est bien meilleure.
Cela me dérange pas de mettre 4 interfaces. Au contraire.
En DMZ, je vais monter un Debian avec le proxy et Apache. Comme je suis un peu court en temps je verrais WPAD après. J'indiquerez aux utilisateurs des portables de mettre le proxy.@chris4916 said in Pfsense1 proxy & Pfsense2 Portail captif:
Un proxy en DMZ peut sans aucun problème être partagé par différents subnets et sans que les machines de ces subnets soient capables de communiquer entre elles.
Ok, mais il faut que je teste les règles de FW de la zone Wifi. A première vue elles seront identiques à celle du LAN à la différence du nom de l'interface.
La semaine prochaine je finirais le maquettage.
Super votre solution et merci pour votre aide.
Je vous tiens informer de mes avancements.
Cordialement et bonnes fêtes de fin d'année.Marcel
-
@marcel6566yahoo-fr said in Pfsense1 proxy & Pfsense2 Portail captif:
Ok, mais il faut que je teste les règles de FW de la zone Wifi. A première vue elles seront identiques à celle du LAN à la différence du nom de l'interface.
Il y a une petite différence, si on s'en tient aux règles "par défaut": lorsque tu installes pfSense, par défaut depuis le LAN, tu as un accès à internet via le WAN alors que les autres nouvelles interfaces que tu vas créer n'ont, par défaut, pas d'accès.
Pour le reste, les règles devraient être en effet assez similaires entre les réseaux LAN et Wifi puisque, si je comprends bien, seul l'accès au proxy en DMZ sera autorisé (en tous cas en ce qui concerne le flux HTTP.
Garde en tête qu'il faut autoriser du flux HTTPS qui ne passera pas par le proxy en mode explicite.
Quid des autres services tels que le mail par exemple ? -
Comme je suis un peu court en temps je verrais WPAD après.
Dans une entreprise de mon groupe, j'ai mis moins de 15' pour le faire !
Les étapes, en suivant le fil que j'ai indiqué, :- paramétrage du DC (serveur DNS et DHCP du LAN)
- options 252 du DHCP
- définition de wpad.domaine dans le DNS (+ ajustement de la globalquerylist because serveur Windows)
- ajustement des mime-type du serveur Apache + restart
- création du fichier proxy.pac (et de ses répliques wpad.dat .da)
(Le serveur proxy ayant besoin d'Apache fournira le proxy.pac, et s'appelera wpad.domaine.)
Testez et au besoin, suivez le conseil de Juve en utilisant autoprox.exeBien évidemment, proxy explicite ou par WPAD, le trafic http et https est traité !
-
Bonsoir et meilleurs voeux pour cette nouvelle année.
J'ai bien avancé sur le prototypage et j'ai encore besoin de vous lumières.Actuellement ma maquette est un Pfsense trois pattes (WAN - LAN 10.10.0.1/16 - DMZ 172.17.0.1/16)
J'ai monté mon debian proxy en 172.17.0.2 sur la patte DMZ. Squid sur le port 8080.
Ma machine teste en 10.10.0.2 a pour gw 10.10.0.1 et les paramètres proxy 10.10.0.1:8080 et l'accès à Internet fonctionne.Le parefeu est configuré ainsi.
NAT Port Forward sur LAN
TCP/UDP - Source LAN net - Destination :8080 - NAT IP 172.17.0.2:8080FW LAN
IPv4 - UDP - Destination :53
Ipv4 - TCP/UDP - Source LAN net - Destination :8080
Tout bloquéFW DMZ
IPv4 - UDP - Destination :53
Ipv4 - TCP/UDP - Destination DMZ net:8080 (autorise la redirection)
Ipv4 - TCP - Source DMZ net - Destination :80 (Proxy vers Internet)
Ipv4 - TCP - Source DMZ net - Destination :443 (Proxy vers Internet)
Ipv4 - TCP - Source :80 - Destination DMZ net (Internet vers Proxy)
Ipv4 - TCP - Source :443 - Destination DMZ net (Internet vers Proxy)
Tout bloquéQue pensez-vous de mes règles. Puis-je optimiser ? Que manque-t-il ?
@chris4916 said in Pfsense1 proxy & Pfsense2 Portail captif:
Il y a une petite différence, si on s'en tient aux règles "par défaut": lorsque tu installes pfSense, par défaut depuis le LAN, tu as un accès à internet via le WAN alors que les autres nouvelles interfaces que tu vas créer n'ont, par défaut, pas d'accès.
Je n'ai rien configuré de tel. Ca fonctionne tout de même ?
@chris4916 said in Pfsense1 proxy & Pfsense2 Portail captif:
Garde en tête qu'il faut autoriser du flux HTTPS qui ne passera pas par le proxy en mode explicite.
Je coince un peu. Pour moi lors d'une requête d'un navigateur le paquet est envoyé au proxy:port proxy. Le domaine:443 est dans l'entête, le proxy peut donc l'analyser ! Après ce n'est qu'un échange en tcp ?
J'attaque demain la partie wifi.
Encore merci.
Marcel -
pourquoi tu ne configures juste pas le proxy à son adresse IP réelle sur ton navigateur ?
Quel est l'intérêt de faire croire au navigateur que le proxy est en 10.10.0.1 pour ensuite faire un forward/NAT depuis pfSense ?Si le proxy en est 172.17.0.1, configure celui-ci au niveau du navigateur.
Autorise depuis le LAN un accès à cete IP sur le prot du proxy uniquement et comme la DMZ est accessible via la default gateway des postes clients, ça fonctionne.
Ensuite, en ce qui concern tes règle de FW, il n'y a normalement pas de session initié depuis internet vers le proxy. donc pas de flux entrant. -
@chris4916 said in Pfsense1 proxy & Pfsense2 Portail captif:
Quel est l'intérêt de faire croire au navigateur que le proxy est en 10.10.0.1 pour ensuite faire un forward/NAT depuis pfSense ?
D'autant que l'exploitabilité des logs du proxy va être dégradée.