Raspberry Pi comme serveur local DNS/DHCP

Pour un réseau local de petite entreprise ou d’une famille active sur Internet, il est possible de faire intégralement confiance à un fournisseur d’Accès Internet (FAI) qui va systématiquement offrir les services de base d’un réseau local sur sa box Internet (fibre ou ADSL). Mais si vous souhaitez (comme moi) disposer de plus de flexibilité, il sera utile de mettre en place ses propres services.

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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.