Détection de tunneling DNS : pipeline ML

Un pipeline de machine learning qui détecte le tunneling DNS, ce canal caché qui fait sortir des données à l'intérieur de requêtes DNS ordinaires. Il apprend la forme des requêtes et le comportement d'une source dans le temps plutôt que de reconnaître des signatures d'outils, et il tient sur des captures qu'il n'a jamais ouvertes : 99,99 % de détection sur des outils de tunneling inconnus et 99,84 % sur un autre poste.

Aperçu du projet

Le DNS est le seul protocole que presque tous les pare-feux laissent passer, ce qui en fait la sortie la plus discrète d'un réseau. Le tunneling abuse exactement de cela : les données sont encodées dans le sous-domaine d'une requête, un serveur contrôlé par l'attaquant les décode, et l'exfiltration ressemble à une résolution de noms ordinaire. La détection par signatures attrape les outils déjà connus et rate le suivant ; ce pipeline prend donc l'autre voie et apprend le canal lui-même.

Chaque paquet devient 34 variables. 17 variables lexicales lisent la chaîne de requête (entropie de Shannon sur la requête complète et sur le sous-domaine, longueur, profondeur des labels, proportions de chiffres, de majuscules, de base64 et d'hexadécimal), 14 variables comportementales sont calculées sur une fenêtre glissante de 200 paquets groupée par IP source et par session (débit de requêtes, statistiques d'inter-arrivée et de longueur de paquet), et 3 signalent doublons et retransmissions. Quatre classifieurs ont été entraînés et comparés sur un corpus PCAP étiqueté, découpé au niveau du fichier et non de la ligne : le jeu de test est donc constitué de captures que le modèle n'a jamais ouvertes, et non de lignes mélangées issues de la même rafale de trafic.

Il a ensuite été confronté à des données tenues strictement à l'écart de l'entraînement : des outils de tunneling absents du jeu d'entraînement (tcp-over-dns, Cobalt Strike, dns2tcp, OzymanDNS), des captures enregistrées sur un autre poste (AndIodine sous Android), et du trafic DNS wildcard légitime réservé comme piège à faux positifs. La détection s'est maintenue à 99,99 % sur les outils inconnus et à 99,84 % d'un poste à l'autre, ce qui prouve que le modèle a appris la structure du canal plutôt que l'empreinte des cinq programmes sur lesquels il a été entraîné.

Fonctionnalités clés

34 variables par paquet DNS : 17 lexicales (entropie de Shannon sur la requête et sur le sous-domaine, longueur, profondeur des labels, proportions de chiffres, de majuscules, de base64 et d'hexadécimal), 14 comportementales (débit de requêtes, statistiques d'inter-arrivée et de longueur de paquet) et 3 indicateurs de doublons et de retransmissions
Variables comportementales calculées sur des fenêtres glissantes de 200 paquets groupées par IP source et par session : le modèle lit le rythme d'une source, et pas seulement une requête isolée
Découpage entraînement/test au niveau du fichier plutôt que de la ligne, ce qui supprime la fuite qui gonfle silencieusement les résultats lorsque des paquets quasi identiques issus de la même rafale se retrouvent des deux côtés
Quatre classifieurs entraînés et comparés (régression logistique, Random Forest, XGBoost, LightGBM), atteignant environ 1,00 de ROC-AUC et de F1 sur le jeu de test en distribution
Évaluation « leave-one-tool-out » sur les cinq familles d'entraînement (dnscat2, dnspot, iodine, DNS-shell, tuns) : le modèle est réentraîné sans une famille puis testé uniquement sur celle-ci, de sorte que la généralisation est mesurée et non supposée
Trois jeux de résistance tenus strictement hors entraînement : outils de tunneling inconnus à 99,99 % de détection, captures d'un autre poste à 99,84 %, et DNS wildcard légitime réservé comme piège à faux positifs