Problème de proxy

Kassad

J'ai vu le topic traitant du sujet dont les dernières réponses dates d'il y a un an, il me semble que depuis les dernières versions la situation a évoluée (d'après les notes de mises à jour je suis néophyte dans PfSense).

Pour l'aspect de l'architecture je suis loin d'être seul sur ce lien et ne maîtrise pas son architecture de plus PfSense est en test pour l'instant pour au final utiliser son portail captif en plus du firewall je comprend qu'ils ne veuillent pas changer leur architecture pour l'instant.
Ayant lu les différents posts traitant du sujet sur ce forum (en anglais et en français) je m'attendais à cette remarque ;D .

Pour la politique du proxy je suis en contact avec les personnes qui l'ont mis en place et continuent de le gérer je pense et j'espère qu'elles n'ont rien oublié de me dire sur la gestion.
Un test a été fait sur une autre machine, celle-ci en débian, et la configuration du HTTP_PROXY (export HTTP_PROXY=http://<user>:<password>@<ip>:<port>) a permis de se connecter à internet.

Pour l’instant j'ai essayer différentes solutions proposées ici et là avec :

setenv HTTP_PROXY "http://<user>:<password>@<ip>:<port>"

ou

setenv HTTP_PROXY "http://<ip>:<port>"
setenv HTTP_PROXY_AUTH "basic:*:<user>:<password>"

Et cela mis dans /root/.tcshrc car cela ne marchait pas à chaud.

J'ai bien vérifié elles sont bien prises en compte par freeBSD mais je me demande si PfSense n'a pas modifié justement les bases des proxy de freeBSD et imposé ses propres variables.
C'est pourquoi je suis entrain d'essayer de voir (et je n'y arrive pas ;) )ce que modifie dans les fichier de conf la partie Proxy support de l'interface graphique (system=>Advanced=>Miscellaneous).</password></user></port></ip></port></ip></password></user></port></ip></password></user>

Kassad

Toujours personne ?

J'ai pour l’instant négocié pour outrepasser le proxy mais j'aurais aimé avoir une solution à ce problème de plus que PfSense semble équipé d'outil pour.
Même si j'outrepasse le problème pour l'instant je ne désespère pas d'arriver à trouver une solution.

Merci d'avance

Kassad

Je reviens vers vous pour une demande plus spécifique.

En effet pour des raisons évidentes de simplification du réseau nous voulons que les logs et le filtrage d'url de notre portail soit fait pas notre solution commercial.
Je souhaite donc rediriger le flux du portail vers cette machine. J'avais vu et j'ai eu la confirmation suivants plusieurs tuto et postes sur ce forum qu'il faut régler l'option dans le menu System / Advanced puis l'onglet Miscellaneous et remplir les champs de Proxy support.
Sauf que petit problème cette configuration ne fonctionne pas chez nous (j'ai testé sur 3 machines différentes Pf que j'ai installé dont une clean que je venais de faire)

J'ai donc essayer avec squid et son option de chaînage de proxy et celle-ci fonctionne mais nous aimerions ne pas installer squid pour alléger la machine et éviter d'installer des paquets superflus.

Pfsense doit avoir un proxy de base installé mais celui-ci ne semble pas vouloir rediriger correctement sans squid.

Si quelqu'un a déjà eu le soucis ou aurait une solution je suis preneur et si il faut plus d'informations je suis disponible.

ccnet

Pfsense doit avoir un proxy de base installé mais celui-ci ne semble pas vouloir rediriger correctement sans squid.

Non.

Kassad

Merci d'essayer de répondre à la question c'est toujours agréable de recevoir ce genre de réponse ….......

Sinon je pense qu'il y a bien quelqu'un qui utilise cette option et chez qui cela marche nan ? Qu'on soit sure qu'elle fonctionne pas que je me casse la tête sur un truc qui mène à rien

ccnet

En effet pour des raisons évidentes de simplification du réseau nous voulons que les logs et le filtrage d'url de notre portail soit fait pas notre solution commercial.

Fait par ou pas fait ?
Pour le reste votre besoin m'est assez obscure. Et comme vous ne dites rien des reglages du proxy de sortie, on ne sait toujours pas si il faut imputer ou non le problème à Pfsense. Je ne peux donc que vous eviter de vous fourvoyer en pensant que Pfsense comporte nativement un proxy.

jdh

Un pfSense est un firewall avant tout.
Il ne doit donc pas être derrière un proxy mais directement relié à Internet.
(Au besoin, il peut-être derrière un autre firewall avec une règle d'accès total.)

A partir du moment où, pfSense est directement relié à Internet, il n'y a pas lieu de charger des packages via un proxy !

Kassad

Petit retour après quelques temps de galère.

Le réglage dans System / Advanced permet à Pfsense d'avoir accès à internet mais pas aux ordinateurs du LAN, cela permet quand même de pouvoir faire les mises à jours et installer les packages si besoin.

Pour installer un proxy externe sans squid il faut faire une règle de NAT et rediriger le flux http vers ce proxy (qui est sans authentification du coup). De plus si vous voulez enregistrer les logs sur ce proxy il faut faire un outbound pour le réseau LAN sinon il n'y aura qu'une adresse IP source dans vos logs, ce sera Pfsense.

Si cela peut en aider certains.

PS: Vous préconisez toujours de ne pas mettre squid sur Pfsense, mais comment enregistrez vous les logs et faites de politique de filtrage d'url si vous ne mettez pas de proxy externe ?

ccnet

PS: Vous préconisez toujours de ne pas mettre squid sur Pfsense, mais comment enregistrez vous les logs et faites de politique de filtrage d'url si vous ne mettez pas de proxy externe ?

Je ne suis pas certain de comprendre ce que vous appelez un "proxy externe". Externe à Pfsense, au firewall en général, est en effet la solution à adopter. Si par externe vous entendez placé devant le firewall, alors vous faite une erreur d'architecture. Le proxy doit se trouver dans une dmz. Une dmz qui n'accepte aucun trafic entrant et qui ne gère que du trafic sortant. Les trafics entrants doivent être gérés dans une autre dmz. Les utilisateurs accèderont à internet via la proxy, le firewall, ou d'autres machines peuvent éventuellement avoir un accès sans proxy. Exposer le proxy devant le firewall est une erreur. Je vous rappelle que les logs potentiellement présents sur le proxy constituent des données sensibles au sens de la Cnil (protection des données à caractère personnel). Un proxy avec ses utilitaires est très loin d'être un système aussi compact et minimaliste qu'un firewall. Statistiquement le nombre de vulnérabilités présentes est considérablement plus élevé. Je vous laisse aussi imaginer ce qu'il est possible d'obtenir d'un proxy corrompu.

Le proxy a aussi besoin d'être protégé.

Pour installer un proxy externe sans squid il faut faire une règle de NAT et rediriger le flux http vers ce proxy (qui est sans authentification du coup). De plus si vous voulez enregistrer les logs sur ce proxy il faut faire un outbound pour le réseau LAN sinon il n'y aura qu'une adresse IP source dans vos logs, ce sera Pfsense

.

Squid ou pas Squid ne change rien à l'affaire.

Sur l'authentification vous commettez une confusion. En aucun cas, la présence de l'adresse ip de la machine cliente dans les logs d'un proxy, ne constitue une authentification. Au mieux on identifie une machine à un instant t. En aucun cas on authentifie un utilisateur. On authentifie un utilisateur avec un identifiant et un mot de passe (et, ou un certificat par exemple). Authentifier les utilisateurs accédant à internet est aujourd'hui une nécessité juridique. A ce titre l'adresse ip n'offre aucune fiabilité. Pour cette raison le problème du nat outbound ne se pose pas et l'apparition d'une ip unique dans les logs du proxy n'est pas un problème. C'est même presque un avantage (l'ip unique accédant au proxy) puisque l'on peut restreindre l'accès au proxy strictement à l'ip du firewall, donc à un flux que l'on contrôle.

Je comprend bien que votre solution traite le problème tel que vous l'avez posé. Mais une architecture inadaptée conduit à résoudre des problèmes que ne devraient pas se poser, le tout avec un niveau de sécurité bien en deçà de ce que l'on obtient avec une bonne architecture. Dans la mise en œuvre de la sécurité les choix d'architecture sont partie intégrante. Je parle bien de mise en ouvre et non de politique de sécurité ce qui est tout autre chose.

Kassad

Waou

Tout d'abord quand je parle d'externe cela veut dire que ce n'est pas sur la machine de Pfsense cela me semblait logique.
Bien sur que notre proxy est est en dmz, le placement du réseau que va gérer Pfsense ne dépend pas de moi et cela ne représentera qu'une infime partie du réseau totale dont je ne connais pas l'entièreté, je travail suivant des contraintes. Le réseau est protégé et utilisé par un nombre important d'agent et est géré par une équipe d'ingénieurs qualifiés je pense qu'ils savent ce qu'ils font et mêmes si le font mal je n'ai pas le choix et doit faire de mon mieux pour y intégrer ma solution.

Pour l'authentification vous comprenez de travers mais après relecture ma phrase mérite en effet éclaircicement :
Je disais cela car notre proxy demande habituellement une authentification et un profil classique pouvait donc être réalisé si j'utilisais squid qui propose une option upstream proxy avec un identifiant/mot de passe, la solution avec le nat ne permet pas cela et une règle spéciale doit être définie dans notre proxy pour ne pas demander d'authentification pour les adresse IP de mon réseau. Pour faire de l'identification sur le proxy il nous faudrait faire des modifications sur les postes clients ce qui ne peut pas être fait pour nous car les utilisateurs seront des usagers externes dont nous ne maîtrisons pas le matériel.

Par contre la présence de l'adresse IP est indispensable pour faire le recoupement avec les logs de connexion du portail captif mis en place pour pouvoir dire qui a fait quoi et à quel moment comme le nécessite la législation.

Si vous n'aviez pas compris l'architecture décrite dans le premier post qui était primitive et uniquement vraie pour les premiers tests a été dépassée et était aussi fausse au vu des changements opérés dans notre cahier des charges, cela ne me semblait pas important à préciser au vu des questions qui sont plutôt indépendantes de l'architecture.

Mais j'aurais aimé savoir comment vous voyez idéalement l'enregistrement des logs de consultation des usagers vu que j'utilise Pfsense comme portail captif. La présence d'un proxy est surement indispensable maintenant comment le liez-vous à Pfsense sachant qu'il peut être en coupure mais pas directement relié à internet sur sa patte WAN (je ne suis pas le seul sur cet accès) , notre proxy est sécurisé et disponible sur la patte WAN.
Cela m'aidera peut-être à mieux intégrer Pfsense dans mon réseau.

Merci d'avance.