L’essentiel en 30 secondes
- L’exfiltration DNS cache des données dans des requêtes que presque tous les réseaux laissent passer, et que la plupart des DLP ne regardent pas.
- Bloquer le port 53 sortant ne suffit pas : le résolveur interne devient le relais.
- À vérifier : résolution, DNS chiffré, filtrage, détection testée à faible débit et chaîne de réponse.
Un cas typique : une organisation bloque proprement le DNS, le FTP et les sites de « paste » comme Pastebin, pendant que d’autres chemins, plus banals, restent ouverts. La posture n’est pas uniformément faible. Elle est inégale. Un DNS bien fermé ne dispense pas de le revérifier : un canal fermé en mars peut se rouvrir en juin, à la faveur d’une mise à jour de navigateur.
L’exfiltration DNS consiste à faire sortir des données d’un système d’information en les cachant dans des requêtes ou des réponses DNS, un protocole que presque tous les réseaux laissent passer. Ce que vous devez vérifier, c’est si vos résolveurs, votre filtrage sortant et votre SOC le voient passer. Voici la liste des contrôles, sans recette d’attaque.
Pourquoi le DNS reste un angle mort de la prévention des fuites
Le DNS est un protocole de service, dont chaque poste a besoin pour fonctionner. Nous le voyons rarement inspecté avec le même soin que le web ou la messagerie. Une requête de plus au milieu de milliers d’autres : personne ne la remarque.
La plupart des DLP du marché analysent des fichiers, des pièces jointes ou des flux HTTP. Elles ne lisent pas le contenu d’un nom de domaine que vous demandez. Votre DLP n’est pas mal réglée. Le DNS n’a simplement jamais fait partie de son travail, et ce genre d’écart se découvre en testant (voir notre guide sur le test d’exfiltration de données).
MITRE ATT&CK range ce comportement dans la tactique Exfiltration, sous la technique T1048 (exfiltration par un protocole alternatif) ; l’usage du DNS comme canal applicatif figure aussi sous T1071.004, et le tunnel de protocole sous T1572. Pour situer le DNS parmi les autres techniques, voir la tactique Exfiltration (TA0010) expliquée aux défenseurs.
Les trois questions à poser avant tout test
- Qui a le droit de résoudre vers Internet ? Si chaque poste peut interroger directement n’importe quel serveur DNS externe, vos autres contrôles deviennent secondaires.
- Où sont les journaux ? Sans journaux du résolveur dans votre SIEM, vous n’avez aucune détection a posteriori.
- Le DNS chiffré est-il maîtrisé ? DNS over HTTPS (DoH, RFC 8484, sur le port 443) et DNS over TLS (DoT, RFC 7858, sur le port 853), activés par Firefox, Chrome ou une application, peuvent contourner votre résolveur d’entreprise sans bruit.
Checklist des contrôles à valider
1. Architecture de résolution
- Vos postes et serveurs n’utilisent que les résolveurs internes autorisés.
- Votre pare-feu bloque le port 53 sortant (UDP et TCP) pour tout ce qui n’est pas un résolveur autorisé.
- Vous bloquez le port 853 (DoT), ou vous l’autorisez vers une liste fermée.
- Les résolveurs DoH publics connus (1.1.1.1 chez Cloudflare, 8.8.8.8 chez Google, 9.9.9.9 et les autres) sont bloqués au proxy, et vos politiques navigateur coupent le DoH non géré (DnsOverHttpsMode pour Chrome et Edge, DNSOverHTTPS pour Firefox).
- Vos segments sensibles (bases de données, production) n’ont aucune résolution externe inutile.
2. Filtrage et réputation
- Votre résolveur applique un filtrage par réputation (domaines récents, catégories à risque).
- Les domaines enregistrés depuis moins de 30 jours sont bloqués ou mis en observation.
- Un mécanisme de type RPZ (zones de politique de réponse) est en place et mis à jour.
L’ensemble relève plus largement du filtrage sortant.
3. Détection comportementale
- Alerte sur un volume anormal de requêtes vers un même domaine parent.
- Alerte sur des sous-domaines longs (selon la RFC 1035, un label DNS peut aller jusqu’à 63 caractères, un nom complet jusqu’à 253) ou à forte entropie, signe d’un encodage.
- Alerte sur une proportion inhabituelle d’enregistrements peu courants (TXT, NULL) depuis un poste utilisateur.
- Corrélation poste, utilisateur et heure, pour séparer un service légitime d’un comportement isolé.
4. Chaîne de réponse
- L’alerte arrive bien à votre SOC, avec un niveau de priorité cohérent.
- Vos analystes disposent d’une procédure pour isoler le poste et bloquer le domaine.
- Vous mesurez le délai entre l’événement et l’action, en minutes.
Tableau : contrôle, faille fréquente, preuve attendue
| Contrôle | Faille fréquente | Preuve à obtenir |
|---|---|---|
| Blocage du DNS direct | Règle présente mais exception trop large (sous-réseau entier autorisé) | Une requête vers un résolveur externe depuis un poste standard est rejetée et journalisée |
| Maîtrise du DoH | Politique appliquée à un seul navigateur | Aucune résolution chiffrée non gérée depuis les navigateurs et applications courantes |
| Filtrage par réputation | Liste non mise à jour ou mode « observation » jamais basculé en blocage | Un domaine de test récent est bloqué, et non simplement signalé |
| Détection d’anomalies | Seuils réglés pour éviter le bruit, donc trop hauts | Un rejeu à faible débit déclenche une alerte |
| Remontée au SIEM | Journaux DNS non collectés ou échantillonnés | L’événement de test est retrouvable dans le SIEM avec poste et utilisateur |
Scénario concret : un test qui « passe » à tort
Un scénario type, un lundi, dans une collectivité qui a bloqué le port 53 sortant et déployé un résolveur filtrant. Dans la console, le canal DNS est fermé. Imaginez un rejeu avec des données synthétiques depuis un poste du service finances, à faible débit (2 ou 3 requêtes par minute), vers un domaine de test que nous contrôlons.
Résultat : aucune alerte. Le résolveur interne a transmis les requêtes, exactement comme il est configuré pour le faire. Le filtrage par réputation n’a rien vu, car le domaine de test n’était pas classé. Et la règle d’entropie existait bien, avec un seuil pensé pour de gros volumes.
Schéma · bloqué en direct, relayé en interne
Étape suivante
Que laisse passer votre résolveur DNS ?
Une démo de 30 minutes : une campagne complète sur les 8 canaux que nous testons, sur notre environnement de démonstration. Le POC montre in situ, sur un scénario simple en environnement synthétique, comment la solution se comporte chez vous. Ce qui sort réellement de vos canaux, c’est le pilote qui vous le montre.
Comment tester l’exfiltration DNS sans utiliser de donnée métier réelle
3 principes guident un test DNS côté défenseur :
- Des données synthétiques uniquement. Des leurres au format réaliste (faux numéros de clients, faux IBAN) suffisent pour éprouver vos règles. Voir tester l’exfiltration en production grâce aux données synthétiques.
- Un domaine de destination maîtrisé, déclaré à l’avance à vos équipes réseau et au SOC selon le niveau d’aveuglement voulu.
- Plusieurs débits et plusieurs segments. Un test unique depuis le poste de l’administrateur ne dit rien du poste d’un commercial en télétravail ou d’un serveur applicatif. C’est pourquoi nous plaçons au moins un agent par sous-réseau, sous Windows ou Linux.
Surtout, répétez. Une configuration DNS bouge : nouveau résolveur, mise à jour de navigateur qui réactive le DoH, exception ajoutée en urgence un vendredi soir. Un test qui passait il y a 6 mois peut échouer aujourd’hui. Avec Enforcis, les prochaines versions permettront de programmer des rejeux périodiques ou déclenchés par un changement, selon la criticité du périmètre et la fraîcheur attendue de la preuve ; elles apporteront aussi des intégrations SIEM.
FAQ
L’exfiltration DNS est-elle détectée par une DLP classique ?
Rarement. La plupart des DLP analysent des contenus (fichiers, messages, flux web) et non les noms de domaine résolus. La détection repose plutôt sur votre résolveur, le filtrage DNS et le SIEM.
Bloquer le port 53 sortant suffit-il ?
Non. Cette mesure ferme le DNS direct, mais le résolveur interne reste un relais légitime vers Internet, et le DoH passe par le port 443 comme n’importe quel site web. Complétez par du filtrage et de la détection comportementale.
Le DNS chiffré rend-il le contrôle impossible ?
Pas s’il est géré. Coupez le DoH non géré par politique navigateur, bloquez les résolveurs DoH publics connus et faites passer vos postes par votre propre résolveur. Le vrai point aveugle, c’est l’application que vous n’avez pas inventoriée et qui embarque son propre DoH.
Quels signaux d’exfiltration DNS surveiller dans les journaux du résolveur ?
Nous regardons d’abord 4 signaux. Un volume anormal de requêtes vers un même domaine parent. Des sous-domaines longs ou à forte entropie : un label peut atteindre 63 caractères selon la RFC 1035. Une part inhabituelle d’enregistrements TXT ou NULL depuis un poste utilisateur. Et des domaines enregistrés depuis moins de 30 jours. Corrélez poste, utilisateur et heure dans votre SIEM, puis vérifiez par un rejeu à 2 ou 3 requêtes par minute que vos seuils se déclenchent.