Mettre en place une protection parentale pour la famille

Et c’est parti pour la mise en place d’une protection parentale pour la famille afin de filtrer les accès Web (et leurs contenus) de manière transparente pour tous les périphériques de la famille. Les loutors finiront un jour par avoir accès à Internet et je préfère prendre les devants pour éviter toute surprise.

Pour cela, j’utilise mon Raspberry PI 3, installé avec Raspbian Jessie en tant que passerelle, pour séparer mon réseau interne d’Internet.

Vu que le RP fait office de passerelle avec 2 interfaces réseaux, eth0 en interne et eth1 en externe, la configuration routeur est déjà faite et je ne détaillerai pas ces opérations dans ce post.

Pour mettre en place cette protection parentale, les paquets suivants seront installés

  • Squid3 qui assure la partie “proxy” et intercepte les protocoles HTTP et HTTPS
  • SquidGuard qui autorise ou non les domaines à visiter, les IP du réseaux locales, les heures de navigation, …
  • IpTables pour rerouter le trafic HTTP et HTTPS sur squid pour rendre le proxy “transparent”
  • Nginx avec le support PHP pour afficher une belle page Web en cas de site non-autorisé

Quelle version de Squid ?

Par défaut, la version de Squid est la 3.4. Cette version ne permet pas de gérer le protocole HTTPS de manière simple (SSL bumping très rudimentaire).

Avec la version 3.4, on est obligé de déployer un certificat SSL sur les PC/tabelettes/smartphone pour pouvoir décrypter le contenu des paquets. En effet, les navigateurs récents stoppent toute connexion HTTPS dès qu’une activité suspecte sur le certificat est détecté. Vu que Squid 3.4 remplace le certificat du site distant par un certificat dynamique, le navigateur pense à une attaque de type “Man In The Middle”.

Mais outre les questions d’éthique (je ne peux plus proposer à mes invités ma connexion Wifi) que cela peut poser en plus des problèmes de sécurité, le déploiement du certificat SSL me parait trop lourd.

La version 3.5 introduit une nouvelle option, “Peek and Splice” dans la fonctionnalité ssl_bump qui permet de choisir quelle partie de la connexion SSL on souhaite vérifier. Dans notre cas, on souhaite vérifier le nom de domaine lors du TCP CONNECT en HTTPS et non le contenu des données ou l’URL.

Il va donc falloir récupérer les sources de Squid 3.5 et les recompiler à la sauce Debian.

Mise à jour de sa distrib’

  • On commence tout d’abord par une petite mise à jour de sa distribution favorite

Compilation de Squid 3.5

  • On installe les paquets nécessaires, on télécharge les sources de squid 3.5, on édite quelques fichiers et on compile le tout
  • A ce stade, il faut modifier 2 fichiers pour que la compilation se déroule correctement :
    • ~/build/squid3/squid3-3.5.23/debian/rules : les flags de compilation sont ajustés pour rajouter le support SSL (non activé par défaut) + suppression d’option d’authentification inutile
    • ~/build/squid3/squid3-3.5.23/debian/control : la ligne de contrôle des dépendances est mise à jour pour supprimer des dépendances inutiles
  • Puis on lance la compilation

Installation de Squid 3.5

  • Une fois la compilation terminée, on peut installer les paquets fraîchement compilés
  • On crée maintenant le fichier /etc/squid3/squid.conf, on rajoute son réseau et on l’autorise avec 2-3 autres modifications. Comme beaucoup de réseaux locaux, le mien est en 192.168.1.X.
    Pour la génération du certificat SSL, j’ai réutilisé celui déjà mis en place au niveau du serveur Nginx en tant que reverse proxy. La procédure de création du certificat n’est donc pas décrite.
    Le fichier doit ressembler à ça :
  • Une fois la configuration de Squid3 faite, on s’occupe du répertoire /cache visant à améliorer la navigation. Le DD étant une SD, je monte ce répertoire en RAM plutôt que sur la SD pour économiser la flash.
  • Vient l’édition du fichier /etc/fstab afin de monter 500Mo de RAM dans le répertoire /cache. La taille de 500Mo est à ajuster en fonction de la taille de cache déclarée dans le fichier /etc/squid3/squid.conf. Il est recommandé de ne pas utiliser 100% du /cache mais 80% (500 x 80% = 400). D’où les 400Mo déclaré dans /etc/squid3/squid.conf et les 500Mo dans /etc/fstab.
  • Un redémarrage des services et on peut désormais tester notre serveur proxy depuis un poste. L’IP de mon raspberry est 192.168.1.5. La navigation Internet doit pouvoir s’effectuer sans souci depuis le poste client.

SquidGuard

  • Comme précédemment, on installe les paquets nécessaires.
  • Maintenant, il s’agit d’utiliser des listes contenant les sites et contenus interdits ou à surveiller. L’université de Toulouse met à disposition gracieusement de telles listes et on va donc récupérer ces listes pour les utiliser.
  • On édite le fichier /etc/squidguard/squidGuard.conf avec la liste des IP des appareils autorisés à tous les contenus (déclaration du group parents). Pour chaque contenu non-autorisé, un fichier *contenu*.access est crée dans le répertoire /var/log/squidguard afin de logguer les tentatives d’accès.
  • On charge les listes téléchargées dans squidGuard. A noter que ces 2 commandes doivent être relancées à chaque modification du fichier /etc/squidguard/squidGuard.conf
  • Nouvelle édition du fichier /etc/squid3/squid.conf pour rajouter la ligne suivante
  • Re redémarrage des services et nouveau test sur un site interdit
  • La page suivante doit apparaître, ce qui est normal vu que nginx n’a pas encore été installé et configuré
  • Côté log, on peut voir que les connexions HTTP et HTTPS sont bien interceptées

Nginx

  • Comme vu, on installe les paquets nécessaires
  • On édite le fichier /etc/php5/fpm/pool.d/www.conf pour décommenter/vérifier la ligne suivante

    Vu que squidGuard et Nginx tournent sur la même machine, on utilise donc une socket Unix pour la communication.
  • On redémarre PHP5
  • On crée un nouveau fichier /etc/nginx/conf.d/php5-fpm.conf pour indiquer la location de la socket
  • Puis, édition du fichier /etc/nginx/sites-available/default pour prendre en charger les fichiers *.php et fixer les accès. On autorise seulement l’accès au réseau local
  • Un petit fichier de test pour vérifier que Nginx avec le support PHP5 fonctionne bien
  • On redémarre Nginx et on affiche la page PHP Info

SquidGuard, le retour

  • On va customiser notre page indiquant les sites bloqués. Pour cela, on crée le fichier /var/www/squidguard/block.php
  • Puis le fichier /var/www/squidguard/filter.css
  • Un nouveau test sur un contenu interdit en HTTP devrait nous afficher la jolie page suivante
  • Pour le même site mais en HTTPS, pas de jolie page Web mais un message du navigateur avertissant d’un souci de confidentialité dans la chaîne SSL entre le site et lui. Cette erreur apparaîtra sur tous les navigateurs récents (Opera Neon, Chrome, Firefox, Safari, …).
  • Côté log, on a bien l’entrée correspondante

Configuration du proxy transparent

  • Si le paquet IPtable n’est pas déjà installé
  • Puis, mise à jour des règles IPTables pour intercepter le trafic HTTP et HTTPS et le re-router sur le port 3128 et 3129 du proxy squid3
  • On fait un nouveau test en pensant bien à désactiver la configuration proxy. Le résultat doit être le même que précédemment, la page de restriction doit s’afficher.

Mise à jour des listes

  • Histoire d’automatiser le téléchargement des listes et de toujours avoir les dernières nouveautés, un p’tit script /etc/cron.daily/blacklist.sh est mis en place

Ressources utilisées

  • http://www.pihomeserver.fr/2015/09/01/un-controle-parental-grace-au-raspberry-pi-squid-et-squidguard
  • https://adilmehmoodbutt.wordpress.com/2014/02/19/how-to-install-squid3-transparent-proxy-server/
  • https://www.guillaume-leduc.fr/projet-installation-configuration-nginx-php-fpm.html
  • https://redmine.pfsense.org/issues/6777
  • https://docs.diladele.com/administrator_guide_5_0/install/rpi/index.html
  • http://david.mercereau.info/serveur-proxy-squid3-avec-ssl-rebuild-debian-squeeze-package/
Tagged with: ,