1. Contexte et menace
Le DNS tunneling est une technique d’exfiltration de données et de communication furtive qui exploite le protocole DNS pour transporter des informations arbitraires entre un système compromis et un serveur contrôlé par un attaquant.
Cette méthode est particulièrement dangereuse car le trafic DNS est souvent autorisé à travers les pare-feu, rarement inspecté en profondeur, et non chiffré.
Des campagnes APT comme OilRig ou APT32 ont utilisé le DNS tunneling pour piloter des malwares et exfiltrer des secrets, parfois pendant plusieurs mois avant détection.
2. Comprendre l’exploitation du DNS
Le DNS (Domain Name System) traduit les noms de domaine en adresses IP.
Chaque requête DNS comporte un ou plusieurs labels (parties séparées par des points), avec des limites techniques :
- Longueur max d’un label : 63 caractères
- Longueur max du FQDN : 253 caractères
Un attaquant encode des données (base32/base64, hex) dans ces labels et les envoie dans des requêtes vers un domaine qu’il contrôle.
Son serveur DNS décode ensuite ces labels pour reconstituer les données.
Exemple de requête d’exfiltration :
aGVsbG93b3JsZA.attacker.com
Ici, aGVsbG93b3JsZA est la chaîne Base64 de helloworld.
3. Variantes et sophistication
Les attaquants avancés utilisent :
- TXT record tunneling : la réponse DNS contient les données dans un enregistrement TXT.
- CNAME tunneling : utilisation de redirections pour transporter les données.
- Split-payload : division des données sur plusieurs requêtes pour réduire la suspicion.
- Covert C2 : envoi de commandes vers un malware via DNS.
4. Indicateurs de compromission
Quelques signaux révélateurs :
- Nom de domaine avec labels très longs ou aléatoires.
- Fréquence élevée de requêtes vers un domaine unique.
- Usage répété d’enregistrements TXT ou CNAME inhabituels.
- Volume DNS disproportionné par rapport au trafic HTTP/HTTPS.
5. Détection avancée
5.1 Capture et analyse avec tcpdump/tshark
tcpdump -i eth0 port 53 -w dns.pcap
tshark -r dns.pcap -Y "dns.qry.name contains attacker.com"
5.2 Détection comportementale avec Zeek (ex-Bro)
zeek -i eth0 local "Site::local_nets += { 192.168.0.0/16 }"
cat dns.log | awk '{if(length($8)>50) print $0}'
Ici, on filtre les requêtes DNS dont le nom dépasse 50 caractères, indicateur typique d’encodage de données.
5.3 Suricata avec règle personnalisée
alert dns any any -> any any (msg:"Suspicious long DNS query"; dns_query; pcre:"/^[A-Za-z0-9]{40,}/"; sid:1000001; rev:1;)
5.4 Détection statistique
Enregistrer le nombre de requêtes par IP et par domaine, puis déclencher une alerte si un seuil est dépassé :
zeek-cut id.orig_h query < dns.log | sort | uniq -c | sort -nr | head
6. Contre-mesures et durcissement
- Inspection DNS en profondeur avec filtrage sur longueur et entropie des labels.
- Liste blanche des domaines autorisés pour les serveurs critiques.
- Blocage des domaines nouvellement enregistrés (souvent utilisés par les attaquants).
- Utilisation de DNS sur TLS/HTTPS interne avec inspection côté résolveur.
- Segmentation réseau pour isoler les hôtes sensibles.
7. Automatisation de la réponse
Exemple : détection d’un domaine suspect → blocage automatique :
DOMAIN="attacker.com"
iptables -A OUTPUT -m string --string "$DOMAIN" --algo bm -j DROP
echo "127.0.0.1 $DOMAIN" >> /etc/hosts
Intégration SIEM
Envoyer l’événement dans un SIEM (Elastic, Splunk) avec contexte complet (IP source, domaine, timestamp) pour corrélation avec d’autres signaux d’attaque.
8. Conclusion
Le DNS tunneling est un canal d’exfiltration discret et puissant.
Une détection efficace nécessite une approche combinant inspection technique, analyse comportementale et automatisation de la réponse.
Ignorer ce vecteur revient à laisser une porte dérobée ouverte dans presque tout environnement réseau.
