Pi-hole™, le blocage de pubs facile mais...


Peut mieux faire

Traditionnellement, pour bloquer la publicité sur le Web on utilise un logiciel complémentaire pour son navigateur favori du type uBlock Origin. Ceci dit la méthode, quoique très efficace pour un navigateur, n'est pas accessible pour les autres logiciels pouvant être amené à afficher des pages Web (un client Steam par exemple). Par ailleurs, cela impose une installation et configuration sur chaque machine, quand cela est possible (pas de blocages de pubs sur votre Nintendo Switch flambant neuve).

Sur Internet, tout commence en général par une requête DNS. La publicité pour agrandir certaines parties de l'anatomie ne fait pas exception à la règle. Une méthode très efficace pour bloquer la publicité est donc celle du DNS menteur. Pour peu que l'on dispose d'un résolveur DNS ou d'un cache se connectant à un résolveur, il est possible de lui fournir une liste qui fera pointer chaque domaine des cyber-Maurice Lévy vers le localhost de la machine ou une adresse IP appartenant au réseau local. Les serveurs distribuant les réclames ne seront jamais contactés, les pubs ne s'afficheront pas et vous ne serez pas traqués depuis ces domaines. De telles listes de domaines à bloquer existent. Citons celles de yoyo.org, qui a le chic d'être récupérable sous de multiples formats, dont celui d'un fichier de configuration Unbound (nous y reviendrons une prochaine fois, promis)

C'est ici que Pi-hole™, repéré sur Twitter, entre en jeu. Ce service ce propose de faire de la résolution DNS et d'utiliser plusieurs listes anti-pubs concaténées (ils revendiquent bloquer plus de 100 000 domaines), une belle interface Web 2.0 pour surveiller tout ça et la possibilité de transformer son Raspberry Pi (ou une autre machine faisant tourner du Linux, le projet semble ceci dit avoir été conçu avec le Pi en tête vu son nom) en serveur DHCP pour relayer la bonne parole sur le réseau local. Le tout grâce à une unique ligne de commande. Diantre ! Armons nous donc d'une machine virtuelle et testons la bête.

Une installation de Debian plus tard...

Premier constat, l'installation est vraiment facile. Une ligne de commande et le script récupéré fait tout le travail. Très vite vient la première déconvenue : on me demande de choisir un fournisseur DNS dans une liste de fournisseurs de DNS publics pas forcément compatibles avec le respect de la vie privée.

8.8.8.8 !

Il est néanmoins possible de mettre une adresse personnalisée (en l'occurrence, celle de mon Raspberry Pi, qui fait tourner le Unbound servant tout mon réseau local).

8.8.4.4 !

En regardant le dépôt GitHub du projet (ou en lisant un peu le script d'installation), on constate que c'est dnsmasq qui va être chargé de faire le travail DNS. dnsmasq est un outil léger permettant servant à la fois de relais/cache DNS (forwarder en anglais, ce qui explique la déconvenue - il n'est donc pour l'instant pas possible d'installer Pi-hole™ sur une machine disposant d'un résolveur) et de serveur DHCP (il gère aussi SLAAC pour les configurations IPv6). Le script me demande ensuite si je souhaite bloquer les pubs sur IPv4 et IPv6 (nous y reviendrons) puis si je veux installer le serveur Web qui fournira la console d'administration (il s'agit de lighttpd). Si un serveur Web tourne déjà sur la machine, il sera donc possible de passer cette étape. Notons qu'un petit rappel d'hygiène élémentaire (il faut penser à configurer le pare-feu de la machine pour n'accepter les connexions HTTP(S) provenant du réseau local) eût été de bon aloi. Enfin on me demande si je souhaite loguer toutes les requêtes DNS (afin d'avoir les statistiques et les beaux graphiques promis).

Et voilà ! Un petit mot pour me dire comment configurer les autres machines du réseau pour qu'elles puissent profiter de Pi-hole™, l'adresse de la console d'admin et le mot de passe (que l'on peut changer à la ligne de commande). Ne reste plus qu'à dire à ma Debian d'utiliser 127.0.0.1 comme serveur DNS et le tour est joué. On notera également au passage le nom de domaine bidon (ce qui est, rappelons le, une mauvaise pratique. Le jour où .hole sera un TLD, cela peut poser des problèmes).


L'interface est plutôt réussie, il y a les beaux graphiques promis, une table listant les requêtes DNS et leur statut (acceptée ou rejetée), la possibilité de gérer des listes noires ou blanches... Il est bien possible de transformer l'outil en serveur DHCP (désactivé par défaut), avec gestion de baux statiques et tutti quanti. Nouvelle déconvenue ceci dit, DNSSEC est proposé mais non activé par défaut, comme cela devrait être le cas sur tout logiciel DNS sérieux.

Que se passe-t-il en termes de requêtes DNS sur le réseau ? L'avantage d'avoir aiguillé Pi-hole™ vers une machine que je contrôle est de me permettre de voir ce qui ce passe. Et là, encore une déconvenue : les requêtes pour des enregistrements A sont bien filtrées en amont, mais ce n'est pas le cas de celles pour les enregistrements AAAA :

		john@resolveur ~ $ grep www.google-analytics.com  /var/log/unbound.log
		Mar 13 21:10:00 unbound[22484:2] info: 192.168.0.1 www.google-analytics.com. AAAA IN
		Mar 13 21:10:14 unbound[22484:0] info: 192.168.0.1 www.google-analytics.com. AAAA IN

Et depuis la machine hébergeant Pi-hole™, la requête A est bien interceptée mais pas la AAAA (l'adresse indiquée appartient bien à Google) :

		root@pihole-VM:/home/john# dig +short A www.google-analytics.com
		10.0.2.15
		root@pihole-VM:/home/john# dig +short AAAA www.google-analytics.com
		www-google-analytics.l.google.com.
		2a00:1450:4007:814::200e

Malgré ce que me dit l'interface donc :

Un autre example sur un domaine demandé en se rendant sur https://yahoo.co.jp/

		john@resolveur ~ $ grep s.yjtag.jp  /var/log/unbound.log
		Mar 13 21:05:23 unbound[22315:1] info: 192.168.0.1 s.yjtag.jp. AAAA IN

Encore une fois, l'interface dit le contraire :

Est-ce une bogue due au fait que la machine n'utilise pas IPv6 ? Il faudrait se renseigner auprès des développeurs. Cela est néanmoins fâcheux, car cela fait partir des requêtes DNS qui ne sont pas souhaitées dans la nature. Quoiqu'il en soit, l'outil semble bien faire le travail demandé, soit bloquer la publicité. Ce qu'il ne fait pas en revanche, c'est respecter votre vie privée (c'est évident quand le premier résolveur proposé est un service étatsunien). Pis, il peut aggraver la situation en donnant à la personne qui administre Pi-hole™ l'accès à toutes les requêtes DNS qui seront faites sur le réseau local. Si vous souhaitez surveiller ce que font vos enfants, votre colocataire ou votre chat sur Internet, voici une méthode très simple pour les espionner de très près, en temps réel et avec une joli interface Web 2.0.

Au final

Pourquoi râler si le respect de la vie privée n’est pas dans le cahier des charges ? Eh bien, c’est justement parce qu’il n’y est pas ! Il y avait matière à lancer un projet ayant comme objectif de bloquer la pub et d’essayer respecter au maximum la vie privée des utilisateurs. En permettant de mettre un vrai résolveur à la place de dnsmasq (au choix Unbound, Knot-Resolver…) pour faire au choix de la QNAME minimisation ou bien un cache allant interroger un résolveur (que l'on contrôle bien sûr) via DNS-sur-TLS par exemple. À noter que sur le site web du projet, le terme privacy n'est jamais cité. C'est dommage, une liste de ce que fait et ne fait pas Pi-hole™ serait souhaitable, car si la publicité est bien bloquée, il faut bien préciser aux potentiels utilisateurs que ça ne fait donc pas de miracle en termes de protection de la vie privée, même si le blocage des principaux mouchards est bien évidemment un plus.

Addendum : Je me plains plus haut de l'oubli de précision pour la création de règles de pare-feu sur les ports 80/443. Il faut également bien évidemment ajouter le port 53, à moins que vous ne souhaitiez transformer votre machine en résolveur ouvert. A noter qu'après installation, les logiciels écoutent par défaut sur toutes les interfaces disponibles. Il n'est pas possible de le changer durant cette étape, il convient donc d'aller éditer la configuration des services pour le faire.