Filtrer le web avec SquidGuard sous CentOS 7

Il existe une pléthore de solutions pour filtrer le Web et mettre en place une sorte de « contrôle parental » pour un réseau. La plupart de ces techniques relèvent de la catégorie farces et attrapes et se distinguent avant tout par leur inefficacité. Seule une poignée de systèmes de filtrage fonctionne de manière à peu près correcte. Parmi ces solutions, on trouve le redirecteur SquidGuard couplé au serveur proxy Squid, dont nous avons décrit la configuration en détail dans une série d’articles.

Chaque requête HTTP/HTTPS du réseau local est redirigée de façon transparente vers le serveur proxy, qui analyse une série de règles avant d’autoriser ou d’interdire la connexion. En cas de refus, c’est une page explicative qui s’affiche à l’utilisateur. Pour faire le tri, on se servira des listes fournies par le Centre de Ressources Informatiques de l’Université de Toulouse.

La page web du projet laisse à penser que SquidGuard n’est plus maintenu. Or, le développeur Debian Joachim Wiedorn a repris le flambeau, et c’est lui qui assure désormais la maintenance du code de SquidGuard.

• Installation
• La page explicative
• Récupérer les listes noires
• Sexe, drogue & rock’n’roll ?
• Automatiser la mise à jour des listes

Installation

Sous Red Hat Enterprise Linux et CentOS, SquidGuard est fourni par le dépôt de paquets EPEL.

$ sudo yum install squidGuard

La page explicative

Lorsque SquidGuard refuse l’accès à une page, c’est toujours une bonne idée d’expliquer les raisons de ce refus aux utilisateurs. Pour commencer, on va donc mettre en place une page d’avertissement, qui sera hébergée sur le serveur proxy lui-même. Voilà ce que ça donne sur ma machine.

La mise en place d’une page web locale est expliquée en détail ici.

Récupérer les listes noires

Dans la configuration par défaut, SquidGuard fournit une collection de listes sous forme d’une archive /var/squidGuard/blacklists.tar.gz. Nous utiliserons plutôt les listes fournies par l’Université de Toulouse et maintenues par Fabrice Prigent. On peut les récupérer manuellement comme ceci. L’archive compressée pèse près de 11 Mo.

$ cd /var/squidGuard
$ sudo rm blacklists.tar.gz
$ sudo wget -c ftp://ftp.ut-capitole.fr/blacklist/blacklists.tar.gz
$ sudo tar xvzf blacklists.tar.gz
$ cd blacklists

Chacun des répertoires correspond à une catégorie (ou destination) du Web.

$ ls -l | awk '{print $9, $10, $11}'
ads -> publicite
adult  
aggressive -> agressif
agressif  
arjel  
associations_religieuses  
astrology  
audio-video  
bank  
bitcoin  
blog  
cc-by-sa-4-0.pdf  
celebrity  
chat  
child  
cleaning  
cooking  
cryptojacking  
dangerous_material  
dating  
ddos  
dialer  
download  
drogue  
drugs -> drogue
educational_games  
filehosting  
financial  
forums  
gambling  
games  
global_usage  
hacking  
jobsearch  
...

On peut très bien utiliser l’outil rsync pour récupérer les listes. Cette méthode est même recommandée, étant donné que rsync ne téléchargera que la différence entre les arborescences distante et locale lors d’une mise à jour. La seule différence par rapport au téléchargement avec wget, c’est que nous retrouvons nos destinations dans un répertoire dest/ au lieu de blacklists/.

$ cd /var/squidGuard
$ sudo rm -rf blacklists*
$ sudo rsync -rv rsync://ftp.ut-capitole.fr/blacklist/ .
$ cd dest

Repérez le fichier global_usage et jetez un oeil à son contenu. Il s’agit d’un fichier explicatif sur le contenu des listes.

Sexe, drogue & rock’n’roll ?

Dans l’exemple ci-dessous, nous allons filtrer les sites à contenu potentiellement problématique (porno, violence, drogues) pour toutes les machines du réseau local.

SquidGuard se configure par le biais du fichier de configuration /etc/squid/squidGuard.conf. Pour commencer, nous allons renommer le fichier de configuration d’origine, qui pourra éventuellement nous servir de modèle pour des configurations plus élaborées.

$ cd /etc/squid
$ sudo mv squidGuard.conf squidGuard.conf.orig

Ensuite, nous allons éditer le fichier /etc/squid/squidGuard.conf comme ceci.

# /etc/squid/squidGuard.conf
dbhome /var/squidGuard/dest
logdir /var/log/squidGuard

src microlinux {
  ip 192.168.2.0/24
}

# Des sites adultes allant de l'érotique à la pornographie dure
destination adult {
  domainlist adult/domains
  urllist adult/urls
  log adult
}

# Quelques sites racistes, antisémites et incitant à la haine
destination agressif {
  domainlist agressif/domains
  urllist agressif/urls
  log agressif
}

# Drogues
destination drogue {
  domainlist drogue/domains
  urllist drogue/urls
  log drogue
}

acl {
  microlinux {
    pass !adult
    pass !agressif
    pass !drogue
    redirect 302:http://proxy.microlinux.lan/avertissement.html
  }
  default {
    pass none
    redirect 302:http://proxy.microlinux.lan/avertissement.html
  }
}

Cette configuration mérite quelques explications.

• La directive dbhome indique à SquidGuard où trouver la base de données des listes.
• La directive logdir spécifie l’endroit où l’on désire récupérer les logs.
• Les sources définissent les groupes de postes clients. Ici, la source microlinux définit toutes les machines du réseau 192.168.2.0/24.
• Les acl ou Access Control Lists permettent de définir quelle source peut ou ne peut pas aller vers quelle(s) destination(s).
• Lorsqu’une destination n’est pas autorisée, la directive redirect permet de servir une page explicative au client.

À présent, il faut configurer Squid pour qu’il utilise SquidGuard. Éditez le fichier /etc/squid/squid.conf et ajoutez ceci à la fin du fichier.

# SquidGuard
url_rewrite_program /usr/bin/squidGuard
url_rewrite_children 8

Avant d’aller plus loin, nous devons régler quelques permissions. Le proxy Squid tourne avec les droits de l’utilisateur système squid et du groupe système squid.

$ sudo chown -R squid:squid /var/squidGuard

On va également ajuster les permissions pour le répertoire des logs.

$ sudo chown -R squid:squid /var/log/squidGuard

Ce n’est pas une mauvaise idée d’aligner les permissions du fichier /etc/squid/squidGuard.conf sur celles de squid.conf.

$ sudo chown root:squid /etc/squid/squidGuard.conf
$ sudo chmod 0640 /etc/squid/squidGuard.conf

Pour pouvoir fonctionner rapidement, SquidGuard n’utilise pas les fichiers au format texte, mais des bases de données au format Berkeley. Ces bases de données n’existent pas encore, et nous devons les construire.

$ sudo squidGuard -C all

Sur mon routerboard PC Engines, ça mouline près de deux minutes, étant donné que la base de données gère quelques millions d’URLs.

Si tout s’est bien passé, on obtient quelque chose comme ceci.

$ cat /var/log/squidGuard/squidGuard.log
... New setting: dbhome: /var/squidGuard/dest
... New setting: logdir: /var/log/squidGuard
... init domainlist /var/squidGuard/dest/adult/domains
... create new dbfile /var/squidGuard/dest/adult/domains.db
... init urllist /var/squidGuard/dest/adult/urls
... create new dbfile /var/squidGuard/dest/adult/urls.db
... init domainlist /var/squidGuard/dest/agressif/domains
... create new dbfile /var/squidGuard/dest/agressif/domains.db
... init urllist /var/squidGuard/dest/agressif/urls
... create new dbfile /var/squidGuard/dest/agressif/urls.db
... init domainlist /var/squidGuard/dest/drogue/domains
... create new dbfile /var/squidGuard/dest/drogue/domains.db
... init urllist /var/squidGuard/dest/drogue/urls
... create new dbfile /var/squidGuard/dest/drogue/urls.db
... squidGuard 1.4 started (1554529650.768)
... db update done

Quelques mises en garde cruciales s’imposent ici.

• SquidGuard est une application assez pointue, pour ne pas dire une petite usine à gaz un peu capricieuse. La moindre faute de frappe dans un des fichiers de configuration se solde généralement par un échec. Il est donc nécessaire de porter une grande attention à la syntaxe.
• Les bases de données (fichiers *.db en-dessous de l’arborescence /var/squidGuard/dest/) doivent être construites après avoir écrit le fichier de configuration, car seules les destinations définies dans ce fichier seront compilées. Autrement dit, si vous devez ajouter une destination par la suite (malware, tricheur, etc.) il va falloir penser à compiler les bases de données correspondantes.
• En règle générale, ça ne fonctionne que rarement du premier coup. Dans ce cas, jetez un oeil dans les logs, notamment squidGuard.log. Ce dernier vous sera d’un grand secours, car il vous avertira de tous les problèmes de configuration.

Étant donné que la commande squidGuard -C all a été invoquée par root, les fichiers générés par cette commande appartiennent à ce dernier. On va donc devoir rectifier le tir une deuxième fois pour les permissions.

$ sudo chown -R squid:squid /var/squidGuard
$ sudo chown -R squid:squid /var/log/squidGuard

Recharger la configuration.

$ sudo systemctl restart squid

À présent, naviguez sur le Web au hasard tout en choisissant bien, et testez le filtrage de quelques sites potentiellement problématiques. Si tout se passe comme prévu, les pages ne s’affichent pas, et l’utilisateur se trouve confronté à la page explicative. Non content de cela, sa tentative est enregistrée dans le fichier log correspondant à la catégorie de site prohibé.

$ cat /var/log/squidGuard/adult 
2020-05-20 08:19:24 [15540] Request(microlinux/adult/-) 
https://www.youporn.com/ 192.168.2.2/alphamule - GET REDIRECT
2020-05-20 08:19:35 [15540] Request(microlinux/adult/-) 
https://www.pornhub.com/ 192.168.2.2/alphamule - GET REDIRECT
$ cat /var/log/squidGuard/agressif 
2020-05-20 08:19:50 [15540] Request(microlinux/agressif/-) 
http://whitehonor.com/ 192.168.2.2/alphamule - GET REDIRECT
$ cat /var/log/squidGuard/drogue 
2020-05-20 08:19:43 [15540] Request(microlinux/drogue/-) 
http://www.cannabizz.com/ 192.168.2.2/alphamule - GET REDIRECT

Automatiser la mise à jour des listes

Étant donné que la récupération des listes noires et la construction des bases de données est une opération quelque peu fastidieuse, on va la confier à un script que l’on exécutera de temps en temps. Voilà à quoi cela peut ressembler.

#!/bin/bash
#
# blacklist.sh
#
# Build/refresh blacklist database for SquidGuard URL filter.
#
# (c) Niki Kovacs 2020 <info@microlinux.fr>

# University of Toulouse
BLHOST='ftp.ut-capitole.fr'

# Make sure the script is being executed with superuser privileges.
if [[ "${UID}" -ne 0 ]]
then
  echo 'Please run with sudo or as root.' >&2
  exit 1
fi

# Check if blacklist server is up.
if ping -c 1 ${BLHOST} > /dev/null 2>&1
then
 echo "Blacklist server ${BLHOST} is up."
else
  echo "Unable to access blacklist server ${BLHOST}." >&2
  exit 1
fi

# Stop Squid
echo 'Stopping Squid server.'
systemctl stop squid

# Download blacklists
echo "Downloading blacklists from ${BLHOST}..."
cd /var/squidGuard
rsync -rv rsync://${BLHOST}/blacklist . > /dev/null

# Set permissions on blacklists.
echo 'Setting permissions on blacklists.'
chown -R squid:squid dest/

# Build database
echo "Building database. This might take a few minutes..."
echo "Check output in /var/log/squidGuard/squidGuard.log."
squidGuard -C all

# Set permissions on databases and log files
echo 'Setting permissions on databases and log files.'
chown -R squid:squid /var/squidGuard
chown -R squid:squid /var/log/squidGuard

# Start Squid
echo 'Starting Squid server.'
systemctl start squid

exit 0

On pourrait très bien songer à confier l’exécution de ce script à une tâche automatique (cronjob), mais j’évite de le faire dans la pratique quotidienne. En effet, les noms des catégories peuvent changer de temps à autre. Ça ne va pas arriver tous les jours, mais vous y aurez droit de temps en temps. Or, si votre fichier de configuration définit une destination qui n’a pas de catégorie correspondante dans les listes noires, l’exécution du script échouera. Et si vous administrez un ou plusieurs serveurs proxy dans un lycée ou dans une entreprise, c’est à ce moment précis que votre téléphone se mettra à sonner avec insistance. Je vous aurai prévenus.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.