Sécuriser une infrastructure DNS pour ADDS

Dans cet article, nous traiterons de la mise en œuvre d’une architecture DNS ayant pour rôle de sécuriser la zone DNS d’une infrastructure Active Directory. Cet article adresse principalement un risque de sécurité pour les petites structures qui expose directement le serveur DNS à internet.

Pourquoi utiliser un serveur DNS intermédiaire ?

C’est avant une bonne pratique de sécurité : un contrôleur de domaine est un élément critique et sensible de votre infrastructure, par conséquent vous devez l’isoler des réseaux non contrôlé.

D’autre part, lorsque l’on parle d’un serveur DNS qui est maître d’une zone DNS Active Directory, les données contenues sont également sensibles. Hors, le serveur répondra à n’importe-quelle interrogation DNS, sans distinction du moment qu’elle remplie ses conditions de sécurité propre : si un attaquant extérieur parvient à réaliser une interrogation, il peut obtenir toutes les informations utiles à une future attaque ; les informations comme la topologie de votre annuaire lui donneront des axes pour préparer ses déplacements latéraux tout en restant sous le radar.

Enfin, cela permet également de fluidifier le trafic DNS : chaque DNS héberge un cache et la mise en œuvre d’un serveur intermédiaire vous permettra également de créer de nouvelles zones DNS que vous pourrez exploiter sans divulguer d’information sur votre architecture. Par exemple, mon serveur WSUS est ainsi installé dans une zone isolée et n’est pas adhéré à mon domaine : j’ai créé une zone sur mon serveur intermédiaire pour pouvoir l’accéder plus simplement. En cas de compromission du serveur, la seule information dont disposera l’attaquant sur le plan DNS est une zone sans intérêt et un serveur DNS qui ne peut pas accéder à mon serveur DNS interne.

Architecture à triple surface d’exposition

Pour ne pas exposer directement un contrôleur de domaine hébergeant un serveur DNS, nous mettons en œuvre un serveur DNS de rebond sur chaque surface d’attaque potentiel :

En Tiers 3, le serveur est exposé à un réseau à risque (internet par exemple) et permet de traiter les demandes vers les partenaires public (DNS de FAI, …).

En Tiers 2, le serveur sert d’intermédiaire entre le réseau de confiance et internet : il est également exposé à des clients dont le niveau de sécurité ne peut être intégralement garanti (application exposés sur internet, client externe, …).

En Tiers 1, le serveur est exposé à un réseau connu et des clients identifiés sur un réseau de confiance.

Pour le DNS de tiers 3, vous pouvez sélectionner n’importe quel serveur DNS public. Veillez toutefois à en choisir un de confiance : ceux de google par exemple, très répandu, ne sont pas “librement offert” mais collecte les requêtes qui leurs sont transmises pour générer des statistiques… D’autre part, toutes vos requêtes vers le niveau 3 peuvent être analysées et donner des informations sur vos habitudes d’accès (création de site de hameçonnage, etc.) : il est donc important de sélectionner des serveurs DNS robustes.

Personnellement, je choisi la solution de Cisco OpenDNS (www.opendns.com) qui offre plusieurs solutions (de la gratuite à la payante) avec une sécurité accrue et la possibilité de filtrer la nature des requêtes à traiter (filtre de catégorie comme par exemple la pornographie).

Une fois votre solution retenue et paramétrée, consignez les adresses de vos serveurs pour une future utilisation (dans mon cas, 208.67.222.222 et 208.67.220.220) puis configurer votre firewall pour n’autoriser le trafic DNS qu’à destination de ces nouvelles adresses (UDP 53).

Pour cette démonstration, l’architecture retenue sera la suivante :

 

  1. Les clients du domaine interrogent le serveur DNS du contrôleur de domaine.
  2. Le serveur DNS redirige vers le proxy DNS les requêtes qu’il ne peut pas traiter (redirection inconditionnelle).
  3. Le proxy DNS interrogent les serveurs DNS d’OpenDNS qui retourne la réponse au Proxy DNS.

Installation du Proxy DNS

Une fois votre serveur Windows Server 2016 Standard installé et configuré, ouvrez une invite de commande PowerShell en mode administrateur ; la première action sera d’installer le rôle de serveur DNS et les outils d’administration :

Install-WindowsFeature -Name DNS -IncludeManagementTools

Le serveur requiert maintenant d’être configuré pour permettre le transfert des requêtes vers nos DNS Public : Lancez la console DNS du serveur (dnsmgmt.msc). Faites-un clic-droit sur le nom du serveur et sélectionnez propriétés :

  • Dans l’onglet interfaces, sélectionnez uniquement les adresses IP suivantes et sélectionnez l’adresse d’écoute de votre serveur.
  • Dans l’onglet redirecteurs, cliquez sur modifier… puis ajoutez les serveurs publics de références que vous avez retenu (dans mon cas, ceux d’OpenDNS). Décocher la case utiliser les indications de racine si aucun redirecteur n’est disponible.
  • Dans l’onglet avancé modifiez l’option charger les données de zone au démarrage avec la valeur à partir d’un fichier. Activez l’option Activer le nettoyage automatique des enregistrements obsolètes et fixez le délai de nettoyage à 1 heure.
  • Cliquez sur OK pour finaliser la configuration.

Dès à présent, le serveur est en mesure de traiter des requêtes publics : vous pouvez le vérifier en utilisant la commande nslookup, par exemple :

Nslookup ms-sec.fr <adresse ip du serveur>

N’oubliez pas de reconfigurer ensuite l’interface réseau du serveur : le client DNS que celui-ci utilise ne devrait en aucun cas être le contrôleur de domaine hébergeant le rôle DNS mais un serveur DNS auxiliaire (ou aucun).

Configuration du contrôleur de domaine

Une fois le proxy DNS en place, il nous reste à modifier la configuration DNS de notre domaine de sorte que les requêtes que nous savons pas traitées soient envoyée vers notre Proxy DNS. Lancez la console DNS hébergeant la zone de votre domaine (dnsmgmt.msc).

Faites-un clic-droit sur le nom du serveur et sélectionnez propriétés :

  • Dans l’onglet redirecteurs, remplacer les entrées en place par l’adresse de votre serveur proxy DNS. Décocher la case utiliser les indications de racine si aucun redirecteur n’est disponible.

Une fois la configuration en place, vérifier que votre service est opérationnel en lançant une commande depuis un poste client (nslookup ms-sec.fr par exemple).

Proxy DNS : perte des redirecteurs par défaut

Il peut arriver pour diverse raison que votre solution de DNS public soit non-opérationnelle. Dans la configuration actuelle, vous ne seriez alors plus en mesure de résoudre des noms DNS tel qu’adresse de site web, domaine de messagerie,… Dans ce cas, il est possible de configurer le proxy pour que celui-ci réoriente le trafic DNS vers des serveurs DNS de secours.

Pour réaliser cette opération, j’utilise en général les serveurs DNS du FAI qui porte mon accès internet et je configure le serveur proxy de sorte qu’il les utilise lorsqu’il n’obtient pas de réponse du redirecteur par défaut.

Lancez la console DNS du serveur (dnsmgmt.msc) puis faites-un clic-droit sur le nom du serveur et sélectionnez propriétés :

  • Dans l’onglet redirecteurs, cocher la case utiliser les indications de racine si aucun redirecteur n’est disponible.
  • Dans l’onglet indications de racine, supprimer les entrées existantes. Cliquez sur ajouter puis entrez le nom du serveur DNS de votre FAI. Cliquez sur résoudre pour transformer le nom en adresse, puis OK pour terminer. Répétez l’opération pour chacun des serveurs DNS à ajouter.
  • Cliquer sur OK une dernière fois pour finaliser la configuration

Le mot de la fin

J’espère que ce petit article aidera à mieux sécuriser vos infrastructures sans pour autant avoir recours à des solutions complexes ou onéreuse : rappelez vous que le proxy DNS peut parfaitement être une machine Linux (donc sans coût additionnel sur un hyperviseur). Il s’agit d’une configuration sans réel hardening, mais bien suffisante pour protéger à minima un annuaire : avec plus de temps et de réflexion, il est tout à fait possible de sécuriser davantage votre serveur DNS !

Lien Permanent pour cet article : https://ms-sec.fr/?p=1287

Laisser un commentaire

Votre adresse ne sera pas publiée.

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