Squid et SquidGuard
Vous trouverez ici un strict minimum, pour une installation de squid sous Mandrake. Pour plus de détails, consultez le chapitre dédié à ces logiciels
Installation et paramétrage
Nous utilisons, comme d'habitude, une distribution Mandrake, mais les paquetages doivent exister pour toutes les distributions majeures de Linux. Un seul paquetage est nécessaire.
SQUID est un serveur proxy très sophistiqué, capable, entre autres, de construire des "tableaux de proxys", d'accepter des "plug-ins" pour le filtrage et le contrôle d'accès, SQUIDGUARD étant le plus connu. Il existe également des outils d'audit qui permettent d'extraire pas mal de statistiques intéressantes sur l'emploi du proxy. Si nous reprenons notre exemple d'un réseau scolaire, ça permet de se faire une idée relativement précise (et parfois instructive) des centres d'intérêts des élèves...
L'objectif n'est pas ici d'étudier en détail toutes les possibilités de SQUID. Nous nous arrêterons à une procédure minimaliste, permettant d'exploiter SQUID de façon basique.
Pour l'installation
Installer le paquetage squid (squid-2.4.STABLE4-2mdk dans l'exemple) avec l'outil de votre choix. Depuis la version 8.2, le "software manager" en mode graphique commence à devenir tout à fait exploitable, mais vous pouvez aussi utiliser la commande "urpmi" dans une console (software manager n'est qu'une interface graphique appliquée à urpmi). Plus rudimentairement, vous pouvez utiliser l'ancien gestionnaire de paquetages graphique "kPackage", ou la commande "rpm"
Vérifiez que le daemon squid sera bien lancé au démarrage, par exemple avec le "Mandrake Control Center" (toujours depuis la version 8.x), ou avec des moyens plus traditionnels.
Pour le paramétrage
SQUID s'appuie essentiellement sur le fichier /etc/squid/squid.conf. Le moyen le plus simple pour modifier la configuration par défaut (qui ne fonctionnera d'ailleurs pas telle qu'elle), est probablement d'utiliser webmin. Rien ne vous interdit cependant de modifier squid.conf avec votre éditeur de texte favori. Pour le peu qu'il y a à faire pour démarrer SQUID, nous utiliserons cette méthode.
Pour une configuration minimale, qui permettra juste à votre réseau local de passer le proxy, il n'y a que deux lignes à rajouter dans le fichier de configuration :
- Une ligne d'ACL (Access Control List) qui va définir votre réseau local :
acl localnet src 192.168.0.0/255.255.255.0
Cette ligne signifie :- Une acl nommée "localnet"
- Définit toute la classe IP 192.168.0.0. (Adresse du réseau/masque de sous réseau). Bien entendu, la plage IP est à ajuster en fonction de la cartographie IP de votre réseau.
Cette ligne est à ajouter à la suite des acl déjà existantes
(Vous voyez déjà apparaître la possibilité de filtrer l'accès à partir des IPs...).
- Une ligne de règle d'accès
http_access allow localnet
Cette ligne est à ajouter juste en dessous de la ligne "http_access allow localhost" et juste avant "http_access deny all".
Relancez squid après chaque modification de configuration par /etc/init.d/squid restart.
Cette modification mineure devrait suffire à permettre l'usage de SQUID depuis tous les postes de votre réseau local.
Pour une configuration plus fine, il vous faudra plonger dans les documentations relatives à SQUID :
L'interface "webmin" est aussi très utile, puisqu'elle vous permettra de gérer votre proxy depuis n'importe quel poste de votre réseau local via votre navigateur favori. Le module de gestion de SQUID est assez complet pour être efficace dans la plupart des cas.
Inconvénient d'une solution "simple"
- Comme nous l'avons dit, un proxy comme SQUID pourra vous assurer le HTTP et le FTP, pas les autres protocoles comme POP3. Il est donc souvent mis en oeuvre un routeur NAT en plus. Dans ce cas, si vous voulez forcer vos clients à passer par le proxy, pensez à bloquer le trafic HTTP au niveau du NAT.
- L'usage d'un proxy nécessite le paramétrage des clients. Cette opération peut être lourde sur un gros réseau et vos utilisateurs peuvent aller "bricoler" dessus. Si le réseau est un domaine Microsoft (NT4 ou 2000), vous avez toujours la possibilité d'exploiter les "policies" pour paramétrer vos clients à distance. Cette solution vous assurera un paramétrage "propre" d'Internet Explorer à chaque ouverture de session sur les clients, mais ça n'empêchera pas vos utilisateurs de modifier en cours de session.
La parade ultime
Moyennant quelques efforts, vous pouvez user de netfilter conjointement avec SQUID pour réaliser un "proxy transparent". C'est la pire saleté qui existe, puisque, dans ce cas, le client va obligatoirement passer par le proxy, qu'il le veuille ou non, qu'il le sache ou non...
Ce qu'il se passe en réalité, c'est que le client n'a pas besoin d'être paramétré pour utiliser le proxy. Il va faire une requête directe sur le serveur source. Mais, au passage du routeur NAT, celui-ci va intercepter les requêtes HTTP et les transmettre "de force" au proxy. Le client n'y voit que du feu. Cette méthode, que je trouve inacceptable de la part d'un fournisseur d'accès, peut être tolérable sur un réseau d'entreprise. Elle n'affecte qu'un faible nombre de clients, qui peuvent (et doivent) en être avertis et savent à qui s'adresser s'ils rencontrent des dysfonctionnements.
Pour sombrer encore un peu plus dans les atteintes à la liberté et à l'égalité, vous pouvez même réserver un "régime de faveur" à certains postes qui conserveront le droit de passer directement par le NAT (vos chefs en général et la direction de l'établissement en particulier, votre poste personnel..)
Surveillance
Il existe pas mal d'outils pour surveiller et affiner le fonctionnement de SQUID. L'outil de base étant le fichier de logs qui est, sur la distribution Mandrake, /var/log/squid/access.log
Méfiez-vous de la taille que peut prendre ce fichier, suivant l'activité déployée par le réseau local sur le Net...
- Assurez-vous que les fichiers de logs de squid sont bien archivés par logrotate : Vous devez trouver, toujours pour Mandrake, un fichier /etc/logrotate.d/squid
- Assurez-vous que vous ne risquez pas de saturer la partition contenant les logs. C'est une bonne habitude que de monter /var/log sur une partition dédiée (/var à défaut).
Filtrage des accès
Vous pouvez installer le "plug-in" SQUIDGUARD, lui aussi administrable via webmin, qui vous permettra d'ajouter pas mal de possibilités de contrôle d'accès. Attention tout de même que le couple SQUID/SQUIDGUARD consomme nettement plus de ressources qu'un simple routeur NAT... Prévoyez une machine en conséquence.
A titre d'exemple, un P200 avec 128 Mo de RAM et une partition de 5 Go pour le cache de SQUID semble suffire largement pour un réseau local de 50 postes.
Conclusion
Cette page n'a pas la prétention de vous mener très loin dans l'utilisation de Squid et de SquidGuard. Vous trouverez plus de détails dans le chapitre qui leur est dédié.