Le DNS associe un nom de domaine lisible à une adresse IP exploitable par les équipements réseau. Les ports TCP, eux, déterminent quels services acceptent ou refusent une connexion entrante. Ces deux mécanismes, souvent configurés une fois puis oubliés, constituent pourtant des vecteurs d’attaque privilégiés lorsqu’ils sont mal gérés.
Résolution DNS et surface d’attaque : ce que change le chiffrement
Par défaut, les requêtes DNS circulent en clair sur le port UDP 53. Un attaquant positionné sur le réseau peut intercepter ces requêtes, les modifier ou rediriger le trafic vers un serveur malveillant. Le filtrage DNS classique repose justement sur cette visibilité : l’administrateur inspecte les requêtes pour bloquer les domaines dangereux.
L’arrivée de DNS over HTTPS (DoH) bouleverse cet équilibre. DoH encapsule les requêtes DNS dans du trafic HTTPS standard, sur le port TCP 443. Le contenu des requêtes devient invisible pour les outils de supervision réseau. Un poste configuré pour utiliser un résolveur DoH externe peut ainsi contourner l’ensemble du filtrage DNS d’entreprise sans déclencher d’alerte.
La parade ne consiste pas à bloquer DoH en aveugle. L’approche recommandée est de définir un résolveur DNS autorisé en interne, compatible DoH ou DoT (DNS over TLS, port 853), puis de forcer son usage sur les postes via des stratégies de groupe ou un MDM.
Les requêtes vers des résolveurs externes non approuvés sont alors bloquées au niveau du pare-feu. Cette configuration préserve la confidentialité des échanges DNS tout en maintenant la capacité de filtrage, comme le détaille le guide sécurité sur Open Syd dans son volet dédié au durcissement des politiques réseau.
Ports TCP ouverts : réduire la surface exposée du réseau
Chaque port TCP ouvert sur un serveur représente un point d’entrée potentiel. Un service qui écoute sur un port non utilisé ou non surveillé offre une opportunité directe à un attaquant pour tenter une connexion, exploiter une vulnérabilité ou établir un canal de commande.
Identifier les ports réellement nécessaires
La première étape est un inventaire. Trop d’environnements conservent des ports ouverts hérités de configurations anciennes : des services de test, des interfaces d’administration temporaires, des protocoles obsolètes. Un scan régulier des ports exposés, depuis l’extérieur du réseau, révèle souvent des services dont personne ne soupçonnait l’existence.
Les ports à surveiller en priorité :
- Le port 53 (DNS) doit être restreint aux seuls serveurs DNS internes autorisés, et le trafic DNS sortant vers des résolveurs externes non approuvés bloqué au pare-feu
- Le port 443 (HTTPS) mérite une inspection particulière puisque DoH y transite, rendant possible l’exfiltration de données ou le contournement de politiques de sécurité
- Les ports d’administration distante (22 pour SSH, 3389 pour RDP) ne doivent jamais être exposés directement sur internet sans passerelle intermédiaire ou VPN
- Les ports associés à des services legacy (Telnet sur le port 23, FTP sur le port 21) devraient être désactivés au profit de leurs équivalents chiffrés
Appliquer le principe du moindre privilège aux flux réseau
Chaque règle de pare-feu devrait spécifier une source, une destination et un port précis. Les règles « any to any » sur un port donné reviennent à laisser une porte ouverte à quiconque connaît l’adresse. La segmentation réseau complète cette approche : placer les serveurs DNS dans un segment dédié limite la propagation latérale en cas de compromission.
DNSSEC et protection du compte DNS : deux couches complémentaires
DNSSEC signe cryptographiquement les réponses DNS pour garantir que l’information reçue par le client correspond bien à celle publiée par le serveur légitime. Sans cette validation, un attaquant peut injecter de fausses réponses (empoisonnement de cache) et rediriger le trafic vers des serveurs malveillants sans que l’utilisateur ne détecte quoi que ce soit.
La mise en place de DNSSEC reste un sujet opérationnel autant que cryptographique. Des erreurs de configuration, notamment dans la rotation des clés de signature, peuvent provoquer des interruptions de service. L’activation nécessite donc des tests préalables et une procédure de rollback documentée.
Un angle souvent négligé concerne la protection du compte qui administre les enregistrements DNS. Prendre le contrôle de ce compte permet de modifier directement les réponses DNS, de rediriger le trafic ou de générer des certificats TLS frauduleux. L’agence américaine CISA recommande de protéger ces accès par authentification multifacteur, d’auditer régulièrement les enregistrements publiés et de surveiller les journaux Certificate Transparency pour détecter toute émission de certificat non autorisée.
Directive NIS2 et gestion des risques DNS en Europe
La directive européenne NIS2 élargit le périmètre des entités soumises à des obligations de cybersécurité. Les fournisseurs de services DNS figurent explicitement parmi les entités concernées. Le règlement d’exécution européen 2024/2690 précise les exigences techniques attendues, notamment en matière de gestion des risques cyber.
Pour les organisations qui exploitent leur propre infrastructure DNS, cette évolution réglementaire implique de formaliser plusieurs pratiques :
- Documenter la politique de gestion des zones DNS, y compris les transferts de zone et les mécanismes de réplication
- Mettre en place une journalisation des modifications d’enregistrements et des accès aux serveurs DNS
- Intégrer les composants DNS dans le périmètre des audits de sécurité périodiques
Ces exigences ne sont pas nouvelles sur le plan technique. NIS2 les rend contraignantes sur le plan juridique, avec des sanctions en cas de non-conformité.
La maîtrise conjointe du DNS et des ports TCP forme un socle de sécurité réseau que ni les pare-feu applicatifs ni les antivirus ne remplacent. Un résolveur DNS correctement configuré et des ports strictement filtrés réduisent la surface d’attaque avant même qu’un outil de détection n’entre en jeu.
