La résolution DNS et la gestion des ports TCP constituent deux couches de sécurité souvent traitées séparément dans les politiques réseau des entreprises. Le cloisonnement de ces deux sujets crée pourtant des angles morts exploitables : un pare-feu peut filtrer correctement le port 53 tout en laissant passer des requêtes DNS encapsulées dans du trafic HTTPS sur le port 443. Comprendre comment ces mécanismes interagissent permet de durcir la configuration réseau sans multiplier les outils.
DNS chiffré sur port 443 : la faille que le filtrage classique ne voit pas
Le filtrage DNS traditionnel repose sur l’inspection du trafic transitant par le port UDP/53 ou TCP/53. Cette approche fonctionnait tant que les requêtes DNS circulaient en clair sur un canal dédié.
Le DNS-over-HTTPS (DoH), transporté sur le port TCP 443, change la donne. Les requêtes DNS sont encapsulées dans du trafic HTTPS standard, ce qui les rend indiscernables du reste de la navigation web pour un pare-feu configuré uniquement sur la base des numéros de ports. Le DNS-over-TLS (DoT), qui utilise généralement le port TCP 853, pose un problème similaire mais reste plus facile à identifier et à bloquer.
Selon des recommandations relayées par la CISA et Axio Networks, une politique de filtrage DNS efficace doit désormais imposer les résolveurs autorisés sur chaque terminal, y compris les navigateurs qui activent le DoH par défaut. Il ne suffit plus de surveiller le port 53 : les sorties vers les ports 443 et 853 doivent aussi être contrôlées pour détecter les résolutions DNS non autorisées.
Vous trouverez des informations techniques sur Open Syd qui détaillent les mécanismes de durcissement applicables à ces configurations.
Port TCP 53 et pare-feu : pourquoi bloquer TCP provoque des pannes DNS
Une erreur fréquente dans la configuration des pare-feu consiste à n’autoriser que le trafic UDP sur le port 53, en bloquant TCP/53. La logique semble raisonnable : la grande majorité des requêtes DNS courantes utilisent UDP.
En pratique, TCP/53 reste nécessaire pour les réponses DNS volumineuses. Les enregistrements DNSSEC, qui ajoutent des signatures cryptographiques aux réponses, dépassent régulièrement la limite de taille des paquets UDP. Les transferts de zone entre serveurs DNS autoritaires utilisent aussi exclusivement TCP. Bloquer ce protocole sur le port 53 provoque des pannes intermittentes difficiles à diagnostiquer, parce qu’elles ne se manifestent que pour certains types de requêtes ou certains domaines.
La documentation Cisco sur les prérequis DNS pour Cisco Secure Access distingue trois rôles réseau, chacun nécessitant des règles de pare-feu différentes sur le port 53 :
- Le poste client, qui envoie des requêtes au résolveur récursif interne, peut se limiter à UDP/53 dans la plupart des cas
- Le résolveur récursif doit pouvoir émettre et recevoir en TCP/53 et UDP/53 vers les serveurs faisant autorité, sous peine de ne pas résoudre les enregistrements signés DNSSEC
- Le serveur faisant autorité nécessite TCP/53 ouvert pour les transferts de zone et les réponses volumineuses
Appliquer une règle uniforme à ces trois rôles revient à fragiliser la résolution de noms ou à ouvrir des canaux inutiles.
Politique de sécurité réseau : dépasser le filtrage par numéro de port
Le port 443 n’est plus un indicateur fiable d’un usage web classique. Le DoH y transite, mais aussi des tunnels VPN, des flux applicatifs propriétaires et certaines solutions de sécurité DNS elles-mêmes. Une stratégie fondée sur les seuls numéros de ports laisse passer du trafic non identifié.
Une approche plus robuste combine plusieurs paramètres de contrôle :
- L’identification des résolveurs DNS autorisés par leur adresse IP, avec blocage de tout autre résolveur sur les ports 53, 443 et 853
- L’inspection des certificats TLS pour distinguer le DoH légitime du trafic web standard sur le port 443
- La surveillance applicative qui identifie le protocole réel indépendamment du port utilisé, permettant de détecter un tunnel DNS encapsulé dans du HTTPS
- Le contrôle des paramètres de configuration des navigateurs pour empêcher l’activation automatique du DoH vers des résolveurs externes
Cette logique de défense en profondeur exige de traiter le DNS non pas comme un service isolé, mais comme un composant transversal du système d’information. Les règles de routage, la gestion des applications installées sur les postes et la configuration des systèmes d’exploitation participent toutes à la posture DNS de l’entreprise.
Surveillance DNS et détection des flux anormaux sur le réseau
Le renforcement des règles de pare-feu ne couvre qu’une partie du problème. Un résolveur DNS interne compromis, ou un logiciel malveillant qui utilise le DNS comme canal d’exfiltration de données, peut générer du trafic conforme aux règles de filtrage tout en étant malveillant.
La surveillance du volume et de la fréquence des requêtes DNS constitue un complément nécessaire. Un poste qui émet plusieurs milliers de requêtes vers un même domaine en quelques minutes présente un comportement atypique qui mérite investigation. De même, des requêtes vers des noms de domaine à entropie élevée (chaînes de caractères aléatoires) signalent souvent un tunnel DNS ou une communication avec un serveur de commande et contrôle.
Les retours terrain divergent sur le seuil à partir duquel ces alertes deviennent exploitables sans générer trop de faux positifs. La taille du réseau, le nombre de postes et la diversité des applications métier influencent directement le calibrage. Un système de surveillance DNS mal calibré génère du bruit qui finit par être ignoré par les équipes de sécurité.
La corrélation entre les journaux DNS et les journaux de pare-feu (ports TCP ouverts, connexions sortantes inhabituelles) permet de réduire ce bruit. Un pic de requêtes DNS vers un domaine inconnu, combiné à une connexion TCP sortante sur un port non standard depuis le même poste, produit une alerte bien plus fiable qu’un indicateur isolé.
Le durcissement DNS et la maîtrise des ports TCP ne sont pas deux chantiers distincts. Les données disponibles montrent que les attaques récentes exploitent précisément la jonction entre ces deux couches, là où le DNS chiffré traverse des ports considérés comme sûrs. Traiter ces sujets ensemble, dans une politique de sécurité réseau unifiée, reste la seule approche qui tient compte de la réalité du trafic actuel.
