Le filtrage WEB
Le filtrage web contribue de manière indéniable à l’optimisation de la bande passante et de la sécurité informatique. Son intérêt est donc double, d’une part en bloquant l’accès à des sites internet gourmands en bande passante, le filtrage web contribue à une utilisation plus efficace des ressources réseau. Cela peut améliorer les performances globales du réseau, assurer une connectivité plus rapide et plus stable, et éviter la congestion inutile de la bande passante. D’autres part en restreignant l’accès à des sites potentiellement dangereux ou inappropriés, le filtrage web contribue à prévenir les infections par des logiciels malveillants. Le filtrage web est une composante à part entière de la stratégie de sécurité informatique, fournissant un moyen proactif de protéger le réseau, les utilisateurs et les données contre diverses menaces en ligne tout en favorisant un environnement de travail efficace et sûr.
Pour permettre de filtrer des sites WEB, nous devons mettre en place un outils d’inspection de requêtes http, en effet, dans l’entête de la requête nous retrouverons l’URL cible, cette URL sera ensuite comparée :
- Avec une Blacklist, si l’url est présente, l’accès sera alors refusé
- Avec une Whitelist, si l’url est présente, l’accès sera autorisé
Dans beaucoup de cas, une blacklist est utilisé, ainsi toutes les urls ne figurant pas dans la blacklist sera accepté. Dans la blacklist, nous retrouverons des urls, mais aussi des mots clés, si l’url contient un de ses mots clé alors le site ne sera pas accessible.
Différence entre proxy et filtrage WEB
Dans de très nombreux cas de figure, le filtrage WEB sera associé à un proxy, c’est pour cela que certain confond ses deux composants mais qui jouent un rôle bien distinct. Le filtrage WEB, comme nous l’avons écrit plus tôt, est un outil qui nous permet de bloquer ou d’autoriser l’accès à des sites internet. Le proxy quant à lui, est un serveur mandataire, c’est-à-dire que le client le sollicite pour accéder à des ressources sur internet et c’est le proxy qui va lui remettre les informations émanant de Internet. L’utilisateur ne sera ainsi jamais connecté directement sur Internet. L’intérêt du proxy est d’économiser la bande passante, en effet, lorsqu’un utilisateur demande une ressource sur un internet, il contactera le proxy, ensuite le proxy va rechercher cette ressource sur Internet pour la remettre à l’utilisateur mais en plus de faire cela, il va stocker cette ressource dans son cache et si un autre utilisateur fait la même demande, le proxy ira la récupérer directement dans son cache. Au vu du rôle central du serveur proxy, nous y installons la solution de filtrage mais il est tout à fait possible d’avoir un proxy sans solution de filtrage et il est également possible d’avoir une solution de filtrage sans proxy.
Dans pfSense, le filtrage web n’est pas composant autonome, mais plutôt une fonctionnalité qui nécessite l’association avec un serveur proxy web. Ce serveur proxy, appelé SQUID, est intégré à pfSense mais peut également être installé sur une machine dédiée. Pour des questions de faciliter, nous l’utiliserons avec pfSense.
Installation et configuration de SQUID.
SQUID n’est pas intégré nativement à pfSense, il nous faut l’installer. En effet, pfSense propose d’étendre ses outils en mettant à disposition des packages. L’ensemble de ses packages sont disponible en déroulant le menu « System » et en sélectionnant « Package Manager»
Nous nous rendrons ensuite dans l’onglet « Available Packages ». Dans le champ « Search Item » dans la section « Search », nous renseignerons le nom de l’outil que nous souhaitons installer et nous terminerons en cliquant sur le bouton « Search ».
Dans la liste des résultats, nous pouvons lire dans la description de « squid », que cela sera la version 3.5 de squid qui sera installé qui est une version qui date de juillet 2018, cette version n’est actuellement plus maintenue et comme nous pouvons nous en rendre compte en nous rendant à cette page, https://www.cvedetails.com/vulnerability-list/vendor_id-9950/product_id-17766/version_id-1468085/Squid-cache-Squid-3.5.28.html, cette version fait l’objet d’un très grand de CVE .
Bon à savoir :
Une CVE (Common Vulnerabilities and Exposures) est une identification unique attribuée à une vulnérabilité. C’est une référence standard pour suivre et échanger des informations sur les failles de sécurité, facilitant la communication et la gestion des risques.
De plus, en nous rendant dans la documentation de pfSense traitant des packages, à l’adresse suivante : https://docs.netgate.com/pfsense/en/latest/packages/list.html , nous pouvons lire que l’entreprise derrière pfSense préconise de ne pas l’installer et que ce package va disparaitre de pfSense dans un avenir proche.pour en savoir plus, nous voous invitons à vous rendre sur la documentation officiel de pfsense
Ce point nous permet d’intégrer dans cette documentation un autre concept de la sécurité, à savoir, s’assurer d’utiliser des versions d’outils qui soit maintenu par son éditeur. Lorsque l’éditeur indique une dépréciation, cette période de dépréciation des outils que nous utilisons devrait être une période où nous devrions rechercher des alternatifs. Une des alternatifs possible et c’est celle que nous mettrons en place dans cette documentation est l’installation de la dernière version de SQUID sur une machine dédiée. Cela nous permet à la fois d’avoir une version maintenue de SQUID mais aussi d’appliquer l’adage « Ne pas mettre tous ses œufs dans le même panier », en d’autres termes, il faut diversifier ses outils de renforcement de la sécurité. Laisser toutes la sécurité sur un équipements peut être vu comme un SPoF (Single Point of Failure).
Dans l’aricle «Installation Pfsense sur VMWare Workstation », pour le serveur WEB, nous avions installé la distribution Almalinux pour le serveur WEB. Pour l’installation du serveur proxy, nous vous proposons d’installer UBUNTU dans sa version actuel LTS. Comme pour le serveur WEB, nous veillerons à faire une installation minimale. Les informations de cette machine
- Cette machine sera installée dans le réseau LAN et sera joignable à l’adresse IP 10.1.0.4/24.
- La passerelle sera l’adresse IP virtuelle de notre LAN 10.1.0.252
- Son serveur DNS sera notre DNS local 10.1.0.3
- La machine se nommera SQUID.
Nous ne détaillerons pas l’installation d’Ubuntu Server.
Installation de SQUID
Après avoir mis à jour la liste des paquets disponibles sur les dépôts configuré par défaut, nous mettrons à jours les paquets actuellement installé.
belkhrissi@squid:~$ sudo apt update -y
belkhrissi@squid:~$ sudo apt upgrade -yDans la distribution Ubuntu, nous avons un pare-feu baptisé UFW, s’il est maintenant disponible par défaut, il n’est pas activé. Nous commencerons par activer UFW.
belkhrissi@squid:~$ sudo ufw enable
Dans les dépôts officiels, le paquet squid est présent, c’est cette version que nous installerons.
belkhrissi@squid:~$ sudo apt install squid squid-openssl -y
La version qui sera installé, sera la version 5.7 qui n’est pas la dernière version.
Il serait tout à fait envisageable d’installer SQUID depuis les sources mais cela peut poser d’autres problèmes. En général, sauf cas particulier, l’utilisation des paquets gérés par le système d’exploitation est recommandée. Les paquets facilitent la gestion, la maintenance et la sécurité du logiciel sur le système.
Configuration de SQUID
Le fichier de configuration « squid.conf » présent dans le répertoire « /etc/squid/ » est très documenté, ce qui en fait plus une documentation qu’un fichier de configuration. Nous allons garder copier l’original puis modifier ce fichier en supprimant toutes les lignes commentées.
belkhrissi@squid:~$ sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original
Pour supprimer tous les commentaires du fichier de configuration /etc/squid/squid.conf, c’est-à-dire supprimer toutes les lignes qui commence par le caractère #, nous utiliserons l’outils « sed » et nous utiliserons une expression régulière.
belkhrissi@squid:~$ sudo sed -i '/^\s*#/d; /^\s*$/d' /etc/squid/squid.conf
« sed » est l’outil de traitement de texte en ligne de commande.
« i » indique à sed de modifier le fichier.
« /^\s*#/d » est la commande « sed » qui indique de supprimer (d) toutes les lignes qui commencent (^) par aucun ou plusieurs espaces (\s*) suivis d’un caractère #.
« /^\s*$/d » supprime les lignes vides
Si nous affichons le nombre de ligne nous pouvons voir que nous somme passer d’un peu plus de 9100 lignes à un peu une trentaine de lignes.
Nous analyserons se fichier et l’adapterons à nos besoins.
belkhrissi@squid:~$ sudo vim /etc/squid/squid.conf
Dans la première partie du fichier de configuration, il s’agit essentiellement de la déclaration des ACL (Access Control Lists) pour les différents réseaux. Pour lister ses réseaux, SQUID s’appuie sur des RFC. Ces ACL spécifient les plages d’adresses IP qui sont considérées comme faisant partie du réseau local.
Dans notre contexte, nous pourrions supprimer ses lignes et créer une ACL pour notre réseau local.
Nous créerons également une ACL liée au port. Dans notre cas de figure, nous n’avons autorisé que le port 80 et 443 dans notre pfSense donc nous pouvons effacer la pré-configuration et ne créer qu’une ACL, « ports_autorise » où nous y déclarons le port 80 et 443.
Nous allons ensuite indiquer des directives basées sur les ACLs que nous avons précédemment créé. Les directives sont associées au paramètres « http_access », nous adapterons ses directives à notre contexte. Nous autoriserons les ports autorisés, la machine locale, le LAN et nous interdirons les autres ports ou adresses. De plus, nous modifierons le port d’écoute par défaut
Le paramètre coredum_dir permet de définir où seront stocker les fichiers de vidage en cas de plantage. Ils seront utiles pour le dépannage. Nous ajouterons une autre directive qui va nous permettre de définir un répertoire pour stocker le cache.
- aufs : Le type de stockage du cache, aufs est efficace pour le cache en lecture seul.
- /var/spool/squid : Le répertoire où le cache sera stocké.
- 5000 : La taille maximale du cache en mégaoctets soit 5 Go dans notre cas
- 16 : Le nombre de niveaux d’arborescence dans la hiérarchie du cache.
- 256 : Le nombre maximum d’objets dans chaque niveau de l’arborescence du cache.
En ce qui concerne la configuration du rafraîchissement de notre cache, nous maintiendrons la dernière ligne et y apporterons une modification en ajoutant à la fin de la ligne le terme « last-modified ». Cette configuration vise à conditionner le rafraîchissement de la page à chaque modification, en limitant cette mise à jour à des changements de plus de 20%. Si la ressource à actualiser est une page web affichant une horloge mise à jour chaque seconde, le paramètre « last-modified » change potentiellement chaque seconde. En fixant le seuil de changement à 20%, nous réduisons le risque de surconsommation de bande passante associé à des mises à jour fréquentes.
- « . » indique toutes les URL
- « 0 » : indique le délai minimum de rafraichissement en minute
- « 20% » : pourcentage des données obsolètes que nous tolérons.
- « 4320 »: correspond en nombre de jours le délai maximum d’un fichier sans rafraîchissement
- Last-Modified, permet à Squid de vérifier qu’il possède bien la dernière version du fichier.
Fichier squid.conf
#Déclaration de notre réseau LAN
acl mon_lan src 10.1.0.0/24
#Déclaration des ports autorisés
acl port_autorise port 443
acl port_autorise port 80
#Autorisation pour les ports définis dans port_autorise
http_access allow port_autorise
http_access allow localhost
http_access allow mon_lan
#Interdiction pour les autres ports
http_access deny all
#Configuration du port autorisé à recevoir les requêtes des clients
http_port 8443
#Configuration des répertoires utiles à squid
coredump_dir /var/spool/squid
cache_dir aufs /var/spool/squid 5000 16 256
#Rafraichir le cache si la page a été modifiée
refresh_pattern . 0 20% 4320 last-modifiedAprès avoir effectué toutes les modifications, que nous avons vu, nous sauvegarderons notre fichier « /etc/squid/squid.conf » et nous redémarrerons le service SQUID.
belkhrissi@squid:~$ sudo systemctl restart squid
Dans le pare-feu de la machine exécutant SQUID, nous autoriserons les connexions entrantes depuis n’importe quelle adresse IP du réseau 10.1.0.0/24 vers l’adresse IP spécifique 10.1.0.4 sur le port 8443
belkhrissi@squid:~$ sudo ufw allow from 10.1.0.0/24 to 10.1.0.4 port 8443
Configuration des clients
Afin que SQUID soit utilisé par nos clients, nous devons configurer les machines de notre réseau. Pour cela nous avons deux possibilités, les configurer manuellement, ce qui peut s’avérer long mais qui peut être un paramètre intégrer dans le fichier de réponse du master de déploiement. La seconde option s’est de créer une GPO. Dans ce document, nous détaillerons la seconde option.
Dans la version Windows Server 2022, nous n’avons pas de GPO à configurer pour Edge, nous devons les télécharger les politiques depuis le site de Microsoft en nous rendant sur l’url : https://www.microsoft.com/fr-fr/edge/business/download?form=MA13FQ.
Une fois le fichier CAB télécharger, nous allons effectuer en double-cliquant dessus et décompresser l’archive en choisissant l’option Extraire du menu contextuel.
Sur le contrôleur de domaine, nous ouvrirons la console d’administration « Gestion de stratégie de groupe ». Après avoir déplier le nœud du domaine, nous allons nous rendre dans « Objet de Stratégie de groupe ». Dans la partie de droite, après avoir fait un clic-droit, nous sélectionnerons « Nouveau ». Nous donnerons un nom à notre « Nouvel objet GPO » et nous cliquerons sur le bouton « OK » pour valider notre choix.
Après avoir avoir sélectionner « Modifier » dans le menu contextuel de notre nouvel objet, nous allons nous rendre dans « Configuration ordinateur > Stratégies > Modèles d’administration », nous ouvrions le menu contextuel de « Modèles d’administration » et nous sélectionnerons l’option « Ajout/Suppression de modèles ».
Après avoir cliqué sur le bouton Ajouter, nous allons parcourir le contenu de notre disque pour sélectionner le fichier « msedge.adm » présent dans l’archive que nous avons téléchargée et décompressée un peu plus tôt dans ce chapitre. Le fichier msedge est présent dans « \MicrosoftEdgePolicyTemplates\windows\adm\fr-FR ».
Dans l’objet Modèle d’administration, nous retrouvons un sous-dossier « Modèle d’administration classique (ADM ) », en ouvrant ce dossier, nous avons deux autres dossier Mircrosoft Edge et Microsoft Edge – Paramètre par défaut (les utilisateurs peuvent les modifier). Pour ce qui nous concerne, nous sélectionnerons le premier, c’est-à-dire Microsoft Edge, puis « Serveur Proxy », nous aurons alors accès à la GPO « Paramètres du proxy », nous la modifierons.
Après avoir choisi l’option « Activé », nous allons renseigner l’adresse IP de notre serveur proxy sans oublier d’indiquer le port d’écoute de SQUID, nous validerons cette configuration en cliquant sur « Appliquer » puis sur le bouton « OK » pour fermer la fenêtre.
Nous lierons cette stratégie de groupe à une unité d’organisation qui regrouperons les PC du LAN, cette OU n’étant pas encore créé, nous la créerons et nous y mettrons notre client. Ensuite, nous glisserons cet objet vers cet OU.
Pour que notre machine cliente prenne en compte cette stratégie de groupe, nous redémarrerons la machine. Au redémarrage de la machine, nous vérifierons que la stratégie c’est bien appliqué sur notre machine cliente, pour cela, nous allons nous rendre dans « Paramètres du proxy », nous aurons accés à la configuration « au paramètre proxy ». Nous cliquerons sur le bouton « Configurer », nous aurons accès à la configuration de notre proxy.
Configuration de la règle de pare-feu
Dans notre scénario, nous voulons que les utilisateurs passent par le serveur SQUID, pour aller sur Internet. Cette politique devra être imposer à nos utilisateurs, nous allons donc modifier la règle nous permettant d’accéder à Internet, pour que nos utilisateurs n’aient pas d’autres choix que de passer par notre proxy.
Dans pfSense, nous allons créer un nouvel alias pour notre serveur proxy et un nouvel Alias pour le port d’écoute de notre proxy.
Dans notre LAN, nous allons autoriser nos machines du LAN à ne communiquer qu’en HTTPS et HTTP. Pour créer cette règle, il est essentiel de bien comprendre qu’un client souhaitant se rendre sur Internet, il utilisera un port dynamique appelé aussi les ports éphémères pour envoyer une requête vers le port 80 ou 443.
Dans certain UTM, il existe un objet créer par défaut (alias dans pfSense) qui regroupera les ports éphémères, ce qui n’est pas le cas pour pfSense, nous le créerons. Notons ici que nous allons indiquer une étendue sous la forme <port_debut>:<port_fin>
Bon à savoir :
Le choix d’utiliser la plage 49152:65535 est motivé par la RFC 6335 qui spécifie les procédures générales pour l’allocation des ports.
Nous allons ensuite nous rendre sur la page des règles de notre LAN puis nous éditerons notre autorisant les connexions vers Internet.
Pour arriver à ce niveau de granularité, nous devons cliquer sur le bouton « Display Advanced » dans la section source.
Dans le paramètre Source Port Range, dans la liste déroulante « From », nous sélectionnerons « (other) » puis dans le champ « Custom », nous indiquerons le nom de l’alias de nos ports éphémères, nous aurons la même configuration pour le paramétrage de « To »
Pour la destination, nous indiquerons l’Alias de notre serveur SQUID et dans le port de destination, nous indiquerons le port d’écoute de SQUID.
Depuis notre poste client, nous tenterons de nous connecter à un site internet, par exemple nous testerons une connexion au moteur de recherche Google en tapant dans la barre d’adresse « google.fr ». Nous aurons alors une erreur.
En analysant la page d’erreur, nous pouvons constater, que le navigateur a tenté de se connecter à http://google.fr, nous retentons en forçant le protocole « https ». Cette tentative se conclu également par un échec. Mais cette fois ce n’est pas notre proxy qui nous envoie la réponse d’erreur.
Nous regarderons les logs de connexion du côté de SQUID pour investiguer.
belkhrissi@squid:~$ sudo tail -f /var/log/squid/access.log | grep google.fr
« HIER_DIRECT » indique que le cache n’a pas été utilisé donc nous pouvons affirmer que cela n’est pas dû à un problème de cache. Nous avons ensuite 503 qui correspond au code erreur HTTP, le serveur distant n’a pas pu traiter la demande.
De plus, « NONE_NONE/503 » indique que la requête n’a pas été satisfaite par le cache, aucune tentative de revalidation n’a été faite, et le serveur a renvoyé une réponse avec le code d’erreur HTTP 503.
La requête CONNECT est utilisée pour établir une connexion tunnel entre le client et le serveur distant sans déchiffrement intermédiaire donc CONNECT indique que le client a envoyé une requête CONNECT au proxy Squid.
En rapprochant ses logs et notre fichier de configuration, nous pouvons constater que nous interceptons le trafic HTTP sur le port 8443.
Nous n’avons pas configuré SQUID pour configurer l’interception des requêtes HTTPS. Lorsque Squid intercepte une requête HTTPS, il agit comme une interface intermédiaire entre le client et le serveur distant. Cette interception permet à Squid d’inspecter le trafic HTTPS, même si ce dernier est chiffré. Lorsque le client émet une requête HTTPS, Squid intercepte cette requête. Squid procède au déchiffrement de la requête HTTPS à l’aide de sa clé SSL privée. Ce déchiffrement permet à Squid d’inspecter le contenu de la requête, y compris les en-têtes HTTP et les données. À cet étape, Squid peut effectuer différentes opérations d’inspection, telles que l’application de règles de filtrage, la journalisation ou la modification du trafic en fonction de sa configuration.
Après l’inspection, Squid rechiffre la requête en utilisant le certificat SSL/TLS du serveur distant. Cette étape est cruciale pour transmettre la requête initiale de manière sécurisée au serveur distant sans compromettre la confidentialité des données. La requête rechiffrée est ensuite redirigé vers le serveur distant comme si elle provenait directement du client. Ce mécanisme, est appelé « SSL Bump » dans SQUID.
Dans ce processus, nous voyons que nous avons besoin d’une nouvelle clé privé et de son certificat. Nous stockerons cette clé et ce certificat dans un répertoire que nous créerons.
belkhrissi@squid:~$ sudo mkdir /etc/squid/ssl/
belkhrissi@squid:~$ cd /etc/squid/ssl/
belkhrissi@squid:/etc/squid/ssl# openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout cle_squid.key -out squid_ca.crt
Pour des raisons techniques spécifiques à Squid et à la manière dont il gère les certificats, nous devons convertir le certificat au format DER.
belkhrissi@squid:/etc/squid/ssl#:~$ openssl x509 -in squid_ca.crt -outform DER -out squid_ca.der
Nous allons ensuite configurer le tunnel de communication qui permettra la négociation entre SQUID et les machines souhaitant se connecter sur internet. Lors de cette phase de négociation, il y aura un échange de clé pour chiffrer et déchiffre les données. On utilise la négociation « diffie-hellmann »
belkhrissi@squid:/etc/squid/ssl# openssl dhparam -outform PEM -out dhparam.pem 2048
Pour que SQUID puisse utiliser la clé et les certificats, nous allons rendre l’utilisateur lié au service squid propriétaire du répertoire dans lequel sont stockées ses éléments. Cet utilisateur sur Ubuntu se nomme « proxy » et son groupe est également nommé « proxy ». Nous ajusterons les droits en autorisant que la lecture sur nos certificats et notre clé à notre utilisateur proxy.
belkhrissi@squid:/etc/squid/ssl# chown -R proxy:proxy /etc/squid/ssl/
belkhrissi@squid:/etc/squid/ssl# chmod 400 /etc/squid/ssl/*Squid s’appuie sur une base de données pour gérer les certificats racine de diverses autorités de certification de confiance. Ces certificats racine sont utilisés pour vérifier la chaîne de confiance des certificats SSL/TLS émis par les serveurs web.
belkhrissi@squid:/etc/squid/ssl# mkdir -p /var/lib/squid
belkhrissi@squid:/etc/squid/ssl# rm -rf /var/lib/squid/ssl_db
belkhrissi@squid:/etc/squid/ssl# /usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 20MB
belkhrissi@squid:/etc/squid/ssl# chown -R proxy:proxy /var/lib/squidNous avons préparer la partie certificat pour notre serveur SQUID, nous allons intégrer ses informations dans notre fichier de configuration /etc/squid/squid.conf/
belkhrissi@squid:/etc/squid/ssl#vim /etc/squid/squid.conf
Nous autoriserons le téléchargement de certificats intermédiaires par Squid lorsqu’il intercepte le trafic HTTPS. Au début de fichier, nous allons ajouter :
acl intermediate_fetching transaction_initiator certificate-fetching
http_access allow intermediate_fetching
cache_effective_user proxy
cache_effective_group proxy
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 20MB
sslproxy_cert_error allow all
ssl_bump stare all
http_port 8443 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/ssl/squid_ca.crt tls-key=/etc/squid/ssl/cle_squid.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/ssl/bump_dhparam.pem Nous commenterons la ligne suivant que nous avons configurer précédemment.
#http_port 8443 fichier /etc/squid/squid.conf.
LIGNE A AJOUTER
#######################################################################
acl intermediate_fetching transaction_initiator certificate-fetching
http_access allow intermediate_fetching
#######################################################################
#Déclaration de notre réseau LAN
acl mon_lan src 10.1.0.0/24
#Déclaration des ports autorisés
acl port_autorise port 443
acl port_autorise port 80
#Autorisation pour les ports définis dans port_autorise
http_access allow port_autorise
http_access allow localhost
http_access allow mon_lan
#Interdiction pour les autres ports
http_access deny all
#Configuration du port autorisé à recevoir les requêtes des clients
####LIGNE A COMMENTER
#http_port 8443
#Configuration des répertoires utiles à squid
coredump_dir /var/spool/squid
cache_dir aufs /var/spool/squid 5000 16 256
#Rafraichir le cache si la page a été modifiée
refresh_pattern . 0 20% 4320 last-modified
#LIGNE A AJOUTER
##################################################################################
cache_effective_user proxy
cache_effective_group proxy
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 20MB
sslproxy_cert_error allow all
ssl_bump stare all
http_port 8443 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB tls-cert=/etc/squid/ssl/squid_ca.crt tls-key=/etc/squid/ssl/cle_squid.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/ssl/dhparam.pem
Pour que les modifications que nous avons apportées à la configuration de Squid soient prises en compte, nous devons redémarrer le service Squid.
belkhrissi@squid:/etc/squid/ssl#systemctl restart squid
En cas d’erreur, vous pouvez vérifier si le fichier de configuration ne comporte pas d’erreur à l’aide de la commande suivante :
belkhrissi@squid:/etc/squid/ssl#squid -k parse
Nous ajouterons une règle dans notre pfSense qui autorisera seulement notre serveur Proxy à se connecter sur internet.
Depuis notre poste client, nous tenterons de nous connecter sur un site internet. Vu que le certificat est celui envoyé par SQUID, nous aurons un message nous informant que le certificat ne peut pas être vérifier et par conséquent il ne peut pas vérifier la légitimité de l’émetteur de notre certificat.
Pour faire reconnaitre ce certificat, il nous faut l’installer dans le magasin « Autorité de certification de confiance ». Pour éviter à devoir le faire sur chacun des machines du réseau, nous allons faire cette action par une GPO.
Dans un premier temps, nous devons récupérer ce certificat. Sur mon poste client, sur ma page web qui m’informe que ma connexion n’est pas privée, nous allons cliquer sur «Non sécurisé» présent sur la barre d’adresse.
Nous cliquerons ensuite sur le message en rouge « La connexion à ce site n’est pas sécurisée », ce qui nous amène vers le détail de cet avertissement, nous cliquerons sur le bouton « certificat ».
Nous aurons alors accès aux informations de notre certificat. En nous rendant sur l’onglet « Détails », nous pourrions enregistrer le certificat en l’exportant.
Une fois le certificat récupérer, nous allons le copier/coller sur notre contrôleur de domaine. Sur notre contrôleur de domaine, nous ouvrirons la console mmc « Gestion des stratégies de groupe » disponible dans le menu « Outils »
Dans le menu contextuel de l’unité d’organisation « Ordinateur », nous sélectionnerons « Créer un objet GPO dans ce domaine, et le lier ici… » et nous lui donnerons un nom Nous modifierons ensuite, cet objet GPO.
Dans l’objet de stratégie de groupe, nous nous rendrons à « Configuration ordinateur » -> « Stratégies » -> « Paramètres Windows » -> « Paramètres de sécurité » -> « Stratégie de clé publique » -> « Autorité de certification racines de confiance ». Dans la partie blanche à droite de la console, nous ouvrirons le menu contextuel à l’aide du clic-droit de la souris, puis nous sélectionnerons « importer ».
Nous serons accompagnés d’un assistant d’import tout au long du processus. Nous passerons le message de bienvenue en cliquant sur le bouton « Suivant ». Nous serons ensuite invités à sélectionner notre certificat, après avoir cliqué sur le bouton « Parcourir », nous sélectionnerons notre certificat, puis nous validerons notre choix en cliquant sur le bouton « Ouvrir », puis sur le bouton « Suivant » pour passer à la suite.
Nous laisserons le choix du magasin du certificat puis après avoir cliquer sur le bouton « Suivant », nous cliquerons sur le bouton « Terminer »
Nous testerons notre Objet GPO en actualisant la page où nous avions un avertissement de sécurité. Nous devrions plus avoir le message d’avertissement et en regardant les informations liées au certificat, nous voyons que la machine SQUID a émis le certificat et que la connexion est sécurisée.
Installation et configuration de SquidGuard
La puissance de Squid en tant que serveur proxy réside dans sa conception modulaire et extensible, qui permet l’ajout de modules complémentaires pour étendre ses fonctionnalités et l’adapter aux besoins spécifiques de l’utilisateur. Parmi les modules complémentaires les plus utilisées nous retrouvons SquidGuard. Ce module va permettre à ajouter à SQUID des fonctionnalités de filtrage, de surveillance ou encore de contrôle d’accès. Nous commencerons par installer SquidGuard.
belkhrissi@squid:~$ sudo apt install squidguard -y
SquidGuard fonctionne en s’appuyant sur des whitelist ou blacklist, donc soit on interdit soit on autorise une liste d’url ou de mot clé. Dans la majeur parti des cas, SquidGuard s’appuiera sur une liste de site internet à interdire l’accès soit pour des raisons légales soit pour des raisons de politique de sécurité interne à l’entreprise. L’université de Toulouse propose une blacklist gratuite et qui est régulièrement mise à jour. Nous nous appuierons sur cette blacklist. Après avoir créé le répertoire qui contiendra la blacklist, nous le téléchargement directement depuis le site de l’université de Toulouse.
belkhrissi@squid:~$ sudo mkdir /etc/squidguard/blacklist
belkhrissi@squid:~$ sudo wget http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz belkhrissi@squid:~$sudo tar xf blacklists.tar.gz
belkhrissi@squid:~$sudo cp -R blacklists/* /etc/squidguard/blacklist/
belkhrissi@squid:~$chown -R proxy:proxy /etc/squidguard/blacklist/
La liste fournit par l’université de Toulouse propose des listes de domaine, d’url ou encore d’expression qui vont est catégorisée.
Pour bloquer des catégories, il nous faudra les déclarés dans le fichier de configuration /etc/squidguard/squidGuard.conf. Avant de modifier ce fichier, nous allons garder copier la configuration originale.
belkhrissi@squid:~$ sudo cp /etc/squidguard/squidGuard.conf /etc/squidguard/squidGuard.conf.orginal
Nous repartirons d’un fichier vierge.
belkhrissi@squid:~$ sudo su
root@squid:/home/belkhrissi# echo " " > /etc/squidguard/squidGuard.conf
root@squid:/home/belkhrissi# vim /etc/squidguard/squidGuard.conf
Nous commencerons par déclarer les catégories en indiquant leurs emplacements. Pour notre test, nous bloquerons les sites pour adultes, audio-video ou encore agressif, ses catégories sont disponibles ensuite dans une base de données que nous allons générer par la suite
#Emplacement de la base de données
dbhome /var/lib/squidguard/db
logdir /var/log/squid
#Déclaration des catégories
dest porn {
domainlist /etc/squidguard/blacklist/porn/domains
urllist /etc/squidguard/blacklist/porn/urls
}
dest adult {
domainlist /etc/squidguard/blacklist/adult/domains
urllist /etc/squidguard/blacklist/porn/urls
}
dest audio-video {
domainlist /etc/squidguard/blacklist/audio-video/domains
urllist /etc/squidguard/blacklist/audio-video/urls
}
dest aggressive {
domainlist /etc/squidguard/blacklist/aggressive/domains
urllist /etc/squidguard/blacklist/aggressive/urls
}
Ensuite, nous procéderons à la création d’une ACL (Liste de Contrôle d’Accès). Dans cette ACL, nous établirons une règle par défaut. Cette règle par défaut aura pour objectif de restreindre l’accès aux catégories que nous avons préalablement définies. Pour ce faire, nous utiliserons le mot-clé « pass », suivi du nom de la catégorie précédé du symbole d’exclamation « ! ». Par exemple, « pass !audio-video » signifiera « bloquer la catégorie audio-vidéo ».
Chaque fois qu’un utilisateur se verra refuser l’accès, il sera automatiquement redirigé vers une page web spécifique, pour ce faire un serveur APACHE a été installer sur le serveur qui héberge SQUID. Sans trop rentrer dans le détail voici la procédure d’installation est de configuration
root@squid:~#apt install apache2
root@squid:~#echo " " > /var/www/html/index.html
root@squid:~#vim /var/www/html/index.html
###Contenu de index.html###
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Accès bloqué</title>
<style>
body {
font-family: Arial, sans-serif;
background-color: #f5f5f5;
margin: 0;
padding: 0;
text-align: center;
}
.container {
background-color: #fff;
border-radius: 10px;
box-shadow: 0 0 10px rgba(0, 0, 0, 0.2);
margin: 100px auto;
max-width: 400px;
padding: 20px;
}
h1 { color: #e74c3c;}
p { color: #333;}
</style>
</head>
<body>
<div class="container">
<h1>Accès bloqué</h1>
<p>Le site web que vous tentez d'accéder est bloqué en raison de la politique de sécurité de l'entreprise.</p>
<p>Veuillez contacter le service informatique ou l'administrateur système si vous avez des questions ou si vous pensez que cette restriction est incorrecte.</p>
</div>
</body>
###Fin du Contenu de index.html###root@squid:~#a2enmod ssl
root@squid:~#mkdir /etc/apache2/ssl
root@squid:~#openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
root@squid:~#vim /etc/apache2/sites-available/squidguard-ssl.conf###Contenu de squidguard-ssl.conf ###
<VirtualHost *:443>
ServerName block.elkhrissi.lab
DocumentRoot /usr/lib/cgi-bin/
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
###Fin du contenu de squidguard-ssl.conf ###
root@squid:~#ufw allow 443/tcp
root@squid:~#a2ensite squidguard-ssl
root@squid:~#systemctl reload apache2
Nous pouvons maintenant utiliser le serveur WEB pour indiquer que le site internet sur lequel il souhaite se rendre a été bloqué.
default {
pass !porn !adult !aggressive !audio-video all
redirect https://block.elkhrissi.lab/
}
}
Exemple de fichier squidGuard.conf
#Emplacement de la base de données
dbhome /var/lib/squidguard/db
logdir /var/log/squid
#Déclaration des catgories
dest porn {
domainlist /etc/squidguard/blacklist/porn/domains
urllist /etc/squidguard/blacklist/porn/urls
}
dest adult {
domainlist /etc/squidguard/blacklist/adult/domains
urllist /etc/squidguard/blacklist/porn/urls
}
dest audio-video {
domainlist /etc/squidguard/blacklist/audio-video/domains
urllist /etc/squidguard/blacklist/audio-video/urls
}
dest aggressive {
domainlist /etc/squidguard/blacklist/aggressive/domains
urllist /etc/squidguard/blacklist/aggressive/urls
}
#Création d'une ACL
acl {
default {
pass !porn !adult !aggressive !audio-video all
redirect https://block.elkhrissi.lab/
}
}
Dans cette configuration, nous lirons que nous avons rediriger les utilisateurs qui
Nous allons ensuite rediriger les requêtes http(s) qui sont intercepté par SQUID vers squidGuard en spécifiant l’accès à son fichier de configuration.
root@squid:/home/belkhrissi# vim /etc/squid/squid.conf
A la fin du fichier nous ajouterons les lignes suivantes pour demander à SQUID d’aller consulter la configuration de squidGuard et nous configurerons le nom de sous-processus de squid pour exécuter squidGuard et nous autoriserons les redirections de squidGuard.
# Emplacement du fichier de configuration de SquidGuard
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 5
url_rewrite_access deny CONNECT
url_rewrite_access allow allPlus tôt nous avons spécifier l’emplacement de la base de données et nous avions préciser qu’il nous faudra la générer, c’est ce que nous allons faire maintenant.
root@squid:/home/belkhrissi# squidGuard -d 2 -C all
Bon à savoir :
La commande SquidGuard -d 2 -C all peut être simplifier en squidGuard -C all pour créer la base de données, l’option « -d 2 » permet d’avoir une sortie détaillée et ainsi voir si nous rencontrons des erreurs.
Pour que les modifications soient prises en considération, nous redémarrerons le service SQUID.
root@squid:/home/belkhrissi# systemctl restart squid
Nous tenterons de nous connecter à un site internet d’une des catégories que nous avons interdites, nous devrions être bloqué.
Bon à savoir :
Certain site internet peuvent être configurer, pour des raisons de sécurité, l’accés à votre page web de redirection, cela sera le cas par exemple avec les services « prime video »
Dans les logs de connexion /var/log/squid/access.log, nous voyons que « lorsque que la machine 10.1.0.10 tente de se connecter à Netflix, il rediriger vers https://block.elkhrissi.lab
Sur le plan technique, il est tout à fait envisageable de substituer l’adresse IP par le nom de l’utilisateur, mais cela doit être réalisé en pleine conformité avec la législation en vigueur. En effet, le règlement général sur la protection des données (RGPD) exige une transparence totale dans le processus de collecte des données. Il convient de rappeler que du point de vue juridique, une entreprise est généralement considérée comme un fournisseur d’accès Internet, ce qui la soumet aux mêmes obligations légales, notamment en ce qui concerne la conservation des journaux de connexion. Dans le cas où vous souhaiteriez identifier des individus plutôt que des adresses IP privées, il n’est pas nécessaire de solliciter leur consentement préalable. Cependant, vous avez l’obligation de mettre en place un registre de traitement des données, indiquant clairement qui est responsable de ce processus et spécifiant les modalités pour que les utilisateurs puissent exercer leur droit d’accès, de rectification, de suppression ou de modification des données.
Il est important de noter que cette documentation n’a pas pour vocation de servir de fondement juridique. Par conséquent, nous vous encourageons vivement à consulter un juriste ou un avocat spécialisé dans ce domaine pour obtenir des informations plus détaillées. Il convient de souligner que l’identification des utilisateurs comporte inévitablement des considérations juridiques spécifiques.