Retour a la page d'accueil

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.
Autrement dit : " Nous interdisons tout, puis nous ouvrons des accès spécifiques et précis. "


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.
Dans la pratique, on rencontre fréquemment des environnements dans lesquels les serveur mandataires sont directement associés aux pare-feu. Le serveur mandataire est le point de passage obligé entre l'usager et les services externes : il reçoit les demandes, vérifie les autorisations, et si l'usager est autorisé à utiliser un service externe, émet la demande vers le pare-feu (qui peut lui aussi appliquer un autre type de filtrage visant à autoriser ou non l'accès aux ressources externes). La possibilité pour un utilisateur d'effectuer des actions non prévues par la politique de sécurité est, dans ce cas, plus restreinte que si l'environnement n'est basé que sur l'utilisation de pare-feu.


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 antivirus et les IDS/ADS peuvent permettre aux administrateurs réseaux / systèmes de restreindre davantage encore les possibilités pour un usager autorisé d'effectuer des actions non prévues par des méthodes de détection et par les réactions appropriées.
Les applications de filtrage de contenu peuvent servir a analyser les couches hautes du modele OSI.


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é.
Les divers équipements traversés sont confrontés à un trafic légitime et n'ont parfois que peu de possibilités pour découvrir le canal de communication qui y est inséré.


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 :
* L'installation d'une application sur une station du réseau interne.
* La connexion (automatisée ou non) depuis la station interne vers un serveur externe.


Nous nous voyons confrontés ici à une deuxième abstraction liée a l'utilisation des protocoles TCP/IP.
Nous pensons généralement que la machine initiant une demande de connexion (client TCP par exemple) est la machine cliente au niveau applicatif.
Néanmoins, si nous retournons la situation, nous nous rendons compte que rien n'empèche le client, après établissement d'une connexion, de devenir un serveur applicatif et de répondre aux commandes du client applicatif qu'est devenu le serveur.


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.

Cctt is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Cctt is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with Cctt; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Simon Castro
Maj le 20 Fevrier 2003