Journal Un outil pour gérer une blacklist DNS

Posté par  . Licence CC By‑SA.
Étiquettes :
11
17
fév.
2016

L'idée n'est pas nouvelle, évidemment, mais je voulais réaliser mon propre outil de gestion d'une blacklist DNS. C'est une solution que je trouve, de très loin, supérieure à AdBlock Plus, pratiquement la première extension que tout le monde installe avec son navigateur préféré.

Pourquoi supérieure ? Je vois au moins deux avantages:

  • Le blocage peut s'appliquer à tout un réseau, pas juste une seule machine
  • Le blocage s'applique à toute application, pas seulement le navigateur

Bien sûr, il y a aussi quelques inconvénients:

  • Il faut être capable de monter un serveur DNS
  • Un blocage par DNS est moins précis qu'AdBlock Plus (pas possible de ne cibler qu'une publicité spécifique sur une page)

Mon application est un outil en mode console, basé sur le framework Lumen. C'est donc un outil écrit en PHP. À la base, je l'ai écris pour mon usage personnel, mais je me suis dis que peu de modifications seraient nécessaires pour en faire une application à diffusion plus large.

J'ai donc intégré la possibilité d'écrire des parseurs pour différents formats de listes et le support pour différents serveurs DNS. Ainsi, bien que je n'ai écris qu'un parseur pour les listes contenant un hôte par ligne et une classe de support pour bind, il sera très facile de supporter d'autres sources et d'autres serveurs rapidement. D'ailleurs, c'est déjà prévu.

  • # Logo

    Posté par  (site web personnel) . Évalué à 3.

    Quand on arrive sur la page du dépôt, on a l’impression qu’elle a été censurée par le gouvernement français !

    Peut-être qu’ils utilisent ton projet pour les blocages DNS ؟

    • [^] # Re: Logo

      Posté par  . Évalué à 1.

      Quand on arrive sur la page du dépôt, on a l’impression qu’elle a été censurée par le gouvernement français !

      Ah ? Pourtant c'est juste gitlab…

      Peut-être qu’ils utilisent ton projet pour les blocages DNS 

      J'en doute fortement.

      • [^] # Re: Logo

        Posté par  . Évalué à 3.

        Sa remarque vient du logo qui ressemble à : capture d'ecran du blocage par le ministere de l'intérieur

        C'est marrant, j'ai découvert il y a deux jours stevenBlack/hosts qui est un agregat de serveurs de différentes sources avec un format adapté au fichiers hosts.

        En tout cas, merci pour le projet, je testerai ce week end.

      • [^] # Re: Logo

        Posté par  (site web personnel) . Évalué à 2.

        J’avais même mis un point d’ironie pour pas que ce soit pris au sérieux mais ça a raté.

        C’est juste que la vue du site avec le logo de main centré au milieu m’a tout de suite rappelé les pages censurées par le gouvernement, comme on peut le voir sur la capture postée par Guillaume Rossignol. Et comme c’est précisément du blocage par DNS que fait le gouvernement j’ai trouvé ça rigolo.

        • [^] # Re: Logo

          Posté par  . Évalué à 0.

          Désolé, je suis un handicapé de l'ironie :)

          Je n'avais pas fais le rapprochement. Il va falloir que je trouve une autre icône que celle de nuvola…

  • # L'anglais + projet

    Posté par  . Évalué à 1.

    Si ton projet s'adresse à des anglophones, il faut impérativement revoir l'anglais car c'est un peu une torture de lire le document de présentation du projet.

    Ensuite pas besoin de construire la qualité de ton application en tapant sur un concurrent. Je vois quand même un manque de granularité dans ton approche du blocage.

    Concrètement comment cela se passe? Tu vois une url, tu la copie, tu vas dans le terminal et tu lances la commande pour bloquer le serveur en entier?

    Je trolle dès quand ça parle business, sécurité et sciences sociales

    • [^] # Re: L'anglais + projet

      Posté par  . Évalué à 0.

      Je vois quand même un manque de granularité dans ton approche du blocage

      Oui, je le précise bien.

      Concrètement comment cela se passe? Tu vois une url, tu la copie, tu vas dans le terminal et tu lances la commande pour bloquer le serveur en entier?

      Pour bloquer le FQDN, oui. Si tu lui balance http://ads.sub.server.com/ad.js, tu vas bloquer ads.sub.server.com.

  • # privoxy

    Posté par  . Évalué à 3.

    Dans le même genre, il me semble qu'il était possible de donner à manger des listes d'adblocks à manger à privoxy pour avoir un système de blocage similaire.

  • # DNS RPZ

    Posté par  (Mastodon) . Évalué à 5.

    Va faire un tour par Response_policy_zone, ici et , ce sera beaucoup plus efficace pour Bind, plus simple à configurer, et permet la réplication entre 2+ serveurs récursifs.

  • # /etc/hosts

    Posté par  . Évalué à 3.

    Je comprends tout à fait la problématique de bloquer un domaine au delà du navigateur. Pour cette question, l'application Adaway (sous Android - dispo sur F-droid) et https://github.com/sedrubal/adaway-linux répondent au besoin en patchant le fichier /etc/hosts.

    Ça a le bon goût d'être léger et efficace, multiplateforme (même Windows le respecte!). Cependant, ça demande un accès root (ce que demandera aussi ton serveur de toute façon pour binder le port 53).

    Du coup, je me demande les avantages d'un DNS custom (en dehors de l'intérêt technique de le faire bien sûr) par rapport à cela.

    • [^] # Re: /etc/hosts

      Posté par  . Évalué à 1.

      En ce qui me concerne, j'ai mis cette application sur mon routeur, d'où la présence d'un serveur DNS. Mais il est bien sûr possible de le faire dans le fichier hosts.

      Par contre, quand tu commence à utiliser pas mal de listes qui bloquent quelques centaines de milliers de domaines, il me semble que passer par un serveur DNS est plus efficace, mais je peux me tromper.

    • [^] # Re: /etc/hosts

      Posté par  . Évalué à 0.

      Et pour ce qui est de bloquer au delà du navigateur, je fais tourner une application de web scraping sur un de mes serveurs. C'est donc très utile de pouvoir bloquer au delà du navigateur dans mon cas.

      Par ailleurs, ça évite de devoir configurer tous les navigateurs de tous les utilisateurs.

  • # Pourquoi inférieur ?

    Posté par  . Évalué à -6.

    Ne va pas supporter les filtres cosmétiques, ainsi l'espace pris par les pubs ne va pas être réutilisé ce qui rend les sites moches, bugués voire cassés

    • [^] # Re: Pourquoi inférieur ?

      Posté par  . Évalué à 2.

      En ce qui me concerne, les pubs bloquées par ce moyen n'affichent pas de cadre vide et les sites ne sont pas déformés.

      Dans mon cas, j'associe les domaines à l'IP d'un serveur web avec un vhost par défaut qui renvoi un en-tête 410 et un body vide, pour être tout à fait exhaustif.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.