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



  • Bonjour!!!
    contexte: pro (stage), étudiant en informatique, phase de test avant déploiement.

    Besoin: mettre en place un serveur proxy libre au sein du réseau de ma structure d'accueil

    schéma:
    Wan: 1 modem ADSL
    Lan: 1, dhcp, adresse 192.168.1.0/24
    wifi: pas de wifi
    autres interfaces: pas d'autres interfaces
    règles firewall: par defaut coté wan et lan
    packages: squid3, squidguard

    questions: j'arrive à bloquer les url des sites en http ( j'utilise une backlist) mais ces meme urls de ces sites en https, le proxy n'arrive pas à les bloquer. comment puis-je resoudre ce probème? il y'a til une solution pertinente permettant de bloquer les url des sites https?

    pistes imaginées:

    recherches: suite à mes recherches, j'ai configurer le WPAD/PAC. j'ai aussi lu des chose sur ssl Bump (certaines personnes sur le forum déconseillais cela), aussi il ya la méthode qui consistait à bloquer les adresses ip des sites concernées (methode que mon patron a rejeter).
    log et test: actullement j'ai reinstallé pfsense, donc j'ai un système propre sans aucune configuration juste les paquets squid3 et squidguard installés.

    merci d'avance.



  • Bonjour,

    FORMULAIRE !!!!!!



  • Escusez j'aivais pas vu le formulaire. je corrige tout cela .
    merci



  • Bonjour!!!
    contexte: pro (stage), étudiant en informatique, phase de test avant déploiement.

    Besoin: mettre en place un serveur proxy libre au sein du réseau de ma structure d'accueil

    schéma:
    Wan: 1 modem ADSL
    Lan: 1, dhcp, adresse 192.168.1.0/24
    wifi: pas de wifi
    autres interfaces: pas d'autres interfaces
    règles firewall: par defaut coté wan et lan
    packages: squid3, squidguard

    questions: j'arrive à bloquer les url des sites en http ( j'utilise une backlist) mais ces meme urls de ces sites en https, le proxy n'arrive pas à les bloquer. comment puis-je resoudre ce probème? il y'a til une solution pertinente permettant de bloquer les url des sites https?

    pistes imaginées:

    recherches: suite à mes recherches, j'ai configurer le WPAD/PAC. j'ai aussi lu des chose sur ssl Bump (certaines personnes sur le forum déconseillais cela), aussi il ya la méthode qui consistait à bloquer les adresses ip des sites concernées (methode que mon patron a rejeter).
    log et test: actullement j'ai reinstallé pfsense, donc j'ai un système propre sans aucune configuration juste les paquets squid3 et squidguard installés.

    merci d'avance.



  • Merci pour l'usage du formulaire . Quelques questions et  précisions :
    Proxy libre vous pensez à un proxy transparent ?
    Votre patron a raison de ne pas retenir cette méthode.
    Vous voulez bloquer des sites en https ou examiner le contenu des transactions ?
    Ssl Bump pose des problèmes techniques mais surtout légaux.
    Votre problème est purement Squid et ne concerne pas Pfsense ou très à la marge. Regardez les docs Squid sera plus efficace.



  • Merci pour votre attention.
    En fait mon patron m'a demandé d'utiliser pfsense car  en plus du proxy, il veut un portail captif …
    Proxy transparent? Dans mes recherches j'ai pu comprendre que squid en mode transparent ne pouvait pas bloquer les url des sites en https.
    Je souhaite juste bloquer l'accès au sites pas examiner le contenu des transactions.
    avez vous une solution pour moi? est-ce que squid3 en mode transparent ou non plus squidguard peuvent faire mon affaire?
    Merci d'avance



  • Il y a probablement quelques notions qui ne sont pas très claires pour toi:

    • si tu évoques et mets en œuvre WPAD, alors il n'y a pas de proxy transparent puisque WPAD vise justement à diffuser, de manière automatique, aux navigateur l'information explicite de "où se trouve le proxy"
    • en mode proxy explicite, tu peux normalement faire du filtrage d'URL, indépendamment du protocole (HTTP ou HTTPS). Si cela ne fonctionne que en HTTP, c'est que ton proxy fonctionne en mode transparent ou que tu as configurer celui-ci pour ne filtrer que HTTP.
    • le filtrage d'URL est mis en œuvre par SquidGuard au travers de mécanismes de filtrage, soit avec des règles soit des blacklists. Squid seul permet quelques contrôles mais ceux-ci sont de type ACL et difficiles à gérer si il s'agit de bloquer un grand nombre de destinations.


  • 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?



  • Que squid proxy server soit en mode transparent ou non, je constate qu'il ne filtre que HTTP ce qui n'est pas normal.

    NON c'est parfaitement normal !
    Visiblement, vous ne connaissez pas comment fonctionne et un proxy transparent et le trafic https !

    Vous avez 2 réponses claires : à vous de recherchez en quoi les réponses sont correctes (elles le sont) et ce que vous devez en tirez …

    Ce qui serait le mieux : configurer un proxy dédié (sur une base Debian par exemple) afin de ne pas tout mélanger ...



  • @rash12:

    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.

    A ce stade, peut-être est-il plus simple de partager quelques copie d'écran de configuration ?

    Dans Squid3 je une partie "Man in The Midle", cette fonction peut-il m'aider dans le filtrage de HTTPS?

    MITM (Man In The Middle) n'intervient pas dans le filtrage d'URL mais uniquement dans le filtrage de contenu. Cette fonctionnalité (SSL Bump) permet de scinder en 2 la session HTTPS afin d'avoir accès en clair au contenu.

    Le filtrage d'URL (quels sont les sites autorisés ou pas) se fait au moment du CONNECT, donc avant que le client et le serveur se soient mis d'accord sur une session HTTPS, raison pour laquelle le porxy en mode explicite est suffisant pour contrôler les URL.



  • merci jdh!!!
    j'ai plus trop le temps pour essayer un proxy dedié sur debian….
    il ya til une solution pour filtrer les url https via squid sur pfsense?



  • @rash12:

    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 !



  • 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.



  • @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.



  • 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














  • 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.



  • 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?




  • 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



  • 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.




  • @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.



  • 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 !!!!


Log in to reply