[Resolu]"Bloquer" les sites https via squid3+squidguard
-
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)
-
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 ;-) -
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 !!!!