Lutter contre les canaux cachés avec SNORT

Par Xavier Poli, secuobs.com
Le 12/12/2006

---

Résumé : Fryxar met à votre disposition un patch basé sur tcpstatflow pour l'IDS SNORT ; ces modifications vous permettront, grâce à l'asymétrie de certains protocoles, de détecter un canal caché dans un flux TCP autorisé par le firewall à sortir de votre réseau d'entreprise. - Lire l'article



La généralisation des solutions de filtrage pour les réseaux d'entreprises a amené les chercheurs en sécurité informatique à développer différentes techniques alternatives afin de contourner avec succès ces mécanismes de sécurisation en vue notamment d'avoir accès au LAN (Local Area Network) depuis le WAN (Wide Area Network) ou Internet sans pour autant déclencher de réponses pro-actives.

La mise en place de ces régles de filtrage spécifiques au trafic entrant a cependant pûe être contournée par les chercheurs grâce à l'utilisation de charges utiles « payloads » de type « backdoors » d'un nouveau genre et dites en « connect back ».

La charge malicieuse initialise alors la connexion vers le poste de l'attaquant et non l'inverse ; cette technique peut être elle-même plus ou moins déjouée par une configuration fine et stricte des rêgles qui concernent le traffic sortant du réseau de l'entreprise en le segmentant selon les besoins les plus minimalistes.

C'est donc dans ce contexte restreint d'exploitation que les techniques dites de « covert channels » ( gray-world.net - lien ) sont apparues ; leur principe consiste à profiter d'un flux autorisé en sortie par le « firewall » pour un protocole donné afin de faire transiter des données relatives à d'autres protocoles par le biais de ce flux via la création d'un canal caché. « Covert channels tunneling tool » ( Cctp – lien ) est un des outils disponibles permettant de réaliser cela.

Les « firewalls » dits applicatifs, capables de disséquer le trafic afin d'en connaître la véritable nature, sont une réponse à cette méthode cependant des protocoles comme l'« HTTPS » représentent de sérieux problèmes pour eux de par leur nature intrinséque (chiffrée) ; l'analyse des statistiques liées aux connexions en cours restent alors la seule solution possible pour la détection de ces « covert channels ».

Il est maintenant possible pour les utilisateurs du système de détection d'intrusion opensource « Snort » d'appliquer le fichier de modification « snort_covered_channels_detection.txt » qui vous permettra de détecter tout au moins une partie de ces « covert channels » avec une faible marge d'erreur.

Ce patch est basé sur l'utilisation de « tcpstatflow » ( Fryxar - lien ) du même auteur. Il a été développé pour la version 2.6.1.1 de « SNORT » et utilise le composant « stream4 » qui permet de ré-assembler les fragments d'une connexion « TCP » établie avant d'effectuer une recherche d'attaques par signature.

Pour l'installer, il vous suffit de récupérer les sources de « SNORT » ( lien ) et le patch en question ( lien ) que vous appliquerez à l'aide de la commande « patch -p0 < snort_covered_channels_detection.txt » avant de compiler les sources de « SNORT » et de l'installer.

Pour l'activer il est nécessaire d'éditer le fichier de configuration de « SNORT » afin de positionner le paramètre « detect_covered_channels » sur le nombre d'octets différentiel à définir comme le seuil de tolérance à atteindre lors d'une connexion de ce type avant d'émettre une alerte ; il faut également stipuler pour le paramètre « covered_channels_ports » la liste des ports à surveiller en vue de l'émission de ces alertes.

Le fonctionnement de ce patch part du principe que certains protocoles (HTTP/HTTPS/FTP/SMTP/POP3) présentent une importante asymétrie entre les données transférées dans les sens ascendant et descendant des connections « TCP » qui sont établies sensiblement à la manière de « Moltunnel » ( lien ).

Cette asymétrie étant suffisamment prononcée pour provoquer l'émission d'une alerte lors de la détection d'une anomalie différentielle sur les compteurs de trafic ; lors d'une connexion en « HTTP/HTTPS » ou en « POP3 » le ratio doit être généralement en faveur des données descendantes alors que pour le « SMTP » ce sont les données ascendantes qui sont les plus nombreuses.

Le cas du FTP est lui dépendant de l'utilisation que vous en faites, cependant les utilisateurs « lambda » l'utilisent en général plus pour télécharger des fichiers depuis un serveur de ce type que d'y en envoyer.