Wiki [Tuto/HowTo] Mettre en place un serveur DNS aux noms de domaines parametrable (Rogue DNS)

0
20
août
2018

Sommaire

Screenshot-2018-10-23-Pi-Hole-WEBUI-Dashboard-Admin

Préambule

Ce tutoriel va vous permettre de remettre en place un semblant de HairPinning, ce qui pourra s'avérer salvateur pour les services auto-hébergés derrière des routeurs bridés.
La méthode qu'on va mettre en place ici vous apportera même une belle feature : le blocage d'une partie de la publicité sur tout votre réseau.
Par contre en déplacement, les machines peuvent parfois mettre un peu de temps (généralement 1-5 min max) pour renouveller leur cache DNS. En attendant ce renouvellement, les services ne sont de facto pas joignable.
La consommation machine est très faible et doit pouvoir tenir sur un RPI1 sans problème. Il n'y a que l'interface WEB qui a tendance a surconsommer le pauvre navigateur du client (testé sur firefox-ubuntu).

/!\ L'interface web de PiHole n'est accessible qu'en http. Vous devrez configurez vous même la sécurisation du canal entre le client et le serveur. Par exemple via votre VPN, en configurant lighttp/Haproxy pour utiliser https ou encore via un tunnel SSH.

NDLR : J'ai proposé l'ajout de la feature Rogue DNS directement à PiHole afin de ne plus avoir besoin de DNSChef. Peut-être que DNSChef ne sera donc plus nécessaire dans le futur.

Introduction

Le serveur DNS est un serveur qui permet aux clients d'un réseau informatique de transformer un nom de domaine du type www.helloworld.com en adresse IP, permettant ainsi aux machines de communiquer.
Comme les logiciels de serveur DNS (comme PiHole ou encore Bind9) ne permettent pas de modifier l'adresse IP attribuée à un nom de domaine, nous allons donc ici utiliser deux logiciels :

  • DNSChef (rogue DNS) qui ira récupérer les vrais adresses IP liées aux noms de domaine. Ce logiciel écoutera sur 127.0.2.1:5353 (boucle locale).

  • PiHole (serveur DNS) qui recevra les requêtes des clients et les redirigera, ou non, vers le serveur DNS, ou utilisera son propre cache. Ce logiciel écoutera sur l'adresse IP LAN du serveur.

Une fois ce serveur mis en place, vous pouvez au choix :

  • configurer votre routeur pour qu'il utilise ce serveur DNS (le routeur pouvant servir de cache DNS)
  • configurer votre routeur pour que les clients utilisent ce serveur DNS en lieu et place de celui du routeur.

Nous allons ici choisir la deuxième méthode : le DNS primaire (principale) utilisé par les clients sera notre propre serveur, tandis que le DNS secondaire (de secours) sera le routeur lui-même (ou un second serveur DNS maison).
Dans le tutoriel nous considérerons que notre serveur imaginaire a comme adresse IP LAN 192.168.1.42 et tourne sous ubuntu 16+.

Mise en place de DNSChef.

Passez en admin

  • sur Raspbian / Ubuntu
sudo -i
  • sur Debian / Ubuntu Minimal
su

Installez les pré-requis.

apt-get install python-pip screen
pip install --upgrade pip
python -m pip install dnslib IPy

Rendez-vous dans le dossier où enregistrer le script de dnschef, ici on choisit /opt/scripts

cd /opt/scripts

Téléchargez dnschef et rendez le exécutable.

wget https://raw.githubusercontent.com/iphelix/dnschef/master/dnschef.py
chmod +x /opt/scripts/dnschef.py

Maintenant, on va préparer un fichier de configuration externe, qui permettra de rediriger des noms de domaines vers des adresses IP spécifiques.

nano /opt/scripts/config/dnschef.ini

Ajoutez dedans les noms de domaines que vous souhaitez filtrer et vers quelle IP il faut rediriger les clients.
Voici un exemple ([A] concerna la section IPv4 tandis que [AAAA] concerne la section IPv6, plus d'infos ici : External definitions file):

[A]
*.google.com=192.0.2.1
thesprawl.org=192.0.2.2
*.google-analytics.*=192.168.42.42
[AAAA]
*.google.com=2001:4860:4860:0:0:0:0:8888
thesprawl.org=2001:4860:4860:0:0:0:0:8844
*.wordpress.*=2001:4860:4860:0:0:0:0:8888
  • Une fois terminé, tapez CTRL+X pour sauver et quitter.

Créez et éditez notre fichier de lancement.

touch /opt/scripts/start_DNS_Rogue.bash
chmod +x /opt/scripts/start_DNS_Rogue.bash
nano /opt/scripts/start_DNS_Rogue.bash

Et ajoutez le script script

#!/bin/bash

/usr/bin/screen -S dnschef -X quit
sleep 1
/usr/bin/screen -d -m -S dnschef /opt/scripts/dnschef.py --file /opt/scripts/config/dnschef.ini --interface 127.0.2.1#5353 --nameservers 80.67.169.12,195.238.2.21,80.67.169.40,195.238.2.22,1.1.1.1,185.233.100.100,89.234.141.66,89.234.186.18,85.214.20.141,1.0.0.1,8.8.8.8,8.8.4.4,9.9.9.9 --nameservers 2a0c:e300::100,2a0c:e300::101,2001:4860:4860:0:0:0:0:8888,2001:4860:4860:0:0:0:0:8844 -q
        # --file /opt/scripts/config/dnschef.ini
        # --logfile=/var/log/dnschef.log
  • Note : si vous devez lancer deux fois l'instance de DNSChef (par exemple pour avoir un DNS pour votre LAN et un pour votre VPN), pensez à donner des noms différents aux fenêtres screen.

Éditez le planificateur de tâche (cron) de root.
ndlr : trouver comment le lancer sans root.

crontab -e

Ajoutez la commande suivante au démarrage via cron.

        # DNS
@reboot         ( sleep 10 ; /opt/scripts/start_DNS_Rogue.bash )

Quelques paramètres de dnschef

--interface
--interface 0.0.0.0
--interface 192.168.1.42
--interface ::
  • Permet de spécifier l'adresse sur laquelle écouter. Par défaut uniquement 127.0.0.1, pour écouter sur toutes les adresses IPv4 utilisez --interface 0.0.0.0 ou pour écouter sur toutes les adresses IPv6 utilisez --interface ::
--nameservers
--nameservers 8.8.8.8
--nameservers 2001:4860:4860:0:0:0:0:8888,2001:4860:4860::8844
--nameservers 80.67.169.40,195.238.2.21,195.238.2.22,8.8.8.8,8.8.4.4
  • Permet de spécifier une liste de nom de domaines. (une liste fournie ici) Par défaut dnschef utilise 8.8.8.8 (google).

Mise en place de PiHole.

  • Note : vous avez intérêt à avoir déjà fixé votre IP LAN ;)

Rendez-vous dans /tmp/ et téléchargez l'installeur de PiHole.

cd /tmp
wget -O basic-install.sh https://install.pi-hole.net

Passez en admin

  • sur Raspbian / Ubuntu
sudo -i
  • sur Debian / Ubuntu Minimal
su

Installez PiHole.

bash /tmp/basic-install.sh
  • Si vous faites une erreur, la commande suivante vous permettre de relancer l'installation ou la reconfiguration :
pihole -r

Comme serveur DNS, choisissez Custom puis indiquez 127.0.2.1:5353. Vous pouvez, mais n'êtes pas obligé, installer la WEBUI ou encore choisir ou non d'enregistrer les logs sans impacte sur votre installation finale.

Si vous avez installez l'interface graphique web (WEBUI)

  • Éditez le fichier /etc/lighttpd/lighttpd.conf
nano /etc/lighttpd/lighttpd.conf
  • Cherchez (CTRL+W) "port" et définissez le port HTTP que vous souhaitez utiliser. Par exemple
server.port                 = 88
  • Adaptez et ajoutez la ligne suivante afin de fixer l'adresse IP que le serveur web peut écouter (afin d'éviter certaines attaques).
server.bind                 = "192.168.1.42"
  • Générez votre mot de passe administrateur pour l'interface web.
pihole -a -g

À ce stade, vous devez redémarrer la machine.

Finalisation

Sur votre serveur DNS, activez Pihole
ndlr : s'active seul normalement, sauf s'il y a eu un problème, pas forcément bloquant, lors de l'installation (par exemple port 80 ou 53 déjà utilisé par un autre logiciel)

pihole enable

Vous pouvez utiliser la commande suivante pour checker quel logiciel écoute sur quelle IP/port. :

netstat -ntlp | grep LISTEN

Sur une machine cliente, testez la commande suivante en spécifiant un des noms de domaines que vous avez indiquez a DNSChef. Remplacez 192.168.1.42 par l'adresse IP Lan de votre nouveau serveur DNS.

host -t A www.helloworld.com 192.168.1.42
  • La commande doit vous retourner quelque chose du type :
└─ $ ▶ host -t A www.helloworld.com 192.168.1.42
Using domain server:
Name: 192.168.1.42
Address: 192.168.1.42#53
Aliases:

www.helloworld.com has address 192.168.1.42

Configurez ensuite votre routeur pour que les clients utilisent le serveur DNS que nous venons d'installer. Voici un tuto pour la BBOX2.

  • # Post Scriptum

    Posté par . Évalué à 1 (+0/-0). Dernière modification le 02/09/18 à 17:38.

    Attention : si vous utilisez ce tuto pour bloquer l'accès à des noms de domaines (par exemple googleanalytic) en renvoyant vers une IP inexistante :
    Certains Fournisseurs d'accès Internet, entre autre Proximus/Belgacom, font quand même sortir du LAN des données qui sont censées ne pas être routées, provoquant ainsi une fuite de données potentiellement grave pour la vie privée.
    Par exemple si votre réseau se situe sur 192.168.0.1 et que vous tentez de joindre l'ip 192.168.42.42, voici ce que cela donne

    └─ $ ▶ traceroute 192.168.42.42
    traceroute to 192.168.42.42 (192.168.42.42), 30 hops max, 60 byte packets
     1  _gateway (192.168.0.1)  3.835 ms  4.076 ms  11.246 ms
     2  xx.xxx-183-91.adsl-dyn.isp.belgacom.be (91.183.xxx.xxx)  63.382 ms  63.984 ms  64.736 ms
     3  xxx.xxx-183-91.adsl-static.isp.belgacom.be (91.183.xxx.xxx)  40.081 ms  45.656 ms  46.774 ms
     4  ae-xxx-xxx.ibrstr1.isp.belgacom.be (91.183.xxx.xxx)  48.130 ms  51.493 ms  53.148 ms
     5  * * *
     6  * * *
     7  * * *
     8  * * *
     9  * * *
    10  * * *
    11  * * *
    12  * * *
    13  * * *
    14  * * *
    15  * * *
    16  * * *
    17  * * *
    18  * * *
    19  * * *
    20  * * *
    21  * * *
    22  * * *
    23  * * *
    24  * * *
    25  * * *
    26  * * *
    27  * * *
    28  * * *
    29  * * *
    30  * * *
    

    Pensez donc à vérifier, via l'outil tracert / traceroute , le chemin qui se situe entre vos utilisateurs et l'adresse IP sensée être "morte" (down).

    🇪🇺

  • # amélioration sécurité

    Posté par . Évalué à 1 (+0/-0). Dernière modification le 13/09/18 à 15:57.

    Il y aurait moyen d'améliorer la sécurité en créant un utilisateur dédié et en lui attribuant la permission d'ouvrir le port DNS officiel (53).

    🇪🇺

  • # sudo su

    Posté par (page perso) . Évalué à 3 (+1/-0).

    sudo su

    Gni ?

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: sudo su

      Posté par . Évalué à 0 (+0/-1).

      C'est ainsi que l'on passe en root sur les ubuntu-like (pas les versions minimales) et Raspbian 😉

      🇪🇺

      • [^] # Re: sudo su

        Posté par . Évalué à 3 (+1/-0).

        Ce qui doit faire tiquer Tonton c'est que sudo su est déprécié en faveur de sudo -i
        Même la doc de Ubuntu n'évoque plus sudo su.
        Sur Raspbian ou toute Debian configurée sans mot de passe root, sudo -i est aussi une meilleure pratique.

        • [^] # Re: sudo su

          Posté par . Évalué à 0 (+0/-1). Dernière modification le 28/04/19 à 15:36.

          Sur Raspbian ou toute Debian configurée sans mot de passe root, sudo -i est aussi une meilleure pratique.

          "dépréciée, "meilleure pratique" ? why ?

          🇪🇺

          • [^] # Re: sudo su

            Posté par . Évalué à 4 (+2/-0).

            Comme utiliser sudo à la place de gksudo kdesudo (cité sur la page que j'ai lié précédemment), la configuration des variables d'environnement peut dangereusement merder avec sudo su et tu peux te retrouver avec un /home/utilisateur/ qui se corrompt insidieusement par une (ré)écriture de fichiers avec des droits de lecture/écriture exclusifs à root.
            À contrario, l'option -i de sudo a un comportement prédictible et est prévue pour cet usage spécifique.

Envoyer un commentaire

Suivre le flux des commentaires

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