FR2872983A1 - Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme - Google Patents
Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme Download PDFInfo
- Publication number
- FR2872983A1 FR2872983A1 FR0451496A FR0451496A FR2872983A1 FR 2872983 A1 FR2872983 A1 FR 2872983A1 FR 0451496 A FR0451496 A FR 0451496A FR 0451496 A FR0451496 A FR 0451496A FR 2872983 A1 FR2872983 A1 FR 2872983A1
- Authority
- FR
- France
- Prior art keywords
- community
- rules
- firewall
- filter
- network
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
-
- 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
- H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
- H04L63/0218—Distributed architectures, e.g. distributed firewalls
-
- 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]
-
- 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/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40104—Security; Encryption; Content protection
-
- 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
- H04L63/0227—Filtering policies
-
- 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
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- 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/2803—Home automation networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
L'invention concerne la protection par pare feu d'une communauté d'appareils domestique interconnectables.L'invention permet une gestion répartie et totalement décentralisée de la politique de pare-feu, implémentée au niveau de chaque appareil, cohérente et s'adaptant dynamiquement aux changements intervenant au sein du réseau domestique. Nous parlerons de pare-feu omniprésents.
Description
2872983 1
Système de pare-feu protégeant une communauté d'appareils, appareil participant au système et méthode de mise à jour des règles de pare- feu au sein du système La présente invention concerne la sécurisation d'une communauté d'appareils interconnectables et plus particulièrement la gestion de la politique de règles de pare-feu ( firewall en anglais) permettant de filtrer le trafic entre ces appareils et le réseau auquel ils sont connecté.
Un réseau local, et plus particulièrement un réseau domestique, est formé d'un ensemble de dispositifs (téléviseurs, enregistreurs numériques, ordinateurs, assistants numériques personnels, etc.) mis en réseau qui s'auto configurent et interagissent de manière transparente pour l'utilisateur afin de lui offrir des services augmentés. UPnP décrit dans "UPnPTM Device Architecture 1.0", HAVi décrit dans "HAVi Specification version 1.1" et Rendezvous décrit par E. Guttman dans Autoconfiguration for IP networking: Enabling local communication IEEE Internet Computing, May 2001, sont quelques propositions actuelles de standards de réseaux domestiques. Les appareils appartenant à un utilisateur ou une famille d'utilisateurs vont partager une même politique de sécurité. Ces appareils sont connectables entre eux via de multiples réseaux. Ces réseaux peuvent être des réseaux câblés au sein du foyer comme IEEE 1394, IEEE Ethernet ou autre. Ils peuvent aussi être des réseaux sans fils comme IEEE 802.11, Bluetooth ou autre. Les appareils peuvent aussi communiquer via Internet comme par exemple un dispositif mobile que l'utilisateur aura emporté sur son lieu de travail et qui communiquera avec le réseau du domicile via le réseau d'entreprise et Internet.
Ces communautés doivent être sécurisées si on souhaite leur large déploiement. En effet, il existe des mobiles et de véritables opportunités pour attaquer les appareils d'un utilisateur. La première étape pour sécuriser une communauté d'appareils domestiques consiste à marquer sa frontière, c'est à dire à définir quels sont les dispositifs qui appartiennent à la communauté.
2872983 2 La seconde étape pour la sécurisation de ces communautés domestiques est de définir une politique de filtre des communications entre les appareils de la communauté et le monde extérieur, voire entre les appareils de la communauté eux-même. Ce genre de filtres, appelé parefeu, est bien connu. Il existe plusieurs types de pare-feu.
En particulier, il est connu d'équiper un réseau d'entreprise d'un parefeu disposé sur le lien entre ce réseau d'entreprise et l'extérieur. En effet sur ce type de réseau, toutes les communications entre le réseau et l'extérieur passent par un ou plusieurs points de connexion bien identifiés. Dans ce cas le pare-feu est administré par du personnel compétent à même de définir la politique de sécurité et de l'implémenter.
II est également connu d'équiper un ordinateur personnel directement relié à Internet de ce que l'on appelle communément un pare-feu personnel. Ce pare-feu est un filtre logiciel sur l'ordinateur filtrant le trafic réseau entre l'ordinateur et le monde extérieur. Ce filtrage s'opère en fonction d'une politique définie par l'utilisateur. Pour ce faire des outils existent lui permettant d'exprimer cette politique d'une façon simple et de la traduire sous forme de règles de filtres de paquets en fonction des protocoles utilisés, des services utilisés ou du sens de la communication. Malgré ces outils destinés à faciliter la tâche de l'utilisateur, celui-ci est tout de même en charge de la gestion de son pare-feu et de l'évolution de la politique de sécurité sur son ordinateur.
Pour la gestion de la politique de pare-feu dans un réseaux possédant plusieurs points d'accès sur l'extérieur a été développée la notion de pare-feu distribué. Dans ce type de pare-feu, la politique de sécurité est définie en un point du réseau servant de serveur de politique et appliquée en de multiples points, typiquement sur tous les points d'accès au réseau. De cette façon on assure la cohérence de la politique de pare- feu sur tout le réseau en centralisant en un seul point les règles de politique et leur mise à jour.
Les caractéristiques des communautés d'appareils domestiques modernes posent un certain nombre de problèmes lorsque l'on essaye de 2872983 3 les protéger par un pare-feu suivant l'une des techniques évoquées plus haut. L'utilisation de média hertziens, par nature partagés, la communication entre dispositifs au travers de l'Internet, la découverte et l'échange automatique de services entre dispositifs mis en présence sont autant de facteurs qui rendent floue la frontière physique des réseaux domestiques ainsi que la localisation des points d'accès entre les appareils du réseau domestique et l'extérieur. Dans une telle communauté, chaque appareil est susceptible de communiquer avec des appareils extérieurs au réseau sans que cette communication passe obligatoirement par un point d'accès identifié.
D'autre part, les appareils de la communauté domestique sont susceptibles de tomber en panne, d'être éteints ou emportés par l'utilisateur hors d'atteinte des moyens de communication du reste de la communauté. Il est donc clair que la politique de sécurité doit s'appliquer d'une part sur les appareils emportés hors du domicile comme sur ceux restés au sein du domicile. II n'est donc pas possible de tabler sur la présence dans le réseau d'un appareil jouant un rôle privilégié pour assurer la sécurité de la communauté. Il faut de plus que la politique prennent en compte l'évolution de la communauté, l'ajout ou le retrait de nouveaux appareils.
L'invention permet une gestion répartie et totalement décentralisée de la politique de pare-feu, implémentée au niveau de chaque appareil, cohérente et s'adaptant dynamiquement aux changements intervenant au sein du réseau domestique. Nous parlerons de pare-feu omniprésents.
L'invention concerne un système de pare-feu permettant de sécuriser une communauté d'appareils interconnectables partageant un ensemble d'au moins une règle de sécurité globale commune, chaque appareil de la communauté possédant des moyens de stocker une politique locale de sécurité constituée au moins de règles globales de sécurité, d'une liste des membres de la communauté ainsi que de leur état de connexion et d'une liste de services offerts localement, une pluralité d'appareil de la communauté comprenant un filtre de messages à destination et en provenance du réseau auquel ii est connecté où, le système ne comprenant aucun moyen centralisé, il possède sur chaque appareil de la communauté 2872983 4 des moyens locaux de calcul des règles utilisées par le filtre en fonction de la politique locale de sécurité.
Selon un mode particulier de réalisation de l'invention le système possède sur chaque appareil de la communauté des moyens de mise à jour de la politique locale de sécurité et de déclencher un nouveau calcul des règles utilisées par le filtre.
Selon un mode particulier de réalisation de l'invention le système possède des moyens de déclenchement d'un nouveau calcul des règles utilisées par le filtre en réaction à des changements intervenant sur le réseau.
Selon un mode particulier de réalisation de l'invention les changements pris en compte pour déclencher un nouveau calcul des règles utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé sur un appareil de la communauté.
Selon un mode particulier de réalisation de l'invention les changements pris en compte pour déclencher un nouveau calcul des règles de pare-feu utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé localement sur l'appareil.
Selon un mode particulier de réalisation de l'invention le système possède sur chaque appareil de la communauté des moyens de déterminer la liste des appareils extérieurs à la communauté possédant des accès privilégiés à au moins un service offert par un appareil de la communauté, cette liste étant intégrée à la politique locale de sécurité.
L'invention concerne aussi un appareil comportant des moyens pour appartenir à une communauté d'appareils interconnectables partageant un ensemble d'au moins une règle de sécurité globale commune, possédant des moyens de stockage d'une politique locale de sécurité constituée au 2872983 5 moins de règles globales de sécurité, d'une liste des membres de la communauté ainsi que de leur état de connexion et d'une liste de services offerts localement, ledit appareil possédant un pare-feu comprenant un filtre des messages à destination et en provenance du réseau auquel il est connecté tel qu'il possède des moyens locaux de calcul des règles de pare-feu utilisées par le filtre en fonction de la politique locale de sécurité, ne faisant appel à aucun moyens centralisés.
Selon un mode particulier de réalisation de l'invention l'appareil possède des moyens de mise à jour de la politique locale de sécurité et de déclencher automatiquement un nouveau calcul des règles utilisées par le filtre.
Selon un mode particulier de réalisation de l'invention l'appareil possède des moyens de déclenchement d'un nouveau calcul des règles utilisées par le filtre se fait en réaction à des changements intervenant sur le réseau.
Selon un mode particulier de réalisation de l'invention les changements pris en comptes pour déclencher un nouveau calcul des règles utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé sur un appareil de la communauté.
Selon un mode particulier de réalisation de l'invention les changements pris en comptes pour déclencher un nouveau calcul des règles de pare-feu utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé localement sur l'appareil.
Selon un mode particulier de réalisation de l'invention l'appareil possède des moyens de déterminer la liste des appareils extérieurs à la communauté possédant des accès privilégiés à au moins un service offert par un appareil de la communauté, cette liste étant intégrée à la politique locale de sécurité.
2872983 6 L'invention concerne également une méthode de mise à jour de règles utilisées par un pare-feu constitué d'un filtre des messages à destination et en provenance du réseau auquel est connecté l'appareil implémentant la méthode, l'appareil faisant partie d'une communauté d'appareils interconnectables partageant un ensemble d'au moins une règle de sécurité globale commune, l'appareil possédant des moyens de stocker une politique locale de sécurité constituée au moins de règles globales de sécurité, d'une liste des membres de la communauté ainsi que de leur état de connexion et d'une liste de services offerts localement, lesdites règles étant calculées en fonction de la politique locale de sécurité, comportant au moins les étapes suivantes: - la détection de l'ajout, du retrait et du bannissement d'un appareil de la communauté ; - la détection des changements d'adresse réseau d'un appareil de la communauté ; - le déclenchement d'un nouveau calcul des règles en réponse au changement de la politique locale de sécurité.
Selon un mode particulier de l'invention la méthode possède en outre une étape de détection des changements de statut des services hébergés par l'appareil.
Selon un mode particulier de l'invention la méthode possède en 25 outre une étape de détection des changements de statut des services hébergés par un appareil de la communauté Selon un mode particulier de l'invention le déclenchement d'un nouveau calcul des règles de pare-feu est lié à la détection de l'ajout, du retrait et du bannissement d'un appareil de la communauté, à la détection du changement d'adresse IP d'un appareil de la communauté et du changement de statut d'un service.
L'invention sera mieux comprise, et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels: 2872983 7 La figure 1 représente un schéma d'ensemble d'une communauté d'appareils domestiques protégée par l'invention.
La figure 2 représente un exemple de réalisation d'une architecture d'un pare-feu omniprésent.
La figure 3 représente un exemple de réalisation d'une architecture générale d'un appareil domestique embarquant un pare-feu omniprésent.
Un exemple de réalisation d'un pare-feu omniprésent et de la gestion de la politique de sécurité utilisant un tel pare-feu va maintenant être décrite. L'exemple de réalisation est donné dans le cadre d'une communauté d'appareils domestiques communiquant via le protocole IP ( Internet Protocol en anglais). On peut trouver la spécification du protocole IP dans les RFC, requête pour commentaire ( request for comments en anglais), maintenu par l'IETF, groupe de travail d'ingénierie Internet ( Internet Engineering Task Force en anglais) sous le numéro 791. Mais l'homme du métier comprendra que l'on peut appliquer l'invention à tout type de réseau de communication, quel que soit le protocole utilisé, par exemple IEEE 1394 ou autre.
Les contraintes auxquelles on doit faire face dans communauté d'appareils domestiques sont les suivantes.
Tout d'abord, les appareils sont susceptibles d'être allumés ou éteints à tout moment. Il faut donc gérer l'arrivée et le départ de ces appareils du réseau.
Les appareils de la communauté peuvent être physiquement connectés à des appareils n'appartenant pas à la communauté. En particulier pour les communications sans fils, les appareils connectés au réseau physique ne font pas forcément partie de la communauté. De même, tout appareil est susceptible de devenir un point d'accès entre la communauté et le monde extérieur. Les frontières physiques du réseau interconnectant la communauté ne sont donc pas clairement définies.
2872983 8 Tous les appareils appartenant à la communauté ne sont pas forcément à même de communiquer ensemble à tout moment. Par exemple un utilisateur, hors de chez lui, peut faire communiquer un téléphone portable et un assistant numérique qui vont constituer entre eux un sous réseau déconnecté des appareils restés au domicile. Ces appareils, déconnectés du reste du réseau domestique doivent pouvoir appliquer la politique de sécurité définie pour la communauté. La communauté est donc susceptible d'être séparé en un nombre arbitraire de partitions ne pouvant temporairement pas communiquer ensemble. De même, l'environnement et les propriétés d'un appareil peuvent changer dans le temps. Ainsi un appareil peut par exemple changer d'adresse IP entre deux connexions successives au réseau.
D'autre part, il n'est pas possible de compter sur le concours d'un administrateur compétent pour administrer la communauté domestique à la différence de ce qui se passe sur un réseau d'entreprise par exemple. En effet l'utilisateur n'a généralement pas les compétences ou le temps de se plonger dans les problèmes de paramétrage d'un pare-feu. Mais dans un même temps il est la seule autorité sur la communauté. Il est donc nécessaire de lui fournir un moyen simple d'exprimer la politique de sécurité et de la traduire de manière transparente en règles de pare-feu.
La figure 1 illustre un exemple de communauté domestique. La communauté domestique est constituée d'une part des appareils de l'espace référencé 1.1 et situés dans le domicile et des appareils situés dans l'espace 1.3 situés hors du domicile. On suppose ici que ces deux espaces ne peuvent pas communiquer entre eux. L'espace du domicile 1.1 contient d'une part un réseau filaire reliant une télévision 1.5, un magnétoscope numérique 1. 6, un décodeur numérique 1.7, tandis qu'un modem ADSL 1.8 donne accès à Internet 1.4 et une borne sans fil 1.9, fonctionnant par exemple suivant l'un des protocoles de la famille 802.11, permet la connexion d'une chaîne HIFI 1.10 et d'un ordinateur 1.11. La famille de norme 802.11 définit une norme de communication sur un réseau sans fil normalisé dans le document ANSIIIEEE std 802.11-1999 (reaff 2003).
L'ordinateur du voisin 1.14, disposant de capacité sans fil, peut se connecter physiquement au réseau sans fil 1.2 bien que ne faisant pas partie de la communauté domestique. L'utilisateur, hors de son domicile, peut connecter 2872983 9 ensemble par exemple un organiseur numérique 1. 13 et un téléphone mobile 1.12 par une connexion sans fil selon, par exemple le protocole Bluetooth, pour former une partition 1.3 de la communauté. Cette partition étant appelée à se retrouver connectée au reste de la communauté lors du retour de l'utilisateur à son domicile. Le dispositif de pare-feu omniprésent, référencé 1.15, est décentralisé sur chaque appareil et matérialisé par le rectangle gris apparaissant sur les appareils de la communauté.
Pour assurer la sécurité des communautés d'appareils domestiques il est nécessaire de définir une politique de sécurité et les services de sécurité qui vont permettre de mettre en oeuvre cette politique. La politique de sécurité d'une communauté domestique est très proche de celle que l'on peut trouver dans un réseau d'entreprise classique. Elle se compose de deux parties.
Une première partie pose le problème de l'appartenance à la communauté. En effet le premier problème à résoudre est celui de la définition de la frontière de la communauté. Une communauté domestique va constituer un domaine d'application d'une politique de sécurité uniforme.
Tous les appareils d'une même communauté vont partager une politique de sécurité commune et vont partager un niveau de confiance mutuel élevé. On considère généralement que les appareils d'une même communauté peuvent communiquer librement entre eux. Ce problème est résolu, par exemple, par la technique décrite dans le document suivant: Gestion sécurisée de groupes de dispositifs dans un réseau domestique par Nicolas Prigent et Jean-Pierre Andreaux publié dans les actes du second symposium de sécurité des technologies de l'information et des communication (SSTIC 2004). Dans ce document on explique comment l'utilisateur peut définir facilement les appareils appartenant à sa communauté domestique à l'aide d'une identité prouvable cryptographique de chaque appareil. L'utilisateur est à même de gérer l'ajout et le retrait des appareils de la communauté.
La seconde partie de la politique de sécurité de la communauté se propose de gérer les communications entre les appareils de la communauté et le monde extérieur. Il s'agit donc des communications entre les appareils de la communauté et les appareils n'appartenant pas à la 2872983 10 communauté mais pouvant communiquer avec les appareils de la communauté. On retrouve ici des appareils accessibles via Internet ou des appareils apportés par des invités dans le domicile et temporairement connectés au réseau domestique de l'utilisateur. Comme les appareils à l'intérieur de la communauté domestique sont censés se conformer à la politique de sécurité, il est généralement admis que les communications initiées par des appareils faisant partie de la communauté sont libres de sortir de la communauté. Au contraire, les communications initiées par des appareils à l'extérieur de la communauté doivent être contrôlées et leur conformité à la politique de sécurité être garantie. En pratique, l'accès aux services offerts par les appareils appartenant à la communauté doit avoir été explicitement autorisé par l'utilisateur pour que les requêtes à destination de ces services soient acceptées à la frontière de la communauté.
Plus précisément, un service sur un appareil de la communauté pourra être déclaré comme public (c'est à dire que tout appareil extérieur peut y accéder), restreint (c'est à dire que l'accès à ce service par un appareil extérieur est soumis à une condition) ou privé (l'accès par un appareil extérieur est interdit). Il est alors nécessaire de vérifier la conformité des communications initiées par un appareil extérieur à la communauté à cette politique.
Il est clair que la politique de sécurité décrite est un exemple et que les règles ainsi définies peuvent être modifiées sans sortir du cadre de 25 l'exemple de réalisation.
Un exemple de mise en oeuvre de cette politique de sécurité va maintenant être décrit. Pour ce faire, nous allons définir la notion de pare-feu omniprésent. Du fait des contraintes déjà décrites, il est impossible de faire jouer un rôle particulier à un appareil de la communauté, la politique de sécurité devant être assurée sur tous les appareils sans présupposer la présence et l'accessibilité d'un autre appareil de la communauté sur le réseau domestique. En conséquence un service de parefeu, dit omniprésent, va être défini au niveau de chaque appareil de la communauté.
La figure 2 illustre l'architecture de ce service. Elle se compose d'une base de connaissance locale, référencée 2.1, qui contient les 2872983 11 informations relatives à la politique ainsi que les informations sur l'environnement courant de l'appareil. Ces informations sont utilisées par le coeur du pare-feu omniprésent, référencé 2.5, pour générer les règles de pare-feu. Cette base de connaissance locale comprend elle-même le gestionnaire de politique locale (GPL), référencé 2.2, dont la tâche est d'acquérir, de mémoriser et de gérer l'information concernant la politique de sécurité et le module d'adaptation à l'environnement (MAE), référencé 2.3 dont le rôle est d'acquérir, mémoriser et gérer l'information sur l'environnement de l'appareil. Le module de cryptographie, référencé 2.4, s'occupe des opérations d'authentification entre l'appareil local et les autres appareils, ainsi que des clés éventuellement utilisées pour établir des canaux de communication sécurisés. Le coeur de pare-feu omniprésent, référencé 2.5, s'occupe quant à lui de générer les règles utilisées par le filtre de message, référencé 2.6, sur la base des informations contenues dans la base de connaissance locale et en utilisant éventuellement les clés obtenues du module de cryptographie. Le filtre de messages, référencé 2.6, applique les règles ainsi obtenues aux messages issus de, et dirigés vers, la couche de protocole réseau, en l'occurrence, la couche IP. Les applications, référencées 2.8 et 2.9, vont accéder à la couche de protocole réseau de manière transparente et vont recevoir les messages après application du filtre.
Le gestionnaire de politique local est en charge de l'acquisition, de la mémorisation et de la gestion de la politique de sécurité. Il gère les informations pertinentes concernant la politique globale générique, qui est la même pour tous les appareils de la communauté. Un exemple de cette politique est formé des deux règles suivantes: - les appareils appartenant à la communauté domestique sont libres de communiquer entre eux, de manière sécurisée ou non.
- L'accès par des appareils extérieurs à la communauté domestique aux services offerts par les appareils de la communauté est contrôlé.
En utilisant cette politique générale ainsi que les informations spécifiques qu'il possède sur la communauté domestique, en particulier la liste des appareils de la communauté et leur état de connexion, ainsi que la liste des services offerts, localement ou par la communauté, et leur statut 2872983 12 public, restreint ou privé, le gestionnaire est capable de construire sa propre vue locale de la politique de sécurité.
En particulier, le gestionnaire de politique locale possède une première catégorie d'informations sur les frontières de la communauté. II contient principalement des informations sur les appareils appartenant à la communauté domestique et sur la méthode permettant de les identifier et de les authentifier. Chaque dispositif de la communauté domestique dispose d'une identité prouvable, qui lui permet d'être identifié et de s'authentifier auprès des autres dispositifs de son réseau. Nous appelons "identité prouvable" une identité qu'il est facile de vérifier, mais très difficile d'usurper, et qui permet la mise en place sécurisée de matériel cryptographique. Par exemple, la clé publique d'une paire de clés publiquelprivée peut être utilisée comme identité prouvable: un dispositif prétendant être identifié par sa clé publique peut signer un challenge en utilisant sa clé privée, et est le seul à pouvoir déchiffrer un message qui a été chiffré avec sa clé publique. De plus, en se servant de leurs identités prouvables respectives, deux dispositifs peuvent créer un canal de communication sécurisé, leur permettant notamment de mettre éventuellement en place des clés de session symétriques en utilisant un protocole d'accord sur les clés par exemple. Ces clés de session point à point peuvent servir aux authentifications subséquentes et pour sécuriser les communications (authenticité et confidentialité) entre les deux dispositifs.
Il existe de nombreuses méthodes connues pour assurer de manière sûre l'appartenance d'un appareil à une communauté dont celle déjà citée Gestion sécurisée de groupes de dispositifs dans un réseau domestique .
Le gestionnaire de politique locale possède une seconde catégorie d'informations sur les communications autorisées à franchir la frontière de la communauté domestique ou pas. On trouve, tout d'abord, dans cette catégorie la liste des services publics offerts par le dispositif, comme par exemple les serveurs HTTP publics. On y trouve également la liste des services restreints. Ces services sont donc accessibles uniquement sous certaines conditions. Le gestionnaire possède pour chacun de ces services des informations sur les conditions qui doivent être remplies pour 2872983 13 l'accès à ce service. Un exemple de telles informations peut être un nom d'utilisateur et un mot de passe avec la méthode d'authentification utilisée, la connaissance d'une information cryptographique particulière, une liste d'appareils explicitement autorisés, un domaine dont les appareils sont autorisés ou toute autre condition. Il existe plusieurs sources d'informations pour le gestionnaire de politique locale. II peut s'agir de l'utilisateur où d'une source légitime de politique de sécurité comme un autre appareil de la communauté domestique.
Certaines modifications intervenant dans la politique locale sont partagées entre les différents appareils de la communauté. Ces modifications peuvent être de plusieurs types. D'une part, l'utilisateur peut ajouter, retirer ou bannir un appareil de la communauté. L'ajout pourra se faire depuis un appareil de la communauté connecté au nouvel appareil sur lequel l'utilisateur indiquera que le nouvel appareil doit être considéré comme faisant partie de la communauté. Le retrait d'un appareil pourra se faire sur l'appareil que l'utilisateur souhaite retirer de la communauté ou sur un autre appareil y appartenant. Le bannissementconcerne la procédure par laquelle un utilisateur va indiquer à la communauté qu'un appareil auquel il n'a plus accès doit cesser d'être considéré comme un membre de la communauté. Les mécanismes permettant d'implémenter ceci sont décrits dans le document déjà cité Gestion sécurisée de groupes de dispositifs dans un réseau domestique . Ces modifications vont donc être prises en compte par tous les appareils de la communauté dès qu'il vont être en mesure de communiquer.
Un autre type de changement de politique est le changement de statut d'un service sur un appareil de la communauté. Ici deux solutions peuvent être envisagées. La première consiste à dire que ne fait partie de la politique locale d'un appareil que la liste des services hébergés sur cet appareil. Dans cette optique il n'y pas de nécessité à diffuser sur les autres appareils un changement d'état d'un service se produisant sur un appareil. La conséquence de cette solution est que le blocage d'une requête non autorisée pour un service hébergé sur un appareil donné ne pourra se faire que sur ce même appareil. Les autres appareils du réseau n'ayant pas connaissance du statut des services vont donc relayer la requête sans pouvoir en vérifier la conformité à la politique de sécurité. La seconde 2872983 14 solution consiste à diffuser les informations d'état des services sur tous les appareils de la communauté. Dans ce cas, tout changement dans l'état d'un service sur un appareil sera automatiquement envoyé à tous les appareils connectés de la communauté. Une mise à jour aura lieu sur les appareils non connectés au moment du changement lors de leur prochaine connexion. Cette solution permet de bloquer une requête non conforme dès son arrivée sur le premier appareil de la communauté. Le changement de l'état d'un service par l'utilisateur peut n'être autorisé que sur l'appareil hébergeant le service. Dans ce cas, il ne peut pas y avoir de conflit de politique lors de la connexion de deux partitions de la communauté, l'état défini dans la partition hébergeant le service étant toujours considéré comme l'état correct à diffuser sur les appareils de l'autre partition. Dans le cas où l'on autorise l'utilisateur à changer l'état d'un service depuis n'importe quel appareil de la communauté il peut arriver que l'on connecte deux partitions de la communauté ayant un état différent pour un service donné. Ce genre de conflit peut être réglé, soit en tenant compte de l'horaire du dernier changement d'état, soit en sollicitant l'arbitrage de l'utilisateur pour confirmer le choix entre les deux états.
Le module d'adaptation à l'environnement est, lui, responsable de la gestion de l'association entre l'identité des appareils et l'adresse réseau, en l'occurrence IP, qu'ils possèdent à un moment donné. En effet cette information est indispensable lorsque l'on veut envoyer un message à un appareil que l'on ne connaît, sinon, que sous son identité prouvable. Ce module garde également l'association entre les adresses et les identités des appareils privilégiés ayant accès à la communauté. C'est-àdire des appareils qui bien que ne faisant pas partie de la communauté vont avoir un accès privilégié à certains services de la communauté. Une des multiples solutions pour que ce module puisse acquérir et maintenir à jour les associations entre les identités des appareils et leur adresse sur le réseau consiste, pour chaque appareil à diffuser périodiquement son adresse et son identité sur le réseau. Lorsque le module d'adaptation à l'environnement reçoit un message de ce type, il peut alors vérifier que cette identité est légitime pour lutter contre une usurpation toujours possible. C'est également ce module qui est en charge de diffuser les messages d'annonces 2872983 15 périodiques de façon à ce que les MAE des autres appareils puissent également se mettre à jour.
Le module de données cryptographiques va, quant à lui, avoir au moins deux fonctions principales. D'une part il va être en charge de la gestion de l'identité prouvable de l'appareil. D'autre part, il va également servir à construire des canaux de communications sécurisés. En effet, comme on ne peut empêcher un appareil extérieur et potentiellement mal intentionné, d'accéder physiquement au réseau, il peut être utile de sécuriser les communications entre les appareils de la communauté. Il est donc possible de créer un réseau privé virtuel regroupant les appareils de la communauté domestique. Du fait des propriétés de connexion erratiques au sein du réseau domestique l'établissement d'un canal de communication sécurisé ne doit pas requérir la présence de plus de deux appareils dans la communauté. Basé sur la connaissance locale qu'il a de la communauté, chaque appareil est à même d'assurer la sécurité point à point de ses communications avec les autres appareils. Pour des raisons de performance, l'utilisation de cryptographie symétrique est privilégiée, mais il est évident que l'on peut également utiliser de la cryptographie asymétrique.
L'utilisation de cryptographie symétrique nécessite la mise en place symétrique de clés point à point dans les appareils. Pour des raisons de facilité d'utilisation, il n'est pas possible de demander à l'utilisateur de définir et d'entrer ces clés symétriques dans les appareils. De plus ce serait contre productif au niveau de la sécurité : l'utilisateur risque en effet de choisir des clés faibles. La mise en place des clés peut être faite, par exemple, en utilisant le protocole STS ( Station To Station en anglais) défini dans le document Authentication and authenticated key exchanges. Design Codes and Cryptograhpy, 2:107-125, 1992, par W. Diffie, P. van Oorschot, and M. Wiener. Les clés sont donc mises en place de façon non conditionnelle et sans intervention de l'utilisateur qui n'est pas en connaissance des clés utilisées. Ceci permet d'obtenir un bon niveau de sécurité ainsi qu'une bonne ergonomie du système. Un autre avantage de ce système de clés point à point est sa résistance à la corruption d'un appareil. En effet, si un attaquant se trouvait prendre le contrôle d'un appareil, les communications entre les autres appareils ne sont pas compromises du fait que les clés sont strictement point à point entre chaque paire d'appareils de la communauté. Le système fonctionne, de plus, dès la 2872983 16 présence de deux appareils dans la communauté domestique. La taille limitée d'une communauté domestique et la gestion totalement distribuée des clés fait que le nombre de clés à gérer par appareil croît linéairement avec la taille de la communauté et reste raisonnable.
Le coeur du pare-feu est en charge de la génération des règles de parefeu qui vont être utilisées par le filtre. Cette génération se fait à partir des règles de politique de la façon suivante.
Dans un premier temps, le coeur du pare-feu va établir les règles autorisant les communications nécessaires au fonctionnement du pare-feu omniprésent. II s'agit des messages échangés entre les MAE pour annoncer et détecter les appareils avec lesquels on peut communiquer, ainsi que des messages échangés par les modules de cryptographie pour permettre l'authentification et l'échange de clés point à point dans le cas où l'on met en place des canaux de communication sécurisés. Ces messages entre les modules de cryptographie, bien que non indispensable au fonctionnement d'un pare-feu omniprésent, sont nécessaires à l'établissement d'un niveau élevé de sécurité au sein de la communauté domestique. Il faut également autoriser les messages entre les bases de connaissance locales, ainsi, éventuellement, que ceux utiles à l'obtention d'une adresse réseau comme une requête DHCP ou autre. Toutes ces communications sont autorisées sans être sécurisées (chiffrés ou authentifiés) au niveau du filtre.
Dans un second temps, le coeur du pare-feu va établir les règles permettant la communication entre appareils de la communauté. Tout message en provenance d'une adresse identifiée par le module d'adaptation à l'environnement comme appartenant à la communauté va être éventuellement déchiffré et son authenticité va être éventuellement vérifiée, grâce à l'identité prouvable de la source connue, ou la ou les clés symétriques mises en place par le module cryptographique. Si l'authentification est mise en place, le message sera accepté si l'authentification est correcte et refusé sinon. Si aucune authentification n'est mise en place, le message est accepté.
De même, pour tout message à destination d'un appareil de la communauté, on va éventuellement procéder à son chiffrement et à son 2872983 17 authentification en se basant sur l'identité prouvable de la destination, ou sur la ou les clés symétriques mises en place par le module cryptographique, puis à son envoi.
Le coeur du pare-feu va aussi définir les règles régissant les communications relatives aux services privilégiés. Les règles doivent mettre en oeuvre les vérifications des conditions d'accès. Par exemple, si la politique indique qu'un appareil possédant telle identité prouvable peut accéder à un service privilégié donné, on peut ici utiliser le MAE pour connaître l'adresse IP correspondant à cette identité prouvable pour générer la règle autorisant les requêtes à destination de ce service et en provenance de cette adresse. II est également possible d'utiliser les propriétés du groupe de protocoles IP sécurisé IPsec pour filtrer les requêtes à un service chiffrées à l'aide d'un secret partagé. On peut trouver la spécification du groupe de protocoles IPsec dans les RFC, requête pour commentaire ( request for comments en anglais), maintenu par l'IETF, groupe de travail d'ingénierie Internet ( Internet Engineering Task Force en anglais) sous le numéro 2401, et la description d'une partie des protocoles qui le composent AH, ESP et IKE respectivement sous les numéros 2402, 2406 et 2409. Par contre, les services dont l'accès est sécurisé par une méthode d'authentification de plus haut niveau seront déclarés comme services publics et dans ce cas l'authentification se fera au niveau du service. On peut citer dans ce cas l'accès à un serveur HTTP accessible par un nom d'utilisateur et un mot de passe. Dans ce cas, les vérifications ne sont pas possibles au niveau de la couche de protocole réseau.
Le coeur du pare-feu va de même générer les règles autorisant les communications relatives aux services publics et ce quel que soit la source des messages.
Enfin, le coeur du pare-feu va générer les règles interdisant toute connexion entrante autre que celles explicitement autorisées par une des règles ci-dessus et autorisant toute connexion sortante. En effet, par défaut, tous les services sont considérés comme privés.
Ces règles sont régénérées à chaque modification de la politique de sécurité, ou lorsque l'environnement de l'appareil est modifié. Ces 2872983 18 modifications peuvent venir de la modification de la topologie, c'est-à-dire de l'ajout ou du retrait d'un ou de plusieurs appareils du réseau. On peut ici remarquer que le retrait d'un appareil du réseau, c'est à dire la perte de connectivité d'un appareil qui ne quitte pas la communauté, ne nécessite pas une nouvelle génération des règles de parefeu. Pas plus que qu'un retour de connectivité tant que son adresse IP n'est pas modifiée. Donc seul le changement d'adresse IP d'un appareil de la communauté ou d'un appareil autorisé à accéder à un service privilégié, le retrait, l'ajout et le bannissement d'un appareil de la communauté sont des événements nécessitant une nouvelle génération des règles de pare-feu. Cette modification peut également venir de la modification de la politique concernant un service disponible au sein de la communauté. Comme nous l'avons vu, cette modification peut être gérée uniquement localement sur l'appareil hébergeant le service qui devra seul générer un nouvel ensemble de règle ou cette modification peut être diffusée au sein de la communauté et nécessiter alors une nouvelle génération sur tous les appareils de la communauté. Comme cette génération est totalement automatisée, l'appareil dispose à tout instant d'un ensemble de règles de pare-feu cohérent avec la politique de sécurité dont il a connaissance.
L'utilisateur est la seule autorité au sein de la communauté. II est donc le seul qui puisse définir le statut, public, privé ou restreint, des services offerts par les appareils qu'il possède. Pour ce faire, il va devoir s'authentifier sur l'appareil hébergeant le service dont il veut modifier le statut. La façon de s'authentifier sur l'appareil va dépendre de l'appareil et n'est pas nécessairement uniforme au sein de la communauté. II peut s'agir d'un code à entrer sur un téléphone mobile, d'un mot de passe sur une télévision ou autre. Une fois authentifié comme autorité sur l'appareil, l'utilisateur se voit présenter une liste des services offerts par l'appareil et peut en modifier le statut. Pour les services restreints, il peut également préciser la condition d'accès comme le secret partagé à utiliser par exemple.
La figure 3 représente un exemple d'architecture générale d'un appareil, référencé 3.1, prenant part à un dispositif de pare-feu. Un tel appareil comporte une interface réseau, référencée 3.6, destinée à connecter l'appareil au réseau référencé 3.7. Il comporte également une mémoire permanente, référencée 3.5, destinée à stocker les programmes 2872983 19 nécessaires à l'exécution du pare-feu selon l'architecture de la figure 2. Ces programmes seront chargés dans la mémoire vive, référencée 3.3, pour l'exécution par le processeur central référencé 3.2. Tous ces éléments seront reliés entre eux par un bus de communication référencé 3.4. II est évident pour l'homme du métier, que cette architecture peut varier dans l'agencement de ces moyens et n'est qu'un exemple d'architecture d'un appareil à même d'implémenter un pare-feu omniprésent.
De cette façon, nous avons défini un pare-feu omniprésent, fonctionnant sur chaque appareil d'une communauté d'appareils domestiques. Ce pare-feu va mettre en oeuvre une politique de sécurité cohérente et uniforme au sein de toute la communauté et la protéger en filtrant les communications. Ce pare-feu est totalement distribué sur chaque appareil et aucun appareil ne joue de rôle particulier dans son fonctionnement. Cette politique évolue dynamiquement et s'adapte automatiquement aux évolutions de la connectivité au sein de la communauté. L'utilisateur peut modifier cette politique facilement sans devoir connaître le détail de l'implémentation du pare-feu. II apparaîtra à l'homme du métier que l'on peut implémenter l'invention dans le cadre de réseau répondant à divers protocoles de communication y compris non basés sur IP et que l'on ne sort pas du cadre de l'invention en modifiant les règles de la politique de sécurité appliquées ou en modifiant le découpage fonctionnel de l'architecture présentée pour le pare-feu omniprésent.
Claims (15)
1. Système de pare-feu permettant de sécuriser une communauté d'appareils interconnectables partageant un ensemble d'au moins une règle de sécurité globale commune, chaque appareil de la communauté possédant des moyens de stocker une politique locale de sécurité constituée au moins de règles globales de sécurité, d'une liste des membres de la communauté ainsi que de leur état de connexion et d'une liste de services offerts localement, une pluralité d'appareil de la communauté comprenant un filtre de messages à destination et en provenance du réseau auquel il est connecté caractérisé en ce que, le système ne comprenant aucun moyen centralisé, il possède sur chaque appareil de la communauté des moyens locaux de calcul des règles utilisées par le filtre en fonction de la politique locale de sécurité.
2. Système selon la revendication 1 qui possède sur chaque appareil de la communauté des moyens de mise à jour de la politique locale de sécurité et de déclencher un nouveau calcul des règles utilisées par le filtre.
3. Système selon la revendication 2 possédant des moyens de déclenchement d'un nouveau calcul des règles utilisées par le filtre en réaction à des changements intervenant sur le réseau.
4. Système selon la revendication 3 où les changements pris en compte pour déclencher un nouveau calcul des règles utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé sur un appareil de la communauté.
5. Système selon la revendication 3 où les changements pris en compte pour déclencher un nouveau calcul des règles de pare-feu utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement 2872983 21 d'un appareil de la communauté et le changement de statut d'un service hébergé localement sur l'appareil.
6. Système selon la revendication 1 qui possède sur chaque appareil de la communauté des moyens de déterminer la liste des appareils extérieurs à la communauté possédant des accès privilégiés à au moins un service offert par un appareil de la communauté, cette liste étant intégrée à la politique locale de sécurité.
7. Appareil comportant des moyens pour appartenir à une communauté d'appareils interconnectables partageant un ensemble d'au moins une règle de sécurité globale commune, possédant des moyens de stockage d'une politique locale de sécurité constituée au moins de règles globales de sécurité, d'une liste des membres de la communauté ainsi que de leur état de connexion et d'une liste de services offerts localement, ledit appareil possédant un pare-feu comprenant un filtre des messages à destination et en provenance du réseau auquel il est connecté caractérisé en ce qu'il possède des moyens locaux de calcul des règles de pare-feu utilisées par le filtre en fonction de la politique locale de 20 sécurité, ne faisant appel à aucun moyens centralisés.
8. Appareil selon la revendication 7 qui possède des moyens de mise à jour de la politique locale de sécurité et de déclencher automatiquement un nouveau calcul des règles utilisées par le filtre.
9. Appareil selon la revendication 8 qui possède des moyens de déclenchement d'un nouveau calcul des règles utilisées par le filtre se fait en réaction à des changements intervenant sur le réseau.
10. Appareil selon la revendication 9 où les changements pris en comptes pour déclencher un nouveau calcul des règles utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé sur un appareil de la communauté.
2872983 22
11. Appareil selon la revendication 9 où les changements pris en comptes pour déclencher un nouveau calcul des règles de pare-feu utilisées par le filtre sont au moins l'un parmi les suivant: le changement d'adresse réseau d'un appareil de la communauté, l'ajout, le retrait ou le bannissement d'un appareil de la communauté et le changement de statut d'un service hébergé localement sur l'appareil.
12. Appareil selon la revendication 7 qui possède des moyens de déterminer la liste des appareils extérieurs à la communauté possédant des accès privilégiés à au moins un service offert par un appareil de la communauté, cette liste étant intégrée à la politique locale de sécurité.
13. Méthode de mise à jour de règles utilisées par un pare-feu constitué d'un filtre des messages à destination et en provenance du réseau auquel est connecté l'appareil implémentant la méthode, l'appareil faisant partie d'une communauté d'appareils interconnectables partageant un ensemble d'au moins une règle de sécurité globale commune, l'appareil possédant des moyens de stocker une politique locale de sécurité constituée au moins de règles globales de sécurité, d'une liste des membres de la communauté ainsi que de leur état de connexion et d'une liste de services offerts localement, lesdites règles étant calculées en fonction de la politique locale de sécurité, comportant au moins les étapes suivantes: - la détection de l'ajout, du retrait et du bannissement d'un appareil de la communauté ; - la détection des changements d'adresse réseau d'un appareil de la communauté ; - le déclenchement d'un nouveau calcul des règles en réponse au changement de la politique locale de sécurité.
14. Méthode selon la revendication 13 possédant en outre une étape de détection des changements de statut des services hébergés par l'appareil.
15. Méthode selon la revendication 13 possédant en outre une 35 étape de détection des changements de statut des services hébergés par un appareil de la communauté 2872983 23 16 Méthode selon la revendication 14 ou 15 où le déclenchement d'un nouveau calcul des règles de pare-feu est lié à la détection de l'ajout, du retrait et du bannissement d'un appareil de la communauté, à la détection du changement d'adresse IP d'un appareil de la communauté et du changement de statut d'un service.
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0451496A FR2872983A1 (fr) | 2004-07-09 | 2004-07-09 | Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme |
| DE602005026083T DE602005026083D1 (de) | 2004-07-09 | 2005-06-22 | Firewall-System zum Schutz einer Gerätegruppe, am System teilnehmendes Gerät und Verfahren zur Aktualisierung der Firewall-Regeln innerhalb des Systems |
| EP05105528A EP1615386B1 (fr) | 2004-07-09 | 2005-06-22 | Système de pare-feu protégeant une communauté d'appareils, appareil participant au système et méthode mise à jour des règles de pare-feu au sein du système |
| ES05105528T ES2359637T3 (es) | 2004-07-09 | 2005-06-22 | Sistema cortafuegos para proteger una comunidad de aparatos, aparato participante del sistema y método para actualización de las reglas de cortafuegos dentro del sistema. |
| US11/174,830 US7676836B2 (en) | 2004-07-09 | 2005-07-05 | Firewall system protecting a community of appliances, appliance participating in the system and method of updating the firewall rules within the system |
| MXPA05007362A MXPA05007362A (es) | 2004-07-09 | 2005-07-07 | Sistema de corta fuegos que protege una comunidad de aparatos, aparato que participa en el sistema y metodo para actualizar las reglas del corta fuegos dentro del sistema. |
| CN2005100819466A CN1719834B (zh) | 2004-07-09 | 2005-07-08 | 防火墙***、加入***的设备以及更新防火墙规则的方法 |
| KR1020050061592A KR101164680B1 (ko) | 2004-07-09 | 2005-07-08 | 가전제품들의 커뮤니티를 보호하는 방화벽 시스템, 그시스템에 참여하는 가전제품 및 그 시스템 내의 방화벽규칙들을 업데이트하는 방법 |
| JP2005200523A JP4829554B2 (ja) | 2004-07-09 | 2005-07-08 | 装置のグループをプロテクトするファイヤウォール、システムに参加する装置及びシステム内のファイヤウォール・ルールを更新する方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0451496A FR2872983A1 (fr) | 2004-07-09 | 2004-07-09 | Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2872983A1 true FR2872983A1 (fr) | 2006-01-13 |
Family
ID=34948368
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0451496A Pending FR2872983A1 (fr) | 2004-07-09 | 2004-07-09 | Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7676836B2 (fr) |
| EP (1) | EP1615386B1 (fr) |
| JP (1) | JP4829554B2 (fr) |
| KR (1) | KR101164680B1 (fr) |
| CN (1) | CN1719834B (fr) |
| DE (1) | DE602005026083D1 (fr) |
| ES (1) | ES2359637T3 (fr) |
| FR (1) | FR2872983A1 (fr) |
| MX (1) | MXPA05007362A (fr) |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8056124B2 (en) | 2005-07-15 | 2011-11-08 | Microsoft Corporation | Automatically generating rules for connection security |
| US7680906B2 (en) * | 2006-02-22 | 2010-03-16 | Microsoft Corporation | Configuring devices using context histories |
| US20070282880A1 (en) * | 2006-05-31 | 2007-12-06 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Partial role or task allocation responsive to data-transformative attributes |
| US7886351B2 (en) * | 2006-06-19 | 2011-02-08 | Microsoft Corporation | Network aware firewall |
| US8601104B2 (en) | 2006-09-19 | 2013-12-03 | The Invention Science Fund I, Llc | Using network access port linkages for data structure update decisions |
| US8055797B2 (en) * | 2006-09-19 | 2011-11-08 | The Invention Science Fund I, Llc | Transmitting aggregated information arising from appnet information |
| US20080072032A1 (en) * | 2006-09-19 | 2008-03-20 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Configuring software agent security remotely |
| US8224930B2 (en) * | 2006-09-19 | 2012-07-17 | The Invention Science Fund I, Llc | Signaling partial service configuration changes in appnets |
| US8281036B2 (en) | 2006-09-19 | 2012-10-02 | The Invention Science Fund I, Llc | Using network access port linkages for data structure update decisions |
| US8984579B2 (en) * | 2006-09-19 | 2015-03-17 | The Innovation Science Fund I, LLC | Evaluation systems and methods for coordinating software agents |
| US8627402B2 (en) * | 2006-09-19 | 2014-01-07 | The Invention Science Fund I, Llc | Evaluation systems and methods for coordinating software agents |
| US8601530B2 (en) * | 2006-09-19 | 2013-12-03 | The Invention Science Fund I, Llc | Evaluation systems and methods for coordinating software agents |
| US8607336B2 (en) * | 2006-09-19 | 2013-12-10 | The Invention Science Fund I, Llc | Evaluation systems and methods for coordinating software agents |
| US7752255B2 (en) * | 2006-09-19 | 2010-07-06 | The Invention Science Fund I, Inc | Configuring software agent security remotely |
| US9306975B2 (en) * | 2006-09-19 | 2016-04-05 | The Invention Science Fund I, Llc | Transmitting aggregated information arising from appnet information |
| US20080148382A1 (en) * | 2006-12-15 | 2008-06-19 | International Business Machines Corporation | System, method and program for managing firewalls |
| US8443433B2 (en) * | 2007-06-28 | 2013-05-14 | Microsoft Corporation | Determining a merged security policy for a computer system |
| US20090158386A1 (en) * | 2007-12-17 | 2009-06-18 | Sang Hun Lee | Method and apparatus for checking firewall policy |
| DE102008006670A1 (de) * | 2008-02-05 | 2009-08-06 | Db Netz Ag | Kommunikationsinfrastruktur für sicherheitsrelevante Anwendungen |
| US9621516B2 (en) * | 2009-06-24 | 2017-04-11 | Vmware, Inc. | Firewall configured with dynamic membership sets representing machine attributes |
| US8326978B2 (en) * | 2010-02-05 | 2012-12-04 | International Business Machines Corporation | Automatic updates to fabric alert definitions for fabric segmentation, fabric merge, and fabric principal switch changes |
| US9055110B2 (en) * | 2011-11-28 | 2015-06-09 | At&T Intellectual Property I, L.P. | Monitoring and controlling electronic activity using third party rule submission and validation |
| EP2641578B1 (fr) | 2012-03-22 | 2016-01-20 | Arjo Hospital Equipment AB | Sangle pour patient |
| US10164929B2 (en) | 2012-09-28 | 2018-12-25 | Avaya Inc. | Intelligent notification of requests for real-time online interaction via real-time communications and/or markup protocols, and related methods, systems, and computer-readable media |
| US9363133B2 (en) | 2012-09-28 | 2016-06-07 | Avaya Inc. | Distributed application of enterprise policies to Web Real-Time Communications (WebRTC) interactive sessions, and related methods, systems, and computer-readable media |
| GB2508086B (en) * | 2012-09-28 | 2020-07-08 | Avaya Inc | Distributed application of enterprise policies to web real-time communications (WebRTC) interactive sessions,and related methods,systems and computer-readable |
| US9294458B2 (en) | 2013-03-14 | 2016-03-22 | Avaya Inc. | Managing identity provider (IdP) identifiers for web real-time communications (WebRTC) interactive flows, and related methods, systems, and computer-readable media |
| US9088543B2 (en) * | 2013-06-03 | 2015-07-21 | International Business Machines Corporation | Coordinated network security management |
| US10205624B2 (en) | 2013-06-07 | 2019-02-12 | Avaya Inc. | Bandwidth-efficient archiving of real-time interactive flows, and related methods, systems, and computer-readable media |
| US9065969B2 (en) | 2013-06-30 | 2015-06-23 | Avaya Inc. | Scalable web real-time communications (WebRTC) media engines, and related methods, systems, and computer-readable media |
| US9525718B2 (en) | 2013-06-30 | 2016-12-20 | Avaya Inc. | Back-to-back virtual web real-time communications (WebRTC) agents, and related methods, systems, and computer-readable media |
| US9112840B2 (en) | 2013-07-17 | 2015-08-18 | Avaya Inc. | Verifying privacy of web real-time communications (WebRTC) media channels via corresponding WebRTC data channels, and related methods, systems, and computer-readable media |
| US9614890B2 (en) | 2013-07-31 | 2017-04-04 | Avaya Inc. | Acquiring and correlating web real-time communications (WEBRTC) interactive flow characteristics, and related methods, systems, and computer-readable media |
| US9531808B2 (en) | 2013-08-22 | 2016-12-27 | Avaya Inc. | Providing data resource services within enterprise systems for resource level sharing among multiple applications, and related methods, systems, and computer-readable media |
| US10225212B2 (en) | 2013-09-26 | 2019-03-05 | Avaya Inc. | Providing network management based on monitoring quality of service (QOS) characteristics of web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media |
| US10263952B2 (en) | 2013-10-31 | 2019-04-16 | Avaya Inc. | Providing origin insight for web applications via session traversal utilities for network address translation (STUN) messages, and related methods, systems, and computer-readable media |
| US9769214B2 (en) | 2013-11-05 | 2017-09-19 | Avaya Inc. | Providing reliable session initiation protocol (SIP) signaling for web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media |
| US10129243B2 (en) | 2013-12-27 | 2018-11-13 | Avaya Inc. | Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials |
| US9215214B2 (en) | 2014-02-20 | 2015-12-15 | Nicira, Inc. | Provisioning firewall rules on a firewall enforcing device |
| US9794289B1 (en) * | 2014-04-11 | 2017-10-17 | Symantec Corporation | Applying security policies based on context of a workload |
| US10581927B2 (en) | 2014-04-17 | 2020-03-03 | Avaya Inc. | Providing web real-time communications (WebRTC) media services via WebRTC-enabled media servers, and related methods, systems, and computer-readable media |
| US9749363B2 (en) | 2014-04-17 | 2017-08-29 | Avaya Inc. | Application of enterprise policies to web real-time communications (WebRTC) interactive sessions using an enterprise session initiation protocol (SIP) engine, and related methods, systems, and computer-readable media |
| US9912705B2 (en) | 2014-06-24 | 2018-03-06 | Avaya Inc. | Enhancing media characteristics during web real-time communications (WebRTC) interactive sessions by using session initiation protocol (SIP) endpoints, and related methods, systems, and computer-readable media |
| US9560013B2 (en) | 2014-11-04 | 2017-01-31 | Samsung Electronics Co., Ltd. | Firewall based prevention of the malicious information flows in smart home |
| US9871820B2 (en) * | 2014-12-27 | 2018-01-16 | Intel Corporation | Technologies for managing network privileges based on physical presence |
| US10506065B2 (en) | 2014-12-27 | 2019-12-10 | Intel Corporation | Technologies for managing social relationships of a computing device social group |
| CN104580216B (zh) * | 2015-01-09 | 2017-10-03 | 北京京东尚科信息技术有限公司 | 一种对访问请求进行限制的***和方法 |
| US9755903B2 (en) | 2015-06-30 | 2017-09-05 | Nicira, Inc. | Replicating firewall policy across multiple data centers |
| US9813357B2 (en) * | 2015-11-03 | 2017-11-07 | Gigamon Inc. | Filtration of network traffic using virtually-extended ternary content-addressable memory (TCAM) |
| US10594731B2 (en) | 2016-03-24 | 2020-03-17 | Snowflake Inc. | Systems, methods, and devices for securely managing network connections |
| US10348685B2 (en) | 2016-04-29 | 2019-07-09 | Nicira, Inc. | Priority allocation for distributed service rules |
| US10135727B2 (en) | 2016-04-29 | 2018-11-20 | Nicira, Inc. | Address grouping for distributed service rules |
| US11171920B2 (en) | 2016-05-01 | 2021-11-09 | Nicira, Inc. | Publication of firewall configuration |
| US10944722B2 (en) | 2016-05-01 | 2021-03-09 | Nicira, Inc. | Using activities to manage multi-tenant firewall configuration |
| US11258761B2 (en) | 2016-06-29 | 2022-02-22 | Nicira, Inc. | Self-service firewall configuration |
| US11088990B2 (en) | 2016-06-29 | 2021-08-10 | Nicira, Inc. | Translation cache for firewall configuration |
| US11310202B2 (en) | 2019-03-13 | 2022-04-19 | Vmware, Inc. | Sharing of firewall rules among multiple workloads in a hypervisor |
| WO2021121574A1 (fr) | 2019-12-18 | 2021-06-24 | Huawei Technologies Co., Ltd. | Exécution d'une négociation de sécurité pour une configuration de réseau |
| RU2727090C1 (ru) * | 2020-02-18 | 2020-07-17 | Открытое Акционерное Общество "Российские Железные Дороги" | Программно-аппаратный комплекс для обмена данными автоматизированных систем |
| US11233475B2 (en) | 2020-05-14 | 2022-01-25 | Rockwell Automation Technologies, Inc. | DC bus precharge system |
| US11627166B2 (en) | 2020-10-06 | 2023-04-11 | Cisco Technology, Inc. | Scope discovery and policy generation in an enterprise network |
| MA54776B1 (fr) | 2021-10-29 | 2023-09-27 | Univ Int Rabat | Méthode de déploiement d’une nouvelle politique de sécurité de Pare-feu dans un réseau informatique. |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0854621A1 (fr) * | 1997-01-17 | 1998-07-22 | AT&T Corp. | Système et procédé pour permettre la contrÔle d'accès au même niveau dans un reseau |
| US6212633B1 (en) * | 1998-06-26 | 2001-04-03 | Vlsi Technology, Inc. | Secure data communication over a memory-mapped serial communications interface utilizing a distributed firewall |
| EP1313290A1 (fr) * | 2001-11-19 | 2003-05-21 | Stonesoft Corporation | Firewall personnel avec fonction dépendante de la position |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3426832B2 (ja) * | 1996-01-26 | 2003-07-14 | 株式会社東芝 | ネットワークアクセス制御方法 |
| US5968176A (en) * | 1997-05-29 | 1999-10-19 | 3Com Corporation | Multilayer firewall system |
| IL122314A (en) * | 1997-11-27 | 2001-03-19 | Security 7 Software Ltd | Method and system for enforcing a communication security policy |
| JP3732672B2 (ja) * | 1999-03-10 | 2006-01-05 | 株式会社東芝 | ネットワークセキュリティルール管理システム及びネットワークセキュリティルール管理装置 |
| US6675128B1 (en) * | 1999-09-30 | 2004-01-06 | International Business Machines Corporation | Methods and apparatus for performance management using self-adjusting model-based policies |
| US7546629B2 (en) * | 2002-03-06 | 2009-06-09 | Check Point Software Technologies, Inc. | System and methodology for security policy arbitration |
| US7222359B2 (en) * | 2001-07-27 | 2007-05-22 | Check Point Software Technologies, Inc. | System methodology for automatic local network discovery and firewall reconfiguration for mobile computing devices |
| US7322044B2 (en) * | 2002-06-03 | 2008-01-22 | Airdefense, Inc. | Systems and methods for automated network policy exception detection and correction |
| JP4052983B2 (ja) * | 2002-06-28 | 2008-02-27 | 沖電気工業株式会社 | 警戒システム及び広域ネットワーク防護システム |
| US7249187B2 (en) * | 2002-11-27 | 2007-07-24 | Symantec Corporation | Enforcement of compliance with network security policies |
| US7496910B2 (en) * | 2004-05-21 | 2009-02-24 | Desktopstandard Corporation | System for policy-based management of software updates |
| US7540013B2 (en) * | 2004-06-07 | 2009-05-26 | Check Point Software Technologies, Inc. | System and methodology for protecting new computers by applying a preconfigured security update policy |
-
2004
- 2004-07-09 FR FR0451496A patent/FR2872983A1/fr active Pending
-
2005
- 2005-06-22 EP EP05105528A patent/EP1615386B1/fr not_active Expired - Fee Related
- 2005-06-22 DE DE602005026083T patent/DE602005026083D1/de active Active
- 2005-06-22 ES ES05105528T patent/ES2359637T3/es active Active
- 2005-07-05 US US11/174,830 patent/US7676836B2/en not_active Expired - Fee Related
- 2005-07-07 MX MXPA05007362A patent/MXPA05007362A/es active IP Right Grant
- 2005-07-08 JP JP2005200523A patent/JP4829554B2/ja not_active Expired - Fee Related
- 2005-07-08 CN CN2005100819466A patent/CN1719834B/zh not_active Expired - Fee Related
- 2005-07-08 KR KR1020050061592A patent/KR101164680B1/ko active IP Right Grant
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0854621A1 (fr) * | 1997-01-17 | 1998-07-22 | AT&T Corp. | Système et procédé pour permettre la contrÔle d'accès au même niveau dans un reseau |
| US6212633B1 (en) * | 1998-06-26 | 2001-04-03 | Vlsi Technology, Inc. | Secure data communication over a memory-mapped serial communications interface utilizing a distributed firewall |
| EP1313290A1 (fr) * | 2001-11-19 | 2003-05-21 | Stonesoft Corporation | Firewall personnel avec fonction dépendante de la position |
Also Published As
| Publication number | Publication date |
|---|---|
| US20060010491A1 (en) | 2006-01-12 |
| CN1719834B (zh) | 2011-07-13 |
| EP1615386A1 (fr) | 2006-01-11 |
| JP2006040274A (ja) | 2006-02-09 |
| KR20060049972A (ko) | 2006-05-19 |
| CN1719834A (zh) | 2006-01-11 |
| KR101164680B1 (ko) | 2012-07-10 |
| JP4829554B2 (ja) | 2011-12-07 |
| DE602005026083D1 (de) | 2011-03-10 |
| EP1615386B1 (fr) | 2011-01-26 |
| ES2359637T3 (es) | 2011-05-25 |
| MXPA05007362A (es) | 2006-02-13 |
| US7676836B2 (en) | 2010-03-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2872983A1 (fr) | Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme | |
| EP3044913B1 (fr) | Procede et systeme d'etablissement de reseaux prives virtuels entre reseaux locaux | |
| WO2009047325A1 (fr) | Dispositif et procede pour aiguiller des flux d'echange de valeurs publiques ou non sensibles permettant de creer des cles secretes communes entre plusieurs zones | |
| EP1494391A1 (fr) | Procédé de configuration automatique d'un routeur d'accès, compatible avec le protocole DHCP, pour effectuer un traitement automatique spécifique des flux IP d'un terminal client | |
| EP3354000A1 (fr) | Equipement pour offrir des services de résolution de noms de domaine | |
| WO2011151573A1 (fr) | Procede et dispositifs de communications securisees dans un reseau de telecommunications | |
| WO2019186006A1 (fr) | Procédé de connexion sans fil d'un objet communicant à un réseau de communication local, programme d'ordinateur et équipement d'accès correspondant | |
| CA3100170C (fr) | Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede | |
| FR3028369A1 (fr) | Procede et systeme de gestion d'identites d'utilisateurs destine a etre mis en oeuvre lors d'une communication entre deux navigateurs web | |
| US11477026B1 (en) | Using secure tokens for stateless software defined networking | |
| CA3153796A1 (fr) | Procede de connexion d'un noeud de communication, et noeud de communication correspondant | |
| EP4080923B1 (fr) | Dispositif électronique de gestion décentralisée de groupe(s) de communication | |
| FR2895816A1 (fr) | Systeme, dispositif portable et procede pour la configuration d'un dispositif communicant dans un reseau | |
| FR3116978A1 (fr) | Contrôle d’accès à un réseau de communication local, et passerelle d’accès mettant en œuvre un tel contrôle | |
| WO2022238644A1 (fr) | Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe | |
| EP4133707A1 (fr) | Procede mis en oeuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication | |
| WO2024105111A1 (fr) | Procédé de distribution de clefs de session dans un réseau de télécommunication, procédés associés de traitement dans un client et un serveur, module client et serveurs associés | |
| WO2023232888A1 (fr) | Infrastructure de sécurité; procédé et produit programme d'ordinateur associés | |
| FR3093882A1 (fr) | Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants. | |
| FR2906097A1 (fr) | Procedes d'echange de donnees securises, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants. | |
| WO2006035137A1 (fr) | Procede et dispositif de filtrage pour detecter une usurpation d’adresse dans un reseau informatique | |
| WO2017089710A1 (fr) | Procédé de distribution de droits sur un service et plateforme de service | |
| Trabelsi | Services spontanés sécurisés pour l'informatique diffuse | |
| WO2013057391A1 (fr) | Procédé pour accéder à un système d'information disposé derrière une passerelle informatique | |
| WO2005002147A1 (fr) | Architecture de reseau local sans fil |