Proxy Squid / SquidGuard

Présentation du contexte :

GSB (Galaxy Swiss Bourdin) est créé en 2009 par la fusion de Galaxy, expert en maladies virales, et Swiss Bourdin, spécialisé dans les médicaments classiques. Le siège administratif est à Paris, le social à Philadelphie. L’objectif est d’optimiser les coûts et la production en combinant leurs forces. L’entreprise compte 480 visiteurs médicaux en métropole et 60 en outre-mer, répartis en 6 zones.

Le besoin :

La DSI a décidé de mettre en place dans son infrastructure une solution de filtrage web pour contrôler l’accès à Internet, améliorer la sécurité du réseau. Cette solution doit permettre de bloquer l’accès à des sites inappropriés ou non professionnels, tout en offrant une gestion fine des politiques d’accès.

Solutions envisageables et retenues :

Différentes solutions sont possibles :

DansGuardian : Une solution open source de filtrage de contenu.
Untangle : Une plateforme de sécurité réseau complète.
Squid + SquidGuard : Une combinaison puissante et flexible pour le filtrage web.

La solution retenue est Squid + SquidGuard, car elle est open source, hautement configurable, et bénéficie d’une grande communauté.

Principe de fonctionnement :

Squid est un serveur proxy open source qui permet de gérer le trafic web. Il agit comme un intermédiaire entre les utilisateurs et Internet, en filtrant les accès selon des ACL.

SquidGuard est un outil complémentaire à Squid, spécialisé dans le filtrage web. Il permet de bloquer l’accès à des sites web en fonction de listes noires(par exemple, sites malveillants, contenus inappropriés), compilées en base de données Berkeley(ce qui permet d’améliorer les performances, par rapport à des listes au format texte). SquidGuard permet de facilement gérer des listes d’URLS en plus des domaines, contrairement à Squid seul.

Squid + SquidGuard fonctionne de la manière suivante :

Squid reçoit les requêtes HTTP/HTTPS des utilisateurs.
Squid redirige ces requêtes vers SquidGuard pour analyse.
SquidGuard applique les règles de filtrage définies (listes noires, URLs..).
Si la requête est autorisée, Squid la transmet à Internet. Si la requête est bloquée, SquidGuard renvoie une page d’erreur à l’utilisateur.

$C:\Users\lcendamo\Downloads\4d1ceace026046cba5d96eaae457a3baaaa9bb40.png$

Mise en œuvre :

La mise en place de Squid + SquidGuard implique les étapes suivantes :

Installation et configuration de Squid pour gérer le trafic web.
Installation et configuration de SquidGuard pour définir les règles de filtrage.
Création de listes noires ou utilisation de listes existantes pour bloquer les sites indésirables.
Configuration des politiques d’accès par utilisateur ou groupe (par exemple, restrictions spécifiques pour les visiteurs médicaux).
Test et validation de la solution pour s’assurer que le filtrage fonctionne correctement.

Conclusion :

La combinaison de Squid et SquidGuard répond parfaitement aux besoins de GSB en matière de filtrage web. Elle offre une solution performante, sécurisée et flexible, tout en étant économique grâce à son modèle open source. Cette solution permettra à GSB de mieux contrôler l’accès à Internet, d’optimiser l’utilisation de la bande passante, et de renforcer la sécurité du réseau.

Schéma réseau actuel :

Schéma réseau attendu :

Installation :

L’installation se fait en installant les paquets Squid, et SquidGuard.

Il faudra par la suite importer les listes de domaines et d’URL depuis une source sûre, nous utiliserons les listes de dsi.ut-caputole.fr.

Puis il faudra configurer les fichiers Conf de Squid et de SquidGuard.

Nous utiliserons une machine vierge Debian 12.

Installation des paquets

Pour commencer, faire :

apt update && apt upgrade

Puis :

apt install squid

Une fois l’installation faite, nous pouvons vérifier la version installée avec la commande :

squid –version

Ensuite, nous pouvons installer SquidGuard :

apt install squidguard

Importation des blacklists :

Pour importer les blacklists, se rendre dans le dossier ou nous allons télécharger et extraire l’archive contenant les blacklists, que nous allons récupérer sur le site de ut-capitole :

cd /var/lib/squidguard/db

Puis télécharger l’archive :

wget -c http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz

Puis l’extraire :

tar -xzf blacklists.tar.gz

Nous pouvons voir avec la commande ls, que nous avons maintenant deux éléments dans le dossier /var/lib/squidguard/db :

blacklists : le dossier extrait de l’archive

blacklists.tar.gz : l’archive que nous avons téléchargée depuis us-capitole

Voici le contenu du dossier blacklists :

Chaque dossier contient des fichiers texte contenant des listes d’urls et de domains.

Configuration des fichiers conf de squid et de squidguard :

Nous allons maintenant éditer le fichier squidGuard.conf afin de paramétrer les règles de filtrage :

Nano /etc/squidguard/squidGuard.conf

Et le modifier comme suit :

dbhome : le répertoire ou se trouvent les blacklists

logdir : la ou se trouve le fichier log de squidguard

src bar-clients : acl contenant le vlan users de notre réseau. Il est possible d’en créer plusieurs afin de définir différentes règles pour un groupe de machine spécifique, tel que des règles d’horaire par exemple.

dest : acl pour indiquer les différentes listes que l’on veut utiliser, ainsi que le liens de redirection pour les domaines ou url bloquée.

acl : acl pour les restrictions proxy, ici on interdit l’accès aux site, url et expressions contenue dans les différentes listes indiquées pour un vlan particulier, en l’occurrence, le vlan users pour l’acl « bar-clients ». SquidGuard var parcourir une à une les listes indiquées dans l’acl et appliquer la règle définie. Bloquer, ou autoriser le passage. (le ! indique le blocage) Il va donc parcourir les listes adult, pishing et warez. Si l’url demandé par le client est contenue dans une de ses listes, Squid va bloquer l’accès et rediriger l’utilisateur sur l’url de redirection défini. Si l’url demandée n’est dans aucune des trois listes, il va autoriser la connexion, grâce à la règle « all » qui autorise tout ce qui n’a pas été bloqué par les règles précédentes.

Maintenant, nous devons lancer la compilation des bases. Pour ce faire, nous avons la commande suivante :

squidGuard -d -b -P -C all

Le –c suffit mais cette commande nous permet de voir la base se faire en temps réel comme ci-dessous :

Voici le résultat :

Nous allons maintenant configurer Squid pour qu’il utilise SquidGuard.

Pour ce faire, il faut éditer le fichier /etc/squid/squid.conf afin d’ajouter les lignes suivantes :

acl lan src 192.168.110.0/24

http_access allow lan

url_rewrite_program /usr/bin/squidGuard

url_rewrite_children 20

Puis régler les droits d’accès aux répertoire pour que Squid puisse correctement fonctionner :

chown -R proxy:proxy /var/lib/squidguard

chown -R proxy:proxy /var/log/squidguard

Cela va nous permettre d’indiquer à Squid d’utiliser SquidGuard.

Status du service Squid avant modification de son fichier conf :

Status après modification et relance du service :

Nous pouvons constater que Squid utilise bien SquidGuard

Configuration du proxy sur une machine afin de tester le bon fonctionnement :

Nous paramétrons le proxy comme suis sur la machine windows :

Nous lançons un navigateur afin de tester l’accès à internet aux pages non bloquées par une des acl :

Cela fonctionne bien, testons maintenant avec un site bloqué dans l’ACL warez :

Nous sommes bien redirigés vers le lien de redirection configuré dans le fichier squidGuard.conf.

Le proxy est fonctionnel.

Authentification des utilisateurs

Afin de garder les logs de connexion des utilisateurs, et pour autoriser la connexion uniquement aux utilisateurs autorisé, il est possible de mettre en place une méthode d’authentification.

Afin de faciliter la gestion ainsi que l’utilisation, il est possible de configurer Squid pour qu’il authentifie les utilisateurs via Active Directory.

Pour ce faire nous allons avoir besoin d’installer trois paquets : windind, chrony, et samba :

apt install smb

apt install chrony

apt install winbind

Puis on modifie le fichier etc/samba/smb.conf pour y ajouter le nom de notre domaine.

Puis le ficher chrony, ou on y indiquera l’ip de notre serveur NTP.

Il faut ensuite relancer les trois services.

Puis modifier le fichier conf de Squid en y ajoutant les lignes suivantes :

auth_param basic program /usr/bin/ntlm_auth –helper-protocol=squid-2.5-basic

auth_param basic children 50

auth_param basic realm Squid GSB

auth_param basic credentialsttl 2 hours

acl ntlm proxy_auth REQUIRED

http_access allow ntlm

Et on relance le service squid.

Il faut maintenant joindre la machine au domaine :

net ads join -U lcendamo (lcendamo est un compte administrateur du domain)

Puis rentrer le mot de passe du compte. Le serveur devrait maintenant être sur le domaine.

Pour tester :

net ads testjoin

La machine devrait retourner « Join is OK »

La commande wbinfo –g nous permet quant à elle de vérifier si le serveur a bien les accès pour parcourir l’Active Directoy :

Tentons maintenant de lancer un navigateur, il devrait nous demander de nous authentifier :

Il suffira alors de se connecter avec son compte de session AD. Sans cela, il sera impossible de naviguer sur internet, et chaque requête http sera lié à un utilisateur dans les logs.

Haute disponibilité du service :

intro

Pour mettre en place la haute disponibilité du service, il nous faut dans un premier temps une seconde machine Squid, avec les mêmes paramétrages.

Pour ce faire, il est possible de cloner la machine actuelle ou reconfigurer une nouvelle machine de A à Z, manuellement ou en utilisant un outil d’automatisation comme Ansible.

Je vais utiliser un Playbook Ansible que j’ai mis en place, qui va totalement paramétrer la machine et installer les paquets utiles, pour qu’elle puisse fonctionner directement. Les détails de fonctionnement complet de ce Play sont visibles dans le projet Ansible.

Une fois la machine prête, nous pouvons passer à la suite.

Le .pac

Une manière simple de mettre en place la haute disponibilité et d’utiliser un fichier .pac (proxy auto-configuration). Il est simple à créer et il suffit de l’héberger sur un serveur web.

Ce fichier permet de mettre facilement en place des règles d’exclusions, ainsi que de définir un ou plusieurs serveur proxy. De cette manière, l’ordinateur qui aurait le proxy configurer via ce fichier pac, pourras contacter le deuxième serveur indiqué, si le premier ne répond plus.

Voici le fichier .pac disponible à cette adresse http://192.168.110.65/squid.pac :

Les règles d’exclusion se trouvent dans la première partie « if » : on indique que si le nom d’hôte termine en .gsb.lan ou que si l’ip est dans le réseau 192.168.110.0 ( qui correspond à notre sous réseau) les requêtes http seront directement envoyées à l’hôte, sans passer par le proxy.

Dans a seconde partie « else » PROXY permet d’indiquer vers quels serveurs proxy envoyer toutes les autres requêtes http qui n’aurait pas match avec les deux premières règles. Les requêtes seront donc d’abord envoyées au premier proxy indiqué, puis au deuxième si le premier ne répond pas. DIRECT permet d’indiquer à la machine d’envoyer les requêtes normalement si aucun des deux proxy ne répond.

Mise en place et test

Pour paramétrer une machine Windows pour qu’elle utilise le .pac pour le proxy, il suffit de se rendre dans les paramètre proxy de Windows, et de renseigner l’URL du .pac :

Pour tester la haute disponibilité, il suffit de couper le service Squid sur le premier serveur indiqué dans le .pac, qui correspond au serveur primaire et de tenter d’accéder à une page web :

Puis on lance un page web et on test un domaine bloqué :

On a pu continuer à naviguer sur le web et le contenu bloqué est bien bloqué malgré la coupure du SQUID01 qui est le serveur primaire. Le HA est donc bien fonctionnel.

Déploiement de la configuration

Pour déployer la configuration du Proxy sur les postes clients, il est possible de le faire de deux manière :

Avec WPAD (Web Proxy Auto-Discovery Protocol) qui va utiliser le service DHCP pour déployer automatiquement le paramétrage du .pac.
Avec GPO qui va déployer le .pac via le service AD.