+ sur SquidGuard

Il n'est absolument pas question de critiquer le travail fourni par l'Université de Toulouse, mais les listes que nous utilisons ici comportent quelques défauts :

• elles référencent des sites ou des sous-sites que ne devraient pas forcément l'être. Les robots qui cherchent des mots-clés peuvent en trouver sur des pages anodines ;
• elles ne référencent pas des sites qui devraient l'être. L'internet est un monde mouvant où rien n'est écrit dans le marbre.

Ne vous attendez donc pas à un filtrage parfait. Vous aurez sans doute des appels de vos utilisateurs qui se plaindront de ne pouvoir accéder à des pages parfaitement acceptables, de même qu'il vous faudra surveiller que des pages indésirables ne passent pas à travers votre filtrage.

Les listes publiées par l'Université de Toulouse sont régulièrement mises à jour, à vous de suivre leurs évolutions.

Il y a deux stratégies de base, dans tout mode de contrôle d'accès :

Ici, nous interdisons tous les sites à priori, et utilisons alors des « listes blanches » qui contiendront les seules destinations autorisées. Cette méthode, très totalitaire, peut tout de même être envisagée dans certains cas. Très peu de destinations seront accessibles, mais vous les aurez choisies avec soin

Il vous faudra construire ces listes blanches et écrire des acls du genre :

 pass liste_1 liste_2  liste_3 none

où liste_1, liste_2 et liste_3 sont vos listes blanches. Elles se construisent exactement comme une liste noire.

Ici, nous utilisons bien les listes noires, comme vu plus haut, avec les risques que nous avons déjà évoqués. Il s'agit sans doute de ce que vous préfèrerez mettre en place dans la plupart des cas.

Si vous allez jeter un œil dans les fichiers de blacklists, vous constaterez que certains sont très volumineux (pronographie, par exemple). Il est certes possible de modifier ces fichiers en fonction de vos observations, pour retirer des destinations qui ne devraient pas être bloquées, ou ajouter des destinations manquantes. L'inconvénient de ce système est qu'il faut reconstruire l'intégralité de la base de données (.db) associée à ce fichier après chaque modification, ce qui peut prendre du temps.

Une autre méthode consiste à utiliser des fichiers de différences. Cette méthode permet des corrections rapides, mais désynchronise les bases de données et les fichiers textes. Il suffit de créer un fichier domains.diff et/ou urls.diff dans le répertoire qui contient les urls et les domaines à ajouter (mettez un + devant) ou à enlever (mettez un - devant) puis de lancer squidguard -u. Cette opération permettra rapidement de mettre à jour les fichiers .db mais ne touchera pas aux fichiers texte correspondant. Il faudra ensuite enlever les fichiers .diff crées.

Si vous adoptez cette méthode sans plus de précautions, vos sources texte ne seront rapidement plus du tout l'image des bases de données Berkeley.

Exemple d'un fichier domains.diff :

  -laposte.net
  +playboy.com

Ce fichier placé dans le répertoire porn permettra rapidement d'ajouter playboy.com et de retirer laposte.net du fichier domains.db, par la commande :

squidGuard -u

suivie de :

squid -k reconfigure

L'opération est très rapide et vos modifications resteront pérennes après mise à jour des listes noires.

Il existe plusieurs outils destinés à exploiter les logs de squid, principalement le log access.log, parmi lesquels Calamaris, Mysar (MySQL Squid Access Report), et bien d'autres encore.

Calamaris comme Mysar offrent l'avantage de permettre de découvrir facilement quels sont les sites les plus visités et donc de trouver assez simplement les fuites de votre filtrage.