Proxy transparent sous pfSense
Petit article traitant à nouveau du Routeur/Pare-feu pfSense. Ici, nous allons voir comment installer un serveur proxy transparent à l’aide de Squid pour filtrer les requêtes HTTP mais aussi HTTPS via de l’interception SSL.
Avant tout, il faut déjà faire un petit rappel…
1) Proxy, proxy transparent… mais encore ?
Un proxy est un intermédiaire –en français il se traduit par mandataire– qui va comme son nom l’indique se connecter à notre place à une autre machine, par exemple un serveur web. Lorsque je vais aller naviguer sur notamax.be, je vais contacter mon proxy et c’est lui qui va se connecter au site web à ma place: ce dernier n’aura donc aucunement conscience que c’est moi qui l’ai contacté, il ne verra que les informations du proxy (Adresse IP, OS, user-agent…).
En voici une liste (non exhaustive) :
- Proxy anonyme, il va permettre d’améliorer notre vie privée sur Internet en cachant notre adresse IP (sans toutefois chiffrer notre connexion, ce n’est pas un VPN !), notre navigateur et OS utilisé, etc. En effet, ce que le serveur web, c’est votre proxy, et pas votre ordinateur !
- Proxy de cache, qui va comme son nom l’indique mettre en cache (en mémoire) certaines données pour accélérer notre connexion. Si on suit notre premier exemple, le proxy peut sauvegarder en mémoire des pages web, des images, des fichiers, etc.
- Reverse proxy, qui est comparable à un proxy classique si ce n’est qu’il est mis en général au devant d’un serveur (web par exemple), et il permet donc d’augmenter la sécurité et effectuer du caching. Si le client essaye de contacter le serveur et qu’il ne respecte pas certaines règles de sécurité, sa demande est rejetée.
Mais alors, c’est quoi un proxy transparent ? Et bien c’est tout simplement un proxy que l’utilisateur final ne voit pas ; en effet, si vous voulez utiliser un serveur proxy vous allez devoir vous même le configurer sur votre poste de travail (dans votre navigateur ou d’autres logiciels par exemple) alors qu’avec un proxy transparent, les requêtes (HTTP et HTTPS en général) seront récupérées et analysées par le serveur sans que l’utilisateur ne soit mis au courant… l’intérêt ? Et bien par exemple en entreprises, pour être sûr que les utilisateurs ne puissent pas contourner les règles de sécurité en désactivant leur proxy ou autre.
Pour accéder à Internet, l’utilisateur final devra donc obligatoirement passer par le proxy (dans notre cas ce sera notre routeur/pare-feu pfSense) et ainsi nous pourrons réguler le trafic. Mais ce n’est pas fini, c’est ici que ça se corse…
2) Analyser le trafic HTTP, d’accord, mais quid du trafic HTTPS…?
En effet, en général un proxy (transparent ou non) ne sert qu’à la navigation web, il va donc dans notre cas se contenter de mettre en cache des pages web et images et bloquer l’accès à certains sites… pour ce faire, on va donc devoir analyser les requêtes HTTP de nos clients, mais c’est là où en entreprises il faut faire attention: si nous voulons aussi analyser et bloquer certains trafics HTTPS, qui sont donc chiffrés et sécurisés, nous ne pouvons pas le faire sans avoir au préalable avertis les utilisateurs que nous allons réaliser ce qu’on appelle du SSL Interception.
Car oui, même si l’accès à Facebook et autres sites du genre peut (et doit?) être réglementé en entreprise, vous devez tout de même avoir le droit (aux heures de pauses ou autre) de consulter vos mails personnels ou naviguer « librement » sur Internet. Ce type d’opération citée plus haut n’est rien d’autre qu’une attaque Man in the middle -littéralement l’attaque de L’homme du milieu– qui consiste à se placer entre la cible et le serveur pour capturer et éventuellement altérer les données transitant par notre machine. Il y a donc un cadre légal à adopter: vous devez prévenir vos utilisateurs, sinon cela tombe sous le coup de l’illégalité !
Mais bref, nous ne sommes pas ici pour faire un article sur le hacking ou sur la léglistation du domaine IT, nous ce que nous voulons, c’est dans un premier temps capturer et réguler le trafic HTTP, et dans un second temps le trafic HTTPS.
Retenez simplement que la capture du flux HTTPS dans le cadre de l’installation d’un Proxy nécessite l’installation au préalable d’un certificat SSL sur les postes utilisateurs, ce qui est donc assez facilement contournable mais nous en reparlons en fin d’article.
3) Mise en place du lab et schéma
Comme toujours, voici un schéma de notre LAB:
Comme vous pouvez le constater, j’ai repris un réseau virtuel isolé que j’avais déjà créé au préalable lors d’un autre article, sauf qu’ici nous allons simplement rajouter un service supplémentaire à notre cher pfSense.
4) Téléchargement du paquet Squid et configuration de base
La première étape est donc de se connecter sur l’interface admin de notre pfSense et d’aller dans le gestionnaire de paquets pour télécharger squid:
On choisi la version de base, et on valide. Ensuite on peut se rendre dans Services, puis Squid Proxy Server.
On va donc tout d’abord activer Squid, puis ensuite choisir sur quelle interface le proxy va écouter (LAN), éventuellement modifier le port si besoin.
On ne se préoccupe pas encore de la partie transparente ou de la partie proxy-HTTPS, on continue de descendre et on active la fonction de log pour voir les interactions clientes avec notre proxy, et on effectue quelque modifications générales (ne pas afficher la version de Squid lors des pages d’erreurs affichées au client, modifier le hostname, l’adresse mail…) :
On sauvegarde, et c’est bon ! Notre proxy est installé et configuré, si besoin vous pouvez créer une règle dans le Firewall pour activer le trafic du LAN vers le WAN sur le port 3128, en UDP comme TCP.
Bien, on peut maintenant activer le mode transparent pour que nos clients passent par notre proxy obligatoirement:
On peut maintenant vérifier que le système de cache par défaut fonctionne, mais surtout que nos clients se connectent bien au proxy en allant vérifier les logs:
It works ! On peut maintenant essayer de bloquer certains sites web, et ensuite si tout est fonctionnel on passera au SSL Interception 😉
5) Filtrage de domaines et URL
On va donc à présent bloquer l’accès à certains sites web pour vérifier que notre proxy est entièrement fonctionnel. Pour ce faire, rien de plus simple ! On se rend dans Service, Squid Proxy Server, puis dans ACLs
Comme on peut le voir, nous avons une boîte de dialogue Blacklist où nous pouvons entrer des domaines que le proxy va bloquer. Et juste au dessus, nous pouvons aussi bloquer des adresses IP (les utilisateurs peuvent très bien rentrer l’IP du site web et non son URL, soyez malins).
Et lorsque l’on tente d’accéder à ces sites web:
C’est donc entièrement fonctionnel ! On poursuit avec le HTTPS maintenant…
6) Interception SSL (filtrage du trafic HTTPS)
Dernière étape est de loin la plus « complexe », c’est bien entendu de réussir à filtrer le flux HTTPS transitant par notre proxy. Voici comment procéder par étapes.
En premier lieu, et comme pour l’article sur l’installation d’OpenVPN (voir ici), nous allons devoir créer un certificat SSL que nous installerons ensuite sur nos postes clients. Rendons-nous donc dans System puis Certificate Manager. Ici, nous devrons simplement renseigner un nom, le code ISO de notre pays, la longueur de la clé de chiffrement (SHA-256bits est suffisant) et c’est à peu près tout.
On se rend donc ensuite dans le service Squid, dans la configuration générale et on active l’interception SSL comme ci-dessous:
La fonction Splice All permet de capturer l’entiéreté du trafic SSL, et ainsi de bloquer certaines IP et certains domaines via des ACL ou via une blacklist de SquidGard. On choisi ensuite l’interface sur laquelle l’interception va avoir lieu (LAN, comme toujours), on laisse la compatibilité SSL/TLS sur Modern,
On peut directement se rendre sur le service Squid, au niveau des ACLs :
Ici on choisi le sous-réseau autorisé à utiliser notre proxy (pas réellement nécessaire, mais si vous avez quelques soucis cela peut aider), puis on choisi les domaines à bloquer.
Si l’on teste directement la navigation web depuis un de nos postes clients, on va très vite se rendre compte que désormais tous les sites web sont bloqués (erreur SSL) et pour cause: nous n’avons pas encore exporté notre certificat SSL !
On se rend donc de nouveau dans notre Certificate Manager et on clique sur l’icône pour l’exporter :
On se rend ensuite sur un de nos postes clients, et on double-clique sur notre certificat pour l’installer. Ici rien de très sorcier, il faut juste bien veiller au moment du choix du magasin de certificats à le placer dans Autorités de certifications racines de confiance, auquel cas cela ne fonctionnera pas :
Et ensuite on teste :
Et ça fonctionne parfaitement ! Si vous obtenez des erreurs SSL pour certains sites web comme google ou youtube, vérifiez que votre client a bien comme DNS votre proxy, sans quoi il risque d’y a voir quelque soucis.
On peut d’ailleurs aller consulter les logs directement depuis notre interface pfSense :
Comme on peut le voir ici, notre poste client s’est connecté sur le port 443 de notamax.be, c’est-à-dire le port HTTPS, tout est donc correct!
Et bien voilà voilà… je pense n’avoir rien oublié, en espérant vous avoir appris l’utilisation et les nombreuses possibilités de Squid, ainsi que vous avoir éclairé sur la fameuse interception SSL.
Encore une fois, n’hésitez pas à aller voir directement sur le site web de Squid ou de pfSense si vous avez des soucis, ou me communiquer directement par mails comme certains d’entre vous ont déjà fait 🙂
Laisser un commentaire