[Resolu]"Bloquer" les sites https via squid3+squidguard

ccnet

Merci beaucoup chris4916 pour votre réponse.
Le proxy n'est pas en mode transparent et je n'ai fait aucune configuration pour ne filtrer que les url HTTP.
Que squid proxy server soit en mode transparent ou non, je constate qu'il ne filtre que HTTP ce qui n'est pas normal.
Dans Squid3 je une partie "Man in The Midle", cette fonction peut-il m'aider dans le filtrage de HTTPS?

Je confirme qu'il y a confusion dans la compréhension. Oubliez le MTM.
Il y a bien une différence entre le mode transparent et le fonctionnement avec authentification. Ce dernier est nécessaire pour répondre aux contraintes législatives.
Je répète que votre problème est sans lien avec Pfsense. Le package et ses limitations éventuelles ne fait que compliquer les choses. La solution à votre problème est dans la doc Squid et en particulier la compréhension de "Connect" et des acl. Mais …
Au travail maintenant !

rash12

Merci beaucoup chris4916 et ccnet pour vos explication
que veut dire proxy en mode explicite? des demain je me met au travail… j'ai beaucoup lu sur la doc de squid et pfsense et sur les forum cet problème de filtrage des url https revient et j'ai pas vu de solution concrete.

chris4916

@rash12:

que veut dire proxy en mode explicite?

C'est le contraire du mode transparent.

En mode transparent, tu configures un proxy qui se trouve sur le chemin d'accès à internet (pour faire court, la route par défaut) et tu ne dis pas au navigateur qu'il y a un proxy. Celui-ci est transparent.
En mode explicite, tu confirgures ton proxy mais pas pour intercepter. Et tu précises à ton navigateur, de manière explicite, l'adresse du proxy. Oublie les histoires de WPAD, c'est une autre étape.

des demain je me met au travail… j'ai beaucoup lu sur la doc de squid et pfsense et sur les forum cet problème de filtrage des url https revient et j'ai pas vu de solution concrete.

En mode explicite, filtrer HTTP ou HTTPS, c'est la même chose. Il n'y a rien de spécial en terme de filtrage pour HTTPS. Donc tu dois avoir un autre problème qu'il faut identifier, c'est pourquoi je réitère ma proposition: quelques copies d'écran de ta conf Squid et Squidguard devraient aider à comprendre.

rash12

Bonjour!
voici les capture d'écran de ma configuration squid et squidguard. en plus de sa j'ai créer une règle dans le firewall pour autoriser le port 3128 de squid.
merci d'avance

squid.PNG_thumb

squid-transparent.PNG_thumb

MITM.PNG_thumb

squidguard.PNG_thumb

squidguard-backlist.PNG_thumb

squidgu.PNG_thumb

chris4916

et le client (navigateur) avec lequel tu fais les tests est bien configuré pour accéder au proxy ?

Au niveau du firewall, tu devrais, si possible, interdire (au moins provisoirement) l'accès aux ports 80 et 443 coté LAN, ce pour t'assurer que tout le flux passe bien par le proxy.

A la lecture rapide de ta conf, je ne vois rien de choquant pour le moment.

rash12

Merci chris4916
j'ai créer les règles comme tu la dit (capture d'écran) mais cel bloque tout j'ai meme plus accès à l'interface de pfsense. le navigateur pointe sur sur le proxy. mais actuellement je l'ai mise en mode "detection automatique". ya til un problème avec mes règles?

regle.PNG_thumb

chris4916

1 - n'utilise pas l'auto-detection du proxy, pour le moment du moins. c'est une fonction à mettre en oeuvre par la suite une fois que tout fonctionne et ça s'appuie sur WPAD.
2 - tu devrais normalement avoir, au niveau de l'interface d'admin, un accès en HTTPS sur le port 8443 ou un truc comme ça. C'est bien mieux que le port 80 ou 443
3 - au niveau du FW, il faut bloquer l'accès depuis le LAN vers internet pour les port 80 et 443, ce pour t'assurer qu'il n'y a pas d'accès direct. la règle devrait plutôt être un truc du genre "from LAN to 'not LAN' deny", ce qui ne t'empêche pas d'accéder à pfSense sur le port 80

rash12

voila les nouvelles règles!
quand je pointe les navigateurs (firefox et chrome) sur le proxy avec ces règles definie dans le firewall les pages web sont inacessibles.

rrrr.PNG_thumb

chris4916

@rash12:

voila les nouvelles règles!

De mon point de vue, c'est mieux

quand je pointe les navigateurs (firefox et chrome) sur le proxy avec ces règles definies dans le firewall les pages web sont inaccessibles.

Ce n'est pas bien grave, l'essentiel étant que tout soit configuré de manière logique. au moins nous avons progressé en terme de logique puisque nous n'avons plus ce comportement différent en tre HTTP et HTTPS ;D
A cette étape, il convient de comprendre pourquoi ces pages ne s'affichent pas correctement au niveau des navigateurs.

Pour ce faire, il faut regarder dans les logs et également faire quelques vérifications à différents niveaux.

1 - y a t-il un message d'erreur au niveau navigateur ?
2 - pfSense peut-il résoudre correctement les noms ? => un point important à comprendre: en mode proxy explicite, c'est le proxy (donc ici pfSense) qui se charge de résoudre les noms. Il faut donc que la config DNS de pfSense soit correcte. Je pense que c'est le premier point à vérifier.

chris4916

N'étant pas utilisateur de Squid/SquidGuard sur pfSense, il m'a fallu un petit moment pour comprendre les subtilités de cette implémentation :-[
mais en y travaillant avec l’initiateur de ce post, j'ai bien progressé dans ce domaine :)

1 - il semble que le package Squid3 distribué pour pfSense nécessite quelques ajustements pour fonctionner correctement selon les plate-formes.
par exemple [url=https://forum.pfsense.org/index.php?topic=88221.msg566230#msg566230]ce problème au niveau de libldap-2.4.so.2 pour SquidGuard est toujours d'actualité. (attention de bien choisir votre plate-forme lorsque vous créez le lien, amd64 ou i386 ;) )

Il convient donc de recréer les liens symboliques en tapant:

ln -s /usr/pbi/squidguard-amd64/local/lib/libldap-2.4.so.2 /usr/lib/libldap-2.4.so.2
ln -s /usr/pbi/squidguard-amd64/local/lib/libdb-5.3.so /usr/lib/libdb-5.3.so.0

ou

ln -s /usr/pbi/squidguard-i386/local/lib/libldap-2.4.so.2 /usr/lib/libldap-2.4.so.2
ln -s /usr/pbi/squidguard-i386/local/lib/libdb-5.3.so /usr/lib/libdb-5.3.so.0

si vous êtes confrontés à ce problème.

2 - j'ai réalisé, en échangeant avec rash12, qu'un des besoins était, au delà du blocage des sites en HTTPS, l'utilisation de blacklist pour ce même usage. Le problème est que les blacklists de SquidGuard sont pour … SquidGuard ;D ;D ;D et que l'interface graphique ne permet pas de gérer facilement l'équivalent au niveau des ACL de Squid (lequel gère le CONNECT)

A ce niveau, il est important de noter que avec HTTPS, si MITM n'est pas implémenté, le seul levier de filtrage est le domaine et non pas l'URL puisque seule la partie domaine est prise en compte par la méthode CONNECT.

Avec peu de domaines à exclure, la fenêtre "ACL / blacklist" de Squid (pas SquidGuard !) suffit .
Si vous avez beaucoup de domaines et souhaitez bénéficier de fichiers de type blacklist, je n'ai pas trouvé d'autre solution que celle consistant à créer des "custom ACLs" dans l'onglet "general / advanced features"

A ce niveau, il est possible de définir sa propre règle (attention de ne pas utiliser de nom d'ACL déjà utilisé par Squid, ce qui peut être vérifié en regardant la conf Squid disponible dans l'onglet log de Squidguard :o ::) )

l'ACL custom (avant auth) peut par exemple ressembler à:

acl blk_social dstdom_regex -i "/var/db/squidGuard/blk_BL_socialnet/domains"
http_access deny blk_social

cette règle va s'appuyer sur le fichier "domains" de la catégorie "social networks" des blacklists de SquidGuard 8) pour bloquer l'accès en HTTPS.

Il est bien sûr possible de gérer son propre fichier (sans GUI cependant) pour avoir un contenu plus personnalisé.

L'option "blacklist" disponible dans l'onglet "ACLs" fonctionne exactement de cette manière, avec son propre fichier "blacklist" et la même syntaxe Squid mais le contenu de cette fenêtre ne peut bien sûr pas (sauf erreur ou syntaxe que je ne connais pas) être lié à un autre fichier.

L'avantage c'est qu'on s'appuie sur la même blacklist que SquidGuard :D
L’inconvénient, et ce peut être un point bloquant, c'est que les ACL au niveau Squid ne permettent pas de mettre en œuvre de règles basées sur, par exemple des aspects horaires.
Dans ce cas, la seule solution est SSL Bump (Man In The Middle) >:(

PS: cette discussion est basée sur l'utilisation de Squid/SquidGuard comme outil de filtrage / contrôle. Il est bien sûr possible d'envisager des solutions autour du DNS mais celles-ce nécessitent de très bien comprendre quel DNS est utilisé et par qui/quoi 8)

chris4916

Quelques nouvelles de ce topic avant que rash12 le marque [RESOLU]

1 - c'est vraiment très intéressant, de mon point de vue, de mesurer les limites de l'exercice avec pfSense 8)
2 - il n'y a pas, avec ou sans pfSense, de solution simple pour faire du filtrage de type blacklist sur du flux HTTPS. Essayer de le mettre en œuvre en utilisant uniquement la boite pfSense s'avère un peut tricky.

La première approche consiste, avec Squid + SquidGuard, à activer MITM pour que SquidGuard puisse contrôler le flux HTTPS en s'appuyant sur les blacklists mais cette solution présente 2 inconvénients:

il faut déployer (truster) la clé publique du CA utilisé par pfSense lorsque celui-ci s'intercale dans la session HTTP, ce qui peut être un peu pénible
MITM génère des messages d'erreur si HSTS est activé

Une autre approche, en mode proxy explicite, à bloquer les domaines des catégories retenues pour la blacklist comme expliqué dans mon message précédent et à désactiver ce filtrage dans les tranches horaires où il n'est pas nécessaire.
Faire ça à grands coups de script pour modifier la configuration de pfSense serait à mon avis une très très mauvaise idée.

Donc l'idée est de:

garder le filtrage au niveau de Squid (domaines)
créer des schedules au niveau du FW pour interdire, pendant les heures de bureau, l'accès direct à internet (passage par le proxy filtrant obligatoire)
idem avec des schedules et des règles pour autoriser un accès direct (au niveau du FW) en dehors des heures de bureau

le truc, c'est le proxy.pac qui dirige vers le proxy pendant les horaires de bureau et en mode direct en dehors.
Ce qui signifie WPAD obligatoire :-)

Et ce point m'amène à un dernier commentaire:

lorsque l'interface d'admin de pfSense utilise un port spécifique en HTTPS, il n'est pas simple ni judicieux d'exposer le fichier proxy.pac via le serveur web de pfSense.
Oui la bonne idée serait une autre machine pour héberger serveur web, proxy etc… mais nous ne sommes pas dans ce schéma ::)

Une solution est proposée par ce lien trouvé par rash12.
ça consiste ne gros à démarrer une autre occurrence de lighttpd.

Ce design n'est pas 100% satisfaisant, par exemple dans le cas ou on voudrait permettre certains domaines à certains horaires et en interdire d'autres en permanence mais avec un objectif d'un seul serveur, c'est un niveau de service correct.

Idéalement, il faudrait, sur une autre machine, mettre le serveur WPAD et 2 proxy, sur 2 ports différents et avec 2 adresses sources différentes, pour juste passer d'un proxy à l'autre dans proxy.pac.
Chaque proxy peu ainsi filtrer plus ou moins de manière souple ;-)

rash12

Grand merci a chris4916. Grâce à son expertise, a sa disponibilité et sa patience, j'ai reçu a mettre en place le filtrage voulu c'est à dire "bloquer" les sites en https via squid3 sur pfsense.
merci !!!!