FR2866496A1 - Procede de controle d'acces a un reseau d'un terminal source utilisant un tunnel en mode bloquant - Google Patents

Abstract

L'invention concerne un procédé de contrôle d'accès d'un terminal source (T_SOUR) à un réseau comportant notamment un pare-feu (PF) et un portail (PORT) d'authentification, ce portail plaçant et conservant le pare-feu dans un état d'autorisation d'accès en réponse à une requête initiale valide d'accès en mode de base émanant du terminal source, et à la fourniture périodique ultérieure d'un jeton d'authentification valide, le terminal source pouvant en outre communiquer en mode tunnel avec un terminal de destination (T_DEST) du réseau à travers un tunnel bloquant l'échange du jeton.Selon l'invention, le portail ne place et conserve le pare-feu dans son état d'autorisation d'accès pour une connexion en mode tunnel qu'en réponse à une requête préalable d'accès en mode tunnel, émanant du terminal source et incluant la fourniture au portail de données d'identification valides du tunnel.

Description

L'invention concerne, de façon générale, les techniques d'accès à un

réseau informatique.

Plus précisément, l'invention concerne un procédé de contrôle d'accès d'un terminal source à un réseau comportant un point d'accès pour ce terminal, un pare-feu relié au point d'accès, et un portail d'authentification servi par une base de données d'authentification, ce portail plaçant le pare-feu dans un état d'autorisation d'accès en réponse à une requête initiale d'accès en mode de base émanant du terminal source et incluant la fourniture au portail de données d'authentification valides, à défaut desquelles le pare-feu est placé dans un état d'interdiction d'accès, ce portail conservant le pare- feu dans un état d'autorisation d'accès en mode de base en réponse à la fourniture périodique, par le terminal source et sur un canal sécurisé d'échange de jeton, d'un jeton d'authentification valide à défaut duquel le pare-feu est placé dans son état d'interdiction d'accès, et le terminal source communiquant sélectivement en mode tunnel avec un terminal de destination du réseau à travers un tunnel rendant le canal d'échange de jeton inutilisable.

Le contrôle d'accès à un réseau est la procédure par 25 laquelle l'opérateur d'un réseau autorise ou n'autorise pas un usager potentiel à utiliser son réseau.

Or il existe des situations dans lesquelles il n'est, pour l'heure, plus possible à l'opérateur de maintenir le contrôle d'accès à son réseau parce que l'usager choisit d'utiliser un tunnel en mode bloquant, ce qui rend impossibles les communications entre l'usager et l'opérateur du réseau.

Pour des raisons fonctionnelles ou des raisons de sécurité, un usager d'un réseau peut en effet être amené à établir un tunnel vers un hôte distant, tunnel au sein duquel il encapsule son trafic. Selon la configuration et les logiciels utilisés, ce tunnel peut être en mode bloquant, c'est-à-dire rejeter toutes les communications qui n'emprunteraient pas ce tunnel dans le sens de la réception comme dans le sens de l'émission.

Ce mode bloquant constitue en fait une garantie de sécurité supplémentaire pour l'usager. En effet, dans le cas où un usager se connecte via un tunnel au réseau privé ou "intranet" de son entreprise, un pirate ne peut pas attaquer cet usager ni l'utiliser comme relais pour accéder à l'intranet de l'entreprise de ce dernier.

Dans ce contexte, l'invention a pour but de proposer un procédé qui permet à l'opérateur d'un réseau de maintenir le contrôle d'accès à son réseau, même dans le cas où un usager choisit d'utiliser un tunnel en mode bloquant.

A cette fin, le procédé de l'invention, par ailleurs conforme à la définition générique qu'en donne le préambule ci-dessus, est essentiellement caractérisé en ce que le portail place et conserve le pare-feu dans son état d'autorisation d'accès pour une connexion en mode tunnel permettant une communication à travers le tunnel entre le terminal source et le terminal de destination en réponse à une requête préalable d'accès en mode tunnel émanant du terminal source et incluant la fourniture au portail, à travers le canal sécurisé d'échange de jeton, de données d'identification valides du tunnel.

Par exemple, les données d'identification du tunnel incluent une adresse du terminal de destination, une adresse du terminal source, et une identification du protocole du tunnel utilisé.

La requête préalable d'accès en mode tunnel peut répondre à une invitation adressée par le portail au terminal source à lui fournir des données d'identification valides pour une connexion en mode tunnel.

Une telle invitation peut être permanente, périodique, ou 15 être déclenchée par la détection de préparatifs d'établissement d'une connexion en mode tunnel.

L'invitation adressée par le portail au terminal source à lui fournir des données d'identification valides pour une connexion en mode tunnel prend par exemple la forme d'une fenêtre de maintien de session utilisée également pour la connexion en mode de base, cette fenêtre de maintien de session comportant avantageusement un bouton de fin de connexion en mode tunnel.

En réponse à la détection d'une fin de connexion en mode tunnel émanant du terminal source, le portail adresse au terminal source une invitation à lui fournir des données d'authentification valides pour retourner au mode de connexion de base.

En toute hypothèse, le portail peut mettre sélectivement fin à une connexion en mode tunnel en plaçant le pare-feu dans son état d'interdiction d'accès.

D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est faite ci-après, à titre indicatif et nullement limitatif, en référence à la figure unique, qui représente schématiquement les moyens fonctionnels nécessaires à la mise en oeuvre de l'invention.

Compte tenu de la nécessité, pour décrire dans le détail le procédé de l'invention d'une manière compréhensible pour l'homme du métier, d'utiliser le vocabulaire standard de ce dernier, le lecteur peu familier du domaine concerné trouvera ci-après les définitions et références utiles à sa propre compréhension de la description.

1. DEFINITIONS.

Adresse IP: Adresse d'un équipement utilisant IP (voir ce mot) comme protocole de couche 3 du modèle OSI (voir ce mot).

Adresse MAC: Adresse d'un équipement connecté à un médium partagé utilisé par la couche 2 du modèle OSI (voir ce mot).

DHCP (Acronyme tiré de l'anglais "Dynamic Host Configuration Protocol") Protocole d'attribution dynamique des adresses sur un réseau IP (voir ce mot).

DNS (Acronyme tiré de l'anglais "Domain Name Server" ou "Domain Name System") : Service essentiel de l'Internet assurant la conversion des noms de domaines en adresses IP (voir ce mot).

HTML (Acronyme tiré de l'anglais "HyperText Markup Language") Format de document Internet défini par la Norme RFC 1866.

IP (Acronyme tiré de l'anglais "Internet Protocol") . Protocole de niveau réseau utilisé dans l'Internet orienté sans connexion (principe du datagramme).

IPsec (Acronyme tiré de l'anglais "Internet Protocol 15 Security") : Protocole de sécurité utilisé dans l'Internet.

MAC (Acronyme tiré de l'anglais "Medium Access Control") . Terme général désignant la couche qui gère le partage d'un support de transmission entre différentes stations.

Open Source (Expression anglaise) Logiciel libre répondant à des exigences qualitatives définies.

OSI (Acronyme tiré de l'anglais "Open System Interconnection") Modèle d'interconnexion des systèmes ouverts où l'ensemble des actions permettant de faire coopérer plusieurs équipements informatiques est structuré en couches correspondant à des niveaux de détails différents.

PHP (Acronyme tiré de l'anglais "PHP Hypertext Preprocessor") : Langage de script orienté objet, de libre utilisation, permettant de gérer complètement un site Internet.

SSL (Acronyme tiré de l'anglais "Secure Socket Layer") . Norme de mode de communication sécurisée sur réseau, initialement utilisée par le navigateur de marque "Netscape", puis officialisée.

TCP (Acronyme tiré de l'anglais "Transport Control Protocol") Protocole de transport orienté connexion, permettant un échange fiable d'une quantité quelconque de données entre deux équipements (niveau 4 OSI - voir ce mot) reliés par un ou plusieurs réseaux utilisant IP (voir ce mot) .

TLS (Acronyme tiré de l'anglais "Transport Layer Security") : Protocole de sécurisation de la couche transport, défini par la norme RFC 2246. La version 1.0 de TLS est en fait la version 3 de SSL (voir ce mot).

UDP (Acronyme tiré de l'anglais "User Datagram Protocol") . Protocole de transport de blocs de données indépendants, ou "paquets", transitant sur un réseau et contenant toutes les informations nécessaires à leur routage.

URL (Acronyme tiré de l'anglais "Uniform Resource Locator") : Format d'adresse permettant de retrouver une ressource.

VPN (Acronyme tiré de l'anglais "Virtual Private Network") : Réseau privé virtuel.

II. RÉFÉRENCES.

[IEEE-802.1X-2001] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-5 Based Network Access Control", IEEE Standard 802.1X, Septembre 2001.

[IEEE 802.3-2002] IEEE Standard for Information technology Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.

[IEEE-802.11-1997] Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network -Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1997.

[IEEE-802.11-1999] Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network - Specifie Requirements - Part Il: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.

[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specifie Requirements Part Il: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE Draft 802.111 (work in progress), 2003.

[IPsec] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, Novembre 1998.

[OSI] International Organization for Standardization, "Open Systems Interconnexion", ISO 7498.

[TLS] Dierks, T. and Allen, c., "The TLS Protocol version 1.0", RFC 2246, Janvier 1999.

[VTUN] The easiest way to create Virtual Tunnels over 15 TCP/IP networks with traffic shaping, compression and encryption, http://vtun.sourceforge. net/.

[WPA] Wi-Fi protected Access, Wi-Fi Alliance, version 1.2, Decembre 2002.

Le procédé décrit ci-après s'applique typiquement à un scénario où l'opérateur du réseau réalise un contrôle d'accès au niveau TCP/IP et où l'usager souhaite utiliser un tunnel tel que [IPsec] en mode bloquant.

L'invention peut trouver un usage pertinent dans les réseaux radioélectriques IEEE 802.11 ([IEEE-802.11-1997] et [IEEE-802.11-1999]) de première génération , c'est à dire qui ne mettent pas en oeuvre les nouvelles fonctionnalités de sécurité au niveau 2 du modèle [OSI] comme WPA ou 802.11i., et dans les réseaux filaires IEEE 802.3 ([IEEE 802.3-2002]) et Ethernet qui réalisent un contrôle d'accès selon le paradigme de portail captif .

III. ETAT DE LA TECHNIQUE ANTERIEURE Un préliminaire au contrôle d'accès est l'authentification. L'authentification permet à l'opérateur du réseau de déterminer avec certitude l'identité de l'usager qui cherche à utiliser son réseau.

Pour authentifier un usager, l'opérateur d'un réseau doit dialoguer avec ce dernier.

En cas d'authentification réussie, l'opérateur du réseau décide en fonction de l'identité de l'usager si ce dernier est autorisé ou non à accéder au réseau.

Afin d'éviter que des usagers illégitimes ne profitent 20 indûment du réseau, il est nécessaire pour le contrôle d'accès: - de s'assurer que seuls les usagers que l'opérateur a autorisés peuvent utiliser le réseau, c'est-à-dire d'éviter 25 qu'un usager non-autorisé ne puisse utiliser le réseau; et - de maintenir la relation d'authentification avec l'usager, c'est-à-dire de s'assurer que l'usager autorisé qui utilise le réseau est bien le même que celui qui s'est authentifié, afin d'éviter qu'un usager non-autorisé usurpe l'identité d'un usager autorisé.

Plusieurs techniques permettent de réaliser un contrôle d'accès au réseau, en particulier: - des techniques physiques par exemple les prises 5 permettant d'accéder au réseau sont situées dans des locaux fermés à clefs; et - des techniques logiques: par exemple l'accès au réseau est conditionné par la possession d'un secret permettant 10 d'employer des techniques cryptographiques.

En l'absence de mécanismes de sécurité incluant le contrôle d'accès au niveau 2 (lien de données) du modèle à sept couches de 1'[OSI] ou du fait des coûts liés au déploiement de tels mécanismes quand ils existent et du très faible taux de pénétration de ces derniers dans le parc d'équipement des usagers, le paradigme du portail captif a été développé.

Ce paradigme permet de réaliser un contrôle d'accès aux réseaux TCP/IP: en réalisant un filtrage sur les adresses MAC et IP; et - en utilisant des jetons d'authentification échangés entre le terminal source et le portail d'authentification.

Lors de sa connexion au réseau, l'usager est invité à ouvrir son navigateur Internet, et sa première requête à l'aide de ce dernier est automatiquement redirigée vers le portail d'authentification de l'opérateur (d'où le nom de portail captif). Ce portail captif permet à l'usager de s'authentifier de manière sécurisée, par exemple en utilisant les protocoles SSL/[TLS].

Toutes les autres requêtes de l'usager non-authentifié sont bloquées par un pare-feu qui réalise un filtrage par adresse MAC et/ou adresse IP. En cas d'authentification réussie et dans le cas où l'usager authentifié est autorisé à accéder au réseau, le pare-feu est mis à jour pour laisser passer le trafic de cet usager.

L'architecture d'un portail captif implique ainsi globalement (figure) un point d'accès P_ACC, un pare-feu PF, le portail d'authentification luimême PORT, et une base de données d'identification BDD.

Le point d'accès P_ACC offre à un terminal source T_SOUR une voie de connexion sans fil (Wi-Fi par exemple) au réseau Internet.

Le pare-feu PF contrôle directement l'accès du terminal T_SOUR au réseau Internet en filtrant les paquets (typiquement au niveau IP et TCP), et en opérant un filtrage par adresse MAC.

Le portail PORT authentifie l'usager, intercepte les requêtes des usagers non-authentifiés, redirige ces usagers vers une page d'authentification, fait vérifier ses données d'authentification par la base de données BDD, modifie les règles du pare-feu PF en fonction du résultat de cette vérification, et pilote donc l'état du pare-feu.

La base de données BDD contient quant à elle les données valides des usagers autorisés, et répond aux requêtes du portail PORT.

Comme le contrôle d'accès par adresse MAC et adresse IP est intrinsèquement faible (il est en effet très facile, par simple manipulation logicielle, d'usurper l'adresse MAC et l'adresse IP d'un usager), le portail captif PORT utilise un contrôle d'accès supplémentaire par jeton échangé entre le terminal source et le portail d'authentification.

Le portail captif garde en effet un canal de communication sécurisé ouvert avec l'usager, sur lequel l'usager doit présenter périodiquement, ou sur événement, un jeton d'authentification. Le défaut de présentation de ce jeton entraîne la réinitialisation du pare-feu dans l'état bloquant pour cet usager. Ainsi, un usager non-autorisé usurpant l'adresse MAC et/ou l'adresse IP d'un usager autorisé ne pourra pas présenter ce jeton et verra sa connexion terminée. Même si la présence simultanée d'un usager autorisé chargé de présenter le jeton et d'un usager non-autorisé usurpant l'adresse MAC et l'adresse IP de cet usager autorisé est envisageable, les mécanismes de fonctionnement des protocoles TCP/IP rendront les connexions inutilisables: l'usager non-autorisé, s'il veut profiter de la connexion de l'usager autorisé n'a, pour l'heure, pas d'autre choix que de faire taire l'usager autorisé, par exemple par du déni de service. Après avoir fait taire l'usager autorisé, l'usager non- autorisé ne peut profiter du service que tant que le portail captif n'exige pas la présentation du jeton, intervalle de temps qui peut être configuré au niveau du portail captif PORT.

Le paradigme de portail captif tel que décrit jusqu'à présent s'applique, par exemple, tant aux réseaux radioélectriques utilisant la technologie IEEE 802.11 qu'aux réseaux locaux filaires utilisant les technologies IEEE 802.3/Ethernet.

Dans le cas des réseaux radioélectriques utilisant la technologie IEEE 802.11, les mécanismes de sécurité prévus à l'origine dans la norme [IEEE802.11-1997] et [IEEE802.11- 1999] ont rapidement révélé des problèmes majeurs qui rendent leur utilisation tout aussi compliquée qu'inefficace: c'est la faillite consommée en 2000 et 2001 des mécanismes de sécurité connus sous l'acronyme "WEP".

Bien que des mécanismes de sécurité plus robustes soient en cours de déploiement [WPA] ou de spécification [IEEE-802.11i], ils ne présentent pas à l'heure actuelle de maturité suffisante pour être déployés à grande échelle.

Deux scénarios dans lesquels le paradigme de portail captif s'applique aux réseaux radioélectriques utilisant la technologie IEEE 802.11 sont les réseaux radioélectriques locaux, appelés "Hot-Spots", utilisant la technologie IEEE 802.11 et déployés dans des lieux très fréquentés, par exemple les réceptions d'hôtels ou les salles d'attente d'aéroport, où la mise à disposition d'une connexion à Internet présente une forte valeur ajoutée; et - les accès à un réseau offerts par une entreprise à ses visiteurs pour permettre à ces derniers de travailler plus efficacement, par exemple dans les salles de réunion.

Dans le cas des réseaux locaux filaires utilisant les technologies IEEE 802.3/Ethernet, aucun mécanisme de sécurité n'a été prévu à l'origine. Ce n'est qu'en 2001, avec l'adoption de la norme [IEEE802.1X-2001], que des mécanismes de sécurité ont vu le jour pour ces réseaux.

Cependant leur taux de pénétration dans le parc des équipements usagers est encore faible. C'est pour cela qu'une entreprise souhaitant offrir un accès réseau à ses visiteurs, par exemple en salle de réunion, peut être amenée à utiliser le paradigme de portail captif .

Le point faible de la technique connue de portail captif, qui renforce le contrôle d'accès par filtrage d'adresse IP et/ou adresse MAC par un échange de jeton d'authentification, réside justement dans le fait que cette technique suppose que l'opérateur et l'usager soient capables de dialoguer pour pouvoir s'échanger le jeton.

Or, l'application la plus typique utilisée par les usagers dans les scénarios présentés précédemment consiste pour ces usagers à monter un tunnel (créant ainsi un VPN) vers l'intranet de leur entreprise.

Pour des raisons de sécurité, la plupart des applications de VPN empêchent alors toutes les communications à destination ou en provenance de l'usager, autres que celles qui passent à l'intérieur du VPN. Il s'agit donc de tunnels en mode bloquant.

Dans ce cas, il n'est donc plus possible de maintenir l'échange du jeton d'authentification, et aucune solution n'est disponible à l'heure actuelle pour résoudre ce problème.

En conséquence: - soit la sécurisation par échange de jeton est alors purement et simplement abandonnée dans le paradigme de portail captif , auquel cas le contrôle d'accès au réseau ne consiste plus qu'en un filtrage par adresse IP et/ou adresse MAC, ce qui présente des vulnérabilités critiques, - soit la sécurisation par échange de jeton est maintenue et l'usager ne peut pas monter un tunnel en mode bloquant, par exemple vers l'intranet de son entreprise, car la première demande d'échange de jeton postérieure à l'établissement du tunnel échouera et le trafic de l'usager sera bloqué.

IV. PRINCIPE DE L'INVENTION L'invention permet à l'opérateur d'un réseau de maintenir un contrôle d'accès efficace à son réseau, même dans le cas 25 où l'usager choisit d'utiliser un tunnel en mode bloquant.

Pour ce faire, le paradigme de portail captif avec authentification par échange de jeton est amendé pour permettre deux types de connexion, à savoir (1) un type de connexion en mode de base dans lequel l'usager n'utilise pas de tunnel en mode bloquant qui l'empêcherait de communiquer avec l'opérateur du réseau, ce mode de base étant identique au fonctionnement connu du paradigme de portail captif , et (2) un type de connexion en mode tunnel, dans lequel l'usager utilise un tunnel en mode bloquant qui l'empêche de communiquer avec l'opérateur du réseau.

Lorsque le portail captif est informé que l'usager souhaite utiliser un tunnel en mode bloquant, il désactive l'authentification par échange de jeton (que l'usager n'est plus en mesure d'effectuer) et modifie les règles du pare-feu pour ne plus autoriser que le trafic de l'usager correspondant au tunnel établi par lui, cet usager étant identifié par son adresse IP et/ou son adresse MAC, et le tunnel étant par exemple identifié par l'adresse IP source, par l'adresse IP du terminal de destination T_DEST, ainsi que par le protocole de transport.

Ainsi, pour usurper l'identité de l'usager autorisé, un usager non autorisé devrait non seulement usurper l'adresse IP et/ou l'adresse MAC de l'usager autorisé mais aussi s'insérer dans le tunnel établi par l'usager, ce qui peut, d'une part, s'avérer impossible dans la mesure où le tunnel est protégé par des techniques cryptographiques, et d'autre part, se révéler inutile et inintéressant pour l'usager non-autorisé qui n'a que faire de communiquer avec l'hôte distant T_DEST choisi comme terminaison du tunnel par l'usager autorisé.

Pour permettre ces transitions, les fonctionnalités du canal servant à échanger le jeton dans le mode de base sont étendues: désormais l'opérateur et ses usagers peuvent en plus échanger de manière sécurisée des informations de transition via ce canal.

A. Transition du mode de base vers le mode tunnel.

Cette transition peut s'effectuer à l'initiative de l'usager ou de l'opérateur du réseau.

Pour ce faire.

- soit l'usager signale, à l'aide du canal d'échange du jeton, qu'il compte établir un tunnel qui l'empêchera de communiquer avec l'opérateur du réseau. Il peut alors communiquer à l'opérateur du réseau les caractéristiques publiques de ce tunnel (par exemple les adresses IP source et destination de ce tunnel) afin de lui permettre de passer dans le mode tunnel en modifiant les règles de filtrage du pare-feu PF, ou laisser l'opérateur détecter ces caractéristiques puis basculer dans le mode tunnel; - soit l'opérateur du réseau détecte que l'usager est en train d'établir un tunnel, avertit l'usager de la détection de cette opération via le canal d'échange du jeton, et lui présente pour confirmation les caractéristiques publiques détectées de ce tunnel via le canal d'échange du jeton. En réponse à la confirmation ou à l'infirmation reçue de l'usager en mode sécurisé, l'opérateur du réseau bascule ou non la connexion dans le mode tunnel.

B. Transition du mode tunnel vers le mode de base.

Cette transition s'effectue à l'initiative de l'usager ou de l'opérateur du réseau. Ainsi: - soit l'usager décide de ne plus utiliser le tunnel qu'il a établi et envoie alors une requête ordinaire en dehors de ce tunnel. Cette requête est interceptée par l'opérateur du réseau (car il a modifié les règles du pare-feu en passant dans le mode tunnel) qui procède à la ré- authentification du terminal source T_SOUR. En cas d'authentification réussie et d'autorisation, l'opérateur du réseau bascule la connexion du mode tunnel vers le mode de base; - soit l'opérateur décide de ne plus laisser l'usager utiliser son tunnel et réinitialise les règles de son pare-feu PF pour cet usager, qui voit donc son tunnel bloqué. Pour chercher à rétablir sa connexion, cet usager doit alors s'authentifier auprès du portail, soit comme un nouvel utilisateur, soit en utilisant des mécanismes de ré-authentification. En cas d'authentification réussie et d'autorisation, l'opérateur du réseau rétablit la connexion en mode de base.

V. DESCRIPTION D'UN MODE PARTICULIER DE REALISATION DE L'INVENTION.

Dans cette partie de la description, qui explique comment le procédé de l'invention peut être mis en oeuvre dans un mécanisme connu de contrôle d'accès par portail captif , seules sont décrites les transitions du mode de base vers le mode tunnel (ou inversement) à l'initiative de l'usager. Le principe de basculement entre ces deux modes de fonctionnement est équivalent, que ce basculement intervienne à l'initiative de l'usager ou de l'opérateur.

A. Rappel du contexte actuel.

On présente ici le mode de fonctionnement classique d'une connexion d'un usager à un réseau supportant la technologie de portail captif . Cette technologie est mise en oeuvre dans de nombreux produits commerciaux, et est disponible également dans un produit Open Source appelé NoCatAuth (notamment décrit sur le site http://nocat.net).

Cette solution de portail captif Open Source pilote plusieurs moteurs de filtrage Open Source comme "iptables", "packetfilter" ou "IPFilter", respectivement décrits sur les sites.

http://iptables.org, http://www.benzedrine.cx/pf.html, et 15 http://www. ipfilter.org.

Il permet de piloter ces moteurs de filtrage grâce à un dialogue entre le portail captif et une application pilotant le moteur de filtrage.

Les étapes du processus standard de connexion sont les suivantes.

1. L'usager se connecte au réseau dont le contrôle d'accès 25 est réalisé par le portail captif; 2. Le réseau lui permet de récupérer les informations de connectivité classique (adresse IP, adresses serveurs DNS, adresses passerelle par défaut...), ceci étant généralement effectué à l'aide d'un échange DHCP; 3. L'usager décide de s'authentifier auprès du réseau afin d'avoir accès aux services offerts par le site local (typiquement l'Internet); 4. L'usager envoie une requête vers l'Internet qui est interceptée par le moteur de filtrage (règles par défaut) et redirigée vers le portail captif . Le portail captif présente alors la page d'authentification à l'usager; 5. L'usager entre ses données d'authentification (typiquement un numéro de connexion et un mot de passe) qui seront validées par le portail captif ; 6. Le portail captif interagit avec le moteur de filtrage de manière à modifier les règles de filtrage par défaut pour cet utilisateur. A ce moment-là, l'usager est alors capable de communiquer vers l'extérieur (typiquement l'Internet) en fonction des nouvelles règles de filtrage communiquées au moteur de filtrage; 7. Le portail captif pousse une fenêtre d'authentification périodique à l'usager, cette fenêtre permet de maintenir la session entre l'usager et le portail captif grâce à la notion de jeton d'authentification. Cette fenêtre est ici dénommée fenêtre de maintien de session .

En pratique, la fenêtre de maintien de session peut être écrite en code HTML, permettant d'initier une connexion de manière périodique vers une URL bien formatée (contenant en particulier le jeton d'authentification).

B. Mise en oeuvre de 1 'invention dans le contexte rappelé ci-dessus.

La mise en oeuvre de l'invention dans le système de portail captif conduit à affiner les règles de la stratégie de sécurité du mécanisme de filtrage, afin de n'autoriser que les flux explicitement déclarés par l'usager.

Le mécanisme de transition entre modes est mis en oeuvre dans le canal d'échange de jeton, ce mode spécifique permettant un dialogue authentifiégrâce au jeton, et protégé par TLS entre l'usager et le portail captif .

L'invention consiste ici à prévoir, pour une connexion en mode tunnel, la fourniture par l'usager d'une information supplémentaire, comme par exemple l'adresse destination du tunnel (nom DNS ou adresse IP), c'est-àdire l'adresse du terminal de destination T_DEST.

Une fois connecté en mode de base, l'usager dispose ainsi de deux options.

Soit il ne désire pas établir de tunnel, auquel cas il n'a besoin de fournir aucune information supplémentaire par rapport à la situation de l'art antérieur, et la session se poursuit classiquement en mode de base.

Soit l'usager désire établir un tunnel, auquel cas il utilise la fenêtre de maintien de session utilisateur pour spécifier le tunnel qu'il souhaite emprunter, par exemple en indiquant l'adresse de destination du tunnel.

Si la procédure utilisée est valide et autorisée, elle provoque le basculement du mode de base dans le mode tunnel par les étapes suivantes.

Tout d'abord, le portail captif reçoit l'information d'identification du tunnel requis, qui transite dans la fenêtre de maintien de session via le canal sécurisé d'échange de jeton. Le portail captif analyse alors la requête contenant l'adresse de destination du tunnel. Ce portail communique au moteur de filtrage de nouvelles règles de filtrage n'autorisant que la communication entre l'usager et l'adresse spécifiée et désactive la fonction de fenêtre de maintien de session. Il se base alors uniquement sur un filtrage MAC / IP et les nouvelles règles de filtrage fonctions de l'adresse de destination du tunnel.

Une fois connecté en mode tunnel, l'usager dispose de deux options.

Soit il ne désire plus maintenir le tunnel ni communiquer en dehors du tunnel, auquel cas il peut se déconnecter brutalement. Cette connexion ne pourra pas être utilisée de manière frauduleuse car les règles de filtrage n'autorisent que le tunnel préalablement établi, ce qui n'a que peu d'intérêt pour l'attaquant. Pour se déconnecter proprement, l'usager peut spécifier dans la fenêtre de maintien de session qu'il désire terminer sa session. Ceci a pour effet de considérer l'usager comme non authentifié et de remettre les règles de filtrage par défaut.

Soit l'usager désire fermer son tunnel mais continuer à communiquer en mode de base après la fermeture du tunnel.

Si la procédure utilisée par l'usager est valide et autorisée, elle provoque le basculement du mode tunnel dans le mode de base de la façon suivante.

En fait, dès que l'usager ferme son tunnel, qui est en mode bloquant, il peut communiquer vers l'extérieur. Par exemple, la fenêtre de maintien de session est dotée d'un bouton de fin de mode tunnel, et l'usager peut spécifier qu'il veut mettre fin au mode tunnel en activant ce bouton de la fenêtre de maintien de session. Le portail captif reçoit l'information qui transite dans cette fenêtre de maintien de session, qui est chiffrée par TLS / SSL et qui est authentifiée par le jeton d'authentification. Le portail captif analyse alors la requête contenant l'information de fin de mode tunnel et communique au moteur de filtrage de nouvelles règles de filtrage, qui sont les mêmes que pour une connexion classique authentifiée sans mode tunnel. Enfin, le "portail captif" réactive la fonction de fenêtre de maintien de session.

En résumé, la fenêtre de maintien de session doit donc comprendre: - les informations nécessaires à l'établissement du mode de 25 base (par exemple adresse IP, jeton d'authentification...), et - un formulaire pour l'établissement du mode tunnel (requérant par exemple l'adresse de destination et l'identification du protocole utilisé par le tunnel), et qui permet la transition du mode de base vers le mode tunnel, cette fenêtre de maintien de session pouvant également comprendre un bouton de fin de connexion pour la fin d'établissement de tunnel, c'est-à-dire la transition du mode tunnel vers le mode de base.

VI. VARIANTES Le procédé précédemment décrit peut être complété ou adapté au contexte de l'invention selon plusieurs variantes, l'utilisation de ces variantes étant conditionnée par les capacités du terminal source T_SOUR.

Tout d'abord, le passage en mode tunnel peut se faire à 15 l'initiative soit de l'usager soit du portail captif.

Dans le cas où c'est l'usager qui déclenche le passage en mode tunnel, il doit d'abord récupérer un formulaire auprès du portail captif et l'afficher dans son navigateur Internet. L'usager remplit alors le formulaire en spécifiant les caractéristiques des seuls flux qu'il souhaite se voir autoriser. Il renvoie le formulaire rempli au portail captif, qui vérifie l'authenticité du formulaire et l'interprète en termes de règles de filtrage.

Dans une optique d'automatisation du passage en mode tunnel, c'est le système de contrôle d'accès qui doit prendre l'initiative. Pour cela le pare-feu doit être configuré pour réagir au passage de flux de données indiquant la préparation d'une connexion en mode tunnel.

Lorsqu'il reconnaît un de ces flux (par exemple le montage d'un tunnel IPsec provoque le passage de paquets UDP 500), le pare-feu le bloque et envoie un formulaire dans le navigateur de l'usager qui est à l'origine du flux détecté.

Si le pare-feu dispose de suffisamment d'informations avec les données qu'il a pu détecter, alors il pré-remplit le formulaire et le présente à l'usager qui n'a plus qu'à valider ou refuser le changement de mode aux conditions précisées dans ce formulaire. Si l'usager valide le formulaire, alors le portail captif passe en mode tunnel.

Le portail cesse de présenter une fenêtre d'authentification périodique à l'usager et met en place les règles strictes, ce qui permet à l'usager d'établir son tunnel. Dans le cas où le formulaire n'a pu être complètement pré-rempli, l'usager doit le compléter avant validation.

Dans le cas où c'est l'usager qui est à l'initiative du passage en mode tunnel et où le formulaire le permet, l'usager a la possibilité de négocier d'un coup plusieurs tunnels (c'est-à-dire des tunnels de natures différentes ou à établir à destination de machines différentes).

Tous les types de flux, pourvu qu'il soit possible de les désigner dans un formulaire tel qu'évoqué au point précédent, peuvent faire l'objet d'un filtrage par le portail captif.

Toutefois, le procédé de l'invention est particulièrement facile à utiliser avec le protocole IPsec dans la mesure où (a) la mise en uvre de ce protocole provoque généralement un passage de l'usager en mode bloquant (la machine ne peut plus communiquer en dehors du tunnel IPsec), ce qui impose le passage en mode tunnel pour pouvoir continuer à fonctionner, et où (b) les flux qui initialisent le montage d'un tunnel IPsec, c'est-à-dire IKE et ses variantes, sont très caractéristiques car ils utilisent des ports TCP/UDP bien connus, généralement UDP 500. De ce fait, le protocole IPsec s'adapte bien au changement automatique de mode à l'initiative du portail captif.

Néanmoins d'autres protocoles de construction de tunnels sont efficacement utilisables conformément à l'invention, notamment les protocoles nommés SSL et GRE par exemple, ainsi que des encapsulations moins courantes, tels que PPP over SSH, ou des implémentations [VTUN] en mode bloquant.

Enfin, les protocoles qui ne servent pas explicitement à monter un tunnel ("http" ou "telnet" par exemple) peuvent aussi être utilisés dans le cadre de l'invention, même si le besoin n'est pas aussi flagrant qu'avec les protocoles de construction de tunnels.

Les portails captifs utilisent généralement le protocole "http" et les outils connexes (navigateur, langage d'exécution comme Java ou PHP, protocoles cryptographiques comme SSL) pour dialoguer avec l'usager. Néanmoins, toute autre solution fonctionnellement équivalente peut être utilisée pour la mise en oeuvre du procédé de l'invention.

Claims (10)

REVENDICATIONS

1. Procédé de contrôle d'accès d'un terminal source (T_SOUR) à un réseau comportant un point d'accès (P_ACC) pour ce terminal, un pare-feu (PF) relié au point d'accès (P_ACC), et un portail (PORT) d'authentification servi par une base (BDD) de données d'authentification, ce portail (PORT) plaçant le pare-feu (PF) dans un état d'autorisation d'accès en réponse à une requête initiale d'accès en mode de base émanant du terminal source (T_SOUR) et incluant la fourniture au portail (PORT) de données d'authentification valides, à défaut desquelles le pare-feu est placé dans un état d'interdiction d'accès, ce portail (PORT) conservant le pare- feu (PF) dans un état d'autorisation d'accès en mode de base en réponse à la fourniture périodique, par le terminal source (T_SOUR) et sur un canal sécurisé d'échange de jeton, d'un jeton d'authentification valide à défaut duquel le pare-feu (PF) est placé dans son état d'interdiction d'accès, et le terminal source (T_SOUR) communiquant sélectivement en mode tunnel avec un terminal de destination (T_DEST) du réseau à travers un tunnel rendant le canal d'échange de jeton inutilisable, caractérisé en ce que le portail (PORT) place et conserve le pare-feu (PF) dans son état d'autorisation d'accès pour une connexion en mode tunnel permettant une communication à travers le tunnel entre le terminal source (T_SOUR) et le terminal de destination (T_DEST) en réponse à une requête préalable d'accès en mode tunnel émanant du terminal source (T_SOUR) et incluant la fourniture au portail (PORT), à travers le canal sécurisé d'échange de jeton, de données d'identification valides du tunnel.

2. Procédé de contrôle d'accès suivant la revendication 1, caractérisé en ce que les données d'identification du tunnel incluent une adresse du terminal de destination (T_DEST).

3. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce que les données d'identification du tunnel incluent une adresse du terminal source (T_SOUR) et, éventuellement, une identification du protocole utilisé par le tunnel.

4. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce que la requête préalable d'accès en mode tunnel répond à une invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel.

5. Procédé de contrôle d'accès suivant la revendication 4, caractérisé en ce que l'invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel est permanente ou périodique.

6. Procédé de contrôle d'accès suivant la revendication 4, caractérisé en ce que l'invitation adressée par le portail {PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel est déclenchée par la détection de préparatifs d'établissement d'une connexion en mode tunnel.

7. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes combinée à la revendication 4, caractérisé en ce que l'invitation adressée par le portail (PORT) au terminal source (T_SOUR) à lui fournir des données d'identification valides pour une connexion en mode tunnel prend la forme d'une fenêtre de maintien de session utilisée également pour la connexion en mode de base.

8. Procédé de contrôle d'accès suivant la revendication 7, caractérisé en ce que la fenêtre de maintien de session comporte un bouton de fin de connexion en mode tunnel.

9. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce qu'en réponse à la détection d'une fin de connexion en mode tunnel émanant du terminal source (T_SOUR), le portail (PORT) adresse au terminal source (T_SOUR) une invitation à lui fournir des données d'authentification valides pour retourner au mode de connexion de base.

10. Procédé de contrôle d'accès suivant l'une quelconque des revendications précédentes, caractérisé en ce que le portail (PORT) met sélectivement fin à une connexion en mode tunnel en plaçant le pare-feu (PF) dans son état d'interdiction d'accès.