Erreur DNS PfSense transparent

Informatiteub

Bonjour.

Je tente d'installer un proxy avec squid et squidguard pour filtrer la navigation internet dans mon entreprise.

J'ai installé PfSense 2.4.2-RELEASE-p1 en mode transparent avec interception https et SSL.

J'ai créé une autorité de certification et généré un certificat que j'ai installé sur mon poste client test.

Ce poste est sous Windows 7 Pro x64.

J'ai mis l'adresse de PfSense comme passerelle par défaut.

Le filtrage Web est OK. Je navigue sur certaines pages. Par contre lorsque je veux accèder à www.google.fr, www.yahoo.fr ou login.microsoftonline.com par exemple j'ai un message d'erreur:
Le serveur DNS a retourné: Name error: the domain name does not exist.

Le ping ok est ainsi que le tracert vers ces sites.

Il semblerait que dès que je veux accéder sur une page en https ca ne fonctionne plus.

J'ai testé d'ajouter des règles dans le firewall pour forcer l'autorisation du https sans succès.

Je n'ai pas activé le DNS Forwarder mais le résolveur DNS oui.

Donc si vous avez des pistes je suis preneur car je me casse les dents depuis quelques temps sur ce problème.

Merki.

ccnet

J'ai installé PfSense 2.4.2-RELEASE-p1 en mode transparent avec interception https et SSL.

J'imagine qu'il faut comprendre que vous avez ajouté le package Squid sur Pfsense et que vous l'avez configuré en mode transparent.

Ce faisant vous contrevenez à plusieurs dispositions légales dont je ne suis pas certain que vous en ayez pris la mesure.
Il est bien clair que nous parlons d'interception SSL pour du trafic sortant, ce qui est un cas fort différent de celui du trafic entrant sur une infrastructure via un reverse proxy.
La loi informatique et liberté, tout le RGPD applicable en Mai 2018, pose un certain nombre de principes notamment ceux de :
1. Licéité, loyauté, transparence
2. Intégrité et confidentialité
Ceux ne sont pas les seuls mais vous y contrevenez de façon évidente si vous n'avez pas informé de façon très formelle les utilisateurs (Loi I et L Art 32 a minima) puisque lors de l'utilisation de SSL des utilisateurs vont se connecter à des sites en fournissant des informations à caractère personnel. Il faut de très bonnes raisons (contexte SD par exemple) pour justifier la mise en œuvre de ce type de solution. Information formelle signifie charte informatique signée, approuvée par les instances représentatives et déposée au greffe du conseil des prud'hommes et à l'inspection du travail.

Ensuite il a été jugé (Cass sociale 02/10/2001 et c'est loin d'être le seul arrêt) que le salarié, même fautif dans l'usage du SI, avait droit au respect de la vie privée (Code civil art 9).

Si il vous était nécessaire de déployer un tel système, dans l'éventualité de poursuites (l'entreprise contre un salarié), vous devriez apporter la preuve des faits pour lesquels vous poursuivez. Or vous avez choisi le proxy transparent donc aucune authentification des utilisateurs ni imputabilité possible. Le mode transparent est un mauvais choix.

C'est encore un mauvais choix pour la responsabilité civile et pénale de votre employeur. En effet la jurisprudence impose aux entreprises (et autres) mettant à disposition un accès internet l'obligation d'être en mesure de fournir des logs de connexion à la demande d'une autorité judiciaire (et seulement) sur une période d'un an glissant. A défaut c'est la responsabilité (civile et pénale) du représentant légal de l'organisation qui sera engagée. Tout cela en garantissant par ailleurs les principes et loi évoquées plus haut.

Je passe sur toutes les autres références juridiques (Code des télécom, code pénl, droit au secret des correspondances, …) qui rendent elles aussi caduque votre vision de la situation.

Techniquement je ne suis même pas certain que SSLBump soir en mesure d'intercepter le flux https dès lors que la PFS est utilisé dans la suite cryptographique négociée.

D'un point de vue organisationnel comment avez vous mis en place la sécurisation de l'autorité de certification interne (et de son biclé) que vous avez créé ? En cas de problème vous aurez des comptes à rendre sur ce sujet.

SSL Bump est abandonné depuis Squid 3.5.
Https n'est pas supporté en mode transparent.

Précisions enfin que l'interception de trafic entrant est un tout autre sujet.

Informatiteub

Merci pour toutes ces informations dont j'étais au courant.
Je te à souligner que ce proxy n'est qu'en phase de test et uniquement un seul poste test n'est impacté.

A vrai dire j'ai choisi le mode transparent pensant qu'il répondrait à mes besoins.
Je voudrais être certain que toutes les navigations internet passeraient par le filtrage SquidGuard quelque soit l'explorateur utilisé. Je pourrait déployé le paramètre de proxy via GPO mais je ne peux pas être certain que les utilisateurs ne se serviront pas de Firefox ou autre.

Connaissez vous un mode ou fonctionnalité qui tout en étant légale m'assure un filtrage complet des flux?

jdh

A partir d'un certain volume (vous voyez), la config à recommander est

un proxy dédié (et séparé du firewall),
la méthode WPAD implantée.

Cela a plusieurs avantages connus :

moindre charge sur le firewall
machine dédiée ajustable en terme de ressources
machine ajustée en termes de fonctionnalités : rotation des logs, visu des logs, authentification si besoin, …
Bien évidemment, l'inconvénient majeur est connu :
c'est à soi de faire !

Je ne reviens pas sur l'aspect légal clairement décrit par ccnet (à très juste titre).
Je préconise de bien prendre en compte cet aspect, dont certains passent par dessus ...

L'aspect 'transparent' est une fausse bonne idée

ça ne fonctionne que sur http et non https,
il est impossible d'authentifier.

L'aspect 'je casse https' est évidemment mauvais comme exposé (doctement) par ccnet.
En sus, avec HSTS, cela ne devrait même être impossible ...

ccnet

@Informatiteub:

Merci pour toutes ces informations dont j'étais au courant.

Comme dirait le sergent Hartman : Tu ne m'a pas convaincu !

jdh

WPAD est un protocole précis et reconnu par les navigateurs : IE, EDGE et Chrome l'utilise 'out of the box', pour Firefox, il faut cocher une option qui n'est pas par défaut.
Si au niveau du firewall, on n'autorise SEULEMENT le proxy à avoir accès à Internet (http, https), forcément il faudra que les navigateurs trouvent le proxy.
Néanmoins de (très) nombreux programmes ont une option de 'mise à jour' et recherche sur Internet : rares sont ceux qui savent trouver le proxy !

Ccnet ou moi vous avons expliqué les problèmes inhérents aux proxies et firewall.
A de multiples reprises sur le forum cela est écrit, réécrit, (et vous avez même un contributeur qui tient des discours variés, alternant le oui et le non).

Commencez donc par lire …