Le système de noms de domaine (Domain Name System — DNS) constitue l'infrastructure fondamentale du routage sur Internet. Comme la quasi-totalité des services réseau dépendent de la résolution de noms de domaine lisibles en adresses IP, les pare-feu d'entreprise autorisent généralement les flux sortants UDP et TCP sur le port 53 avec un contrôle minimal. Les pare-feu à état qui filtrent rigoureusement les protocoles web (HTTP/HTTPS) ou bloquent tout trafic sortant direct réexpédient fréquemment les requêtes récursives vers des résolveurs internes ou publics.

Les groupes d'acteurs malveillants avancés (APT) et les logiciels malveillants exploitent cette confiance structurelle à travers la technique du tunnel DNS (DNS Tunneling). En encodant des données binaires quelconques dans les libellés de requêtes et les enregistrements de réponses, les assaillants établissent des canaux de commande et contrôle (C2) bidirectionnels furtifs et exfiltrent des données confidentielles depuis des réseaux isolés, sans établir de connexion IP directe vers des serveurs externes.

Comprendre le fonctionnement d'un tunnel DNS exige d'examiner la manière dont la hiérarchie de résolution est transformée en canal de transmission, les méthodes statistiques d'analyse d'entropie utilisées pour démasquer ce trafic, et les contrôles réseau nécessaires pour supprimer ces canaux de fuite.

Mécanismes des canaux DNS clandestins

Le tunnel DNS s'appuie sur le mécanisme de délégation hiérarchique normalisé dans la RFC 1035. Au lieu de communiquer directement avec un serveur externe, l'hôte compromis achemine ses messages par l'intermédiaire des résolveurs récursifs du réseau.

+--------------------+
|   Hôte compromis   |  (Segmente et encode la charge utile dans la requête)
+--------------------+
          |
          |  Requête UDP/53 : "a1b2c3d4e5f6.data.tunnel.attacker.com"
          v
+--------------------+
| Résolveur local    |  (Transmet la requête récursive vers l'amont)
| d'entreprise       |
+--------------------+
          |
          v
+--------------------+
| Serveurs racines   |  (Délèguent la zone vers le serveur de l'attaquant)
| et serveurs TLD    |
+--------------------+
          |
          v
+--------------------+
| Serveur d'autorité |  (Décode les données reçues dans le libellé ;
| de l'assaillant    |   intègre les ordres C2 dans la réponse TXT)
+--------------------+

1. Exfiltration de données en amont via les libellés de requête

D'après les spécifications de la RFC 1035, un nom de domaine pleinement qualifié (FQDN) peut atteindre 253 octets au total, chaque libellé séparé par un point étant limité à 63 octets :

$$\text{Taille maximale d'un libellé} = 63\text{ octets}, \quad \text{Taille maximale d'un FQDN} = 253\text{ octets}$$

Pour faire sortir des données d'un réseau protégé :

  1. Le programme malveillant divise les fichiers sensibles (clés privées ou identifiants de bases de données) en fragments binaires compacts.
  2. La charge utile est encodée en Base32, en Base64 ou en chaîne hexadécimale.
  3. La chaîne encodée est insérée comme sous-domaine associé au domaine de l'assaillant :
    78696e66696c747261746564.session1.c2.attacker.com
  4. Le client émet une requête standard de type A ou AAAA.
  5. Le résolveur local, ne disposant pas de la réponse en mémoire cache, interroge les serveurs racines et les TLD jusqu'au serveur d'autorité malveillant.
  6. Le serveur de noms de l'attaquant enregistre le libellé entrant, extrait les données encodées et reconstitue le fichier initial.

2. Réception des instructions C2 via les enregistrements de réponse

Dans le sens descendant, le serveur d'autorité de l'attaquant transmet ses instructions à l'intérieur des enregistrements de réponse DNS :

  • Enregistrements TXT : La RFC 1035 autorise les enregistrements TXT à transporter des chaînes jusqu'à 255 octets chacune, plusieurs chaînes pouvant être combinées dans une seule réponse. Avec les extensions EDNS0, un paquet de réponse DNS peut convoyer plusieurs kilooctets de shellcode exécutable ou d'instructions complexes.
  • Enregistrements NULL : Définis dans la RFC 1035 pour transporter des données binaires brutes (jusqu'à 65 535 octets via TCP), les enregistrements NULL évitent les contraintes de filtrage textuel des passerelles anciennes.
  • Enregistrements CNAME : Des réponses composées d'alias CNAME en chaîne peuvent dissimuler des paramètres de commande au sein des noms intermédiaires.

Dans la mesure où toutes les requêtes sont émises depuis le réseau interne par le client, ces flux traversent sans encombre les passerelles NAT et les pare-feu filtrant les connexions entrantes.

Propriété du canal Flux Web standard (HTTPS) Canal par tunnel DNS
Port et protocole TCP 443 UDP / TCP 53
Fiabilité du transport Accusés de réception TCP natifs Protocole à fenêtre glissante personnalisé sur UDP
Topologie de connexion Connexion directe client-serveur Requêtes acheminées par le résolveur local
Bande passante utile Très élevée (dizaines ou centaines de Mbit/s) Faible (1 kbit/s à 100 kbit/s)
Contrôle d'inspection Inspection SNI / ALPN TLS Souvent ignoré dans les flux récursifs

Détection technique : Analyse statistique et heuristique protocolaire

Puisqu'un blocage indiscriminé du port 53 paralyserait les communications de l'entreprise, les équipes de sécurité déploient des modèles d'analyse comportementale et statistique d'anomalies.

1. Mesure de l'entropie de Shannon

Les noms de domaine issus du langage naturel respectent des fréquences linguistiques régulières. À l'inverse, les flux binaires encodés présentent un degré de désordre très élevé :

$$H(X) = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$$

Où $P(x_i)$ représente la probabilité d'apparition du caractère $x_i$ dans le libellé :

  • Les sous-domaines légitimes d'une entreprise (comme auth.service.internal.corp) présentent généralement une entropie comprise entre 2,2 et 3,4.
  • Les libellés de tunnels encodés en Base32 ou Base64 atteignent couramment des valeurs d'entropie situées entre 4,2 et 4,8.

Des outils d'analyse réseau tels que Zeek ou Suricata surveillent en continu les flux de requêtes sortantes et déclenchent des alertes lorsque des libellés à haute entropie se succèdent anormalement.

2. Signatures comportementales et volumétriques

Outre l'aléa des caractères, les tunnels DNS se signalent par plusieurs indicateurs structurels :

  • Volume élevé de sous-domaines uniques : Un hôte unique générant des milliers de requêtes vers des sous-domaines aléatoires sous un même domaine parent en un court intervalle.
  • Augmentation anormale des requêtes TXT/NULL : Les flux ordinaires comportent majoritairement des enregistrements A, AAAA, CNAME et PTR. Une multiplication soudaine des requêtes TXT vers des domaines externes inconnus trahit l'existence d'un canal caché.
  • Longueur excessive des libellés : Proportion élevée de requêtes dont les libellés approchent la limite protocolaire de 63 octets.
  • Durée de vie (TTL) quasi nulle : Les serveurs de noms d'attaque définissent un TTL égal à zéro ou très faible pour interdire la mise en cache par les résolveurs et forcer chaque commande à traverser le réseau.

Durcissement des résolveurs et des passerelles d'entreprise

Pour contenir les tunnels DNS, les administrateurs doivent imposer des règles rigoureuses sur les flux sortants et sur les serveurs récursifs.

1. Verrouillage du port 53 sortant

Les postes clients et les serveurs applicatifs ne doivent en aucun cas pouvoir contacter directement des adresses IP externes sur le port 53. Le pare-feu doit obliger le transit par les résolveurs agréés :

# Autoriser les requêtes DNS uniquement vers le résolveur d'entreprise
sudo iptables -A OUTPUT -p udp --dport 53 -d 10.0.0.2 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 -d 10.0.0.2 -j ACCEPT

# Bloquer toute sortie directe du port 53 depuis les postes de travail
sudo iptables -A OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
sudo iptables -A OUTPUT -p tcp --dport 53 -j REJECT --reject-with tcp-reset

2. Déploiement des zones de politique de réponse (RPZ) sous Unbound

Les serveurs récursifs modernes intègrent des listes de réputation au moyen des Response Policy Zones (RPZ).

Dans la configuration d'Unbound (/etc/unbound/unbound.conf), la limitation des débits et des mémoires tampons permet de juguler les tentatives d'exfiltration :

server:
    # Limitation du tampon UDP pour réduire la charge utile par paquet
    msg-buffer-size: 8192
    
    # Limitation de cadence pour prévenir les salves anormales de requêtes
    ratelimit: 100
    ratelimit-factor: 10
    
    # Journalisation détaillée pour l'analyse de sécurité
    log-queries: yes
    log-replies: yes

# Blocage des domaines identifiés de tunnels DNS malveillants
response-policy:
    zone:
        name: "tunnel-blocklist.rpz"
        zonefile: "/etc/unbound/zones/rpz-blocked.zone"

Cloisonnement structurel avec WireGuard et VPNRice

Si le durcissement des résolveurs améliore la détection, la protection la plus absolue consiste à encapsuler l'intégralité du trafic de l'hôte dans un tunnel chiffré imperméable.

Redirection intégrale du trafic DNS

Sur un réseau local non sécurisé, les logiciels malveillants peuvent tenter d'exploiter le serveur DNS fourni par DHCP ou d'interroger un serveur distant non contrôlé.

Les réseaux privés virtuels de niveau 3 exploitant WireGuard neutralisent ce scénario en redéfinissant entièrement la table de routage du système :

+---------------------------------------------------------------+
|                       Machine cliente                         |
|                                                               |
|  Interface physique (eth0)  ---> Paquets UDP chiffrés         |
|  Interface WireGuard (wg0)   ---> AllowedIPs = 0.0.0.0/0, ::/0|
|  Configuration DNS           ---> 10.8.0.1 (Dans le tunnel)   |
+---------------------------------------------------------------+

Dès l'établissement du tunnel WireGuard :

  1. Le noyau réoriente l'intégralité des routes 0.0.0.0/0 et ::/0 exclusivement au travers de l'interface virtuelle (wg0).
  2. La cible de résolution DNS du système est verrouillée sur l'adresse de la passerelle interne (10.8.0.1).
  3. Toute tentative d'émission d'un paquet UDP brut vers un serveur DNS tiers est interceptée par la pile réseau, chiffrée avec ChaCha20-Poly1305 et acheminée vers la passerelle sécurisée.

Aucun tiers situé sur le réseau local ou sur les liaisons intermédiaires ne peut observer les requêtes en clair ni capter les fragments de données dissimulés.

Architecture défensive au sein de VPNRice

Le réseau VPNRice applique des mesures de sécurité complémentaires pour garantir l'intégrité des résolutions :

  1. Résolveurs Anycast internes isolés : Les requêtes DNS des utilisateurs sont traitées par des résolveurs récursifs propres, qui ne relaient aucune communication vers des serveurs d'autorité suspects.
  2. Filtrage heuristique en temps réel : Les nœuds de passerelle examinent en continu l'entropie des noms, la structure des libellés et la fréquence des requêtes afin d'interrompre les flux d'exfiltration.
  3. Contrôle cryptographique strict : Le protocole RiceGuard vérifie que l'adresse source interne correspond précisément à la clé publique de l'utilisateur, empêchant toute tentative d'altération du trafic de résolution.

En combinant l'évaluation de l'entropie de Shannon et l'encapsulation chiffrée totale, les gestionnaires de réseaux éradiquent les canaux DNS clandestins et préservent la confidentialité des données stratégiques.