Squid et SquidGuard- Installation d’un proxy et sécurisation des accès internet

Qu’est ce qu’un proxy ?
Un proxy est un logiciel qui sert d’intermédiaire entre un navigateur (client) et internet. Il est installé sur un serveur. Un proxy a plusieurs fonctions possibles :

  • il met en cache les pages consultées par les clients pour un accès plus rapide
  • il permet de loguer les différentes requêtes effectuées par les clients
  • il permet de filtrer le contenu en fonction de plusieurs critères, et d’autoriser ou non l’accès à un site.

En résumé, c’est un outil primordial pour tout réseau d’entreprise, car il répond à plusieurs problématiques :

  • dans le cas d’un réseau étendu, il permet à plusieurs entités éloignées géographiquement d’avoir un accès à internet centralisé. Cela évite d’avoir à payer un accès internet à chaque agence
  • il permet d’interdire a priori l’accès à des sites illégaux/interdits/contre-productifs
  • il permet d’économiser de la bande passante grâce à son système de cache
  • il permet a posteriori de savoir quel client est allé sur quel site, et à quelle heure. Ce n’est pas (uniquement) pour du flicage, mais il est primordial que l’administrateur réseau puisse répondre à une sollicitation judiciaire le cas échéant, si un employé a par exemple posté un message à caractère illicite dans un forum (nous ne discuterons pas ici de l’éthique, savoir s’il faut ou non répondre à ces sollicitations, ce blog n’est pas fait pour ça).

Nous allons ici étudier Squid, qui fait partie des proxys les plus utilisés, puis son complément SquidGard qui permet de configurer avec précision des systèmes de blocages importants.

Toutes les manipulations suivantes sont faites sur un Ubuntu server 8.04 LTS, ayant un accès internet fonctionnel.

Installation et configuration de Squid

L’installation de Squid est très simple. Il suffit de lancer la commande

sudo apt-get install squid

Premiers filtrages

Les fichiers de configuration se trouvent dans /etc/squid. Celui qui nous intéresse particulièrement est le squid.conf. Ce fichier est extrêmement documenté et la plupart des lignes de ce fichier sont des commentaires. Bien entendu, il faut les droits administrateur pour modifier ce fichier et il est fortement conseillé d’en faire une copie avant édition.

Dans un premier temps, nous allons regarder le port sur lequel Squid va écouter

Le port 3128 est le port par défaut. A moins que cela ne vous convienne pas, vous pouvez laisser cette valeur.

Les ACL

Les ACL (Access Control List) sont des groupes de différentes natures, servant par la suite à définir des règles de filtrage. Il y a de nombreuses nature d’acl, nous allons nous arrêter sur les plus utilisées :

  • src : adresse réseau source
  • dst : adresse réseau destination
  • dsstdomain : nom de domaine de destination
  • time : heure de connexion
  • port : port de destination
  • protocole : protocole de connexion (http, https, ftp, etc…)

Il y en a bien d’autres que vous pourrez consulter dans le documentation, pour permettre des réglages poussés de squid.

Dans le fichier squid.conf, une acl se définit ainsi :

acl <nom_de l’acl> <type de l’acl> <valeur>

Ainsi, on peut voir dans le fichier squid.conf :

acl localhost src 127.0.0.1/32

Qui définit l’acl localhost, qui est la source 127.0.0.1/32 (notre machine locale). Beaucoup d’acl sont définies par défaut, notamment les safe_ports.

Les access lists

Ce sont les différents tests qui sont faits en fonction des ACL. C’est un peu confus pour le moment, mais ça s’éclaircira plus tard avec la pratique. Comme pour les ACL, il y a beaucoup de valeurs possibles, nous ne nous arrêterons que sur les plus utilisées :

  • http_access : c’est la plus importante, celle qui définit l’autorisation d’accéder aux sites
  • cache : définit si on doit cacher ou pas le contenu

Les access lists sont de la forme :

<access lists> allow|deny acl AND acl AND …

Par exemple :

http_access deny !Safe_ports

Nous interdisons (deny) l’accès http à tout ce qui n’est pas Safe_ports (le point d’exclamation indique la négation). Les access_lists sont lues dans l’ordre du fichier, et on s’arrête à la première access_list vérifiée.

Par défaut, un squid fraîchement installé comprend des acl pour le réseau local. Il faut vérifier que les acl localnet correspondent bien à votre réseau. Il faut ensuite les autoriser en rajouter l’access list :

http_access allow localnet

puis redémarrer squid. Ensuite, il faut configurer un navigateur pour utiliser ce proxy et tester une page quelconque.

Une fois cette page testée, on devrait la voir apparaître dans les logs de squid : /var/log/squid/access.log

Analyser le contenu

Une fois la configuration effectuée, il est important de savoir qui va voir quel site. Pour cela, il existe divers outils.

Sarg

C’est un programme qui génère des pages web (il faut donc qu’il y ait un serveur web sur le serveur qui gère squid). Ces pages sont très complètes et d’analyse très simple. Pour l’installer, il suffit de faire

sudo apt-get install sarg

et de patienter jusqu’au lendemain pour voir les stats de la veille… Pour cela, il faut aller dans un navigateur à l’adresse http://<ip_du_serveur>/squid-reports/

Premiers filtrages

Avant de passer à une solution complète de type SquidGard, on peut déjà commencer par bloquer certains mots en se basant sur l’url. Pour cela, on va créer un fichier /etc/squid/sites_refuses.txt dans lequel on va mettre les mots clés interdits, un par ligne. Puis, on va modifier le squid.conf

acl interdit url_regex -i "/etc/squid/sites_refuses.txt"
http_access deny interdit

On crée donc une acl interdit qui se base sur un regex du fichier sites_refuses.txt, puis une access_list qui fait un deny de l’acl interdit.

Cette solution est facile et rapide à mettre en oeuvre, mais difficile à entretenir et peut poser certains problèmes. Par exemple, si on choisit d’interdire le mot "sexe", on va aussi bloquer les validations de formulaire en get qui contiennent le mot "sexe", ce qui peut se révéler gênant.

Installation de SquidGuard

Bon, là j’avoue, j’efface tout. J’avais écrit un début d’article, mais on trouve cent fois mieux sur le site de Christian Caleca. Je vous laisse donc aller voir là bas pour la suite.

Laisser un commentaire