Introduction Les autorisations de transit de données entre des réseaux interconnectés via un (des) système(s) de contrôle d'accès sont définies et mises en place conformément à une politique de sécurité. Une politique de sécurite éxemplaire relative aux contrôles d'accès réseau s'appuie sur le postulat qui consiste à interdire tous les flux de données qui n'ont pas été prévus. Les systèmes de contrôle d'accès les plus fréquents reposent sur l'utilisation de pare-feu (firewall). A ces pare-feux peuvent être associés d'autres outils comme des serveurs mandataires (proxy), des anti-virus, des systèmes de détection d'intrusion (Intrusion Detection System), des systèmes de détection d'anomalies (Anomaly Detection System), des outils de filtrage de contenu, etc. Les pare-feu Un pare-feu est un constituant physique ou logique du système chargé de gérer les contrôles d'accès entre les x réseaux que sont les réseaux internes (LAN, DMZ) et les réseaux externes (Internet, liens d'interconnexion privés, ...) d'une entreprise, d'un particulier, etc. Le pare-feu applique la politique de sécurité existante gràce à des ensembles de règles qui permettent, selon le modèle utilisé, des possibilités de filtrage et de réaction aux évènement plus ou moins fines et complexes. Théoriquement, un usager interne, ou externe, ne peut donc effectuer que les actions qui ont été prévues par cette politique. Les serveurs mandataires Un serveur mandataire est, le plus souvent, un constituant logique chargé de jouer le rôle d'intermediaire entre des usagers (individus, stations, processus, ...) et des services distants. Le serveur mandataire applique la politique de sécurité existante gràce à des ensembles de règles plus ou moins fines. Le terme générique proxy s'applique pour toute une série de passerelles qui peuvent être des serveurs de cache, des reverse-proxy, des proxy applicatifs, etc. NDR : Comme on me l'a judicieusement fait remarquer, on peut assimiler un pare-feu à une classe de serveur mandataire. Je préfère, cependant, établir une distinction car elle peut refleter un état d'esprit d'entreprise lors de la mise en place d'un système de contrôle d'accès réseau. Les antivirus - les IDS - Les ADS - les applications de filtrage de contenu D'autres outils peuvent être installés au niveau de l'architecture réseau. Les applications au niveau du poste client Il est même possible, en définitive, d'installer des applications sur les postes clients de façon à s'assurer que les stations ne sont pas utilisées à autre chose que ce à quoi elles sont supposées servir. Malgré toutes ces implémentations, il demeure des possibilités d'utilisation des flux autorisés au niveau du système de contrôle d'accès pour faire transiter des données arbitraires dont le trafic est imprévu/interdit dans la politique de sécurité. Ces possibilités d'évasion permettent l'ouverture de canaux de communication (covert channel, canal subliminal, ...) donnant accès à des services externes à partir du réseau interne ou accès à des ressources internes à partir du réseau externe. Elles varient en fonction de l'environnement rencontré : environnement à base de pare-feu à filtrage de paquet statique, à base de pare-feu à filtrage de paquet à états (stateful inspection), environnement basés sur l'utilisation conjointe de pare-feu et de serveurs mandataires, etc. Le principe fondamental des évasions présentées dans ce document repose sur l'absence de vérification de la valeur intrinsèque des données qui transitent. Autrement dit, les flux autorisés sont utilisés pour véhiculer des données qu'ils ne sont pas supposés transporter. Il est, dans certains cas, envisageable de mettre en place des parades à ces transits non autorisés. Cependant, certaines de ces parades peuvent être lourdes de conséquences et/ou difficiles à mettre en oeuvre. Theorie : outrepasser la politique mise en place au niveau des flux Les flux de données autorisés entre le réseau interne d'une entreprise et l'Internet sont définis par la politique de sécurité que celle-ci a mise en place. Ces flux sont autorisés explicitement (autorisation d'effectuer de la consultation HTTP vers l'extérieur par exemple) et sont implementés au niveau des divers équipements (pare-feu, serveurs mandataires, ...) que doit traverser le trafic pour aller par exemple du poste client à la ressource externe. Tout autre trafic que celui qui a été prévu est théoriquement interdit à l'utilisateur. Cette interdiction est traditionnellement mise en place au niveau des couches réseau, transport et applicatives (couches 5,6,7) du modèle OSI. Il est cependant trivial de noter que cette interdiction ne s'appuie que sur une abstraction protocolaire qui voudrait qu'un transfert de données s'appuyant sur les diverses couches du modèle OSI ne puisse servir qu'à transporter les données prévues par le(s) protocole(s) sous-jacent(s). Transfert de données depuis le réseau interne vers l'extérieur Si nous partons du principe qu'un usager accrédité du réseau interne a la possibilité d'accéder à une ressource externe via un protocole quelconque - alors, cet usager a la possibilité depuis sa station d'ouvrir un canal de communication vers l'extérieur et ce, quels que soient les équipements traversés. Ce canal de communication non prévu ou interdit est contenu/encapsulé/masqué dans le protocole autorisé. Transfert de données depuis l'extérieur vers le réseau interne Si nous partons du principe qu'il est possible, par un biais quelconque, de poser une application spécifique sur une station du réseau interne et que la station mise en jeu a la possibilité d'accéder à une ressource externe via un protocole quelconque, alors il est possible, depuis l'extérieur, d'accéder au réseau interne et ce, quels que soient les équipements traversés. L'établissement de ce canal de communication s'effectue en deux phases : Nous nous voyons confrontés ici à une deuxième abstraction liée a l'utilisation des protocoles TCP/IP. Conclusion Elle est laissée à l'imagination du lecteur :) Licence :
This website and its content is part of the online documentation of CCTT - Covert Channel Tunneling Tool v0.1.3 - Copyright (C) 2002,2003 Simon Castro.
Simon Castro |