MolTunnel un détecteur pour les connexions tunnelées

Par Xavier Poli, secuobs.com
Le 11/06/2006

---

Résumé : Autant les techniques de « tunneling » s'avérent pratiques pour la mise en place de VPN, autant l'émergence de logiciels comme Skype montrent aujourd'hui les limites du « Firewalling ». MolTunnel a été developpé dans le but d'offrir à terme une solution à cette tendance. - Lire l'article



Autant les techniques de « tunneling » s'avérent pratiques pour la mise en place de Réseaux Privés Virtuels (VPN) facilitant le rattachement des utilisateurs nomades aux réseaux « corporate », autant l'émergence de logiciels de type P2P comme Skype ( lien ) pour la VoIP montre aujourd'hui les limites d'un « Firewalling » classique et représente un véritable poison pour les services techniques.

De nombreux utilitaires libres et/ou gratuits permettent d'outrepasser les règles de filtrage via différents protocoles acceptant le principe du tunnel, notamment SSL et HTTP/HTTPS pour les plus courrament utilisés : SSLTunnel ( lien ) et Stunnel ( lien ) qui utilisent tous les deux la méthode du relayage TCP par CONNECT, Firepass ( sur l'excellent site Gray-World - lien ) basé quant à lui sur un mode GET/POST de formulaire par script CGI pour le HTTP, et enfin HTTPTunnel ( lien ) qui utilise aussi le mode GET/POST à la différence qu'il opére ici par manipulation directe des URL.

Des solutions propriétaires et commerciales existent également LoopHole : ( lien ), Socks2HTTP ( lien ) et Hopster ( lien ) pour ne citer que les plus connues.

Le protocole ICMP n'est pas en reste avec l'application PingTunnel ( lien ) qui utilise les requêtes de type 8 (Echo Request) et de type 0 (Echo Reply). Egalement des solutions pour le protocole DNS avec Nstx ( lien ) et OzyMan DNS ( lien ) de Dan Kaminsky. Ces deux derniers sont notamment utilisés pour outrepasser le caractère payant des réseaux WIFI présents dans les hôtels et différents lieux publics.

Cette problématique n'est pas à proprement parler simple à solutionner, Guillaume Lehembre et Alain Thivillon de la société HSC ( lien ) s'y sont pourtant attelés ; les résultats de leurs travaux ont été présentés lors du SSTIC ( lien ), cuvée 2006. D'après leur étude, deux grandes écoles « s'affrontent » avec plus ou moins de réussite chacune dans la lutte contre le « tunneling ».

A savoir la détection en temps réel notamment utilisée par les anti-virus et les HIDS et la détection statique avec l'analyse postérieure des données de connexion. Ces deux techniques sont basées sur l'observation de différentes métriques en fonction des propriétés intrinsèques à chaque protocole (ratio upload/download et inversement, valeurs des en-têtes, taille des paquets, durée des connexions, intervalles entre les requêtes).

Partant de ces constats, les deux chercheurs ont développé un logiciel basé sur la bibliothèque LIBNDIS ( lien ) qui utilise elle-même la LIBPCAP ( lien ) pour l'analyse du trafic IP. Moltunnel, puisque c'est son nom, permet également le ré-assemblage des flux TCP pour leur analyse, et la fermeture des connexions monitorées à l'aide d'un paquet RST.

Plusieurs options de filtrage et de traitement sont proposées comme la mise en place d'exceptions multi-critères (adresse IP source et destination, ports DST et URL) par expression rationnelle, l'activation et la désactivation des tests (validité des requêtes pour le HTTP et de la méthode CONNECT pour le SSL, [White|Black]Lists des en-têtes HTTP (User-Agent) et le logging des cas positifs dans des fichiers au format CVS.

Parmi les scénarios identifiables à l'aide de cet applicatif on retrouve, entre autres, pour la partie détection en temps réel : Skype Over SSL mais également Skype avec la méthode CONNECT via un proxy HTTPS, GNU-HTTPTunnel par reconnaissance de l'absence d'en-tête « User-Agent » et Google Talk via l'interception de ce même type d'en-tête ici spécifique sur le principe du « Pattern Matching ».

En ce qui concerne les résultats de la détection statique de cette solution : WebEx ( lien ) et SSLTunnel sont reconnus avec la technique des ratios [U/D|D/U] couplée à l'analyse de la taille des paquets. La solution commerciale homonyme HTTPTunnel et une passerelle HTTP<->IRC sont toutes les deux identifiables par la présence de connexions dont la durée aura été jugée trop longue, 3400 et 12529 secondes en l'occurrence.

Bien que significatifs ces résultats positifs, de l'aveu même des auteurs, ne sont que « temporaires », chacune des solutions de « tunneling » citées pouvant dans ses futures versions s'adapter avec par exemple l'ajustement d'en-têtes adéquates, l'établissement de connexions alternativement descendantes puis ascendantes pour le problème des ratios, mais encore la rupture périodique de la connexion et la génération de « bruits » réseaux par de fausses requêtes parasites afin d'engorger le traitement de ces flux.

Parmi les contres-mesures à ces évolutions, sont prévus à l'avenir l'utilisation des réseaux de neurones et la mise en place d'une architecture client/serveur permettant de centraliser au niveau du serveur le traitement des données envoyées par les agents collecteurs au niveau des clients.

Il a également été évoqué le remplacement des bibliothèques NIDS par le moteur de l'IDS libre SNORT ( lien ) pour une optimisation des performances et la mise à disposition du code sous licence BSD dès le second trimestre de l'année courante afin de profiter de l'effet « communautaire » pour le développement et l'intégration de ces différentes évolutions ; l'utilitaire n'est pas disponible publiquement en téléchargement à l'heure actuelle.

La lutte s'annonce d'ores et déjà acharnée et passionnante entre les deux parties. A noter en attendant la disponibilité de plusieurs projets, adeptes de la LIBNDIS eux aussi, plus ou moins analogues à MolTunnel : DSNIFF ( lien ), tcpstatflow ( lien ) et NetEntropy ( lien ).