Énumération DNS et sous-domaines

Le DNS est l'annuaire d'Internet : il traduit des noms lisibles en adresses. Pour un testeur, cet annuaire est aussi une mine d'indices, car il révèle quels serveurs existent, comment le courrier circule et quels services l'organisation a oubliés. Cette leçon vous montre comment l'interroger dans un cadre autorisé.

Dans la leçon précédente, vous avez appris à rassembler des informations sans toucher la cible. Nous passons ici à des interrogations directes. Rappel essentiel : toute requête dirigée vers les serveurs d'une organisation réelle est une action active, qui ne se fait que dans un périmètre autorisé. Dans ce cours, nous travaillons avec un domaine de test fictif (verdelune.test, une extension réservée à cet usage) servi par un petit serveur DNS que vous pouvez monter dans votre propre labo.

Rappel : comment fonctionne le DNS

Quand vous tapez un nom dans un navigateur, votre machine interroge un résolveur, qui interroge à son tour une chaîne de serveurs jusqu'au serveur faisant autorité pour le domaine. Ce serveur détient la « zone » : l'ensemble des enregistrements du domaine. Voici les types d'enregistrements qui intéressent un testeur :

Interroger un domaine : les bases

Deux utilitaires standards suffisent pour commencer : nslookup et dig. Voici des exemples sur le domaine fictif du labo (ils ne fonctionneront que si vous avez monté le serveur DNS de votre propre réseau interne) :

dig verdelune.test A
dig verdelune.test MX
dig verdelune.test NS
dig verdelune.test TXT
dig -x 192.168.56.20

Chaque commande interroge un type d'enregistrement. La dernière effectue une résolution inverse pour une adresse du labo. Observez la section de réponse : elle donne la valeur et une durée de vie (TTL) qui indique combien de temps l'information peut rester en cache.

Le transfert de zone : une mauvaise configuration à comprendre

Un serveur DNS faisant autorité doit parfois copier sa zone vers un serveur secondaire. Cette opération s'appelle un transfert de zone. Si le serveur accepte de répondre à n'importe qui, un observateur obtient d'un coup la liste complète des enregistrements du domaine, y compris des machines internes. C'est une erreur de configuration classique.

Dans un audit autorisé, on vérifie si le serveur de noms du client restreint correctement ces transferts. Dans votre labo, vous pouvez tester le comportement de votre propre serveur de noms :

dig @192.168.56.5 verdelune.test AXFR

Si le serveur répond avec la liste des enregistrements, la faille est constatée : la recommandation consiste à limiter les transferts aux seuls serveurs secondaires légitimes. Si la réponse est un refus, le serveur est correctement configuré. Dans les deux cas, vous avez simplement observé le comportement de votre serveur, et ce constat va dans le carnet de mission.

Découvrir des sous-domaines

Un domaine principal (verdelune.test) peut avoir de nombreux sous-domaines (www.verdelune.test, mail.verdelune.test, intranet.verdelune.test…). Beaucoup sont oubliés : un environnement de test créé il y a trois ans, un portail jamais mis à jour. Ce sont souvent les maillons les plus faibles. Plusieurs techniques permettent de les découvrir.

• Sources passives : registres de certificats publics, moteurs de recherche, archives. Elles n'envoient rien aux serveurs de la cible.
• Résolution par dictionnaire : un outil essaie une longue liste de noms courants (« www », « mail », « dev », « test », « vpn », « intranet ») et note ceux qui résolvent. C'est de la reconnaissance active : elle génère beaucoup de requêtes vers les serveurs DNS de la cible.
• Résolution inverse sur une plage : on interroge les enregistrements PTR de toutes les adresses d'une plage autorisée.
• Recoupement avec les certificats et les en-têtes : un certificat peut lister plusieurs noms alternatifs pour un même serveur.

Voici le principe d'une résolution par dictionnaire, illustré avec un simple script shell sur votre domaine de labo. Il ne contient aucune technique offensive : il pose les questions les plus banales à votre propre serveur de noms.

for nom in www mail dev test intranet vpn; do
  dig +short "$nom.verdelune.test" A
done

Les outils spécialisés font la même chose à plus grande échelle, avec des dictionnaires de milliers de noms. Retenez surtout la logique : on part d'un domaine autorisé, on énumère, puis on vérifie chaque résultat par rapport au périmètre.

Lire la carte DNS comme un testeur

Une fois les enregistrements collectés, il s'agit de les interpréter. Quelques questions à vous poser :

• Quelles adresses reviennent plusieurs fois ? Elles désignent souvent un même serveur qui héberge plusieurs services.
• Les noms évoquent-ils des environnements internes (« recette », « preprod », « admin ») exposés par erreur ?
• Y a-t-il des alias vers des services qui n'existent plus ? Un tel alias « orphelin » est une faiblesse connue que le client doit nettoyer.
• Les enregistrements TXT et MX révèlent-ils des prestataires, des protections anti-usurpation de messagerie ou leur absence ?

Ces observations enrichissent le carnet de mission et orientent le scan de ports, qui viendra à la leçon suivante.

Le point de vue défensif

Un défenseur retient de cette leçon plusieurs gestes simples : restreindre les transferts de zone, supprimer les enregistrements inutiles, surveiller les alias vers des services externes, éviter de publier des noms internes dans les zones publiques. Le DNS est trop souvent un angle mort : on le configure une fois et on l'oublie. Un audit régulier de ses propres zones est un excellent exercice d'hygiène.

À vous de jouer : cartographier le DNS de Verdelune

Si votre labo comprend un serveur DNS (ou si vous éditez simplement le fichier /etc/hosts de votre machine d'attaque pour simuler une zone), créez quelques enregistrements pour verdelune.test : un nom pour le serveur web, un pour le serveur de fichiers, un alias, et un nom volontairement trahissant un environnement de test. Puis :

1. Interrogez chaque type d'enregistrement avec dig et notez les résultats ;
2. Essayez une résolution par dictionnaire avec la boucle ci-dessus ;
3. Construisez dans votre carnet un tableau « nom, adresse, rôle probable, dans le périmètre (oui/non) ».

Nous savons désormais quels noms et quelles adresses existent. Reste à savoir quelles « portes » sont ouvertes sur chaque machine : c'est le rôle du scan de ports.