WO2004015953A2 - Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local - Google Patents

Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local Download PDF

Info

Publication number
WO2004015953A2
WO2004015953A2 PCT/FR2003/002467 FR0302467W WO2004015953A2 WO 2004015953 A2 WO2004015953 A2 WO 2004015953A2 FR 0302467 W FR0302467 W FR 0302467W WO 2004015953 A2 WO2004015953 A2 WO 2004015953A2
Authority
WO
WIPO (PCT)
Prior art keywords
intermediate module
client
equipment
communication
network
Prior art date
Application number
PCT/FR2003/002467
Other languages
English (en)
Other versions
WO2004015953A3 (fr
Inventor
Jonathan Angel
Franck Lefevre
Original Assignee
Execport Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Execport Ltd filed Critical Execport Ltd
Priority to AU2003274228A priority Critical patent/AU2003274228A1/en
Publication of WO2004015953A2 publication Critical patent/WO2004015953A2/fr
Publication of WO2004015953A3 publication Critical patent/WO2004015953A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos

Definitions

  • the invention relates to the efficient implementation of an access control system to a computer network.
  • Access control systems authenticate, authorize, open and close access to a larger network (usually the public Internet) for computers connected to a local network. Traditionally, these access control systems are located at the local network level.
  • a typical application of this invention relates to the equipment of a hotel wishing to offer broadband Internet access to its customers, without having to manage the complexity of the multiple connection settings for each user, nor the different billing logics of the service, necessary to control this access.
  • the invention allows a centralized Web server to manage all aspects of the user interface, authentication, authorization according to various parameters and to be able to limit itself to a few very simple instructions to the system. access control so that it can open or close access to users on the local network.
  • RADIUS centralized access control This approach is characterized by: a) A simplified local access controller on the network between the user and the Internet, with a Web page requiring a name and a password b) A central RADIUS server which keeps track of authorized users, their name and password, as well as the access parameters used to define the rights of use for a visitor. A user connecting via such a system would typically go through the following steps:
  • Access controller redirects access request to access controller web server
  • the gatekeeper's web server produces a standard login page asking the user for their name and password. - The user enters this information
  • the access controller sends this information (often via the Internet) to the central RADIUS server
  • the RADIUS central server responds to the access controller with an authorization or a refusal of access
  • the access controller opens access to the network, according to the instructions received from the RADIUS central server.
  • This method has two limitations:
  • the authentication options offered to the user are limited to a name and a password. This method is well suited in a business environment, which has a fixed list known a priori of users, but it is very poorly suited for public places where visitors are not known a priori (hotels, airports, cafes) and change very often. 2.
  • the web pages viewed by the user as part of the identification process must be adapted and updated for each site, which is expensive and difficult to manage. 2. Access control managed locally by
  • An alternative method solves the first limitation mentioned above, but not the second. It consists of installing a server machine keeping all of the web pages, databases and authorization parameters - all at the local level.
  • WO 9840990 disclosing a method allowing a user device configured to communicate with a personal network to communicate with a foreign network, comprising the steps consisting in: i) connecting the user device to the foreign network; ii) intercepting packets transmitted from the user device, which would otherwise be discarded by devices on the foreign network in order to determine the user device network parameters without prior knowledge; iii) use the determined network parameters to determine whether to intercept the following packets; iv) automatically modify the packets transmitted from the user device according to the network parameters of the user device and the network parameters of the foreign network.
  • This method of the prior art has the disadvantage that only certain packets are intercepted, which induces a fairly complex logic in the device responsible for intercepting the packets to determine which packets to intercept.
  • This method of the prior art has the disadvantage that only certain packets are intercepted, which induces a fairly significant logic in the device responsible for intercepting the packets to determine which packets to intercept.
  • An “intelligent” network security device (called INSD in the document) is operating in a local area network (LAN) according to an “intelligent” network security process.
  • the local network includes a plurality of computers and is connected to the Internet through a firewall.
  • the device is installed in the local network and accesses the Internet.
  • the device examines the code and patterns of behavior and assigns a value to the intrusion attempts.
  • the device then controls the firewall so that it takes one or more action (s) among a plurality of predefined actions, based on said assigned value.
  • the object of the invention presented in this document is to secure a local network, and more particularly to detect intrusions into the network. This document and the present patent application therefore deal with different issues.
  • the application does not change the size of the data packets between the remote server and the local computer, which makes the implementation much more efficient;
  • the present invention intends to remedy the drawbacks of the prior art by providing a method for centralizing all the elements of the user interface and of access control for multiple sites on a centralized Web server.
  • Intermediate module runs on a machine placed between the client computers of network users and the external broadband network (or the router establishing the connection to this network). This intermediate module has the possibility of opening or closing access to the network for each user. It also directs all requests from unidentified users to the central web server.
  • the central Web server controls the intermediate module, and tells it when to open or close network access for a particular user.
  • the technical problem that the invention intends to solve is to be able to control an intermediate module connected to a local network protected by a firewall (firewall) or a router, from a remote server, without opening a breach in the barrier. -fire. Consequently, the invention solves two concrete problems:
  • the central Web server cannot identify the client computer by using a variable that the intermediate module can understand.
  • IP address when the local network is behind a firewall, the Web server only knows the IP address of the firewall, not the client's address. All client computers behind the firewall seem to have the same IP address.
  • Web session the Web session is known to the Web server, but it cannot be understood by the module intermediary, who can only identify the client computer by its address on the local network.
  • the central Web server cannot send it instructions unless it opens gaps in the firewall, which is most often excluded.
  • the central Web server manages client authentication, it must be able to send instructions to the intermediate module for opening or closing access for a given user. But by definition, a firewall is designed to reject any incoming call from the outside network.
  • the present invention is of the type described above and it is remarkable in its broadest acceptance, in that it relates to a system for controlling access to a public network by client workstations comprising a local network. on which the client computers are connected, at least one client computer having a network interface card having its unique MAC identification, a router / firewall protecting the local network from external attacks and providing an address translation service in order to that multiple clients can share the same public / routable IP address, a connection to the Internet or any other external network and a Web server connected to the Internet or any other network, characterized in that said system further comprises a computer equipped with a intermediate module and having at least two network interface cards placed in "promiscuous" mode so that they receive all the packets circulating on the e network, one of said cards being connected to the local network, the other being connected to the router / firewall, the intermediate module being constituted by a means of interception of all the traffic in transmission or in reception at each level client computer and examining traffic and transporting data between said two network cards,
  • said intermediate module is a software module installed on a computer.
  • said intermediate module is hardware equipment.
  • the intermediate module includes a means for modifying the command without changing either the size or the number of packets of the communication.
  • the remote device encapsulates at least one command for the intermediate module in its communications with the client device
  • the intermediate module intercepts each communication between the client equipment and the remote equipment and acts according to said encapsulated command.
  • the method further comprises a step of transfer to the recipient by said intermediate module of said communication between the client equipment and the remote equipment.
  • said interception step consists in that: • the intermediate module intercepts the communication coming from the client equipment and transfers it to the remote equipment;
  • the intermediate module identifies the address parameters of the client equipment on the local network
  • the encapsulation step consists of the remote equipment and the intermediate module exchanging administrative commands concerning the client equipment, using said common identifier.
  • the step of establishing a common identifier is carried out according to the following steps: the remote equipment responds to the client equipment by transmitting to it a redirection instruction towards a document located on a second remote equipment, said document including a predefined field; the client equipment connects to said document through the intermediate module; the intermediate module intercepts the communication and replaces the predefined field with an identifier of the address parameters of the client equipment on the local network; the second remote device receives the communication transmitted by the intermediate module, said communication containing an identifier of the unique session and the identifier of the parameters address on the local network added by the intermediate module; the second remote device associates the session identifier with the identifier of the address parameters.
  • the step of establishing a common identifier is carried out according to the following steps: the remote equipment responds to a request from the client equipment by including in the response a unique parameter; the intermediate module intercepts said response and associates said unique parameter with the address parameters of the client equipment on the local network.
  • the step of establishing a common identifier is carried out according to the following steps: the remote equipment responds to a request from the client equipment; said response contains an instruction to redirect client equipment to document containing a single parameter; the intermediate module intercepts the communication coming from the client and associates said unique parameter with the address parameters of the client equipment on the local network.
  • the remote equipment responds to a request from the client equipment by encapsulating in this response a trigger command intended for the intermediate module in order to generate an action of the intermediate module.
  • the intermediate module intercepts said triggering command in the communication from the remote equipment to the client equipment.
  • This trigger command implies that the intermediate module sends a request to the remote device for instructions.
  • the remote device responds to the request from the intermediate module.
  • the client equipment returns a message to the remote equipment, containing said triggering command
  • the intermediate module intercepts said triggering command in the communication from the client equipment to the remote equipment;
  • - Said trigger command implies that the intermediate module sends a request to the remote equipment to obtain instructions; -the remote equipment responds to the request from the intermediate module.
  • FIG. 2 illustrates a first embodiment of the invention for identifying the client computer on the local network
  • FIG. 3 illustrates a second embodiment of the invention for identifying the client computer on the local network
  • FIG. 4 illustrates a third embodiment of the invention for identifying the client computer on the local network
  • FIG. 5 illustrates a first embodiment of the invention for sending instructions to the local agent
  • FIG. 6 illustrates a second embodiment of the invention for sending instructions to the local agent.
  • a local network where the client computers are connected (this can be any type of network, for example Ethernet, wireless, DSL, etc.)
  • One or more client computers each has a network interface card with its unique MAC identification
  • a machine on which the intermediate module runs having at least two network interface cards. One card is connected to the local network, the other is connected to the router / firewall (see below). These cards are both placed in "promiscuous" mode so that they receive all the packets circulating on the network.
  • a router / firewall that protects the local network from external attacks and provides an address translation service so that multiple clients can share the same public / routable IP address.
  • the intermediate module intercepts all the traffic in transmission or reception at each client computer. It examines traffic and transports data between its two network cards, redirecting traffic to new destinations as shown below.
  • a new client When a new client connects to the local network, it begins to send packets over the network. These packets can include, among others, DHCP requests, network announcements, ARP requests for local servers, Internet calls, etc.
  • the intermediate module intercepts these packets and processes them as follows:
  • DNS server Domain name server
  • DNS responses are sent to the client computer.
  • Domain names that cannot be resolved by the local DNS server are associated with a default IP address.
  • TCP / IP from all client computers.
  • requests using the http protocol it is configured to accept both standard and proxy requests.
  • the server responds to the client with an http redirect to a document named XXX in the rest of the presentation.
  • XXX has a particular shape, and includes a predetermined parameter. This parameter is called “magic-string” in the remainder of this document.
  • the target server for the redirect is the central web server.
  • the browser receives the redirect command, and therefore follows the redirect instruction.
  • the intermediate module intercepts http requests from the client computer containing the magic-string, replaces it with the information on the client computer that sent the packet first, then sends the modified packet to the server specified by the URL.
  • Information on the computer typically contains:
  • the unique code identifying the site (this allows a central server to work simultaneously with multiple sites and multiple intermediate modules) •
  • the identifier of the client computer on the local network (it is generally a unique reference created by the middle module, but it can also include the MAC address of the client computer)
  • the length of the magic-string is the same as that of the client computer identifier on the local network. This ensures that the number of packets passing through the intermediate module remains unchanged.
  • the central web server receives the packet with the modified magic-string. It then has information on the client computer, and in particular:
  • the server has an active web session with the web browser on the client computer.
  • the central web server guides the user through the identification process. When it has successfully identified a new user, it creates an administrative command for the intermediate module so that it can open Internet access, identifying the corresponding local computer by a local address in a format understood by the module. intermediate. The administrative command can then also deactivate the systematic sending of TCP / IP packets to the central Web server.
  • XXX contains a unique code created by the "central" web server in a predefined format and position.
  • the intermediate module intercepts this unique code, and associates the unique code with the local address of the client computer without modifying the information intended for the client. From this point on, the central web server can create administrative commands for the middle module using this unique code to identify the client computer.
  • XXX contains a unique code created through the central web server.
  • This unique code has a predefined format and position.
  • the client computer receives the redirection command, returns a new request to obtain XXX.
  • the intermediate module intercepts this command sent with this unique code, associates this code with the address of the local computer of the client computer and sends the request to the server designated in the redirection command. From this point on, the central web server can send administrative commands to the intermediate module using this unique code to identify the client computer.
  • the central web server needs to be able to tell the middle module that it must open network access to the client.
  • the intermediate module blocks this type of command, since it comes from outside the local network. It is the very purpose of a firewall.
  • the invention solves this difficulty by making the intermediate module the initiator of any communication with the central Web server.
  • the central Web server When the central Web server has commands intended for the intermediate module, it inserts in its next response to an http request coming from a client passing through an order pushing the client to make a request to a new document named YYY and containing a predetermined text or object which serves as a trigger for the intermediate module and is called “trigger” in the rest of the presentation.
  • This request can be initiated either by an http redirect request to YYY, or by the inclusion in the returned document of a link to YYY.
  • the intermediate module intercepts all the packets from the client computer, and "sees" the request for YYY from the client computer and containing the trigger.
  • the intermediate module then contacts the central Web server with an http request.
  • the server responds to this request with a data block containing the command it wishes to communicate to the intermediate module.
  • This command contains the local address of the client computer and the conditions under which network access must be opened (for example: duration, volume limitation, etc.)
  • the firewall sees the http session between the middle module and the central web server as a standard http session, nothing different from another http session between a client and a server. As long as the central web server responds to a request from behind the firewall, data is transferred through the firewall.
  • the intermediate module intercepts all the packets coming from the central Web server intended for the client computer, and "sees" the trigger, predefined in the new document.
  • the intermediate module without influencing the communication between the client and the server, then contacts the central Web server with an http request.
  • the server responds to this request with a data block containing the command it wishes to communicate to the intermediate module.
  • This command contains the local address of the client computer and the conditions under which network access must be opened (for example: duration, volume limitation, etc.)
  • the creation of a communication between the intermediate module and the central Web server does not interrupt the communication between the client and the central web server. It continues to be active and to pass through the intermediate module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un procédé de communication entre un équipement client et un module intermédiaire situés tous les deux sur un réseau local et un équipement distant situé sur un réseau distant caractérisé en ce que: l'équipement client initie une connexion avec l'équipement distant; l'équipement distant encapsule au moins une commande pour le module intermédiaire dans ses communications avec l'équipement client; le module intermédiaire intercepte chaque communication entre l'équipement client et l'équipement distant et agit selon ladite commande encapsulée. Elle concerne aussi un système pour la mise en œuvre d'un tel procédé.

Description

PROCEDE ET ARCHITECTURE DE COMMUNICATION ENTRE UN EQUIPEMENT CLIENT ET UN MODULE INTERMEDIAIRE SITUES TOUS LES DEUX SUR UN RESEAU LOCAL.
L'invention concerne la mise en œuvre efficace d'un système de contrôle d'accès à un réseau informatique. Les systèmes de contrôle d'accès authentifient, autorisent, ouvrent et ferment l'accès à un réseau plus vaste (en général l'Internet public) pour des ordinateurs reliés à un réseau local. Traditionnellement, ces systèmes de contrôle d'accès se situent au niveau du réseau local.
Une application typique de cette invention concerne l'équipement d'un hôtel souhaitant offrir un accès Internet haut-débit à ses clients, sans pour autant avoir à gérer la complexité des multiples paramétrages de connexion de chaque utilisateur, ni les différentes logiques de facturation du service, nécessaires pour contrôler cet accès.
De manière spécifique, l'invention permet à un serveur Web centralisé de gérer tous les aspects de l'interface utilisateur, de 1 ' authentification, de l'autorisation en fonction de paramètres divers et de pouvoir se limiter à quelques instructions très simples au système de contrôle d'accès afin qu'il puisse ouvrir ou fermer l'accès à des utilisateurs sur le réseau local.
État de l'art
L'état de l'art dans les réseaux haut-débit peut être groupé en deux catégories :
1. Le contrôle d'accès centralisé RADIUS 2. Le contrôle d'accès géré localement
1. Le contrôle d'accès centralisé RADIUS Cette approche est caractérisée par : a) Un contrôleur d'accès local simplifié sur le réseau entre l'utilisateur et Internet, avec une page Web requérant un nom et un mot de passe b) Un serveur centralisé RADIUS qui conserve trace des utilisateurs autorisés, leur nom et leur mot de passe, ainsi que les paramètres d'accès permettant de définir les droits d'utilisation d'un visiteur. Un utilisateur se connectant via un tel système passerait typiquement par les étapes suivantes :
L'utilisateur demande l'accès à une page Web depuis son navigateur
Le contrôleur d'accès redirige la demande d'accès vers le serveur Web du contrôleur d'accès
Le serveur Web du contrôleur d'accès produit une page de connexion standard demandant à l'utilisateur son nom et son mot de passe. - L'utilisateur entre ces informations
Le contrôleur d'accès envoie ces informations (souvent via Internet) au serveur central RADIUS
Le serveur central RADIUS répond au contrôleur d'accès avec une autorisation, ou un refus d'accès
En cas d'autorisation, le contrôleur d'accès ouvre l'accès au réseau, en fonction des instructions reçues du serveur central RADIUS .
Cette méthode possède deux limitations :
1. Les options d' aut entification offertes à l'utilisateur se limitent à un nom et un mot de passe. Cette méthode est bien adaptée en environnement d'entreprise, qui possède une liste fixe et connue a priori d'utilisateurs, mais elle est très mal adaptée pour les lieux publics où les visiteurs ne sont pas connus a priori (hôtels, aéroports, cafés) et changent très souvent. 2. Les pages Web vues par l'utilisateur dans le cadre du processus d'identification doivent être adaptées et mises à jour pour chaque site, ce qui est coûteux et difficile à gérer. 2. Le contrôle d'accès géré localement par
1 'administrateur réseau
Une méthode alternative permet de résoudre la première limitation mentionnée ci-dessus, mais pas la seconde. Elle consiste à installer une machine serveur conservant l'ensemble des pages Web, bases de données et de paramètres d'autorisation — tout au niveau local.
Toutefois, les limitations de cette approche sont les suivantes :
- l'installation et la maintenance d'un tel système sont complexes. Chaque site possède sa propre configuration, son propre jeu de pages Web, de paramètres d'autorisation, etc. Les mises à jour deviennent problématiques dès que le nombre de sites gérés devient important. - l'interface avec les données centralisées est complexe. Elle nécessite que des standards très stricts soient établis pour les protocoles d'autorisation entre le contrôleur d'accès et le serveur centralisé. Toute déviation de ces standards nécessite en effet une mise à jour coordonnée de la logique d'autorisation sur chacun des points d'accès locaux des contrôleurs.
On connaît également dans l'art antérieur la demande de brevet internationale WO 9840990 divulguant une méthode permettant à un dispositif utilisateur configuré pour communiquer avec un réseau personnel de communiquer avec un réseau étranger, comprenant les étapes consistant à : i ) connecter le dispositif utilisateur au réseau étranger ; i i ) intercepter les paquets transmis du dispositif utilisateur, qui seraient dans un autre cas jetés par les dispositifs du réseau étranger afin de déterminer sans connaissance préalable les paramètres réseau du dispositif utilisateur ; iii) utiliser les paramètres réseau déterminés pour déterminer s'il faut intercepter les paquets suivants ; i v ) modifier automatiquement les paquets transmis depuis le dispositif utilisateur en fonction des paramètres réseau du dispositif utilisateur et des paramètres réseau du réseau étranger.
Cette méthode de l'art antérieur comporte l'inconvénient que seuls certains paquets sont interceptés, ce qui induit une logique assez complexe dans le dispositif chargé d'intercepter les paquets pour déterminer quels paquets intercepter.
Cette méthode de l'art antérieur comporte l'inconvénient que seuls certains paquets sont interceptés, ce qui induit une logique assez importante dans le dispositif chargé d'intercepter les paquets pour déterminer quels paquets intercepter.
L'art antérieur connaît également, par le brevet américain US 6 119 236 (Shipley Peter M), un dispositif
« intelligent » de sécurisation des réseaux et un procédé associé à ce dispositif. Un dispositif « intelligent » de sécurisation des réseaux (appelé INSD dans le document) est en fonctionnement dans un réseau local (LAN) selon un procédé « intelligent » de sécurisation des réseaux. Le réseau local comporte une pluralité d'ordinateurs et est connecté à l'Internet à travers un pare-feu (firewall). Le dispositif est installé dans le réseau local et accède à l'Internet. Le dispositif examine le code et les « patterns » de comportement et attribue une valeur aux tentatives d'intrusion. Le dispositif commande ensuite le pare-feu pour qu'il prenne une ou plusieurs action(s) parmi une pluralité d'actions prédéfinies, en se basant sur ladite valeur attribuée. Le but de l'invention présentée dans ce document est de sécuriser un réseau local, et plus particulièrement de détecter les intrusions dans le réseau. Ce document et la présente demande de brevet traitent donc des problématiques différentes .
La présente invention se distingue de l'art antérieur :
• des « patterns » de données prédéterminés sont envoyés du serveur distant à l'ordinateur local ;
• ces « patterns » de données sont utilisés comme charges utiles pour transporter des informations entre le serveur distant et l'application ;
• le besoin d'établir une communication entre le serveur distant et l'application est éliminé ;
• en utilisant une charge utile, l'application ne modifie pas la taille des paquets de données entre le serveur distant et l'ordinateur local, ce qui rend 1 ' implémentation beaucoup plus efficace ;
• ces informations sont corrélées avec une session de communication active entre le serveur distant et l'ordinateur local.
Problème technique résolu par 1 'invention
La présente invention entend remédier aux inconvénients de l'art antérieur en fournissant une méthode pour centraliser tous les éléments de l'interface utilisateur et du contrôle d'accès de multiples sites sur un serveur Web centralisé.
Sur chaque site, au niveau du réseau local, un agent logiciel, appelé dans la suite de ce document
« module intermédiaire' » , tourne sur une machine placée entre les ordinateurs clients des utilisateurs du réseau et le réseau externe haut-débit (ou le routeur établissant la connexion à ce réseau). Ce module intermédiaire a la possibilité d'ouvrir ou de fermer l'accès au réseau pour chaque utilisateur. Il dirige également toutes les requêtes des utilisateurs non identifiés vers le serveur Web central.
Le serveur Web central contrôle le module intermédiaire, et lui indique quand ouvrir ou fermer l'accès au réseau pour tel ou tel utilisateur. Le problème technique que l'invention entend résoudre est de pouvoir contrôler un module intermédiaire connecté à un réseau local protégé par un pare-feu (firewall) ou un routeur, à partir d'un serveur distant, ceci sans ouvrir de brèche dans le pare-feu. Par conséquent, l'invention résout deux problèmes concrets :
1. Lorsque l'ordinateur client et le module intermédiaire sont situés derrière un pare-feu, le serveur Web central ne peut pas identifier l'ordinateur client en utilisant une variable que le module intermédiaire pourra comprendre.
Lorsqu'un ordinateur client se connecte au serveur Web central, celui-ci a deux façons de l'identifier:
• Par son adresse IP • Par la session Web
Mais aucune de ces informations ne convient pour que le serveur Web central base ses instructions au module intermédiaire:
• L'adresse IP: lorsque le réseau local est derrière un pare-feu, le serveur Web ne connaît que l'adresse IP du pare-feu, et non l'adresse du client. Tous les ordinateurs clients situés derrière le pare-feu semblent ainsi avoir la même adresse IP.
• Session Web: la session Web est connue du serveur Web, mais elle n'est pas compréhensible par le module intermédiaire, qui ne peut identifier l'ordinateur client que par son adresse sur le réseau local.
2. Lorsque le module intermédiaire est situé derrière un pare-feu, le serveur Web central ne peut pas lui envoyer d'instruction à moins d'ouvrir des brèches dans le pare-feu, ce qui est le plus souvent exclu.
Si le serveur Web central gère les authentifications des clients, il lui est nécessaire de pouvoir envoyer des instructions au module intermédiaire pour l'ouverture ou la fermeture de l'accès pour tel ou tel utilisateur. Mais par définition, un pare-feu est conçu pour rejeter tout appel entrant du réseau extérieur.
Pour ce faire, la présente invention est du type décrit ci-dessus et elle est remarquable dans son acceptation la plus large, en ce qu'elle concerne un système de contrôle d'accès à un réseau public par des postes clients comportant un réseau local sur lequel sont connectés les ordinateurs clients, au moins un ordinateur client possédant une carte d'interface réseau ayant son identification MAC unique, un routeur/pare-feu protégeant le réseau local d'attaques extérieures et fournissant un service de traduction d'adresse afin que de multiples clients puissent partager la même adresse IP publique/routable, une connexion à Internet ou tout autre réseau externe et un serveur Web connecté à Internet ou tout autre réseau, caractérisé en ce que ledit système comporte en outre un ordinateur équipé d'un module intermédiaire et possédant au moins deux cartes d'interface réseau placées en mode « promiscuous » afin qu'elles reçoivent tous les paquets circulant sur le réseau, l'une desdites cartes étant connectée au réseau local, l'autre étant connectée au routeur/pare-feu, le module intermédiaire étant constitué par un moyen d'interception de tout le trafic en émission ou en réception au niveau de chaque ordinateur client et d'examen du trafic et de transport des données entre lesdites deux cartes réseau, pour rediriger le trafic vers de nouvelles destinations .
Selon une première variante, ledit module intermédiaire est un module logiciel installé sur un ordinateur.
Selon une deuxième variante, ledit module intermédiaire est un équipement matériel.
De préférence, le module intermédiaire comporte un moyen pour modifier la commande sans changer ni la taille, ni le nombre de paquets de la communication.
L'invention concerne aussi un procédé de communication entre un équipement client et un module intermédiaire situés tous les deux sur un réseau local et un équipement distant situé sur un réseau distant caractérisé en ce que :
•l'équipement client initie une connexion avec l'équipement distant ;
• l'équipement distant encapsule au moins une commande pour le module intermédiaire dans ses communications avec l'équipement client ;
• le module intermédiaire intercepte chaque communication entre l'équipement client et l'équipement distant et agit selon ladite commande encapsulée.
Selon une variante, le procédé comporte en outre une étape de transfert au destinataire par ledit module intermédiaire de ladite communication entre l'équipement client et l'équipement distant.
Avantageusement, ladite étape d'interception consiste en ce que : • le module intermédiaire intercepte la communication provenant de l'équipement client et la transfère à l'équipement distant ;
• le module intermédiaire identifie les paramètres d'adresse de l'équipement client sur le réseau local ;
• l'équipement distant établit une session unique avec l'équipement client ;
• l'équipement distant et le module intermédiaire établissent un identifiant commun de la connexion du client sur le réseau local ;
L'étape d ' encapsulation consiste à ce que l'équipement distant et le module intermédiaire échangent des commandes administratives concernant l'équipement client, en utilisant ledit identifiant commun.
Selon une variante, l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes : l'équipement distant répond à l'équipement client en lui transmettant une instruction de redirection vers un document situé sur un deuxième équipement distant, ledit document comprenant un champ prédéfini ; l'équipement client se connecte audit document à travers le module intermédiaire ; le module intermédiaire intercepte la communication et remplace le champ prédéfini par un identifiant des paramètres d'adresse de l'équipement client sur le réseau local ; - le deuxième équipement distant reçoit la communication transmise par le module intermédiaire, ladite communication contenant un identifiant de la session unique et l'identifiant des paramètres d'adresse sur le réseau local ajouté par le module intermédiaire ; le deuxième équipement distant associe l'identifiant de session à l'identifiant des paramètres d'adresse.
De préférence, l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes : l'équipement distant répond à une requête de l'équipement client en incluant dans la réponse un paramètre unique ; le module intermédiaire intercepte ladite réponse et associe ledit paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local.
Avantageusement, l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes : l'équipement distant répond à une requête de l'équipement client ; ladite réponse contient une instruction de redirection de l'équipement client vers document contenant un paramètre unique ; le module intermédiaire intercepte la communication provenant du client et associe ledit paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local.
Selon une variante, l'équipement distant répond à une demande de l'équipement client en encapsulant dans cette réponse une commande de déclenchement à l'intention du module intermédiaire afin de générer une action du module intermédiaire.
De préférence, le module intermédiaire intercepte ladite commande de déclenchement dans la communication de l'équipement distant vers l'équipement client. Cette commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions. L'équipement distant répond à la requête du module intermédiaire. Selon un mode de mise en œuvre particulier :
- l'équipement client retourne un message à l'équipement distant, contenant ladite commande de déclenchement ;
- le module intermédiaire intercepte ladite commande de déclenchement dans la communication de l'équipement client vers l'équipement distant ;
- ladite commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions ; -l'équipement distant répond à la requête du module intermédiaire.
L'invention sera mieux comprise à la lecture de la description qui suit, se référant aux dessins annexés concernant un exemple non limitatif de réalisation, où : - La figure 1 illustre une vue globale de
1 ' architecture;
La figure 2 illustre un premier mode de réalisation de l'invention pour identifier l'ordinateur client sur le réseau local ; - La figure 3 illustre un deuxième mode de réalisation de l'invention pour identifier l'ordinateur client sur le réseau local;
La figure 4 illustre un troisième mode de réalisation de l'invention pour identifier l'ordinateur client sur le réseau local ;
- La figure 5 illustre un premier mode de réalisation de l'invention pour envoyer des instructions à l'agent local ; -La figure 6 illustre un deuxième mode de réalisation de l'invention pour envoyer des instructions à l'agent local.
Architecture
L'invention décrite de façon schématique en référence à la figure 1 utilise les éléments d'architecture suivants :
• Un réseau local où sont connectés les ordinateurs clients (ce peut être n'importe quel type de réseau, par exemple Ethernet, sans fil, DSL, etc.)
• Un ou plusieurs ordinateurs clients (chacun possède une carte d'interface réseau ayant son identification MAC unique) • Une machine sur laquelle tourne le module intermédiaire, possédant au moins deux cartes d'interface réseau. Une carte est connectée au réseau local, l'autre est connectée au routeur/pare-feu (voir ci-dessous). Ces cartes sont toutes deux placées en mode « promiscuous » afin qu'elles reçoivent tous les paquets circulant sur le réseau.
• Un routeur/pare-feu qui protège le réseau local d'attaques extérieures et fournit un service de traduction d'adresse afin que de multiples clients puissent partager la même adresse IP publique/routable.
• Une connexion à Internet ou tout autre réseau externe
• Un serveur Web connecté à Internet ou tout autre réseau. L'architecture du système est donnée en figure 1.
Dans l'invention, le module intermédiaire intercepte tout le trafic en émission ou en réception au niveau de chaque ordinateur client. Il examine le trafic et transporte les données entre ses deux cartes réseau, redirigeant le trafic vers de nouvelles destinations comme indiqué ci-dessous.
Identifier l'ordinateur client sur le réseau local
Lorsqu'un nouveau client se connecte au réseau local, il commence à envoyer des paquets sur le réseau. Ces paquets peuvent comprendre, entre autres, des requêtes DHCP, des annonces réseau, des requêtes ARP pour des serveurs locaux, des appels Internet, etc. Le module intermédiaire intercepte ces paquets et les traite de la manière suivante :
• Tous les paquets sont inspectés pour vérifier qu'il s'agit bien d'un nouveau client (identifié par son adresse MAC). Lorsqu'un nouveau client est détecté, il est ajouté à la liste des ordinateurs clients connus. • Toutes les requêtes DHCP sont envoyées sur le réseau externe (où un serveur DHCP doit être installé). De manière similaire, les réponses DHCP sont renvoyées à l'ordinateur client sur le réseau interne. Cela permet aux ordinateurs clients activant DHCP d'obtenir une information IP correcte sur le réseau externe.
• Toutes les requêtes ARP pour la résolution d'adresse MAC d'une adresse IP font l'objet d'une réponse avec l'adresse MAC du routeur du réseau externe.
• Toutes les demandes de résolution de nom de domaine sont envoyées à un serveur DNS (Domain name server) qui est accessible au réseau local (il peut être situé sur le réseau externe, ou via le fournisseur d'accès Internet du réseau local). Les réponses du DNS sont envoyées à l'ordinateur client. Les noms de domaine qui ne peuvent être résolus par le serveur DNS local (par exemple les noms de domaine locaux, spécifiques pour un réseau d'entreprise) sont associés à une adresse IP par défaut.
• Toutes les autres requêtes TCP/IP sont envoyées à un serveur Web centralisé sur un port spécifié (ou un ensemble de ports). Ceci est fait en remplaçant l'adresse IP de destination de chaque paquet avec l'adresse IP du serveur Web centralisé, et le numéro du port par l'un des ports que le serveur Web centralisé écoute, et l'adresse MAC par l'adresse MAC du routeur sur le réseau externe. Le serveur Web centralisé reçoit les requêtes
TCP/IP de tous les ordinateurs clients. Concernant les requêtes utilisant le protocole http, il est configuré pour accepter aussi bien les requêtes standards que proxy. Lorsque ces requêtes sont des requêtes standards, le serveur répond au client par une redirection http vers un document nommé XXX dans la suite de l'exposé.
Dans une des réalisations de l'invention (comme indiqué sur la figure 2), XXX possède une forme particulière, et comprend un paramètre prédéterminé. Ce paramètre s'appelle « magic-string » dans la suite de ce document. Le serveur cible de la redirection est le serveur Web central.
Si la requête initiale provenait d'un navigateur Web, alors le navigateur reçoit la commande redirect, et suit donc l'instruction de redirection.
Le module intermédiaire intercepte les requêtes http de l'ordinateur client contenant la magic-string, remplace celle-ci par l'information sur l'ordinateur client qui a envoyé le paquet en premier, puis envoie le paquet ainsi modifié sur le serveur spécifié par l'URL. L' information sur 1 'ordinateur contient typiquement :
• Le code unique identifiant le site (cela permet à un serveur central de travailler simultanément avec de multiples sites et de multiples modules intermédiaires) • L'identifiant de l'ordinateur client sur le réseau local (c'est généralement une référence unique créée par le module intermédiaire, mais il peut également inclure l'adresse MAC de l'ordinateur client)
La longueur de la magic-string (en caractères) est identique à celle de l'identifiant de l'ordinateur client sur le réseau local. Cela permet d'assurer que le nombre de paquets transitant par le module intermédiaire reste inchangé.
Le serveur Web central reçoit le paquet avec la magic-string modifiée. Il dispose alors de l'information sur l'ordinateur client, et notamment :
• L'identifiant de l'ordinateur client sur le réseau local (en un format que le module intermédiaire peut comprendre) • L'identifiant du site où l'ordinateur client est connecté
• En outre, le serveur a une session Web active avec le navigateur Web sur l'ordinateur client.
Le serveur Web central guide l'utilisateur pendant le processus d'identification. Lorsqu'il a réussi à identifier un nouvel utilisateur, il crée une commande administrative destinée au module intermédiaire afin que celui-ci puisse ouvrir l'accès Internet, en identifiant l'ordinateur local correspondant par une adresse locale en un format compris par le module intermédiaire. La commande administrative peut alors désactiver également l'envoi systématique des paquets TCP/IP sur le serveur Web central.
Dans une autre réalisation de l'invention (décrite en figure 3 ) , XXX contient un code unique crée par le serveur Web «central dans un format et une position prédéfinis. Le module intermédiaire intercepte ce code unique, et associe le code unique à l'adresse locale de l'ordinateur client sans modifier les informations destinées au client. A partir de ce moment, le serveur Web central peut créer des commandes d'administration pour le module intermédiaire en utilisant ce code unique pour identifier l'ordinateur client.
Enfin, dans une autre réalisation de l'invention (décrite en figure 4), XXX contient un code unique crée par le serveur Web central. Ce code unique a un format et une position prédéfinis. L'ordinateur client reçoit la commande de redirection, renvoie une nouvelle requête pour obtenir XXX. Le module intermédiaire intercepte cette commande émise avec ce code unique, associe ce code à l'adresse de l'ordinateur local de l'ordinateur client et envoie la requête au serveur désigné dans la commande de redirection. A partir de ce moment, le serveur Web central peut envoyer des commandes d'administration au module intermédiaire en utilisant ce code unique pour identifier l'ordinateur client.
Envoyer des instructions au module intermédiaire Lorsque le processus d'identification d'un nouveau client est terminé, le serveur Web central a besoin de pouvoir indiquer au module intermédiaire qu'il doit ouvrir l'accès au réseau au client. Or, lorsque le module intermédiaire est situé derrière un pare-feu, ce dernier bloque ce type de commande, car elle provient de l'extérieur du réseau local. C'est l'objet même d'un pare- feu.
L'invention résout cette difficulté en faisant du module intermédiaire l'initiateur de toute communication avec le serveur Web central.
Lorsque le serveur Web central possède des commandes destinées au module intermédiaire, il insère dans sa prochaine réponse à une requête http venant d'un client passant par l'intermédiaire une commande poussant le client à effectuer une requête vers un nouveau document nommé YYY et contenant un texte ou objet prédéterminé qui sert de déclencheur au module intermédiaire et nommé « déclencheur » dans la suite de l'exposé. Cette requête peut être initiée soit par une demande de redirection http vers YYY, soit par l'inclusion dans le document renvoyé d'un lien vers YYY. Exemple : image dans document HTML dont la source est YYY. Dans une des mises en œuvre de l'invention (cf. figure 5), le module intermédiaire intercepte tous les paquets de l'ordinateur client, et « voit » la requête pour YYY de l'ordinateur client et contenant le déclencheur. Le module intermédiaire contacte alors le serveur Web central par une requête http. Le serveur répond à cette requête avec un bloc de données contenant la commande qu'il souhaite communiquer au module intermédiaire. Cette commande contient l'adresse locale de l'ordinateur client et les conditions dans lesquelles l'accès au réseau doit être ouvert (par exemple : durée, limitation en volume, etc.)
Le pare-feu voit la session http entre le module intermédiaire et le serveur Web central comme une session http classique, en rien différente d'une autre session http entre un client et un serveur. Tant que le serveur Web central répond à une requête provenant de derrière le pare-feu, les données sont transférées par le pare-feu.
Dans une autre mise en œuvre de l'invention (cf. figure 6), le module intermédiaire intercepte tous les paquets provenant du serveur Web central destinés à l'ordinateur client, et « voit » le déclencheur, prédéfini dans le nouveau document. Le module intermédiaire, sans influer sur la communication entre le client et le serveur, contacte alors le serveur Web central avec une requête http. Le serveur répond à cette requête avec un bloc de données contenant la commande qu'il souhaite communiquer au module intermédiaire. Cette commande contient l'adresse locale de l'ordinateur client et les conditions dans lesquelles l'accès au réseau doit être ouvert (par exemple : durée, limitation en volume, etc.)
Dans tous les cas, la création d'une communication entre le module intermédiaire et le serveur Web central n'interrompt pas la communication entre le client et le serveur Web central. Celle-ci continue d'être active et de passer à travers le module intermédiaire.

Claims

REVENDICATIONS
1 - Procédé de communication entre un équipement client et un module intermédiaire situés tous les deux sur un réseau local et un équipement distant situé sur un réseau distant, caractérisé en ce que :
• l ' équipement client initie une connexion avec l ' équipement distant;
• l ' équipement distant encapsule au moins une commande pour le module intermédiaire dans ses communications avec l ' équipement client;
• le module intermédiaire intercepte chaque communication entre l ' équipement client et l ' équipement distant et agit selon ladite commande encapsulée .
2 - Procédé de communication selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape de transfert au destinataire par ledit module intermédiaire de ladite communication entre l'équipement client et l'équipement distant.
3 - Procédé de communication selon la revendication 1 ou 2, caractérisé en ce que l'action du module intermédiaire consiste à modifier la commande sans changer ni la taille, ni le nombre de paquets de la communication.
4 - Procédé de communication selon l'une des revendications 1 à 3, caractérisé en ce que ledit module intermédiaire est un module logiciel installé sur un ordinateur.
5 - Procédé de communication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape d'interception consiste à : • le module intermédiaire intercepte la communication provenant de l'équipement client et la transfère à l'équipement distant ;
• le module intermédiaire identifie les paramètres d'adresse de l'équipement client sur le réseau local ;
• l'équipement distant établit une session unique avec l'équipement client ;
• l'équipement distant et le module intermédiaire établissent un identifiant commun de la connexion du client sur le réseau local ; et en ce que l'étape d'encapsulation consiste en particulier à ce que l'équipement distant et le module intermédiaire échangent des commandes administratives concernant l'équipement client, en utilisant ledit identifiant commun.
6 - Procédé de communication selon la revendication 5, caractérisé en ce que l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes : l'équipement distant répond à l'équipement client en lui transmettant une instruction de redirection vers un document situé sur un deuxième équipement distant, ledit document comprenant un champ prédéfini ; l'équipement client se connecte audit document à travers le module intermédiaire ; le module intermédiaire intercepte la communication et remplace le champ prédéfini par un identifiant des paramètres d'adresse de l'équipement client sur le réseau local ; le deuxième équipement distant reçoit la communication transmise par le module intermédiaire, ladite communication contenant un identifiant de la session unique et l'identifiant des paramètres d'adresse sur le réseau local ajouté par le module intermédiaire ; le deuxième équipement distant associe l'identifiant de session à l'identifiant des paramètres d'adresse.
7 - Procédé de communication selon la revendication 5, caractérisé en ce que l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes : l'équipement distant répond à une requête de l'équipement client en incluant dans la réponse un paramètre unique ; - le module intermédiaire intercepte ladite réponse et associe ledit paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local.
8 - Procédé de communication selon la revendication
5, caractérisé en ce que l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes : l'équipement distant répond à une requête de l'équipement client ; ladite réponse contient une instruction de redirection de l'équipement client vers document contenant un paramètre unique ; le module intermédiaire intercepte la communication provenant du client et associe ledit paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local. 9 - Procédé de communication selon l'une quelconque des revendications 1 à 4 , caractérisé en ce que : l'équipement distant répond à une demande de l'équipement client en encapsulant dans cette réponse une commande de déclenchement à l'intention du module intermédiaire afin de générer une action du module intermédiaire .
10 - Procédé de communication selon la revendication 9 , caractérisé en ce que : le module intermédiaire intercepte ladite commande de déclenchement dans la communication de l'équipement distant vers l'équipement client ; ladite commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions ; - l'équipement distant répond à la requête du module intermédiaire .
11 - Procédé de communication selon la revendication 9 , caractérisé en ce que : - l'équipement client retourne un message à l'équipement distant, contenant ladite commande de déclenchement ; le module intermédiaire intercepte ladite commande de déclenchement dans la communication de l'équipement client vers l'équipement distant ; ladite commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions ; l'équipement distant répond à la requête du module intermédiaire.
12 — Système de contrôle d'accès à un réseau public par des postes clients susceptible de mettre en œuvre le procédé selon l'une quelconque des revendications précédentes comportant un réseau local sur lequel sont connectés les ordinateurs clients, au moins un ordinateur client possédant une carte d'interface réseau ayant son identification MAC unique, un routeur/pare-feu protégeant le réseau local d'attaques extérieures et fournissant un service de traduction d'adresse afin que de multiples clients puissent partager la même adresse IP publique/routable, une connexion à un réseau externe [comme par exemple Internet] et un . serveur Web connecté à un réseau [comme par exemple Internet], caractérisé en ce que ledit système comporte en outre un ordinateur équipé d'un module intermédiaire et possédant au moins deux cartes d'interface réseau placées en mode « promiscuous » afin qu'elles reçoivent tous les paquets circulant sur le réseau, l'une desdites cartes étant connectée au réseau local, l'autre étant connectée au routeur/pare-feu, le module intermédiaire étant constitué par un moyen d'interception de tout le trafic en émission ou en réception au niveau de chaque ordinateur client et d'examen du trafic et de transport des données entre lesdites deux cartes réseau, pour rediriger le trafic vers de nouvelles destinations .
13 - Système de contrôle d'accès selon la revendication 12, caractérisé en ce que ledit module intermédiaire est un module logiciel installé sur un ordinateur. 14 - Système de contrôle d'accès selon la revendication 12, caractérisé en ce que ledit module intermédiaire est un équipement matériel.
15 - Système de contrôle d'accès selon l'une quelconque des 12 à 14, caractérisé en ce que le module intermédiaire comporte un moyen pour modifier la commande sans changer ni la taille, ni le nombre de paquets de la communication.
PCT/FR2003/002467 2002-08-06 2003-08-05 Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local WO2004015953A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003274228A AU2003274228A1 (en) 2002-08-06 2003-08-05 Method and architecture for communication between a client equipment and an intermediary module which are both located on a local network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0210001A FR2843508A1 (fr) 2002-08-06 2002-08-06 Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local
FR02/10001 2002-08-06

Publications (2)

Publication Number Publication Date
WO2004015953A2 true WO2004015953A2 (fr) 2004-02-19
WO2004015953A3 WO2004015953A3 (fr) 2004-04-22

Family

ID=30470965

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/002467 WO2004015953A2 (fr) 2002-08-06 2003-08-05 Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local

Country Status (3)

Country Link
AU (1) AU2003274228A1 (fr)
FR (1) FR2843508A1 (fr)
WO (1) WO2004015953A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006092042A1 (fr) * 2005-03-02 2006-09-08 6002552 Canada Inc. Procede et protocole permettant de transmettre des commandes etendues a des dispositifs usb

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3004827B1 (fr) * 2013-04-19 2018-10-12 Hopi Procede pour l'utilisation a distance d'un lecteur usb de carte a puce associe a une carte professionnelle de sante ou a une carte patient dite carte vitale et systeme associe.

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0986229A2 (fr) * 1998-09-09 2000-03-15 JSB Software Technology plc Procédé et système pour surveillance et contrôle de l'accès au réseau
US6119236A (en) * 1996-10-07 2000-09-12 Shipley; Peter M. Intelligent network security device and method
WO2001017193A2 (fr) * 1999-08-30 2001-03-08 Nortel Networks Limited Protocole internet transparent du type « bump in the wire »
US20020035639A1 (en) * 2000-09-08 2002-03-21 Wei Xu Systems and methods for a packet director

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6119236A (en) * 1996-10-07 2000-09-12 Shipley; Peter M. Intelligent network security device and method
EP0986229A2 (fr) * 1998-09-09 2000-03-15 JSB Software Technology plc Procédé et système pour surveillance et contrôle de l'accès au réseau
WO2001017193A2 (fr) * 1999-08-30 2001-03-08 Nortel Networks Limited Protocole internet transparent du type « bump in the wire »
US20020035639A1 (en) * 2000-09-08 2002-03-21 Wei Xu Systems and methods for a packet director

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006092042A1 (fr) * 2005-03-02 2006-09-08 6002552 Canada Inc. Procede et protocole permettant de transmettre des commandes etendues a des dispositifs usb

Also Published As

Publication number Publication date
AU2003274228A1 (en) 2004-02-25
AU2003274228A8 (en) 2004-02-25
FR2843508A1 (fr) 2004-02-13
WO2004015953A3 (fr) 2004-04-22

Similar Documents

Publication Publication Date Title
US8261057B2 (en) System and method for establishing a virtual private network
EP1605660B1 (fr) Contrôle d'accès à un réseau d'un terminal source utilisant un tunnel en mode bloquant
EP1733539B1 (fr) Dispositif et procédé de détection et de prévention d'intrusions dans un réseau informatique
US20030051155A1 (en) State machine for accessing a stealth firewall
FR2801754A1 (fr) Methode pour assigner une double adresse ip a un poste de travail relie a un reseau de transmission de donnees ip
FR2857187A1 (fr) Procede de configuration automatique d'un routier d'acces, compatible avec le protocole dhcp, pour effectuer un traitement automatique specifique des flux ip d'un terminal client
FR2844941A1 (fr) Demande d'acces securise aux ressources d'un reseau intranet
EP1774751A1 (fr) Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns
US8015406B2 (en) Method to create an OSI network layer 3 virtual private network (VPN) using an HTTP/S tunnel
EP3533202B1 (fr) Controle dynamique et interactif d'une passerelle residentielle connectee a un reseau de communication
WO2004086719A2 (fr) Systeme de transmission de donnees client/serveur securise
EP1672849B1 (fr) Procédé d'exploitation d'un réseau informatique local relié à un réseau distant privé par un tunnel IPsec
WO2007031654A1 (fr) Procede, passerelle, systeme d'exploitation et systeme de gestion d'entree
WO2004015953A2 (fr) Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local
EP3087719B1 (fr) Procédé de ralentissement d'une communication dans un réseau
EP1704682B1 (fr) Systeme de communication entre reseaux ip prives et publics
FR2843847A1 (fr) Systeme permettant d'etablir une connexion telnet avec un dispositif eloigne depourvu de modem
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
FR2955727A1 (fr) Procede securise d'acces a un reseau et reseau ainsi protege
WO2005091565A1 (fr) Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant
WO2006037864A2 (fr) Procede de controle d'acces a un reseau d'un terminal source utilisant un tunnel en mode bloquant, et programmes d'ordinateur pour sa mise en oeuvre
FR2878346A1 (fr) Procede et systeme de mesure de l'usage d'une application

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP