Pour ma part, j’ai noté que l’apparition sur le marché de nano-ordinateurs comme les box Android ou les Raspberry Pi permet d’envisager de mettre en oeuvre des services qui semblaient horriblement chers et difficiles à déployer auparavant.

J’ai donc décidé d’acheter un Raspberry Pi 3 B+ qui offre une solution qui ne coûte pas cher, qui ne consomme pas beaucoup d’énergie, qui peut rester branchée en permanence, et qui est programmable intégralement. Je voulais déployer les services de base d’un réseau tout en me donnant la maîtrise la plus complète possible.

Le minimum à assurer :

• Un serveur DHCP (pour attribuer les adresses IP en local sur le réseau avec la possibilité de fixer des adresses statiques, pour une meilleure gestion)
• Un serveur DNS qui assure à la fois
  • le cache des recherches DNS (pour accélérer l’ensemble des opérations Internet des utilisateurs)
  • la fourniture de noms pour le réseau local
  • des réserves pour permettre le futur filtrage des recherches DNS (je ne m’intéresse guère au filtrage des contenus adultes, mais je me préoccupe sensiblement de bloquer les phishers, même si les deux problèmes sont techniquement identiques)

Dans le futur, il faudra aussi assurer des services complémentaires (pas étudiés ici) comme :

• Serveur de base temps NTP
• Serveur de noms WINS pour Windows

Comparaison

De fait, j’ai noté que deux serveurs semblaient aptes à gérer simultanément le DHCP et le DNS : Unbound et dsnmasq.

Unbound:

• Serveur léger
• Support DNSSEC
• plutôt tourné vers la sécurité
• Pas de serveur DNS authoritative (mais capable de gérer un domaine local)

dnsmasq:

• Serveur léger
• Support DNSSEC
• DHCP et DNS sont integrés dans un seul serveur
• Capable d’exploiter /etc/hosts pour alimenter le serveur DNS
• Pas de serveur récursif DNS (seulement forward vers un serveur récursif ou authoritative comme 8.8.8.8 ou 9.9.9.9 ou le serveur DNS de votre propre FAI)
• Pas de serveur DNS authoritative (mais capable de gérer un domaine local)

Cela m’a mené à exploiter dnsmasq, principalement à cause de la possibilité de gérer simultanément DNS et DHCP.

Découvertes intéressantes

Première information vite découverte : les serveurs NAS Synology sont tout à fait incompatibles avec le filtrage de DNS de CleanBrowsing. Celui-ci compte synology.me (service nécessaire pour le DDNS de Synology) dans les domaines à risque. De nombreux services du NAS cessent immédiatement de fonctionner.

Je n’ai pas vérifié mais il est probable que de nombreux autres services DDNS (Dynamic DNS) soient black-listés pour les mêmes raisons : devant le nombre de petits serveurs Synology (ou autres) mal configurés, ces DDNS renvoient sans doute vers une forte proportion de domaines qui ont été pris en otage par les hackers.

Il faut donc pouvoir gérer cela plus finement si vous avez vous-même votre propre NAS Synology (et sans doute d’autres marques).

Observations

Après quelques mois d’utilisation de dnsmasq sur Rapsberry Pi, il est temps de faire quelques commentaires pour partager cette expérience.

Tout d’abord, cela a très bien fonctionné. J’ai bien eu un cas où le serveur DHCP semble s’être arrêté sans autre forme de procès. J’ai essayé de comprendre la cause mais il s’est révélé plus simple de rebooter le serveur (bouton On-Off) pour retrouver le service. Evidemment, quelques dizaines de minutes de recherche m’auront valu quelques regards inquiets de l’autre utilisatrice du réseau…

Les filtres DNS mis en place pour limiter l’accès à des domaines particulièrement dangereux fonctionnent bien, mais il est exact qu’il ne semble pas y avoir eu de déclenchement intempestif (ce n’est pas la seule barrière que j’utilise contre les sites malveillants). Le script de création du filtre est ci-dessous :

#!/bin/sh
#Dated 2020-11-10 1.0 Addition of --quiet to wget (to reduce clutter to /var/mail/pi)
#                     *** STABLE RELEASE ***

cd /var/lib/work

#Get anti-phishing filter lists from Internet
wget -q -O ./isc-low.txt 'https://isc.sans.edu/feeds/suspiciousdomains_Low.txt'
wget -q -O ./isc-med.txt 'https://isc.sans.edu/feeds/suspiciousdomains_Medium.txt'
wget -q -O ./isc-hig.txt 'https://isc.sans.edu/feeds/suspiciousdomains_High.txt'
wget -q -O ./yoyo.dnsmasq.txt 'https://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq&hostformat=nohtml&showintro=0&mimetype=plaintext'
#Remodel the lists into DNSmasq filters
catcherIP='192.168.1.250'
inputfile="./isc-med.txt"
tmpfile="/tmp/.adlist.$$"
tmpconffile="/tmp/.dnsmasq.conf.$$"
configfile="/etc/dnsmasq.filter.conf"
configheader="/etc/dnsmasq.filter.header"

#Start with putting our own header
    [ -f "$configheader" ] && cat $configheader >> $tmpconffile
#check if TmpFile could be init'd with header
if [ ! -s $tmpconffile ]
then
    echo "temp fil '$tmpconffile' could not be found or is empty; quitting"
    exit
fi
#Remove list headers
cat $inputfile | grep -v "^#" | grep -v "^Site$" > $tmpfile
#Buid list to DNSmasq format, and add it to the file
sed "s/(.*)/address=\/\1\/${catcherIP}/" $tmpfile >> $tmpconffile
#Move the final list to destination
sudo cp $tmpconffile $configfile

Un des avantages de ce serveur est sa rapidité. Je pouvais m’en inquiéter avant de connaître le Raspberry Pi, mais étant donné la faible charge de travail sur ce serveur (malgré un petit serveur HTTP, des connexions à distance et quelques scripts locaux) et la bonne puissance de la CPU, tout se passe très bien même devant la dizaine de clients qui font appel au serveur DNS en mode à peu près continu (les iPhones sont particulièrement exigeants).

dnsmasq est parfaitement capable de gérer le DHCP IPv6, et le DNS IPv6 correspondant. La documentation à ce sujet est faible (c’est le moins qu’on puisse en dire), mais ça fonctionne bien et j’ai pu assurer un fonctionnement fiable dans ce domaine également (temporairement, le Raspberry Pi m’a même servi de proxy pour tout le trafic IPv6 sans faiblir ou être remarqué ; là, j’ai été surpris par sa puissance).

Après une installation initiale qui fonctionnait avec une allocation dynamique des adresses IP, j’ai passé le serveur DHCP en configuration presqu’exclusivement statique (c’est un choix personnel qui me permet de reconnaître plus facilement le contenu de mon réseau). Là aussi aucune difficulté, aussi bien en IPv4 qu’en IPv6.

Conclusion : totalement positive.

Dans le futur, je peux être tenté de déployer des serveurs DHCP et DNS plus puissants (peut-être ou peut-être pas) et surtout un espion de réseau genre SNORT ou SURICATA. Mais c’est une autre histoire. Et peut-être que dans ce dernier cas, je serai tenté par un calculateur avec beaucoup plus de puissance de calcul (j’ai un Avenger96 à l’essai, mais il ne me semble pas idéalement supporté en matière de soft).

Quelques autres liens intéressants

• D’autres solutions pour un serveur DHCP :
  • Installation de DNSmasq (DHCP seul)
  • Dragon : installation de DNSmasq (DHCP et DNS)
  • Instructables : installation de DNSmasq (DHCP et DNS)
  • Serveur ISC-DHCP sur Debian
  • Serveur ISC-DHCP sur Ubuntu
  • Outils prévus pour fonctionner avec ISC-DHCP
  • Guide rapide pour l’installation de serveurs DHCP, DNS et NTP sur Raspberry Pi
• Des informations sur l’installation d’un serveur DNS :
  • Serveur DNS BIND en local sur Debian 9
  • Serveur DNS BIND authoritative sur Ubuntu
  • Serveur DNS BIND comme « caching » ou « forward-only » sur Ubuntu
• Filtres DNS :
  • LE guide sur le nettoyage du DNS à partir de listes du domaine public
• La mise en oeuvre sur un NAS ou un routeur Synology :
  • Configuration de serveur DNS sur DSM
• Comparaisons de serveurs :
  • BIND vs. dnsmasq vs PowerDNS vs Unbound

J’ai une connexion Internet Fibre chez Numéricable qui utilise obligatoirement une adresse IP dynamique (pas d’adresse IP fixe chez Numéricable qui sont un peu gentiment arriérés). Ce n’est pas bien grave sauf que j’ai un serveur RAID provenant de chez Synology (une DiskStation DS413j à 4 disques en mode redondant RAID-5) qui me procure quelques services que je souhaite partager avec Internet (quand je suis en déplacement avec un mobile ou un PC portable, j’aimerais accéder à mon serveur FTP, à mon serveur de mail).

J’ai donc décidé de m’organiser pour permettre de retrouver facilement le Synology DiskStation depuis un sous-domaine (par exemple mail.roumazeilles.net).

La solution que j’ai adoptée :

Adresse IP dynamique :

Comme mon adresse IP est dynamique, pas moyen de faire grand chose avant d’avoir résolu ce point. J’ai opté pour le service DDNS de Synology. Comme j’utilise DSM 5.0 (la version la plus récente du soft de Synology), il est accessible dans le panneau de configuration au menu « Accès extérieur ». Il suffit d’ajouter un DDNS en choisissant Synology comme prestataire et j’ai enregistré un nom qui me convient (disons ds). A partir de là, malgré les changements d’adresse IP, ma DiskStation reste accessible à ds.synology.me.

Sous-domaine du DNS :

Il faut ensuite faire pointer mail.roumazeilles.net vers ds.synology.me. Le sujet est un peu plus compliqué parce que j’ai déjà réservé le nom de domaine roumazeilles.net chez Gandi et qu’il pointe vers un serveur mutualisé chez OVH. C’est le serveur d’hébergement (loué chez OVH) qui comporte toute l’information relative à roumazeilles.net. J’ai donc du aller sur mon serveur et dans sa configuration DNS modifer (dans votre cas, il s’agira peut-être d’ajouter) un enregistrement de type CNAME.

mail 10800 IN CNAME ds.synology.me. (N’oubliez pas le point final dans votre entrée CNAME, ou elle ne fonctionnera pas !)
Comme j’ai de la chance, mon panneau de contrôle OVH me permet de ne pas me rater avec la syntaxe exacte, mais l’affaire est identique : je lui dit que le sous-domaine mail est décrit pas un enregistrement CNAME qui pointe directement sur ds.synology.me (un peu abscons mais pas très méchant).

Ensuite, il reste à attendre que l’information DNS « se propage » (quelques minutes à quelques heures, parfois 24-48h). Et un petit contrôle se fait avec ping mail.roumazeilles.net qui doit répondre correctement avec mon adresse IP chez Numéricable.

C’est dans ce contexte, alors que l’Internet Engineering Task Force (IETF) préparait une nuit sans IPv4 pour sensibiliser le public, Google a lancé la version réservée à IPv6 de son moteur de recherche : ipv6.google.com (si vous êtes comme presque tout le monde, vous ne trouverez sans doute rien au bout de ce lien).

Il ne nous reste plus qu’à changer tous le plus tôt possible.

Cela veut dire que IPv6 va maintenant pouvoir devenir une réalité dans la plupart des régions du monde, même s’il reste encore beaucoup à faire dans ce domaine pour le rendre absolument omniprésent.