SquidGuard

Installation

Autant il est simple de mettre en service une configuration minimale de Squid opérationnelle, autant squidGuard va nécessiter un travail méticuleux et délicat. Vous voilà prévenu…

Installer squidGuard depuis les paquetages Debian

# aptitude install squidguard
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Lecture de l'information d'état étendu       
Initialisation de l'état des paquets... Fait
Lecture des descriptions de tâches... Fait  
Les NOUVEAUX paquets suivants vont être installés : 
  libcompress-raw-zlib-perl{a} libcompress-zlib-perl{a} libfont-afm-perl{a} libhtml-format-perl{a} libhtml-parser-perl{a} 
  libhtml-tagset-perl{a} libhtml-tree-perl{a} libio-compress-base-perl{a} libio-compress-zlib-perl{a} libmailtools-perl{a} 
  libtimedate-perl{a} liburi-perl{a} libwww-perl{a} squidguard 
0 paquets mis à jour, 14 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 0o/1430ko d'archives. Après dépaquetage, 4633ko seront utilisés.
Voulez-vous continuer ? [Y/n/?] 

Pas de soucis particuliers pour cette installation.

Un premier point sur la situation

Voyons ce que squidGuard nous a installé :

# dpkg -L squidguard
/.
/var
/var/lib
/var/lib/squidguard
/var/lib/squidguard/db
/var/lib/squidguard/squidGuardRobot
/var/log
/var/log/squid
/usr
/usr/bin
/usr/bin/squidGuard
/usr/bin/sgclean
/usr/bin/hostbyname
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/squidguard
/usr/share/doc
/usr/share/doc/squidguard
/usr/share/doc/squidguard/README
/usr/share/doc/squidguard/README.Debian
/usr/share/doc/squidguard/copyright
/usr/share/doc/squidguard/examples
/usr/share/doc/squidguard/examples/RobotUserAgent.pm
/usr/share/doc/squidguard/examples/squidGuard-simple.cgi.gz
/usr/share/doc/squidguard/examples/squidGuard.cgi.gz
/usr/share/doc/squidguard/examples/squidGuardRobot.gz
/usr/share/doc/squidguard/examples/squidGuardRobot.in.gz
/usr/share/doc/squidguard/doc
/usr/share/doc/squidguard/doc/squidGuard.gif
/usr/share/doc/squidguard/doc/configuration.html
/usr/share/doc/squidguard/doc/faq.html
/usr/share/doc/squidguard/doc/index.html
/usr/share/doc/squidguard/doc/installation.html
/usr/share/doc/squidguard/doc/configuration.txt.gz
/usr/share/doc/squidguard/doc/faq.txt.gz
/usr/share/doc/squidguard/doc/installation.txt.gz
/usr/share/doc/squidguard/changelog.Debian.gz
/usr/share/doc/squidguard/NEWS.Debian.gz
/usr/share/doc/squidguard/changelog.gz
/usr/share/doc/squidguard/ANNOUNCE.gz
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/hostbyname.1.gz
/usr/share/man/man1/sgclean.1.gz
/usr/share/man/man1/squidGuard.1.gz
/usr/share/man/man1/update-squidguard.1.gz
/usr/sbin
/usr/sbin/update-squidguard
/etc
/etc/squid
/etc/squid/squidGuard.conf
/usr/share/doc/squidguard/README.html
/usr/share/doc/squidguard/FAQ.html
/usr/share/doc/squidguard/CONFIGURATION.html
/usr/share/doc/squidguard/CONFIGURATION.gz
/usr/share/doc/squidguard/FAQ.gz

L'installation a créé un répertoire /var/lib/squidguard/db, mais il est vide. Il est destiné à contenir nos listes noires et blanches et deux scripts cgi dont nous verrons l'utilité plus tard.

Elle a également créé un fichier de configuration /etc/squid/squidGuard.conf. Voyons un peu :

# cat /etc/squid/squidGuard.conf
#
# CONFIG FILE FOR SQUIDGUARD
#

dbhome /var/lib/squidguard/db
logdir /var/log/squid

Il faut indiquer à squidGuard où trouver la base de données des listes (que nous n'avons pas encore), ainsi que l'endroit où l'on désire récupérer les logs.

#
# TIME RULES:
# abbrev for weekdays:
# s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat

time workhours {
        weekly mtwhf 08:00 - 16:30
        date *-*-01  08:00 - 16:30
}

SquidGuard sait autoriser ou non l'accès en fonction de plages horaires, si nécessaire. Si des plages horaires sont définies, nous pourrons écrire des règles d'accès spécifiques dans les plages et hors des plages. Par exemple, nous pouvons autoriser un accès plus ou moins restreint tous les soirs entre 18h et 20h dans la semaine et entre 10h et 20h les samedis et dimanche, et tout bloquer en dehors de ces plages, mais pour certains utilisateurs seulement.

#
# REWRITE RULES:
#

#rew dmz {
#       s@://admin/@://admin.foo.bar.no/@i
#       s@://foo.bar.no/@://www.foo.bar.no/@i
#}

SquidGuard sait, à la volée, modifier les URL demandées par les clients dans certaines conditions. Ce n'est probablement pas une fonction primordiale.

#
# SOURCE ADDRESSES:
#

#src admin {
#       ip              1.2.3.4 1.2.3.5
#       user            root foo bar
#       within          workhours
#}

#src foo-clients {
#       ip              172.16.2.32-172.16.2.100 172.16.2.100 172.16.2.200
#}

#src bar-clients {
#       ip              172.16.4.0/26
#}

Les sources sont là pour définir des groupes de clients. Les sources définies par des adresses IP sont les plus simples à mettre en place. Lorsque l'identification des clients est requise, il devient également possible de définir des noms d'utilisateurs dans les sources.

#
# DESTINATION CLASSES:
#dest good {
}

dest local {
}

#dest adult {
#       domainlist      adult/domains
#       urllist         adult/urls
#       expressionlist  adult/expressions
#       redirect        http://admin.foo.bar.no/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
#}

Les destinations, comme leur nom l'indique, définissent des ensembles de domaines, d'URL ou d'expressions régulières à appliquer aux URLs.

acl {
#       admin {
#               pass     any
#       }

#       foo-clients within workhours {
#               pass     good !in-addr !adult any
#       } else {
#               pass any
#       }

#       bar-clients {
#               pass    local none
#       }

        default {
                pass     local none
#               rewrite  dmz
#               redirect http://admin.foo.bar.no/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
}

Enfin, les acls permettent de définir quelle source peut aller (ou ne pas aller) vers quelle(s) destination(s). Un « ! » veut dire « NOT » (non). Dans cet exemple :

  • les sources foo-clients, pendant les heures de travail, pourront accéder aux destination good, ne pourront pas accéder aux destinations in-addr ni aux destinations adult. Le any final ne semble pas nécessaire, mais il précise que toutes les autres destinations sont possibles ;
  • les sources bar-clients ne pourront accéder qu'à la destination local. Ici, le none final est important, car il bloquera toutes les autres destinations ;
  • la source default s'applique à tous les clients qui ne font pas l'objet d'une acl particulière.

A première vue, c'est assez compliqué. Nous verrons que ça l'est vraiment.

Le redirect permet, lorsqu'une destination n'est pas autorisée, de servir au client une page explicative. Les scripts cgi fournis avec squidGuard nous serviront ici.

Une première configuration

Nous n'avons pas encore les moyens de travailler efficacement, nous n'avons pas encore de base de données de destinations, mais nous pouvons déjà écrire un fichier de configuration pour squidGuard, pour nous mettre un peu dans le bain.

Notez que, squid3 ou squid, peu importe, squidguard est compilé pour trouver sa configuration dans /etc/squid/squidGuard.conf, même si nous verrons qu'au moment de s'en servir avec squid, il est possible de lui indiquer un autre fichier.

Pour éviter de perdre beaucoup de temps par la suite, à comprendre pourquoi des choses ne fonctionnent pas comme elles le devraient d'après les docs, autant construire notre configuration là où c'est prévu.

Un squidGuard.conf minimum

Seul la machine de l'admin pourra aller n'importe où, touts les autres hôtes du réseau resteront bloqués :

dbhome /var/lib/squidguard/db
logdir /var/log/squid
  
src admin {
        ip              192.168.0.10
}

acl {
        admin {
                pass     any
        }

        default {
                pass      none
                redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
        }
}

Notez l'emplacement des logs de squidGuard. Vous pouvez bien entendu les placer ailleurs. Pensez à vérifier que l'utilisateur proxy a accès en écriture là où vous voulez placer ces logs.

Il faut maintenant placer le script cgi sur notre apache :

# gunzip /usr/share/doc/squidguard/examples/squidGuard.cgi.gz
# mv /usr/share/doc/squidguard/examples/squidGuard.cgi /usr/lib/cgi-bin/
# chmod +x /usr/lib/cgi-bin/squidGuard.cgi

Enfin, il faut configurer squid3 pour qu'il invoque squidGuard en ajoutant ces lignes à la fin de /etc/squid3/squid.conf :

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
url_rewrite_children 5

Et demander à squid de recharger sa configuration :

# /etc/init.d/squid3 reload

Nous pouvons vérifier que la modification a bien été prise en compte :

# ps aux | grep squid
root      2154  0.0  0.3   6052  1564 ?        Ss   13:42   0:00 /usr/sbin/squid3 -D -sYC
proxy     2156  0.0  1.3  10036  7120 ?        S    13:42   0:00 (squid) -D -sYC
proxy     6669  0.0  0.1   2648   704 ?        S    16:33   0:00 (squidGuard) -c /etc/squid/squidGuard.conf
proxy     6670  0.0  0.1   2644   708 ?        S    16:33   0:00 (squidGuard) -c /etc/squid/squidGuard.conf
proxy     6671  0.0  0.1   2644   708 ?        S    16:33   0:00 (squidGuard) -c /etc/squid/squidGuard.conf
proxy     6672  0.0  0.1   2648   712 ?        S    16:33   0:00 (squidGuard) -c /etc/squid/squidGuard.conf
proxy     6673  0.0  0.1   2644   704 ?        S    16:33   0:00 (squidGuard) -c /etc/squid/squidGuard.conf
...

Un petit test avec une machine dont l'adresse IP n'est pas 192.168.0.10 :

Ce n'est pas très joli, il manque des informations que nous pourrions avoir, mais le résultat est là, nous sommes bien bloqué. En revanche, nous passerons sur la machine dont l'adresse IP est 192.168.0.10.

Configuration des destinations

Fort heureusement, un ensemble de destinations est activement maintenu par le Centre de Ressources Informatiques de l'Université de Toulouse, que nous trouvons ici : ftp://ftp.univ-tlse1.fr/blacklist/ , vous trouverez les destinations qui vous intéressent plus particulièrement, mais nous allons choisir l'archive qui les contient toutes : ftp://ftp.univ-tlse1.fr/blacklist/blacklists.tar.gz et les installer là où c'est prévu, dans /var/lib/squidguard/db.

cd /var/lib/squidguard/db/
wget ftp://ftp.univ-tlse1.fr/blacklist/blacklists.tar.gz
tar xzf blacklists.tar.gz
cd blacklists

Nous avons toutes les destinations souhaitables :

ls -l | awk '{ print $8, $9, $10 }'

ads -> publicite
adult
aggressive -> agressif
agressif
astrology
audio-video
blog
cleaning
dangerous_material
dating
drogue
drugs -> drogue
filehosting
financial
forums
gambling
games
global_usage
hacking
liste_bu
mail -> forums
marketingware
mixed_adult
mobile-phone
phishing
porn -> adult
proxy -> redirector
publicite
radio
README
reaffected
redirector
sect
sexual_education
shopping
strict_redirector
strong_redirector
tricheur
violence -> agressif
warez
webmail

Notez la présence de certains alias.

Le fichier « global_usage » n'est pas une liste de destinations, mais un fichier explicatif sur le contenu de cette archive.

Avant d'oublier ce détail majeur, tout le contenu de /var/lib/squidguard/db/blacklists doit être accessible en lecture et en écriture par l'utilisateur sous l'identité duquel squid tourne. Pour nous, c'est l'utilisateur « proxy » :

cd /var/lib/squidguard/db/
chown -R proxy:proxy blacklists

Nous devons maintenant créer un fichier de configuration pour squidGuard, qui tienne compte de quelques unes de ces destinations. Par exemple : porn, drugs, phishing, marketingware

Création des destinations

Allons voir ce qu'il y a dans ces divers sous-répertoires. Le répertoire porn est sans doute le plus intéressant :

  • domains contient une liste de domaines à interdire ;
  • expressions est vide ;
  • nurls contient des URLs ;
  • urls contient également des URLs ;
  • usage indique la nature de cette destination (liste noire, pornographie) ;
  • very_restrictive_expression contient quelques expressions régulières bien senties (attention aux ressources consommées par ces expressions).

Dans squidGuard.conf, nous allons tenir compte de ces divers sous-répertoires :

dest pornographie {
        urllist         porn/urls
        urllist         porn/nurls
        domainlist      porn/domains
        expressionlist  porn/very_restrictive_expression
}

Notez que le nom de la destination n'est pas forcément le même que celui utilisé dans les listes. Résistez cependant à la tentation :

  • de placer des lettres accentuées dans les noms des destinations, squidGuard ne saura les interpréter ;
  • de placer des espaces dans ces noms, squidGuard ne les interprètera pas non plus.

Vous avez compris le principe ? Voici un fichier de configuration qui devrait faire l'affaire, dans un premier temps :

dbhome /var/lib/squidguard/db/blacklists
logdir /var/log/squid

src admin {
        ip              192.168.0.10
}

src users {
        ip              192.168.0.0/24
}

dest pornographie {
        urllist         porn/urls
        urllist         porn/nurls
        domainlist      porn/domains
        expressionlist  porn/very_restrictive_expression
}

dest drogues {
        urllist         drugs/urls
        domainlist      drugs/domains
}

dest phishing {
        urllist         phishing/urls
        domainlist      phishing/domains
}

dest marchands_de_guerre {
        urllist         marketingware/urls
        domainlist      marketingware/domains
}

acl {
        admin {
                pass     any
          }

        users {
                pass !pornographie !drogues !phishing !marchands_de_guerre any
                redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&clientname=%n&clientident=%i&srcclass=%s&targetclass=%t&url=%u
        }

        default {
                pass      none
                redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&clientname=%n&clientident=%i&srcclass=%s&targetclass=%t&url=%u
        }
}

Notez l'acl pour les « users », ce sont bien les noms des destinations qu'il faut utiliser et non pas les noms des répertoires dans la base de données.

Attention...

Bon gros avertissement…

Faites très attention à ce que vous écrivez dans ce fichier de configuration, les fautes de frappe sont très vite arrivées, les copier/coller peuvent entraîner des oublis, certains répertoires de listes contiennent des domaines, des urls, des expressions, d'autres non. Il faut être très minutieux dans cette écriture, les causes d'erreurs sont très nombreuses ! (Vous voilà prévenus).

Il existe cependant, comme nous allons le voir, un moyen de vérifier qu'il n'y a pas d'erreurs. En effet, ce n'est pas parce que le le fichier de configuration est rédigé que le travail est terminé. SquidGuard, pour pouvoir travailler rapidement, n'utilise pas les fichiers texte, mais des bases de données au format Berkeley. Il est vivement conseillé de construire ces bases avant le démarrage de squid (et donc de squidGuard), faute de quoi, ces bases seront construites à la volée, pour chaque instance de squidGuard. Nous en avons ici 5, mais pour un gros site, 20 à 25 peut être plus adapté. Dans de telles conditions, le démarrage peut largement dépasser le quart d'heure !

La commande squidGuard -C all va permettre de construire ces bases de données sur disque, et squidGuard les utilisera alors au démarrage, ce qui fera gagner énormément de temps.

su proxy
squidGuard -C all

Et nous en profitons pour aller voir le fichier de logs de squidGuard :

tail -f /var/log/squid/squidGuard.log
2007-06-07 18:14:54 [6815] init urllist /var/lib/squidguard/db/blacklists/porn/urls
2007-06-07 18:14:55 [6815] create new dbfile /var/lib/squidguard/db/blacklists/porn/urls.db
2007-06-07 18:14:55 [6815] init urllist /var/lib/squidguard/db/blacklists/porn/nurls
2007-06-07 18:14:56 [6815] create new dbfile /var/lib/squidguard/db/blacklists/porn/nurls.db
2007-06-07 18:14:56 [6815] init domainlist /var/lib/squidguard/db/blacklists/porn/domains
2007-06-07 18:15:43 [6815] create new dbfile /var/lib/squidguard/db/blacklists/porn/domains.db
2007-06-07 18:15:45 [6815] init expressionlist /var/lib/squidguard/db/blacklists/porn/very_restrictive_expression
2007-06-07 18:15:45 [6815] init urllist /var/lib/squidguard/db/blacklists/drugs/urls
2007-06-07 18:15:45 [6815] create new dbfile /var/lib/squidguard/db/blacklists/drugs/urls.db
2007-06-07 18:15:45 [6815] init domainlist /var/lib/squidguard/db/blacklists/drugs/domains
2007-06-07 18:15:45 [6815] create new dbfile /var/lib/squidguard/db/blacklists/drugs/domains.db
2007-06-07 18:15:45 [6815] init urllist /var/lib/squidguard/db/blacklists/phishing/urls
2007-06-07 18:15:45 [6815] urllist empty, removed from memory
2007-06-07 18:15:45 [6815] init domainlist /var/lib/squidguard/db/blacklists/phishing/domains
2007-06-07 18:15:45 [6815] create new dbfile /var/lib/squidguard/db/blacklists/phishing/domains.db
2007-06-07 18:15:45 [6815] init urllist /var/lib/squidguard/db/blacklists/marketingware/urls
2007-06-07 18:15:45 [6815] urllist empty, removed from memory
2007-06-07 18:15:45 [6815] init domainlist /var/lib/squidguard/db/blacklists/marketingware/domains
2007-06-07 18:15:45 [6815] create new dbfile /var/lib/squidguard/db/blacklists/marketingware/domains.db
2007-06-07 18:15:45 [6815] squidGuard 1.2.0 started (1181232894.801)
2007-06-07 18:15:45 [6815] db update done
2007-06-07 18:15:45 [6815] squidGuard stopped (1181232945.727)

Vous devriez pouvoir repérer toute erreur dans ces logs.

Un second point sur la situation

  • Il est donc nécessaire de porter une grande attention à la rédaction du fichier de configuration ;
  • il est également nécessaire de construire les bases de données berkeley après avoir écrit le fichier de configuration, car seules les destinations définies dans ce fichier seront compilées (vous trouverez des fichiers domains.db et urls.db dans les destinations utilisées). Autrement dit, si vous devez ajouter une configuration par la suite, il faudra penser à la compiler ;
  • squidGuard -C all part du principe que le fichier de configuration de squidGuard se trouve (pour Debian) dans /etc/squid/. Si vous voulez à tout prix placer sa configuration ailleurs, il vous faudra utiliser l'option -c : squidGuard -c /etc/squid3/squidGueard.conf -C all par exemple ;
  • le fichier de logs de squidGuard est d'un grand secours pour cette opération, car il avertira de tout problème de configuration.

La commande squidGuard sait également faire quelques autres choses (man squidguard :-P)

Mais nous sommes encore très loin du compte…

Attention...

Puisqu'on n'est pas là pour réaliser une passoire, signalons tout de même ceci :

squidQuard redirige les URI interdits vers un URI local, généralement destiné à expliquer pourquoi le site convoité a été bloqué. Généralement, il s'agit d'un script CGI.

Si cet URI de redirection n'est pas indiqué, ne sachant pas où rediriger les requêtes interdites, squidGuard les laissera tout de même passer, réalisant ainsi une pernicieuse passoire !!!

Il est donc impératif d'installer un tel script ou, à défaut, une page d'avertissement quelconque vers laquelle rediriger les URI interdits.

Le paquetage Debian de squidGuard n'installe rien à ce propos, mais vous trouverez dans /usr/share/doc/squidguard/examples deux scripts dont vous pourrez vous inspirer ou essayer d'utiliser en l'état (après les avoir installés dans /usr/lib/cgi-bin et rendus exécutables).

Mais ce n'est pas tout, il vous faudra aussi revenir sur l'ACL Default, pour spécifier la redirection :

  http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
Cette ligne part du principe que vous avez sur la machine locale un serveur HTTP en état de marche et qu'il dispose d'un script squidGuard.cgi. Les paramètres transmis dans cet exemple permettent de communiquer au script toutes les informations nécessaires pour identifier les circonstances du blocage.

Bien entendu, ce script, ou un autre (page php comprise) peuvent être situés sur une machine autre, il suffit de rédiger l'URI de redirection en fonction.