Un serveur DNS qui répond à toutes les requêtes sans distinction, des ports ouverts par défaut que personne n’a revus depuis la mise en service : on retrouve ce schéma dans la majorité des réseaux d’entreprise. La sécurité réseau se joue souvent sur ces deux axes négligés, la gestion des DNS et le contrôle des ports TCP, bien avant l’achat d’un pare-feu de nouvelle génération.
Contrôle des résolveurs DNS : le premier verrou à poser sur le réseau
Sur le terrain, le problème commence presque toujours au même endroit. Les postes de travail et les objets connectés envoient leurs requêtes DNS vers n’importe quel résolveur, y compris des résolveurs publics que l’administrateur ne supervise pas. Tant qu’on n’a pas restreint les résolveurs autorisés, on laisse un canal de sortie invisible.
La première action consiste à forcer tout le trafic DNS vers un résolveur interne maîtrisé. On bloque les requêtes sortantes sur le port UDP et TCP 53 vers toute destination autre que ce résolveur. Cela permet de journaliser chaque requête, de détecter les domaines suspects et de couper les communications vers des serveurs de commande et contrôle (C2).
Le chiffrement DNS complexifie cette approche. DNS over HTTPS (DoH) utilise le port TCP 443, le même que le trafic web classique, ce qui le rend difficile à filtrer avec des règles réseau traditionnelles. DNS over TLS (DoT) passe par le port TCP 853, plus facilement identifiable.
Pour garder la main, on peut apprendre le fonctionnement d’Open Syd et choisir une stratégie adaptée : autoriser DoT sur le port 853 vers le résolveur interne tout en bloquant DoH sur les postes pour éviter que les navigateurs court-circuitent la politique DNS de l’organisation.
Ports TCP ouverts : auditer avant de filtrer
On voit régulièrement des serveurs avec des dizaines de ports en écoute, dont certains correspondent à des services installés par défaut et jamais utilisés. Chaque port ouvert est une surface d’attaque potentielle. Le réflexe consiste à scanner son propre périmètre avant qu’un attaquant ne le fasse.
Un audit des ports TCP et UDP actifs, réalisé depuis l’extérieur du réseau, révèle souvent des services oubliés : une interface d’administration sur un port non standard, un service de base de données exposé, un ancien serveur mail encore joignable. Fermer un port inutile réduit le risque plus efficacement qu’une règle de détection.
Prioriser la fermeture par niveau de risque
Tous les ports ouverts ne présentent pas le même danger. Voici une approche de tri pragmatique :
- Les ports liés à l’administration distante (SSH sur 22, RDP sur 3389, interfaces web sur 8080 ou 8443) doivent être restreints à des plages IP internes ou accessibles uniquement via VPN. Les laisser exposés sur Internet reste la première cause de compromission par force brute.
- Les ports de services de messagerie (25, 465, 587, 993) méritent un filtrage géographique strict si l’activité est locale, et une vérification que les protocoles de chiffrement TLS sont activés pour protéger les données en transit.
- Les ports utilisés par des protocoles non chiffrés (Telnet sur 23, FTP sur 21, HTTP sur 80) devraient être désactivés au profit de leurs équivalents sécurisés. Si un service legacy impose leur maintien, on isole ce service dans un segment réseau dédié.
Journalisation DNS et corrélation avec les flux TCP
Bloquer et filtrer ne suffit pas si on ne regarde jamais ce qui se passe. La journalisation des requêtes DNS, croisée avec les logs de connexion sur les ports TCP, constitue un outil de détection redoutable et sous-exploité.
Un poste qui résout un nom de domaine inhabituel, puis ouvre une connexion TCP sortante vers une adresse IP inconnue sur un port élevé, produit un signal faible. Pris isolément, chaque événement semble anodin. C’est la corrélation entre la requête DNS et le flux TCP qui révèle l’exfiltration.
Le guide NIST SP 800-81 Revision 3, publié le 19 mars 2026, insiste sur cette notion de visibilité opérationnelle. Il regroupe DoH, DoT et DoQ sous la catégorie « encrypted DNS » et recommande de traiter le DNS non plus comme une simple infrastructure de fond, mais comme un point de contrôle de sécurité à part entière.
Ce que la journalisation doit capturer
Pour être exploitable, un journal DNS doit enregistrer au minimum le nom de domaine demandé, l’adresse IP source, l’horodatage et la réponse retournée. Côté ports TCP, on conserve les connexions établies, refusées et les tentatives de connexion avortées. Les retours varient sur la durée de rétention idéale, mais le règlement d’exécution européen 2024/2690, applicable depuis le 7 novembre 2024, impose à certains fournisseurs de services DNS et d’infrastructure une journalisation continue avec preuve d’efficacité des contrôles.
DNSSEC et chiffrement : protéger l’intégrité des réponses DNS
Un résolveur qui répond correctement ne garantit pas que la réponse n’a pas été altérée en chemin. L’empoisonnement de cache DNS redirige les utilisateurs vers des serveurs frauduleux sans qu’aucune alerte ne se déclenche côté réseau. DNSSEC ajoute une signature cryptographique aux enregistrements de zone pour valider leur authenticité.
DNSSEC valide l’origine des réponses, le chiffrement DNS protège leur confidentialité en transit : les deux mécanismes se complètent, aucun ne remplace l’autre.
En pratique, déployer DNSSEC sur ses zones internes impose de gérer le renouvellement des clés cryptographiques. Une clé expirée sans rotation programmée provoque une panne de résolution aussi brutale qu’une attaque. On automatise la rotation ou on ne déploie pas.
Politique de sécurité réseau : relier DNS et ports dans une approche unifiée
Traiter les DNS d’un côté et les ports de l’autre crée des angles morts. Un service autorisé par le pare-feu mais résolvant des domaines malveillants passera sous le radar. À l’inverse, un blocage DNS sans contrôle des ports laisse la porte ouverte aux connexions directes par adresse IP.
La démarche cohérente relie les trois couches :
- Le résolveur DNS interne filtre les domaines et journalise les requêtes.
- Le pare-feu restreint les ports TCP et UDP aux seuls services déclarés et maintenus.
- Un outil de corrélation (SIEM ou simple script d’analyse de logs) croise les événements DNS et les connexions réseau pour identifier les comportements anormaux.
Cette articulation n’exige pas un budget conséquent. Un résolveur filtrant, des règles de pare-feu révisées trimestriellement et une pile de logs consultée chaque semaine couvrent la majorité des vulnérabilités liées aux DNS et aux ports. Le maillon le plus fragile n’est pas l’outil, c’est la régularité de la revue.
