Squid3+Squidguard+ssl filtering -pfsense 2.2.4

danielmuro83

Contexte :

Bonjour,
Je travaille dans une société de service informatique et nous avons une demande de plus en plus présente concernant l’installation de pfsense. Je suis en phase de test des fonctionnalités qui nous intéresses le plus.

Besoin :

Je test donc un pfsense en version 2.2.4 :
Filtrage web (+ssl) avec authentification, Portail captif, IPS, filtrage applicatif, loadbalancing WAN.

Actuellement je suis sur le filtrage web (+ssl) et authentification AD.
Mon problème se situe à ce niveau.

Schéma :

Mon pfsense est une VM installée sur mon poste.

WAN : mon interface wan est une interface relié à mon réseau interne et à comme passerelle mon firewall d’entreprise NETASQ U70S

LAN : Je n'ai qu’une interface Lan, pas de vlan rien d'extraordinaire.

Le pfsense n’a pour le moment aucunes fonctions particulières (dhcp, dns , etc…)

Règles NAT : automatic outbound, aucun autre NAT.

Règles Firewall : Je n’ai pas de règles spécifiques en dehors des règles par default qui autorise le flux en sortie.

Packages ajoutés : squid3, squidguard

Autres fonctions assignées au pfSense : Aucune pour le moment

Question :

J’ai installé Squid3 + SquidGuard = OK
J’ai configuré l’authentification Active directory = OK
J’ai configuré l’analyse du flux HTTPS via « SSL Man In the Middle Filtering » de squid = OK
Certificat généré par pfsense et deployé sur mon poste.

En mode Transparent :
Tout fonctionne bien, le filtrage HTTP et HTTPS, j’ai bien les pages de blocages dans les deux cas.
Le problème, je n’ai pas l’authentification… Mais c’est logique.

En mode non transparent :
Tout fonctionne, le filtrage http et HTTPS, j’ai bien l’authentification, j’ai bien les pages de blocages pour les sites en http bloqués, mais pas pour les sites HTTPS bloqués ou à la place j’ai un warning certificate, qui me dit « le certificat n’est valide que pour https » avec comme erreur « Code d'erreur : ssl_error_bad_cert_domain ».

Cela ne se produit QUE sur les sites HTTPS bloqués dans la liste squidguard, le site est par contre bien bloqué mais au lieu d’avoir le message de blocage classique j’ai ce message d’erreur de certificat.

Lorsque je valide l’exception, j’ai squid qui me dit « Unable to determine IP address from host name https »
Pour un autre site twitter par exemple j’ai juste un message d’erreur de certificat HSTS, pas la possibilité de faire une exception, mais le site est bien bloqué.

Vous pouvez voir ces messages via ces liens :

https://drive.google.com/file/d/0B3cV-uxq7_whSUkyRnhhT3JiTDA/view?usp=sharing
https://drive.google.com/file/d/0B3cV-uxq7_whd3U1ZkQydXZJN3c/view?usp=sharing
https://drive.google.com/file/d/0B3cV-uxq7_whTzlHUFNRckVZT3c/view?usp=sharing

Pourquoi cela se produit-il ? N’y a-t ’il pas moyen de faire en sorte qu’en mode non transparent on puisse afficher la page de blocage pour les sites HTTPS comme pour le mode transparent qui lui marche sans problème ?

Recherches :

Dans les logs Squid pour le mode non transparent (qui pose problème) :
CONNECT fr-fr.facebook.com:443 - HIER_NONE/- -

Dans les logs Squid pour le mode transparent (qui fonctionne bien) :
GET https://fr-fr.facebook.com/ - HIER_DIRECT/192.168.102.90 text/html

Le fait qu’en mode transparent le flux est intercepté celui-ci doit être traité de façon différente ?
Existe-t-il une option à ajouter à squid afin de bypasser ces warnings ?

Quelqu'un a-t'il déjà rencontré ce problème ?

Merci par avance de votre retour et de votre aide.

Cordialement.

jdh

(Voilà un 'newbie' qui respecte le formulaire : c'est bien, continuez …)

Le rôle d'une société de service est de fournir une solution et le 'bon' conseil.
(Car il y a le 'bon' conseil et le 'mauvais' conseil, pareil que pour le chasseur ...)

pfSense n'a rien à voir avec une appliance 'UTM' à la mode.
Sauf à utiliser un pc (ou serveur) surpuissant, il est à déconseiller de mettre sur le firewall le proxy; parce que ce sont 2 taches très différentes (en fonctions et en ressources systèmes) !
Il est à préconiser de mettre un petit matériel comme firewall et un autre matériel comme proxy (d'autant qu'il faut ajouter identification AD).
Je pense qu'il est facile de comprendre que tout ajout sur un firewall est potentiellement source d'insécurité (et d'instabilité).

Concernant le mode Transparent, il est à noter

cela ne fonctionne QUE pour http
cela est contradictoire avec toute authentification.
J'ignore qui vous a envoyé dans cette impasse.
A défaut, je vous encourage à lire comment fonctionne le mode Transparent ...

En fait le mode Transparent n'est pas une si super-idée que ça, bien au contraire ...

'Man in the middle' vous parle-t-il ? voyez vous le rapport avec Transparent ?
Pensez vous qu'une société de service puisse soutenir une solution incorporant du 'Man-in-the-middle' ?

Moi, en tant qu'utilisateur, cela m'inquiéterait qu'au milieu d'une session en mode sécurisé (https), on (=ma société) puisse s'immiscer ! Pas vous ?

danielmuro83

Bonjour,

Merci pour votre réponse.

Je suis d'accord avec vous sur le fait que Pfsense n'est pas ce qui se fait de mieux en UTM.
Néanmoins il a le mérite d'être gratuit (et il est également utilisé dans certains datacenter par des prestataires tel que NBS par exemple).

Actuellement nous vendons essentiellement du Stormshield et du Fortigate, qui fonctionnent très bien soit dit en passant.
Malheureusement certains clients (de plus en plus) viennent en nous demandant la mise en place d'un firewall open source (principalement les très petites structures, qui n'ont pas les moyens d'investir malgré nos conseils dans des solutions payantes).

Après ce qu'il faut savoir c'est que même les UTM plus perfectionnés "stormshield et fortigate" possèdent les fonctionnalités de filtrage web, antivirus, et applicatif voir même antispam (bien que limité).
L’intérêt, étant de mutualiser un maximum les fonctionnalités en un seul boitier, et c'est la direction de plus en plus de constructeurs.

Encore une fois, je suis d’accord avec vous également sur la séparation des rôles, qui me semble en tout point de vue le plus adéquat et sécurisé, mais on en revient toujours au problème de coût.

Concernant la demande client en règle générale, c'est toujours les mêmes requêtes (à 90% du temps):
Ils veulent tous un firewall et effectuer du filtrage web fonctionnel et complet.
Le problème c'est qu'aujourd'hui les sites utilisent de plus en plus le protocole SSL il n'est donc pas possible de les filtrer de façon classique (exemple connu de Facebook).
Chez stormshield et Fortigate (ayant effectué les formations) ils nous montrent que face à cette évolution ils peuvent néanmoins analyser le contenu ssl et donc le filtrer (même si cela demande plus ressources).
A défaut pour Facebook on peut aussi passer par le filtrage applicatif.

Le problème étique est un tout autre problème.
Dans un cadre professionnel bien encadré par des règles, l’utilisateur étant bien évidement informé que tous le flux transitant sur le réseau local peut être amené à être analyser, et l'entreprise en accord avec la loi, que cela me dérange ou non, il s'agit après de la politique de la société.
Après on peut aller plus loin dans ce sens, et mettre en avant le droit à l'exploitation des logs, enregistrement des conversations téléphoniques, etc….
Pour ma part je laisse les entreprises faire leurs choix, mon rôle dans ce cas étant de les informer du cadre de loi.

Pour en revenir au squid en mode transparent, je vous confirme que celui-ci fonctionne très bien avec le "Man in the middle", il intercepte même le flux https et bloque celui-ci correctement lorsque cela est demandé.

Mon problème ne se pose qu'en mode explicite, ou même si les sites HTTPS dans la blacklist sont bloqués (ce qui est demandé), le message de blocage n'apparait pas, j'ai juste une erreur SSL.

Le mode transparent me convient, la seule chose c'est que je ne peux pas utiliser l'authentification (ce qui est logique dans son fonctionnement), donc pour la traçabilité ce n’est pas terrible.

Si quelqu'un a une piste technique la dessus sur l'éventuel moyen de régler le souci :)

Merci encore !

chris4916

Il est évident, pour les raisons que tu décris, que pratiquement tous les fournisseurs de solutions qui embarquent un proxy mettent à disposition une solution de "SSL bumping" même si c'est clairement une entorse au principe de fonctionnement de SSL.

La différence de comportement entre le mode transparent et le mode explicit tient au fait que la commande passée par le client n'est pas la même selon le mode d’utilisation de celui-ci.
En mode explicite, le client passe une commande "CONNECT" toujours en clair avant que le proxy permette l'établissement du tunnel. En mode transparent, il n'y a pas de "CONNECT".

Les messages que tu montres sont liés au fait que le client ne truste pas le certificat utilisé par le proxy. Ce ne sont donc pas des messages d'erreur mais d'avertissement qui peuvent être résolus en installant sur chaque client la clé publique du certificate autority qui a signé le certificat que tu utilises sur le proxy pour le SSL bump (ou en utilisant ici un certificat signé par un CA que le client truste déjà).

La seule erreur qu'il convient, à mon avis, d'investiguer, c'est celle liée à la mauvaise construction de l'URL qui donne lieu qu message Squid:
"https:///https://*"

jdh

Je reprends :

firewall et proxy sont 2 taches bien distinctes (avec des pré-requis bien différents).

Il y a, avec les UTM qui existent depuis des années, 2 mensonges au milieu du discours marketing bien huilé :

mensonge technique : on ne peut faire 'fw' et 'proxy' avec le même matériel
mensonge sécuritaire : le proxy peut faire du 'man-in-the-middle'

On ne peut prétendre apporter de la sécurité en prétendant analyser à l'intérieur d'un flux SSL ! ARNAQUE
Enfin, c'est mon avis, mais les décideurs ne sont pas assez informés …
(Il est clair qu'aucun avant-vente de ce type de matériel ne résisterait 2' dans mon bureau !).
Sans compter qu'il faut valider le certificat de la machine 'Man-in-the-middle' qui remplace le certificat de tous les sites visités !

Il me parait bien plus efficace et plus propre de proposer

un firewall (dédié bien sûr = non virtualisé)
un proxy explicite (tout à fait virtualisable)

La seule contrainte est de prévoir WPAD (avec la config, très légère, de tous les navigateurs).

Sur le proxy, vous aurez tout loisir d'ajouter authentification AD, filtrage blacklist, en http comme https, logs, archivage logs, quota, ...
L'intérêt, net et évident, est que cette solution est à la fois simple et permet un réel contrôle : pour un utilisateur, bien identifié, le certificat présenté au début de la session SSL est bien celui du site visé.
Je présume (mais n'ai pas essayé) que le blocage d'un site, qu'il soit http ou https, étant en amont de l'établissement réel de la session ssl, amènera à la page de blocage dans les 2 cas et non l'erreur de certificat. (Fonctionnement différent puisque le client fait une requête et le proxy fait la vraie connexion au serveur).

Malgré tout, il est possible de faire tout ce que vous voulez faire, qui est très insecure.
Sauf transparent et authentification puisque impossible.
Je ne vois pas pourquoi, vous semblez comprendre et espérer une solution à la fois !
Les réponses, pour le certificat, sont dans Squid + SSL Bump ...
L'importation systématique du certificat du MITM masquera tout certificat !

Si un utilisateur demande au RSI pourquoi le certificat SSL de sa session vers sa banque n'est pas celui de sa banque, je n'aimerais pas être à sa place !
Il est probable qu'un utilisateur tombant sur une erreur de certificat, parce que le site est bloqué, finira par se dire 'Man-In-The-Middle' avec toutes les conséquences induites.
Dans l'autre cas, il sait que la connexion est logué et pas son contenu (alors qu'avec 'Man-In-The-Middle', il y a incertitude d'où certitude ...).
Il est certain, qu'à la longue, un utilisateur ne voyant aucune demande pour un nouveau site https, finira par se poser la même question. (Pas tous mais certain ...)

On est là dans la limite de l'Open-Source, qui dans la copie d'un fonctionnement insecure, s'égare ...
(enfin c'est mon avis)

jdh

Pour info, je vous suggère de regarder SSLStrip et HSTS.
Exemple : http://www.octetmalin.net/linux/tutoriels/sslstrip.php (ça date de 07/2011 : super le .ico avec cadenas juste à côté de http !)

La page wikipedia de HSTS indique "Une attaque du type man-in-the-middle ne peut pas intercepter de requête tant que le HSTS est actif pour ce site."

ccnet

http://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/
Par ailleurs je ne peux que souscrire à ce qui précède.

Si un utilisateur demande au RSI pourquoi le certificat SSL de sa session vers sa banque n'est pas celui de sa banque, je n'aimerais pas être à sa place

Moi non plus.
Concrètement la gestion de la clé privée du biclé qui réalise le MITM sur Pfsense (ou ailleurs) c'est "un peu" sensible.

chris4916

Nous sommes tous d'accord pour dire que "SSL bump" n'est pas bien et que dans l'absolu il ne faudrait pas le faire.
Sauf que tous les proxy HTTP les plus utilisés sont capables de fournir cette fonctionnalité et que la plupart des entreprises souhaitent fortement l'implémenter.

La raison est clairement justifiée par un des tous premiers paragraphes du lien fourni pas ccnet:

@No:

La protection de bout en bout qu’apporte TLS est a priori incompatible avec d’autres exigences de sécurité complémentaires visant à inspecter le contenu des échanges.
L’analyse d’un contenu (web par exemple) sécurisé à l’aide de TLS, peut toutefois se justifier afin de s’assurer que les données provenant d’un réseau non maîtrisé (Internet par exemple) ne représentent pas une menace pour le système d’information interne.
Les architectures visant à déchiffrer les flux TLS, pour permettre leur analyse, « tordent » donc le modèle pour lequel ce protocole est conçu.

En entreprise, il est très simple d'informer tous les utilisateurs que tout flux HTTPS est cassé au niveau du proxy et que l'utilisateur n'est pas supposé consulter les données de sa banque au travail, même si l'utilisation très modérée des ressources de l'entreprise pour un usage personnel est généralement admise.

A mon avis, expliquer à un DSI, convaincu que pour lutter efficacement contre les virus, SSL bump fait partie de la solution, qu'il ne faut pas le faire et lui proposer une solution alternative efficace est quelque chose de très difficile.

Ce que d'aucun prendrait pour un mensonge sécuritaire est relayé, expliqué et même justifié par cette publication de l'ANSSI.

Mon point de vue est que si on peut éviter de mettre ça en œuvre, il ne faut pas hésiter mais lorsque tous tes clients le demandent, que tous les outils ou presque le permettent et que l'ANSSI le soutient, refuser de déployer SSL Bump revient juste à refuser des clients. Ce qui est un choix éthiquement respectable, à défaut d'être économiquement viable.

(et je suis le premier à dire que ce n'est pas bien. Mon point ici c'est de dire qu'au delà de la position théorique parfaite, il y a la réalité du terrain. Le même débat que la solution "all-in-one" pour les TPE/PME qui intègre FW et proxy, entre autres, sur la même machine.)

jdh

Ce que je ne comprends pas, c'est l'entêtement à mettre en oeuvre un procédé très contestable sous prétexte de mettre qu'une seule machine alors même que l'on sait que les 2 fonctions n'ont pas les mêmes pré-requis matériels !

Surtout qu'avec un proxy dédié, on sait respecter le confidentialité de la session sans la casser (le certificat présenté à l'utilisateur est le bon).
Surtout aussi qu'avec HSTS (qui est déjà adopté), j'ignore si Bump l'a dans le c.

chris4916

Il y a 2 aspects, et donc potentiellement 2 discussions différentes:

Faut-il tout faire tourner sur la même machine
SSL bump (MITM)

1 - Pour l'approche UTM (all-in-one) nous en avons déjà longuement discuté. Nous sommes de plus d'accord que lorsque c'est possible, il est largement préférable de déployer des machines différentes. Certains, et j'en fais partie, acceptent cependant qu'il existe des cas où, dans la durée, cette solution intégrée sera plus stable et plus fiable (et également plus facile à vendre aux TPE/PME) qu'une solution moins facile à gérer qui consiste à ne viser que l'architecture intellectuellement idéale.

2 - Pour SSL bump, qui est donc une autre discussion indépendante de la précédente (sauf dans le cas où tu vises un proxy en mode transparent, dont je suis également d'accord de dire que ce n'est pas, et de loin, le meilleur choix ;)), HSTS impose une gestion fine des certificats sans quoi il y a des warnings dans tous les sens. Ceci dit, je ne peux commenter le déploiement sur pfSense car je ne l'ai pas expérimenté.

Il n'y a pas d'entêtement mais la réalité de la vraie vie, dans le cas de danielmuro83 qui reporte que beaucoup de ses clients souhaitent ce type de solution et qu'il est très difficile de les faire changer d'avis.
Et donc tu peux choisir, en tant que fournisseur de service, de ne pas travailler avec ces clients là mais ton entreprise a t-elle vraiment toujours le choix ? ???

chris4916

peux-tu, stp, montrer la page de configuration de Squid sur pfSense, en tous cas la partie SSL Man-in-the-middle filtering ?

sooulepavelaplage

@chris4916:

Il n'y a pas d'entêtement mais la réalité de la vraie vie, dans le cas de danielmuro83 qui reporte que beaucoup de ses clients souhaitent ce type de solution et qu'il est très difficile de les faire changer d'avis.

bonjour,

apres, pour faire plasir a tous le monde, et ne garder que le "meilleur des deux mondes", il existe des boitiers (tour ou rack) ou il est possible d’intégrer :

pour la version tour, 2 cartes mère atx, 2 alim, 12 dd 3.5, avec kvm intégrés (ouais msieur !!) marque fusion, arrivage aléatoire… chez cd... gros... ou ruedu... (j'en ai 2)
pour le rack, 4U, 4 cartes mere atx+bus passif pci déporté , 4 alims, 16 dd 3.5 et toujours kvm intégré. vu l'an dernier sur alibaba. [edit] mais je crois 10 minimum et provenance chine.

bon fin d'aprem

jdh

1 fois par semaine, j'ai une Société de Service Informatique qui me propose ses services …

J'aimerais avoir quelqu'un qui me dise

Je ne vous propose pas une appliance 'tout-en-un'
Mais je vous propose, un le firewall (avec le vpn, le filtrage général, les nat, ...), deux le proxy qui contrôle la navigation.
Et si je lui disais "mais pourquoi pas une machine qui fait tout" (parce que je connais la réponse),
"Eh bien, non, je ne vous propose pas un seul boitier mais un boitier et un serveur parce que ..."

L'avant-vente qui me dirais cela, je le trouverai plus sérieux ...

chris4916

@jdh:

L'avant-vente qui me dirais cela, je le trouverai plus sérieux …

Nous sommes d'accord.
Mais là tu te positionnes en tant que client qui a déjà fait un choix et qui justement attend de la société de service une réponse conforme au choix que tu as déjà fait.

Quand tu es société de service et que ton client a fait le choix contraire, même si tu as à ton catalogue un service de déploiement de BlueCOat et que ton client potentiel te dit: "moi je voudrais un truc simple avec un seul serveur qui fait tout parce que j'ai lu dans une revue spécialisée que les UTM étaient maintenant très performants et qu'en plus je n'ai personne pour m'en occuper donc je mettrai ce serveur dans un placard…etc" tu peux essayer de le convaincre mais ça va être difficile.

D'autant que tes arguments relatifs profil de charge hardware ne tiennent pas, surtout pour des TPE/PME.

Les problèmes potentiels sont ailleurs, au niveau des opérations et de l'exploitation.

sooulepavelaplage

@jdh:

1 fois par semaine, j'ai une Société de Service Informatique qui me propose ses services …
[…] L'avant-vente qui me dirais cela, je le trouverai plus sérieux …

salut

d'abord tu remarqueras (maintenant qu'on s'est bien engueulé, on peut se tutoyer) que toi qui semble tellement "service-service" ou plutôt "charte-charte" est le premier à déraper vers tes convictions et pas vers la question. je précise que comme les autres intervenants sur ce fil, je suis d'accord avec toi sur le principe de la "séparation des pouvoirs" des bécanes… mais on fait pas toujours ce que l'on veut quand on tente d'être le 1er coin (de bucheron) chez un nouveau client.

sinon, pour rire, si tu en vois, ou es contacté par, un par semaine, cela fait 40 par an (une fois enlevé les congés, le mois d'aout, la fin de l'année et les ponts de mai) . si tu en avais trouvé un seul qui aille dans le sens de tes convictions sur l'ensemble de ta carrière, tu l'aurais surement dit, et tu aurais surement ajouté : "a pas du bouffer tous les jours le garçon!"

bonne soirée.

danielmuro83

Déjà merci à vous pour votre temps :)

Je suis tout à fait d'accord sur l'ensemble des principes cités plus haut.
A chaque machine son rôle, c'est bien évidement le meilleurs concept et la meilleur démarche à proposer en tant que société de service, et ceux pour toutes raisons déjà évoquées plus haut et ce à juste titre.

Cependant malgré le fait que nous devons un conseil de qualité, il est nécessaire de prendre en compte la réalité actuelle du marché (ce n'est pas de l'entêtement).
Notre intérêt bien sûr (et aussi dans celle du client) est de proposer au premier abord ce qui se fait selon les bonnes pratiques.
Néanmoins, même si le client apprécie le conseil, si pour des raisons financières (ou pour tout autre raison d'ordre fonctionnelle), il ne peut pas opter pour une solution de ce type, que devons-nous faire ? Ne pas répondre à la demande ? (pas très productif), ou tenter de lui proposer une solution plus adaptée.

Les acteurs du marché l'ont compris et veulent pouvoir se positionner sur tout type d'infra, non pas seulement les grandes mais aussi les petites structures.
Comme j'ai pris par exemple Fortinet et stormshield, mais aussi Sophos (dont j'ai assisté au tour de France ce matin même), ils ont tous un axe de développement autour de la mutualisation des rôles aux seins même de leurs UTM (Filtrage Web, Antivirus, antispam (voir passerelle de messagerie), filtrage applicatif, portail captif, gestion des access points, etc…..)
Sophos parle même d'interconnexion entre l’antivirus client et l'analyse antiviral de l'UTM et la gestion centralisé au niveau Cloud...

Le fait d'être en accord ou non avec ces concepts est un débat en effet intéressant et pertinent, chaque avis étant justifiable.
Mais c'est une réalité que de constater que c'est le parti pris des constructeurs et que les prochaines solutions seront de plus en plus all-in-one.

jdh

Je me souviens d'un de mes patrons qui me disait "tu délègues quand tu maîtrises" (parce que si le "délégué" lâche, tu es capable de reprendre).
Mais il y a le cas où tu ne maîtrises pas.

Il y a donc 2 sortes de clients :

celui qui a une bonne compétence,
celui qui n'est pas assez compétent (qui croit l'avoir).
Le premier refusera de faire un MITM, le second n'en aura pas même conscience.
Il est clair que les fabricants d'UTM visent les seconds … qui sont les plus nombreux.

Comme clients, je ne souhaite pas être mené en bateau. (Suis-je a-normal ?)
L'avant-vente qui viendrait me parler de son formidable UTM qui fait tout, aurait forcément la question du MITM. Et là il sait ou pas.
Néanmoins, je verrais d'un bon oeil un prestataire me proposant 2 solutions et m'expliquant que la 2ième, plus chère, est plus respectueuse ...

Il y a contradiction entre 'Marketing' et 'Sécurité' ...

(Dans la pratique, je n'ai besoin de personne pour faire les firewall des entreprises où je passe depuis 15 ans. Mais il m'est arrivé d'utiliser des petits boitiers type Zyxell, ou des moyens comme WatchGuard, ...)
(Dans l'une, j'ai commencé par annuler le contrat de support d'un checkpoint à 4000€/an dans une pme industrielle de 300 pers sur 2 sites : fallait pas pousser ...)

(Si un avant-vente parle de choses qu'il ne connait pas à fond, tant pis pour lui ...)