Serveurs DNS ouverts - Pratiques exemplaires

Number: TR13-002
Date: 8 Avril 2013

1. Public cible

Le présent rapport est destiné aux professionnels et gestionnaires de la TI des gouvernements provinciaux, territoriaux et des administrations municipales, ainsi que des infrastructures essentielles et des industries connexes. Il présuppose que le lecteur maîtrise les bases du service DNS. Les personnes ayant obtenu le présent produit peuvent le divulguer aux responsables techniques de leur organisme.

2. Objet

Le présent rapport vise à présenter au personnel de la sécurité des TI les pratiques exemplaires en matière de configuration sécurisée du système de noms de domaine (DNS) et des serveurs DNS ouverts. Il vise à aider les responsables des systèmes à cerner les serveurs DNS potentiellement vulnérables et à atténuer les risques associés, comme les attaques par empoisonnement de cache ou par réflexion et amplification. Ce document est destiné aux administrateurs de système, aux équipes d'intervention en cas d'incident informatique (EIII), aux Centres des opérations de sécurité informatique et aux autres groupes technologiques connexes.

3. Service DNS

Le protocole DNS (Domain Name System) constitue une base de données distribuée, hiérarchique et dynamique servant surtout à établir la correspondance entre noms de domaine, comme www.publicsafety.gc.ca, et adresses IP, comme 198.103.108.123. Il existe deux types de serveurs DNS : les serveurs faisant autorité et les serveurs récursifs. Un serveur DNS faisant autorité fournit une réponse à partir d'un enregistrement originel qu'il détient. Un serveur récursif donne la réponse aussi sans disposer d'un enregistrement originel, soit à partir de sa cache de réponses déjà fournies, soit en interrogeant d'autres serveurs DNS au nom de son client.

On exploite souvent le service DNS aux fins d'attaque, car il se sert surtout du protocole UDP (User Datagram Protocol), un protocole sans état qui n'établit pas de liaison entre l'expéditeur et le destinataire, ce qui le rend vulnérable aux attaques de type mystification de l'expéditeur et condition de concurrence. Quoiqu'indépendantes de la conception du protocole DNS, ces faiblesses peuvent avoir une incidence sur la configuration et l'utilisation du service DNS. Parmi les attaques exploitant le service DNS, les plus courantes consistent en attaques par empoisonnement de cache ou des attaques par réflexion et amplification, qui peuvent entraîner un déni de service. Malgré ces vulnérabilités, le service DNS reste vital au bon fonctionnement d'Internet, et on peut souvent le configurer de façon sécuritaire.

Figure 1 Fonctionnement récursif normal d'un serveur DNS ouvert

Fonctionnement récursif normal d'un serveur DNS ouvert
Description de l'image

La figure ci-dessus montre le fonctionnement récursif normal d'un serveur DNS ouvert dont les étapes sont décrites ci-après.

  1. L'utilisateur interroge un serveur DNS ouvert pour connaître l'adresse IP de www.xyz.domain.com.
  2. Le serveur DNS ouvert transfère la requête à un serveur racine DNS.
  3. Le serveur racine DNS répond qu'il ne connaît pas cette adresse mais qu'il peut identifier le domain .com.
  4. Le serveur DNS ouvert transfère la requête au serveur DNS faisant autorité pour le domaine .com.
  5. Le serveur DNS faisant autorité pour le domaine .com ne peut répondre à la requête mais connaît le serveur faisant autorité pour www.xyz.domaine.com.
  6. Le serveur DNS ouvert transfère la requête au serveur faisant autorité pour www.xyz.domain.com.
  7. Le serveur faisant autorité pour www.xyz.domain.com donne l'adresse IP.
  8. Le serveur DNS ouvert retourne la réponse à l'utilisateur à l'origine de la requête.

3.1 Attaques par réflexion et amplification

Les attaques par réflexion exploitent les serveurs DNS récursifs afin de transmettre des paquets de requête DNS dont l'adresse IP d'origine a été mystifiée pour correspondre à celle de la victime ciblée. Le serveur DNS ouvert renvoie alors bien innocemment à la victime les messages de réponse DNS; l'attaque est amplifiée par un rapport démesuré entre le message de requête et le torrent de réponses reçues, ce qui entraîne un déni de service. À la taille modeste du paquet de requête, au plus 64 octets, correspond un message de réponse pouvant atteindre 512 octets, ce qui donne un facteur d'amplification de 8 pour 1. Ce facteur dépend aussi de l'utilisation par l'attaquant d'une extension du protocole DNS appelée Extension Mechanisms for DNS (EDNSONote de bas de page 1), auquel cas le facteur d'amplification peut atteindre 70 pour 1. L'attaquant exploite alors de multiples serveurs DNS ouverts afin d'amplifier son attaque et d'écraser le serveur ciblé; de plus, mystifier les adresses d'origine complique l'identification de la source de ces attaques.

Figure 2 Attaque par réflexion et amplification DNS

Attaque par réflexion et amplification DNS
Description de l'image

La figure ci-dessus montre le fonctionnement d'une attaque par réflexion et amplification DNS dont les étapes sont décrites ci-après.

  1. Un attaquant active un botnet. Il s'agit d'un groupe d'hôtes compromis formant un réseau d'ordinateurs zombies.
  2. Le botnet achemine de multiples requêtes pour demander l'adresse IP de www.xyz.domain.com à divers serveurs DNS ouverts en utilisant une adresse IP d'origine qui a été mystifiée.
  3. Le serveur DNS ouvert transfère la requête à un serveur racine DNS.
  4. Le serveur racine DNS répond qu'il ne connaît pas cette adresse mais qu'il peut identifier le domain.com.
  5. Le serveur DNS ouvert transfère la requête au serveur faisant autorité pour .com.
  6. Le serveur DNS faisant autorité pour le domaine .com ne peut répondre à la requête mais connaît le serveur faisant autorité pour www.xyz.domain.com.
  7. Le serveur DNS ouvert transfère la requête au serveur faisant autorité pour www.xyz.domain.com.
  8. Le serveur faisant autorité pour www.xyz.domain.com donne l'adresse IP.
  9. De multiples serveurs DNS ouverts retournent la réponse à l'adresse IP d'origine qui a été mystifiée mais qui est en réalité celle de la victime de l'attaque. Chaque paquet de réponse est amplifié par un facteur pouvant atteindre 70, ce qui entraîne un déni de service.

3.2 Attaques par empoisonnement de cache DNS

Pour mettre en œuvre une attaque par empoisonnement de cache DNS, un attaquant insère un enregistrement de domaine et d'adresse frauduleux dans la cache d'un serveur DNS. Cela découle de la réception d'une fausse réponse avant celle du serveur légitime, réponse dont le port d'origine, l'identificateur l'adresse IP et le nom de la requête correspondent à la bonne. En conséquence, les internautes sont redirigés vers un domaine qui peut être malveillant.

4.0 Serveurs DNS ouverts

Un serveur DNS ouvert répond à des demandes récursives provenant de tout poste à l'extérieur de son domaine. Par défaut, la plupart des serveurs DNS sont configurés de façon récursive; comme ces réglages sont souvent ignorés par les administrateurs, cela transforme un tel serveur en cible de choix à exploiter pour mener des attaques où l'adresse IP d'origine a été mystifiée.

L'exploitation d'un serveur DNS ouvert n'est pas recommandée, à moins de le configurer et d'en surveiller l'utilisation de façon à prévenir tout abus. On trouve dans Internet bon nombre de serveurs DNS ouverts ou publics, comme le serveur DNS de Google (à l'adresse 8.8.8.8).

4.1 Essais de serveurs DNS ouverts

Plusieurs outils permettent de savoir si votre serveur est ouvert.

4.1.1 Outils en ligne

Measurement Factory a rendu disponible en ligne un essai de serveur DNS ouvert qui envoie une requête récursive à une ou plusieurs adresses. Si l'une de ces requêtes est transmise au serveur faisant autorité pertinent, le serveur DNS l'ayant transmis est ouvert.
http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl

Autres tests accessibles :
Test DNS de l'ISC
https://isc.sans.edu/dnstest.html

Test DNS de Thinkbroadband
http://www.thinkbroadband.com/tools/dnscheck.html

Projet Open DNS Resolver
http://openresolverproject.org/

4.1.2 Vérification par l'invite de commande

Vous pouvez aussi, selon le système d'exploitation utilisé, vérifier l'état de votre serveur DNS directement à l'invite de commande :

Unix et SE dérivés, notamment Linux
#dig +short amiopen.openresolvers.org TXT
Windows
$ nslookup
   > set type=TXT
   > amiopen.openresolvers.org
Le SE devrait afficher la réponse suivante :
"Your resolver at ip.add.re.ss is CLOSED"

Recommandations

Voici quelques conseils qui vous aideront à atténuer les risques de voir l'infrastructure DNS exploitée pour mener des attaques par réflexion et amplification. Si la récursion DNS ouverte n'est pas nécessaire dans votre infrastructure, la solution la plus efficace reste de la désactiver et de filtrer les requêtes entrantes, tel que décrit dans les documents BCP 38Note de bas de page 2/ et BCP 84Note de bas de page 3.

5.1 Désactivation de la récursion DNS ouverte

Les serveurs DNS les plus couramment utilisés sont BIND et Microsoft. Voici des pages Web (en anglais) qui décrivent comment désactiver la récursion DNS :

BIND
http://www.cymru.com/Documents/secure-bind-template.html

Serveur DNS de Microsoft
http://technet.microsoft.com/en-us/library/cc771738.aspx

5.2 Filtrage des requêtes entrantes

Filtrer les requêtes entrantes  permet d'éviter la plupart des attaques par déni de service ou déni de service distribué entraînées par les attaques par réflexion et amplification. Nous encourageons les exploitants des réseaux à mettre en place un filtrage, tel que décrit dans les documents techniques BCP 38 – Network Ingress Filtering (filtrage des requêtes entrantes) et BCP 84 – Ingress Filtering for Multihomed Networks (filtrage des requêtes entrantes pour réseaux à accès multiples) afin de vérifier si l'adresse fait partie d'une plage d'adresses préétablie accessible par l'interface d'entrée. Tout paquet ne respectant pas les critères fixés est ignoré. Cela réduit considérablement les chances de réussite d'une attaque utilisant une adresse externe mystifiée. Les attaques qui utilisent une adresse d'origine à l'intérieur de la plage d'adresses autorisées risquent de réussir quand même, mais dans ce cas, il sera plus facile au responsable du réseau d'atténuer l'attaque et d'en cerner la source.

5.3 Configuration des serveurs DNS

Voici quelques-unes des pratiques exemplaires en configuration de serveurs DNS à envisager dans le contexte de votre propre environnement réseau :

6. Configuration sécuritaire d'un serveur DNS ouvert

Malgré le risque d'être exploités de façon malveillante, bon nombre de serveurs DNS ouverts restent accessibles à un grand nombre d'internautes. Les conseils de configuration suivants visent à vous aider à réduire les risques qu'un serveur DNS ouvert dont vous êtes responsable soit exploités de façon abusive.

6.1 Restriction du débit

Limitez le débitNote de bas de page 4 Note de bas de page 5, des serveurs DNS faisant autorité à un nombre préétabli de paquets DNS de réponse identiques. Cela réduit considérablement le nombre de paquets de réponse DNS envoyés à la victime, sans incidence sur les requêtes DNS légitimes. Le réglage du nombre de paquets par secondes varie selon la charge normale du serveur DNS et selon que la traduction d'adresses de réseau (fonction NAT) a été configurée ou non. Mesurez la charge de base normale de votre serveur, et limitez le débit en conséquence (tout trafic au-delà de cette charge risque de faire partie d'une attaque par réflexion et amplification. Le serveur répondra quand même aux requêtes légitimes, mais ses réponses seront courtes et succinctes, ce qui forcera un client à réessayer avec le protocole TCP. 

6.2 Défense contre l'empoisonnement de cache

6.2.1 Utilisation de données non évidentes dans les requêtes envoyées

Pour empoisonner la cache d'un serveur DNS, un attaquant doit deviner correctement le port d'origine, l'identificateur de requête, l'adresse IP et le nom de requête de la requête légitime originelle. Or, un attaquant aura plus de difficulté à deviner les bonnes données si elles diffèrent de celles auxquelles on s'attend. L'utilisation de données non évidentes dans les requêtes envoyées donnera plus de difficulté à un attaquant qui tente de deviner les bonnes données. La plupart des serveurs DNS modernes randomisent déjà le port d'origine et l'identificateur de requête; il est donc vital de tenir à jour vos serveurs DNS. Voici quelques conseils sur l'utilisation de données non évidentes dans les requêtes envoyées.

Port d'origine aléatoire

N'envoyez jamais une requête externe par le port UDP 53, mais choisissez plutôt au hasard parmi un grand nombre de ports non enregistrés. Il faut toutefois désactiver la dérandomisation des ports si vous utilisez un dispositif NAT.

Identificateur de requête aléatoire

Configurez votre serveur DNS pour qu'il attribue un nombre aléatoire à toute requête DNS envoyée.

Nom de requête en casse aléatoire

Les serveurs DNS ignorent habituellement la casse; en d'autres termes, les domaines xyz.edu et XYZ.edu correspondent à la même adresse IP. En outre, les serveurs DNS faisant autorité renvoient une réponse dans la même casse que celle transmise par un serveur récursif. Basculer aléatoirement, dans le nom de domaine demandé, entre minuscules et majuscules, ou utiliser un masque 0x20Note de bas de page 6 Note de bas de page 7, compliquera considérablement la tâche d'un attaquant voulant reproduire le nom de domaine.

Choix aléatoire de serveurs DNS

Les serveurs DNS ouverts utilisent habituellement le chemin le plus court pour choisir le serveur DNS à interroger. Choisir au hasard parmi les serveurs DNS connus compliquera encore plus la tâche d'un attaquant potentiel, car il devra deviner le serveur interrogé s'il veut empoisonner la cache de votre serveur.

7. Conclusion

Le service DNS est vital au bon fonctionnement d'Internet, et il faut porter une attention particulière à la sécurisation de ce service vital. Cependant, comme bien d'autres technologies d'Internet, DNS n'a pas été conçu en fonction de l'environnement diversifié et souvent hostile qu'est devenu Internet. Par conséquent, il importe de protéger ce service à l'aide des outils et pratiques exemplaires actuels. Mettre en place des mesures de sécurité, comme celles décrites dans le présent document, peut atténuer les risques associés à l'utilisation abusive es serveurs DNS.

8. Références


Note aux lecteurs

En appui à la mission de Sécurité publique Canada de bâtir un Canada sécuritaire et résilient, le mandat du CCRIC est d'aider à assurer la sécurité et la résilience des cybersystèmes essentiels non gouvernementaux à la base de la sécurité nationale, de la sécurité publique et de la prospérité économique du pays. À titre d'équipe d'intervention en cas d'incident lié à la sécurité informatique du Canada, le CCRIC agit comme centre national de coordination pour la prévention, l'atténuation, l'intervention et le rétablissement liés aux incidents cybernétiques commis contre des systèmes non fédéraux. Pour ce faire, il formule des conseils éclairés, offre du soutien et coordonne l'échange de renseignements ainsi que l'intervention.

S'il vous plaît noter que la clé PGP du CCRIC a récemment été mise à jour.
http://www.securitepublique.gc.ca/cnt/ntnl-scrt/cbr-scrt/_fl/CCIRCPublicPGPKey.txt

Pour obtenir des renseignements de nature générale, veuillez communiquer avec la division des Affaires publiques de l'organisme :

Téléphone : 613-944-4875 ou 1-800-830-3118  
Télécopieur : 613-998-9589 
Courriel : ps.communications-communications.sp@canada.ca

Notes de bas de page

  1. 1

    http://www.rfc-editor.org/rfc/rfc2671.txt

  2. 2

    http://tools.ietf.org/html/bcp38

  3. 3

    http://www.ietf.org/rfc/rfc3704.txt

  4. 4

    http://ss.vix.com/~vixie/isc-tn-2012-1.txt

  5. 5

    http://ss.vix.su/~vjs/rl-arm.html

  6. 6

    http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

  7. 7

    http://courses.isi.jhu.edu/netsec/papers/increased_dns_resistance.pdf

Date de modification :