Tunnel DNS : quand la sortie de données se déguise en requête
Chaque requête DNS transporte du texte. Un tunnel transforme ce texte en canal de sortie, et le résultat ressemble à une suite tout à fait normale de questions.
Comment le tunnel est construit
Les données à sortir de la machine sont encodées et découpées en morceaux. Chaque morceau devient un nom de domaine, du type un-morceau-de-donnees.tunnel.exemple. Le résolveur répond normalement et la réponse ramène ce que l'autre extrémité voulait dire.
Comme l'adresse a la forme d'un nom ordinaire, tout ressemble à une requête banale. Le serveur qui reçoit les données et renvoie les réponses est sur un domaine ordinaire et résout normalement. Les tunnels fonctionnent parce qu'on laisse le DNS transporter du texte dans les deux sens, et que très peu de gens filtrent ce chemin.
Pourquoi cela passe inaperçu
Le trafic ressemble à du DNS, il part vers le port 53 ou vers l'adresse d'un serveur DNS sur HTTPS, et personne ne regarde. Même quand le contenu de la requête est inspecté, ce qu'elle contient est chiffré, ce qui échappe à une simple lecture.
Le volume aide aussi à masquer : l'exfiltration est en général petite et étalée sur des heures, mêlée au trafic normal de l'appareil. Une requête toutes les dix secondes paraît bien moins suspecte qu'un envoi important à un instant donné.
Comment réduire la surface
Bloquer les domaines connus de tunnels couvre une partie du problème, mais ces listes changent tout le temps. Observer aide davantage : un appareil qui demande beaucoup de noms inexistants, ou qui interroge toujours le même domaine avec des préfixes étranges, fait autre chose que l'ordinaire.
Dans la configuration, deux mesures font la différence. Restreindre la sortie DNS pour que seul le résolveur choisi réponde, et garder un journal des requêtes par appareil pour rendre le motif visible. C'est l'historique, plus que le filtre, qui montre généralement par où la sortie passait.