Vous êtes sur la page 1sur 88

Diplme de Recherche Technologique

prsent par Nicolas Tachker

Spcialit Informatique

Extension des fonctions dun logiciel "pare-feu"

Date de la soutenance : 29 octobre 1999 composition du jury : Roland Balter Jacques Briat Nouar Garcia Franois Xavier Le Dimet Serge Lacourte Michel Riveill Frederic Soinne

Diplme de Recherche Technologique prpar chez Bull S.A. Echirolles

Remerciements

Tout d'abord, je tiens remercier toutes les personnes de Bull, de Dyade et de l'Inria qui m'ont accueilli et assist durant ces deux annes. Je remercie plus particulirement : Roland Balter, responsable du projet Sirac Daniel Monges, responsable du service Internet et Scurit Serge Lacourte, responsable du projet AAA Frdric Soinne, responsable du projet NetWall Ainsi que tous les membres des quipes NetWall, Bronco et Gestion de Configuration pour la confiance et lintrt quils m'ont tmoign tout au long de mon contrat.

3 Table des matires


CHAPITRE 1 : INTRODUCTION ......................................................................................................................6 1.1 CONTEXTE DU PROJET .................................................................................................................................7 1.1.1 SIRAC, le laboratoire.........................................................................................................................7 1.1.2 Bull, centre de dveloppements industriels ........................................................................................7 1.1.3 Dyade, partenariat Bull - Inria ..........................................................................................................8 1.2 CONSTATS ...................................................................................................................................................8 1.2.1 Limitations actuelles de NetWall .......................................................................................................8 1.2.2 Technologie dveloppe dans Sirac ...................................................................................................9 1.3 OBJECTIFS DU TRAVAIL .............................................................................................................................10 1.3.1 Ajout dun filtre pour SQL*Net (protocole dynamique) ..................................................................10 1.3.2 Dfinition dune architecture d'ouverture pour NetWall .................................................................10 1.3.3 Intgration des fonctions d'extension par agents.............................................................................10 CHAPITRE 2 : DESCRIPTION DE LEXISTANT.........................................................................................12 2.1 NETWALL .................................................................................................................................................13 2.1.1 Description de NetWall....................................................................................................................13 2.1.2 Rsum des fonctionnalits de NetWall ...........................................................................................15 2.1.3 Limitation de NetWall ......................................................................................................................16 2.2 AAA "AGENT ANYTIME ANYWHERE " .....................................................................................................17 2.2.1 Introduction .....................................................................................................................................17 2.2.2 Architecture globale.........................................................................................................................18 2.2.3 Utilisation pour enrichir NetWall ....................................................................................................19 CHAPITRE 3 : DESCRIPTION DU TRAVAIL RALIS ............................................................................20 3.1 PRINCIPES GNRAUX DE LAPPROCHE ......................................................................................................21 3.1.1 Introduction .....................................................................................................................................21 3.1.2 SQL*Net...........................................................................................................................................21 3.1.3 Lopen framework............................................................................................................................21 3.1.4 Liens entre lopen framework et H.323............................................................................................22 3.1.5 SDK..................................................................................................................................................23 3.2 ARCHITECTURE .........................................................................................................................................24 3.2.1 NetWall ............................................................................................................................................24 3.2.2 Open framework...............................................................................................................................27 3.2.3 H.323 ...............................................................................................................................................33 3.2.4 Librairie SDK...................................................................................................................................34 3.2.5 Schma de l'architecture OFW, SDK et H.323 ................................................................................35 3.2.6 Le multi plates-formes......................................................................................................................36 3.3 RALISATION.............................................................................................................................................37 3.3.1 Protocoles dynamiques ....................................................................................................................37 3.3.2 librairie open framework .................................................................................................................46 3.3.3 AAA, H.323 et les logs .....................................................................................................................46 3.3.4 librairie SDK....................................................................................................................................47 3.4 EXPRIMENTATIONS ..................................................................................................................................47 3.4.1 SQL*Net...........................................................................................................................................49 3.4.2 Sun RPC...........................................................................................................................................49 3.4.3 OFW.................................................................................................................................................49 3.4.4 Netmeeting et Netscape confrence .................................................................................................50 3.4.5 librairie SDK et les proxies..............................................................................................................51 CHAPITRE 4 : BILAN ET PERSPECTIVES ..................................................................................................52 4.1 RAPPEL DES OBJECTIFS ET BILAN TECHNIQUE ............................................................................................53 4.2 PERSPECTIVES ...........................................................................................................................................54 4.3 BILAN PERSONNEL .....................................................................................................................................56 GLOSSAIRE ........................................................................................................................................................58 RFRENCES ....................................................................................................................................................60

4
ANNEXES ............................................................................................................................................................62 1.1 FONCTIONS COUVERTES PAR NETWALL ....................................................................................................63 1.1.1 Filtrage dynamique au niveau IP.....................................................................................................63 1.1.1 Fonctions de log et daudit. .............................................................................................................64 1.1.2 Configuration et administration via une interface graphique conviviale. .......................................64 1.1.3 Authentification des utilisateurs au niveau des relais applicatifs ....................................................64 1.1.4 Fonctions de coopration des relais applicatifs avec des produits externes dAntivirus.................65 1.1.5 Contrle distance scuris ............................................................................................................65 1.1.6 Fonction dalerte dynamique ...........................................................................................................65 1.2 AGENT ANYTIME ANYWHERE ...................................................................................................................66 1.2.1 Ralisation .......................................................................................................................................66 1.2.2 Extensions ........................................................................................................................................75 1.2.3 Outils de construction ......................................................................................................................77 1.3 CMVC ET ODE, GESTION DES SOURCES ...................................................................................................80 1.3.1 Introduction .....................................................................................................................................80 1.3.2 Gestion de la configuration de NetWall...........................................................................................80 1.3.3 Glossaire..........................................................................................................................................85 1.4 FORMATION POUR LE DRT ........................................................................................................................86 1.4.1 Description des enseignements slectionns en 1997-1998.............................................................86 1.4.2 Description des enseignements slectionns en 1998-1999.............................................................87 1.4.3 Formation suivie chez Bull ..............................................................................................................88

Durant la dernire dcennie, le rseau informatique mondial Internet a connu une croissance exponentielle. En effet il permet d'changer de trs grande quantit d'informations dans des dlais extrmement cours, ce qui permet, notamment, d'augmenter la productivit des entreprises. Cependant, le raccordement de ces dernires au rseau mondiale ainsi que le caractre confidentiel des informations qu'elles envoient, ncessite de dvelopper des logiciels nouveaux permettant d'assurer une protection vis--vis du piratage ou de la malveillance. L'ensemble de ces logiciels constituent le domaine de la Scurit Informatique. Afin de rpondre l'attente de ses clients, la socit Bull a dvelopp le pare-feu NetWall partir de 1995. C'est dans le cadre de ce projet que j'ai effectu mon Diplme de Recherche Technologique du 3 novembre 1997 au 2 novembre 1999, au sein de l'quipe Internet et Scurit de la socit Bull Echirolles. L'objectif de ce rapport est donc de prsenter l'environnement de travail et l'existant lors de mon arrive dans l'quipe, d'expliquer les motivations et les enjeux de la collaboration entre Bull et l'Inria et de dcrire le travail ralis et l'exprience que cette formation m'a permis d'acqurir.

Chapitre 1 : INTRODUCTION

Introduction

Ce chapitre prsente le contexte structurel et scientifique du projet. Dans un premier temps, nous donnons une brve prsentation du laboratoire et de l'entreprise qui ont servi de cadre ce travail. Dans un deuxime temps, nous dcrivons la problmatique scientifique qui a conduit ce travail. Les limitations actuelles sur le logiciel de pare-feu NetWall sont d'abord exposes. Mon travail a port sur la conception et la ralisation d'extensions ce logiciel pour lever ces limitations. La technologie ncessaire ces extensions a t dveloppe en partie au sein de l'quipe NetWall et en partie par une opration de transfert technologique depuis le laboratoire Sirac.

1.1

Contexte du projet

1.1.1 SIRAC, le laboratoire


SIRAC (Systmes Informatiques Rpartis pour Applications Coopratives) est un laboratoire commun l'Universit Joseph Fourier, l'Institut National Polytechnique de Grenoble, et l'Institut National de Recherche en Informatique et Automatique (Unit de Recherche Rhne-Alpes). Le laboratoire comprend une trentaine de chercheurs, dont neuf permanents (chercheurs de l'INRIA et enseignants-chercheurs de l'universit), une dizaine de doctorants et des ingnieurs contractuels. Le laboratoire mne depuis plusieurs annes des recherches dans le domaine des systmes et applications rpartis. Il entretient de longue date une tradition de partenariat troit avec des industriels, en particulier avec le Groupe Bull. Lobjectif gnral du laboratoire SIRAC est de concevoir et raliser des services et outils pour le dveloppement et lexcution dapplications rparties. A cet effet, le laboratoire dveloppe des technologies rpondant deux besoins : a) construire des applications rparties en combinant des techniques de programmation base dobjets et des techniques de programmation par agents ; b) faciliter la configuration, le dploiement, ladministration et lvolution de ces applications sur des plates-formes dusage courant. Le travail de DRT prsent ici s'inscrit dans ce programme de recherche et vise transfrer des rsultats du laboratoire vers le groupe Bull.

1.1.2 Bull, centre de dveloppements industriels


L'quipe NetWall fait partie de la division Bull Soft et est intgre dans le dpartement AccessMaster. AccessMaster est un progiciel qui permet d'instaurer une politique de scurit centralise et homogne de l'ensemble des systmes d'information distribus et htrognes de l'entreprise ainsi que des accs aux rseaux de tlcommunications externes et l'Internet. L'administrateur peut grer le rseau global Internet/Intranet de l'entreprise depuis un point de contrle unique. Cette capacit repose sur la gestion centralise des utilisateurs. Ceux-ci disposent, en effet, d'un mot de passe unique (single sign-on) qui leur permet d'accder de faon transparente toutes les applications auxquelles ladministrateur leur donne accs. Le logiciel NetWall, qui fait partie de la suite AccessMaster, est un pare-feu TCP/IP. Un pare-feu est un composant (matriel et/ou logiciel) utilis dans un environnement de rseau pour protger une machine sensible ou un rseau. En outre, il contrle l'accs entrant et sortant de ce rseau par le biais de mcanismes de filtrage du trafic TCP/IP. NetWall comprend la fois des capacits de filtrage IP dynamique et un ensemble de passerelles applicatives permettant aux responsables de la scurit ou aux administrateurs de contrler les accs entre leurs rseaux privs et Internet, d'isoler les sous-rseaux internes et de protger les serveurs sensibles. De plus, NetWall prend en charge toutes les mthodes d'authentification standards.

Introduction

Un antivirus associ NetWall renforce la scurit des rseaux locaux et des postes de travail.

1.1.3 Dyade, partenariat Bull - Inria


Le partenariat stratgique entre Bull et l'Inria est organis sous la forme d'un Groupement d'Intrt conomique (GIE) d'une dure de cinq ans, partir du 1er avril 1996. La vocation de Dyade est de concevoir et de dvelopper de nouveaux composants technologiques pour les futurs systmes d'information. Dyade a pour origine une vision commune, entre Bull et l'Inria, de la nouvelle dimension des technologies de la communication et du traitement de l'information. Les objectifs de Dyade sont de conjuguer l'expertise en recherche amont de l'Inria et la capacit industrielle de Bull ; de dfinir et exploiter de nouvelles filires technologiques rpondant aux besoins des systmes d'information et d'intermdiation. Dyade doit pour cela identifier les domaines d'action fort potentiel innovant, dmontrer la maturit et l'intrt des technologies dveloppes avec des utilisateurs pilotes, transfrer et valoriser les rsultats dans les units oprationnelles de Bull et dans les filiales ou "start-up" de Bull ou de l'Inria. Bull peut ainsi renforcer son portefeuille technologique et accder un march fort potentiel de croissance. L'Inria peut valider et valoriser ses rsultats et identifier de nouveaux axes de recherche stratgiques pour l'industrie franaise.

1.2

Constats

1.2.1 Limitations actuelles de NetWall


1.2.1.1 Filtre sur des protocoles dynamiques complexes

Les protocoles de la couche TCP ou UDP se rpartissent en deux catgories. Dune part, les protocoles simples qui utilisent une seule connexion pour assurer la communication entre le client et le serveur. Cette connexion s'tablit entre un port fixe du serveur (associ au service TCP ou UDP considr) et un port que le client s'alloue dynamiquement. Dautre part, les protocoles dynamiques qui, partir dune premire connexion entre un port fixe du serveur et un port dynamique du client, en ouvrent dautres aprs change des valeurs des ports associes ces connexions. Par consquent, filtrer des protocoles dynamiques complexes peut tre trs compliqu, voir impossible avec l'architecture actuelle de NetWall. Nous avons pu le constater pour SQL*Net et H.323 (vido confrence sur Internet). Pour le protocole SQL*Net, nous avons pu ajouter le filtre au niveau du driver de NetWall, mais nous imposons certaines restrictions sur l'utilisation de ce protocole, comme par exemple l'impossibilit de filtrer des donnes cryptes, de plus le "listener" (dmon dcoute du protocole SQL*Net) doit tre le serveur de donnes, etc. Pour le protocole H.323, le problme est plus compliqu, car les donnes changes sont codes en ASN.1. Les machines utilisant ce protocole changent des numros de ports allous dynamiquement afin douvrir des connexions permettant le transfert des donnes, par exemple de type audio et vido. Or, tout comme dans le noyau des systmes dexploitation, il n'est pas possible de dcoder de l'ASN.1 dans le driver de NetWall ce qui permettrait de trouver les numros de port allous dynamiquement. Pour rsoudre ce problme, il faut alors filtrer H.323 au niveau applicatif cest--dire drouter la totalit du trafic dans lespace utilisateur. Une telle solution rend le protocole inexploitable du fait du trop faible dbit du son et de limage.

Introduction

Par consquent, il faut analyser les connexions de contrle (celles sur lesquelles transitent les numros de ports dynamiques) dans l'espace utilisateur et laisser passer les donnes (sons et images) sans les drouter mais l'architecture de NetWall ne le permet pas sans certaines amliorations.

1.2.1.2

Gestion des logs

NetWall fournit plusieurs fichiers de logs : un pour les traces du driver de NetWall, un pour les proxies, un pour le dmon d'administration, etc. De plus, les formats d'criture dans ces fichiers de logs sont diffrents. Il est donc difficile de regrouper lensemble des traces associes une connexion, surtout s'il y a un droutement proxy, car il faut mettre en relation plusieurs fichiers de logs qui contiennent des verbes diffrents. Ces problmes ne seraient pas trs gnants si les fichiers de logs ne faisaient que quelques dizaines de lignes. Or ce n'est pas le cas, NetWall fournit un volume moyen de logs d'environ 200 Mo par jour. Bien sr ce chiffre dpend de la frquentation sur les serveurs protgs par NetWall mais aussi du niveau de logs fix par l'administrateur. Nous voyons bien que l'exploitation des fichiers de log, pour un administrateur en charge de la scurit, est difficile et fastidieuse sans outils et sans harmonisation des fichiers de logs.

1.2.2 Technologie dveloppe dans Sirac


L'action Dyade AAA (Agents Anytime Anywhere) vise fournir des outils et des services pour faciliter l'extension d'applications existantes, soit par enrichissement des fonctions de l'application cible (par exemple pour dfinir des filtres la demande pour une application de pare-feu), soit par interconnexion d'applications existantes (par exemple pour la mise en coopration d'applications interactives mono utilisateur). L'approche suivie s'appuie sur une technologie agents. Un agent est une unit d'excution autonome mono-localise qui communique avec l'extrieur par un mcanisme vnement-raction. Le comportement d'un agent est dcrit par une classe Java qui hrite d'une classe prdfinie. L'intgration d'applications existantes est ralise par des agents d'interfaage (wrappers). La spcificit de AAA rsulte des proprits de l'environnement d'excution des agents : communication asynchrone par messages typs, garantie de dlivrance des messages, ordre causal de dlivrance des messages, persistance des agents et atomicit de la raction excute l'arrive d'un message. Cet environnement d'excution est lui-mme ralis en Java, ce qui assure sa portabilit. Il est utilis dans deux domaines applicatifs : le pare-feu (NetWall) et l'administration de systmes (ISM/Open-Master). La contribution du projet Sirac l'action AAA concerne les outils et services pour la configuration et la reconfiguration des agents. Ces outils facilitent la rutilisation des agents, leur personnalisation et leur intgration au sein d'une application. Ils permettent de faire voluer une application en fonction des besoins, en apportant une perturbation minimale son fonctionnement. Une application relle (la gestion du fichier journal (log) cr par NetWall) a mis en vidence la puissance d'expression et la souplesse d'utilisation des outils de configuration dvelopps dans AAA.

Le systme AAA ainsi que les outils et les services de configuration et reconfiguration dvelopps par Sirac sont crits en Java et sont donc disponibles sur toute plate-forme supportant une machine virtuelle Java. Pour information, l'outil graphique de configuration reprsente environ 30 000 lignes de code Java et le systme AAA, tendu avec les services de configuration et de reconfiguration, reprsente environ 40 000 lignes de code Java.

Introduction

10

1.3

Objectifs du travail

L'objectif global de mon travail a t de trouver et de mettre en uvre des solutions techniques pour apporter des solutions aux problmes qui viennent d'tre prsents. Trois types d'action ont t plus particulirement ralises pour atteindre cet objectif : la mise en uvre de protocole dynamiques ; la dfinition d'une architecture ouverte pour NetWall afin de permettre plus aisment l'intgration de nouvelles fonctions ; l'intgration d'un environnement agents, dvelopp au sein du GIE Dyade, qui permet de dfinir la demande de nouvelles fonctions de traitement des informations enregistres par le pare-feu. Ces points sont brivement introduits ci-dessous et prsents plus en dtail dans la suite du document.

1.3.1 Ajout dun filtre pour SQL*Net (protocole dynamique)


Une forte demande des utilisateurs de NetWall tait le filtrage de SQL*Net. L'ajout d'un filtre pour SQL*Net dans le driver de NetWall tait un des objectifs premiers de mon DRT. SQL*Net est un nom gnrique dsignant lensemble des couches ncessaires la communication entre clients et serveurs Oracle. Ce protocole passe notamment au travers des couches TCP et IP. Il utilise des adresses IP et des ports de communication pour se connecter aux serveurs de donnes. La difficult de ce protocole est qu'il change des numros ports de communication durant la phase d'initialisation de la connexion. Ces ports sont appels ports dynamiques. NetWall a besoin de prparer une liste de contrles d'accs autorisant le passage de la connexion. Il est donc obligatoire de trouver et de stocker la valeur du port dynamique pour autoriser le passage des donnes.

1.3.2 Dfinition dune architecture d'ouverture pour NetWall


Lobjectif du travail est de dfinir une architecture douverture pour NetWall, ou plutt dtendre larchitecture actuelle du pare-feu. Ce travail permet lajout de fonctionnalits comme laudit, la dtection dintrusion et la mise en uvre de contre mesures mais aussi de dfinir et d'implmenter une infrastructure dintgration ouverte et extensible base sur la technologie agents pour des applications tierces telles que des solutions spcifiques de contrle et de filtrage. Lobjectif est dassurer ainsi lvolutivit de NetWall en vue du support de nouveaux protocoles tels que laudio et la vido sur Internet.

1.3.3 Intgration des fonctions d'extension par agents


Une plate-forme agents a t ralise par l'quipe AAA de Dyade et permet l'change de messages de faon asynchrone entres applications. Un dbouch industriel possible l'utilisation des agents AAA est une application de traitement des logs. Les agents reoivent de faon asynchrone les notifications d'alarmes des diffrents quipements du rseau et filtrent les informations. Les machines base dagents sont capables danalyser de nouveaux protocoles tels que laudio et la vido sur Internet ou tout autre protocole. Elles peuvent ragir des demandes douverture de connexion et se charger de la dtection des ports dynamiques. Cette technologie base dagents intresse lindustrie. Ainsi, un des objectifs du travail est de raliser un transfert de technologie entre lInria et Bull. Ce transfert comprend lintgration dans NetWall du dveloppement effectu par laction AAA.

Introduction

11

Prsentation de la structure du document.

Le chapitre II est une description de l'existant, prsente en deux tapes : le produit NetWall qui constitue le contexte applicatif de l'tude d'une part, et la plate-forme agents AAA qui constitue le support technologique issu du laboratoire d'autre part. Le chapitre III dtaille le travail ralis dans le DRT. Dans un premier temps les principes gnraux de l'approche suivie sont prsents. Puis est dcrite l'architecture de la solution retenue pour tendre les fonctions du logiciel NetWall. Ensuite sont exposs quelques lments sur la mise en uvre de cette architecture et sur les exprimentations qui ont t ralises. Le chapitre IV dresse un bilan du travail ralis et propose quelques perspectives d'extensions pour le court terme.

12

Chapitre 2 : DESCRIPTION DE LEXISTANT

Description de lexistant

13

2.1

NetWall

2.1.1 Description de NetWall


Par dfinition, NetWall, plus gnralement un garde-barrire (passerelle de scurit) ne peut protger que le trafic qui le traverse. Cela signifie par exemple que : - NetWall ne peut pas protger les accs entre deux machines situes sur un mme rseau, si ces accs ne se font pas au travers de NetWall. NetWall ne peut pas protger un rseau vis vis des autres rseaux, sil existe des chemins daccs ne passant pas par NetWall. - NetWall ne peut protger laccs aux biens que par les services rseaux quil contrle et dans la limite des contrles effectus sur ces services. Laccs ces serveurs, effectu par les services rseaux prvus et au travers du garde-barrire est garanti, sil est ralis dans le respect de la politique de scurit dfinie par ladministrateur.

2.1.1.1

Quest-ce quun garde-barrire ?

Un garde-barrire est un logiciel, qui install sur une machine lentre dun rseau dentreprise ou dun sous-rseau local, permet dassurer sa scurit en le protgeant de toute attaque ou tentative dintrusion. Il a pour rle de filtrer les accs en provenance de lextrieur. Il est l pour protger les donnes sensibles et les services du rseau local.

garde-barrire

INTERNET

Zone Sous-Rseau sensible

Rseau dentreprise protger

Description de lexistant

14

Il y a deux approches principales dans la ralisation du garde-barrire pour combattre les intrusions dans un rseau TCP/IP : - Le filtrage IP - Les passerelles applicatives (Applications proxies)

Le filtrage IP : Chaque paquet essayant de traverser la couche IP est compar avec une liste de contrle daccs. Cette liste de rgles est utilise pour dterminer si le paquet est autoris traverser ou non. Ces rgles sont bases sur les adresses sources et destinations contenues dans les paquets et les interfaces rseaux sur lesquelles ils arrivent (internes, externes ou zone dmilitarise (DMZ)). Le mcanisme de filtrage est implment dans le noyau (kernel).

Application (ftp, telnet, ...) 86(5 .(51(/ TCP filtrage IP IP Rseau

Rseau

Les passerelles applicatives (proxies) : Un dmon proxie est implment sur la passerelle pour chaque service TCP/IP support. Les proxies sont implments dans lespace utilisateur. Un utilisateur extrieur, dsirant se connecter un serveur interne pour un service donn (smtp, http, ftp...), se connecte dabord au proxy auprs duquel, ventuellement, il sauthentifie, avant de se connecter au serveur destination. Tout le trafic doit passer au travers du proxy, qui procde aux vrifications et aux filtrages bass sur les commandes spcifiques du service.

Proxy Client

Serveur

Rseau externe Garde-Barrire

Rseau interne

Description de lexistant

15

NetWall combine ces deux approches : filtrage IP et passerelles applicatives. Il est constitu des composants logiciels suivants.

2.1.1.2

Le composant de filtrage IP dynamique

Ce composant se divise en 2 parties : - un module de filtrage (driver), implant dans le noyau des systmes dexploitation, est charg du traitement des paquets en fonction des rgles de filtrage. Ce driver est un driver chargeable, utilisant la notion dextension noyau. Il est intgr dynamiquement au noyau du systme dexploitation, en drivation des couches TCP/IP du systme. Il permet dintercepter les paquets IP avant leur entre dans les couches TCP/IP. - un processus dmon, dans lespace utilisateur du systme dexploitation, en liaison avec le driver ci-dessus, est charg de transmettre ce dernier les rgles de filtrage telles que dfinies par ladministrateur, ainsi que de recevoir du driver les informations relatives la scurit pour les enregistrer.

2.1.1.3

Un ensemble de relais applicatifs (proxy)

Lensemble de ces logiciels est implant dans lespace utilisateur du systme dexploitation. Ils reoivent la connexion issue de la machine cliente et, aprs contrle, ouvrent une nouvelle connexion destination de la machine serveur.

2.1.1.4

Linterface Graphique dadministration et de configuration

Cest un composant situ au-dessus des autres composants du logiciel NetWall. Il contrle le composant de filtrage IP dynamique et les relais applicatifs, pour ce qui concerne la configuration des rgles de filtrage, le dmarrage et larrt, la configuration et lexploitation des informations enregistres relatives la scurit.

2.1.2 Rsum des fonctionnalits de NetWall


NetWall est un logiciel garde-barrire (firewall), permettant une protection aussi bien face Internet qu Intranet. Il permet de raliser un cloisonnement des rseaux et de dfinir quelles machines peuvent accder quelles machines et pour quels services. Il peut traiter les services au-dessus des protocoles TCP et UDP, le protocole ICMP, et tout protocole au-dessus de IP. Il combine une technologie de filtrage IP dynamique de haut niveau, implmentant une gestion du contexte de ltat des connexions TCP et pseudo connections UDP, et un ensemble de relais applicatifs, permettant une authentification des utilisateurs et des filtrages internes aux applications. Une technologie de translation dadresses, statique et/ou dynamique permet le masquage des adresses des rseaux protgs vis--vis de lextrieur. NetWall offre galement des fonctions daudit et dalertes compltes et ergonomiques. Il peut tre utilis en conjonction avec dautres produits de scurit de Bull, tels que - SecurWare VPN pour raliser des fonctions de chiffrement et de rseaux virtuels privs, - lauthentification des utilisateurs distants par cartes puce (CP8), - ISM/AccessMaster pour une gestion centralise des utilisateurs (authentification et privilges) et la possibilit dauthentification unique ("Single Sign On").

Description de lexistant

16

Grce son infrastructure de relais transparents, NetWall permet un utilisateur sur un poste client dadresser directement le serveur final, sans connatre ladresse du garde-barrire. Ltape classique de double identification/authentification, auprs du garde-barrire et auprs du serveur final, peut tre effectue en une seule fois avec NetWall. En effet, une syntaxe particulire, reconnue par les relais applicatifs, permet lutilisateur de saisir les donnes didentification et dauthentification, en une seule fois. Ces donnes seront transmises au serveur final.

2.1.3 Limitation de NetWall


Chargement dynamique de la politique de scurit impossible Ladministrateur de NetWall dfinit une politique de scurit. Il peut autoriser des connexions entre des machines, des groupes de machines, des rseaux, des sous rseaux et il doit dfinir un service et une action pour ces diffrentes connexions. Le service se prsente sous la forme dun numro de port. Une fois quil a dfini toutes ses rgles, qui sont de type rgle n machine A vers Machine B port XX ACTION Log il peut dmarrer NetWall. En fait, il dmarre le dmon netwalld qui se charge de transfrer les rgles au driver de NetWall. Le driver quand lui est charg chaque boot. Quand le dmon nest pas en marche, il applique une rgle par dfaut. Cette rgle est : soit je rejte tous les paquets IP, soit je les accepte tous. Si ladministrateur dcide de rajouter une rgle pour autoriser ponctuellement le passage dune connexion, il doit ajouter cette rgle en utilisant linterface graphique, puis arrter le dmon netwalld et le redmarrer. Nous voyons dans ce cas l que lon va appliquer la politique de scurit dfini lorsque le dmon ne marche pas. Il faut savoir que la dure du dmarrage de NetWall est proportionnelle aux nombres de rgles, plus il y a de rgles plus le dmarrage est lent, surtout sur les plates-formes AIX et Solaris. Ceci nous montre une limitation de NetWall, nous ne pouvons pas ajouter des rgles de filtrage de manire dynamique (en fonctionnement de NetWall), il faut obligatoirement passer par une phase darrt de NetWall. Gestion des ports dynamiques Lorsquun client se sert dune application spcifique pour dialoguer entre plusieurs entits de sa socit, il veut scuriser ses connexions en installant un pare-feu. Il peut se retrouver bloqu car son application spcifique ngocie des ports dynamiques comme le fait ftp, SQL*Net, rpc, La seule faon quil a de traverser le pare-feu est dautoriser le passage de tous les services, donc tous les ports entre ces deux machines client et serveur. Mais cette solution nest pas trs scurise. En fait nous nous rendons vite compte de la limitation quimplique lutilisation dun pare-feu avec des applications dialoguant avec des ports dynamiques. NetWall gre plusieurs services qui utilisent des ports dynamiques, mais il ne les gre pas tous. Nous voyons que les fabricants de pare-feu salignent en proposant des produits filtrants les services les plus couramment utiliss. Pourtant dans le cas de certains protocoles, la scurit est trs dure raliser, car nous ne pouvons pas toujours extraire les numros de port dynamique. Dans certaines applications, les donnes sont encodes et le dcodage nest pas toujours possible dans le driver de NetWall. Nous pouvons citer comme exemple netmeeting qui utilise le protocole H.323. La solution ce problme est daccepter douvrir son pare-feu, cest dire de laisser passer tous les ports, mais dans ce cas le pare-feu nest pas trs utile. Une autre solution est de drouter tout le trafic et de le faire passer travers un proxy qui se chargera de rsoudre les problmes de port. Mais les connexions deviennent trs lentes et peuvent ne pas fonctionner (ex : netmeeting). Enfin nous observons un problme supplmentaire, savoir que le droutement proxy nest pas transparent, cest dire que la connexion se fait entre la machine cliente et NetWall puis NetWall et la machine serveur.

Description de lexistant

17

Gestion des logs Il existe un manque de clart et de prcision dans linformation se trouvant dans les fichiers de log de NetWall. En effet, nous prenons des traces au niveau du driver et au niveau des proxies et nous les stockons dans des fichiers de log. Or, il nest pas vident de mettre en relation les logs provenant du driver et les logs provenant des proxies, car les informations contenues dans ces fichiers ne sont pas suffisamment corrles. Ainsi, dans le driver nous navons pas dinformation sur les utilisateurs et dans les proxies nous navons pas dinformation sur les adresses IP (translates ou relles), les ports rels etc... Les informations de ce type sont rcupres par les proxies laide des sockets donc aprs translation. Exemple : dans les traces driver nous pouvons avoir A vers B ouverture de connexion et tout de suite derrire A vers B fermeture de connexion. Nous navons pas vu que lutilisateur Durand na pas le droit de se connecter au serveur B. Alors que dans les traces provenant du proxy nous avons A vers N (NetWall) utilisateur Durant rejet. Donc pour suivre une connexion il serait utile davoir accs la mme information. Au niveau du driver, il faut connatre toutes les informations des proxies, et au niveau des proxies il faut connatre toutes les informations sur la connexion vu par le driver. Dans ce cas, les traces, et donc les fichiers de log, seraient dune trs grande prcision, ils seraient alors entirement corrls et donc trs faciles a exploiter. Ractivit contre des attaques NetWall n'est pas capable de ragir aux attaques en modifiant de manire dynamique ses actions de protections. Pour palier a cette limitation, des agents spcifiques de Dyade seraient implants et ils seraient capables de traiter et danalyser, les logs et les alertes remontes par le dmon de NetWall. Ces agents pouraient centraliser les informations provenant de plusieurs NetWall, il serait par consquent possible de dtecter des attaques qui passeraient inaperues sur chaque NetWall. Dans ltat actuel, pour enrailler une attaque, il faut modifier ou ajouter des rgles en utilisant linterface graphique de NetWall, puis arrter le dmon et le redmarrer. De plus, il faut dployer cette modification sur tous les NetWall, alors que les agents pourraient crer des rgles de rejet ou de redirection vers des machines leurres, et ce, en fonctionnement de NetWall. Une autre ide serait dobserver et de loguer, de faon ponctuelle et beaucoup plus prcise, le trafic dune rgle donne. Ces traces seraient prises ponctuellement pour ne pas saturer les log. A lheure actuelle, il nest pas possible de changer une action associe une rgle, sans modifier les rgles dfinies dans linterface graphique. De mme nous avons vu quil faut arrter et redmarrer le dmon pour que le changement soit pris en compte.

2.2

AAA "Agent Anytime Anywhere "

2.2.1 Introduction
Les agents sont des objets "ractifs" qui se comportent conformment au modle "vnement raction" : un vnement est une transition d'tat significative laquelle un ou plusieurs agents vont ragir.

Description de lexistant

18

Agent Agent SendTo React

Channel

Modle de base
Dans notre modle, un vnement est reprsent par une notification ; une notification est un objet passif qui est signal l'agent destinataire afin qu'il excute la raction approprie. L'envoi de notifications reprsente le seul moyen de communication entre agents ; les notifications transitent entre agents via un bus de message.

2.2.2 Architecture globale


2.2.2.1 Principes de ralisation

Un agent est un objet passif, instance d'une classe qui hrite de la classe Agent ; la classe Agent dfinit le comportement commun tous les agents. Le comportement ractif est mis en uvre au moyen de la mthode react qui dfinit le comportement de l'agent lors de la rception d'une notification ; cette mthode est appele par le moteur d'excution. Chaque classe d'agents est, en particulier, caractrise par l'ensemble des ractions qu'elle traite dans la mthode react. Les agents sont des objets persistants : les donnes qui composent leur tat ont une dure de vie indpendante de toute excution. L'architecture distribue est compose d'un ensemble de serveurs d'agents rpartis sur diffrents sites ; chaque agent est attach un moteur d'excution, les seules entits mobiles sont les notifications. Chaque agent est dsign par un identificateur unique qui permet sa localisation. Les notifications sont des objets passifs organiss comme une hirarchie de classes dont la racine est la classe notification. L'interface du bus de message est ralise par la classe Channel, cette classe dfinit la mthode sendTo qui permet l'envoi d'une notification un agent dsign par son identificateur. Les notifications sont alors achemines vers une file de messages o elles sont stockes dans l'ordre chronologique ; le bus de message a la responsabilit de la localisation de l'agent destinataire.

2.2.2.2

Caractristiques du bus de message

Dans un premier temps l'envoi d'une notification est une opration "point point", l'metteur prcisant le ou les destinataires. Le bus de message assure les proprits suivantes : - toute notification accepte sera dlivre une fois et une seule chaque destinataire ; - l'ordre de rception des notifications entre 2 agents est conforme l'ordre causal d'mission : - si un agent A met successivement les notifications n1 et n2, alors aucun agent ne recevra n2 avant n1 ; - si un agent A1 met une notification n1, et qu'un agent A2 aprs avoir reu n1 met une notification n2, alors aucun agent ne recevra n2 avant n1. L'excution des ractions est ralise au moyen d'un moniteur transactionnel : soit l'ensemble des actions d'une raction (Constitu des notifications envoyes et des changements de l'tat de l'agent) est valid, soit l'ensemble de ces actions est dfait.

Description de lexistant

19

La ralisation, l'extension et la construction des agents sont dtailles en annexe.

2.2.3 Utilisation pour enrichir NetWall


Nous pouvons enrichir NetWall en nous appuyant sur un dveloppement fait par laction AAA. En utilisant la technologie base dagents et les librairies fournies par NetWall, nous sommes capables de rpondre aux difficults qua NetWall de filtrer un protocole comme H.323. AAA pourrait concevoir une librairie (en java) sappuyant sur les librairies de NetWall et ainsi fournir des outils qui faciliteraient le dveloppement dun intgrateur pour lajout de protocole dynamique. Loutil de configuration base dagents permet un administrateur non initi, de crer son application de gestion de log. Il peut transfrer ses connaissances et son exprience dans le domaine de lanalyse et de lexploitation des logs, en utilisant une interface qui est fournie par AAA. Il peut ainsi directement extraire les informations qui lui semblent pertinentes. Il na plus besoin de faire un pr traitement des fichiers de log de NetWall avant lexploitation des rsultats.

20

Chapitre 3 : DESCRIPTION DU TRAVAIL REALISE

Description du travail ralis

21

3.1

Principes gnraux de l'approche

3.1.1 Introduction
Ds mon arrive dans le projet NetWall, il a fallut me familiariser avec le driver et regarder larchitecture de NetWall. Jai commenc par lire le code ralis pour le filtrage du service ftp. Ceci ma permis de voir la difficult dune telle implmentation. La meilleure faon dapprhender NetWall tait de coder le filtre pour SQL*Net. Jai donc commenc lanalyse de ce service qui communique en utilisant des ports dynamiques. Lors du dveloppement, jai pu constater la difficult dajouter un filtre o les connexions sont assez complexes. Dautres complications peuvent rsulter de la dfinition des services que lon trouve dans des RFC qui peuvent tre assez ouvertes, cest dire que linterprtation qui peut en tre faite peut diffrer suivant les personnes. De plus, les versions des services peuvent voluer et rendre lutilisation des filtres de NetWall incompatible avec ces nouvelles versions, ceci engendre un cot de dveloppement pour se raligner, nous lavons vu pour le service des sun-RPC. Pour ouvrir larchitecture de NetWall et rpondre aux limitations, par exemple, limpossibilit de filtrer dans le driver certains services comme H.323, il a t ncessaire de dvelopper une librairie permetant un dialogue (interrogation sur des connexions, actions de cration et de destruction de cache, ) entre lespace utilisateur et le driver. De plus une extension de NetWall a t indispensable pour permettre une prise de log cohrente entre le driver et les proxies. Cette extension est fournie sous forme de librairie. Elle permet entre autre, de grer les utilisateurs dans le driver.

3.1.2 SQL*Net
L'ajout du filtre pour SQL*Net ne demande pas de modification de l'architecture de NetWall. L'approche a t relativement simple puisqu'il suffisait de s'inspirer du dveloppement fait pour le filtre de ftp. En effet l'analyse du protocole SQL*Net a mis en vidence un change de port dynamique entre le client et le serveur. Le paquet contenant ce port dynamique est facilement reprable car il contient le mot "PORT", c'est le mme mot que pour ftp. La description complte du travail ralis pour l'ajout du filtre de SQL*Net est dtaille dans un chapitre suivant.

3.1.3 Lopen framework


3.1.3.1 Fonctionnement dynamique de NetWall

Nous avons vu dans les chapitres prcdents que le fonctionnement dynamique de NetWall n'tait pas possible sans une modification de son architecture. Or, nous voulons obtenir des informations sur certaines connexions, et agir sur les rgles de filtrage en autorisant ou rejetant les connexions. Cependant, une forte interaction avec NetWall est ncessaire car toutes ces actions doivent tre faites pendant sont fonctionnement. Ainsi, il n'est pas possible d'arrter NetWall pour autoriser le passage de certains ports dynamiques en ajoutant des rgles leurs autorisant le passage. Car les numros de ports dynamiques, qui peuvent tre lus dans les fichiers de log produits par NetWall, sont en effet dynamiques et peuvent changer chaque connexion. Le fait d'arrter NetWall coupe les connexions. Dans le domaine de la gestion des logs, il est intressant de pouvoir modifier la prcision des logs pour certaines connexions qui attirent notre attention, et ce bien sr sans arrter le filtrage.

Description du travail ralis

22

L'approche qui a t choisie est de rajouter un point d'entre dans le driver de NetWall, ainsi nous pouvons lui passer des commandes sans arrter le filtrage. Ces actions peuvent tre excutes par des services, dmons ou tout autre programme s'appuyant sur la librairie d'open framework de NetWall.

3.1.3.2

Manipulation d'entres caches en fonctionnement

Le cache de NetWall est constitu de listes dentres caches. Des dcisions trs rapides peuvent tre prises grce ces entres caches. Car lorsquelles ont t cres pour une connexion, nous pouvons appliquer tous les paquets les actions qui ont t dcides lors de louverture de cette connexion. Pour rpondre aux limitations de NetWall, il est ncessaire de disposer doutils permettant la manipulation dentres caches. Nous avons besoin des oprations suivantes : cration, destruction, recherche et prise d'informations sur une connexion. La destruction dentres caches est limite au seul crateur de celles-ci. Ainsi, un accs est autoris en lecture seule, sur toutes les entres caches du driver. Cela permet dviter dventuelle maladresse au cours dune destruction dentre cache. Par consquent, nous sommes sr que lextension de NetWall, grce aux manipulations dentres caches, ne perturbera pas le bon fonctionnement du driver. Pour la ralisation, nous avons opt pour une paire d'identificateurs, l'un provenant du driver et l'autre provenant de l'application s'excutant dans l'espace utilisateur. Pour le traitement et les changes entre les dmons, services, etc... et le driver, nous devons crer une nouvelle structure "VCACHE" qui est indpendante de la structure "entre cache". Cette structure "VCACHE", nous permet de fournir des informations trs compltes sur une connexion. Nous fournissons plus d'information que ce que l'on peut obtenir d'une socket. En effet, par exemple les adresses IP dans les diffrents domaines du NetWall, ne sont connues que du driver. Grce la librairie de l'open framework ces informations peuvent tre utilises par les programmes s'excutant dans l'espace utilisateur. Il faut savoir que ces informations sont indispensables pour la rouverture des connexions. La librairie "ofw" permet d'occulter les diffrentes crations d'entres caches, effectivement elles peuvent tre de type statique ou dynamique suivant la prsence d'un joker la place d'un numro de port.

3.1.3.3

Droutement d'une partie d'une connexion

En s'appuyant sur les proprits de NetWall, le fonctionnement dynamique de NetWall et la manipulation d'entres caches, il devient possible de drouter une partie des connexions de faon transparente. C'est dire que le serveur et le client ne connaissent pas la prsence de NetWall. Nous pouvons drouter le flux dit de contrle et laisser passer les donnes. Nous avons donc tous les lments pour filtrer des nouveaux protocoles dynamiques comme H.323. Les taux de transfert sont alors optimiss, et les difficults dues au protocole TCP/IP sont alors cartes car dans l'espace utilisateur nous sommes au dessus de la couche TCP.

3.1.4 Liens entre lopen framework et H.323


3.1.4.1 Plugin H.323 de AAA

Le dveloppement du plugin H.323 est fait par l'quipe de AAA. Le dveloppement est ralis en java de mme que l'architecture des agents sur laquelle ce plugin est bas. Pour fonctionner, le plugin s'appuie sur une librairie dynamique (lib_ofw) fournie par NetWall. Cette librairie procure tous les outils de manipulation des entres caches. L'ide gnrale du dploiement et du dclenchement du plugin est la suivante. Pour le dploiement, le plugin doit tre mis en route chaque dmarrage de NetWall de manire automatique. Il doit tre dmarr comme un proxy ou service de NetWall.

Description du travail ralis

23

Pour le dclenchement, nous ajoutons une rgle de filtrage grce au GUI de NetWall. Nous verrons par la suite que le dclenchement de cette rgle de filtrage cre une entre cache. Le plugin a besoin de s'approprier cette entre cache et de la rfrencer comme tant parent de toutes les autres demandes d'ouverture qui dcouleraient de cette connexion. Comme le service H.323 est dmarr, il se trouve en attente sur un numro de port. Ds que les paquets arrivent dans NetWall, il sont alors transmis au plugin. Le plugin peut alors commencer son analyse protocolaire et dclencher la cration d'entres caches qui permettront le passage direct du son et de la vido.

3.1.4.2

Interface native des agents

La difficult du lien entre la librairie open framework et le plugin H.323 est due aux deux langages utiliss. D'une part le langage C pour la librairie "OFW" et d'autre part le langage Java pour le plugin H.323. NetWall tant prsent sur trois plates-formes savoir AIX, Windows NT et Solaris, il y a donc un code natif sur chaque plate-forme car la librairie NetWall est programme en C. Par contre, le code java des agents est le mme sur les trois plates-formes. Il est donc ncessaire d'avoir une interface entre la librairie "OFW" et le plugin H.323. Cette interface se prsente sous la forme d'une librairie java. Elle permet de faire abstraction des plates-formes utilises. Cette librairie peut tre utilise par des intgrateurs pour simplifier le dveloppement et l'ajout de nouveau filtre. De plus, la programmation tant la mme sur les trois plates-formes le nombre de lignes de code est divis par trois.

3.1.5 SDK
L'volution de NetWall dans sa version 5.0 a rendu possible la connaissance des utilisateurs dans le driver. Ainsi, nous avons d crer des nouvelles structures d'changes car la librairie "ofw" ne pouvait pas transfrer ces informations. Nous avons cr une librairie "sdk" en nous appuyant sur des spcificits qui n'taient pas prsentes lors du dveloppement de la librairie "ofw". De plus, la librairie "sdk" devait rpondre des besoins trs prcis de la part de tous les proxies de NetWall. C'est pourquoi nous n'avons pas adapt les structures de l'open framework car le ralignement avec les agents de AAA aurait t plus long. D'autre par, l'ajout des fonctions de la librairie "sdk" s'appuie sur le travail fait pour l'open framework. Les changes de structures avec le driver sont trs simples mettre en place car nous nous appuyons sur l'architecture ouverte de l'open framework. La librairie "sdk", doit nous donner la possibilit de retrouver l'information d'une connexion par un balayage des listes de contrles d'accs. Mais aussi, par un balayage des listes d'entres caches et enfin de donner les valeurs des adresses IP de NetWall ainsi que ses interfaces d'entre ou de sortie. Bien entendu, les listes de contrles d'accs contiennent dornavant les identificateurs des utilisateurs. Les fonctions fournies par la librairie "sdk" vont nous permettre d'avoir des traces fortement corrles entre le driver et les proxies. Ainsi, nous aurons des fichiers de logs cohrents et plus faciles exploiter. Elles vont aussi nous permettre de prendre des dcisions sur l'ouverture de connexion.

Description du travail ralis

24

3.2

Architecture

3.2.1 NetWall
3.2.1.1
IP Contrle

Chemin dun paquet TCP/IP dans la fonction de contrle de NetWall


Paquet (mbuf)

Rejet

Extraction Profile IP Analyse protocole

Rejet

Filtrage des options IP

Rejet ou attend

Contrle fragmentation IP Dpile fragment ok

Recherche entre Cache statique ok Rejet

nok

Recherche entre Cache dynamique ok ok

nok Recherche dans la liste des contrles (GUI)

Rejet ok Rejet ok Rejet Cration dentre cache Contrle fragmentation IP Dpile fragment

Recherche translation dadresse

Management des connexions Rejet

Action Rejet

Accepte, Rejet, Proxy, Attend

Description du travail ralis

25

3.2.1.2

Le cache de NetWall

Le cache de NetWall est constitu de listes dentres caches. Des dcisions trs rapides peuvent tre prises grce ces entres caches. Car lorsquelles ont t cres pour une connexion, nous pouvons appliquer tous les paquets les actions qui ont t dcides lors de louverture de cette connexion. A savoir, si on accepte le passage du paquet TCP/IP, si on le rejte ou si on lenvoie la couche TCP pour quil ne soit pas rout par la couche IP (droutement proxie). En fait, il y a beaucoup dactions qui peuvent tre faites sur un paquet, par exemple la translation dadresse, les log, etc le fait de stoker ces actions nous vite un recalcule pour chaque paquet ce qui ralentirait considrablement le trafic. Dans NetWall, il y a deux grandes classes d'entres caches. La premire est la classe des entres caches statiques. Ce sont des structures o tous les champs, comme l'adresse IP de la source, le port source, l'adresse IP de la destination, le port de la destination, le protocole etc... sont connus et renseigns. Une fois quelles ont t cres plus rien n'est modifi dans la structure principale. Elles sont alors insres, en utilisant des mthodes de hachage, dans des listes de petite taille pour optimiser la recherche. La deuxime classe est celle des entres caches dynamiques. Ce sont des structures identiques aux structures des entres caches statiques, mais certains champs ne sont pas connus donc non renseigns. Il peut s'agir des champs ports de la source ou ports de la destination qui prennent alors la valeur zro. Il se peut aussi qu'un des champs adresse ait la valeur 127.0.0.1 (local host), ceci est d des problmes de spoofing dans le droutement proxy. Les entres caches dynamiques sont des entres caches statiques contenant un joker. Elles sont ranges dans une mme liste, et lorsque tous les champs sont connus, elles sont dtruites et recres dans les listes d'entres caches statiques. L'utilit des entres caches dynamiques est la suivante. Par exemple, dans le cas des services dialoguant au travers de port dynamique, nous extrayons les numros de ports des donnes contenu dans les paquets, et nous crons une entre cache dynamique avec bien sr un joker. Le client va contacter le serveur en utilisant le port dynamique (port de la destination) que le serveur lui a donn. Sur la machine NetWall, nous n'avons aucun moyen de connatre le port source que le client va utiliser, et pourtant, grce l'entre cache dynamique, NetWall laisse passer la connexion. Nous obtiendrons la valeur du port source lors de l'envoi du premier paquet, et nous pourrons alors crer l'entre cache statique. Un lment important pour NetWall est qu'il est capable de faire une recherche trs rapide dans son cache, pour garder des taux de transfert optimums. Ainsi, nous retrouvons lentre cache correspondant une connexion, en utilisant une fonction de hachage. Il y en a plusieurs dans NetWall, cela dpend du protocole ou de la fragmentation (TCP, UDP, ICMP, Fragment et autre). Ces fonctions de hachage nous positionnent en dbut de liste, il ne nous reste plus qua parcourir cette liste pour trouver lentre cache. Cette opration est trs rapide car les listes correspondantes une entre possible sont trs petites. Pour ne pas mlanger les entres caches, il est ncessaire d'identifier de manire unique une connexion. Donc nous nous servons des lments suivants : ladresse source, ladresse destination, dans le cas dune connexion TCP ou UDP du port source et du port destination, dans le cas dune connexion ICMP du type et dans les autres cas, du protocole ou de lid du fragment. Voici le dtail de la structure dune entre cache, nous voyons toutes les informations qui sont stockes et qui nauront pas besoin dtre recalcules.

Description du travail ralis

26

Structure dune entre cache (ip_cache).


*next
/* next element */

*prev
/* previous element */

*link
/* link to another element */

*back
/* link back to another element */

*pt_ttl
/* pointer sur les timers de connexion */

ip_ttl
*next *prev ttl real_ttl type *entry

ipa_src
/* adresse source */

ipa_dst
/* adresse destination */

ipa_sport
/* TCP/UDP port source */

ipa_dport
/* TCP/UDP port destination */

ipa_itype
/* ICMP type */

act_obj
act_flags act_param side

ipa_proto
/* protocole */

action_param
ipc_new_src ipc_new_dst ipc_ipmap_data dyn_map_flag dyn_map_port *ipc_offset *ipc_offset_table seq_limit

ipa_id
/* identifiant du fragment */

rpctr_id
/* RPC identifiant de transaction */

ipa_action
/* action appliquer */

ips_tcb
/* tat de la connexion */

ips_tcb
activ_timer init_timer iIps_tcpcb

*ack_cache
/* pointeur sur les acquittements */

ips_tcpcb
state fin_state datalen finseq

ftp_link
/* FTP lien sur les caches de ctrl et de donne */

ipa_level
/* Normal (0) Admin (1) */

ipa_len
/* longueur des paquets */

ftp_link
*ctrl *data *dflt *dynd

rule_number
/* numro de rgle (GUI) */

Description du travail ralis

27

rsh_dtg ipc_chstate ipa_src_side rpc_persistent

3.2.1.3

Le droutement proxy

Lorsque laction proxy est positionne, tous les paquets dune connexion sont drouts. Cest dire, une connexion entre un client A et un serveur B est en fait droute par NetWall (tout le trafic passe par l'espace utilisateur), nous avons donc une connexion de A vers N (NetWall) puis N vers B. Cette action est ncessaire pour filtrer par exemple certaines commandes de FTP comme le put, le get, ou pour faire un filtrage particulier de certains services, par exemple pour rediriger une connexion mail (pop) vers un anti-virus. Le droutement proxy ralentie considrablement le trafic entre deux machines. Ceci est normal car les paquets traversent plusieurs couches pour passer du noyau du systme dexploitation lespace utilisateur.

3.2.2 Open framework


3.2.2.1 Insertion dans NetWall

Nous devons tablir un dialogue entre le driver de NetWall qui se trouve dans le noyau du systme dexploitation et lespace utilisateur. Nous utilisons des ioctl pour ces dialogues. Avant de faire passer des structures de donnes entre l'espace utilisateur et le noyau, il faut ouvrir un file descriptor (fd). Les files descriptor sont des points d'entre dans le driver. Ces points d'entre sont positionns au boot de la machine lors du chargement du driver. Jusqu' prsent il y avait sept points d'entre dans le driver de NetWall. /dev/netwall_adm => Administration /dev/netwall_amt => Translation d'adresse /dev/netwall_ipc => Chargement et dchargement driver /dev/netwall_acl => Administration des listes de control d'accs /dev/netwall_alert => Administration des alertes /dev/netwall_auth => Administration de l'authentification /dev/netwall_log => Administration des logs Quand le dmon de NetWall "netwalld" dmarre, il ouvre ces sept fd. Ceci a pour effet au niveau du driver, de positionner un tat ouvert pour ces points d'entre. Donc aucune autre application ou dmons de l'espace utilisateur ne pourront ouvrir de nouveau ces sept points d'entres car pour le driver l'tat ouvert est dj utilis (par le dmon de NetWall). C'est un verrou qui est positionn dans le driver.

Description du travail ralis

28

Pour permettre plusieurs programmes d'accder au driver via un point d'entre particulier, il a fallu ajouter une mthode d'ouverture de file descriptor qui ne verrouille pas l'accs d'autres applications ou dmons. Ce point d'entre particulier est appel entre clone (/dev/netwall). Nous avons besoin de cette entre clone car l'architecture d'ouverture de NetWall ne se limite pas une seule application ou dmon s'excutant dans l'espace utilisateur et souhaitant accder au driver.

Dcrivons maintenant la liste des fonctions qui peuvent tre excutes en utilisant l'entre clone. Ces fonctions sont codes dans la librairie open framework. Elles rpondent au besoin de manipulation d'entres caches et de recherche d'information sur les connexions. create_cache( union cache_info *cache ) Cette fonction est appele pour crer une entre cache statique ou dynamique, cela dpend de la prsence ou non de joker dans la structure Virtual_Cache qui est le paramtre d'entre de cette fonction. La structure Virtual_Cache fait partie de l'union cache_info ainsi que la structure CacheID qui est la structure retourne aprs la cration de l'entre cache. remove_cache( struct CacheID *id ) Cette fonction est appele pour dtruire une entre cache. S'il s'agit de l'entre cache parent alors elle sera dtruite ainsi que tous ses enfants, sinon elle est la seule dtruite. Cette fonction est appele avec la structure CacheID qui nous permet de trouver l'entre cache de manire instantane car l'adresse de cette dernire se trouve dans la structure. get_cache( union cache_info *cache ) Cette fonction est appele pour recueillir une structure ip_cache telle quelle est dans le driver. Le paramtre d'entre est une structure CacheID. get_virtual_cache( union cache_info *cache ) Cette fonction est appele pour recueillir une structure Virtual_Cache telle quelle est dans le driver. Le paramtre d'entre est une structure CacheID. Ces deux dernires fonctions sont le moyen le plus simple de trouver toutes les informations sur une connexion et sur le traitement qui est effectu par NetWall. get_mapping_real_fict( struct addr_real_fict *rf ) Cette fonction est appele pour connatre l'adresse IP d'une machine par rapport au domaine de NetWall. Car une adresse IP peut tre diffrente suivant le ct qui est regard. Il faut donc donner une adresse IP et un ct ("side") ainsi la fonction nous donne l'adresse IP connue de ce ct. get_mapping( struct Profile *prof ) Cette fonction est trs proche de la fonction get_mapping_real_fict. Nous passons juste deux adresses IP au lieu d'une. set_cacheid( union cache_info *cache ) Cette fonction est appele pour s'approprier une connexion. Elle est utilise pour s'attribuer l'entre cache cre par le GUI. Elle a en entre une structure Virtual_Cache qui ne contient que les informations suivantes : adresse IP de la source et de la destination, le port source, le port destination et le protocole. Elle a en sortie une structure Virtual_Cache compltement remplie. get_addr_intf_info( struct InetAddr *addr_side) Cette fonction est appele pour connatre le ct ("side") d'une adresse IP. Nous lui passons en entre une adresse IP et en sortie nous rcuprons le ct ("side") correspondant.

Description du travail ralis

29

isLocalAddr( ulong addr) Cette fonction est appele pour savoir si une adresse IP est une adresse locale de NetWall.

La librairie open framework utilise l'entre clone "/dev/netwall". Dans le driver, cette entre clone (IPSECU_CLONE_MINOR) dclenche la fonction ofw_ioctl(commande, argument, &size). Elle permet alors d'excuter une des fonctions open framework dfinies ci-dessus suivant la commande qui est envoy comme paramtre d'appel. Par consquent, l'ajout de fonctions pour changer des informations entre le driver et l'espace utilisateur devient trs simple. Toute la difficult du point d'entre clone est rsolue.

Description du travail ralis

30

3.2.2.2

Modification de la structure du cache

*next
/* next element */

*prev
/* previous element */

*link
/* link to another element */

*back
/* link back to another element */

*pt_ttl
/* pointeur sur les timers de connexion */

ip_ttl
*next *prev ttl real_ttl type *entry

ipa_src
/* adresse source */

ipa_dst
/* adresse destination */

ipa_sport
/* TCP/UDP port source */

ipa_dport
/* TCP/UDP port destination */

ipa_itype
/* ICMP type */

act_obj
act_flags act_param side

ipa_proto
/* protocole */

action_param
ipc_new_src ipc_new_dst ipc_ipmap_data dyn_map_flag dyn_map_port *ipc_offset *ipc_offset_table seq_limit

ipa_id
/* identifiant du fragment */

rpctr_id
/* RPC identifiant de transaction */

ipa_action
/* action appliquer */

ips_tcb
/* tat de la connexion */

ips_tcb
activ_timer init_timer iIps_tcpcb

*ack_cache
/* pointeur sur les acquittements */

ips_tcpcb
state fin_state datalen finseq

ftp_link
/* FTP lien sur les caches de ctrl et de donne */

ipa_level
/* Normal (0) Admin (1) */

ipa_len
/* longueur des paquets */

ftp_link
*ctrl *data *dflt *dynd

rule_number
/* numro de rgle (GUI) */

Description du travail ralis

31

rsh_dtg ipc_chstate

ofw_link
ofw_link
/* lien sur cache OFW */

*parent *child

ofw_id
/* identifiant de connexion OFW */

ofw_id
u_id *k_cache

ipa_src_side rpc_persistent

Pour lopen framework, nous raisonnons en terme de connexion et surtout de parent et denfant. Une connexion TCP (parent) peut trs bien engendrer des connexions TCP et UDP (enfant). C'est le cas pour des dialogues bass sur le service H.323 et T120 de netmeeting. Nous pouvons ainsi accder une entre cache de faon instantane. Ceci est utile pour la recherche et surtout pour la destruction d'entre cache lors d'une fin de connexion, il suffit de donner le parent de la connexion et nous dtruisons tous les enfants de cette connexion sans avoir faire de recherche. Pour cette raison, nous avons ajout dans la structure du cache de NetWall, deux champs. Le premier est une structure ofw_link qui permet de lier entre elles les entres caches cres pour une connexion. Elles sont cres par un dmon, un proxy ou un programme s'excutant dans l'espace utilisateur. Cette structure contient un pointeur sur l'entre cache parent, ce qui permet un accs direct l'entre cache parent. L'autre lment de la structure est un pointeur sur l'entre cache enfant. Ceci est trs utile lors de la fermeture de connexion ou de la destruction du parent car il entrane la destruction de tous les enfants. Le deuxime champ, est une structure ofw_id. Cette structure permet l'identification unique d'une entre cache open framework. Elle contient un identifiant provenant de l'application s'excutant dans l'espace utilisateur et un identifiant unique provenant du driver qui n'est autre que l'adresse de cette entre cache.

3.2.2.3

Lien entre les entres caches pour lopen framework

Dans le driver de NetWall les entres caches sont lies entre elles grce aux quatre premiers lments de la structure ip_cache. Ce lien dpend du protocole utilis : les entres caches TCP (protocole 6) sont lies entre elles, les entres caches UDP (protocole 17) sont lies entre elles etc. ; mais les liens ne sont pas croiss (TCP et UDP ou autre). Dans le cadre de l'open framework, lorsque nous crons une entre cache, elle est soit parent, si elle n'a pas de parent ce qui est trs rare car elle dcoule normalement d'une rgle qui provient du GUI de NetWall, soit enfant. Toute nouvelle entre cache enfant qui est cre, est insre en tte de la liste enfant (structure ofw_link) et son pointeur parent pointe sur l'entre cache parent.

Description du travail ralis

32

entre cache 4 entre cache 1 parent enfant parent enfant

entre cache 3 parent enfant

entre cache 2 parent NULL

Description du travail ralis

33

3.2.3 H.323
Dans une confrence H.323, les participants schangent des messages dont les formats rentrent dans lune des trois catgories suivantes : Des messages constitus dune longueur variable doctets suivis dune structure ASN.1 Par exemple, les messages Q.931 servant ltablissement de lappel. Des messages constitus dune structure ASN.1. Par exemple, les messages H.245 pour la ngociation des paramtres. Des messages constitus dune suite doctets de longueur variable. Par exemple, les paquets RTP et RTCP, audio et vido. Les messages ASN.1 sont encods en conformit avec les PER (Packed Encoding Rules). Il existe deux variantes dencodage PER, savoir lencodage align et lencodage non align. H.323 utilise la variante aligne. Tous les messages ASN.1 de H.323 contiennent des champs optionnels. En consquence, il est impossible dextraire une information pour lexaminer ou la modifier un endroit prcis de la structure encode ; Il est ncessaire de dcoder une partie ou la totalit du message. Ceci est indispensable pour pouvoir extraire les numros de port changs au cours d'une connexion. La solution choisie et implmente consiste drouter la connexion de contrle et laisser passer les connexions de donnes, comme le montre le schma ci-dessous, en utilisant les fonctions de manipulation des entres caches dcrites dans les paragraphes prcdents.

Plugin H.323 USER .(51(/ TCP

filtrage IP

IP connexion de control connexion de donne

Description du travail ralis

34

3.2.4 Librairie SDK


Lextension de NetWall via la librairie "sdk" nous permet des changes de structures entre les proxies et le driver. Pour le dveloppement de cette librairie nous nous sommes appuys sur l'architecture de l'open framework. Nous utilisons donc l'entre clone de l'open framework pour accder au driver. Les fonctions suivantes sont codes dans la librairie "sdk". Elles sont indispensables pour le fonctionnement des proxies sur NetWall 5.0. get_rule_obj(struct scan_obj *scan, struct rule_obj *rule, object_id *tab) Cette fonction est appele pour parcourir les listes de contrles d'accs dans le driver. Elle prend en entre une structure "scan_obj", contenant tous les lments ncessaire la recherche du meilleur lment des listes de contrles d'accs. Cette fonction prend aussi en entre un tableau d'utilisateurs, s'il y a des utilisateurs dclars. Ainsi, nous utilisons la mme mthode que le driver pour chercher un lment dans les listes de contrles d'accs. Cette recherche est faite l'aide d'un "flag" qui dtermine ce que l'on doit regarder ou ignorer. C'est pourquoi, s'il y a des utilisateurs dclars, le "flag" sera positionn pour faire une recherche des utilisateurs en plus de la recherche habituelle. Quand la recherche est termine, nous avons le meilleur lment trouv, et nous appliquons, au niveau des proxies, l'action retourne pour cet lment. Cette action est stocke dans la structure "rule_obj" (retourne par la fonction get_rule_obj), qui contient aussi toutes les informations sur cette connexion. Nous aurons notamment les domaines d'entres et de sorties de NetWall, les adresses IP de la machine source et de la machine destination dans chacuns de ces domaines ainsi que leurs identificateurs, le port source et le port destination, la priode de validit, l'identificateur du service (protocole), l'identificateur unique de la rgle et l'identificateur unique de la liste du contrle d'accs du driver. get_itf_obj(struct itf_obj *itf) Cette fonction est appele pour trouver les interfaces ("sides") d'entres et de sorties de NetWall, ainsi que les adresses IP de ces interfaces et leurs identificateurs associs. get_cnx_obj(int sock, struct cnx_obj *cnx_obj) Cette fonction est appele pour trouver l'entre cache correspondant la socket. Nous lui donnons en entre une socket, et elle nous donne en sortie une structure "cnx_obj" qui contient de nombreuses informations sur cette connexion. Ces informations sont indispensables aux proxies. Grce elles, ils peuvent ouvrir une connexion auprs du serveur final. Les lments suivants sont prsents dans la structure "cnx_obj" : les domaines d'entres et de sorties de NetWall, les adresses IP de la machine source et de la machine destination dans chacun de ces domaines ainsi que leurs identificateurs, le port source et le port destination, l'identificateur du service, l'identificateur unique de la rgle, le protocole et l'action (accepter ou rejeter).

Comme nous le voyons, dans la version 5.0 de NetWall, nous travaillons beaucoup avec des identificateurs. Ce sont des longs non signs, ceci vite de descendre dans le driver des chanes de caractres qui seraient beaucoup plus dlicates manipuler. Nous faisons la correspondance entre les identificateurs et les noms lorsque nous prenons en compte les logs dans l'espace utilisateur.

Description du travail ralis

35

3.2.5 Schma de l'architecture OFW, SDK et H.323

Plugin H.323 H.245 session H.225 session Proxies : pop imap ftp telnet http mail gateway H.323 rule Logs

Agents Native - ASN.1

Lib_sdk USER

Lib_ofw

Dmon de NetWall

KERNEL

NetWall driver

OFW

fichier de log cnx.ulm ioctl

Langage C Langage C et Java

Langage Java

Description du travail ralis

36

3.2.6 Le multi plates-formes


3.2.6.1 Le droutement proxy

Le droutement proxy dans NetWall, est un flag dans la structure action (act_obj). Lorsque le flag "IP_CONTROL_PROXY" est positionn, cela a pour consquence de court-circuiter la couche IP (couche de routage) et de transmettre directement le paquet la couche TCP comme si le paquet tait l'intention du NetWall et non du destinataire. Le problme est que nous travaillons sur plusieurs plates-formes, AIX, Solaris et Windows NT. L'implmentation du droutement proxy est diffrent suivant les plates-formes. Pour une version AIX de NetWall, nous avons une fonction qui envoie le paquet directement la couche TCP. Il n'y a donc aucun problme de routage du paquet car nous court-circuitons la couche IP. L'adresse IP de destination peut tre n'importe laquelle de toute faon le paquet sera pour NetWall. Pour une version Solaris ou Windows NT de NetWall, nous n'avons pas l'quivalent de la fonction d'AIX qui nous permet l'envoi direct la couche TCP. Donc sur ces deux plates-formes, il nous faut faire une translation de l'adresse destination en une adresse locale de NetWall et une transformation du port source en un port que l'on alloue dynamiquement et ce pour assurer l'unicit de la connexion TCP/IP. Une fois ces translations faites, nous envoyons ce paquet la couche IP qui va le router naturellement la couche TCP locale du NetWall. Nous obtenons par cette mthode un droutement proxy. Mais cela engendre quelques inconvnients. A savoir un disfonctionnement de la translation d'adresse. En cas de translation statique d'adresse et de droutement proxy, les connexions ne franchissent pas NetWall. Nous perdons la valeur translate de l'adresse IP de destination, uniquement sur les platesformes Solaris et Windows NT. Ce problme est rsolu dans la version 5.0 de NetWall.

3.2.6.2

Le Routage

Une difficult majeur pour les versions Solaris et Windows NT de NetWall, est qu'il n'y a pas de fonction systme pouvant s'excuter dans le driver et permettant le calcul des routes. Ainsi, nous avons besoin de connatre l'interface ou la carte de sortie d'un paquet pour une adresse destination donne. Cela nous permet de prparer les entres caches et de positionner les valeurs des interfaces de sortie pour le spoofing. Nous avons trouv un moyen de contourner ce problme. Nous formatons un paquet test et nous l'envoyons la couche IP. Cette dernire va calculer le routage et il ne nous reste plus qu'a rcuprer les informations. Cette mthode fonctionne trs bien quand on a un paquet. Si nous n'avons pas de paquet, nous sommes incapable d'en formater un pour rcuprer les informations de routage. Or dans la cas de la librairie open framework, nous crons des entres caches par anticipation, nous n'avons pas de paquet "sous la main" pour calculer le routage. Ce problme est rsolu dans la version 5.0 de NetWall.

Description du travail ralis

37

3.3

Ralisation

3.3.1 Protocoles dynamiques


3.3.1.1 Analyse et implmentation de SQL*Net

Cette partie est la description complte du travail qui a t fait dans NetWall pour permettre le filtrage de SQL*Net. 1) Oracle et les rseaux (SQL*Net) SQL*Net est un nom gnrique dsignant en fait lensemble des couches ncessaires la communication entre clients et serveur oracle. SQL*Net assure la transparence du rseau cest--dire quune base de donnes peut tre accde indiffremment quelle que soit sa localisation physique (locale ou distante) cette abstraction rseau implique la transparence vis vis : - des systmes dexploitation et des architectures matrielles - des protocoles rseaux utiliss - des mdias et de la topologie du rseau, assures par le "Transport Network Substrate "(TNS) - de la localisation physique des bases, celles-ci seront donc dsignes par des noms ou adresses IP, un numro de port et le SID dsignant linstance de la base sur ce serveur. Nous ne parlerons que du protocole TCP/IP. On connat lintrt de dsigner les ressources rseau par des noms indpendants de leur adresse physique (convivialit, dplacement transparent de services,...). Chaque base de donnes, chaque serveur, chaque listener (dmon en charge de la rception des requtes des clients) aura un nom unique. On utilise un fichier de configuration TNSNAMES.ORA (quivalent /etc/host) sur chaque poste client ou serveur. a) SQL*Net connexion SQL*Net tablit une connexion une base de donnes quand le client ou une autre base de donnes serveur envoie une demande de connexion une base distante. Cette demande est faite de manire automatique ou manuelle. Il y a trois composants dans toutes les connexions SQL*Net : - Client : Logiciel qui amorce la connexion, quil soit client ou serveur oracle7. - TNS Listener : Dmon qui coute sur un port fixe dans le cas de TCP/IP. Dans notre cas, cest le port 1521. - Serveur : Logiciel qui sert le client, il sagit dun serveur oracle7 ddi ou dun serveur oracle7 multi-thread (avec un dispatcheur), nous dtaillerons plus loin la diffrence entre ces deux serveurs. Classiquement : Le client appelle le serveur par lintermdiaire du listener qui coute sur le port 1521. Le client envoie une requte au listener qui contient ladresse cible (serveur), le port (1521) et lidentifiant de la base de donnes (SID). Le listener accepte la demande de connexion et la passe au serveur appropri.

Description du travail ralis

38

Description de la requte SQL*Net (tnsname.ora) : (DESCRIPTION= (ADDRESS= (COMMUNITY= community_name) (PROTOCOL=tcp) (HOST=database_server) (PORT=1521) ) (CONNECT_DATA= (SID=database_identifier) ) )

Description de la requte rponse (si port dynamique) : (ADDRESS= (PROTOCOL=tcp) (DEV=15) (HOST=129.183.155.24) (PORT=4257))

Description du travail ralis

39

b) Serveur ddi Pour utiliser un serveur ddi avec SQL*Net, il faut que le dmon oracle (Listener) soit dmarr sur le serveur. De plus SQL*Net permet de filtrer laccs des bases de donnes en regardant les autorisations dfinies dans le fichier protocol.ora. Ce fichier contient une liste dadresses IP et la rgle associe. Ce contrle est indpendant de NetWall. Les tapes de la connexion : - Le client initialise la connexion en contactant le LISTENER sur le port 1521 comme dcrit ci-dessus. - Le listener reoit la demande et dtermine si le client a le droit de se connecter en vrifiant les droits dans le fichier protocol.ora. Si le listener refuse la connexion, il renvoie une erreur au client et continue lcoute en vue dune nouvelle demande de connexion. - Si la connexion est accepte, le listener engendre un processus serveur. - Il lgue la connexion du client au processus serveur et ils se partagent efficacement le port 1521 (figure A). Le plus souvent, le listener lgue la connexion au lieu de la rediriger vers un autre port. - lorsque le listener engendre un processus serveur (figure B), celui-ci contacte le systme qui lui donne un numro de port disponible (comme le fait le port-mapper). Il transmet linformation au client et ferme la connexion. Le client ouvrira une nouvelle connexion sur ce nouveau port. - Le listener continue couter les connexions entrantes.

schma : C : client L : listener S : serveur


figure A figure B

1521

1521

S L C
1521 4257

1521

S
4257

Description du travail ralis

40

c) Serveur multi-thread Un serveur multi-thread supporte plusieurs clients par processus serveur. Ceci permet de rduire la mmoire utilise. De plus, un nombre plus important dutilisateurs peuvent se connecter la base de donnes. Cest le listener qui sert de relais pour une connexion un dispatcher, donc le client contacte le serveur en passant par le listener qui lui renvoie automatiquement un numro de port dynamique (celui du dispatcheur). Pour pouvoir faire des accs une base qui se trouve sur un serveur multi-thread, il est impratif de dmarrer le listener, le serveur multi-thread et le dispatcheur. SQL*Net permet de filtrer laccs des bases de donnes en regardant les autorisations dfinies dans le fichier protocol.ora. Ce fichier contient une liste dadresses IP et la rgle associe. Ce contrle est indpendant de NetWall. Les tapes de la connexion : - Le client initialise la connexion en contactant le LISTENER sur le port 1521 comme dcrit ci-dessus. - Le Listener reoit la demande et dtermine si le client a le droit de se connecter en vrifiant les droits dans le fichier protocol.ora. Si le listener refuse la connexion, il renvoie une erreur au client et continue lcoute en vue dune nouvelle demande de connexion. - Le listener renvoi au client une requte qui contient ladresse IP du dispatcher et le numro de port sur lequel il doit le contacter. - Le client perd la connexion avec le listener et ouvre une nouvelle connexion avec le dispatcher en utilisant ladresse et le numro de port contenu dans la requte rponse du listener. - Le listener et le dispatcher cre un lien pour se mettre jour sur les nouvelles connexions. Le listener peut envoyer une nouvelle connexion un dispatcher qui tourne. - Le listener continu couter les connexions entrantes. schma : C : client L : listener S : serveur D : dispatcheur

C C

L
1521 @IP + 4250

L
1521

D 4250 L
1521 mise jour

D 4251 D 4252

D
4250

Description du travail ralis

41

2) Information ncessaire pour filtrer SQL*Net avec NetWall Ladministrateur dfinit ses rgles de scurit, il autorise un client A faire des connexions vers un serveur B en utilisant le service SQL*Net. Au niveau du GUI de NetWall, il va ajouter une rgle A vers B sur le port 1521 et prciser quil accepte cette connexion. La difficult pour NetWall, rside dans le fait quil faut autoriser le passage des informations de la machine client A vers la machine serveur B pour un trafic SQL*Net, et ce pour suivre la politique de scurit dfinie par ladministrateur. Or ce trafic sinitialise forcement avec le quintupl adresse source (machine client A), port source, adresse destination (machine serveur B), port destination (port=1521) et protocole TCP (numro=6), mais le serveur peut dcider de ne plus dialoguer sur le port 1521 mais sur un autre port quil dtermine de faon dynamique. Il y a donc dans les connexions SQL*Net, un change de numro de port au cours de la connexion. Ladministrateur ne peut pas connatre le numro de port dynamique chang au cours dune connexion. Pourtant il veut autoriser la connexion du client A vers le serveur B pour le service SQL*Net. NetWall doit donc extraire le numro de port dynamique, pour crer une rgle autorisant le client A se connecter au serveur B conformment la politique de scurit tablie par ladministrateur. Sans cette nouvelle rgle la connexion entre les deux machines est impossible. En rsum : - Le client initialise la connexion sur le port 1521. - Le serveur renvoie au client, dans certains cas (dcris prcdemment), ladresse et le port sur lequel il doit le contacter. Ces informations sont contenues dans les data dun paquet TCP/IP. ex : |.J.......@(ADDRE| |SS=(PROTOCOL=tcp| |)(DEV=15)(HOST=1| |29.183.155.24)(P| |ORT=4257)) | Il faut regarder le contenu des paquets rponse pour extraire le numro de port dynamique (dans lexemple cest le port 4257). Cette information est indispensable pour crer une rgle dynamique qui permettra dautoriser le passage des paquets suivants sur le port 4257. Dans la suite, nous expliquons le traitement appliqu aux paquets si l'administrateur de NetWall a associ une translation d'adresse statique ou dynamique, la source ou la destination des paquets SQL*Net. a) Translation statique dadresse Nous pouvons translater statiquement ladresse IP des clients ou des serveurs (voir Fonctions couvertes par NetWall / filtrage dynamique au niveau IP). La translation statique dadresse, consiste masquer ladresse relle dune machine interne toutes les machines (externes) qui se trouvent de lautre ct de NetWall. La seule contrainte est de prciser le chemin (routage) sur les machines externes pour quelles puissent atteindre la machine dont ladresse a t translate. ex : 129.183.155.24 est translate en 222.222.222.22

i. Translation statique de ladresse du serveur

La difficult pour le garde barrire est de modifier les en-ttes IP des datagrames et ladresse du serveur qui sont contenues dans la rponse du serveur.

Description du travail ralis

42

Pour len-tte IP il faut modifier les adresses qui ont t translates ou les adresses qui ont besoin dtre translates et recalculer le checksum IP de ce datagrame. Il faut faire cette opration pour tous les paquets changs entre le client et le serveur. Dans le cas ou il y a une modification faire dans les donnes : Exemple : Donnes mises par le serveur (sans len-tte IP et TCP) ====( 128 bytes transmitted on interface en0 )==== 16:30:04.592962799 ETHERNET packet : [ 08:00:3e:30:33:93 -> 00:00:c0:35:3f:00 ] type 800 (IP) IP header breakdown: < SRC = 129.183.155.24 > (rioga.frec.bull.fr) < DST = 129.183.155.15 > (onyx.frec.bull.fr) ip_v=4, ip_hl=20, ip_tos=0, ip_len=114, ip_id=32388, ip_off=0 ip_ttl=60, ip_sum=c66b, ip_p = 6 (TCP) TCP header breakdown: <source port=1521, destination port=2661 > th_seq=cb5e8510, th_ack=55eebaa th_off=5, flags<PUSH | ACK> th_win=16060, th_sum=fdc7, th_urp=0 Data : |.J.......@(ADDRE| |SS=(PROTOCOL=tcp| |)(DEV=15)(HOST=1| |29.183.155.24)(P| |ORT=4257)) | mais le client doit recevoir les donnes suivantes : IP header breakdown: < SRC = 222.222.222.22 > < DST = 129.183.155.15 > (onyx.frec.bull.fr) ip_v=4, ip_hl=20, ip_tos=0, ip_len=114, ip_id=32388, ip_off=0 ip_ttl=60, ip_sum= xxxx, ip_p = 6 (TCP) TCP header breakdown: <source port=1521, destination port=2661 > th_seq=cb5e8510, th_ack=55eebaa th_off=5, flags<PUSH | ACK> th_win=16060, th_sum= xxxx, th_urp=0 Data : |.J.......@(ADDRE| |SS=(PROTOCOL=tcp| |)(DEV=15)(HOST=2| |22.222.222.22)(P| |ORT=4257)) | Problmatique pose dans NetWall : - si la longueur de ladresse translate est gale la longueur de ladresse relle : Ladresse relle du serveur dans les donnes, doit tre remplace par ladresse translate. Mais il faut aussi recalculer le checksum TCP car les donnes ont chang, puis mettre jour les adresses contenues dans len-tte IP et pour finir recalculer le checksum IP. - si la longueur de ladresse translate est diffrente de la longueur de ladresse relle : Il faut changer certaines informations au niveau IP et TCP comme dcrit dans le cas prcdent. Mais il faut aussi recalculer les valeurs donnant la longueur des donnes calcules pour et par SQL*Net (ici J =74 et @ =64). Dans lexemple, la longueur totale du paquet est de 114 (cest la

Description du travail ralis

43

longueur de len-tte IP + la longueur de len-tte TCP + la longueur des donnes), mais il faut retrancher 40 (longueur de len-tte IP + longueur de len-tte TCP) ce qui nous donne une longueur des donnes qui vaut 74. Cette modification de longueur des paquets engendre des problmes supplmentaires, pour la cohrence des numros de squences et des numros dacquittements. Si ces numros de squences ne correspondent pas ce que la couche TCP attend, les paquets seront rejets par cette dernire. Il faut donc grer des listes de numros de squence pour rester cohrent par rapport aux deux couches TCP (client et serveur) qui dialoguent entre elles. Ces listes seront indispensables pour assurer le dialogue entre le client et le serveur, et ce pour tous les paquets qui seront mis aprs cette modification de donne. Attention il faut modifier le fichier tnsname.ora sur le client pour quil puisse se connecter au serveur dont ladresse est translate.

ii. Translation statique de ladresse du client

Les donnes des paquets mis par le client ne contiennent pas dinformation modifier. Donc, il y aura juste une modification des en-ttes IP au passage du NetWall. Il faut remplacer les adresses translates par les adresses relles ou vis et versa, puis recalculer le checksum IP.

Description du travail ralis

44

iii. Exemple de connexion avec translation statique dadresse (serveur)

Connexion entre le client "coq_et " et le serveur "rioga ", on passe travers NetWall qui est sur "cobra ". On fait une translation statique de ladresse de "rioga ", son adresse relle est 129.183.155.24, son adresse virtuelle est 3.3.3.3 Cet exemple illustre les modifications des numros de squences (dcrit ci-dessus). En gras, les valeurs modifier au passage de NetWall.

Serveur Rioga 129.183.155.24

NetWall cobra 129.183.155.7 3.3.3.3


Seq=4474921 len=301 Seq=4474921 len=301

Client Coq_et 129.184.155.1

(DESCRIPTION= . .)

@(ADDRESS= (PORT=) )

Seq=506fdab4 ack=4474a26 len = 74 <PUSH|ACK>

Seq=506fdab4 ack=4474a26 len = 67 <PUSH|ACK>

Seq=506fdafe ack=4474a26 len = 0 <FIN|ACK>

Seq=506fdaf7 ack=4474a26 len = 0 <FIN|ACK>

Seq=4474a26 ack=506fdaff len = 0 <ACK>

Seq=4474a26 ack=506fdaf8 len = 0 <ACK>

Seq=4474a26 ack=506fdaff len = 0 <FIN|ACK>

Seq=4474a26 ack=506fdaf8 len = 0 <FIN|ACK>

Seq=506fdaff ack=4474a27 len = 0 <ACK>

Seq=506fdaf8 ack=4474a27 len = 0 <ACK>

Description du travail ralis

45

b) Translation dynamique dadresse Pour faire de la translation dynamique dadresse, cela ne peut se faire que par la translation dynamique des clients, car faire de la translation dynamique des serveurs na pas de sens. Dans ce cas nous sommes trs proches de la translation statique de ladresse du client, sauf que le client prend ladresse IP du NetWall lorsquil le traverse et comme port source un port dfini par NetWall. Nous pouvons donc retrouver ladresse du client grce ce numro de port. Il nest pas ncessaire de modifier les tables de routage pour faire de la translation dadresse dynamique. 3) Restriction sur lutilisation de SQL*Net avec NetWall Il ne faut pas faire de lencodage de donnes avec SQL*Net si lon veut passer travers un NetWall, car NetWall ne sera pas capable de lire le numro de port dynamique contenu dans les data des paquets TCP/IP. Le listener doit tre en coute sur le port 1521 ou 1526. Le listener, le dispatcheur et le serveur de donnes doivent se trouver sur la mme machine, ils doivent avoir la mme adresse IP. Donc cette configuration ne marche pas avec NetWall :

Description du travail ralis

46

3.3.1.2

Modification de limplmentation des sun-RPC

Le service sun-rpc est un service qui utilise des ports dynamiques. Ces ports sont fournis par le port mapper. Nous pouvons accder au port mapper en utilisant le protocole TCP ou UDP. NetWall filtre les sun-rpc. Jusqu' prsent lorsqu'un programme appelait le port mapper il utilisait le protocole TCP (ou UDP). La connexion qui s'tablissait par la suite tait sur le mme protocole TCP (ou UDP). Le problme est le suivant, l'application contacte le port mapper en utilisant le protocole UDP et ouvre, ds qu'il a la connaissance du port qui lui a t assign, une connexion TCP. Or, NetWall cre une entre cache dynamique pour autoriser la connexion sur ce nouveau port, mais en utilisant le protocole UDP et non TCP. Donc l'application cliente ne peut pas fonctionner, car les paquets arrivant avec le protocole TCP ne seront pas autoriss traverser NetWall, parce que le protocole n'est pas celui de l'entre cache. La correction adopte a t d'autoriser la connexion sur UDP ou sur TCP en positionnant un joker pour le protocole. La vrification du protocole n'est plus faite quand il s'agit d'une entre cache dynamique cre la suite d'une demande d'ouverture de connexion des sun-RPC.

3.3.2 librairie open framework


La librairie open framework a t ralise en deux tapes. Le dveloppement devait dans un premier temps rpondre des attentes de clients sur la plate-forme AIX. La demande du march tait de filtrer le protocole H.323, ce qui rendait possible l'utilisation de logiciel comme Netmeeting au travers de NetWall. Au dbut de l'analyse de l'extension des fonctionnalits de NetWall, nous n'tions prsents sur le march des "pare-feu" seulement sur la plate-forme AIX, en effet la version de NetWall sur Windows NT tait en cours de dveloppement et le portage de NetWall sur Solaris allait dbuter. La deuxime tape tait donc le portage de l'open framework sur les plates-formes Windows NT et Solaris. En effet, NetWall devait avoir un fonctionnement identique sur les trois plates-formes AIX, Windows NT et Solaris. La librairie, a t faite en utilisant le langage C, elle est dpendante des plates-formes. Le code est en grosse partie le mme sur AIX, Windows NT et Solaris, seuls les appels vers le driver de NetWall sont diffrents, mais nous n'avons pas mis les sources dans la partie commune du projet. En effet, le portage sur Windows NT et Solaris n'tait pas prvu. La librairie open framework, rpond aux attentes exprimes dans les chapitres prcdents, savoir la manipulation d'entre cache lorsque NetWall fonctionne. Cette librairie est livre sur les trois platesformes et elle a un fonctionnement identique sur chacune d'elles. De plus, cette librairie a permis NetWall de filtrer le protocole H.323 de faon optimum, ce qu'aucun fabriquant de pare-feu ne savait faire.

3.3.3 AAA, H.323 et les logs


La ralisation du plugin H.323, a t faite l'INRIA par l'quipe AAA. Ce plugin s'appuie comme nous l'avons d'crit dans des chapitres prcdents sur une architecture base sur les agents et sur la librairie open framework. Le travail qui t ralis a Bull est un travail d'intgration de code. Nous nous sommes heurts de nombreux problmes pour transfrer le code et pour l'archiver dans le projet NetWall. En effet, le dveloppement du plugin est fait dans le langage Java. Or, l'quipe de gestion des sources de NetWall, et plus gnralement de tous les projets prsents Echirolles, n'avait pas d'outils permettant de compiler et de gnrer des classes Java.

Description du travail ralis

47

Il nous a fallu mettre en place tout lenvironnement permettant de compiler le code Java et nous avons d refaire tous les makefiles permettant de compiler le plugin. Cette partie a t un trs gros travail, mais nous sommes parvenu archiver, compiler et gnrer des classes Java. Nous faisons ceci de manire transparente pour le projet. Que l'on travaille sur un code c ou un code java, les outils de compilation et d'archivage sont les mmes. De plus le travail qui a t fait pour la compilation du code java dans le projet peut tre dornavant utilis dans tous les projets de Bull Echirolles. Nous avons pu constater l'utilit de ce travail lorsque nous avons transfr les sources de l'application de gestion des logs de NetWall. Le dveloppement de l'application de gestion des logs a t fait par l'quipe AAA et le code est en Java. L'intgration dans le projet NetWall a t trs simple car tout l'environnement de dveloppement tait dj prsent, seul les makefiles ont t modifis.

3.3.4 librairie SDK


La librairie "sdk" a t ralise pour la version 5.0 de NetWall. Cette librairie tait indispensable pour le fonctionnement des proxies livrs avec le pare-feu. D'un point de vu ralisation, la librairie est identique sur les trois plates-formes. Nous avons dvelopp la librairie "sdk", en utilisant le langage C. Le code est commun aux trois plates-formes ; seul les appels aux ioctl, c'est dire aux points d'entres dans le driver sont diffrents. En effet ces points d'entres sont dpendants des plates-formes. Pour la partie driver de NetWall, le code est lui aussi dans la partie commune du projet ; il se trouve au mme endroit que le code de l'open framework. La librairie "sdk", rpond aux attentes exprimes dans les chapitres prcdents. A savoir, un change d'information entre le driver et les proxies, pour des prises de dcision sur l'ouverture de connexion et pour l'uniformisation des logs. Cette librairie est livre sur les trois plates-formes, elle a un fonctionnement identique sur chacunes d'elles. De plus, elle a permis NetWall dans sa version 5.0 de simplifier les rgles de filtrage des proxies qui grent des droits d'accs pour les utilisateurs.

3.4

Exprimentations

L'quipe NetWall dispose d'une plate-forme de test, comprenant de nombreuses machines. Notamment, des machines AIX mono processeur, bi-processeurs, quadri-processeurs, mais galement plusieurs PC installs avec Windows NT client et serveur, ce sont des PC mono processeur ou biprocesseurs ainsi que des machines Solaris sparc et intel. Toutes les machines sont quipes d'au moins trois cartes rseaux, ce qui nous permet d'avoir de nombreux rseaux indpendants. Le schma suivant reprsente notre salle de test.

Description du travail ralis

48

RIOGA

r15 toc

c11 c13 c12 c1

COBRA

ioupi r12

r16

r11

r14

c3 r13

c21

arte

ortie

shine

onyx

fox

coq

orchis

datura

o1

o3

o2

o4

a1

a2

a21

a31

o1

portillon

ROSE clio r12

a2

ACONIT

rseau 100 mega rseau 10 mega rseau FDDI rseau TokenRing NetWall AIX NetWall NT NetWall Solaris Serveur AIX

Toutes les machines ont en plus une carte rseau les reliant au rseau d'entreprise.

Description du travail ralis

49

Grce cette plate-forme de test, nous avons pu exprimenter et tester les diffrentes modifications de NetWall. Les modifications les plus importantes ont t ralises dans le driver de NetWall. Le moindre problme de pointeur ou le moindre problme d'allocation mmoire entrane un crash de la machine et il faut parfois rinstaller le systme d'exploitation. La suite dcrit les exprimentations qui ont t ralises, et ce dans un ordre chronologique.

3.4.1 SQL*Net
Pour pouvoir commencer les tests, Nous avons d installer des serveurs oracles supportant SQL*Net version 2. Nous avons install deux types diffrents de serveurs sur des machines AIX. Le premier est un serveur ddi et le second est un serveur multi-thread. Aprs avoir pris connaissance du fonctionnement de Oracle SQL*Net, nous pouvions interroger les serveurs de donnes partir d'un client. Les clients pouvant tre des clients AIX ou des clients Windows NT. En effet, il est important de tester les connexions avec ces deux types de clients car les requtes de connexion sont diffrentes. Les essais de filtrage ont t raliss en utilisant un NetWall version 3.3. Nous avons vrifi le bon fonctionnement des connexions lorsque celles-ci taient acceptes au niveau des rgles de filtrage de NetWall, et le rejet dans le cas contraire. L'tape suivante est la translation statique d'adresse. Tout d'abord la translation de l'adresse du client, c'est le cas le plus facile, car il n'y a pas de dcalage dans les offsets de l'en-tte TCP. Puis la translation statique de l'adresse du serveur (qui dans ce cas l cre un dcalage dans les offsets). Et enfin, la translation dynamique d'adresse. Les tests de fonctionnalits tant effectus (tests L1), les binaires sont tester par l'quipe de test qui effectue les tests d'intgration et de robustesse.

3.4.2 Sun RPC


Le filtrage du service Sun RPC tait dj prsent dans NetWall, mais une correction du code a t ncessaire pour le fonctionnement des montages NFS entre des machines AIX et des machines Solaris. Cette modification faite nous avons vrifi qu'elle n'entrane pas de rgression dans le fonctionnement et dans le filtrage de NetWall. Les tests ont t ralis via un montage NFS entre un client AIX et un serveur Solaris, en passant au travers de NetWall. Le but tant atteint, des tests de translation d'adresse statique et dynamique ont t effectus.

3.4.3 OFW
Pour vrifier le fonctionnement de la librairie "lib_ofw", nous avons crit deux programmes de tests crant des entres caches dynamiques, et effectuant des recherches et des destructions d'entres caches. Le premier programme tablit une connexion entre un client et un serveur telnet en passant au travers de NetWall, qui a pour seule rgle de filtrage, une rgle rejetant toutes les connexions. Dans ce cas l, NetWall est vraiment un mur infranchissable, sauf pour la connexion telnet car le programme de tests a cr une entre cache dynamique acceptant cette connexion. Aprs la connexion nous dtruisons l'entre cache, et nous vrifions qu'aucune connexion n'est possible. Le deuxime programme de test est un peu plus compliqu, il s'agit d'un plugin ftp. En effet NetWall filtre le service ftp uniquement sur le port 21, c'est pourquoi nous avons pens au plugin ftp qui est

Description du travail ralis

50

capable de filtrer le service ftp sur n'importes quels ports. Nous droutons seulement la connexion de contrle pour l'analyse et la dcouverte du port dynamique. Ce programme a permis de tester la quasi-totalit des fonctions de la librairie open framework, sans s'intresser aux problmes de translation d'adresse dans ce deuxime programme de test car la translation d'adresse est ralise dans le cadre de l'exprimentation du plugin H.323.

3.4.4 Netmeeting et Netscape confrence


Nous avons install sur plusieurs PC, Microsoft NetMeeting afin d'effectuer des confrences. Ces PC sont munis de cartes sons et de vidos camras. NetMeeting est un logiciel bas sur le protocole H.323. Nous avons dans un premier temps effectu les tests sur un NetWall AIX version 4.0. Les exprimentations se droulent suivant des mthodes d'approches classiques. C'est dire, nous vrifions le fonctionnement de l'application sans NetWall, puis nous rajoutons NetWall, si tout se droule bien nous passons aux tests de translation d'adresse IP sur chacunes des machines clients et serveurs. Pour nos tests nous ralisons deux confrences simultanes avec deux utilisateurs dans chacune des confrences. Nous avons vrifi le bon fonctionnement des confrences lorsque celles-ci taient acceptes au niveau des rgles de filtrages de NetWall, et le rejet dans le cas contraire. En exploitant les traces fournies par NetWall, nous constatons que seules, les connexions de contrle sont droutes dans l'espace utilisateur o le plugin fait son analyse protocolaire. Les connexions de l'audio et de la vido ne sont quant elles pas droutes. Aprs une initialisation de connexion lgrement plus importante lorsque nous filtrons le protocole H.323, nous obtenons les mmes performances pour la suite de la confrence, qu'il y est filtrage ou non. Nous avons par la suite procd des tests de vido confrence avec de la translation statique d'adresse IP est constater le bon fonctionnement de ces confrences. Ainsi s'achevaient nos tests sur AIX, nous avons compltement rpondu la demande qui tait de filtrer le protocole H.323. Un petit plus a mme tait rajout, car nous filtrons compltement le logiciel NetMeeting. En effet, NetMeeting utilise deux protocoles le premier H.323 et le second T120, ce dernier est utilis pour des conversations de type "chat", pour l'utilisation de tableau blanc et pour le partage d'application, transfert de fichiers, etc... Au vu des exprimentations ralises et des rsultats nous pouvons dire que nous filtrons totalement le protocole H.323 et le protocole T120. Une fois finis les tests du plugin sur NetWall AIX, nous sommes passs aux tests sur les platesformes Windows NT et Solaris. Nous avons rencontr des difficults lors des tests de translation statique d'adresse IP. En effet, nous nous sommes heurts un dfaut connu de NetWall (ce dfaut tait considr comme un cas d'cole). La solution ce problme arrive avec la version 5.0 de NetWall, o toutes les translations d'adresses et tous les droutements proxies ont t revus et grs diffremment. Les tests fait sur la version 5.0 de NetWall NT et Solaris atteste du bon fonctionnement du plugin H.323. Ainsi nos trois plates-formes ont le mme fonctionnement. Nous avons pouss les exprimentations un peu plus loin, en faisant des confrences avec trois, quatre ou cinq intervenants. Les confrences fonctionnent, mais il ne faut pas faire de translation d'adresse IP. De toute faon NetWall garanti le fonctionnement qu'avec des confrences deux. Des tests ont t faits pour raliser des confrences partir du logiciel Netscape confrence, il s'appuie sur le protocole H.323. Nous avons mme test des confrences entre Netscape confrence et NetMeeting.

Description du travail ralis

51

3.4.5 librairie SDK et les proxies


Il n'a pas t crit de programme de test pour vrifier le fonctionnement de la librairie "lib_sdk". En effet, les exprimentations ralises sur la librairie ont t faites au travers des tests d'intgrations des proxies de NetWall version 5.0 et sur chacune des trois plates-formes (AIX, Solaris et Windows NT). Tous les proxies ont t impacts par la librairie "lib_sdk". La vrification du fonctionnement des proxies devait tre faite, car un changement important t opr dans cette version. La dcision de l'ouverture de connexion par rapport un utilisateur se fait dans le driver de NetWall. Cela ce passe en deux tapes, la premire, le driver accepte le passage de la connexion vers l'espace applicatif. La deuxime, le proxy vrifie si l'utilisateur a le droit de se connecter en se servant de la librairie "lib_sdk". Lorsqu'un client contact un serveur, il ne sait pas forcment qu'il traverse un proxy applicatif qui peut effectuer un filtre sur la connexion. Ce type de proxy s'appelle un proxy transparent car il n'est visible ni du client ni du serveur. L'autre cas possible est que le client n'a pas connaissance du serveur de destination. Il ouvre une connexion avec le proxy de NetWall et ce dernier se charge de le connecter au serveur. La situation est la suivante, le client et le serveur ne se voient pas, ils s'changent des donnes au travers du proxy de NetWall. Nous parlons alors de proxy non transparent. Le test des proxies transparents et non transparents a t ralis grce la librairie "lib_sdk". Elle fournit l'information ncessaire aux proxies pour qu'ils puissent connecter le serveur. La plupart des proxies ont t tests en ouvrant des connexions l'aide de telnet sur les numros de port de chaque service. Le refus d'ouverture de connexion de certains utilisateurs non autoriss est ainsi test. Il en est de mme pour le filtre de certains verbes (GET, PUT, ...). Les tests de fonctionnement des proxies suivants : pop, imap, ftp, telnet, http, mail et gateway sont effectu en utilisant de nombreux shell script mis notre disposition.

52

Chapitre 4 : BILAN ET PERSPECTIVES

Bilan et perspectives

53

4.1

Rappel des objectifs et bilan technique

Le principal objectif de ce travail de DRT tait de permettre au milieu industriel dintgrer dans un produit finalis (commercialisable) une technologie dveloppe au sein d'un laboratoire de recherche. La technologie base d'agents propose par lInria devait nous permettre, d'une part, de dfinir et dimplmenter une infrastructure d'intgration ouverte et extensible, d'autre part, de dvelopper un systme d'audit et de gestion des logs pour le produit NetWall. L'aboutissement de ce travail devait assurer l'volutivit de NetWall en vue, notamment, de supporter de nouveaux protocoles tels que l'audio et la vido confrence sur Internet ou encore de filtrer plus finement l'accs aux bases de donnes. La principale difficult dun tel transfert de technologie rside aussi bien dans les problmes techniques dintgration dans le produit existant que dans les contraintes conomiques et les dlais lis la fabrication du produit. Il est noter que les objectifs de dpart ont volu au contact de cette problmatique. Le travail de DRT s'est recentr, au regard de ces contraintes, autour de l'ouverture de l'architecture de NetWall et du ralignement des fichiers de logs. De fait, le dveloppement d'un systme d'audit et de gestion des logs a t ralis par l'quipe AAA. Au cours de ces deux annes de travail plusieurs ralisations concrtes ont t mises en place. Elles peuvent tre regroupes dans trois ensembles rappels brivement ci-aprs. Le premier ensemble correspond la mise en uvre de solutions pour filtrer les protocoles dynamiques. Ainsi, un filtre pour l'accs aux bases de donnes a t implment au niveau du driver de NetWall. En effet, NetWall a t enrichi par le filtrage du protocole SQL*Net. Ce protocole est utilis par une machine cliente pour accder aux bases de donnes d'un serveur Oracle. Les connexions entres ces deux machines s'tablissent au travers de ports allous dynamiquement. La difficult, comme nous l'avons indiqu prcdemment, est d'extraire ces numros de ports des donnes et de prparer l'environnement pour cette connexion. Une autre ralisation fut le filtrage du protocole H.323. En consquence, NetWall a t un des premiers pare-feu filtrer rellement le protocole H.323 d'audio et vido confrence sur Internet. A cet effet, la technologie base d'agents dveloppe par l'quipe AAA fut incorpore dans NetWall. Le deuxime ensemble concerne la dfinition d'une architecture ouverte pour NetWall rendant ralisable l'intgration de nouvelles fonctions en s'appuyant sur deux librairies. En effet, une infrastructure ouverte et extensible ralise au travers de la librairie open framework, offre la possibilit des partenaires de dvelopper des solutions spcifiques de contrle et de filtrage. Le dveloppement du filtre H.323 fut possible grce cette librairie qui permet la manipulation directe d'lments du driver (entres caches), au niveau des couches applicatives. Une autre librairie a t dveloppe pour effectuer des changes d'informations entre le driver et l'espace applicatif. Cette librairie SDK est indispensable pour le fonctionnement des proxies et pour la cohrence des fichiers de log. Ces deux librairies offrent une relle valeur ajoute au pare-feu de Bull. Enfin, La dernire ralisation concrte a t l'insertion dans NetWall du prototype de gestion des logs. Ce prototype collecte des fichiers de logs gographiquement disperss car les pare-feu peuvent tre prsents dans plusieurs agences d'une mme socit. Ce prototype permet de dfinir la demande des nouvelles fonctions de traitement des informations enregistres par les NetWall. Grce lui, NetWall se munit d'une technologie de pointe en intgrant des fonctionnalits base d'agents et de programmation objet en Java.

Bilan et perspectives

54

La difficult conceptuelle dans la mise en uvre des nouvelles fonctions a rsid principalement dans le fait que l'architecture existante fournissait peu de libert quand l'insertion de code permettant son ouverture. De plus, il tait risqu de raliser d'importantes modifications dans le code avant la sortie du produit. C'est pourquoi, il a t insr dans l'architecture un code qui permet l'ouverture sans impacter le fonctionnement et la stabilit de NetWall. Ceci nous a limit pour le dveloppement de certaines fonctions comme la cration de listes de contrle d'accs dans le driver. En outre, la conception de fonctions de filtrage, utilisant la librairie open framework, est plus complique et demande une certaine connaissance de NetWall. Ces contraintes nous ont conduits raliser une librairie qui a une forte adhrence NetWall notamment pour la gestion de la translation d'adresse. Par ailleurs, la mise en uvre sur diffrents systmes d'exploitation s'est rvle complique car certaines fonctions ncessaires au fonctionnement de NetWall n'taient pas prsentes sur toutes les plates-formes. Nous avons donc t contraints d'effectuer quelques modifications dans l'architecture de l'open framework.

Toutes nos ralisations ont t bases sur lutilisation des mthodes et outils de dveloppement standards de Bull, en particulier l'environnement ODE (OSF Dveloppement Environnement) et loutil CMVC (Configuration Management Version Contrle) pour la gestion des modifications sur le code source. Le principe de fonctionnement de ces outils est rsum ici. Pour travailler sur des fichiers, le dveloppeur effectue une copie de la dernire version des fichiers dans son environnement de dveloppement, en utilisant une commande de l'outil ODE. Il peut alors effectuer tous les travaux ncessaires sans perturber les autres personnes travaillant sur le projet. Lorsquil a termin son codage et les tests d'intgrations, il utilise une commande ODE afin de soumettre ses fichiers dans la base commune. Si, entre temps, un autre dveloppeur a modifi et soumis les mmes fichiers, un mcanisme permet de fusionner les deux versions. La soumission se fait sous le contrle de l'administrateur de l'outil CMVC. La procdure de validation est la suivante, le dveloppeur doit faire les tests unitaires de fonctionnement, puis il fait l'intgration de son code et teste le fonctionnement de son application ou de ses modifications. Une fois ces tests accomplis, l'quipe de validation effectue des tests de "stress" et de non-rgression sur la totalit du produit. Elle vrifie aussi que le programme rpond bien au cahier des charges ou au document de spcification. Si les testeurs dtectent un disfonctionnement, ils assignent un dfaut au dveloppeur en utilisant l'outil CMVC. Ce dernier est charg de la correction, il resoumet ensuite son programme l'quipe de validation.

4.2

Perspectives

Dans cette section, nous prsentons essentiellement quelques perspectives d'extension court terme, dont l'objet est de complter directement le travail ralis dans mon projet de DRT. Pour conclure, il est fait tat de quelques perspectives plus long terme sur un usage plus approfondi de l'environnement agents pour la dtection des attaques. Librairie en Java pour la gestion des entres caches

NetWall fournit la librairie "lib_ofw" et la librairie "lib_sdk". Ce sont des librairies codes en langage C, dpendantes des plates-formes sur lesquelles elles sont utilises. De plus, elles sont relativement adhrentes au driver de NetWall. Leur emploi demande une certaine connaissance et comptence dans la gestion des connexions, propose par le driver de NetWall. Ainsi, les translations d'adresses sont disponibles au travers de ces librairies mais cela demande une expertise indniable de NetWall pour mettre en place un tel mcanisme.

Bilan et perspectives

55

Il serait intressant de fournir une librairie en langage Java base sur les librairies open framework et sdk. Elle pourrait offrir une couche d'abstraction supplmentaire et ainsi se dtacher compltement du driver. La gestion des connexions serait plus simple et tous les problmes de dpendance du driver seraient carts. Cette librairie serait directement utilisable dans des programmes Java, ce langage devenant incontournable du fait de sa grande portabilit.

Ajouter des listes de contrle d'accs dans le driver grce l'open framework

Lajout dlments dans les listes de contrle d'accs du driver est une volution attrayante de la librairie open framework. En effet, cela permettrait l'open framework de grer les connexions de bout en bout, ce qui viterait l'ajout d'une rgle au niveau de l'interface graphique de NetWall, puis une appropriation de cette dernire par l'open framework. La gestion des entres caches deviendrait alors beaucoup plus simple, car dans ce cas, il ne serait plus ncessaire de crer des entres caches en se proccupant : - des actions appliquer aux paquets, - de la translation d'adresse, - dautres mcanismes, telle que la gestion des tats de la connexion TCP. Toute la gestion des connexions serait faite par le driver. L'inconvnient d'un tel ajout rsiderait dans limpossibilit de visualiser les rgles de filtrage ajoutes par l'open framework. En effet, L'ajout de ces rgles tant dynamique, lorsque NetWall fonctionne, il faudrait prvoir une communication entre le driver et linterface graphique.

Gestion des logs

- Outil de configuration Une grande entreprise dont les locaux sont distants gographiquement peut tre scurise de faon globale et centralise grce la version 5.0 de NetWall. Ainsi, cette nouvelle version n'est plus un pare-feu isol sans relation avec les autres pare-feu de l'entreprise. Il est capable de crer des domaines de scurit non plus restreints une zone gographique dtermine, mais englobant un domaine de scurit virtuel. Ceci implique une forte coopration entre tous les systmes NetWall de l'entreprise qui peuvent tre grs de manire globale et centralise. Dans ce nouvel environnement de scurit o NetWall se prsente comme un des leader du march, il est indispensable d'intgrer une notion de gestion globale et centralise de logs. C'est pourquoi, fort d'une exprience en gestion d'applications rparties et distribues, l'quipe du projet AAA fournit des outils base d'agents et de Java pour cette gestion. Cependant, il manque un outil de configuration permettant d'exploiter la totalit des fonctionnalits livres avec l'outil de gestion de logs. En effet, seules trois configurations standards sont disponibles dans NetWall. Or, cet outil a des capacits bien suprieures. Par exemple, il offre la possibilit de grer les logs par rapport des domaines de scurit. Les logs pris sur un domaine interne, non critique pour l'entreprise, n'ont pas une importance primordiale. Il serait donc intressant de disposer dun minimum de logs et de les conserver durant une courte priode. Par contre, un domaine jug sensible, comme les finances ou Internet, demande une attention particulire. Il est donc intressant d'avoir un maximum de logs et de les conserver plus longtemps. - Fichier de log L'application de gestion des logs de l'quipe AAA utilise le fichier "cnx.ulm" gnr par NetWall pour raliser le traitement demand par l'administrateur. Une analyse du fichier de logs est effectue, localement, sur chaque NetWall, puis le rsultat est envoy un collecteur, charg de traiter de

Bilan et perspectives

56

manire globale les informations qu'il reoit. Le collecteur est une machine indpendante dont la localisation gographique dpend de l'administrateur. Il serait possible d'optimiser la collecte d'informations en se branchant directement sur le driver et sur les proxies de NetWall. Ceci viterait l'tape d'criture et de lecture dans le fichier "cnx.ulm", ainsi que la prise de verrou avant l'criture dans ce fichier. L'information serait collecte directement et non plus toutes les x minutes. Il serait alors possible de ragir plus vite dventuelles attaques. Une perspective plus long terme concerne l'utilisation des agents AAA pour la dtection en ligne de certains types d'attaques et pour la mise en place immdiate de ractions associes. En effet, l'environnement AAA permet de dfinir et de configurer la demande des agents de filtrage qui peuvent donc tre associs la dtection d'vnements particuliers.

4.3

bilan personnel

Pour conclure ce document, je donne ci-aprs quelques rflexions personnelles sur l'exprience acquise travers ce projet de DRT. Ceci concerne plus particulirement le savoir-faire en matire de noyau de systme d'exploitation et de technologie pare-feu d'une part, et le bilan d'une opration de transfert de technologie d'autre part. acquisition de connaissances

L'extension des fonctionnalits de NetWall, m'a permis de dcouvrir des systmes d'exploitation, de me former sur AIX, Solaris, Windows NT et linux. Une part importante de mon travail a concern le dveloppement de fonctionnalits se trouvant dans le noyau des systmes d'exploitation et ainsi de me familiariser avec le fonctionnement de ces noyaux. Cet apprentissage a t trs enrichissant, notamment au niveau de limportante rigueur et du caractre spcifique associs au dveloppement dextensions d'un driver. En effet, la recherche dune erreur au travers dun environnement dexcution pas pas nest pas possible. De plus, le moindre problme d'adressage en mmoire peut avoir des consquences importantes. Un pointeur non initialis ncessite souvent un redmarrage de la machine quand il ne sagit pas dune rinstallation complte du systme dexploitation. A la suite d'un tel problme, il faut rechercher la cause du dysfonctionnement, dans un fichier contenant limage de la mmoire au moment de lerreur. Ceci se fait l'aide dun dbogueur. La convivialit limite de ces outils rend lanalyse longue, complique et ncessite une grande exprience dans ce domaine. Il savre donc indispensable dinsrer dans le code source de nombreuses traces, qui permettent de suivre le droulement du programme.

Un pare-feu est un systme ou un groupe de systmes qui permet de mettre en uvre une politique de contrle daccs entre diffrents rseaux. Conceptuellement il y a deux types de pare-feu selon qu'on s'intresse au niveau IP ou au niveau applicatif. Les pare-feu de niveau IP prennent gnralement leurs dcisions en se basant sur les adresses source, destination et les ports indiqus dans chaque trame TCP/IP ou UDP/IP, pris individuellement. Ils grent des informations internes sur ltat de chaque connexion filtre, le contenu des flux de donnes, etc. La caractristique la plus importante en ce qui concerne la plupart des pare-feu de niveau IP est quils routent le trafic directement travers eux. Ils tendent devenir trs rapides et transparents pour les utilisateurs. A linverse, les performances dun rseau peuvent tre rduites de faon importante par un pare-feu applicatif. Ce type de pare-feu est surtout utilis pour le filtrage de verbes ou dactions associs un service spcifique (telnet , ftp, http, ) Peu peu, les pare-feu de niveau IP tendent devenir plus "conscients" de linformation qui les traverse et les pare-feu de niveau applicatif acquirent une certaine transparence. De plus en plus, les

Bilan et perspectives

57

pare-feu supporteront le cryptage afin de protger le trafic qui passe entre eux par lintermdiaire dInternet. NetWall est un pare-feu complet puisqu'il propose un filtrage IP et un filtrage au niveau applicatif. Il offre galement une solution pour permettre de crypter les donnes qu'il change avec un autre NetWall ou un autre progiciel de scurit.

Travailler dans le domaine de la scurit informatique et pour l'volution d'un pare-feu implique de s'intresser aux diffrentes attaques connues et la possibilit d'engendrer des trous de scurit lors de son dveloppement. Les attaques peuvent tre classes comme suit : Classe d'attaque Ecoute passive Vol de mot de passe Usurpation d'identit Protocoles incrimins Slip, icmp, smtp, snmp, dns, http, X Slip, ftp, telnet, r-command ppp, ip, arp, tcp, udp, ftp, smtp, pop, telent, r-command, rcp, nfs, snmp, dns, imap Dni de service ip, snmp, icmp, tcp, dns Corruption du client ou du serveur ip, udp, smtp, telent, r-command, rcp, nfs, http, script java Divulgation illicite d'informations ftp Contrle d'un hte par Tous les protocoles exploitation de bogue J'ai t confront deux types d'attaques. La premire tait un trou de scurit de NetWall. Il s'agissait d'un bogue dans la mthode de filtrage pour les usurpations d'adresses. La deuxime tait une nouvelle attaque de type recouvrement de fragments. Les contrles pour empcher ces deux attaques ont t mis en place dans toutes les versions de NetWall. Transfert de technologie Inria Bull

Le travail du Diplme de Recherche Technologique s'inscrit dans un programme de recherche et ralise un transfert de technologie des rsultats du laboratoire vers le groupe Bull. En effet, le laboratoire SIRAC mne depuis plusieurs annes des recherches dans le domaine des systmes et applications rparties. Lobjectif gnral du laboratoire est de concevoir et de raliser des services et outils pour le dveloppement et lexcution dapplications rparties. A cet effet, le laboratoire dveloppe des technologies utilisant une programmation base dobjets et des techniques de programmation par agents. Par consquent, NetWall se pourvoit d'une technologie de pointe en intgrant, les fonctionnalits base d'agents et de programmation par objets en Java. Ce transfert de technologie a t mis en uvre deux reprises, la premire lors de la ralisation du plugin H.323. La deuxime, lors de l'volution dans le traitement et la gestion des logs.

58

GLOSSAIRE

Glossaire

59

AAA ACL anti-spoofing boot datagrame dispatcheur driver de NetWall entre cache file descriptor flag ftp ftpd GUI H.323 ioctl kernel listener Mbuf multi-thread Netbiosd Netmeeting Netwalld Port port-mapper Proxy, proxies rshd/rexecd Spoofing SQL*Net Sun-RPC TCP/IP

Timer

Agents Anytime Anywhere Liste de Contrle d'Accs Anti-usurpation d'adresse IP Dmarrage du systme d'exploitation Paquet comprenant en-tte IP, en-tte TCP et les donnes de l'application Permet de dispatcher les ports de connexion des serveurs multi-thread Composant qui effectue le filtrage IP Structure permettant des contrles d'accs trs rapide Point d'entr dans le noyau du systme d'exploitation Drapeau Protocole de transfert de fichiers Dmon du protocole ftp interface graphique utilisateur protocole d'audio et vido confrence sur Internet Commande d'change de structure entre le noyau et l'espace utilisateur noyau du systme d'exploitation dmon d'coute du protocole SQL*Net Paquet Internet Serveur oracle grant plusieurs port de connexion SQL*Net Dmon de netbios Logiciel de visioconfrence sur Internet Dmon de NetWall Porte d'entr un service Fournisseur de porte (Sun-RPC) Passerelle applicatif Dmon des r-commandes usurpation d'adresse IP nom gnrique dsignant lensemble des couches ncessaires la communication entre clients et serveur oracle Remote procedure call de Sun Transfer Control Protocol/Internet Protocol. Il s'agit du protocole de communication utilis sur Internet. Il est simple, robuste et est support dans la plupart des environnements. Minuterie

60

REFERENCES

Rfrences

61

Oracle, White Paper SQL*Net and Firewalls Oracle, White Paper SQL*Net Support in Gauntlet Internet Firewalls http://www.tis.com INRIA, Base Rpartie configuration et Installation Bull, External Interface Specification, NetWall Kernel Bull, Software Design Sepcification, NetWall: Windows NT version Bull, NetWall Administrator's Guide (rfrence :86 A2 51 KX 01) Dyade, AAA spcification, Architecture dagents. Dyade, Agent Infrastructure: The Agent Anytime Anywhere Platform http://www.dyade.fr/actions/aaa/aaa.html http://www.dyade.fr http://dyade.inrialpes.fr SCSSI, Panorama des vulnrabilits d'Internet http://mirror.ox.ac.uk/rfc.html ITU-T Recommandation H.225.0, version 2, call signaling protocols and media stream packetization for packet based multimedia communications systems. ITU-T Recommandation H.323, visual telephone systems and equipment for local area netwaorks which provide a non-garanteed quality of service. Intel, H.323 and firewalls, intel internet video phone. http://support.intel.com/support/videophone/trial21/interfaq.htm http://support.intel.com/support/videophone/trial21/h323_wpr.htm

62

ANNEXES

Annexes

63

1.1

Fonctions couvertes par NetWall

1.1.1 Filtrage dynamique au niveau IP


Gestion de contextes concernant ltat des connexions TCP et des pseudo connexions UDP. NetWall garantit que les paquets de retour, correspondent vritablement une connexion en cours. Pour ce faire, NetWall gre un automate dtat, qui suit ltat de la connexion TCP dans son volution, ou utilise une technique de timer dinactivit pour le trafic UDP. Contrle dynamique des connexions alloues par les services tels que FTP, RPC, Netbios, SQL*NET, rcp/rshell/rexec. NetWall, grce aux capacits de filtrage dynamique intgrant des fonctionnalits d'analyse intra protocole dtaille, scrute le trafic destination des processus dallocation dynamique de ports (ftpd, portmapper, netbiosd, listener, rshd/rexecd). Il reconnat les demandes douverture de connexions annexes ou attaches, ouvre alors un contexte et peut dynamiquement autoriser une connexion secondaire vers le port allou. Cette autorisation sera automatiquement supprime ds que la connexion secondaire en cause sera referme. Exemple : Contrle dynamique des connexions de donnes FTP en relation avec la connexion de contrle. NetWall scrute les changes sur la connexion de contrle de FTP, analyse les requtes douverture de ports (commandes PORT et PASV de FTP). Il gre alors un contexte dcrivant lensemble de la session FTP et garantit ainsi que les connexions de donnes de FTP sont effectivement issues de la connexion de contrle en cours. Gestion scurise de la fragmentation IP. En cas de fragmentation IP, les informations pertinentes en terme de filtrage sont situes dans le premier fragment. Les autres fragments doivent alors tre traits en fonction du premier fragment. NetWall est capable de contrler la cohrence de cette fragmentation, afin dappliquer la mme politique de scurit sur le premier fragment que sur les autres fragments. Translation statique et dynamique des adresses. Permet le masquage des adresses des rseaux internes par rapport aux rseaux externes, et permet de cacher les adresses des postes clients initiant des connexions vers lextrieur derrire ladresse du garde-barrire. Ce masquage est effectu par les mthodes suivantes : - Translation statique dadresses IP. Pour chaque adresse IP relle, ladministrateur peut dfinir dans NetWall une adresse IP virtuelle, constituant ainsi des tables de translation. Les adresses source et/ou destination dans les paquets IP sont modifies la vole lors du traitement des paquets, en fonction de ces tables de translation. Dans ces conditions, seules les adresses dclares comme virtuelles (i.e. celles dfinies par ladministrateur dans la table de translation) sont visibles depuis les autres rseaux. Cette caractristique peut permettre de masquer la fois des adresses de clients (initiateurs de connexions) ou de serveurs (receveurs de connexions). - Translation dynamique dadresses IP. Une adresse est automatiquement alloue lorsquun utilisateur tablit une connexion au travers de la cible dvaluation depuis un rseau vers un autre. Cette adresse est celle de la plateforme supportant NetWall elle-mme (adresse de linterface rseau par laquelle doit sortir le paquet). Ladresse source prsente dans len-tte du paquet est remplace par cette valeur.

Annexes

64

Pour le traitement des paquets de rponse, NetWall mmorise ltat de la connexion et peut ainsi faire lopration en sens inverse et retrouver la machine qui a initi cette connexion. De cette manire, la machine externe destinataire de la connexion ne voit que ladresse de linterface rseau de NetWall avec laquelle il communique et non ladresse de la machine qui a initi cette connexion. Par principe, la translation dynamique na de sens que pour des connexions sortantes, cest dire que la translation dadresse ne peut sappliquer que sur ladresse de la machine qui initie lchange, et en aucun cas sur celle de la machine destinataire de lchange. Cette translation dynamique ne sapplique quaux protocoles TCP et UDP. Anonymat des machines. Ladministrateur peut configurer NetWall pour que la commande ping ne le traverse pas. Cela vite les attaques visant connatre les noms des machines du rseau protg par des requtes ICMP de type "echo request", envoys par la commande ping. Dispositif de protection contre lusurpation dadresses IP (anti-spoofing) conforme la recommandation CERT (CA-95:01). Lattaque consiste pour une station dun rseau, se faire passer pour une machine dun autre rseau, dans le but de bnficier de ses droits. NetWall contrle, partir de ladresse source telle quinscrite dans le paquet en cours de filtrage, la cohrence entre linterface rseau sur laquelle le paquet est attendu et linterface rseau par laquelle le paquet est entr. Pour chaque adresse ou groupe dadresses de machine de sous-rseau ou de rseau, ladministrateur doit indiquer lors de la configuration de NetWall sur quelle interface les paquets issus de ladite adresse doivent arriver. En cas dincohrence, NetWall dtruit les paquets. Filtrage des options IP. NetWall peut rejeter les paquets contenant des options IP telles que par exemple les options de routage selon la source souvent la base dattaques.

1.1.1 Fonctions de log et daudit.


NetWall enregistre les informations relatives sa propre activit. Il offre ladministrateur la possibilit de filtrer et dexploiter ces informations.

1.1.2 Configuration et administration via une interface graphique conviviale.


Relais applicatifs permettant des contrles ou filtrages internes aux protocoles applicatifs, comme par exemple le filtrage des commandes internes de FTP pour autoriser ou refuser les accs en lecture et/ou en criture.

1.1.3 Authentification des utilisateurs au niveau des relais applicatifs


S/Key Une liste de mots de passe est gnre partir dun mot de passe connu de lutilisateur. La liste de mots de passe drive est connue de NetWall et de lutilisateur. Ce dernier doit fournir comme mot de passe chaque nouvelle demande dauthentification le mot de passe suivant dans cette liste. Mots de passe simples

Annexes

65

Challenges et Rponses MD5 Authentification des utilisateurs par carte puce CP8 Authentification des utilisateurs par des serveurs dauthentification externes - Radius - SecureID - Active Card - Access Master MD5 SKey X X X X X X NO NO NO NO NO NO NA NA NO NO NO NO SecurID AccessMaster ActivCard X X (no SSO) X X X (full SSO) X X X (full SSO) X NO NO NO X X (no SSO) X X X (no SSO) X NA NA NA NO X (no SSO) X X X (no SSO) X (Cookie Mode) (Cookie Mode) RADIUS X X X NO X X NA X X

Password IP Authentication X FTP X Telnet X Generic NO POP X IMAP X Mail NA HTTP/FTP X Reverse HTTP X

X = Authentification possible. NO = Pas d'authentification. NA = Non applicable. SSO = Single Sign On.

1.1.4 Fonctions de coopration des relais applicatifs avec des produits externes dAntivirus 1.1.5 Contrle distance scuris
Fonctionnalit garantissant lauthentification mutuelle et lintgrit des donnes changes entre la station dadministration et le(s) garde-barrire(s) administr(s). Cette interface donne accs lensemble des fonctionnalits dadministration de NetWall, et reste compatible avec ladministration locale par linterface graphique sur une console directement raccorde (gestion de verrous contrlant les conflits daccs).

1.1.6 Fonction dalerte dynamique


Fonctionnalit fournissant une infrastructure permettant ladministrateur de recevoir des alertes dynamiquement, en fonction dvnements et de conditions de son choix. En fonction de la configuration dfinie par ladministrateur, NetWall peut excuter un certain nombre dactions de manire prvenir ce dernier de loccurrence dvnements relatifs la scurit. Ces actions peuvent tre lenvoi dun trap SNMP, lenvoi dun message SMTP, laffichage dun message sur la console dadministration ou lexcution dun programme fourni par ladministrateur.

Annexes

66

1.2

Agent Anytime Anywhere

1.2.1 Ralisation
1.2.1.1 La classe AgentId

Lidentificateur dagent AgentId doit permettre d'identifier et de localiser de manire unique chaque agent dans le systme. Les agents doivent pouvoir tre crs distance d'un serveur sur un autre ; afin de permettre la mmorisation de l'identification de l'agent cr par l'agent crateur, la gnration des l'AgentId est ralise par le serveur initiateur. En consquence, il doit donc rpondre deux critres :

localisation statique des agents afin de permettre lacheminement des notifications ; gnration locale des agents crs distance.
creation engine 16bits localisation engine 16bits stamp of object 32bits

Format des identificateurs dobjets Afin de rpondre ces exigences, l'identificateur d'agent est constitu de trois parties : l'identification du serveur d'agents de l'agent crateur (attribut from), l'identificateur du serveur d'agents de rsidence de l'agent cr (attribut to), une estampille locale au serveur d'agents de l'agent crateur (attribut stamp). L'attribut to constitue l'indication de localisation de l'agent1, l'ensemble constitue l'identificateur global unique de l'agent. Actuellement chaque serveur d'agents gre deux zones d'estampilles : une zone pour les agents locaux, une zone pour les agents crs destination d'autres serveurs2. aaa/agent/AgentId.java public class AgentId implements Serializable, Cloneable { private static int current[]; static void init() throws IOException {} public short from; public short to; public int stamp; AgentId() {} AgentId(short to) {} AgentId(short from, short to, int stamp) {} public int hashCode() {} public boolean equals(Object obj) {} } La classe AgentId ralise l'interface Serializable afin de permettre la srialisation des identificateurs d'agents pour les besoins de persistance et de communication, elle ralise l'interface Cloneable afin de permettre leur duplication. Ses mthodes hashCode et equals sont prvues pour en permettre une utilisation comme cl dans une table de hachage.

1 2

Actuellement, les agents ne sont pas censs migrer, cette information est donc toujours jour. On pourrait comme dans la version C++ grer autant de zones que de serveurs.

Annexes

67

1.2.1.2

La Classe Agent

La classe Agent est une classe abstraite qui dfinit linterface et le comportement commun l'ensemble des agents : tous les agents sont des instances de classes qui hrite de celle-ci ; ces fonctions se dcomposent en plusieurs parties : L'interface d'accs au bus de message ; linterface de la mthode de raction aux notifications ; l'identificateur unique et le nom de l'agent ; les donnes et mthodes statiques permettant la gestion des agents en mmoire ; les mthodes de cration des agents. 1) L'interface d'accs au bus de messages La mthode sendTo permet d'envoyer une notification l'agent spcifi en paramtre. Elle permet de fixer l'identificateur de l'metteur avant d'utiliser la mthode sendTo de la classe Channel ; cette mthode est protge afin d'en empcher l'utilisation par une entit autre que l'agent.
aaa/agent/Agent.java public abstract class Agent implements Serializable { protected void sendTo(AgentId to, Notification not); public void react(AgentId from, Notification not); }

2) L'interface de raction La mthode react est excute par le moteur d'excution au sein d'une transaction lors du traitement d'une notification destine l'agent. La mthode react dfinie dans la classe Agent dtermine le traitement par dfaut apporter aux notifications d'erreurs de la machine agents : destinataire d'une notification inconnu, aucun traitement connu appliquer la notification, etc. 3) La gestion d'agents en mmoire Les agents sont des entits persistantes et la classe Agent encapsule le mcanisme de "swap-in/swapout" qui permet de charger (ou retrouver) en mmoire principale les agents utiliser et de dcharger sur disque les agents inutiliss depuis un certain temps3. Ce mcanisme est mis en uvre au moyen d'une table de hachage, Agent.agents dont la cl est l'AgentId, qui conserve la liste des agents actuellement prsents en mmoire ; la date de dernier accs est elle conserve dans l'tat de l'agent. La mthode load permet de retrouver dans la table de hachage l'agent dont l'identificateur global est pass en paramtre ; si cet agent n'est pas prsent, il est alors charg depuis le disque. La mthode save permet de sauvegarder sur disque l'image d'un agent. Afin de permettre les oprations de chargement/dchargement, la classe Agent implmente l'interface Java Serializable qui permet la srialisation (resp. dsrialisation) d'un objet afin de le stocker (resp. charger) dans un fichier. La mthode garbage est appele lorsque le nombre d'agents en mmoire devient trop important, elle permet de vider tous les agents qui n'ont pas t accds depuis un certain temps. Certains agents devant tre chargs en permanence, l'attribut protg fixed permet de les fixer en mmoire (cf. 5)). Ces fonctions ne sont utilises que dans la boucle de traitement du moteur d'excution et ne ncessitent donc aucune synchronisation.

A un instant donn, seul l'agent en cours d'excution ncessite rellement d'tre charg.

Annexes

68

aaa/agent/Agent.java public abstract class Agent implements Serializable { static Hashtable agents; public static void init() {} public static Agent load(AgentId id) {} public void save() throws IOException {} }

4) La cration d'agents La cration des agents s'effectue en trois phases : 1. La cration locale d'une image de l'agent via les constructeurs publics de sa classe : cet objet possde l'identificateur dfinitif du futur agent et peut-tre manipul comme n'importe quel objet mais il n'est pas persistant et il ne peut pas recevoir de notifications. 2. L'initialisation des attributs de l'agent au travers de l'interface de l'objet. 3. Le dploiement lanc par l'appel de la mthode deploy4 sur l'objet. Cette mthode cre une notification AgentCreateRequest contenant l'tat srialis de l'agent et l'envoie l'agent AgentFactory charg de la cration des agents au sein du serveur de destination de l'agent. Une fois que l'agent a t dploy, il ne peut plus tre utilis qu'au moyen d'envoi de notifications ; la proprit de causalit du bus de message et l'atomicit de la raction de l'agent AgentFactory permettent d'adresser des notifications l'agent cr ds son dploiement.

Certains agents5 sont crs via des constructeurs spciaux de la classe Agent permettant de fixer leur identificateur, ou de positionner des attributs protgs. Ces constructeurs ne sont accessibles que par les classes du package aaa.agent.
aaa/agent/Agent.java public abstract class Agent implements Serializable { private AgentId id; public String name; protected boolean fixed; public Agent(short to, String n) {} Agent(short to, String n, boolean f) {} Agent(String n, boolean f, AgentId id) {} public void deploy() {} }

5) Les agents "fixs" en mmoire Certains agents pourront tre fix en mmoire, c'est dire qu'ils seront chargs et initialiss lors de chaque dmarrage du serveur, puis conservs en mmoire durant toute la dure d'excution du serveur d'agents ; une mthode de finalisation sera appele lors de la terminaison du serveur...

Les agents "fixs" en mmoire sont crs au moyen de constructeurs protgs de la classe Agent et accessibles uniquement depuis le package aaa.agent. Ces agents sont enregistrs dans une liste permettant de les charger lors du dmarrage du serveur ; ils ne sont supprims de la mmoire du serveur que lors de la terminaison de celui-ci.
Cette mthode est dfinit dans la classe Agent et elle ne peut pas tre surcharge. Par exemple, les agents AgentFactory afin qu'ils puissent tre facilement identifiable en l'absence d'un service de dsignation.
5 4

Annexes

69

Lors de leur chargement, le systme appelle la fonction initialize afin de permettre l'initialisation de leur contexte ; lors de la terminaison, la fonction finalize peut-tre utilise pour librer les ressources des agents en mmoire. Les agents "fixs" en mmoire sont utiliss par exemple pour la ralisation des agents qui grent les communications avec l'extrieur.

1.2.1.3

Les classes Notification et Message

La classe Notification dfinit la racine commune lensemble des notifications ; elle ralise la srialisation et la duplication de toute notification. Chaque notification est parfaitement identifie par son metteur, son destinataire et son contenu.
aaa/agent/Notification.Java public class Notification implements Serializable, Cloneable {}

Une notification n'est jamais stocke en tant que tel, elle fait toujours partie d'un objet Message qui prcise son metteur et son destinataire, soit dans une queue de messages, soit dans une liste de messages en attente de dlivrance dans le composant rseau. Les objets de la classe Message sont dsigns par un identifiant local unique qui permet de les retrouver dans l'espace de stockage. La classe Message est compose de deux parties, la premire concerne la gestion des identificateurs de message ; outre l'aspect synchronisation, le seul vrai problme rsoudre est d'viter la gnration de deux identificateurs identiques entre deux sessions successives. Afin d'viter d'avoir sauvegarder l'identificateur courant lors de chaque allocation, on conserve un identifiant de session dans celui-ci6. La seconde partie de la classe Message se compose des donnes des objets Message, des constructeurs et des oprations de sauvegarde et de restauration.

On pourrait ventuellement factoriser l'criture de l'identificateur courant lors du commit en utilisant une opration de sauvegarde explicite.

Annexes

70

aaa/agent/Message.Java public class Message implements Serializable { static int current; static void init(short session) { current = ((int) session) << 16; } static synchronized int newStamp() { return (++current); } AgentId from; AgentId to; int stamp; Notification not; void save() throws IOException { Transaction.save(this, "Message" + stamp); } static Message load(long stamp) throws IOException { return (Message) Transaction.load("Message" + stamp); } /* Construct a new empty message in order to restore from disk. */ public Message() {} /* Construct a new message. */ public Message(AgentId _from, AgentId _to, Notification _not) { }

1.2.1.4

Le bus de message

La classe Channel fournit linterface denvoi dune notification dun agent un autre ; la classe Channel est responsable de la localisation de lagent destinataire : en fonction de cette localisation, elle dposera le message soit dans la queue de message qin afin quil soit traiter localement par le moteur d'excution, soit dans la queue qout afin quil soit trait par la couche rseau.
aaa/agent/Channel.java public class Channel { public static Channel channel; private Queue mq; public synchronized void sendTo(AgentId from, AgentId to, Notification not) throws IOException { } }

La classe MessageQueue fournit l'implmentation de la partie destinataire du mcanisme de communication. Les messages7 ayant une dure de vie faible, la liste de messages FIFO est conserve en mmoire principale au moyen d'un vecteur ; cette liste possde une image persistante. 1) Persistance et atomicit Les queues de messages qin et qout sont les seuls objets partags entre les diffrents threads : moteur d'excution et composants rseau ; cette particularit implique de nombreux problmes de gestion de transaction : verrouillage, isolation, etc.
7

Couple <notification, identificateur de lagent destinataire>.

Annexes

71

Afin d'viter la gestion de transactions parallles on restreint la dure de chaque transaction et on les srialise. L'aspect transactionnel portant uniquement sur les images disques des objets, il suffit d'isoler les accs aux objets partags (les queues de messages) et de raliser les sauvegardes en section critique. Afin de faciliter la gestion de l'atomicit, les notifications sont conserves dans une queue interne au bus de message jusqu'au point de validation ; elles sont alors recopies dans les queues de messages qin et qout. Pour diminuer le surcot du la sauvegarde lors de chaque opration d'insertion (push) et de suppression (pop), les objets Message sont sauvegards indpendamment et seule la liste des identificateurs de message est sauve. La mthode Restore n'est utilise que pour restaurer l'intgralit de la MessageQueue au lancement du programme.

1.2.1.5

Le moteur d'excution

La classe Engine est la pice centrale de l'architecture : dans sa boucle de traitement, elle distribue les notifications aux agents et elle s'assure de l'aspect transactionnel de la raction une notification. L'engine est un objet actif qui hrite de la classe Thread ; son rle est de prendre successivement les messages de la queue qin et d'appeler la mthode react des agents destinataires avec la notification en question. Afin d'assurer la proprit d'atomicit de la raction, la squence d'oprations est ralise au sein d'une transaction :

en cas de terminaison correcte, on assure la conservation des changements lis la raction : sauvegarde de l'tat modifi de l'agent, enregistrement des notifications gnres par la raction et suppression de la notification traite ; en cas d'erreur, annulation de tous les changements effectus.
aaa/agent/Engine.java

public class Engine extends Thread { public Engine() {} public void run() { while (true) { Message msg = qin.get(); agent = Agent.load(msg.to); try { agent.react(msg.from, msg.not); } catch ( ) { }; // Suppress the processed notification from message queue. qin.pop(); // Push all new notifications in qin and qout, then saves changes. channel.dispatch(); // Saves the agent state then commit the transaction. Agent.save(); } } }

Le constructeur de la classe Engine initialise le thread et dmarre la mthode run qui contient la boucle du moteur d'excution. 1) Traitement en cas d'erreurs Si l'agent destinataire de la notification est inconnu, le moteur d'excution retourne une notification UnknownAgent l'agent source.

Annexes

72

Si l'agent destinataire ne sait pas traiter la notification il gnre une exception UnknownNotificationException, cette exception est rcupre par le moteur d'excution qui retourne alors une notification UnknownNotification l'agent source. Dans ces deux cas, le moteur d'excution valide les rsultats de la raction. Si une exception survient durant le traitement de la raction, le moteur d'excution restaure l'tat de l'agent depuis son image persistante, puis il dtruit le notification fautive et il efface les notifications gnres par la raction. 2) Gestion de l'atomicit En cas de bonne terminaison de la raction, le moteur d'excution commence une transaction pour enregistrer les rsultats obtenus ; la transaction assure l'atomicit et la persistance des diffrents changements : suppression de la notification traite de la queue de messages qin, destruction sur disque du message associ, distribution des notifications gnres par la raction dans les queues de messages qin et qout, sauvegarde de l'tat modifi de l'agent. La transaction peut alors tre valide. Le traitement atomique de ces actions est important afin que si une erreur survient durant cette phase, le systme puisse repartir dans l'tat prcdant la transaction. Une fois la transaction valide, on peut rendre visibles les notifications ajoutes dans les queues de messages qin et qout avant de librer le verrou transactionnel. En cas de problmes durant la raction, le moteur d'excution commence une transaction pour rparer : restauration de l'tat de l'agent, suppression de la notification fautive de la queue de messages qin, destruction sur disque du message associ, nettoyage du bus de messages de toutes les notifications gnres par la raction.

1.2.1.6

Les composants rseau

Le problme rsoudre est la mise en place d'un systme de communication pour l'envoi et la rception de messages entre les serveurs ; pour diffrentes raisons ce systme doit se situer au dessus de IP. 1) Architecture La couche de communication est constitue de plusieurs composants actifs : le composant NetServerIn gre l'ensemble des messages reus par le serveur : notifications, messages de service, etc ; le composant NetServerOut met les notifications destination des autres serveurs ; Ces diffrents composants interagissent entre eux et avec le moteur d'excution, la synchronisation et la gestion des transactions est donc cruciale. 2) Identification et localisation Les serveurs d'agents sont identifis statiquement lors du dploiement de l'application ; A tout moment un nouveau serveur peut tre cr, la destruction d'un serveur implique la destruction pralable de tous ses agents. 3) Notifications distribues Hormis les proprits de fiabilit du systme de communication, il faut garantir le traitement transactionnel de la raction une notification. Pour ce faire, l'ensemble des changements relatifs une raction est enregistr dans une seule et mme transaction du moteur d'excution, le transfert des notifications distantes est ensuite ralis en asynchrone par le composant NetServerOut :

Annexes

73

1. Lorsqu'un agent signale une notification, celle-ci est stocke dans une file interne au bus de message. 2. Lors de la fin de la raction, le contenu de cette file est diffus dans la queue qin pour les notifications destination d'agents locaux, dans la queue qout dans le cas contraire ; la transaction valide le traitement atomique de la raction est alors assur. 3. L'activit asynchrone du composant NetServerOut prend alors chaque notification dans la queue qout et insre le message correspondant dans une liste locale durant une transaction, puis les communique aux serveurs destinataires. 4. Associ chaque serveur, le composant NetServerIn reoit les notifications en provenance des autres serveurs et les incorpore dans la queue locale qin durant une transaction ; aprs avoir valid la transaction, et donc avoir assur la permanence du message reu, le rcepteur envoie l'acquittement l'metteur. 5. Aprs avoir reu l'acquittement, l'metteur peut supprimer le message de la liste des messages mettre.
Les notifications sont transmises par valeur ; en consquence, leurs identificateurs restent des identificateurs locaux et ds qu'un message a t transmis et acquitt la notification associe sur le site source peut tre dtruite. Durant le transfert des messages d'un site un autre il faut encoder/dcoder les donnes transmises afin de rsoudre les problmes d'htrognit. Cet encodage/dcodage doit tre fait pour les objets notifications, mais aussi pour les agents lors de leurs dploiements. Pour ce faire, on utilise le mcanisme de srialisation/dsrialisation d'objets Java (cf. interface Serializable).

1.2.1.7

Persistance et atomicit

1) FSTransaction La persistance et les transactions sont ralises en utilisant le systme de fichiers de la machine hte. Chaque serveur d'agents est associ un rpertoire de persistance organis de la faon suivante :

CurrentDir state of all persistent objects

PreviousDir state of modified objects Created

Phase

Structure du rpertoire de persistance


A chaque objet est associ un fichier dont le nom est simplement le nom unique de l'objet. Ce fichier contient l'tat de l'objet tel qu'il est rendu par les primitives de srialisation Java ; ce fichier reflte l'tat courant de l'objet sil rside dans le rpertoire current, et l'tat antrieur la transaction courante sil rside dans le rpertoire previous. Lors d'une opration d'annulation de la transaction, le systme ne prend pas en charge la restauration des tats des objets en mmoire ; cette tape est la charge de l'utilisateur en se basant sur les images disques restaures.

Annexes

74

a) Initialisation : init. Cette fonction initialise le rpertoire de travail, puis teste l'tat (fichier Phase) dans lequel se trouvait le systme lors de l'arrt : si le systme a t arrt durant un commit (resp. rollback), alors init termine la phase de validation (resp. annulation) partir des informations stockes sur disque ; validation : destruction de tous les fichiers du rpertoire previous, nettoyage du fichier Created ; annulation : restauration dans le rpertoire current des fichiers modifis par la transaction8, destruction de tous les fichiers crs par la transaction9 ; si le systme a t arrt durant une transaction, alors init annule la transaction ; si le systme a t arrt normalement (en dehors de toute transaction), alors init n'a rien a faire. b) Cration d'objets Lorsqu'un objet est sauv pour la premire fois, son image est crite dans un fichier du rpertoire current, et son nom est conserv dans le fichier Created afin de savoir quels fichiers dtruire en cas de rollback. Lors de l'opration de validation, il suffit d'effacer le contenu de ce fichier afin d'entriner cette cration. L'opration de rollback consiste dtruire du rpertoire current tous les fichiers dont le nom figure dans le fichiers Created. Afin d'optimiser les oprations de validation et d'annulation " chaud", la liste des objets crs est conserve en mmoire dans un vecteur : created. c) Lecture et modification dobjets : load, save L'opration de lecture retourne simplement l'objet contenu dans le fichier correspondant du rpertoire current sil existe. Lors d'une sauvegarde, le systme recopie le fichier correspondant l'objet dans le rpertoire previous si cela n'a pas encore t fait, puis il crase ce fichier avec l'image courante de l'objet. La phase de validation consiste alors simplement a "oublier" les sauvegardes des objets modifis, en dtruisant tous les fichiers du rpertoire previous. Afin d'optimiser les oprations de validation et d'annulation " chaud", la liste des objets modifis est conserve en mmoire dans un vecteur : used. Les primitives load et save peuvent tre utilise sans problme en dehors d'une transaction. d) Destruction dobjets : delete Le fichier correspondant l'objet est simplement dplac dans le rpertoire previous ; lors du commit, le fichier est alors rellement dtruit. Si une opration rollback est excute, le fichier est restaur dans le rpertoire current. La mthode de destruction de l'objet persistant doit tre appele explicitement. e) Validation et reprise : commit, abort Ces oprations commencent par "logger" dans le fichier Phase que la transaction entre dans une phase de validation ou de reprise. L'opration commit dtruit ensuite tous les fichiers du rpertoire previous, puis elle efface le contenu du fichier Created. L'opration rollback commence par restaurer l'tat de tous les objets dont une copie apparat dans le rpertoire previous, puis elle dtruit tous les fichiers dont le nom apparat dans le fichier Created. Lors d'une validation ou d'une annulation de transaction " chaud", ces oprations utilisent les vecteurs created et used pour acclrer la dtermination des fichiers traiter. Si le systme est arrt durant ces

8 9

partir des images sauvegardes dans le rpertoire previous. dont la liste est contenue dans le fichier Created.

Annexes

75

oprations, le systme termine la validation ou la reprise lors du dmarrage suivant partir des informations sauvegardes sur disque. Le verrou de la transaction n'est pas libr immdiatement par les primitives commit et abort, il est ncessaire d'appeler explicitement la primitive release pour le faire ; ceci permet, lors d'une validation ou d'une reprise, d'effectuer un certain nombre d'oprations en exclusion mutuelle sur les objets chargs en mmoire.

1.2.1.8

Compression, cryptage, etc

Il suffit d'utiliser un ou plusieurs filtres lors des oprations de sauvegarde et restauration des objets (GZIPInputStream vs. GZIPOutputStream par exemple).

1.2.2 Extensions
1.2.2.1 La communication avec l'extrieur

1) Architecture globale Deux proprits essentielles ont t recherches lors de la dfinition de ce mcanisme de communication : bidirectionnel et indpendant de la technologie Agent. L'aspect bidirectionnel a t rendu possible par l'existence d'un agent proxy par flot de communication et donc par processus. L'indpendance vis--vis de la technologie Agent est permise par le fait que les drivers manipulent des flots de donnes fournis par l'utilisateur ; en consquence, l'utilisateur peut librement transformer les donnes transfres pour permettre le dialogue des deux entits : Notification Format propritaire Format propritaire Notification

ClientProxy TcpProxy

Processus Externe
DriverOut Channel
NotificationOutputStream

ProxyAgent

Engine

NotificationtInputStream

DriverOut

Architecture globale
Outre l'agent proxy et les objets flots de donnes, le mcanisme met en uvre deux composants actifs et une queue de messages : l'agent proxy reoit les notifications destines au processus extrieur et les insre dans une queue de messages locale ;

Annexes

76

le driver DriverOut prend les objets Notification dans la queue locale et les crit sur le flot de donnes sortant ; l'objet Notification est alors transform par l'objet NotificationOutputStream en un message comprhensible par le processus extrieur ; le driver DriverIn lit des objets Notification10 sur le flot de donnes entrant, il les dirige alors vers la queue de messages correspondante : qin ou qout ; ce driver a la responsabilit de grer l'atomicit de l'accs aux queues de messages ; Le driver DriverConnect, dont l'utilisation est optionnel permet la gestion asynchrone de la connexion.

a) Lagent proxy Le rle de la classe AgentProxy est de fournir un framework permettant de produire des agents proxy spcifique tout en maintenant la cohrence de fonctionnement de la machine agents. Il doit donc permettre la spcialisation du protocole de communication et masquer l'accs aux mcanismes interne de la machine. L'agent AgentProxy est un agent "fix" en mmoire, il a la responsabilit de l'tablissement de la connexion et de la cration des drivers : La mthode initialize cre la queue de communication avec le driver DriverIn, appelle la mthode spcifique de connexion (cration des flots de donnes d'entre et de sortie), puis cre et dmarre les drivers ; La mthode reinitialize permet de reconnecter les flots de donnes ; La mthode finalize appelle la mthode spcifique de dconnexion (fermeture des flots de donnes), puis arrte et dtruit les drivers.
aaa/agent/ProxyAgent.java public abstract class ProxyAgent extends Agent { } aaa/agent/ProxyAgent.java class DriverIn extends Driver { } class DriverOut extends Driver { } class DriverConnect extends Driver { }

b) Linterface NotificationInputStream
aaa/agent/NotificationInputStream.java public interface NotificationInputStream { /** * Gets a Notification from the stream. */ public Notification readNotification() throws ClassNotFoundException, IOException; /** * Closes the stream. */ public void close() throws IOException; }

c) Linterface NotificationOutputStream
10

Crs par l'objet NotificationInputStream partir des donnes en provenance du processus extrieur.

Annexes

77

aaa/agent/NotificationOutputStream.java public interface NotificationOutputStream { /** * Writes a <code>Notification</code> to the stream. */ public void writeNotification(Notification msg) throws IOException; /** * Closes the stream. */ public void close() throws IOException; }

2) Lagent TcpProxy L'agent TcpProxy est un exemple d'utilisation du mcanisme de communication dcrit ci-dessus ; il permet, par hritage, d'crire des Agents de gestion de flots TCP clients ou serveurs. La classe TcpProxy surcharge les mthodes initialize et reinitialize, elle dfinit les mthodes connect et disconnect, elle dfinit deux mthodes abstraites afin de fixer les filtres d'entres et sorties : SetInputFilters : permet de crer le filtre d'entre partir du flot d'entre du socket. SetOutputFilters : permet de crer le filtre de sortie partir du flot de sortie du socket. a) Une utilisation de lagent TcpProxy : aaa/ode Il suffit de dfinir les filtres de transformation entre les notifications et les messages comprhensibles par l'application extrieures, puis de construire une classe d'agents hritant de TcpProxy dfinissant les mthodes abstraites setInputFilters et setOutputFilters. L'application aaa/ode permet l'utilisation de l'environnement de dveloppement ODE en distribu depuis des PC's. Elle utilise le TcpProxy pour interfacer un diteur emacs avec la machine agents afin de lui permettre de transmettre les commandes de l'utilisateur et de rcuprer les messages d'erreurs. La classe SandboxInputStream permet de filtrer le flot de donnes en provenance du socket TCP et d'en extraire les commandes destines l'application ; ces commandes sont ensuite transformes en notification destination des agents concerns. La classe SandboxOutputStream permet de transformer les notifications de compte-rendu en messages afin d'tre afficher dans une fentre. La classe SandboxClientProxy dfinit le proxy serveur permettant la connexion de l'diteur emacs.

1.2.3 Outils de construction


1.2.3.1 Agents configurables

La communication entre les agents se fait au moyen d'objets rles dont la mission est la configuration de l'agent destinataire11 et la transmission des notifications celui-ci. Chaque rle contient un ou plusieurs agents proxy dont l'interface est "conforme" l'agent reprsent.

11

Ce qui permet la construction d'application base d'agents par des outils visuels.

Annexes

78

Agent
{ ...

Rle X
Set/Add/Remove

Agent X
React(Not) { Channel.SendTo(from, to, not); }

AgentId to; X.React(n); React(from, Not) { Channel.SendTo(from, to, not); }

... }

Rle
1) Abonnements Un mode de construction dapplication est lespionnage, dans ce cadre un agent nest pas explicitement destinataire d'une notification mais il demande recevoir (abonnement) des notifications qui ne lui sont pas directement destines. Dans ce cadre, le besoin est de recevoir l'ensemble (ou une partie filtre) des notifications mises (resp. recues) par un agent ou par un ensemble d'agents. Afin de permettre ce type de fonctionnement, on autorisera le concepteur de l'application insrer des agents de filtrage entre les proxy et le bus de communication. La porte de ces filtres dpendra de leur emplacement.
Agent
Rle X
Set/Add/Remo ve Agent AgentId to; React(Not) { Channel.SendTo(from, to, not); }

Filtre
SendTo(from, to, Not)

Channel
Filtre
SendTo(from, to, Not)

Rle Y
Set/Add/Remo ve Agent AgentId to; React(Not) { Channel.SendTo(from, to, not); }

Filtre
SendTo(from, to, Not)

Filtre
SendTo(from, to, Not)

Agent

Architecture de filtrage
Sur la figure ci-dessous, certains filtres ne s'appliquent qu'aux communications avec un agent donn, d'autres toutes les communications "sortantes" d'un agent, et enfin les derniers toutes les communications locales. Chaque raction une notification spcifique est ralise au moyen d'une mthode doReact qui prend en paramtre une notification de ce type. La mthode React permet de dispatcher les notifications en fonction de leur type ; la classe Agent fournit une implmentation gnrique mais coteuse de la mthode React qu'il est conseill de surcharger.

Annexes

79

Agent
reactTo(from, not) { Not1 Not2 } doReact(from, Not1) { ... } doReact(from, Not1) { ... }

Role1
reactTo()

Role2
reactTo()

Role3
reactTo()

Agents et ractions
La classe Role permet de spcifier le comportement attendu de la part d'un correspondant agent ; en particulier on spcifie l'ensemble des types de notifications que cet agent doit accepter de traiter. La classe Role ralise la mme interface que la classe Agent, et bien que l'activit normale d'un rle soit la transmission de la notification un agent externe, on peut envisager des En outre, l'objet Rle permet la configuration dynamique du (ou des) destinataire(s) des notifications, ainsi que la mise en place des filtres.
Agent Role1
reactTo()

Role
Set/Add/Remove reactTo(from, not) { channel.sendTo(from, to, not); filters.sendTo(from, to, not); } AgentId to;

Filtre
sendTo(from, to, not) { Spy1.reactTo( new SpyNot(from, to, not)); up.sendTo(from, to, not); }

Role2
reactTo()

Rle Spy1
reactTo()

Filtre
sendTo()

Role3
reactTo()

up

Rle Spy1
reactTo()

Filtre
sendTo() up

Channel Filtre
sendTo() up

Rles et filtres
Les filtres sont des objets passifs qui ralisent l'interface "sendTo" du Channel, chaque filtre possde une liste de rle auquel il diffuse les notifications qui lui sont adresses. Les filtres sont organiss hirarchiquement.

Annexes

80

1.3

CMVC et ODE, gestion des sources

1.3.1 Introduction
La gestion des modifications sur le code source est assure par loutil CMVC (Configuration Management Version Control). Lquipe NetWall assure : - le dveloppement et la maintenance des codes sources - la rdaction des documents de dveloppements Le service " SHCM" (Software Hardware Configuration Management) assure : - la gestion de la base de rfrence des codes sources (base ODE) et de la base darchivage (base RCS) - la fabrication de NetWall Le service " Documentation" assure : - la rdaction de la documentation dexploitation Le service " GRDOC "assure : - la gestion de la base des documents de dveloppements - la gestion de la base des documents dexploitation

1.3.2 Gestion de la configuration de NetWall


1.3.2.1 Procdure de dveloppement

1) Gnralits La procdure de dveloppement est base sur lutilisation des outils ODE et CMVC. Elle sappuie sur le process du service SHCM. Le lecteur doit tre familiaris avec les termes de loutil ODE pour mieux comprendre la suite. Un GLOSSAIRE, donne une dfinition des termes les plus souvent employs. 2) Initialisation de lenvironnement de dveloppement Linitialisation consiste mettre disposition un espace pour le dveloppement. Elle est assure par le service SHCM. Les outils ODE et CMVC tant grs de manire trs troite, le dveloppement ne commence que lorsque les environnements sont prts pour les deux outils. Ds que linitialisation est termine, tous les objets de la liste de configuration sont sous contrle. a) Initialisation de la base ODE Lespace mis la disposition des dveloppeurs sappelle un "latest". Au dbut du dveloppement, le "latest" est vide et on a la visibilit sur tous les fichiers de rfrence contenus dans un "freeze". Au fur et mesure du dveloppement, le "latest" contiendra les fichiers modifis. b) Initialisation de la base CMVC

Annexes

81

Pour permettre la saisie des dfauts ("Defects"), il est cr des "composants" dans CMVC. Un "composant" CMVC na pas de contenu, cest seulement une indication donne par la personne qui ouvre le dfaut. Cette indication est une "vue utilisateur" sur la partie de NetWall o le dfaut est identifi. Le composant CMVC nest pas li au code source. La saisie des dfauts sur la documentation dexploitation se fait sur le composant : netwall_doc La saisie des dfauts sur les tests se fait sur le composant : netwall_test Il est galement cr une "Release" cest dire la version dans laquelle les dfauts sont corrigs, et un "Level" qui contiendra les "Defects" intgrs dans le prochain "freeze". 3) Fonctionnement Chaque dveloppeur possde un environnement de dveloppement priv sur la machine de dveloppement. Cet environnement priv sappelle une "sandbox". La base des sources du projet NetWall est situe sur la machine de l'quipe SHCM. Le lien entre les environnements privs et lenvironnement commun (base ODE) est assur par un montage NFS. Laccs aux donnes est scuris via un systme dACLs (Access Control List). 4) Dveloppement Pour travailler sur un fichier, le dveloppeur commence par le "privatiser" : la commande bco dODE effectue une copie de la dernire version du fichier (soit depuis le latest, soit depuis le freeze) vers la sandbox du dveloppeur. Le dveloppeur peut alors effectuer tous les travaux ncessaires sans perturber les autres personnes travaillant sur le projet. Il peut crer des versions intermdiaires dans sa sandbox avec la commande bci. Lorsquil a termin son codage et les tests d'intgrations, il utilise la commande bsubmit afin de soumettre son(ses) fichier(s) dans le latest. Si, entre temps, un autre dveloppeur a modifi et soumis le(s) mme(s) fichiers(s) un mcanisme de "merge" permet de fusionner les deux versions.

Annexes

82

5) Gestion des versions Les numros et les changements de version sont compltement grs par loutil ODE. Toute soumission de fichier (quelle que soit la modification) entrane un changement de version. 6) Contrle des modifications Toutes les modifications sont contrles : loutil ODE a un lien avec loutil CMVC afin que toutes les modifications de code soient lies un dfaut et que la modification nait lieu que lorsquelle est autorise. Ce contrle est fait au niveau de la commande bsubmit. Lors de la soumission, on associe une version de fichier un "Defect" dans CMVC. La soumission (bsubmit) ne sera faite que si la "track" associe ce Defect est dans ltat "fix". 7) Cycle de vie des dfauts
Originator : defect open

OPEN
Developper : defect accept

Originator : defect cancel / reopen

CANCEL
user : defect cancel

WORKING

RETURN

TRACK

Developper :Track create

LEVEL
SHCM Team

APPROV
mra : Approval accept

WORKIN

FIX Developper : bco/bci/bsubmit INTEGRAT


Developper : track integrate CMVC

CMVC

INTEGRAT

Osreply

COMMIT

CMVC

COMMIT

CMVC

TEST
Developper : Test accept CMVC

COMPLET

COMPLET

VERIFY
Originator : verify accept

CLOSE

Annexes

83

a) Fin de dveloppement La fin de dveloppement est appele EOS (End of Submission). Quelques jours avant la date prvue pour le freeze, une "Demande dagrment" est envoye par le service SHCM au chef de projet et aux dveloppeurs. Cette "Demande dagrment" donne au chef de projet une vue sur le contenu de la version qui va tre fabrique ainsi que le travail restant effectuer avant que la fabrication puisse commencer. Ds que la rponse la demande dagrment est positive et que toutes les tracks sont ltat " integrate", on commence la fabrication de NetWall. b) Fabrication de NetWall NetWall est fabriqu par le service SHCM : cest la phase de "freeze". Pendant cette phase les modifications ne sont plus autorises. Si un problme survient pendant cette phase, SHCM cre un dfaut dans CMVC. Ce dfaut, qui a un cycle de vie trs court, permet aux dveloppeurs de fixer le problme rapidement, et la fabrication du freeze peut reprendre. Lorsque le freeze est termin, le service SHCM met un "EOF report" (End Of Freeze). Le freeze est alors disponible pour les tests.

1.3.2.2

Procdure de test

Lentre en vrification/validation est marque par lEOF (End Of Freeze). Lactivit de test est jalonne par la cration de "Defects" dans CMVC. La correction des "Defects" suit le cycle dcrit prcdemment, jusqu la fabrication dun nouveau "freeze", et ce jusquau freeze final, qui marque le dbut de la livraison en clientle de NetWall.

1.3.2.3

Procdure de maintenance

1) Initialisation de lenvironnement de maintenance Cette opration est faite par le service SHCM. a) Initialisation de la base ODE Lespace mis la disposition des dveloppeurs sappelle une "shared sandbox". Au dbut de la maintenance, la "shared sandbox" est vide et on a la visibilit sur tous les fichiers du "freeze". Au fur et mesure de la maintenance, elle contiendra les fichiers modifis. Les corrections sont dlivres dans ce que l'on appelle les "PTF"(Program Temporary Fix). b) Initialisation de la base CMVC Les dfauts sont crs sur les mmes composants que pour le dveloppement. Une "Release de PTFs " est cre pour les corrections.

Annexes

84

2) Dveloppement des corrections Pour effectuer une correction, le dveloppeur se connecte sur la machine dveloppement. Il utilise la sandbox de maintenance, qui est "backe" sur la "shared sandbox" de maintenance, elle mme "backe" sur le freeze pour lequel la correction doit tre faite. Si la correction doit tre reporte dans la version en cours de dveloppement, le dveloppeur utilise sa sandbox de dveloppement et soumet sa modification dans le "latest".

Base

de

sources

Base

darchivage

Freeze i-1

PTF

Freeze i Maintenance Shared SandBox

Maitenance SandBox

Annexes

85

3) Fabrication dun PTF AIX Un PTF est fabriqu dans lenvironnement ODE, sous la responsabilit du dveloppeur. Un PTF est dit "incrmental" : il englobe tous les prcdents. Un PTF est constitu : - dun fichier contenant les binaires modifis : cest le fichier <numro du PTF>.bff (par exemple Z000999.bff). Loutil "ptfpkg" affecte le numro et fabrique le fichier. - dun fichier texte, contenant les informations relatives au PTF : cest le fichier <numro du PTF>.txt (par exemple: Z000999.txt). Ce fichier est fabriqu avec loutil " mktxt". Afin damliorer le reprage de ces PTFs, ils sont renomms en utilisant loutil "ptf_rename". La notation devient alors : <lpp>.<vrmf>.<oldname> o: <lpp> est le nom du lpp modifi, vrmf est la version telle quarchive dans ODE, oldname est le nom donn par loutil ptfpkg Exemple : Z002115.bff devient : NetWall.rte.3.3.0.5.Z002115.bff Z002115.txt devient : NetWall.rte.3.3.0.5.Z002115.txt

1.3.3 Glossaire
ACL Backing tree Access Control List Arbre de rfrence lisible depuis une sandbox (on dit quune sandbox est "backe" sur le latest ou sur une shared sandbox par exemple).Cela permet de voir des fichiers sans les privatiser. Configuration Management Version Control End Of Submission of source files to start the building of a freeze End of Validation Bulletin Image "gele" dun ensemble de fichiers sources extraits dODE Arbre de rfrence contenant tous les fichiers sources en cours de dveloppement soumis par les dveloppeurs OSF Development Environment - environment used to develop the source code; it allows the parallel development (merge feature), the compilation and the building of builds. La "Production De Programme" contient tous les processeurs impliqus dans la fabrication dun freeze Correction sur un ou quelques fichiers envoys en clientle pendant la priode de maintenance entre deux versions officielles. Program Temporary Fix Revision Control System - Unix source file manager used by ODE Espace de travail priv chaque dveloppeur Espace de travail partag par une quipe. Son contenu est compilable et peut reprsenter une version de produit. Software Hardware Configuration Management

CMVC EOS EVB Freeze Latest ODE

PDP PTF PTF RCS Sandbox Shared sandbox SHCM

Annexes

86

1.4

Formation pour le DRT

1.4.1 Description des enseignements slectionns en 1997-1998


1.4.1.1 Systmes Rpartis (SR)

DESS Gnie Informatique Responsable : S. Krakowiak Volume horaire : 18 heures cours + 6 heures TP Ce cours a pour but de prsenter les concepts et mthodes qui servent de base la conception, la ralisation et l'exploitation des systmes informatiques rpartis, en mettant l'accent sur les aspects traits au niveau du systme d'exploitation et du logiciel de base.

1.4.1.2

Option Systmes Rpartis (SR)

DESS Gnie Informatique Responsable : S. Krakowiak Volume horaire : 85 heures L'option Systmes Rpartis et Rseaux du DESS Gnie Informatique a pour objectif de former des ingnieurs comptents dans le domaine du logiciel de base et des applications pour les systmes informatiques rpartis. Ce domaine connat depuis plusieurs annes un dveloppement important, sous l'influence de deux facteurs : Evolution technique. Amlioration constante du rapport cot-efficacit des ordinateurs, amlioration des performances des communications (rseaux haut dbit), dveloppement de l'Internet et des rseaux d'entreprise (Intranets). Nouvelles applications. L'accs gnralis aux rseaux favorise le dveloppement de nouveaux secteurs d'applications. Ainsi, on observe un rapprochement entre les mondes du traitement de l'information, des tlcommunications, et de la tlvision. D'autres domaines en expansion sont ceux du travail coopratif et du commerce lectronique. Le domaine technique des systmes rpartis est caractris par plusieurs tendances : - Emergence d'outils logiciels (middleware) pour faciliter le dveloppement de nouvelles applications et l'intgration de l'existant. - Emergence de nouveaux modles de programmation et de structuration des applications (code mobile, agents) - Importance des aspects lis la tolrance aux fautes et la haute disponibilit de l'information et des services. - Importance des aspects lis la scurit des systmes (confidentialit, authentification, protection d'accs). - Importance de l'administration des systmes et rseaux, notamment pour rpondre aux impratifs de scurit et d'volutivit.

1.4.1.3

Construction des Applications Reparties (CAR)

DEA Informatique Systmes et Communications Responsable : Roland Balter Volume horaire : 12 heures

Annexes

87

Ce cours dcrit les principes directeurs de la construction d'applications rparties. Il comprend deux parties : - la premire partie est consacre aux outils logiciels disponibles pour le constructeur d'applications rparties. On dcrit l'tat de l'art industriel et quelques solutions avances. - la seconde partie prsente les mcanismes sous-jacents utiliss par les systmes pour la gestion de l'information rpartie et la mise en uvre des traitements rpartis.

1.4.1.4

Serveur de Bases de Donnes et objets multimdia (SBD)

DEA Informatique Systmes et Communications Responsable : M. Adiba Volume horaire : 12 heures Dans ce module, nous dcrivons les aspects systmes qui sont lis d'une part, l'volution des architectures des systmes informatiques (par exemple le client/serveur), et, d'autre part, l'volution des modles et systmes de bases de donnes. Nous dcrivons les architectures des SGBD et les techniques mises en uvre pour crer, grer et maintenir des bases de donnes rparties quelles soient relationnelles ou objets. Un accent particulier est mis sur la notion de transaction et ses volutions. Nous traitons galement le problme de la modlisation, du stockage et de l'exploitation des objets multimdia (textes, Sons, Images, Vido) sous langle des bases de donnes.

1.4.1.5

Interconnexion de Systmes (IS)

Matrise MINF Responsable : Roland Balter, J. Briat Volume horaire : 18 heures cours + 18 heures TD L'objectif de cette formation est de prsenter les principes directeurs de la construction d'applications rparties selon le modle client-serveur. Le cours est structur en trois parties. La premire partie est une introduction aux principes de fonctionnement des rseaux. La seconde partie prsente le modle client-serveur, les outils de construction d'application associs et le principe de ralisation l'aide de l'appel de procdure distance. La troisime partie dcrit quelques services distribus essentiels tels que le service de dsignation, le service de fichiers distribus, le service d'authentification, etc.

1.4.2 Description des enseignements slectionns en 1998-1999


1.4.2.1 Gnie Logiciel (GL)

DESS Gnie Informatique Responsable : F. Ouabdesselam, J. Parissis, J.M. Favre Volume horaire : 156 heures Objectifs : Prsenter les problmes qui relvent du Gnie Logiciel et les diverses solutions envisages pour toutes les phases du cycle de vie. L'enseignement vise en priorit donner aux tudiants le rflexe d'une approche rigoureuse dans la recherche des solutions ; cette approche passe par l'emploi de moyens adapts (mthodes, formalismes, outils). L'enseignement met galement en vidence le fait

Annexes

88

qu'une production semi-automatique de logiciel de qualit est possible sous certaines conditions et que la puissance des moyens disponibles varie selon les domaines d'application.

1.4.2.2

Interface Homme-Machine (IHM)

DESS Gnie Informatique Responsable : L. Nigay Volume horaire : 30 heures Objectifs : Ce module prsente les principes thoriques et pratiques ncessaires la conception et la ralisation des systmes interactifs : la psychologie cognitive et le gnie logiciel. Des tudes de cas sont prsentes au moyen de techniques audiovisuelles.

1.4.2.3

Multimdia

DESS Gnie Informatique Responsable : G. Kuntz Volume horaire : 21 heures Objectifs : Assimiler les spcificits des donnes multimdias et comprendre les problmes soulevs par leur intgration au Web, concevoir une application multimdia en choisissant partir du cahier des charges le systme et le support le plus adquat

1.4.3 Formation suivie chez Bull


1 semaine de formation sur le dveloppement dapplications en Java. 2 jours de formation sur cmvc.