Sécuriser DNS Bind9 – Serveur unique
Sommaire
I. Présentation
Le serveur de votre architecture se doit d’être sécurisé afin de ne pas se retrouver avec un serveur en déni de service et de ne pas voir s’arrêter la majorité des services qui s’appuient sur le DNS. Se protéger, oui, mais contre quoi ? Contre les attaques de types « DNS Spoofing » et « DNS cache poisoning ».
La sécurisation d’un serveur de noms autonome, unique, passe essentiellement par le paramétrage des restrictions des requêtes client, sur le transfert de zone, et de ne pas afficher la version de Bind installée sur votre serveur lorsqu’on lui demande de l’indiquer. Toutefois, un des meilleurs moyens d’augmenter la sécurité de Bind est de le maintenir à jour, c'est-à-dire d’installer la version la plus récente disponible afin d’éviter d’installer un système contenant des vulnérabilités connues.
Dans ce tutoriel, je pars du principe où vous maitrisez Bind9 et ses différents fichiers de configuration. Je vous rappelle qu’un tutoriel sur la mise en place et la configuration d’un serveur DNS avec Bind9 est disponible sur notre site.
De plus, dans ce tutoriel nous verrons comment sécuriser un serveur Bind lorsqu’il est seul c'est-à-dire qu’il n’y a pas de serveurs secondaires. Nous aborderons ce cas dans un autre tutoriel.
II. Le DNS Spoofing
Le terme « Spoofing » qui signifie en français « usurpation », indique qu’une attaque de type DNS Spoofing consiste à se faire passer pour quelqu’un d’autre sur le réseau. Enfaite, lorsqu’une machine essaiera d’en contacter une autre via son nom elle devra interroger le serveur DNS pour qu’il fasse la correspondance entre le nom et l’adresse IP pour répondre à la machine qui a envoyée la requête et lui indiquer l’adresse IP de la machine qu’elle cherche à joindre.
Chaque requête DNS contient un numéro d’identification, et, pendant ce processus, le but de l’attaque va consister à récupérer ce numéro d’identification par deux possibilités :
- Sniffer le réseau,
- Utiliser une faille présente sur les OS et les serveurs DNS qui permet de prédire les numéros d’identifications.
Une fois le numéro d’identification trouvé, il faut répondre à la requête DNS du client avec une réponse falsifiée avant que celle du « vrai » serveur DNS arrive. Ainsi, le client utiliseras sans le savoir l’adresse IP de la machine du pirate, avec confiance puisque c’est le DNS qui lui a répondu. La requête n’arrivera jamais à destination de la machine à laquelle elle était destinée à la base puisque la réponse a été falsifiée.
III. Le DNS cache poisoning
Le terme « cache poisoning » qui signifie en français « empoisonnement du cache », indique qu’une attaque de type DNS cache poisoning consiste à faire accepter au serveur DNS des informations incorrectes qu’il stockera ensuite dans son cache.
Pour se faire, le pirate doit exploiter une vulnérabilité du serveur DNS qui acceptera des informations incorrectes s’il ne contrôle pas ce qu’il reçoit, pour savoir si ça vient d’une source sûre, fiable. Lorsqu’il recevra des requêtes de la part des clients, il répondra en utilisant des informations erronées et à ce moment-là, les clients seront dirigés vers la machine pirate ou vers un site web falsifié (phishing).
Grâce à l’empoisonnement du cache, le pirate peut rediriger toutes les machines qui utilisent le serveur DNS empoisonné vers ce qu’il souhaite.
IV. Restrictions sur les requêtes clients
La première des choses à effectuer est l’application de restrictions au niveau des requêtes des clients, puisque par défaut n’importe quel client de n’importe quel réseau peut interroger le serveur DNS, ce qui n’est pas sécurisé.
Toutefois, il semble plus astucieux d’autoriser uniquement les clients du réseau LAN à interroger le serveur DNS en autorisant uniquement le réseau 192.168.1.0/24 dans le cas où votre réseau de LAN est 192.168.1.0/24. Bien sûr, il est possible d’indiquer plusieurs adresses réseaux puisque vous avez sûrement plusieurs sous-réseaux. Il est également possible d’autoriser uniquement une adresse IP précise à interroger le serveur DNS, en plus de vos sous-réseaux.
Pour appliquer ces restrictions, il y a deux manières de faire :
- Appliquer sur la totalité des requêtes reçues sur le serveur DNS.
- Appliquer des restrictions différentes pour chaque zone.
Toutefois, il est possible de coupler les deux manières, en indiquant une restriction globale puis une restriction particulière pour certaines zones et si des zones n’ont pas de paramètres spécifiques, la restriction globale sera appliquée. Dans le cas où les deux sont définies, il faut savoir que la restriction spécifique à une zone et prioritaire sur la restriction globale.
Afin d’avoir une gestion plus fine et plus flexible de ces restrictions, je pense qu’il est préférable de les configurer pour chaque zone mais cela sera plus long à mettre en place. Quoi que, Bind9 permet la mise en place d’ACL (Access Control List) c'est-à-dire « Liste de contrôle d’accès ». Ce qui nous permet de définir plusieurs ACL et ensuite de les attribuer sur les différentes zones et donc lorsque vous souhaiterez effectuer une modification de restriction vous n’aurez qu’à modifier les ACL et non les zones une par une.
Dans un premier temps, nous allons tout de même voir comment appliquer une restriction au niveau de toutes les requêtes c'est-à-dire sur toutes les zones. Vous devez modifier le fichier « named.conf.options » qui contient les différents paramètres de Bind9. Dans ce fichier, il est nécessaire d’ajouter et de configurer le paramètre « allow-query » qui signifie « Requête autorisée » dans la partie « options » du fichier. Ce paramètre contiendra alors comme valeurs vos adresses de réseau et éventuellement celles des hôtes uniques autorisées.
Par exemple, pour autoriser uniquement les clients du réseau « 192.168.1.0/24 » et la machine 192.168.2.254 du réseau « 192.168.2.0/24 », indiquez ceci :
allow-query {192.168.1.0/24; 192.168.2.254;};
Ce qui vous donnera un fichier contenant différentes options :
Dans un second temps, et maintenant que nous avons vu les restrictions globales nous allons voir la partie ACL qui permet d’effectuer des restrictions zone par zone. Ces ACL doivent être définies dans le fichier où sont définies vos zones qui par défaut est « named.conf.local ».
Note : La gestion d’ACL n’est pas obligatoire mais simplifie grandement l’administration du système, notamment sur la durée.
Les ACL doivent être définies en début de fichier puisqu’on les appelle dans la déclaration des zones, il faut qu’elles soient définies avant sinon Bind9 ne pourra pas les trouver vu qu’on lui demandera d’appeler une ACL qu’il n’a pas encore lue dans le fichier.
Une ACL se définie de la manière suivante :
acl "nom-acl" {paramètres};
Où le nom de l’ACL doit être significatif pour vous, afin de vous aider à s’y retrouver quand il faudra retoucher à la configuration dans quelques temps. Les paramètres quant à eux doivent être indiqués dans la partie « { }; » et dans ce cas ce sera les adresses réseaux et hôtes qu’on autorise à effectuer des requêtes.
Par exemple, pour faire une ACL qui autorise les clients des réseaux LAN 192.168.1.0/24 et 192.168.2.0/24 à effectuer des requêtes, voici ce qu’on indiquera :
acl "acl-lan" { 192.168.1.0/24;192.168.2.0/24; };
Puis ensuite, il faut appliquer l’ACL sur une zone en indiquant le paramètre « allow-query » dans la zone qui se référencera à l’ACL « acl-lan » que nous venons de définir. Par exemple, pour appliquer cette ACL à la zone « flo1.fr » :
allow-query { "acl-lan"; };
Remarque : Il est possible d’appliquer plusieurs ACL sur la même zone.
V. Restrictions sur le transfert de zone
Lorsque vous disposez d’un seul et unique serveur DNS, il est important de ne pas autoriser le transfert de zone afin qu’aucun autre serveur dont vous ignorez l’existence puisse venir lire vos fichiers de zones.
Dans le cas de la gestion de plusieurs serveurs DNS, la restriction sur le transfert de zone et plus complexe et nous verrons ça dans un autre tutoriel dédié à la sécurisation de Bind9 lorsqu’il y a plusieurs serveurs. Afin de le protéger, dans le fichier « named.conf.options » on va configurer le paramètre « allow-transfer » qui signifie « Autoriser le transfert » pour que le transfert soit autorisé pour personne.
Toujours dans la partie « options » du fichier, ajoutez la ligne suivante :
allow-transfer { none; };
VI. Masquer la version de Bind
Je vous disais dans la présentation qu’il est important de maintenir à jour Bind pour que les vulnérabilités connues soient corrigées sur votre serveur DNS. Nous allons voir comment masquer la version de Bind installée sur votre serveur, comme ça un éventuel pirate ne pourra pas obtenir d’informations sur votre version et pourra plus difficilement trouver des failles de sécurité connues à exploiter.
Pour connaître votre version de Bind actuelle, saisissez la commande suivante :
named –v
Toutefois, si cette commande ne fonctionne pas, saisissez celle-ci :
nslookup –q=txt –class=CHAOS version.bind. 0
La classe « CHAOS » permet d’interroger le serveur DNS pour obtenir diverses informations telles que la version de Bind. Le type d’enregistrement « txt » quant à lui permet de stocker une chaîne de caractères. Le paramètre « version.bind. » sert à indiquer qu’on veut connaître la version de Bind en interrogeant le serveur « 0 » qui correspondra au serveur localhost, si vous n’indiquez pas d’adresse IP de serveur ou « 0 », le serveur DNS définit sur le serveur sera interrogé.
Les deux commandes indiquées ci-dessus doivent retourner le même numéro de version, comme on peut le voir sur mon serveur :
Maintenant, nous allons faire en sorte de masquer la version de Bind grâce à la configuration du paramètre « version » dans le fichier « named.conf.options ». Ce paramètre doit avoir pour valeur une chaîne de caractères qui apparaîtra lorsqu’on interrogera le serveur DNS pour connaître sa version.
Par exemple, pour que le nom de version indiqué soit « Inconnu », ajoutez cette ligne au fichier de configuration :
version "Inconnu";
Puis avec un client, Windows par exemple, lorsqu’on refait une requête NSLOOKUP pour obtenir la version du serveur Bind, on obtient bien le message « Inconnu » que nous venons d’indiquer dans le fichier de configuration.
Si vous disposez d’un serveur DNS unique et que vous appliquez les différentes règles décrites dans ce tutoriel, la sécurité de Bind est fortement accrue et vous êtes désormais protégé.
