Introduction : DNS en tant que couche de sécurité stratégique

Bien que sa fonction centrale – résoudre les noms d'hôte respectueux de l'homme aux adresses IP lisibles par machine – soit indispensable pour la navigation sur le Web, le courrier électronique et pratiquement toutes les applications en réseau, DNS est devenu un outil puissant pour faire respecter la segmentation du réseau et définir les zones de sécurité. En tirant parti stratégiquement du DNS, les organisations peuvent contrôler le trafic est-ouest, isoler les charges de travail sensibles et créer des politiques d'accès granulaire qui réduisent la surface d'attaque.

Comprendre la segmentation des réseaux et les zones de sécurité

La segmentation du réseau consiste à diviser un réseau informatique en sous-réseaux distincts (segments ou zones) plus petits pour limiter le rayon de bouffée des brèches, contenir des mouvements latéraux et faire respecter l'accès le moins privilégié.

  • Segmentation physique[ utilisant des interrupteurs, des routeurs et des câbles séparés.
  • Segmentation logique[ par VLAN (IEEE 802.1Q) et sous-réseautage.
  • Segmentation virtuelle[ au sein des hyperviseurs utilisant des commutateurs virtuels et des espaces de noms de réseau.
  • Micro-segmentation au niveau de la charge de travail ou du conteneur, souvent entraîné par des politiques définies par logiciel.

Les zones de sécurité sont une forme spécifique de segmentation qui regroupe les actifs en fonction des niveaux de confiance et de sensibilité aux données.

  • Zone de confiance interne – contenant des bases de données RH, des serveurs de fichiers internes et des services d'annuaire.
  • Zone démilitarisée (DMZ) – hébergement de serveurs Web, passerelles de messagerie et proxys inversés.
  • Zone restreinte/sensible – pour les données réglementées par PCI-DSS ou HIPAA, avec des contrôles d'accès stricts.
  • Zone d'accueil/non-fidélité – réseaux isolés pour les visiteurs, les appareils IdO ou l'accès des entrepreneurs.

DNS agit comme couche d'orchestration centrale qui rend ces zones exécutoires et gérables à l'échelle. Lorsqu'un appareil d'un segment tente de résoudre un nom d'hôte appartenant à une zone différente, le résolveur DNS peut renvoyer une réponse --pas trouvée, rediriger vers un pot d'abeille ou autoriser une résolution seulement si une politique de sécurité spécifique est satisfaite.

Zones DNS et zones de sécurité : une relation symbiotique

Une zone DNS est un espace administratif dans la hiérarchie DNS qui contient des enregistrements de ressources pour un domaine ou sous-domaine spécifique. Par exemple, une organisation peut avoir un serveur DNS faisant autorité pour et un serveur séparé pour . Les zones de sécurité et les zones DNS se mapent souvent directement l'une sur l'autre :

  • Zone interne[ ([) – contient des enregistrements pour les bases de données de backend, les API internes et les contrôleurs de domaine Active Directory. Ces noms ne sont résolvables que par des appareils à l'intérieur du réseau de confiance.
  • Zone de la DMZ () – contient des dossiers pour les services publics tels que ou . L'accès à cette zone est généralement limité pour s'assurer que les requêtes provenant d'Internet ne peuvent pas s'infiltrer dans les espaces de noms internes.
  • () – utilisé pour les réseaux Wi-Fi invités isolés; ne résout que pour les services Internet et refuse les requêtes pour les serveurs internes.

Cette cartographie est réalisée par split-horizon DNS (également appelé DNS fractionné ou DNS fractionné). Dans un déploiement DNS fractionné, le même domaine (par exemple ) est desservi par deux serveurs faisant autorité différents, l'un pour les clients internes et l'autre pour les clients externes. Le serveur interne retourne des adresses IP privées (RFC 1918) pour les services internes, tandis que le serveur externe retourne des adresses IP publiques.

Par exemple, lorsqu'un employé dans la zone interne interroge , le résolveur DNS interne retourne . Si la même requête provient d'un serveur dans la DMZ, il reçoit soit une réponse différente (p. ex., l'IP public d'un proxy inversé) soit une erreur NXDOMAIN, faisant effectivement respecter la limite de sécurité.

Mise en œuvre du DNS dans les stratégies de sécurité

Les architectures de sécurité modernes reposent sur le DNS non seulement pour la résolution de noms, mais aussi comme un point d'application actif. Voici les principales stratégies d'intégration du DNS dans la segmentation du réseau et les zones de sécurité.

1. Ségrégation des zones et des zones

Déployer des serveurs DNS séparés pour chaque zone de sécurité. Utilisez les vues (dans BIND) ou les listes de contrôle d'accès au niveau de la zone pour s'assurer que :

  • Les serveurs DNS internes ne répondent qu'aux requêtes des sous-réseaux internes.
  • Les serveurs DMZ DNS ont un ensemble limité de transitaires (par exemple, uniquement pour les serveurs DNS racine) et sont interdits de requêter DNS interne.
  • Les transferts de zones sont limités aux serveurs secondaires autorisés au moyen de TSIG (Transaction Signatures) ou de LCA IP.

Pour les environnements utilisant Microsoft DNS, les zones intégrées Active Directory peuvent être couvertes par site, forêt AD ou sous-net. Cela permet l'enregistrement dynamique DNS pour les périphériques liés à un domaine tout en empêchant les périphériques voyous de s'enregistrer dans des zones sécurisées.

2. Filtrage DNS et routage fondé sur les politiques

Le filtrage DNS[ (bloquant ou redirigeant les requêtes vers des domaines malveillants connus) est une première ligne de défense, mais il supporte également la segmentation:

  • RPZ (Response Policy Zones) permet à un serveur DNS faisant autorité de réécrire les réponses pour certaines requêtes. Par exemple, si un périphérique de la zone invité tente de résoudre , RPZ peut renvoyer une réponse 0.0.0.0 ou rediriger vers un portail captif.
  • Le revêtement de NNS[ (redirection NXDOMAIN) empêche les paramètres dans les zones de faible confiance d'atteindre des serveurs de haute valeur, même si le paramètre a été compromis et tente d'utiliser un résolveur DNS différent.
  • Le routage basé sur les politiques peut être déclenché par la réponse DNS – par exemple, si une requête résout une IP dans une plage restreinte, le pare-feu supprime la connexion.

De nombreux pare-feu de nouvelle génération et passerelles Web sécurisées s'intègrent avec DNS pour faire appliquer le filtrage par catégorie, qui peut être cartographié vers des zones de sécurité. Par exemple, la zone invitée peut être limitée à des catégories -allowed--- (news, recherche, social) tandis que la zone interne permet l'accès à des applications non catégorisées ou personnalisées.

3. DNSSEC: Authenticité des données DNS dans les zones

DNSSEC (Domain Name System Security Extensions) signe des enregistrements DNS de manière à ce que les résolveurs puissent vérifier leur authenticité. Dans un réseau segmenté, DNSSEC s'assure qu'un attaquant ne peut pas spoof DNS réponses pour rediriger le trafic d'une zone de confiance vers un serveur malveillant.

  • Chaîne de confiance – une zone signée de la racine au domaine interne garantit que seul l'administrateur légitime de zone peut ajouter des enregistrements.
  • L'authentification du déni d'existence – Les enregistrements NSEC ou NSEC3 prouvent qu'un nom d'hôte n'existe pas, empêchant les attaquants de prétendre qu'un serveur interne inexistant est accessible.
  • Transferts de zone de sécurité[ – combinés avec TSIG, DNSSEC ajoute une couche supplémentaire de protection contre les fuites de données de zone.

Tout en mettant en œuvre DNSSEC ajoute des frais généraux opérationnels (gestion des clés, durée de vie des signatures), les entreprises qui traitent des données sensibles devraient les prioriser, en particulier pour les zones qui servent des ressources restreintes. Une ressource recommandée est Cloudflare="s guide sur le fonctionnement de DNSSEC.

4. Microsegmentation DNS et confiance zéro

Dans une architecture de confiance zéro, aucun appareil n'est intrinsèquement fiable; chaque demande d'accès doit être authentifiée et autorisée.

  • Résolution DNS combinée à l'identité de l'utilisateur[ – utilisant des solutions comme les politiques DNS de Microsoft ou des outils tiers, les administrateurs peuvent définir des règles telles que -Seuls les utilisateurs ayant un MFA et appartenant au groupe de sécurité HR peuvent résoudre .
  • ACL DNS dynamique – lorsqu'un contrôle de santé d'un appareil échoue, le serveur DNS peut temporairement supprimer son enregistrement ou refuser une résolution dans des zones sensibles.
  • Règles de pare-feu basées sur le RQQ – au lieu de règles basées sur l'IP (qui rompent avec l'adressage dynamique), les pare-feu peuvent inspecter la requête DNS et mettre en cache la cartographie IP-à-nom d'hôte pour faire appliquer les politiques.

Les environnements Conteneur et Kubernetes amplifient encore davantage cette situation : les services sont accessibles via des noms DNS (par exemple . En mettant en œuvre des politiques réseau qui limitent les pods qui peuvent résoudre les noms DNS, vous réalisez une micro-ségrégation sans gestion manuelle de l'IP.

Meilleures pratiques pour l'utilisation du DNS dans les zones de segmentation et de sécurité des réseaux

Pour maximiser les avantages du DNS en matière de sécurité tout en maintenant le rendement et la gérable, suivez ces pratiques exemplaires élargies.

Conventions relatives à la conception et à la désignation des zones

  • Alignez les noms de zone DNS avec les zones de sécurité. Par exemple, utilisez , , . Cela rend la création de politiques et la vérification simples.
  • Éviter les espaces de noms qui se chevauchent Ne pas placer les enregistrements internes sous un sous-domaine visible publiquement (p. ex. ) à moins que le DNS fractionné ne soit parfaitement isolé.
  • Utiliser des serveurs faisant autorité séparés par niveau de confiance. La séparation physique ou virtuelle empêche un compromis dans la DMZ d'affecter le serveur DNS interne.

Contrôle d'accès et restrictions de requête

  • Restriction des transferts de zone[ vers des IP secondaires autorisées uniquement. Utilisez les touches TSIG pour une authentification supplémentaire. Ne jamais autoriser toutes les IP (0.0.0.0/0) à effectuer des requêtes AXFR.
  • Limiter la récursion aux clients autorisés. Les résolveurs récursifs ouverts sont un risque de sécurité; configurer les transitaires ou utiliser des zones de stub à la place.
  • Block les requêtes DNS sortantes de zones de faible confiance – les réseaux invités ne devraient pouvoir que demander des serveurs DNS spécifiques. Utilisez les règles de pare-feu pour bloquer l'UDP/TCP 53 direct vers Internet, forçant toutes les requêtes via un résolveur configuré qui applique les politiques.

Surveillance et détection des anomalies

  • Logez toutes les requêtes et réponses DNS. Centralisez les journaux dans un système SIEM (Sécurité Information et Gestion des Événements). Cherchez des modèles inhabituels, comme un serveur dans la zone interne qui interroge un domaine dans la DMZ qu'il ne devrait jamais avoir besoin.
  • Alerte en temps réel pour les tentatives de transfert de zone non autorisées, les taux élevés de NXDOMAIN (réalisation possible) ou le tunnelage DNS (grandes requêtes d'enregistrement TXT).
  • Audit périodique des données de zone DNS – supprimer les enregistrements A et CNAME de l'impasse qui pourraient pointer vers des serveurs déclassés dans d'autres zones.

Intégration avec les pare-feu et le NAC

  • Utilisez DNS comme source pour les objets de pare-feu dynamiques.De nombreux fournisseurs de pare-feu peuvent cartographier un FQDN en une collection d'adresses IP et mettre à jour automatiquement les règles lorsque l'enregistrement DNS change.
  • Intégrer avec le contrôle d'accès réseau (NAC) – lorsqu'un appareil est mis en quarantaine (par exemple, parce qu'il manque un correctif de sécurité), sa résolution DNS doit être redirigée vers un jardin muré ou complètement refusée pour les requêtes internes de zone.

Redondance et résilience

  • Déployer plusieurs serveurs DNS par zone pour éviter un seul point de défaillance. Utilisez n'importe quelle adresse de diffusion pour les serveurs faisant autorité pour fournir un équilibre de charge et la résilience DDoS.
  • Scénarios de rupture de test – s'assurer que si le serveur DNS interne est inaccessible, les clients ne retombent pas accidentellement dans un résolveur externe qui pourrait fuir les noms internes.

Pièges courants et comment les éviter

Même une segmentation DNS bien conçue peut être minée par une mauvaise configuration.

  • Laisser des IP internes via DNS public – ne jamais publier d'adresses RFC 1918 dans des enregistrements DNS publics. Vérifiez toujours avec des outils comme DNSprompter.
  • Offre une requête récursive en acheminement depuis des zones non-confiées – si un client dans la zone invité peut utiliser un résolveur interne comme transitaire, il peut contourner efficacement la segmentation. Isoler les résolveurs par zone.
  • Ignorer IPv6 – de nombreuses politiques de segmentation ne couvrent que les enregistrements DNS IPv4. Assurez-vous que les enregistrements AAAA sont également gérés de façon appropriée et que le trafic IPv6 ne peut contourner les contrôles basés sur DNS.
  • Sur-relying on DNS for security without defense in profond – DNS est un puissant exécuteur, mais il devrait être complété par des pare-feu réseau, la prévention des intrusions basée sur l'hôte et les contrôles d'identité.

Ressources externes pour la lecture supplémentaire

Pour des implémentations plus détaillées, veuillez consulter ces sources faisant autorité :

Conclusion

En alignant délibérément les zones DNS avec les zones de sécurité, en appliquant la résolution de l'horizon fractionné, en appliquant la DNSSEC et en surveillant les modèles de requêtes, les organisations peuvent contenir des failles, empêcher les mouvements latéraux et appliquer des politiques d'accès granulaire sans exiger une planification massive des adresses IP. La clé est de traiter DNS comme un contrôle de sécurité de première classe, intégré aux pare-feu, aux systèmes d'identité et aux politiques d'accès au réseau.