 | Présentation de Squid |  |
|---|---|---|
| Prev | Chapter 1. Présentation | Next |
Squid est un serveur proxy/cache libre très connu du monde Open Source.
Ce serveur est très complet et propose une multitude d'options et de services qui lui ont permis d'être très largement adopté par les professionnels mais aussi dans un grand nombre d'école ou administrations travaillant avec systèmes de type Unix.
Squid est capable de relayer les protocoles HTTP, FTP, SSL et Gopher. Le protocole Socks, lui, n'est pas supporté par Squid actuellement.
Mis à part les fonctions essentielles d'un proxy, Squid propose beaucoup d'autres services. Ces services ont très largement contribué à faire de Squid une référence en matière de proxy dans le monde des serveurs de type Unix. Nous aurons le loisir de parcourir rapidement dans les prochains chapitres les étapes de configuration de Squid pour profiter de ces services.
Nous verrons plus loin de ce même document que Squid peu produire différents type de log selon son mode de fonctionnement,
Le cache est bien plus qu'un service rendu par Squid à vrai dire. Il fait partie intégrante de Squid [1] et justifie à lui seul l'utilisation de Squid pour un réseau partageant un même accès à Internet.
Le rôle d'un serveur cache est de stocker les objets demandé par les utilisateurs pour la première fois via les protocoles HTTP, FTP et Gopher. Ainsi, lors des demandes futures sur un objet présent en cache, le serveur de cache n'aura pas besoin d'aller chercher cet objet sur internet et retournera directement celui qu'il a en mémoire. Les objets stocké peuvent être de tout type : texte, image, vidéo, ...
Ce mécanisme procure deux grands avantages non négligeables:
Une économie de bande passante d'autant plus grande que le volume de données représentée par l'objet. Le nombre de requête qui pourront être détournées vers le cache dépend de plusieurs paramètres comme la durée d'activité du cache, la durée de vie des objets dans le cache, le nombre de clients et de requêtes sur le réseau, etc [2].
Un gain de temps pour les utilisateurs internet. Effectivement lorsque le cache prend en charge une requête, le délais d'accès à un objet devient celui de la recherche de cet objet dans le cache + les temps d'accès réseau.
Example 1.1. Exemple d'utilisation d'un cache
Voici un exemple mettant en évidence l'activité d'une cache. Un proxy Squid tourne sur ma machine en local avec le service de cache activé. La connection au proxy se fait via l'adresse 127.0.0.1:3128. Je crée dans ma console la variable d'environnement http_proxy qui défini le proxy que mon terminal devra utiliser pour ses requêtes http :
Ensuite, je télécharge un objet sur internet :
Nous pouvons constater que le téléchargement à pris 28 seconde pour 2,4M de donnée. Maintenant, voyons ce qu'il se passe si je relance le même téléchargement (l'option -O ne sert qu'a changer le nom du fichier sauvegardé) :
Ici, le téléchargement n'a pris qu'une seconde (mais en fait, beaucoup moins en direct ;)) !
Dans cette exemple, le cache à clairement intercepté la demande http pour retourner l'objet demandé qu'il avait précédemment enregistré.
Squid supporte beaucoup de protocoles liés aux caches: ICP, HTCP, CARP, Cache Digests, WCCP[3]. Ces protocoles permettent les échanges entre les différents caches et ainsi favoriser les flux de données les plus proche du site plutôt que de solliciter un serveur qui sera peut-être plus éloigné et plus lent à répondre qu'un serveur cache.
Notons que le système de cache de Squid est disponible en mode proxy et transparent.
En plus d'implémenter un cache d'objets, Squid est capable de gérer un cache DNS. Ainsi, gardera en mémoires les association nom/adresse IP.
Dans ce mode, Squid est capable de se substituer à un serveur http, il fonctionne alors en "reverse proxying". Il ne sert donc plus à partager "le monde" pour un réseau, mais à partager une machine (ou plusieurs) "au monde". Ainsi, les clients n'accéderons plus au serveur http, mais à Squid. Dans une configuration classique, Squid devra donc écouter sur le port 80 et avoir connaissance du serveur http qu'il remplace.
Tout l'intérêt de ce service repose sur le cache de Squid. Effectivement, une fois que celui-ci aura enregistré tous les objets possible du serveur http, la plupart des requêtes des clients seront alors traitées par Squid. Ainsi, le serveur http sera beaucoup moins sollicité. Par cette méthode, le serveur web ne sert plus alors qu'a traiter les pages dynamiques, CGI, enregistrement de formulaire, etc.
Il est possible de multiplier les "proxy accelerator" en les faisant communiquer via ICP. Cela permet encore d'augmenter la rapidité de réponse et le backup des données.
Squid permet d'authentifier les clients avant qu'ils accèdent à la ressource qu'ils demandent. L'authentification marche pour les modes proxy et "httpd accelerator". Il devient alors de plus en plus avantageux d'utiliser Squid en frontale d'un serveur web car ce dernier n'aura à assumer que les rôles primordiaux de service web dynamique.
Voici une liste non exhaustive des quelques principaux protocoles supportés par Squid :
Basic : Les associations profiles/mots de passe sont stockés dans un fichier. Les mots de passe sont crypté par la fonction crypt() dans le fichier. L'authentification circule en clair sur le réseau, les mots de passe étant codé en base64. Ce format d'authentification est un classique pour les proxy et utilise le même type de fichier qu'Apache? Sa partie réseau en revanche n'est en aucun cas sécurisée;
Digest : Identique à la première méthode, mais les mots de passe sont crypté par la méthode digest avant d'être émis sur le réseau ;
LDAP : Permet d'utiliser un serveur LDAP en pour authentifier les utilisateurs ;
NTLM : Permet d'authentifier l'utilisateur en utilisant le protocole de Microsoft NTLM. Les serveur supporté sont samba, Windows NT et Windows 2000;
L'authentification est réalisée via des exécutable externe à Squid, chaque protocole d'authentification ayant son propre exécutable. Ces programmes authentifiant ont un format d'utilisation très simple : ils lisent sur STDIN les informations d'authentification sous la forme "login motDePasse" et retourne sur STDOUT "OK" ou "ERR" en fonction que les information soient juste ou pas.
Squid offre la possibilité de filtrer les requêtes des clients. Ainsi, il est possible de restreindre l'accès aux ressources en fonction de plusieurs paramètres différents. Voici une liste de paramètre pouvant intervenir dans le rejet d'une requête répondant à l'un des critère :
L'URL contient un mot interdit. Cela permet de rejeter toute url contenant "winnie" par exemple ;
L'adresse IP source/destinataire est interdite ;
Le domaine de source/destination est interdit ou contient un mot interdit ;
La date de la demande. Par exemple, Squid peut interdire l'accès à Internet durant certaines heures (comme le soir entre 20h et 6h du matin) ;
Le port de destination ;
Le protocole utilisé. Peut permettre de bloquer les transferts FTP par exemple ;
La méthode utilisée. Peut permettre d'empêcher les méthode HTTP comme POST par exemple ;
Le type du navigateur utilisé. Peut permettre d'empêcher l'utilisation d'IE par exemple.
Ce filtrage est basé sur des ACL. Nous verrons plus loin plusieurs exemple d'utilisation des ACL. Squid n'est capable de filtrer que les requêtes de ses clients, pas le contenu de ce qu'il relaye à ceux-ci (bien qu'un proxy filtrant le contenu de page revient à multiplier la charge d'administration par le nombre d'interdiction malencontreuse).
Attention, le filtrage peut consommer beaucoup de ressource si le proxy est fortement sollicité. Squidguard est un logiciel libre externe à Squid qui permet aussi de restreindre l'accès aux ressources demandée par Squid.
Il est possible de réécrire les entêtes des requêtes des clients. Cela a pour utilité par exemple de rendre les demandes anonyme. Ceci se fait très simplement en indiquant dans la configuration de Squid quels sont les champs HTTP autorisé et en précisant que tous les autres ne le sont pas. Il est aussi possible de remplacer le contenu d'un champs. Nous verrons plus loin comment mettre en place ce type de filtrage.
Squid offre la possibilité d'être monitoré à distance via SNMP. Ainsi, les données collectées via ce protocole pourront permettre à l'administrateur de visualiser l'état courant de son proxy, d'avoir des statistiques d'utilisation, des statistique sur le cache, sur le temps processeur consommé, etc...
MRTG est un outils bien connus aussi qui peut permettre à l'administrateur de construire des pages web sur les statistiques qu'il désire voir. MRTG est un logiciel libre et puissant. C'est l'outil idéal à associer avec Squid[2]. Il existe de nombreuse documentation à ce sujet.
[1] Nous verrons que certain services sont "externe" à Squid.
[2] A titre d'exemple, voici quelques statistiques issues du proxy Squid de l'Académie de Nancy :
[3] Dont voici les RFC : ICP (Internet cache protocole, protocole de communication inter-cache), HTCP (Hyper Text Caching Protocol, protocole de management de cache), CARP (Cache Array Routing Protocol), Cache digest, WCCP (Web Cache Control Protocol, redirection de trafic depuis un router vers un proxy).
