Filtrer le web avec SquidGuard sous CentOS

SquidGuardIl 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.

Installation

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

# 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.

L’article sur le serveur Apache décrit en détail la mise en place d’une page web locale. Pour ma page avertissement.html, je me suis servi de la page web par défaut fournie par le paquet httpd dans le répertoire /usr/share/httpd/noindex, et que j’ai adaptée à mes besoins. Voilà ce que ça donne sur ma machine.

Page explicative SquidGuard

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
# rm blacklists.tar.gz
# wget -c ftp://ftp.ut-capitole.fr/blacklist/blacklists.tar.gz
# 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
# rm -rf blacklists*
# 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.

Un filtre simple pour contenus problématiques

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
# 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://nestor.microlinux.lan/avertissement.html
  }
  default {
    pass none
    redirect 302:http://nestor.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.

# chown -R squid:squid /var/squidGuard

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

# 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.

# chown root:squid /etc/squid/squidGuard.conf
# 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.

# squidGuard -C all

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 (1521101196.722)
... db update done

Quelques mises en garde 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.

# chown -R squid:squid /var/squidGuard
# chown -R squid:squid /var/log/squidGuard

Recharger la configuration.

# 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 
...
2018-03-15 08:14:24 [2428] Request(microlinux/adult/-) 
https://www.youporn.com/ 192.168.2.3/bernadette.microlinux.lan 
- GET REDIRECT
2018-03-15 08:14:36 [2428] Request(microlinux/adult/-) 
https://www.pornhub.com/ 192.168.2.3/bernadette.microlinux.lan
- GET REDIRECT
2018-03-15 08:15:57 [2428] Request(microlinux/adult/-) 
https://xhamster.com/ 192.168.2.3/bernadette.microlinux.lan
- 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

# Université de Toulouse
HOST=ftp.ut-capitole.fr

# L'exécution du script est réservée à root
if [ `id -u` != 0 ]; then
  echo
  echo ":: Désolé, vous devez être root pour exécuter ce script."
  echo
  exit
fi

# Vérifier si l'hôte distant est joignable
ping -c 1 $HOST > /dev/null 2>&1 ||
  {
    echo
    echo ":: L'hôte distant n'est pas joignable."
    echo
    exit
  }

# Arrêter Squid
systemctl stop squid

# Récupérer les listes
cd /var/squidGuard
rsync -rv rsync://$HOST/blacklist .

# Définir les permissions
chown -R squid:squid dest

# Construire la base de données
echo ":: Construction de la base de données des sites..."
squidGuard -C all

# Rectifier les permissions
chown -R squid:squid /var/squidGuard
chown -R squid:squid /var/log/squidGuard

# Redémarrer Squid
systemctl start squid

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.

Ce contenu a été publié dans CentOS, Documentation Microlinux, avec comme mot(s)-clé(s) , , , . Vous pouvez le mettre en favoris avec ce permalien.

3 réponses à Filtrer le web avec SquidGuard sous CentOS

  1. Thibaut BARTHALAY dit :

    Bonjour,

    Tuto qui marche parfaitement, merci.

    Juste une petite question, je peux filtrer les requettes HTTP et HTTPS sans problème. Le blocage de Squid Guard marche également en HTTP et HTTPS.

    En revanche, pour la redirection, j’ai un problème. En effet, quand c’est HTTP, la redirection ce fait, pas de soucis. En HTTPS le blocage se fait mais aucune redirection, juste “Ce site est inaccessible” .. une idée ? Merci d’avance.

  2. Thibaut BARTHALAY dit :

    Si cela peut aider, il parait que cela vient du protocole HTTPS qui ne supporte pas le REDIRECT vu qu’il n’est pas censé être intercepté et chiffré de bout en bout… !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.