26/11/2024

DNS et sécurité : quels sont les risques ?

I. Présentation

On a vu précédemment qu’il était possible de redonder les serveurs DNS afin de disposer d’un secours en cas de panne du premier. Même si ce genre d’architecture ne résout pas tous les problèmes de sécurité, il permet toutefois de secourir le service.  Le principal problème concernant la sécurité est le transit des requêtes DNS, en clair sur le réseau, pouvant servir les intérêts d’une personne malveillante.

REMARQUE : les implémentations du serveur BIND utilisent le daemon named pour résoudre les noms, ou simplement faire autorité d’un domaine ou d’un sous-domaine particulier. La notion de sécurité sur le service DNS/BIND n’a été introduite que depuis la version BINDv9.

II. Quels sont les risques ?

Tout serveur DNS se doit également d’être sécurisé afin de ne pas avoir une machine en déni de service et voir les applications sous-jacentes s’arrêter ou ne plus fonctionner correctement. Au fait, contre quoi doit-on se protéger ?

La sécurisation d’un serveur de noms autonome, unique, passe essentiellement par le paramétrage des restrictions des requêtes client, concernant le transfert de zone. Il ne doit pas non plus afficher la version de Bind installée (ou tout autre programme serveur installé), permettant alors de fournir des indications précieuses aux personnes étrangères. Toutefois, un des meilleurs moyens d’augmenter la sécurité de l’outil DNS est de le maintenir à jour, en installant ou upgradant avec la version la plus récente disponible afin d’éviter d’utiliser un système pouvant contenir des vulnérabilités connues.

Par ailleurs, i existe deux grandes familles d’attaques contre des serveurs DNS :

  • Le DNS spoofing (appelé aussi usurpation DNS).
  • Le DNS cache poisonning (ou empoisonnement du cache).

Dans le premier cas, l’attaque consiste à se faire passer pour quelqu’un d’autre, sur le réseau. En effet, comme chaque requête DNS possède un numéro d’identification, durant le processus de piratage, cela consiste à récupérer ce fameux numéro soit :

  • En écoutant ou sniffant le réseau
  • En utilisant une faille présente sur le système d’exploitation et les serveurs DNS permettant de prédire ce numéro d’identification.

Une fois que le numéro est trouvé, il ne reste plus qu’à répondre à la requête DNS initiale du client, en falsifiant la réponse, avant que la véritable réponse n’arrive du serveur lui-même. Ainsi, le client utilisera alors, à son insu, l’adresse IP du pirate, en toute confiance, puisque de son point de vue, c’est bel et bien le serveur primaire de résolution de noms qui lui aura répondu.

Dans le second cas, il s’agit de faire accepter au serveur DNS des informations incorrectes qu’il stockera alors dans son cache. Pour réaliser cet exploit, le pirate doit utiliser une vulnérabilité du serveur DNS, consistant à lui faire ingérer des informations sans contrôle particulier, concernant l’origine des informations. Ainsi, lorsque le serveur DNS répond à ses clients, il le fait avec des données erronées et les clients sont alors redirigés vers la machine du pirate ou vers un site web falsifié (cas de phishing ou d’amorçage). En plus, grâce à l’empoisonnement du cache, l’attaquant peut rediriger toutes les machines utilisant le serveur DNS pollué, vers ce que bon lui semble.

À ces attaques, on peut également trouver des choses beaucoup plus radicales telles que :

  • Les attaques par déni de service (aussi appelé Denial of Service et abrégé en DoS) :

Le pirate rend le service de résolution de noms inopérant ou inaccessible en le saturant de requêtes afin de l’immobiliser.

  • Les attaques par réflexion :

L’attaquant émet de nombreuses requêtes avec le nom de sa "future" victime. Lorsque les destinataires répondent, ils contribuent ainsi à saturer les infrastructures de l’entreprise ciblée, à cause de la convergence des requêtes.

Voyons maintenant quelles solutions nous pouvons mettre en face de ces problématiques.

author avatar
Philippe PIERRE
A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail