Fonctionnement

Bien que ces sujets soient abordés plus en détails ailleurs sur ce site, un petit rappel ne fera sans doute pas de mal. La question de base est :

• Comment permettre aux hôtes d'un réseau d'accéder aux hôtes d'un autre réseau ?

Au départ, nous disposons de deux réseaux physiques, construits avec des HUBS. Il suffit de placer un câble entre les deux HUBS. Cette solution simplissime interconnecte au niveau le plus bas (couche physique), avec quelques contraintes et inconvénients :

• Les trames émises par les nœuds de chaque réseau initial sont propagées sur l'autre réseau (en fait, il n'y a plus qu'un seul réseau physique) et le risque est grand de voir s'écrouler rapidement les performances du réseau ;

• du fait que nous sommes sur le même réseau physique, le réseau IP doit être également le même (même plan d'adressage IP.

Cette solution revient en fait à ajouter de nouveaux hôtes sur un réseau déjà existant.

La même chose, mais avec un dispositif un peu plus intelligent qu'un simple bout de fil, puisque le pont évitera la propagation des trames qui ne concernent pas un hôte de l'autre réseau. L'interconnexion se fait ici au niveau 2. Au niveau IP, les contraintes restent les mêmes, nous sommes partout dans le même réseau IP.

Cette solution est aujourd'hui complètement généralisée, puisque les switchs ne sont rien d'autre que des ponts multivoies et donc, tirer un bout de câble entre deux switches revient à la solution du pont.

Ici, nous interconnections au niveau 3 (IP). Les deux réseaux disposent chacun de leur propre plan d'adressage IP. Les possibilités de contrôle d'accès d'un réseau à l'autre sont bien plus fines (filtrage de paquets genre Netfilter/IPtables).

Nous travaillons ici au niveau 4 (du modèle DOD) c'est à dire au niveau du protocole d'application (HTTP pour ce qui nous concerne ici). Il existe deux types de serveurs mandataires :

• Le proxy « normal », qui nécessite que l'application cliente sache que le proxy existe et sache aussi travailler avec. En effet, dans ce cas, le client envoie ses requêtes au serveur mandataire, à charge pour lui d'aller chercher plus loin l'information réclamée par le client et de la lui transmettre, une fois l'information obtenue. Les clients HTTP (navigateurs) modernes savent tous le faire. C'est en revanche très rarement le cas pour d'autres protocoles comme POP, FTP etc ;

• le proxy « transparent », qui agit dans la totale ignorance du client. Dans cette situation, le client croit s'adresser directement à la cible finale, mais la requête est interceptée et traitée par le mandataire. Cette solution, nécessaire le plus souvent pour des protocoles comme POP ou FTP où les clients ne savent pas utiliser de proxy, n'est pas obligatoire pour HTTP. Nous aurons l'occasion de rediscuter de ce choix.

Dans l'illustration, les hôtes du réseau de gauche accèderont aux informations fournies par les serveurs HTTP du réseau de droite via le serveur mandataire qui est dans leur réseau. Nous reviendrons plus loin sur cette architecture qui peut sembler peu évidente au premier regard.

Installer un système de proxy cache pour HTTP. Ce proxy-cache propose deux fonctions principales :

• L'optimisation de la bande passante sur le lien Internet, lorsque de nombreux clients sont connectés et qu'ils visitent plus ou moins les mêmes sites, à la condition, bien sûr, que ces sites ne soient pas trop dynamiques, ASP, JSP, PHP… ni chiffrés (HTTPS). Comme vous le constatez, la fonction cache présente de moins en moins d'intérêt. Il en reste un cependant, surtout pour les illustrations qui ne sont pas encore toutes en flash ;

• le contrôle et le filtrage de l'accès à la toile, en se servant des URI et, éventuellement, des noms d'utilisateurs, si l'on fait de l'authentification de ces derniers, autant de choses qu'il est difficile, voire impossible de faire avec du filtrage de paquets. En effet, en travaillant au niveau du protocole HTTP, il devient possible de mettre en place des filtres d'URI, des analyses de contenu dans les documents, alors qu'au niveau IP, nous ne pourrions filtrer que sur des adresses et des ports.

Tout responsable d'un réseau local à l'usage de mineurs et connecté à l'Internet se doit de mettre en place un tel système de filtrage de manière à éviter, autant que possible, l'accès à des sites que la morale réprouve, d'autant qu'il s'agit d'une obligation légale.

	Dans un fonctionnement normal, un navigateur HTTP interroge directement le serveur cible et il reçoit directement les réponses de ce dernier. Il n'y a pas de filtrage possible, autrement que sur les adresses IP des serveurs cible.
	Dans le cas d'un proxy « normal », le client demande au proxy d'interroger le serveur cible. Ce dernier répond au proxy qui communique alors la réponse au client. Dans ce mode, le client est configuré pour utiliser un proxy et il modifie les requêtes http en fonction.
	Dans le cas du proxy transparent, le client ignore l'existence du proxy. Il croit envoyer ses requêtes directement au serveur cible, mais ses requêtes sont détournées vers le proxy par le routeur. Le serveur cible répond au proxy qui retransmet la réponse au client, mais ce dernier croit l'avoir reçue directement du serveur cible.

Nous discuterons plus tard de l'intérêt comparé des deux façons d'utiliser notre proxy.

Squid, principal composant de ce système, assure les fonctions de :

• Cache, pour optimiser la bande passante ;

• identification des utilisateurs, nous en verrons une simpliste et une nettement plus complexe ;

• filtrage d'accès « basique », mais déjà intéressant.

SquidGuard propose un filtrage très puissant d'accès au web, en fonction :

• De groupes d'utilisateurs, définis de diverses manières. Ici, nous nous baserons sur des IPs ou des groupes d'IPs, mais il est possible d'utiliser l'identification des utilisateurs mise en place sur Squid ;

• de listes de domaines et d'URI qui serviront à définir soit des cibles  autorisées, soit des cibles interdites (listes blanches, listes noires) ;

• de plages horaires pendant lesquelles l'accès sera autorisé ou interdit

Et bien d'autres choses encore, que nous ne verrons pas ici.

Squid tourne en tâche de fond (daemon). Il écoute sur un port spécifique (3128 par défaut, mais il est possible d'utiliser 8080, plus habituel pour un proxy HTTP). L'éventuel module d'identification vient se greffer dessus, ce qui fait apparaitre un certain nombre de processus fils (5 par défaut).

SquidGuard vient également se greffer dessus et apparait lui aussi sous la forme de processus fils (également 5 par défaut).

Au total, une fois Squid configuré, il n'y aura qu'à démarrer Squid et les processus d'identification et de filtrage avancé démarreront avec.

Pour aller très vite, SquidGuard utilise le format de bases de données Berkeley pour travailler. Pour définir ces bases, l'administrateur a recours à des fichiers au format texte qui seront pré compilés en base de données ou compilés à la volée, suivant la façon de travailler.

Nous verrons que les « destination groups » constituent des bases pré compilées, alors que les « blacklists » sont compilées à la volée et résident uniquement en mémoire. Ce principe est a éviter autant que possible, dans la mesure où il consomme énormément de ressources au démarrage de chaque instance de squidGuard.

Les dernières versions (disponibles  dans Lenny) de Squid (3 3.0.STABLE4-1) et SquidGuard (1.2.0) ont subi beaucoup de changements et les modules webmin ne sont, à l'heure où ces lignes sont écrites, plus adaptés. Nous serons donc obligés de mettre les mains directement dans le cambouis des fichiers de configuration.

Il faut faire très attention à ce que l'on fait et vérifier chaque fois que nécessaire que le but recherché est atteint. SquidGuard réserve pas mal de (mauvaises) surprises à ce propos.

Dans le cas de SquidGuard principalement, une gestion fine des bases de données pour les groupes de destination et les blacklists ne pourra se faire qu'à partir de la ligne de commande. Nous ne ferons qu'effleurer le problème, si vous en arrivez là, c'est que vous êtes déjà assez pointus sur le sujet pour pouvoir vous débrouiller tout seul avec la documentation (pauvre et laconique, il faut bien le dire).

Cette question, qui semble venir comme un cheveu sur la soupe, est tout de même l'une des premières questions à se poser, lorsque l'on désire mettre en place un serveur proxy comme Squid :

• sur https, les échanges sont chiffrés et ne peuvent être mis en cache. Utiliser Squid pour ses fonctions de cache n'offre ici aucun intérêt ;

• https authentifie au moins le serveur interrogé, de manière à ce que le client soit « sûr » qu'il s'adresse au serveur réellement choisi. Qu'advient-t-il de cette certitude, si la connexion passe par un intermédiaire ?

Lorsque nous utilisons un serveur proxy de façon « volontaire » (par le paramétrage de notre navigateur), nous savons que ce paramétrage modifie le comportement dudit navigateur, qui va alors envoyer toutes ses requêtes sur le proxy (voir le chapitre sur HTTP). Dans une telle situation, si le client peut authentifier le serveur proxy, sa connexion https peut à la rigueur encore être considérée comme fiable. Dans ce cadre, Squid peut assumer cette fonction. Mais dans le cas du passage par un proxy « involontaire » (proxy transparent), le client ne sait pas qu'il passe par un tel dispositif, son navigateur n'est pas paramétré pour s'adresser à un serveur proxy, le trafic est dérouté de façon « transparente ». Dans une telle situation, la démarche deviendrait malhonnête, à supposer qu'il soit possible de le faire de façon fonctionnelle.