Brevet FR2844415A1 — publié le 20040312

2002-0152 Domaine technique La présente invention concerne de façon générale les mécanismes de pare-feu qui sont utilisés pour connecter ensemble deux réseaux de transmission de données tels que des 5 réseaux Intranet appartenant à deux entités différentes telles que deux sociétés ayant chacune un contrôle administratif spécifique, et concerne en particulier un système pare-feu pour interconnecter deux réseaux IP gérés par deux administrateurs différents. Etat de la technique Beaucoup de techniques pour la sécurité d'un réseau utilisent aujourd'hui un pare-feu qui est généralement connu comme une combinaison de matériel et de logiciel utilisé pour 15 mettre en oeuvre une politique de sécurité gérant le trafic entre deux ou plusieurs réseaux, certains pouvant être privés sous le contrôle administratif d'un client ou d'un fournisseur de réseau (ex: des réseaux organisationnels) et d'autres n'étant pas sous contrôle administratif tels qu'un réseau 20 public (ex: Internet). Un pare-feu de réseau sert habituellement de première ligne de défense contre les menaces extérieures dues à des systèmes ou réseaux d'ordinateurs organisationnels. Les pare-feu peuvent aussi être utilisés pour partitionner des réseaux ou isoler/interconnecter des 25 VPN. En d'autres termes, un pare-feu est un système conçu pour empêcher un accès non autorisé vers ou à partir d'un réseau privé. Les pare-feu sont fréquemment utilisés pour empêcher les utilisateurs d'Internet non autorisés d'accéder à 30 des réseaux privés connectés à Internet, spécialement les Intranets mais peuvent aussi être utilisés entre deux Intranets. Tous les messages entrant dans ou quittant le réseau Intranet passent à travers le pare-feu qui examine chaque message et bloque ceux qui ne respectent pas les 2 2002-0152 critères de sécurité qui ont été définis. Ils peuvent être aussi utilisés pour interconnecter des réseaux privés gérés par deux entités administratives différentes. Dans ce cas, deux pare-feu sont généralement en cascade avec une liaison 5 intermédiaire appelée DMZ, chacun étant géré par une autorité administrative différente. Les pare-feu réalisent différents procédés à prise de décision et principalement le filtrage des paquets de données consistant à examiner chaque paquet entrant ou sortant et à 10 accepter ou rejeter ce paquet en se basant sur des règles définies par l'utilisateur. Cependant, d'autres fonctions sécuritaires peuvent être implémentées dans un pare-feu telles qu'une passerelle appliquant un mécanisme de sécurité à des applications spécifiques comme FTP et les serveurs Telnet, une 15 passerelle de niveau circuit appliquant un mécanisme de sécurité lorsqu'une connexion TCP ou UDP est établie et un serveur proxy permettant d'établir une connexion pour un client entre le serveur proxy et un dispositif destinataire. En plus de ces fonctions de sécurité, les pare-feu 20 peuvent aussi effectuer des fonctions de routage qui sont associées au réseau protégé et qui sont associées de façon classique à un routeur séparé/individuel. Le routage est le procédé qui décide de la disposition de chaque paquet qu'un dispositif de routage a à traiter. Ceci s'applique aux paquets 25 entrants, aux paquets quittant le réseau pour des destinations externes et aux paquets routés entre des réseaux internes. En fin de compte, il peut y avoir seulement deux possibilités pour les paquets: être transmis ou être refusés. Le mécanisme de routage qui s'appuie sur une table de routage prend la 30 décision en utilisant l'adresse IP de destination se trouvant dans l'en-tête du paquet. Une configuration de routage reflétant la topologie du réseau est généralement utilisée de manière à ce que le parefeu soit capable d'acheminer correctement les paquets jusqu'à 3 2002-0152 leur destination. Une table de routage du pare-feu contient une liste d'adresses de réseau IP pour lesquelles le pare-feu est adapté à fournir des services de routage. Lorsque la recherche dans la table est réussie pour un paquet, la table 5 fournit soit l'adresse du prochain routeur auquel il faut envoyer le paquet soit l'interface à utiliser pour transmettre le paquet. Si la recherche dans la table n'aboutit pas, le paquet est ignoré et un message ICMP "injoignable" est généralement renvoyé à la source indiquant que le paquet n'a 10 pas pu être délivré. Cependant, le mécanisme de routage étant trop rapide et non fiable, il ne peut pas être utilisé pour mettre en òuvre des règles de sécurité. C'est pourquoi une technique de sécurité appelée "stateful inspection" ou filtrage dynamique 15 de paquet est souvent utilisée. Alors que le filtrage de paquet classique est basé seulement sur l'information de l'entête pour chaque paquet individuel sans considérer les paquets précédents, le filtrage ou l'inspection dynamique permet à la fois des combinaisons complexes du contenu du message et du 20 contexte déterminé par les paquets précédents pour déterminer les décisions de filtrage. Comme pour le filtrage de paquet, l'inspection dynamique est mise en oeuvre comme un plus dans le routage. L'intérêt principal de l'inspection dynamique est d'obtenir un compromis entre la performance et la sécurité. 25 Comme ajout au routage, l'inspection dynamique fournit une bien meilleure performance que les proxys. Elle fournit également une amélioration du niveau de la fonction pare-feu au delà du simple filtrage de paquet. Comme les proxys, des critères de contrôle d'accès beaucoup plus complexes peuvent 30 être spécifiés, et comme pour le filtrage de paquet, l'inspection dynamique dépend de la bonne qualité (c'est à dire correcte) associée à la mise en oeuvre du routage. Mais, dans tous les cas, deux pare-feu physiquement différents sont mis en oeuvre l'un à la suite de l'autre dans 4 2002-0152 une interconnexion entre des réseaux Intranet du fait que chaque réseau est géré par une organisation différente qui désire avoir un accès administratif dédié au pare-feu pour définir des règles et conserver des évènements. Une partie des 5 règles est commune mais ces règles sont exécutées deux fois ce qui diminue la performance d'ensemble du système. Le cot et la complexité sont élevés, et la fiabilité est plus faible du fait que deux équipements en série sont utilisés. La configuration est plus complexe car il y a une liaison 10 additionnelle entre les deux pare-feu. Exposé de l'invention Par conséquent, le but principal de l'invention est de remplacer le système de pare-feu classique comportant deux 15 pare-feu physiquement différents en série par un système comprenant un seul dispositif pare-feu pour interconnecter deux réseaux IP appartenant à deux entités différentes gérées par deux administrateurs différents. L'objet de l'invention est donc un système pare-feu pour 20 interconnecter un premier réseau IP à un second réseau IP, les deux réseaux appartenant à deux entités différentes ayant chacune une administration différente dans lequel tout paquet transmis ou reçu par le premier réseau IP est filtré en utilisant une première fonction pare-feu et tout paquet 25 transmis ou reçu par le second réseau IP est filtré en utilisant une seconde fonction pare-feu. Ce système comprend essentiellement un seul dispositif pare-feu comportant des moyens de filtrage effectuant aussi bien la première fonction pare-feu que la seconde fonction pare-feu, un port console 30 permettant à l'administrateur ayant la charge d'administrer chaque réseau IP d'entrer les règles de filtrage pour mettre à jour la fonction pare-feu associée et des moyens de contrôle interconnectant le port console et les moyens de filtrage pour transmettre à ceux-ci les règles de filtrage de manière à ce 2002-0152 que chaque administrateur puisse gérer le système de façon indépendante à partir du port console. Brève description des dessins Les buts, objets, caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description suivante plus particulière de l'invention en référence aux dessins joints, dans lesquels: la figure 1 est un blocdiagramme d'un système antérieur 10 comportant deux réseaux IP appartenant à deux entités différentes ayant deux administrateurs différents, la figure 2 est un bloc-diagramme du même système que celui illustré sur la figure 1 mais dans lequel les deux dispositifs pare-feu ont été remplacés par un seul dispositif pare-feu 15 selon l'invention, la figure 3 est un bloc-diagramme représentant les blocs fonctionnels d'un dispositif pare-feu, les figures 4A et 4B sont des blocs-diagrammes représentant les blocs fonctionnels d'un système pare-feu selon l'invention 20 respectivement pour l'écoulement des données du premier réseau au second réseau et pour l'écoulement des données du second réseau au premier réseau, et la figure 5 est un diagramme schématique représentant la méthode de réalisation de la fusion des règles. 25 Description détaillée de l'invention La figure 1 montre un système classique o deux réseaux NET1 10 et NET2 16 appartenant à deux entités administratives différentes telles que deux sociétés différentes, sont 30 interconnectés en toute sécurité via un système pare-feu complexe comprenant un premier pare-feu FW1 12 et un second pare-feu FW2 14. Le propriétaire administratif du NETl référencé MG1 11, gère FW1 tandis que le propriétaire MG2 17 du réseau NET2 gère 6 2002-0152 FW2. Un LAN 15 interconnecte FW1 et FW2 et est, dans cet exemple, une zone démilitarisée DMZ 15 partagée par les deux sociétés. Des serveurs communs peuvent être mis en oeuvre dans cette zone tels que le serveur SR 18. Les deux sociétés 5 peuvent utiliser un tel serveur. Une telle zone est ainsi appelée communauté d'intérêt COI. Le système illustré sur la figure 1 est coteux et ajoute des bytes en surplus dans l'écoulement des données puisque le traitement pare-feu est exécuté deux fois. En plus, 10 toute panne de l'un des pare-feu arrête le trafic. Ces inconvénients sont évités par le système pare-feu selon l'invention illustré sur la figure 2 dans lequel les deux pare-feu FW1 et FW2 sont remplacés par un seul dispositif physique FW 20 qui peut aussi fournir une zone locale 15 démilitarisée pour connecter un serveur externe partagé tel que SR 18. Le seul pare-feu 20 permet à MG1 11 et MG1 17 de gérer respectivement leur partie logique de pare-feu dans le système de pare-feu dual. Dans un tel système, aucune visibilité à la 20 configuration d'une partie est fournie à l'administrateur de l'autre partie mais les règles qui peuvent être agrégées permettent d'optimiser la performance. Par conséquent, le cot d'une telle implémentation est moins élevé et la fiabilité meilleure. Un pare-feu standard avec ses blocs fonctionnels est représenté sur la figure 3. A noter qu'un pare-feu est normalement divisé en deux dispositifs qui sont fonctionnellement identiques pour les deux chemins de données excepté pour le mécanisme d'inspection dynamique qui inclut un écoulement de contrôle additionnel entre les côtés transmission et réception. Attendu que les blocs fonctionnels sont les mêmes pour les deux chemins de données, seul le dispositif pare-feu contrôlant le chemin de données sortant du réseau NETl est représenté sur la figure 3. 7 2002-0152 Les blocs fonctionnels du pare-feu comprennent dans le sens de la transmission à partir de NETI 10 à DMZ 15 comme exemple, une première fonction de conversion d'adresse de réseau NATin 30 qui est optionnelle puisque cette fonction 5 n'est nécessaire que si il y a une règle de correspondance pour modifier l'adresse IP de source et qui transmet les données à un second bloc FILTin 31. Cette fonction effectue le filtrage sur l'interface d'entrée et envoie les paquets acceptés à IPgwl 35 qui est l'unité de transmission de pare10 feu. Elle peut prendre des décisions de routage basées sur le routage défini par le point de contrôle de routage RCP 34. RCP maintient les routes avec les dispositifs de routage associés et met à jour la table de routage de la passerelle 35. En appliquant ces règles, un paquet peut être transmis à 15 une fonction intégrée telle qu'une application proxy PXY 36 ou un serveur SERVi 38 pour authentification, encryptage ou autre module de service tel qu'un service DHCP. Il peut aussi être transmis à RCP si le paquet est un message de mise à jour de routage. Autrement, le chemin principal est de transmettre le 20 paquet à l'interface de sortie, mais le paquet a de nouveau deux blocs à passer: un premier bloc de filtrage pour la sortie des paquets FILToutl 33 suivi d'une seconde fonction NAToutl 32 seulement s'il y a une règle de correspondance pour modifier l'adresse IP de destination. Puis, le paquet quitte 25 le pare-feu et entre dans le DMZ 15 dans cet exemple. Le besoin d'appliquer un filtrage et NAT à la sortie est principalement pour les paquets qui ont été modifiés dans le proxy et les serveurs et pour lesquels les règles d'entrée sont sans valeur. Ces blocs existent même quand les fonctions 30 NAT ne sont pas utilisées. Dans le bloc de filtrage 31, les règles de filtrage déterminent si un paquet sera autorisé à travers le filtrage IP, dans les routines TCP/IP du noyau ou dans le réseau. Le filtrage statique basé sur une liste d'accès filtre les 8 2002-0152 paquets en utilisant des filtres configurés de façon statique basés sur les champs suivants: - adresses de source et de destination - type de protocole (ex: TCP, UDP, ICMP, IGMP, RSVP, OSPF, IGP, EGP, NVP) - numéros des ports de source et de destination - champ TOS (type de service) - options IP - fragmentation IP - type de code ICMP - bit Ack et Rst de TCP Pour la comptabilité IP, des règles d'entrée et de sortie peuvent être également établies séparément, en enregistrant le nombre de bytes qui transitent. Chaque fois 15 qu'une occurrence de règle se produit, le compte de bytes du paquet est ajouté à la règle (permettant la collecte de statistiques en cascade). Les données de comptabilité IP peuvent être saisies soit après le bloc de filtrage, soit après la passerelle IPgwl 35. Les données sont fournies au 20 bloc de contrôle CTRL 39 qui les collecte pour les fournir ensuite à l'entité administrative. Le routage IP dans IPgw 35 est une option qui permet de transmettre des paquets selon les règles de routage définies dans le point de contrôle RCP. Le support du serveur 38 et du proxy 36 peuvent aussi être 25 inclus. D'autres fonctions peuvent être intégrées dans le serveur 38 ou le proxy 36 telles que la fonction d'authentification IP. Dans ce cas, les paquets qui sont authentifiés passent seulement une fois à travers le pare-feu 30 pour empêcher le double traitement. L'encryptage tel que "IPsec tunneling" est une fonction très souvent utilisée dans un pare-feu. Comme il n'est pas possible d'analyser un tunnel encrypté, le paquet décrypté 9 2002-0152 venant du module d'encryptage doit passer par le bloc de filtrage de sortie et par conséquent est analysé. A noter que le bloc de contrôle CTRL 39 administrant le pare-feu effectue l'authentification de l'utilisateur 5 (l'administrateur du pare-feu) la configuration, les fichiers log, les statistiques et la détermination des problèmes de sorte qu'il est relié à chacun des blocs fonctionnels internes (les liens ne sont pas montrés sur la figure du fait qu'ils ne sont pas fonctionnels mais simplement utilisés pour le 10 contrôle). L'accès au pare-feu pour l'administration peut toujours être fait à l'aide du port console 37. La configuration peut également être réalisée par l'accès au contrôle CTRL 39 à partir de NETi ou de DMZ même si cette dernière possibilité n'est pas recommandée pour des raisons de 15 sécurité. Selon l'invention, un seul dispositif pare-feu illustré sur les figures 4A et 4B remplace les deux pare-feu classiques en cascade. Comme expliqué ci-dessous, les blocs fonctionnels sont les mêmes que dans un pare-feu classique mais ils ne sont 20 pas dupliqués en deux pare-feu. En référence à la figure 4A représentant le pare-feu pour le chemin de données de NETi à NET2, la première et la dernière fonctions sont les fonctions de conversion d'adresse de réseau dans les blocs NATinl 30 et NATout2 42. Les règles associées peuvent être nécessaires 25 entre l'interface d'entrée et le DMZ interne ou entre le DMZ et l'interface de sortie ou les deux. Les règles nécessitent les paramètres suivants: - source d'origine, destination d'origine, service d'origine se référant à l'adresse de la source, de 30 la destination et au service du paquet avant sa conversion, et source convertie, destination convertie, service converti se référant à ces paramètres après conversion. 2002-0152 - un type de paramètre de conversion (par exemple SNAT en tant que NAT statique, DNAT en tant que NAT dynamique, MASQUERADING aussi appelé conversion d'adresse de port). L'administrateur du réseau raccordé localement gère seulement NAT sur son interface locale. Aussi, seule une entrée NATinl 30 est implémentée du côté NETl et gérée par l'administrateur de NETi tandis que la sortie NATout2 42 à l'interface NET2 est gérée par l'administrateur NET2. Comme dans un pare-feu classique, une fonction essentielle est le filtrage tel que déjà mentionné en référence à la figure 3, réalisé dans le bloc FILTinl2 41. Des règles sont associées à cette fonction telles que les règles de renforcement du numéro de séquence, les règles d'inspection 15 dynamique, les règles dépendantes du temps, les règles de filtrage statique par pare-feu logique séparées en blocs de filtrage d'entrée et de sortie. Dans la mesure o les paquets de données peuvent être traités par d'autres fonctions dans un serveur ou proxy comme déjà mentionné, un autre bloc de 20 filtrage FILToutl2 43 est nécessaire avant le bloc NATout2 42. La fonction de ce bloc de sortie est la même que la fonction du bloc FILTinl2 placé à l'entrée. Les règles de routage d'entrée/sortie sont aussi définies pour tous les paquets mais établies par chaque 25 administrateur sur la passerelle IP correspondante aussi appelée moteur de routage virtuel et de transmission référencé IPgwl 35 et IPgw2 45 situés entre les blocs FILTinl2 41 et FILToutl2 42. Chaque passerelle obtient les règles de transmission à l'aide du point de contrôle de routage dédié 30 RCP1 34 et RCP2 44 gérant et faisant connaître respectivement les routes pour IPgwl et IPgw2. Les administrateurs doivent échanger des informations pour fournir les routes entre ces deux passerelles mais aucun bloc commun n'est nécessaire dans un mode de réalisation utilisant deux passerelles différentes. il 2002-0152 Un mode de réalisation optionnel basé sur une seule passerelle IP partagée est possible lorsqu'aucune contrainte de visibilité n'existe entre les deux réseaux NET1 et NET2 ou si la passerelle IP peut être gérée par un seul administrateur, 5 l'autre faisant connaître ses routes grâce à un routeur externe à la passerelle IP interne et à un point de contrôle de routage associé. Les informations de comptabilité IP réunies par une entité administrative à partir des blocs fonctionnels tels que 10 NAT 30 et 42, des blocs de filtrage 41 et 43 et des passerelles IP 35 et 45 sont emmagasinées dans un bloc de contrôle dédié CTRL1 39 ou CTRL 49. Les statistiques globales du trafic agrégé sont emmagasinées dans le contrôle commun 47. D'autre fonctions administratives dédiées telles que la 15 notification e. mail, la sécurité de gestion du réseau et du mot de passe sont gérées séparément dans CTRL1 39 et CTRL2 49. La configuration d'origine du pare-feu par chaque administrateur est aussi conservée dans le bloc de contrôle respectif. La sécurité et l'intégrité de chaque partie de la 20 configuration sont obtenues grâce à une configuration certifiée (certificats) qui permet de réduire cette entité duale à un seul équipement sans problème de sécurité. Le proxy dédié tel que PXY1 36 et PXY2 46, et les fonctions de serveur telles que SRV1 38 et SRV2 48 continuent 25 à être dédiées dans ce mode de réalisation puisqu'elles sont chacune connectées à un bloc passerelle correspondant c'est à dire respectivement IPgwl 35 et IPgw2 45. La connexion de IPgwl à IPgw2 peut être considérée comme zone DMZ et peut fournir une connexion externe pour des 30 serveurs externes tels que SR18. La figure 4B Montre le chemin des données pour le trafic qui va du NET2 16 au NETi 10. La plupart des blocs fonctionnels sont communs avec ceux du chemin opposé décrit 12 2002-0152 sur la figure 4A puisque ce sont les mêmes blocs que les simples pare-feu standards. Les principales différences concernent les blocs NATin2 42' et FILTin2l 43' du côté NET2 et les blocs NAToutl 30' et 5 FILTout2l 41' du côté NETi. Le bloc NATin2 42' a une relation forte avec le bloc NATout2 42 puisque, dès qu'une correspondance NAT est définie dans un des deux blocs, la correspondance inverse doit être activée dans l'autre bloc en tant que fonction inverse de conversion. De façon similaire, 10 NATOutl 30' et NATinl 30 ont la même relation entre eux. Les blocs FILTin21 et FILTOut 12 n'ont aucune relation excepté pour les règles d'inspection dynamique dans la mesure o un flot de données identifié d'un côté sera accepté sur l'autre côté. Ceci signifie que des règles dynamiques sont 15 ajoutées aux deux blocs grâce à la fonction d'inspection dynamique comme c'est le cas des pare-feu standards. Le même lien dynamique peut être mis en òuvre entre FILTout2l et FILTin 12. En référence de nouveau aux figures 4A et 4B, une 20 caractéristique essentielle de l'invention est le bloc de fusion 40 utilisé pour fusionner les règles. Avant d'expliquer le procédé de fusion, il est utile de mentionner que le mécanisme de filtrage d'un pare-feu applique les règles dans un mode séquentiel en utilisant une liste de règles. Si le 25 paquet entrant respecte la première règle, il quitte le bloc de filtrage et est transmis au bloc suivant du pare-feu. Sinon, la seconde règle est appliquée et ainsi de suite. Normalement, il devrait être conforme à une règle. Pour raison de sécurité, la dernière règle appliquée est une règle 30 implicite pour refuser tous les messages qui ne sont pas conformes. Les messages non conformes sont des messages qui n'ont pas été conformes à une règle avant la fin de la séquence des règles. Comme la dernière règle est le plus souvent une règle du type " refuser tout ", un paquet 13 2002-0152 atteignant cette dernière règle est rejeté. Dans un mécanisme pare-feu dual selon l'invention, il est donc essentiel de fusionner les règles de manière à n'appliquer qu'un nombre réduit de règles. Le procédé de fusion est déroulé indépendamment pour FILTin12 ou FILToutl2. Grâce à ce mécanisme, le pare-feu à double administration peut déterminer les règles redondantes de chaque administrateur de façon à optimiser la performance. Aucun des deux administrateurs ne peut accéder au résultat de 10 fusion de manière à protéger la connaissance des règles mais l'administrateur de chaque côté peut déterminer que ses règles ont été correctement implémentées grâce à l'identification de la fusion réalisée règle par règle. Dans un système classique, la cascade de deux pare-feu 15 signifie que dans chaque sens, les règles de sortie d'un parefeu sont suivies par les règles d'entrée du second pare-feu. Ceci n'est plus le cas avec la fonction proposée de fusion des règles puisque la plupart des règles de filtrage peuvent être exécutées une seule fois dans un mode de réalisation intégrant 20 les deux pare-feu logiques comme expliqué avec plus de détails ci-après. Deux ensembles de fichiers d'évènements sont construits et gérés par CTRL1 et CTRL2 attendu que chaque règle est identifiée avec la règle mère de chaque côté même après 25 fusion. Chaque administrateur peut définir chaque information, règle ou fichier comme étant commun ou local de sorte que des fichiers d'alarmes par exemple peuvent être partagés. Dans ce cas, le contrôle est donné au bloc de contrôle commun 47 qui traite toutes les caractéristiques, fichiers et services 30 communs. Les caractéristiques communes comprennent l'interface de configuration utilisée par les deux administrateurs pour établir chaque nouvelle configuration de chaque côté, le visualiseur d'activités qui montre en temps réel le trafic de 14 2002-0152 NETi à NET2 incluant l'activité DMZ, le mécanisme de récupération et de stockage des alertes et évènements qui définit à quels blocs CTRL1, CTRL2 ou COMMON CTRL les évènements doivent être envoyés, le gestionnaire de matériel 5 pour l'installation et la détermination des problèmes et l'interface d'authentification d'utilisateur avec la protection d'accès comme mécanisme commun nécessaire pour identifier les administrateurs de chaque pare-feu logique sur requête à partir du port console 37 ou de l'interface NETi ou 10 NET2. En comparaison, un pare-feu standard comprend en tant que bloc de contrôle ce qui se trouve dans CTRLî et COMMON CTRL excepté que dans un tel cas, l'identification du pare-feu logique correspondant à l'utilisateur n'est pas nécessaire et l'enregistrement de l'information trafic n'a pas a être défini 15 puisque un seul ensemble de fichiers d'évènements est disponible. Un administrateur peut permettre ou non l'accès à l'autre côté du pare-feu sur son interface d'accès directe. Sur un pare-feu standard, l'administration utilisant par 20 exemple Telnet est possible à partir de n'importe quelle interface. Bien sr, l'administrateur peut verrouiller des ports tels que l'interface de réseau public. Sur une pare-feu dual, chaque administrateur gère cette autorisation et donc l'accès utilisant d'autres ports ou interfaces que l'interface 25 dédiée à son réseau peut être verrouillé. Ceci signifie que le verrouillage de port ne peut pas être fait au niveau protocole, par exemple en autorisant Telnet ou non sur un port, parce que l'un des administrateurs désire conserver cet accès protocole sur une interface pour lui-même mais non pour 30 l'autre administrateur. Un mécanisme de filtrage plus complexe utilisant un serveur d'authentification externe tel que TACAS ou RADIUS est recommandé pour authentifier de façon sre l'utilisateur et ses droits d'un côté ou de l'autre du parefeu dual. S'il est nécessaire de permettre l'administration à 2002-0152 partir de différentes interfaces, les serveurs d'authentification des deux entités administratives devront être reliés pour permettre la transmission de l'authentification au serveur approprié. En référence à la figure 5, une fonction de fusion utilisant 2 fichiers de configuration 50 et 51 doit être considérée. La fonction de fusion doit prendre en compte les règles qui peuvent être entièrement fusionnées ou partiellement fusionnées et l'ordre pour les appliquer au 10 reste de l'ensemble des règles. Cette fonction est basée sur un arbre par configuration qui permet de construire un nouvel arbre commun et ensuite la fusion des feuilles. L'ensemble restant des règles fusionné devient l'ensemble commun desrègles à appliquer. Si ce fichier de 15 configuration est visible des deux entités administratives ou visible de seulement de l'une d'elles ou d'aucune dépend de l'accord entre les sociétés. De manière à expliquer comment les règles peuvent être fusionnées, il est nécessaire de détailler comment, dans un 20 pare-feu standard, les règles de filtrage sont construites avec une même structure pour les définir qui ressemble à l'ensemble suivant de champs dans chaque règle: " Action ", " type de protocole ", " adresse de source A ", " adresse de destination B ", " numéros de port ", " options ". 25 Le contenu des champs peut être par exemple * " Action " est permettre ou refuser * " type de protocole " définit le protocole sur lequel cette règle est appliquée (i.e. IP, TCP, UDP...) * " adresse de source A " décrit l'adresse IP de la 30 source du paquet, * adresse de destination B " décrit l'adresse IP de la destination du paquet, * " numéro de port " définit le numéro de port spécifique en relation avec le protocole, 16 2002-0152 " options " définit les paramètres additionnels qui peuvent servir à créer des règles plus précises (i.e. TOS, DSCP). Dans le système pare-feu selon l'invention, les deux 5 administrateurs peuvent définir les règles de filtrage. Pour savoir quel administrateur a défini les règles, une référence implicite (TAG) est ajoutée à la règle. Cette référence est codée à l'aide de 3 bits et peut prendre 5 états différents: * 0 codé 000 indique que cette règle a été définie dans CTRL1 39, * 1 codé 001 indique que cette règle a été définie dans CTRL2 49, * 2 codé 010 indique que cette règle a été définie dans 15 CTRL1 39 et CTRL2 49 * 3 codé 011 indique que cette règle définie dans CTRL2 49 inclut la règle définie dans CTRL1 39, * 4 codé 100 indique que cette règle définie dans CTRL1 39 inclut la règle définie dans CTRL2 49 De façon à séparer les évènements induits par les actions dans un but de debugging par les blocs de contrôle CTRL1 39 et CTRL2 49 et utiliser une voie avec sécurité, un point de référence fait la correspondance entre le numéro de référence et à quel bloc de contrôle la règle se réfère: * valeur de référence = 0, alors le bloc de contrôle de référence est CTRL1 39, * valeur de référence = 1, alors le bloc de contrôle de référence est CTRL2 49, * valeur de référence = 2, alors les blocs de contrôle 30 de référence sont CTRL1 39 et CTRL2 49, * valeur de référence = 3, alors le bloc de contrôle de référence est CTRL2 49, 17 2002-0152 * valeur de référence = 4, alors le bloc de contrôle de référence est CTRL1 39. La première étape est de comparer une règle du fichier de configuration CF1 50 (définie par CTRL1 39) avec les règles 5 du fichier de configuration CF2 51 (définies par CTRL2 49) de façon à vérifier si une règle CF1 peut être fusionnée avec une règle de CF2. Lorsque le traitement d'une règle est terminé, la règle suivante de CF1 est mise dans le bloc de procédé de fusion 40. Le procédé de détermination pour identifier une fusion possible est réalisé à l'étape 52. La comparaison est faite par rapport aux champs de la règle comme mentionné ci-dessus. Les critères minimum pour fusionner deux règles sont d'avoir la même Action, le même protocole et le même numéro de port 15 s'il existe plus un recouvrement entre les adresses de source et/ou un recouvrement entre les adresses de destination. Si ces critères sont réunis, alors les règles peuvent être fusionnées et le procédé de vérification 52 transmet les règles correspondantes au procédé de vérification 53. Si un seul critère n'est pas vérifié, alors les règles ne peuvent pas être fusionnées et le procédé de vérification 52 transmet les règles au procédé de vérification 56. Le procédé 56 modifie la règle 1 et la règle 2 en ajoutant les valeurs de référence (TAG) appropriées (0 pour 25 la règle 1 et 1 pour la règle 2) et place les deux règles dans le fichier de configuration des règles 60. La règle 2 correspondante avec TAG = 0 est conservée dans le fichier CF2 51 du fait qu'elle pourrait être fusionnée avec la prochaine règle de CF1. Dans ce cas la valeur de référence dans le 30 fichier de configuration 60 peut être écrasée. Lorsqu'une fusion est possible, l'étape 53 vérifie si les deux règles (règle 1 et règle 2) sont les mêmes. Si c'est le cas, le procédé transmet seulement la règle 1 au procédé 57 qui modifie la règle 1 en ajoutant la valeur de référence 18 2002-0152 (TAG) 2 et la met dans le fichier de configuration 60. Si les règles 1 et 2 sont différentes, alors les deux règles sont transmises à l'étape 54. L'étape 54 vérifie si la règle 1 est incluse en termes 5 de source/destination dans la règle 2. Si c'est le cas, le procédé 54 transmet la règle l au procédé 58 qui modifie la règle 1 en ajoutant la valeur de référence 3 et la transmet dans le fichier de configuration 60. Si la règle 1 n'est pas incluse dans la règle 2, alors les deux règles sont transmises 10 au procédé 55. Le procédé 55 vérifie si la règle 2 est incluse en termes de source/destination dans la règle 1. Si c'est le cas, le procédé 55 transmet la règle 2 au procédé de l'étape 59 qui modifie la règle en ajoutant la valeur de référence 4 et la 15 place dans le fichier de configuration 60. Si la règle 2 n'est pas incluse dans la règle 1, alors les deux règles sont transmises au procédé de vérification 52. Ce procédé sait que les règles ont déjà été vérifiées et les transmet au procédé de l'étape 56 du fait qu'elles ne peuvent pas être fusionnées 20 de façon correcte. A noter que l'inclusion de règle est différent selon que la règle est une règle PERMETTRE ou REFUSER. * Une règle PERMETTRE A est incluse dans une autre règle permettre B si l'espace sous-réseau défini par A25 source ou destination- est plus grand que celui défini par B. La règle la plus restrictive en termes d'espace d'adressage est conservée: règle B * Une règle REFUSER A est incluse dans une autre règle refuser si l'espace sous-réseau défini par A-source ou 30 destination- est plus petit que celui défini par B. La règle la plus restrictive est conservée: règle B. Lorsque deux règles sont fusionnées, la vérification de la partie restante de la liste est arrêtée. Un procédé de fusion amélioré avec plus d'un passage est possible. Il peut 19 2002-0152 être recommandé lorsque le nombre de règles est très important. Dans ce cas, une inclusion multiple de règles peut être utilisée. Le procédé de fusion sera mieux compris avec l'exemple 5 suivant dans lequel la liste des règles CF1 et la liste des règles CF2 sont comme suit Liste CF1 - permettre TCP 172.20.0.0 192.0.0.0 23 - permettre ICMP any any - refuser IP 192.168.10.0 192.168.20.0 Liste CF2 - permettre ICMP 172. 0.0.0 192.168.00 - permettre TCP any any - permettre UDP 172.0.0.0 192.0. 0.0 La première règle CF1 est comparée à la règle 1 de CF2 - les types de protocole ne sont pas les mêmes, alors ces règles ne peuvent pas être fusionnées. La première règle CF1 est comparée à la règle 2 de CF2 - la règle 1 de CF1 est incluse dans la règle 2 de CF2, alors 20 ces règles peuvent être fusionnées. La règle 1 de CF1 est conservée. La seconde règle CF1 est comparée à la règle 1 de CF2 - la règle 1 de CF2 est incluse dans la règle 2 de CF1, alors ces règles peuvent être fusionnées. Larègle 1 de CF2 est 25 conservée. La troisième règle CF1 est comparée à la règle 1 de CF2 - les champs d'Action des règles ne sont pas les mêmes, alors ces règles ne peuvent pas être fusionnées. La troisième règle CF1 est comparée à la règle 2 de CF2 30 - les champs d'Action ne sont pas les mêmes, alors ces règles ne peuvent pas être fusionnées. La troisième règle CF1 est comparée à la règle 3 de CF2 - Les champs d'Action des deux règles ne sont pas les mêmes, alors ces règles ne peuvent pas être fusionnées. 2002-0152 Dans cet exemple, le fichier de configuration commun est comme suit après la comparaison et la fusion: - permettre TCP 172.20.0.0 192.0.0.0 permettre ICMP 172.0.0.0 192.168.0.0 - refuserIP 192.168.10.0 192.168.20. 0 - permettre UDP 172.0.0.0 192.0.0.0 21 2002-0152 Revendications 1. système pare-feu pour interconnecter un premier réseau IP (10) à un second réseau IP (16), les deux réseaux appartenant à deux entités différentes ayant chacune une administration différente dans lequel tout paquet transmis ou reçu par ledit premier réseau IP est filtré en utilisant 10 une première fonction pare-feu et tout paquet transmis ou reçu par ledit second réseau IP est filtré en utilisant une seconde fonction pare-feu; ledit système étant caractérisé en ce qu'il comprend essentiellement un seul dispositif pare-feu (20) comportant 15 des moyens de filtrage (41, 43) effectuant aussi bien ladite première fonction parefeu que ladite seconde fonction pare-feu, un port console (37) permettant à l'administrateur ayant la charge d'administrer chaque réseau IP d'entrer les règles de filtrage pour mettre à jour la 20 fonction pare- feu associée et des moyens de contrôle (39, 47, 49) interconnectant ledit port console et lesdits moyens de filtrage pour transmettre à ceux-ci lesdites règles de filtrage de manière à ce que chaque administrateur puisse gérer le système de façon indépendante à partir dudit port 25 console. 2. Système pare-feu selon la revendication 1, dans lequel lesdits moyens de filtrage comprennent une première unité de filtrage (FILTinl2 41) effectuant ladite première fonction 30 de filtrage et une seconde unité de filtrage (FILToutl2 43) effectuant ladite seconde fonction de filtrage. 3. Système pare-feu selon la revendication 2, comprenant en outre une première unité de conversion d'adresse de réseau 22 2002-0152 (NATinl 30) interconnectée entre ledit premier réseau IP (10) et ladite première unité de filtrage (41) pour changer l'adresse IP de source d'un paquet reçu à partir dudit premier réseau IP ou changer l'adresse IP de destination d'un paquet transmis audit premier réseau IP. 4. Système parefeu selon la revendication 2, comprenant en outre une seconde unité de conversion d'adresse de réseau (NAToutl2 42) interconnectée entre ledit second réseau IP 10 (16) et ladite seconde unité de filtrage (43) pour changer l'adresse IP de destination d'un paquet transmis audit second réseau IP ou changer l'adresse IP de source d'un paquet reçu à partir dudit second réseau IP. 5. Système pare-feu selon la revendication 3 ou 4, comprenant en outre au moins une passerelle IP (IPgwl 35, IPgw2 45) interconnectée entre ladite première unité de filtrage (41) et ladite seconde unité de filtrage (43) pour déterminer les règles de routage à appliquer aux paquets de données, 20 lesdites règles de routage étant fournies par au moins un point de contrôle de routage (RCP1 34, RCP2 44). 6. Système pare-feu selon la revendication 5, comprenant une première passerelle IP (IPgwl 35) associée audit premier 25 réseau IP obtenant ses règles de routage à partir d'un premier point de contrôle de routage (RCP1 34), et une seconde passerelle IP (IPgw2 45) associée audit audit second réseau IP obtenant ses règles de routage à partir d'un second point de contrôle de routage (RCP2 44). 30 7. Système pare-feu selon la revendication 5 ou 6, dans lequel lesdits moyens de contrôle comprennent une unité de contrôle commun (47) connectée audit port console (37) pour identifier l'administrateur qui entre des règles de filtrage 23 2002-0152 par ledit port console, et une première unité de contrôle (CTRL1 39) et une seconde unité de contrôle (CTRL2 49) associées respectivement à chacun desdits réseaux IP, chaque unité de contrôle gérant les règles de filtrage correspondant à son réseau IP associé. 8. Système de pare-feu selon la revendication 7, comprenant en outre une unité de fusion (40) connectée à ladite première unité de contrôle (39) et à ladite seconde unité de contrôle 10 (49) pour déterminer par comparaison si une règle entrée par un administrateur est redondante avec une des règles entrées précédemment par l'autre administrateur et fusionner les deux règles si c'est le cas. 9. Système de pare-feu selon la revendication 8, dans lequel ladite unité de fusion (40) décide de fusionner lesdites deux règles lorsque ces règles correspondent à la même action, au même protocole, au même numéro de port et lorsqu'il y a recouvrement entre les adresses de source 20 et/ou recouvrement entre les adresses de destination. 10. Système de pare-feu selon la revendication 9, dans lequel ladite unité de fusion (40) détermine si lesdites deux règles sont identiques lorsque ces règles peuvent être 25 fusionnées et si c'est le cas, transmet seulement une desdites règles à un fichier de configuration de règles commun (60) pour être utilisée comme règle de filtrage pour lesdites première et seconde fonctions de filtrage. 11. Système de pare-feu selon la revendication 10, dans lequel ladite unité de fusion (40) détermine si une desdites deux règles est incluse dans l'autre lorsque les deux règles ne sont pas identiques et si c'est le cas, transmet ladite 24 2002-0152 règle incluse audit fichier de configuration de règles commun (60). 12. Système pare-feu selon la revendication 11, dans lequel une 5 référence (TAG) est ajoutée à chaque règle avant de la transmettre audit fichier de configuration de règles commun (60), ladite référence étant utilisée pour identifier le type de règle telle qu'elle a été déterminée par ladite unité de fusion (40). 13. Système de pare-feu selon la revendication 9, 10, 11 ou 12, dans lequel ladite unité de fusion (40) continue la comparaison de ladite règle entrée par un administrateur avec la suivante desdites règles entrées précédemment par 15 l'autre administrateur seulement lorsque ladite unité de fusion (40) décide de ne pas fusionner lesdites deux règles et arrête cette comparaison dans le cas contraire. 14. Système de pare-feu selon l'un quelconque des revendications 20 1 à 12, dans lequel ledit dispositif pare-feu est divisé en un premier dispositif pare-feu (Fig. 4A) et un second dispositif pare-feu (Fig. 4B) qui sont fonctionnellement identiques pour traiter respectivement les paquets de données du chemin de données dudit premier réseau IP (10) 25 audit second réseau IP (16) et les paquets de données du chemin de données dudit second réseau IP audit premier réseau IP.