2005 Apprentissage Moreau OSAE

INSTITUT DES TECHNIQUES DINGENIEUR DE LINDUSTRIE DAQUITAINE
MEMOIRE DE FIN DETUDES

PRESENTE EN VUE DOBTENIR
LE DIPLOME DINGENIEUR DES TECHNIQUES DE LINDUSTRIE Dans la Spcialit Rseaux et Tlcommunications e e e ee

PAR
Grgoire Moreau e
DIPLOME DELIVRE PAR LECOLE NATIONALE SUPERIEURE DELECTRONIQUE, INFORMATIQUE & RADIOCOMMUNICATION de BORDEAUX
` CONCEPTION ET MISE EN PRODUCTION DUN SYSTEME AUTOMATISE DE SECURISATION DU RESEAU REAUMUR
SOUTENU LE 19 SEPTEMBRE 2005
REAUMUR, 351 cours de la libration e 33405 TALENCE
ANNEES : 2004 2005
AUTEUR : Grgoire Moreau e
TITRE : Conception et mise en production dun syst`me automatis de scurisation du e e e rseau REAUMUR e
ENTREPRISE PARTENAIRE : REAUMUR, Universit Bordeaux I e
MAITRE DAPPRENTISSAGE : Laurent Facq, Directeur technique
TUTEUR PEDAGOGIQUE : Michel Pallard
NOMBRE DE PAGES : 53 pages sans lappareil de rfrence. ee NOMBRE DE REFERENCES BIBLIOGRAPHIQUES : 5
RESUME : Ce projet prsente la solution rpondant au besoin dautomatiser la gese e tion de la scurit sur le rseau REAUMUR. Elle traite direntes informations e e e e pour aboutir ` la reconnaissance de probl`mes de scurit, agit pour prvenir a e e e e les personnes responsables et potentiellement met en quarantaine les machines posant probl`me. Le travail a consist en lanalyse du besoin prcis, le choix dune e e e solution, son dveloppement et sa mise en oeuvre, avec enn une analyse des rsultats. e e
MOTS CLES : scurit informatique / scurit rseau / dtection dintrusions / actions e e e e e e automatises / interaction homme-machine / traitement automatis dinformations e e
` PARTIE A REMPLIR PAR LE MA ITRE DAPPRENTISSAGE ACCESSIBILITE DE CE RAPPORT (entourer la mention choisie) : Classe 0 = Acc`s libre e Classe 1 = Condentiel jusquau Classe 2 = Hautement condentiel jusquau Date : Nom du signataire : (date de n de condentialit) e Signature
Remerciements
Je remercie tout dabord tout le personnel de mon entreprise REAUMUR pour leur accueil et leur disponibilit. Je tiens ` remercier plus particuli`rement Daniel Marchand, e a e directeur du service, pour ses eorts dans le cadre de mon recrutement en tant quapprenti. Je remercie vivement mon ma tre dapprentissage Laurent Facq, directeur technique, pour ses enseignements, sa disponibilit et sa conance. e Je tiens ` remercier toute lquipe pdagogique du CFAI et de lENSEIRB et partia e e culi`rement Didier Thiers pour mavoir donn lopportunit de suivre cette formation. Je e e e remercie tous les enseignants pour leurs cours, leur patience et la qualit de leur pdagogie. e e Je remercie mon tuteur pdagogique Michel Pallard de la qualit de ses conseils. e e Je remercie toute la promotion RT1 pour ces 3 annes enrichissantes au point de vue e humain. Je remercie ma compagne Marie-Nolle Benassy pour sa patience et ses nombreuses e relectures mme si le sujet du mmoire est loin dtre sa passion ! e e e Je remercie enn mes parents pour leurs conseils aviss et leurs encouragements. e
Table des mati`res e

Introduction 1 Prsentation de REAUMUR e 1.1 Prsentation gnrale . . . . . . . . . . . . . . . . . . e e e 1.1.1 De Renater1 ` REAUMUR2 . . . . . . . . . a 1.1.2 REAUMUR, un rseau de campus, un service e 1.1.3 REAUMUR et le rseau rgional et urbain . e e 1.2 Avenir de REAUMUR . . . . . . . . . . . . . . . . . 5 6 6 6 6 9 9 11 11 12 12 13 13 14 14 14 15 15 15 16 17 17 17 18 18 19 19 20 20 20 22 22
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
2 Situation initiale 2.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Analyse de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2.4 Objectifs viss par le projet . . . . . . . . . . . . . . . . . . . . . . e 2.5 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Dmarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2.7 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.1 Utilisateurs du syst`me . . . . . . . . . . . . . . . . . . . . e 2.7.2 Perte de temps sur le traitement des probl`mes de scurit e e e 2.7.3 Interaction plus rapide avec les correspondants . . . . . . . 2.7.4 Risques associs aux absences de personnel . . . . . . . . . e 2.8 Planning prvisionnel . . . . . . . . . . . . . . . . . . . . . . . . . e 3 Recherche des solutions 3.1 Solutions envisageables . . . . . . . . . . . . . . . . . . 3.1.1 Principe de fonctionnement gnral . . . . . . . e e 3.1.2 Solutions commerciales . . . . . . . . . . . . . 3.1.3 Solutions libres . . . . . . . . . . . . . . . . . . 3.1.4 Dveloppement interne . . . . . . . . . . . . . . e 3.2 Choix de la solution . . . . . . . . . . . . . . . . . . . 3.3 Choix des outils logiciels et matriels pour le syst`me . e e 3.3.1 Quelle sonde de dtection dintrusion ? . . . . . e 3.3.2 Quel format de stockage utiliser pour Snort ? . 3.3.3 Quelle base de donnes ? . . . . . . . . . . . . . e 3.3.4 Quels langages de programmation ? . . . . . . .
1 2
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
Rseau National de Tlcommunications pour la Technologie, lEnseignement et la Recherche. e ee REseau Aquitain des Utilisateurs des Milieux Universitaires et de Recherche.
3/58
3.4
3.3.5 Dimensionnement du matriel . . . . . . . . . . . . . . . . . . . . . . e Faisabilit du dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . e e
23 24 25 25 26 26 26 26 28 29 30 31 32 33 33 33 35 35 36 36 36 36 37 37 38 39 39 39 40 40 40 40 40 41 42 42 43 44 44 45 45 45 46 47
4 Ralisation e 4.1 Les tapes de la ralisation . . . . . . . . . . . . . . . . . . . . . . . . . e e 4.2 Enqute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 4.3 Prsentation du cahier des charges fonctionnel pour le dveloppement . e e 4.3.1 Situations de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Dnition des fonctions du syst`me . . . . . . . . . . . . . . . . . e e 4.4 Analyse et principe de fonctionnement . . . . . . . . . . . . . . . . . . . 4.4.1 Les sources dinformations . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Lanalyse des donnes : plusieurs vnements de scurit pour e e e e e unique probl`me de scurit . . . . . . . . . . . . . . . . . . . . . e e e 4.4.3 La prise de dcision et laction en dcoulant . . . . . . . . . . . . e e 4.4.4 Une fois la dcision prise, son application . . . . . . . . . . . . . e 4.4.5 Linteraction des utilisateurs avec le syst`me . . . . . . . . . . . e 4.5 Dveloppement du syst`me . . . . . . . . . . . . . . . . . . . . . . . . . e e 4.5.1 Pour les sources dinformations . . . . . . . . . . . . . . . . . . . 4.5.2 Lanalyse des donnes . . . . . . . . . . . . . . . . . . . . . . . . e 4.5.3 La dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 4.5.4 Lexcution de la dcision . . . . . . . . . . . . . . . . . . . . . . e e 4.6 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Utilisation de moteurs de templates . . . . . . . . . . . . . . . . 4.6.2 Choix du moteur de templates . . . . . . . . . . . . . . . . . . . 4.6.3 Scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e 4.6.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5 Prsentation des informations et des interactions possibles . . . . e 5 Mise en production 5.1 Premi`re tape : version alpha . . . . . . . . . . . e e 5.1.1 Le syst`me . . . . . . . . . . . . . . . . . . e 5.1.2 Linterface . . . . . . . . . . . . . . . . . . . 5.1.3 Rsultats . . . . . . . . . . . . . . . . . . . e 5.2 Deuxi`me tape : version beta . . . . . . . . . . . . e e 5.2.1 Le syst`me . . . . . . . . . . . . . . . . . . e 5.2.2 Linterface . . . . . . . . . . . . . . . . . . . 5.3 Version de production stable livre pour septembre e 6 Bilan du projet 6.1 Rponse au cahier des charges fonctionnel . . e 6.2 Respect du planning . . . . . . . . . . . . . . 6.3 Cot du projet . . . . . . . . . . . . . . . . . u 6.3.1 Cot eectif . . . . . . . . . . . . . . . u 6.3.2 Cot potentiel . . . . . . . . . . . . . u 6.4 Gains . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Gain de temps . . . . . . . . . . . . . 6.4.2 Gain en termes dimage et de scurit e e 6.5 Bilan humain . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . un . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . apr`s validation . e
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
4/58
6.5.1 6.5.2
Gestion du changement et de la mise en quarantaine . . . . . . . . . Documentations, prsentation et formation . . . . . . . . . . . . . . e
47 47 48 48 49 49 49 51 51 51 52 53 54 56
7 Bilan de comptences e 7.1 Domaine scientique et technique 7.2 Domaine organisationnel . . . . . 7.3 Domaine conomique . . . . . . . e 7.4 Domaine humain . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
8 Perspectives 8.1 Distribution du syst`me dans la communaut des logiciels libres . . . . . . . e e 8.2 Amlioration de lintelligence du syst`me . . . . . . . . . . . . . . . . . . . e e 8.3 Elargissement du prim`tre du syst`me . . . . . . . . . . . . . . . . . . . . e e e Conclusion Bibliographie Glossaire Annexes A Partenaires de REAUMUR B Cahier des charges fonctionnel C Mod`le conceptuel des donnes e e
II IV XIII
Introduction
La scurit des rseaux depuis quelques annes, a vu son importance saccro au point e e e e tre de devenir une priorit dans de nombreuses socits. Des outils automatiss de plus en e ee e plus complexes, des virus ` la rplication foudroyante attaquent les rseaux et menacent en a e e permanence lintgrit des syst`mes dinformation. Par exemple, une machine dote dun e e e e syst`me Windows, et non protge, est dsormais contamine en moins de 12 minutes3 . e e e e e REAUMUR, le service en charge du rseau inter-universitaire ponyme nchappe pas ` e e e a ce constat et se trouve mme en premi`re ligne de dfense face ` ces menaces. e e e a Dans un tel contexte, la gestion manuelle de la scurit devient fortement consommatrice e e de temps. Lobjet de mon projet de mmoire est donc dautomatiser et damliorer la gestion de la e e scurit. e e Jai suivi une dmarche commenant par lanalyse de la situation initiale pour dterminer e c e une problmatique et les besoins associs. A partir de ces besoins, jai recherch des solutions e e e pouvant y rpondre et ralis le projet. Jai ensuite valu sa rponse aux besoins une fois e e e e e e celui-ci mis en oeuvre. Je termine enn sur un bilan personnel.
mesure de Sophos
Chapitre 1
Prsentation de REAUMUR e
1.1
1.1.1
Prsentation gnrale e e e
De Renater1 ` REAUMUR2 a
Le rseau Renater, depuis 1991, raccorde les direntes universits franaises entre elles e e e c et apporte ` celles-ci un lien avec Internet. En Aquitaine, le besoin de crer un service a e dinterconnexion au niveau du campus entre les direntes universits pour fdrer en un e e e e point unique lacc`s ` Renater (gure 1.1) a engendr la cration du rseau de campus e a e e e REAUMUR. La mission de REAUMUR est dnie ainsi : e REAUMUR a pour mission dassurer lexploitation, la gestion et le dveloppement e de moyens et de services rseaux communs, dans le cadre des activits scientiques, e e pdagogiques, documentaires ou de gestion des dirents centres, laboratoires et services e e des organismes partenaires. REAUMUR xe notamment les conditions de scurit dutilie e sation, en accord avec les partenaires. 3 . Ces partenaires sont, entre autres, les universits e 4 de Bordeaux I, III et IV, le CNRS, lENSEIRB ou encore lENSAM.
1.1.2
REAUMUR, un rseau de campus, un service e
Le service REAUMUR se trouve sur le campus universitaire de Talence, sur le domaine du Haut Carr. Il est rattach administrativement ` lUniversit Bordeaux I et plus prcisment e e a e e e a ` la DRIMM5 . REAUMUR est donc historiquement proche des utilisateurs pour la partie Bordeaux I (dans les petits laboratoires ou certaines administrations, les usagers du rseau sont parfois e
1 2
Rseau National de Tlcommunications pour la Technologie, lEnseignement et la Recherche. e ee REseau Aquitain des Utilisateurs des Milieux Universitaires et de Recherche. 3 Extrait de la convention portant statuts du service interuniversitaire REAUMUR. 4 Pour une liste exhaustive voir lannexe A page II. 5 Direction des Ressources Informatiques et Multimdia Mutualises. e e
Chapitre 1. Prsentation de REAUMUR e
7/58
Fig. 1.1 Rseau Renater e
directement relis ` nos quipements). Cependant, de mani`re gnrale et dans le cadre de e a e e e e lvolution vers les rseaux urbains et rgionaux, REAUMUR a pour rle dinterconnecter e e e o les rseaux des dirents partenaires et de servir dinterface pour la connexion ` Renater. e e a Dun point de vue technique, ` sa cration, REAUMUR tait bas sur un rseau de a e e e e bre optique utilisant le protocole FDDI6 (dbit de 100 Mbit/s ` 200 Mbit/s). En 2000, le e a rseau REAUMUR a migr sur le campus vers le protocole Gigabit Ethernet (1000 Mbit/s). e e Entre 2000 et aujourdhui, le lien entre REAUMUR et Renater est pass de 34 Mbit/s ` 1000 e a Mbit/s en passant par un palier ` 100 Mbit/s. Cette augmentation traduit un accroissement a de la demande en ressources de la part des utilisateurs. La gure 1.2 page 8 prsente les direntes mani`res dtre connect ` REAUMUR. e e e e ea Sur cette gure, on trouve trois types dquipements : les postes clients, les commutateurs e et les routeurs. Les commutateurs sont des lments dinterconnexion qui permettent de constituer des ee rseaux locaux. Les routeurs sont des lments dinterconnexion qui permettent la liaison e ee de rseaux entre eux. e
FDDI : Fiber Data Distribution Interface : protocole de liaison relativement ancien, utilisant la bre optique comme support.
6
8/58
Petit laboratoire, petit site
Coeur de rseau REAUMUR
Partenaire possdant son propre routeur
Utilisateurs
Partenaires utilisant le routeur de REAUMUR
commutateur REAUMUR
routeur REAUMUR
Poste Client
commutateur partenaire
routeur partenaire
Fig. 1.2 Diversit des connexions sur REAUMUR e
9/58
On peut ainsi observer trois grands types de connexion ` REAUMUR : a la connexion type petit laboratoire ou petit site, avec un commutateur REAUMUR sur lequel des utilisateurs peuvent directement se connecter, la connexion dun partenaire avec son rseau interne reli ` un commutateur REAUe ea MUR hberg sur leur site, e e enn, la connexion dun partenaire qui va se faire directement sur notre routeur de cur de rseau. e Sur le plan conomique, le budget de REAUMUR est dtermin par son directeur, puis e e e vot par le conseil dadministration rassemblant les organismes membres de REAUMUR. Il e sl`ve pour lanne 2004 ` 570 000 e. ee e a Lquipe de REAUMUR est compose de 7 personnes : e e 2 ingnieurs de recherche : directeur (gestion de ladministratif et des ressources hue maines) et directeur technique (chef de projet, dveloppement, scurit du rseau), e e e e 1 ingnieur dtude (dveloppement et gestion quotidienne du rseau), e e e e 1 assistant ingnieur (assistance aux utilisateurs), e 1 technicien (gestion de la partie physique du rseau), e 1 secrtaire (assistance au directeur, gestion de la page Web du service), e 1 apprenti (assistance aux ingnieurs, dveloppement). e e Les concurrents potentiels de REAUMUR sont les socits prives de gestion de rseau ee e e qui pourraient tre choisies pour remplacer toute ou partie de lquipe titulaire pour cere e taines fonctions.
1.1.3
REAUMUR et le rseau rgional et urbain e e
LESRA7 est le point de rassemblement des organismes denseignement et de recherche aquitains pour leur connexion ` Renater. a Depuis son origine, ESRA est pilot par REAUMUR tandis que sa gestion tait cone e e e a ` des socits prives. Depuis 2004, REAUMUR g`re directement le rseau ESRA. ee e e e
1.2
Avenir de REAUMUR
Les tudiants et personnels du campus vont disposer de moyens dacc`s au rseau de e e e plus en plus nombreux (avec le programme Aquitaine Campus Ouvert) que ce soit avec ou sans l. La gestion de la scurit dans ce cadre devient donc de plus en plus complexe. e e Pour acqurir une dimension europenne, les universits bordelaises se rapprochent de e e e plus en plus, avec une fusion en point de mire. Le premier pas tant la cration dun PRES8 e e
Rseau Enseignement Suprieur et Recherche en Aquitaine. e e Pole Recherche Enseignement Suprieur cf. http ://www.u-bordeaux1.fr/bx1/pres.pdf et e http ://www.cpu.fr/Publications/Publication.asp ?Id=347
8 7
10/58
Universit de Bordeaux par les 4 universits. Les structures inter-universitaires comme e e REAUMUR sont directement concernes. e Les dbits des liaisons internes au campus et vers Renater vont encore augmenter avec e la croissance des besoins des utilisateurs en termes de nouveaux services : visioconfrence, e grilles de calcul (rseaux ` tr`s haut dbit dordinateurs ddis au calcul). Ainsi, certains e a e e e e liens sont en cours de migration sur du 10Gigabit Ethernet. Laugmentation du prim`tre de REAUMUR, au niveau du campus de la plaque urbaine e e et rgionale, va amener un plus grand nombre dutilisateurs ce qui entra une gestion de e ne la scurit plus dicile. e e Laugmentation du nombre dutilisateurs am`ne aussi un probl`me. IP9 version 4 (le e e protocole de base dInternet) arrive ` ses limites en terme du nombre de machines quil peut a adresser du fait de la taille alloue ` ladresse des machines. On commence donc ` manquer e a a dadresses IP pour les machines. Il existe des moyens pour contourner ce probl`me mais ils e sont gnralement peu satisfaisants en terme de scurit et de compatibilit (par exemple, e e e e e le NAT10 ). Pour y rpondre, le nouveau protocole IP version 6 est en cours dinstallation e dans les direntes universits et va induire des migrations de matriels et logiciels. Cela e e e risque dentra ner une augmentation du besoin en ressources humaines. En plus de la ncessit dimportants dbits, les nouvelles applications ont des besoins de e e e 11 et donc dune approche dirente du rseau. qualit de service e e e Toutes ces volutions vont demander du temps et des moyens humains supplmentaires. e e Or, actuellement, la fonction publique est dans une situation o` mme le renouvellement u e des dparts ` la retraite pose probl`me. Il faut donc compter au mieux sur des ressources e a e humaines qui vont rester constantes. Il est donc ncessaire dconomiser du temps sur les e e tches qui peuvent en faire lobjet. a De ce fait, le projet va saxer sur lconomie de temps dans une des tches les plus e a consommatrices : la gestion de la scurit. e e
IP : Internet Protocol, protocole de niveau rseau, permettant ladressage des machines et lachee minent des donnes. e 10 NAT : Network Address Translation permet dutiliser une mme adresse IP sur Internet pour e un ensemble de machines mais peut poser probl`me pour certaines applications comme la visioe confrence. e 11 Qualit de service (QoS pour Quality of Service en anglais) : il sagit en fait de la qualit du e e transport des informations dans le sens o` les donnes arrivent dans lordre et avec un dlai de u e e transmission contrl. Dans le cadre dun change classique de donnes, il ny a pas ` sen soucier. oe e e a Par contre, par exemple pour la visioconfrence, la qualit de service est ncessaire pour viter e e e e davoir des mauvaises transmissions.
9
Chapitre 2
Situation initiale
Au commencement du projet, jai dtermin le contexte du projet et analys lexistant. e e e De cette mani`re, suite ` des discussions avec mon ma dapprentissage nous avons pu e a tre dnir une problmatique et les contraintes du projet. A partir de cette problmatique nous e e e avons dgag des objectifs et leurs indicateurs associs pour enn aboutir ` lexpression des e e e a besoins.
2.1
Contexte du projet
REAUMUR est confront ` une grande quantit de probl`mes de scurit. ea e e e e Dune part, certains de ces probl`mes sont potentiellement dangereux pour le rseau car e e ils peuvent entra ner des dysfonctionnements des quipements rseaux et une saturation de e e la bande passante du campus. Dautre part, des probl`mes lis aux abus dutilisateurs (utilisation non professionnelle du e e rseau) peuvent induire une surconsommation de ressources et donc un surdimensionnement e du rseau. Ils peuvent entra e ner une mauvaise image de REAUMUR vis ` vis de Renater, a voire mme des plaintes en justice (dans les cas dutilisation du rseau pour des changes e e e de chiers illgaux). e De plus, ces probl`mes consomment un temps de traitement manuel non ngligeable aussi e e bien au niveau de lquipe du service quau niveau des correspondants de REAUMUR. Ces e correspondants (interlocuteurs privilgis de REAUMUR) sont les personnels prsents sur e e e les sites, informaticiens ou non. Ils g`rent la communication entre utilisateurs naux et e REAUMUR. La situation actuelle de la fonction publique, rappelons le, fait quil est dicile dobtenir des ressources humaines supplmentaires. Il est donc primordial de russir ` automatiser les e e a tches pouvant ltre. Ainsi, du temps pourra tre gagn pour lquipe de REAUMUR. Cellea e e e e ci pourra raliser des projets supplmentaires plutt que de traiter des tches quotidiennes e e o a rptitives. e e
Chapitre 2. Situation initiale
12/58
2.2
Analyse de lexistant
Au dbut du projet, soit au dbut de lanne 2004, le traitement des probl`mes de scurit e e e e e e se faisait en 3 tapes : e dtection dun probl`me, analyse puis mise en quarantaine de la machine incrimine e e e si besoin tait et envoi de courrier lectronique au correspondant responsable de la e e machine, rsolution du probl`me de la part du correspondant et envoi de courrier lectronique ` e e e a REAUMUR demandant le rtablissement de la connexion de la machine sur le rseau, e e prise en compte par REAUMUR, et le cas chant, leve de la quarantaine. e e e Des mesures avaient t faites de mani`re ` quantier le temps perdu par REAUMUR ee e a pour la gestion des probl`mes de scurit (dans la portion qui peut tre automatisable). Le e e e e rsultat tait de 1 heure et 15 minutes par jour globalement (et de temps ingnieur qui plus e e e est !). Il faut noter que cette valeur est une moyenne et quil arrive sur certaines priodes e (apparition dun nouveau virus, piratage massif...) que cette dure soit largement dpasse. e e e Il y a donc une perte de temps relle qui, de plus, occasionne des interruptions dans les e tches dingnierie. a e De plus, les informations concernant les probl`mes de scurit ne sont pas directement e e e accessibles aux correspondants. Ceux-ci doivent transiter par le personnel de REAUMUR pour les obtenir. Il y a donc, en plus, un probl`me dacc`s ` linformation. e e a Les correspondants ont estim quils attendent en moyenne 2 heures avant que leurs e demandes de leve de quarantaine ne soient traites. La perte de temps au niveau des e e correspondants, et donc au niveau des utilisateurs naux, est importante. Enn, le fait que la scurit soit gre manuellement par du personnel introduit le risque e e ee que des piratages puissent avoir lieu durant la nuit, les week-end et les vacances. Un syst`me e automatique pourrait contrer les attaques dans ces priodes. e
2.3
Problmatique e
De cette analyse de lexistant, on peut dduire une problmatique portant sur trois e e volets : 1. du temps est perdu pour ragir aux probl`mes de scurit dans le sens o` ces ractions e e e e u e sont la plupart du temps systmatiques et pourraient tre traites automatiquement, e e e 2. lorsque les probl`mes entra e nant une mise en quarantaine ont t rsolus par les ee e correspondants, ceux-ci sont dpendants de REAUMUR pour le rtablissement de e e lacc`s au rseau des machines posant probl`me, e e e 3. un risque potentiel important existe durant les priodes dabsences de personnels dans e le service.
13/58
2.4
Objectifs viss par le projet e
Le projet doit aboutir ` la mise en service dun syst`me automatis dassistance ` la a e e a gestion de la scurit. Il doit rpondre ` trois objectifs principaux qui dcoulent de la e e e a e problmatique : e 1. dgager au moins 75% de temps pour lquipe REAUMUR dans les tches e e a de scurit automatisables. e e Lindicateur de performance associ ` cet objectif est le rapport du nombre de e a probl`mes de scurit traits automatiquement sur le nombre de probl`mes total. e e e e e Ce rapport correspond au pourcentage de probl`mes de scurit nayant pas ncessit e e e e e dintervention, il traduit donc le temps gagn. e Cet indicateur est relev dans les comptes-rendus du syst`me ; e e 2. permettre une interaction instantane avec les correspondants de REAUe MUR pour 90% des probl`mes de scurit. e e e Lindicateur de performance associ ` cet objectif est le rapport des probl`mes de e a e scurit qui ncessitent une communication, et donc une perte de temps, sur le nombre e e e total de probl`mes de scurit. e e e Cet indicateur est relev par dcompte des changes eectus par courrier lectronique e e e e e avec les correspondants ; 3. traiter automatiquement au moins 50% des probl`mes de scurit qui sure e e viennent durant les priodes non ouvres. e e Lindicateur de performance associ ` cet objectif est le rapport du nombre de e a probl`mes traits automatiquement sur le nombre de probl`mes total durant les e e e priodes non ouvres. e e Cet indicateur est relev dans les comptes rendus du syst`me. e e
2.5
Contraintes
Ces objectifs doivent tre remplis, mais sous certaines contraintes. e La politique de REAUMUR est dutiliser autant que possible les logiciels libres et de mettre ` disposition de la communaut les outils dvelopps en interne. Elle sexplique par a e e e une volont dindpendance vis ` vis des socits externes pour notre gestion de la scurit e e a ee e e du rseau. De plus, les comptences ncessaires ` lutilisation et ` la conception de logiciels e e e a a libres sont prsentes dans lquipe. e e Dun point de vue technique, le ux rseau du campus vers lextrieur peut potentiellee e ment atteindre le Gigabit (il sagit de la bande passante dont nous disposons avec Renater). Sur le plan conomique, le budget allou est de 5 000 e pour la partie matrielle. Le e e e cot dj` engag pour lapprenti est de 15 000 e(salaire et charges). u ea e En termes de calendrier, le syst`me devait tre mis en fonctionnement dici Mars 2005. e e Lensemble de la documentation et la prsentation du syst`me devait tre fait dici juin e e e juillet 2005.
14/58
2.6
Dmarche e
Pour pouvoir mener ` bien ce projet suivant les contraintes formules, jai suivi la a e dmarche suivante : e expression des besoins, recherche de solutions, en fonction de la solution retenue, conception ou choix du syst`me, ralisation et mise e e en oeuvre, validation, mise en beta test pour certains utilisateurs, ralisation dune documentation dutilisation, e mise en production, suivi.
2.7
Expression des besoins
Suivant les objectifs et les contraintes il faut maintenant dterminer les besoins qui y e sont associs et pour qui ? e
2.7.1
Utilisateurs du syst`me e
On peut distinguer trois types dutilisateurs du syst`me : e lquipe REAUMUR, e les correspondants, les utilisateurs naux du rseau. e Le syst`me doit permettre une gestion particuli`re des droits qui sont les suivants : e e voir les informations de scurit, e e modier le comportement du syst`me, e lever une quarantaine. Lassociation droits-utilisateurs est la suivante : lquipe REAUMUR a tous les droits sur tous les probl`mes relevs pour tout le e e e campus, avec le maximum de dtails, e les correspondants ont la possibilit de lever les quarantaines qui concernent le souse rseau dont ils ont la responsabilit mais disposent dinformations partielles, e e les utilisateurs naux nont que le droit de lever la quarantaine sur leur machine (avec une protection contre les abus) et nont que le minimum dinformations sur le probl`me e dtect. e e
15/58
2.7.2
Perte de temps sur le traitement des probl`mes de e scurit e e
Pour rpondre ` ce point, il faut dabord dnir les types de probl`mes qui seront traits : e a e e e actes de piratage (compromission de machine), propagation de virus, abus dutilisateurs (utilisation du rseau non conforme ` la charte REAUMUR1 ). e a Le syst`me doit donc tre capable de dtecter et de rpondre automatiquement ` ces e e e e a probl`mes avec un minimum dintervention humaine. e La rponse aux probl`mes sera fonction de la gravit de ceux-ci. Dans les cas les plus e e e graves, la machine source du probl`me est mise en quarantaine. Dans les cas les moins graves, e le syst`me envoie uniquement un courrier lectronique au correspondant responsable de la e e machine posant probl`me. e La rponse ` ces probl`mes doit se faire rapidement : de lordre de 5 minutes. e a e Le fait de mettre la machine en quarantaine plutt que de faire un tri slectif des paquets o e de donnes (pour direncier ceux qui correspondent ` un probl`me de scurit de ceux qui e e a e e e sont sains) est ` la fois un choix politique et technique. Cest un choix politique car le fait de a bloquer compl`tement une machine dans le cadre dabus dutilisation fait prendre conscience e aux utilisateurs de leur non-respect de la charte. On esp`re ainsi induire des changements de e comportement. Cest aussi un choix technique car, dans le cas dune attaque pirate, si jamais un ltrage slectif est mis en oeuvre, rien ne garantit que le pirate ne trouve nalement pas e un moyen de contourner celui-ci. Une mise en quarantaine compl`te permet ainsi de ne pas e laisser la possibilit au pirate davoir un quelconque acc`s ` la machine posant probl`me. e e a e
2.7.3
Interaction plus rapide avec les correspondants
Pour amliorer la rapidit de linteraction avec les correspondants, il doit leur tre fourni e e e une interface sur le syst`me leur permettant dagir directement sur celui-ci. Les actions e principales sont : visualiser les vnements de scurit, e e e e lever les quarantaines.
2.7.4
Risques associs aux absences de personnel e
Pour diminuer ces risques, le syst`me doit au maximum pouvoir prendre des dcisions e e automatiques. Plus les rponses sont rapides, moins les risques sont grands. e De plus, les dcisions ne doivent pas tre errones pour viter de bloquer des machines e e e e qui nont pas ` ltre. Le syst`me doit aussi permettre de ne pas bloquer des machines a e e
Charte REAUMUR : document sign par tout utilisateur de REAUMUR prcisant que lutilie e sation du rseau doit tre strictement professionnelle ` des ns de recherche. e e a
1
16/58
considres comme vitales pour le rseau, par exemple les serveurs de nom (DNS2 , serveurs ee e de courrier lectronique, etc. Dans le cas dune suspicion sur une machine de ce type, la e dcision doit tre prise par un ingnieur REAUMUR. e e e
2.8
Planning prvisionnel e
Le planning prvisionnel du projet que jai dni lors de la validation de mmoire est le e e e suivant :
2004 M Conception CDCF MCD Ralisation Base de donnes Intgration existant Dveloppement Interface graphique Documentation Developpeur Utilisateur Formation Utilisateur Validation Tests Mesures Maintenance A M J J A S O N D J F 2005 M A M J
Fig. 2.1 Planning prvisionnel du projet e
CDCF : Cahier Des Charges Fonctionnel. MCD : Mod`le Conceptuel des Donnes. e e La ligne rouge correspond ` la date de mise en production prvisionnelle. a e Lanalyse de la situation initiale ma permis dobtenir une problmatique rsumant les e e besoins du service et des utilisateurs. Lexpression de ces besoins permet maintenant deffectuer un choix dans les direntes solutions potentielles. e
2 DNS : Domain Name Server, serveur qui attribue les noms de domaines (par exemple ubordeaux.fr), et les noms de machines sur ces domaines.
Chapitre 3
Recherche des solutions

Il existe de nombreuses solutions commerciales ou libres permettant plus ou moins de rpondre aux besoins. Il est donc ncessaire deectuer une analyse de ces solutions an e e deectuer le bon choix.
3.1
Solutions envisageables
Tout dabord, examinons le principe de fonctionnement gnral de la solution recherche. e e e
3.1.1
Principe de fonctionnement gnral e e
De mani`re globale, les solutions pouvant rpondre au probl`me pos sont bases sur e e e e e le principe de la contre-mesure associe ` une sonde de dtection dintrusion (IDS1 ). Le e a e principe de fonctionnement dun tel dispositif est le suivant : la sonde dtecte un vnement e e e de scurit et le syst`me de contre-mesure ragit en ltrant la connexion rseau de la machine e e e e e qui pose probl`me. Il existe des solutions plus puissantes permettant de vrier sur chaque e e 2 ,...) et leur niveau de mise ` machine ltat des composants de scurit (antivirus, pare-feu e e e a jour pour ensuite autoriser ou non lacc`s de la machine au rseau. e e On distingue ainsi deux approches : une au niveau global, lautre au niveau des postes clients. Dans notre situation, avec un parc informatique tr`s htrog`ne et dont la gestion e ee e ne nous appartient pas, il est impossible de mettre en place une solution ncessitant une e action sur tous les postes. Du fait de notre situation dintermdiaire, nous ne pouvons avoir e quune approche globale vis ` vis du ux rseau transitant entre le campus et lextrieur a e e (Renater). Au niveau du ltrage des machines qui posent probl`me, il y a deux approches possibles. e La premi`re est de bloquer uniquement les communications problmatiques (Peer to Peer3 , e e
IDS : Intrusion Detection System : outil permettant de dtecter des vnements de scurit. e e e e e Pare-feu : logiciel ou matriel qui ltre les menaces les plus simples du ux rseau. e e 3 Peer to Peer : protocole dchange de donnes se faisant directement de poste client ` poste e e a client sans avoir besoin de serveurs. Le Peer to Peer est utilis en grande majorit ` des ns illgales. e ea e
2 1
Chapitre 3. Recherche des solutions
18/58
tentative de connexion de la part dun pirate, diusion dun vers4 , ...). La seconde est disoler totalement la machine. Notre choix est de bloquer totalement les machines posant probl`me e (voir la section 2.7.2 page 15 pour plus de dtails). e Il est possible de distinguer trois types de solutions : les solutions commerciales, les solutions libres, le dveloppement en interne dune solution. e Il faut examiner de quelle mani`re chacune de ces solutions rpond au probl`me. e e e
3.1.2
Solutions commerciales
Dans le cadre des solutions commerciales, on peut trouver de mani`re non exhaustive : e Cisco PIX 525 : 9 930 e5 , Cisco ASA 5540 : 14 060 e, CheckPoint Enterprise : 17 400 e, Allot NetEnforcer : 24 900 e.
On peut voir que les solutions commerciales ont un principal dfaut : elles cotent tr`s e u e cher (largement au del` du budget maximum x : pour rappel 5 000 e pour la partie a e matrielle). e Elles apportent beaucoup de fonctionnalits inutiles dans le cadre de ce projet et sont e dicilement modiables. Il est ncessaire de souscrire ` des abonnements pour tenir les quipements ` jour par e a e a rapport aux nouvelles menaces de scurit. e e Enn, je nai pas dtaill davantage mon tude par rapport ` ces solutions car elles ne e e e a rpondent pas ` une contrainte : elles nous lient ` des socits externes pour la gestion de e a a ee la scurit. e e
3.1.3
Solutions libres
Dans le domaine des logiciels libres, il existe une multitude doutils de contre-mesure associs ` la sonde de dtection dintrusion que nous utilisons ` REAUMUR, Snort. Ces e a e a outils sont entre autres : Hogwash, Guardian, Flexresp... De mani`re gnrale, ces outils font le mme travail. Ils traitent les paquets de donnes de e e e e e mani`re transparente, laissant passer ceux qui ne dclenchent pas de signature et bloquant e e les autres. Cependant, ils ne permettent pas la mise en quarantaine directement comme nous le souhaitons. Ils ncessitent la dviation du ux rseau par un PC, ce qui peut induire des e e e
Un vers est un virus se propageant de mani`re autonome par le rseau. Contrairement ` un e e a virus classique qui se diuse par courrier lectronique, il ne ncessite pas daction de la part de e e lutilisateur. 5 Tous les montants indiqus sont extraits des tarifs publics en vigueur au mois de Juin 2005 e
4
19/58
risques de pannes et de mauvaises performances (un PC, aussi puissant soit-il, nest pas conu exclusivement pour traiter un ux rseau important ; au contraire dun routeur ou c e dun pare-feu matriel). e De plus, la abilit de tels dispositifs est limite. En eet, il peut y avoir des faux positifs e e qui entra nent des ltrages errons. e Enn, la conguration et lintelligence de ces outils sont tr`s limites. Nous avons un e e besoin plus complexe. Pour linterface avec les utilisateurs, il existe plusieurs outils permettant la visualisation des vnements de scurit dtects par Snort : ACID, Snort Alert Monitor et bien dautres. e e e e e e Cependant, ceux-ci ne fournissent quune vue unique sans orir une gestion ne des droits ncessaire dans notre contexte multi-utilisateur. e
3.1.4
Dveloppement interne e
Le dveloppement en interne de la solution permet de rpondre totalement et prcisment e e e e a ` nos besoins. De plus, les cots dun tel dveloppement sont pour leur grande part couverts u e par le salaire de lapprenti. Cependant, un tel travail comporte des risques qui peuvent empcher datteindre tous e les objectifs. Ces risques trouvent leur origine au niveau de la conception, de la gestion du planning ou dune mauvaise valuation de la faisabilit. e e
3.2
Choix de la solution
Des trois solutions prsentes, lune peut tre limine directement. Il sagit de lutilie e e e e sation de solutions commerciales. Dune part, ces solutions sont beaucoup trop coteuses, u dautre part, elles sont en contradiction avec une contrainte : elles nous lieraient ` une a socit pour la gestion de la scurit. ee e e Les deux solutions restantes divergent beaucoup dans la rponse quelles apportent aux e besoins. Aucune des solutions libres ne rpond compl`tement, bien que certains besoins soient e e couverts par dirents outils libres. e Au contraire, le dveloppement dune solution interne pourrait fournir une rponse e e compl`te, mme si ce choix comporte des risques. e e Les besoins lis ` linterface du syst`me sont tr`s particuliers ` cause de la spcicit e a e e a e e de notre situation ` REAUMUR. En eet, il est ncessaire dassurer une gestion tr`s ne a e e des droits entre les dirents utilisateurs du syst`me (voir 2.7.1 page 14). Aucune interface e e dans le domaine des logiciels libres ne permet actuellement de disposer dune telle gestion des droits. En dnitive, on constate quil manque de nombreux lments aux solutions libres pour e ee pouvoir rpondre ` tous nos besoins. Cependant, dvelopper des logiciels qui existent dj` e a e ea
20/58
est une perte de temps et augmente les risques de non russite. e Aussi, notre choix se porte sur lutilisation doutils libres avec un dveloppement e complmentaire pour rpondre totalement aux besoins. e e De nombreux prototypes ont dj` t raliss par mon ma ea ee e e tre dapprentissage suivant cette stratgie. Ils permettent de conrmer la faisabilit dun syst`me ralis de cette e e e e e mani`re. Cette faisabilit sera tudie plus prcisment par la suite. e e e e e e
3.3
Choix des outils logiciels et matriels pour le e syst`me e
Avant de commencer le dveloppement, il faut donc : e rechercher quels logiciels libres peuvent tre utiliss et pour sacquitter de quelles e e tches, a dterminer les formats de stockage de linformation en fonction des contraintes teche niques et des besoins, faire le choix des langages de programmation qui vont tre utiliss, e e dimensionner le matriel supportant le syst`me. e e
3.3.1
Quelle sonde de dtection dintrusion ? e
Snort, une sonde de dtection dintrusion, est utilise depuis de nombreuses annes par e e e mon ma tre dapprentissage. Il sen sert pour dtecter les probl`mes de scurit avec des e e e e r`gles de sa cration. Ce patrimoine doit tre rutilis et pouvoir voluer. De plus, Snort e e e e e e demeure le dtecteur dintrusion de rfrence dans le monde des logiciels libres. Il est donc e ee logique de sen servir dans le cadre du projet.
3.3.2
Quel format de stockage utiliser pour Snort ?
Les informations que Snort rcolte sont dissocies en deux parties. La premi`re, lalerte, e e e contient le nom de la signature qui a t dtecte avec les informations (source et destination ee e e de la communication, instant prcis de dtection, dtails techniques sur la communication) e e e concernant le paquet de donnes responsable de lvnement. La seconde, la charge utile, e e e reprsente le contenu de ce paquet de donnes. e e Snort permet de stocker ces informations de plusieurs mani`res et je me suis partie culi`rement intress aux suivantes : e e e base de donnes, e chiers textes pour les alertes et chiers binaires6 pour les charges utiles,
Format binaire : il sagit du format de reprsentation lmentaire des donnes en informatique. e ee e Son alphabet est compos de 2 lments : 0 et 1. e ee
6
21/58
socket UNIX7 , format binaire pour lensemble des informations (alertes et charges utiles), appel e unied. En premier lieu, jai test lexportation dans une base de donnes. Mais rapidement, je e e me suis rendu compte quil y avait des probl`mes. Le plus important dentre eux est la e performance. Snort, lorsquil crit dans la base de donnes, doit attendre que celle-ci ait e e trait les informations transmises. Durant ce laps de temps, le ux rseau ne sinterrompt e e pas et des vnements peuvent potentiellement ne pas tre dtects. Le schma de la base e e e e e e de donnes est pour sa part relativement complexe et rend lexploitation dicile. e Lutilisation de chiers textes associs ` des chiers binaires pour les charges utiles e a permet de disposer facilement des alertes. En contrepartie, la rcupration des charges utiles e e correspondantes nest pas directe. De plus, ce format est relativement peu performant. Lutilisation de socket UNIX permet dviter dutiliser de lespace sur le disque en ene voyant directement les informations (les alertes et les charges utiles associs sont alors e groupes) de Snort dans un programme eectuant le traitement souhait. Mais, ce mode de e e fonctionnement comporte le mme inconvnient que la base de donnes : le fait que Snort e e e soit oblig dattendre un autre programme lorsquil retourne ses informations, entra e nant de nouveau un risque de pertes. Le format unied permet de stocker toutes les informations (alertes et charges utiles) dans des chiers binaires. Ce format est celui qui demande le moins de travail ` Snort et permet, a dapr`s sa documentation, de traiter sans pertes un ux Gigabit. Pour sa lecture il ncessite e e lutilisation du logiciel barnyard. Cela permet de dsynchroniser lcriture des informations e e par Snort et leur lecture. Celle-ci peut tre faite indpendamment. Les informations sont e e alors traits sans pour autant entraver le fonctionnement de Snort. e Le principal crit`re de choix tant les performances, jai donc choisi le format le plus e e ecace : le format unied. Il permet de limiter au maximum le nombre dvnements non e e capturs par Snort. De plus, il ore la possibilit de rendre indpendants la capture des e e e informations et leur traitement. Barnyard, lorsquil lit les chier unied, ore les mmes formats de sortie que Snort e accompagns de variantes. Jai choisi dutiliser une de ces variantes : la sortie sous forme e de chier texte contenant ` la fois les alertes et leurs charges utiles associes. Cependant, le a e stockage de telles informations sur le disque dur est compl`tement redondant avec les chiers e unied dj` stocks. Cest pourquoi jai utilis un chier FIFO8 qui ne prend aucune place ea e e sur le disque dur. Barnyard va crire dedans comme dans un chier normal. Tant quun e programme nira pas lire ce chier, barnyard devra attendre (rappelons que ce nest pas gnant du fait de la dsynchronisation avec Snort). e e Une fois ces donnes traites par le syst`me, le rsultat va tre stock dans une base de e e e e e e donnes. Il ne faut cependant pas la choisir au hasard. e
Socket UNIX : cest un moyen de dialogue entre programmes sur une machine ayant un syst`me e dexploitation UNIX. 8 FIFO : First In First Out, cest une structure de donnes o` le premier lment insr est le e u ee ee premier ` sortir. a
7
22/58
3.3.3
Quelle base de donnes ? e
Du fait de la ncessit dutiliser un outil libre et ouvert, le choix se limite principalement e e a ` PostgreSQL et MySQL. PostgreSQL dispose de plus de fonctions tandis que MySQL est cens tre plus pere e formant. De mon point de vue, jai un besoin de performance relatif tandis que certaines fonctionnalits de PostgreSQL peuvent simplier le dveloppement (par exemple, le type de e e donnes INET9 ). Actuellement, les direntes bases de donnes de REAUMUR sappuient e e e sur PostgreSQL. Cependant, dans un souci dvolutivit du syst`me, jai souhait mesurer e e e e les performances de MySQL et PostgreSQL. Jai donc install les deux logiciels sur une e machine de test et cr des conditions dutilisations extrmes (600 000 entres dans la base ee e e qui reprsentent une anne darchives). Jai ensuite eectu direntes requtes : e e e e e pour une lecture de toutes les entres : PostgreSQL a mis 28 secondes tandis que e MySQL en a mis 15, une lecture sous conditions, de sorte ` nobtenir quune centaine dentres correspona e dant ` une recherche (un cas plus proche dune utilisation relle) fait que MySQL a e seondre, il met 240 secondes. PostgreSQL, quant ` lui, ne met que 6 secondes. a Dautres mesures publies sur Internet conrment que PostgreSQL est globalement plus e performant10 . Cependant, cela reste un sujet controvers. e Mon choix se porte sur PostgreSQL surtout du fait de notre exprience de celui-ci et des e fonctionnalits avances quil propose. e e
3.3.4
Quels langages de programmation ?
Pour la partie traitement et automatisation, il est ncessaire de disposer dun langage e pouvant dialoguer simplement avec une base de donnes et orant des structures de donnes e e simples dutilisation mais performantes. Par ailleurs, il faut prendre en compte le langage dans lequel les dirents prototypes e existants ont t dvelopps pour pouvoir potentiellement en reprendre certains. Mon choix ee e e se porte donc sur le langage PERL11 dautant que cest un langage que jai eu plusieurs fois loccasion de manipuler (en particulier pour mon projet technique). Pour la partie interface graphique, il faut que celle-ci soit utilisable quel que soit le matriel de lutilisateur (PC, station UNIX, MAC, ...). Une interface WEB rpond le mieux e e a ` cette demande. Mais quel langage utiliser pour cette interface ?
INET : type de donnes dans PostgreSQL qui permet de manipuler directement des adresses IP e et sous-rseaux IP et deectuer directement des tests dinclusion, de comparaison, etc. e 10 voir ` ce propos http ://benchw.sourceforge.net/ a 11 PERL : Practical Extraction and Report Language, langage de programmation permettant dcrire des scripts puissants. e
23/58
Il faut tout dabord noter que les pages devront tre gnres dynamiquement. On ne e e ee 12 simples. Dans le domaine des pages WEB dynamiques, choisira donc pas les pages HTML on distingue deux possibilits : CGI13 (en utilisant le langage C14 ou le PERL) ou PHP15 . e Du fait des contraintes, les outils non libres tel ASP sont carts. Lutilisation du C (avec e e CGI) pour crer des pages WEB peut tre intressante pour ce qui est des performances e e e quelle procure. Cependant, la complexit dun tel syst`me risque dtre gnante. Il est aussi e e e e possible dutiliser PERL (avec CGI) pour gnrer les pages mais celui-ci na pas t cr e e e e ee dans ce but en premier lieu. Il est donc logique dutiliser loutil le plus adapt ` ce type de ea travail : PHP. Pour des raisons de maintenabilit, la version de PHP que jai choisie est celle qui est e fournie avec la distribution GNU/Linux que nous utilisons : Debian (version Sarge), PHP version 4. Ainsi, les mises ` jour de PHP sont transparentes car gres par la distribution. a ee
3.3.5
Dimensionnement du matriel e
Le matriel utilis est un PC. Il doit tre en mesure de capturer et traiter un ux rseau e e e e Gigabit et stocker les informations pertinentes sur les probl`mes de scurit dans ce ux. Le e e e dimensionnement se fait surtout par rapport aux outils qui vont tre les plus consommateurs e de ressources : Snort et la base de donnes PostgreSQL. e Snort fonctionne depuis de nombreuses annes sur le PC de mon ma dapprentissage. e tre Nous disposons ainsi dinformations sur les besoins en espace disque, de consommation de mmoire vive et de temps processeur pour lutilisation de Snort. Par ailleurs, les bases de e donnes ont besoin de beaucoup de mmoire et de grandes capacits en disque dur. e e e Dans le cadre du syst`me mis en place, le ux rseau peut atteindre 1Gbit full duplex16 e e au maximum. Le choix matriel sest donc port sur un processeur rapide accompagn dune e e e grande quantit de RAM, dun disque dur de capacit relativement leve et surtout dune e e e e carte rseau capable de grer un tel ux. La machine choisie dispose donc dun processeur e e Pentium4 ` 3,4Ghz, avec 1Go de RAM et 160Go de disque et bien videmment une carte a e rseau Gigabit. Dailleurs, il ne sagit pas dune carte sur bus PCI17 mais dun contrleur e o rseau Intel directement intgr ` la carte m`re. Cela ore de meilleures performances (pas e e ea e de limitation de bande passante ` cause du bus PCI qui sav`re limit aux environs de a e e 500Mbit/s dans le meilleur des cas).
HTML : HyperText Markup Language, langage permettant dcrire des pages dites hypertextes. e Celles-ci permettent de relier des documents stocks sur dirents serveurs par lintermdiaire de e e e liens. 13 CGI : Common Gateway Interface, permet de faire dialoguer un navigateur WEB avec un programme excut ct serveur qui peut tre crit en nimporte quel langage. e e oe e e 14 Langage C : langage de programmation datant des annes 70, performant, mais complexe. e 15 PHP : langage de programmation spciquement cr pour lcriture de pages WEB dynamiques. e ee e 16 Full duplex : permet un change simultan dinformations (mission et rception en mme temps) e e e e e 17 PCI : Peripheral Component Interconnect, lment interne ` un PC permettant de connecter ee a des cartes dextensions, comme par exemple une carte rseau... e
12
24/58
3.4
Faisabilit du dveloppement e e
Le travail ` faire est en partie un redveloppement. La faisabilit de celui-ci est donc a e e relativement garantie du fait quil existe dj` un certain nombre dlments en tat de ea ee e marche mme sils doivent tre rcrits. e e ee La partie du syst`me qui concerne lautomatisation nexiste pas du tout. La faisabilit e e 18 ont permis de valider de cette partie est incertaine mais dirents prototypes jetables e certains concepts.
18 Prototype jetable : cest un programme qui sert ` vrier quil est possible deectuer une tche. a e a Il est crit rapidement et nest pas destin ` tre utilis par la suite. Il permet de se faire une premi`re e eae e e exprience. e
Chapitre 4
Ralisation e
Le contexte du projet est le suivant : je suis seul ` dvelopper, je re-conois certains a e c lments en me basant sur les prototypes de mon ma ee tre dapprentissage tandis que je conois les lments qui manquent (toute la partie automatisation). c ee Le but est dobtenir rapidement un syst`me utilisable pour ensuite lamliorer en fonction e e de la rponse de celui-ci aux besoins. On sinspire en particulier de la mthode RAD1 . e e
4.1
Les tapes de la ralisation e e
An de dnir au mieux le besoin des utilisateurs, une enqute a t ralise. Elle ma e e ee e e permis dlaborer le cahier des charges fonctionnel du syst`me qui rpond donc, dans la e e e mesure du possible, aux besoins des utilisateurs et ` la problmatique. a e Une fois ce cahier des charges valid, je me suis pench sur la cration dun mod`le e e e e conceptuel des donnes (MCD) permettant de disposer de toutes les informations pour e pouvoir raliser les direntes fonctions dans le cadre des contraintes formules. e e e Les dirents mod`les conceptuels des donnes que jai pu construire ont t discuts avec e e e ee e mon ma tre dapprentissage. Lobjectif de ces discussions tait de disposer dune version e cohrente avec les besoins mais pas trop complexe ` mettre en oeuvre tout un conservant e a un haut niveau de performance. Nous avons donc choisi de nous inspirer de la mthode RAD, du fait de son fonctione nement sur la base de prototypes et la construction de lapplication par modules. Nous nous en inspirons seulement car il est toujours dicile dappliquer une mthode de mani`re e e orthodoxe (dans notre cas, par exemple, il a t impossible de ne pas dpasser 120 jours de ee e dveloppement et de faire valider chaque tape du dveloppement par les utilisateurs). e e e
RAD : Rapid Application Development, mthode de dveloppement rapide dapplication, fonde e e e sur des cycles courts et une forte interaction avec les utilisateurs
1
Chapitre 4. Ralisation e
26/58
4.2
Enqute e
Lenqute a t mene aupr`s de tous les correspondants de REAUMUR (au nombre de e ee e e 200). Il y a eu 59 rponses individuelles soit plus de 25%. Elle a permis de dterminer plus e e prcisment les besoins des utilisateurs et surtout dnir lordre de priorit des dirents e e e e e lments ` dvelopper. ee a e
4.3
Prsentation du cahier des charges fonctionnel e pour le dveloppement e
Je vais dans cette partie prsenter les fonctions du syst`me extraites du cahier des charges e e fonctionnel du syst`me. La version compl`te de celui-ci se trouve en annexe : B page IV. e e Pour crire celui-ci, jai utilis la mthode de lanalyse fonctionnelle. e e e
4.3.1
Situations de vie
Voyons tout dabord les direntes situations dans lesquelles va se trouver le syst`me : e e installation, exploitation, maintenance, volution. e
Ces direntes situations reprsentent les dirents cas quil faut prvoir dans le cadre e e e e de la vie du syst`me. e
4.3.2
Dnition des fonctions du syst`me e e
Dnissons quelques termes : e FP est une fonction principale, celle-ci dnit la rponse ` un besoin, e e a FC est une fonction contrainte. FP1 Le syst`me permet ` lquipe REAUMUR dautomatiser partiellement la gestion de e a e la scurit. e e FP2 Le syst`me permet aux correspondants de grer les leves de ltrages les concernant. e e e FP3 Le syst`me permet ` lquipe REAUMUR de visualiser tous les vnements et infore a e e e mations collects de lensemble du rseau. e e FP4 Le syst`me permet aux correspondants de visualiser les vnements et informations e e e collects de la partie du rseau les concernant. e e FP5 Le syst`me permet ` lquipe REAUMUR de choisir une ou plusieurs actions pour un e a e vnement non trait automatiquement. e e e FP6 Le syst`me permet aux correspondants de personnaliser le comportement de celui-ci e pour leur domaine.
27/58
FP7 Le syst`me permet aux utilisateurs naux de lever un ltrage concernant leur machine. e
FC1 Le syst`me doit respecter les r`gles de scurit informatique. e e e e FC2 Le syst`me doit avoir une interface homme/machine intuitive et ergonomique. e FC3 Le syst`me doit disposer dune interface machine/machine (option). e FC4 Le syst`me doit utiliser des standards libres et ouverts. e FC5 Le syst`me doit disposer doutils de mesure sur son utilisation. e FC6 Le syst`me doit pouvoir sinterfacer avec les outils utiliss. e e FC7 Le syst`me doit signaler les vnements. e e e FC8 Le syst`me doit avoir son code source et sa documentation technique en anglais. e FC11 Le syst`me doit tre disponible sous forme de paquet Debian (option). e e FC21 Le syst`me doit pouvoir tre maintenu par dautres personnes que le dveloppeur e e e initial. FC22 Le syst`me doit tre modulaire. e e FC31 Le syst`me doit pouvoir sadapter aux volutions du rseau. e e e FC32 Le syst`me doit pouvoir disposer dune interface en plusieurs langues (option). e
28/58
4.4
Analyse et principe de fonctionnement
Je vais ici dtailler lanalyse qui a t faite en vue dobtenir le mod`le conceptuel des e ee e donnes (cf. Annexe C page XIII) et les grandes lignes ` suivre pour le dveloppement. e a e Dun point de vue global, le fonctionnement peut tre schmatis sur la gure 4.1 page e e e 28. Je vais par la suite le dtailler lment par lment. e ee ee
Access List sur Routeur
Traitement manuel
Quarantaine
E-Mail
script PERL
Excution
Dcisions
Exceptions
Script PERL
Prise de dcision Actions par catgorie
Catgories
Problmes de scurit
Script PERL
Analyse
Lgende
Scan de port Dtection de signatures
Script PERL
Anti-virus
volutions possibles
Script PERL
Script PERL
Script PERL
Table dans la base de donnes
Traitement des scans de ports
Traitement des alertes sur signatures
Extraction infos des journaux
Traitement
Script PERL
Programme PERL
Snort
Journaux
Source
Source d'informations
Fig. 4.1 Principe de fonctionnement du syst`me e
29/58
4.4.1
Les sources dinformations
vnements agrgs
Script PERL
Traitement : agrgation
vnements
Source
Fig. 4.2 Traitements des vnements de scurit provenant des sources e e e e

La base du syst`me est compose de direntes sources dinformations. Ces sources sont e e e pour le moment les suivantes : la sonde de dtection dintrusions fournit les informations suivantes : e - dtection de scan de ports2 ; e - dtection de signatures3 dans le ux rseau ; e e journaux de lantivirus du serveur de courrier lectronique de REAUMUR. e Les lments qui proviennent de ces sources sont qualis dvnements de scurit. ee e e e e e Il faut noter que ces sources dinformations sont quantitativement tr`s riches, mais les e informations sont souvent rcurrentes. Prenons un exemple : un virus a contamin une e e machine, lorsquil va se dupliquer et envoyer des courriers lectroniques infects, chacun e e va dclencher un vnement de lantivirus. Par ailleurs, la sonde de dtection dintrue e e e sion lorsquelle dtecte des communications correspondantes ` ses signatures gn`re autant e a e e dvnements que de paquets de donnes dans la communication. e e e Il est donc ncessaire dagrger ces informations de mani`re ` ne pas remplir inutilement e e e a la base de donnes tout en disposant des informations ncessaires et susantes pour pouvoir e e ensuite analyser le probl`me. La gure 4.2 page 29 illustre ce mcanisme. e e
Un scan de ports sur un rseau est une action qui vise ` dtecter les failles potentielles dans la e a e scurit des machines connectes ` ce rseau : cet vnement est souvent un signe dacte de piratage e e e a e e e ou de prsence dun virus. e 3 Il est possible de caractriser un ux rseau nement en analysant son contenu et en le compae e rant ` des signatures rpertoriant les dirents comportements de pirates, virus ou encore logiciels a e e utilisant le rseau. e
2
30/58
Des sources supplmentaires peuvent tre ajoutes. Il sut de crer : e e e e un lment traduisant les informations rendues par la source en vnements agrgs ee e e e e dans une table, une table contenant ces vnements agrgs, e e e e une fonction dans le programme danalyse pour grer ce qui provient de cette nouvelle e table.
4.4.2
Lanalyse des donnes : plusieurs vnements de e e e scurit pour un unique probl`me de scurit e e e e e
Problmes de scurit
Script PERL
Analyse Scan de port Dtection de signatures Anti-virus volutions possibles
Fig. 4.3 Analyse et seconde agrgation des vnements de scurit provenant des e e e e e sondes
Une fois les vnements de scurit analyss, il en dcoule des probl`mes de scurit. e e e e e e e e e Une premi`re agrgation est donc faite au niveau des sources dinformations mais il e e reste encore ` pouvoir faire des recoupements entre ces direntes sources. En eet, un a e mme probl`me de scurit peut avoir pour origine plusieurs types dvnements sur les e e e e e e direntes sources. Par exemple, un virus nutilise gnralement pas quun seul vecteur de e e e contamination. Il va ` la fois envoyer des courriers lectroniques et eectuer un scan du a e rseau. Ainsi, lantivirus va dtecter les courriers lectroniques contamins et la sonde de e e e e dtection dintrusion va dtecter le scan. Comme ces deux vnements correspondent au e e e e mme probl`me de scurit, le syst`me doit faire le lien entre eux. e e e e e Pour pouvoir rpondre simplement ` ce besoin de recoupement, jai fait le choix daecter e a des catgories ` chaque type dvnement prcis. Par exemple, un scan sur certains ports e a e e e va tre catgoris comme tant le fait dun virus tandis quun vnement provenant de e e e e e e lantivirus sera lui aussi dans cette catgorie. Ces catgories sont stockes dans la base de e e e donnes et leur nombre est relativement faible. e
31/58
Les dirents vnements provenant des sources sont dans leurs tables respectives. e e e Un programme va donc les lire de mani`re ` agrger les vnements en fonction de leur e a e e e catgorie. Ainsi, la table des probl`mes de scurit va recevoir un seul probl`me pour un e e e e e ensemble dvnements dune mme catgorie sur une machine donne. La gure 4.3 page e e e e e 30 reprsente ce mcanisme. e e
4.4.3
La prise de dcision et laction en dcoulant e e
Dcisions
Exceptions
Script PERL
Prise de dcision Actions par catgorie
Catgories
Problmes de scurit
Fig. 4.4 Prise de dcision en fonction des param`tres e e

Les vnements qui reprsentent le mme probl`me sont donc regroups dans des e e e e e e catgories. Par exemple, lutilisation de clients Peer to Peer tel Kazaa, Edonkey, Emule e va gnrer des vnements distincts mais ceux-ci font partie de la mme catgorie : Peer e e e e e e to Peer. Il sut dassocier un comportement ` chaque catgorie pour voir se proler une a e action automatise rpondant ` chaque vnement. Par exemple, la catgorie Peer to Peer e e a e e e entra une mise en quarantaine de la machine source des vnements. ne e e Ainsi, la prise de dcision se fait d`s lors quun nombre susant dvnements se produit e e e e pour viter les faux positifs4 . De plus, il faut que le syst`me puisse prendre une dcision. e e e En eet, pour certaines catgories, on sait que les informations doivent tre analyses par e e e un ingnieur. Le syst`me pose donc une question dans ce cas. e e La prise de dcision est faite suivant la catgorie. La dcision associe donc le probl`me e e e e a ` laction qui en dcoule. De plus, une liste dexceptions permet dviter de mettre cere e
Faux positifs : les syst`mes de dtection dintrusion ne sont pas exempts de dfauts. Il est parfois e e e possible que des comportements rseaux lgitimes soient considrs comme anormaux. Cependant, e e ee ce genre derreur est tr`s rare. e
4
32/58
taines machines vitales (serveurs de courrier, serveurs dapplication, etc.) en quarantaine. Ce processus est illustr par la gure 4.4 page 31. e Il est prvu de pouvoir eectuer des modications du comportement du syst`me pour e e les catgories de mani`re ` ce que les utilisateurs puissent personnaliser ce comportement. e e a Cependant, les actions choisies ne peuvent tre que plus sv`res que celles faites par dfaut. e e e e Les actions possibles sont : demander lanalyse manuelle, avertir le correspondant dun site par courrier lectronique lorsquun probl`me est e e dtect, e e mettre en quarantaine une machine. Les dcisions sont stockes dans une table et chacune associe donc un probl`me de scurit e e e e e a ` laction correspondante.
4.4.4
Une fois la dcision prise, son application e
Access List sur Routeur
Traitement manuel
Quarantaine
E-Mail
script PERL
Excution
Dcisions
Fig. 4.5 Excution des dcisions prises par le syst`me e e e

Lorsque la dcision est prise par le syst`me, elle est donc applique sur le rseau. Un e e e e programme va eectuer les actions en attente. Ces actions sont associes aux dcisions qui e e ne sont pas encore traites. La gure 4.5 page 32 illustre cette derni`re tape. e e e Les courriers lectroniques sont envoys aux correspondants concerns et sont reus en e e e c copie par les responsables scurit de REAUMUR. e e La mise en quarantaine seectue en plaant des r`gles de ltrage sur un routeur de c e REAUMUR. Potentiellement, dautres moyens de ltrages peuvent tre mis en oeuvre. e
33/58
Enn, la demande de traitement manuel se fait par courrier lectronique aux responsables e scurit de REAUMUR uniquement. e e
4.4.5
Linteraction des utilisateurs avec le syst`me e
Une fois les probl`mes de scurits traits au niveau de REAUMUR, les machines mises en e e e e quarantaine, si ncessaire, et les correspondants avertis, il faut encore que ceux-ci liminent e e le probl`me. Ils peuvent ensuite directement interagir avec le syst`me pour signaler ` celui-ci e e a que le probl`me est rsolu. Il sagit de la procdure dacquittement. e e e Dans certains cas, lutilisateur nal peut avoir les connaissances ncessaires ` e a llimination du probl`me (par exemple en utilisant un antivirus). Il se voit orir la possie e bilit dinteragir avec le syst`me. Ainsi, il peut signaler que le probl`me est rsolu et donc e e e e acquitter celui-ci. Cependant, si jamais le probl`me est toujours prsent et quune mise en e e quarantaine est de nouveau eectue, lutilisateur nal ne pourra plus eectuer dacquittee ment pour une journe et devra contacter le correspondant responsable de son site. Cest e une mani`re de se protger contre dventuels abus dutilisateurs qui enfreignent sciemment e e e la charte REAUMUR. Chaque acquittement est enregistr de mani`re ` pouvoir retracer les actions eectues e e a e sur le syst`me. e
4.5
Dveloppement du syst`me e e
Point par point, je vais faire maintenant le lien entre la conception et lcriture du code e du syst`me en explicitant les choix que jai eus ` faire et les dicults auxquelles jai t e a e ee confront. e
4.5.1
Pour les sources dinformations
A la base du syst`me, il y a donc les trois sources dinformations que jai voques e e e prcdemment, ` savoir les rsultats de scans de ports (Snort), les dtections de signatures e e a e e dans le ux rseau (Snort) et les comptes-rendus de lanti-virus du serveur de courrier e lectronique. e Globalement, les trois sources peuvent tre considres comme de la lecture de chier e ee texte : pour les scans de port, Snort crit directement dans un chier ses comptes rendus, e pour la dtection de signatures, Snort crit dans des chiers binaires qui vont tre e e e ensuite convertis par un autre logiciel en format texte (voir la section 3.3.2 page 20 pour lexplication sur ce point) pour des questions de performance, les comptes-rendus de lanti-virus sont crits dans les journaux du syst`me. e e Le travail ` eectuer dans les trois cas consiste ` lire ces informations et ` conserver a a a uniquement les donnes utiles pour ensuite ne stocker dans la base de donnes que le strict e e ncessaire. e
34/58
Le fonctionnement interne du module qui fait cette agrgation est relativement simple. e Il est dcrit sur la gure 4.6 page 34. e
Image de Ajout dans la base de donnes ou mise jour si besoin est rythme : de l'ordre de la minute
Dcoupage
vnements Table de hachage en mmoire
rythme : instantan
vnements agrgs
Fig. 4.6 Fonctionnement de lagrgation des vnements provenant des sources e e e

Le ux dentre (le texte) est dcoup de mani`re ` disposer des informations utiles pour e e e e a chaque ligne lue. Pour viter daccder de mani`re incessante ` la base de donnes, ces e e e a e 5 . Celle-ci est indexe informations sont crites en mmoire vive dans une table de hachage e e e suivant les lments constituant la clef primaire6 de la table correspondante dans la base ee de donnes. e La table de hachage et la base de donnes contiennent au nal les mmes informations e e mais chacune a un rle prcis. La table de hachage sert de mmoire de travail tandis que la o e e base de donnes sert de mmoire ` long terme et surtout permet linteraction avec le reste e e a du syst`me. e Lorsquun lment se rp`te, il va avoir le mme index que loccurrence prcdente dans ee e e e e e la table et seules certaines informations vont tre mises ` jour (avec donc crasement des e a e anciennes valeurs). Ces informations sont le nombre doccurrences de lvnement et la date e e de la derni`re occurrence. e Pour minimiser les acc`s ` la base de donnes, ceux-ci sont faits ` intervalles rguliers et e a e a e uniquement sil y a une information ` ajouter ou mettre ` jour. Lorsquil y a des oprations a a e a ` eectuer, il faut savoir quels sont les lments ` traiter dans la table de hachage pour les ee a direncier de ceux dj` traits. Plutt que de mettre cette information directement dans la e ea e o table que jai dnie auparavant, jai fait le choix de crer des tables contenant uniquement e e les index des lments devant tre ajouts ou mis ` jour dans la base de donnes. Ceci ee e e a e permet dviter de parcourir tous les lments de la table de hachage pour savoir lesquels e ee doivent faire lobjet dune opration avec la base de donnes. e e Cependant, cette structure a un inconvnient. Lors du redmarrage dun module, il est e e ncessaire de synchroniser la table de hachage avec la base de donnes. e e
Une table de hachage est un tableau dans lequel les informations ne sont pas indexes suivant e des numros mais par des clefs. Celles-ci peuvent tre de nimporte quel type (mot, chire, etc.). e e Le gros avantage dune telle structure de donnes est la possibilit davoir un acc`s direct ` chaque e e e a lment du tableau sans avoir ` le parcourir. ee a 6 Elment identiant de mani`re unique une ligne dans une table dune base de donnes. e e e
5
35/58
4.5.2
Lanalyse des donnes e
Voyons maintenant comment les informations provenant des direntes sources sont e traites pour les regrouper en fonction des probl`mes quelles traduisent. e e La gure 4.7 page 35 illustre ce mcanisme. e
Affectation une catgorie

Dtection de signature

Anti-virus

Scan de ports
Agrgation suivant les catgories
Ajout dans la base de donnes ou mise jour si besoin est rythme : de l'ordre de la minute
Problmes de scurit
Fig. 4.7 Fonctionnement du classement en catgories et de lagrgation suivant e e celles-ci

Suivant le principe expliqu auparavant, les probl`mes sont distingus par des catgories. e e e e Pour aecter un vnement (dune source dinformation) ` une catgorie, il faut plus ou e e a e moins de travail en fonction de linformation. Linformation la plus prcise est celle qui provient de la dtection de signature. En eet, e e chaque vnement dispose dun identiant et il est possible de dnir ` quelle catgorie e e e a e appartient chacun dentre eux. Linformation la plus simple est celle qui vient de lanti-virus. Tout vnement provenant e e de cette source correspond tout simplement ` la catgorie virus. a e Par contre, les vnements provenant de la dtection de scan de ports sont plus diciles e e e a ` classer. En eet, il est ncessaire deectuer un traitement de ces informations, ` savoir e a comparer le comportement observ par rapport ` des comportements types, chacun de e a ceux-ci tant associ ` une catgorie. e ea e Une fois chaque vnement aect ` une catgorie, un recoupement suivant celles-ci est e e ea e eectu. De cette mani`re, on obtient les probl`mes de scurit que lon peut stocker dans e e e e e la base de donnes. e
4.5.3
La dcision e
La prise de dcision se fait de mani`re simple. Seuls les probl`mes de scurit qui ont e e e e e t modis ou qui sont nouveaux sont lus. Le programme vrie si les machines ` lorigine ee e e a
36/58
des probl`mes ne sont pas dans les exceptions. Il crit ensuite dans la table des dcisions les e e e actions correspondant ` la catgorie de chaque probl`me de scurit. Dans les faits, il sagit a e e e e de requtes dans la base de donnes. e e
4.5.4
Lexcution de la dcision e e
Lorsque la dcision est prise par le syst`me, celle-ci nest pas instantanment applique. e e e e Par exemple, dans le cadre de la propagation dun virus, si toute nouvelle dtection de e celui-ci entra une action directe, il y a un risque de saturer lquipement sur lequel nous ne e mettons en place la quarantaine. Le programme qui excute les dcisions va donc regrouper les changements ` eectuer e e a sur les quipements et excuter ceux-ci de mani`re rguli`re. e e e e e
4.6
Interface graphique
Dans la recherche de solutions, le choix a t fait dutiliser une interface WEB dynamique. ee Le langage choisi pour construire cette interface est le PHP. Cependant, lutilisation de PHP seul ne permet pas facilement de disposer dune interface multilingue et permettant des vues direntes suivant les utilisateurs. Des outils permettent de simplier la rponse ` e e a ces contraintes : ce sont les moteurs de templates.
4.6.1
Utilisation de moteurs de templates
Les moteurs de templates permettent une sparation entre le fond (la partie programe mation) et la forme (la prsentation des pages aches). e e Leur utilisation est relativement simple. La partie xe des pages scrit en HTML e classique et contient certains marqueurs associs au moteur de templates. Ces marqueurs e reprsentent les donnes dynamiques que lon ins`re dans les pages. La partie programmae e e tion se fait en PHP classique et certaines commandes associes aux moteurs de templates e permettent dassigner des donnes aux marqueurs. e De cette mani`re, il est possible dutiliser le mme code PHP avec direntes pages e e e HTML qui reprennent les marqueurs que lon souhaite. Dans notre cas, le mme code PHP e va permettre avec plusieurs pages HTML de disposer de vues spciques ` chaque utilisateur e a (niveau variable de dtails dans les informations) et potentiellement, il est possible dcrire e e les pages HTML dans dautres langues.
4.6.2
Choix du moteur de templates
Il existe une multitude de moteurs de templates dans les logiciels libres. Dans le cadre du syst`me, nous souhaitions disposer dun outil prenne. Or, un projet est actuellement e e soutenu par lorganisation responsable de PHP. Il sagit de Smarty. De plus, celui-ci est
37/58
fourni dans la distribution GNU/Linux que nous utilisons (Debian), ce qui nous garantit des mises ` jours simples. a Cest donc vers cet outil que je me suis tourn pour crer linterface du syst`me. e e e
4.6.3
Scurit e e
Les applications crites en PHP peuvent faire lobjet dattaques. Les pirates cherchent e gnralement ` prendre le contrle des machines sur lesquelles sont excutes ces applicae e a o e e tions. Elles reprsentent une porte dentre potentielle si elles sont mal crites. e e e Linterface du syst`me ne concerne que les utilisateurs du campus. Le risque davoir un e pirate sur le campus est relatif car les menaces proviennent gnralement de ltranger. e e e Mais, il peut toujours y avoir des tudiants en informatique dous qui, par jeu, peuvent e e tenter de pirater le syst`me. e La programmation de linterface a donc t faite suivant lide quil y avait des meee e naces potentielles sur le campus. Cela se traduit par un souci constant de protection des informations contre leur modication et leur lecture non autorises. e Il faut donc pouvoir faire la distinction entre les dirents types dutilisateurs qui e acc`dent au syst`me. Cette distinction se traduit par lauthentication des utilisateurs. e e
4.6.4
Authentication
Lauthentication a t conue de mani`re solide pour quil ny ait pas de possibilit ee c e e dusurper lidentit dun utilisateur. e Pour se faire, nous utilisons les certicats X.5097 . Ils orent une authentication forte et quasi inviolable (quasi car aucune protection na le mrite dtre infaillible). Cependant, e e tous les utilisateurs ne disposent pas de certicats sur le campus. Il est ncessaire dorir e un autre moyen. Dans le cadre du dploiement du WiFi8 sur le campus, un outil est en cours de mise en e oeuvre par un stagiaire ENSEIRB (2`me anne li`re informatique) : Mathieu Geli. Cet e e e outil est Shibboleth. Il permet lauthentication dutilisateurs enregistrs sur les dirents e e annuaires des universits. Cest un syst`me qui permet le SSO9 . Sa mise en oeuvre est tr`s e e e simple au niveau du syst`me et sera utilise pour la mise en production. e e
Certicats X.509 : un certicat permet, comme son nom lindique, de certier quun utilisateur ou une machine sont biens ceux quils prtendent. Le standard X.509 est le plus utilis. e e 8 WiFi : Wireless Fidelity, technologie de rseau sans l en plein essor. e 9 SSO : Single Sign On, lauthentication est faite une seule fois et permet daller, sans avoir ` a ressaisir son mot de passe, sur toutes les applications utilisant cette mthode. e
7
38/58
4.6.5
Prsentation des informations et des interactions pose sibles
Il faut rappeler que les correspondants ont des niveaux en informatique tr`s variables. e Linterface a donc t conue pour prsenter les informations les plus simples en premier ee c e lieu. Lacc`s ` des informations plus compl`tes et complexes est possible mais nest pas e a e prsente en premier pour ne pas submerger les correspondants non informaticiens. e e Les interactions possibles (tel lacquittement) sont directement accessibles dans la prsentation simple des probl`mes. e e
Chapitre 5
Mise en production
D`s lors que le dveloppement arrive ` un stade susamment avanc (cest-`-dire, lorsque e e a e a chaque sous-programme fait le travail quil a ` faire dans son environnement de donnes), a e il faut faire travailler les dirents sous-programmes dans un contexte rel (` savoir sur les e e a informations transitant rellement sur le rseau). e e Ces essais se font en plusieurs tapes qui correspondent ` des versions du syst`me. e a e La premi`re version sappelle la version alpha. Il sagit dune version qui na jamais subi e de test dans son ensemble. Cest une version uniquement teste en interne et qui permet e daner le dveloppement. e Elle est suivie par une version beta. Elle se distingue de la version alpha du fait quelle a dj` subi des tests et est accessible ` des utilisateurs volontaires. Cette version permet ea a dapporter les derni`res modications avant dobtenir une version quon qualiera de stable. e
5.1
Premi`re tape : version alpha e e
Au mois de mars 2005, nous avons dcid de lancer la premi`re phase de test grandeur e e e nature du syst`me : la version alpha. e
5.1.1
Le syst`me e
Le syst`me ntait alors que partiellement construit. Les lments fonctionnels taient : e e ee e le traitement des alertes sur signatures, le traitement de la dtection de scan de ports, e lanalyse et lagrgation, e la prise de dcision, e lexcution semi-automatique mais pas lenvoi de courriers lectroniques. e e
Il manque le traitement des informations provenant de lantivirus et lexcution autoe matique avec envoi de courriers lectroniques. En eet, pour viter tout risque de mise en e e quarantaine errone, chacune dentre elles doit tre valide avant sa mise en oeuvre eective. e e e
Chapitre 5. Mise en production
40/58
5.1.2
Linterface
Linterface est alors tr`s sommaire. Elle prsente sur une seule page les direntes actions e e e possibles et ne dispose daucune scurit hormis son isolation du reste du campus. Elle est e e a ` usage strictement interne (visible uniquement depuis nos machines).
5.1.3
Rsultats e
Par ce test, nous avons pu constater le relatif bon fonctionnement des dirents modules e en conditions relles. Mais des probl`mes sont apparus quant ` la abilit du syst`me e e a e e dans le cas dun fonctionnement prolong. Ces probl`mes ont t analyss par mon ma e e ee e tre dapprentissage et moi mme. A la suite des observations que nous avons pu faire jai donc e apport les corrections ncessaires et continu le dveloppement des lments manquants. e e e e ee De mani`re ` valider les modications, chacune dentre elles a t intgre dans la version e a ee e e alpha. En parall`le linterface a t amliore. e ee e e Une fois le syst`me arriv ` un niveau satisfaisant de abilit et de fonctionnalit nous e ea e e avons donc dcid de qualier la version alpha courante comme tant la version beta. e e e
5.2
Deuxi`me tape : version beta e e
Le syst`me ` ce stade est jug comme en mesure de fonctionner dans son contexte rel e a e e (avec des utilisateurs). Le 23 juin 2005, le syst`me a donc t mis en pr-production et des e ee e acc`s ont t ouverts pour certains correspondants. e ee
5.2.1
Le syst`me e
Tous les lments du syst`me taient prts. Cependant, nous avons dcid de ne pas ee e e e e e encore laisser le syst`me fonctionner de mani`re totalement automatique. Durant deux e e semaines, les envois de courriers lectroniques et les mises en quarantaines ont t valids e ee e manuellement. Le 11 juillet, le syst`me a t rendu autonome. e ee Au fur et ` mesure que dventuels probl`mes seront observs dans le fonctionnement, les a e e e corrections associes seront apportes et intgres ` la version beta. Lorsque nous (quipe et e e e e a e testeurs) nobserverons plus de probl`mes, le syst`me aura atteint un tat de fonctionnement e e e satisfaisant et pourra tre valid. e e
5.2.2
Linterface
Le moteur de templates Smarty est donc utilis et permet actuellement les vues multiples e sur le syst`me. Lauthentication nest pas encore dans son tat nal. Celle-ci se fait pour e e
Chapitre 5. Mise en production
41/58
linstant par certicats X.509 mais durant lt, lauthentication par Shibboleth va tre ee e mise en oeuvre. Linterface en elle-mme doit tre valide par les correspondants et modie suivant leurs e e e e retours.
5.3
Version de production stable livre pour sepe tembre apr`s validation e
Une fois que le syst`me et son interface seront valids, au plus tard dbut septembre, il e e e sera possible de qualier le syst`me comme tant dans sa version de production. A partir de e e celle-ci, une nouvelle version verra le jour : la version de dveloppement. Cette version sera e indpendante de la version de production, et voluera dans le cadre de sa diusion dans la e e communaut des logiciels libres. e Il est fort probable que le syst`me et son interface soient valids avant septembre mais e e durant lt une grande partie des correspondants et utilisateurs du rseau sont absents. Il ee e est donc prfrable de faire le lancement au mois de septembre. ee
Chapitre 6
Bilan du projet
6.1 Rponse au cahier des charges fonctionnel e
La rponse au cahier des charges fonctionnel peut tre mesure sur la version actuellement e e e en fonctionnement. Cette rponse est la suivante pour les fonctions principales : e Fonction Rponse e FP1 totale FP2 totale FP3 grande FP4 grande FP5 totale FP6 faible FP7 totale
et pour les contraintes : Fonction Rponse e Fonction Rponse e FC1 totale FC11 non fait FC2 a ` valider FC21 faible FC3 non fait FC22 totale FC4 totale FC5 faible FC32 faible FC6 totale FC7 totale FC8 totale
FC31 grande
Pour les fonctions traites partiellement ou non traites ` ce jour, les raisons sont les e e a suivantes : FP3 Tous les vnements dtects sont visibles, les archives aussi, mais les statistiques ne e e e e sont pas encore faites. FP4 Idem FP3 mais du point de vue des correspondants. FP6 Les correspondants ne peuvent pas personnaliser le comportement du syst`me pour e leur domaine actuellement. Mais la structure de la base de donnes a t prvue pour e ee e le permettre. Par contre, la partie de linterface orant ce service nest pas crite. e FC2 Les correspondants participant au test de la version beta vont valider ou non si linterface est intuitive et ergonomique. FC3 Linterface machine/machine na pas t dveloppe car lenqute a montr que ee e e e e celle-ci nintressait quune faible partie des correspondants. Le dveloppement, la e e scurisation, les tests auraient demands un temps non ngligeable. e e e FC5 Il est prvu de pouvoir eectuer des mesures, celles-ci jusqu` maintenant ont t e a ee faites manuellement, mais il ny a actuellement pas de programme crit pour faire ces e
Chapitre 6. Bilan du projet
43/58
mesures. FC11 La distribution sous forme de paquet Debian se fera lors de la mise ` disposition du a syst`me dans la communaut des logiciels libres. e e FC21 Le code est actuellement en grande partie comment en anglais, mais la documene tation technique nest pas encore prte. e FC31 Les volutions de dbits ne posent pas de probl`me par le choix des outils qui a e e e t fait. Par contre, lvolution ` IPV6 ncessitera quelques petites modications sur ee e a e certaines portions de code (qui g`rent les adresses IP). e FC32 Actuellement, seule la version franaise de linterface est prte, mais lutilisation c e de moteurs de template permettent facilement lutilisation dune autre langue pour linterface. Il reste cependant ` traduire tous les textes. a Au nal, nous estimons avec mon ma dapprentissage (qui estime le projet termin tre e a ` 90%) que le projet rpond en grande partie aux besoins, le manque principal est la e documentation technique compl`te. Celle-ci devrait tre termine dici la mise en production e e e nale.
6.2
Respect du planning
Le planning eectif (gure 6.1) du projet est le suivant :
2004
M Conception CDCF MCD Ralisation Base de donnes Intgration existant Dveloppement Interface graphique Documentation Developpeur Utilisateur Prsentation Interface Validation Tests Mesures Maintenance A M J J A S O N D J F M A
2005
M J J A S
Fig. 6.1 Planning eectif du projet
44/58
La ligne rouge correspond ` la version alpha, la jaune ` la version beta et la verte ` la a a a version de production. En comparant le planning prvisionnel et le planning eectif, on peut distinguer plusieurs e carts : e un premier retard sur le dbut du projet. e En eet durant les mois de mars et davril des tches qui ntaient pas prvues mont a e e t attribues par mon ma dapprentissage. Il sagissait de la conguration et de ee e tre linstallation dune dizaine de routeurs dans le cadre du renouvellement des liaisons avec des sites distants ; un cart global entre les dures estimes et les dures eectives pour les tches de e e e e a conception et de ralisation. e Les tches quotidiennes ont t sous-values et mon implication dans le service a a ee e e t plus importante que prvue (consommation de 50% de mon temps). Enn, jai ee e sous-estim le temps de conception et de ralisation. e e
6.3
Co t du projet u
Le cot du projet peut tre vu sous 2 angles : dune part le cot eectif (ce quil a cot) u e u ue dautre part le cot potentiel (ce quil aurait pu coter si un autre choix de solution avait u u t fait). ee
6.3.1
Co t eectif u
Pour la validation du th`me de mmoire, un budget prvisionnel avait t x. Il tait e e e ee e e de 20 000 e et se rpartissait ainsi : 15 000 e pour mon salaire et 5 000 e pour le matriel. e e Or je nai pas pass tout mon temps sur le projet et le matriel achet a t moins onreux e e e ee e que prvu. e Ainsi, le cot de dveloppement du projet est simple ` calculer. Il a fallu assurer ma u e a rmunration pendant 15 mois (dure totale du projet) avec un ratio dactivit sur le projet e e e e de lordre de 50%, ceci nous donne 7 mois et demi de salaire apprenti (soit environ 7 500 e). ` A cela, il faut ajouter le prix de la machine hbergeant le syst`me : 2 000 e. Ce qui donne e e un total de 9 500 e. Si on consid`re le cot global, il ne faut pas se limiter au cot dachat et de dveloppement e u u e mais prendre aussi en compte le cot de la maintenance. u La maintenance du matriel est assure par la socit qui nous a fourni la machine (cot e e ee u de lextension de garantie 3 ans compris dans le prix donn prcdemment). Par contre, au e e e niveau logiciel, une fois le syst`me valid en production, les bugs rsiduels seront en nombre e e e relativement faible. De plus, tant donn que le syst`me va tre distribu sous forme de e e e e e logiciel libre, une grande communaut de dveloppeurs pourra participer ` sa maintenance. e e a Il reste maintenant la gestion des dirents dveloppeurs qui participeront ` e e a lamlioration du logiciel en fonction de nouveaux besoins. Actuellement, rien nest e prvisible, dautant plus que les amliorations potentielles am`neront des gains non cale e e
45/58
culs. e Le cot de maintenance peut tre considr comme tr`s infrieur au cot de u e ee e e u dveloppement. e Au nal, le cot eectif du projet est infrieur ` 10 000e, soit la moiti du budget u e a e prvisionnel. e
6.3.2
Co t potentiel u
Les solutions sur lesquelles nous aurions pu nous appuyer sont : Cisco PIX 525 : 9 930 e1 , Cisco ASA 5540 : 14 060 e, CheckPoint Enterprise : 17 400 e, Allot NetEnforcer : 24 900 e.
Il faut aussi compter les temps dinstallation et de conguration mais ceux-ci me sont inconnus. De plus, il y a un cot supplmentaire non ngligeable dans ce type de solution : u e e les abonnements. En eet, il est ncessaire de souscrire des contrats pour que les syst`mes e e soient maintenus ` jour. De tels abonnements se chirent aux environs de 1 000 e par an. a A ce cot il faut ajouter la maintenance du matriel (de lordre de 10% par an). u e La seule solution comparable conomiquement avec le cot eectif du dveloppement ne e u e rpond ni ` nos contraintes ni totalement ` nos besoins. e a a Dun point de vue conomique et par rapport aux fonctionnalits souhaites, nous poue e e vons conclure quil est globalement plus avantageux dutiliser un apprenti et les logiciels libres que de mettre en place une solution commerciale.
6.4
Gains
Ce projet apporte des gains de temps, ce qui est dailleurs son objectif premier. Il permet aussi une meilleure interaction avec les correspondants techniques de REAUMUR.
6.4.1
Gain de temps
Pour la validation du th`me de mmoire, le temps perdu sur les tches rptitives (et e e a e e automatisables) a t estim ` 1 heure 15 minutes par jour (en temps ingnieur), ce qui fait ee ea e environ 700 e par mois2 . On obtient le graphique prvisionnel de retour sur investissement e suivant : Le premier objectif du projet est de gagner 75% de temps sur les tches de scurit a e e automatisables. Lors des tests (version alpha et beta) des mesures ont t faites, le rsultat ee e
1 2
Prix au mois de Juin 2005 Charges comprises mais sans compter les frais de structure
46/58
Cot 15"000!
Gain Mois d!Aot 2007
11"250!
7"500!
3"750!
0! 2004 2005 2006 2007 2008
Fig. 6.2 Retour sur investissement
est que 90% des probl`mes dtects sont traits automatiquement. Les probl`mes restants e e e e e (10% des probl`mes) ont un temps de rsolution relativement court (de lordre de 50% du e e temps quil fallait auparavant pour traiter les probl`mes). Le temps gagn est donc de 95%. e e Nous sommes donc tr`s proche du retour sur investissement prvisionnel. e e Le deuxi`me objectif du projet est davoir des interactions instantanes avec les correse e pondants pour 90% des probl`mes de scurit. Celui-ci na pu tre mesur pour linstant e e e e e pour cause de manque de donnes. e
6.4.2
Gain en termes dimage et de scurit e e
Le projet permet aux correspondants techniques davoir une meilleure visibilit sur notre e gestion de la scurit et surtout de pouvoir agir directement sans avoir ` sadresser ` une e e a a personne de lquipe. Ces fonctionnalits permettent damliorer limage de REAUMUR e e e aupr`s des correspondants. e Au-del` du campus et de la rgion, le projet va tre mis ` disposition de la communaut a e e a e des logiciels libres (particuli`rement les utilisateurs universitaires) et va potentiellement e permettre ou faciliter des relations avec dautres universits pour lamlioration du syst`me, e e e voire pour le dveloppement de nouveaux outils communs. e Le projet permet enn et surtout daugmenter globalement la scurit du rseau du fait e e e de lactivit du syst`me 24 heures sur 24 et 7 jours sur 7. Cette amlioration de la scurit e e e e e a deux eets : un sur les consquences lis ` la non dtection de probl`mes de scurit e e a e e e e qui engendre potentiellement des fuites dinformations ou des saturations rseau ; lautre e
47/58
sur limage que nous donnons vis ` vis de Renater qui peut constater que le nombre de a probl`mes chez nous diminue. e
6.5
Bilan humain
Au niveau humain, le projet a une incidence certaine du fait quil peut agir sur toute machine connecte ` REAUMUR (` savoir environ 10 000 machines pour environ 50 000 e a a utilisateurs). De plus, il touche directement les correspondants de REAUMUR (au nombre, pour rappel, de 200) qui doivent ensuite ragir par rapport aux probl`mes dtects. e e e e Etant donn que les principaux utilisateurs du syst`me sont les correspondants, leurs e e besoins ont t relevs et certains volontaires ont pu participer ` la nalisation du syst`me. ee e a e Enn, comme dans tout syst`me interagissant avec des utilisateurs, il y a bien e videmment une documentation et une prsentation formelle de celui-ci. e e
6.5.1
Gestion du changement et de la mise en quarantaine
Les correspondants se voient donc apporter un outil supplmentaire qui induit des chane gements dans leur relation ` REAUMUR. Pour favoriser leur acceptation, il a donc t a ee fait une enqute de mani`re ` orienter le dveloppement du syst`me suivant leurs besoins. e e a e e De plus, les remarques potentielles sont prises en compte et le syst`me est modi suivant e e celles-ci. Les correspondants sont donc, dans la mesure du possible, intgrs dans le cycle e e de dveloppement. e Les utilisateurs naux voient parfois leur machines mises en quarantaine que ce soit de leur faute (abus) ou non (virus). Ils disposent dsormais dinformations prcises sur le e e probl`me quil y a sur leur machine. Ils peuvent surtout eux-mmes le rsoudre et demander e e e une prise en compte immdiate par le syst`me. e e
6.5.2
Documentations, prsentation et formation e
Tout projet de dveloppement doit tre accompagn dune documentation technique, de e e e mani`re ` permettre la maintenance du syst`me par une autre personne que le dveloppeur e a e e initial. Du point de vue des correspondants, une documentation dutilisation va tre faite dici e la mise en production. De plus, une premi`re prsentation de linterface du syst`me a t faite lors de la runion e e e ee e du Groupe des Utilisateurs de REAUMUR (GUR). Cette runion dune dure de 2 heures e e qui comprenait les correspondants des principaux sites (50 personnes) a eu lieu le 23 juin dernier. Mon intervention prsenta durant 20 minutes la ralisation et lutilisation du syst`me. e e e
Chapitre 7
Bilan de comptences e
Sur toute la dure du projet jai dvelopp de nouvelles comptences et utilis des connaise e e e e sances que jai acquises dans le cadre de la formation. Ces comptences sont dordre scientique, technique, organisationnel, conomique et e e humain.
7.1
Domaine scientique et technique
Je vais dtailler ici les direntes connaissances scientiques et techniques que jai pu e e mettre en pratique et dvelopper. e Dans le cadre de lanalyse, la rdaction du cahier des charges et la conception du syst`me e e jai utilis les cours de T.Delamer en syst`me dinformation et analyse fonctionnelle. Jai e e pu mettre en pratique dans le service les mthodes vues et appliques durant ces cours. e e Jai ainsi tabli le cahier des charges fonctionnel et le mod`le conceptuel des donnes du e e e syst`me. Cependant, jai eu quelques dicults ` les construire, malgr les applications e e a e faites en cours. Durant le dveloppement je me suis appuy sur les cours de R.Strandh en gnie logiciel e e e pour crire un code modulaire et lisible. Cela favorisera la mise ` disposition et lvolution e a e du syst`me. e Le cours de scurit rseau de R.Devreese ma donn une vision globale de la scurit e e e e e e que jai pu ensuite aner suivant les besoins du projet. Les TP et le projet du cours de conception de site WEB (PHP) de B.Hamid mont permis davoir la base de linterface, cre avec mon binme Grgory Thiell. Jai pu la ee o e rutiliser et ladapter aux besoins du projet. e Jai approfondi certains sujets, qui mont permis dacqurir des comptences e e complmentaires ` la formation. e a Jai ainsi complt mes connaissances en scurit rseau dans les domaines de la comee e e e promission de machines et de la dtection de comportements suspects. Je dispose dsormais e e dune relative ma trise de la sonde de dtection dintrusion Snort. Jai aussi travaill la e e
Chapitre 7. Bilan de comptences e
49/58
scurisation de linterface du syst`me et du serveur lhbergeant. e e e Dans le domaine du dveloppement, jai appris ` optimiser et tester les performances des e a programmes que jai raliss. Jai confort mes comptences dans lutilisation du langage e e e e PERL et enrichi ma connaissance de PHP.
7.2
Domaine organisationnel
Les cours de gestion de projet de T.Delamer et D.Thiers mont appris ` grer un a e planning, ` cadrer les objectifs et ` ne pas men carter. a a e Dans la pratique jai t amen ` dnir un planning prvisionnel, ` tenter de le respecter ee ea e e a et ` expliquer les carts. a e Pour dnir les besoins prcis des correspondants jai eectu une enqute. Jai ainsi e e e e acquis une exprience dans la rdaction et lexploitation dune enqute. e e e
7.3
Domaine conomique e
Les dirents cours de J.P.Guichane (conomie, relation donneur dordre-fournisseur) e e mont permis de dnir un budget prvisionnel et de calculer le retour sur investissement e e du projet. Cependant, le contexte de la fonction publique est relativement spcique par rapport e aux cas que nous avons pu tudier durant les cours. Dans la mesure du possible jai appliqu e e les notions que nous avons pu apprendre. Jai aussi pu voir le fonctionnement des marchs publics. e
7.4
Domaine humain
Suivant les cours de management de C.Couralet jai appliqu les connaissances acquises e sur la gestion du changement aupr`s des correspondants. Le facteur dacceptation tant tout e e aussi important que la qualit technique du projet, jai donc essay de favoriser celui-ci par e e lenqute et la participation des correspondants dans le cycle de dveloppement. e e Le projet touche un grand nombre de personnes comme jai pu lexpliquer auparavant. Tout utilisateur nal du rseau peut se trouver dans une situation dplaisante : le fait e e davoir sa machine en quarantaine. Il sagit cependant dun choix politique ncessaire au bon e fonctionnement du rseau. Nous avons fait le choix de laisser la possibilit aux utilisateurs e e naux denlever la quarantaine en place sur leur machine. De cette mani`re leurs ractions e e dhumeur contre REAUMUR sont diminues. e Jai pu prsenter oralement devant un public relativement important (50 personnes) la e ralisation et surtout linterface du syst`me. e e
Chapitre 7. Bilan de comptences e
50/58
Au niveau personnel, jai pu enrichir ma capacit ` travailler en quipe dans un contexte ea e de pointe au niveau technologique. Je dispose dsormais dune relle exprience du travail e e e que je navais pas en entrant dans la formation.
Chapitre 8
Perspectives
Maintenant que le syst`me est fonctionnel, il est donc prvu dici la n de lanne de le e e e distribuer en tant que logiciel libre et de lamliorer. e
8.1
Distribution du syst`me dans la communaut e e des logiciels libres
Les direntes institutions universitaires de par le monde ont toujours t troitement e eee lies aux logiciels libres. Ainsi, il est tout naturel pour nous de distribuer le fruit de notre e travail dans cette communaut de mani`re ` ce que des personnes qui ont les mmes besoins e e a e participent ` notre projet au lieu de dvelopper de leur ct un syst`me similaire. a e oe e Il faut aussi noter que la participation de personnes que lon ne conna pas toujours t peut amener des contacts qui nauraient pas eu lieu autrement et ainsi crer des liens avec e les services rseau dautres universits. e e Nous envisageons dutiliser la licence GPL (GNU General Public License). Celle-ci permet la modication et la redistribution du syst`me, d`s lors que lensemble du code source e e du logiciel est fourni. De mani`re gnrale, sauf sil y a de grosses divergences entre les e e e dirents programmeurs, les modications sont rintgres dans le logiciel dorigine. e e e e
8.2
Amlioration de lintelligence du syst`me e e
Dans son tat actuel, faute de temps pour le dveloppement, le syst`me est encore peu e e e intelligent. Il agit suivant des schmas prdnis dans la base de donnes. Cependant, il e e e e est tout ` fait possible daller vers une amlioration de lintelligence du syst`me. On peut a e e imaginer que le syst`me soit capable dapprendre les actions ` mener en fonction des choix e a des utilisateurs sur des probl`mes similaires. Mais il faut, bien videmment, que cet apprene e tissage soit able. Ce type damlioration peut tre risqu et long ` mettre en oeuvre. e e e a On peut esprer que la distribution, sous forme de logiciel libre, permette cette e
Chapitre 8. Perspectives
52/58
amlioration du fait de la participation de plus nombreux dveloppeurs. Nul doute que cette e e amlioration passe par lutilisation doutils de lintelligence articielle (syst`me expert). e e
8.3
Elargissement du prim`tre du syst`me e e e
Actuellement le syst`me fonctionne uniquement ` partir des ux transitants entre REAUe a MUR et Renater, il est tout ` fait possible dlargir le prim`tre du syst`me en ajoutant des a e e e e sondes ` dautres endroits (gestion des connexions sans ls, scurisation de site particuliers) a e suivant les besoins des sites. Les actions menes par le syst`me pourront alors se faire sur e e dautres types dquipements (par exemple les bornes WiFi pour couper lacc`s ` certaines e e a machines).
Conclusion
Rappelons tout dabord lobjectif du projet : disposer dun syst`me automatis de e e scurisation du rseau. Ce syst`me permet de dgager du temps pour REAUMUR et ses e e e e correspondants, damliorer limage du service et daugmenter la scurit sur le rseau. e e e e Mon ma dapprentissage a valu que le projet est actuellement oprationnel ` 90%, tre e e e a nous faisant dj` gagner du temps. Les correspondants pourront tous utiliser le syst`me ea e a ` la rentre universitaire 2005. Nous pouvons donc considrer que lobjectif est atteint en e e grande partie. Durant chaque tape de ce projet, jai pu utiliser les dirents acquis provenant de la e e formation et de mon apprentissage. Mais jai pu surtout enrichir ces acquis et les complter e pour, au nal, dvelopper de nouvelles comptences. e e Je dispose dsormais de comptences concr`tes en scurit informatique et rseau et cest e e e e e e ce que je souhaitais au commencement de mon apprentissage. Mes employeurs morent la possibilit dun contrat de travail ` dure dtermine dans e a e e e le service REAUMUR. Cette opportunit me permettra de dvelopper davantage mes e e comptences dans les domaines de la scurit informatique et rseau. e e e e
Bibliographie
1. Zimmermann (Jacob), Me (Ludovic), Les syst`mes de dtection dintrusion : prine e 3 .- Slestat : Diamond Editions, 2002 .cipes algorithmiques. Magazine MISC n e pages 24-30. 2. Debar (Herv), Morin (Benjamin), Quelques probl`mes lis au dploiement de e e e e syst`mes de dtection dintrusions commerciaux aujourdhui. Magazine MISC n 3 e e .- Slestat : Diamond Editions, 2002 .- pages 31-37. e 3. Bidou (Renaud), Concepts et contournement des IDS. Magazine MISC n 3 .Slestat : Diamond Editions, 2002 .- pages 38-45. e 4. Malterre (Pascal), Les nouveauts de Snort 2. Magazine MISC n 13 .- Slestat : e e Diamond Editions, 2004 .- pages 56-63. 5. Bidou (Renaud), Raynal (Frdric), Canaux cachs (ou furtifs). Magazine MISC e e e n 18 .- Slestat : Diamond Editions, 2005 .- pages 32-38. e
Table des gures

1.1 1.2 2.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 6.1 6.2 Rseau Renater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Diversit des connexions sur REAUMUR e . . . . . . . . . . . . . . . . . . . 7 8 16 28 29
Planning prvisionnel du projet . . . . . . . . . . . . . . . . . . . . . . . . . e Principe de fonctionnement du syst`me . . . . . . . . . . . . . . . . . . . . e Traitements des vnements de scurit provenant des sources . . . . . . . . e e e e
Analyse et seconde agrgation des vnements de scurit provenant des sondes 30 e e e e e Prise de dcision en fonction des param`tres . . . . . . . . . . . . . . . . . . e e Excution des dcisions prises par le syst`me . . . . . . . . . . . . . . . . . e e e Fonctionnement de lagrgation des vnements provenant des sources . . . e e e 31 32 34
Fonctionnement du classement en catgories et de lagrgation suivant celles-ci 35 e e Planning eectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retour sur investissement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 46
C.1 Mod`le conceptuel des donnes . . . . . . . . . . . . . . . . . . . . . . . . . XIV e e
Glossaire
Certicats X.509 : un certicat permet, comme son nom lindique, de certier quun utilisateur ou une machine sont biens ceux quils prtendent. Le standard X.509 est e le plus utilis. e Clef primaire : cest llment identiant de mani`re unique une ligne dans une table ee e dune base de donnes. e CGI : Common Gateway Interface, permet de faire dialoguer un navigateur WEB avec un programme excut ct serveur qui peut tre crit en nimporte quel langage. e e oe e e FDDI : Fiber Data Distribution Interface, protocole de liaison (couche 2 du mod`le OSI) e relativement ancien, utilisant la bre optique comme support. Sa topologie est en double anneau, les informations sur chaque anneau circulent dans des sens opposs. e Lutilisation dun anneau (primaire) avec le deuxi`me (secondaire) eectuant la e correction derreurs permet un dbit de 100 Mbit/s, si le deuxi`me est utilis pour e e e transporter des informations, le dbit atteint 200 Mbit/s. La distance maximale dun e rseau bas sur FDDI est de 200km. e e FIFO : First In First Out, cest une structure de donnes o` le premier lment insr est e u ee ee le premier ` sortir. a Format binaire : il sagit du format de reprsentation lmentaire des donnes en e ee e informatique. Son alphabet est compos de 2 lments : 0 et 1. e ee Full duplex : permet un change simultan dinformations (mission et rception en e e e e mme temps). e HTML : HyperText Markup Language, langage permettant dcrire des pages dites e hypertextes. Celles-ci permettent de relier des documents stocks sur dirents e e serveurs par lintermdiaire de liens. e IP : Internet Protocol, protocole de niveau rseau (couche 3 du mod`le OSI), permettant e e ladressage des machines et lacheminement des donnes. e
Glossaire
57/58
IDS : Intrusion Detection System, outil permettant de dtecter des vnements de scurit. e e e e e Il existe deux types dIDS : les HIDS (H pour Host, cest-`-dire une machine connecte au rseau) qui travaillent a e e au niveau des machines. Ils dtectent des intrusions sur la machine en observant le e comportement des utilisateurs et des logiciels ; les NIDS (N pour Network, rseau en franais) travaillent au niveau du rseau et e c e dtectent les signes dintrusions dans le ux rseau. e e Mod`le OSI : Open Systems Interconnection Reference Model, mod`le cr par lISO e e ee permettant de dnir une base commune ` tout rseau informatique. Ce mod`le e a e e attribue suivant 7 couches des tches spciques ` chacune dans la transmission a e a dinformations sur un rseau. Ces couches vont du lien physique jusqu` lapplication e a qui souhaite transmettre des informations. NAT : Network Address Translation, permet dutiliser une mme adresse IP sur Internet e pour un ensemble de machines. Pare-feu : logiciel ou matriel qui ltre les menaces les plus simples du ux rseau. e e Peer to Peer : protocole dchange de donnes se faisant directement de poste client e e a ` poste client sans avoir besoin de serveurs. Le Peer to Peer est utilis en grande e majorit ` des ns illgales. ea e PCI : Peripheral Component Interconnect, lment interne ` un PC permettant de connecee a ter des cartes dextensions, comme par exemple une carte rseau... e PERL : Practical Extraction and Report Language, langage de programmation permettant dcrire des scripts puissants. e PHP : PHP Hypertext Preprocessor, langage de programmation spciquement cr pour e ee lcriture de pages WEB dynamiques. e Qualit de service (QoS pour Quality of Service en anglais) : il sagit en fait de la qualit e e du transport des informations dans le sens o` les donnes arrivent dans lordre et u e avec un dlai de transmission contrl. Dans le cadre dun change classique de e oe e donnes, il ny a pas ` sen soucier. Par contre, par exemple pour la visioconfrence, e a e la qualit de service est ncessaire pour viter davoir des mauvaises transmissions. e e e Cette qualit de service est spcie contractuellement dans les ores des fournisseurs e e e dacc`s professionnel. e RAD : Rapid Application Development, mthode de dveloppement rapide dapplication, e e fonde sur des cycles courts et une forte interaction avec les utilisateurs e Scan de ports : cest une action qui vise ` dtecter les failles potentielles dans la scurit a e e e des machines connectes ` ce rseau. e a e Socket UNIX : cest un moyen de dialogue entre programmes sur une machine ayant un syst`me dexploitation UNIX. e
Glossaire
58/58
SSO : Single Sign On, procd dauthentication, celle-ci est faite une fois et permet e e daller sans avoir ` ressaisir son mot de passe sur toutes les applications utilisant a cette mthode. e Table de hachage : cest un tableau dans lequel les informations ne sont pas indexes e suivant des numros mais par des clefs. Celles-ci peuvent tre de nimporte quel type e e (mot, chire, etc.). Topologie rseau : dnition de larchitecture dun rseau du point de vue physique. e e e Vers : un vers est un virus se propageant de mani`re autonome par le rseau. Contrairee e ment ` un virus classique qui se diuse par courrier lectronique, il ne ncessite pas a e e daction de la part de lutilisateur. WiFi : Wireless Fidelity, technologie de rseau sans l en plein essor. e
INSTITUT DES TECHNIQUES DINGENIEUR DE LINDUSTRIE DAQUITAINE
MEMOIRE DE FIN DETUDES

PRESENTE EN VUE DOBTENIR
LE DIPLOME DINGENIEUR DES TECHNIQUES DE LINDUSTRIE Dans la Spcialit Rseaux et Tlcommunications e e e ee

PAR
Grgoire Moreau e
DIPLOME DELIVRE PAR LECOLE NATIONALE SUPERIEURE DELECTRONIQUE, INFORMATIQUE & RADIOCOMMUNICATION de BORDEAUX
ANNEXES
` CONCEPTION ET MISE EN PRODUCTION DUN SYSTEME AUTOMATISE DE SECURISATION DU RESEAU REAUMUR
SOUTENU LE 19 SEPTEMBRE 2005
REAUMUR, 351 cours de la libration e 33405 TALENCE
Table des annexes

A Partenaires de REAUMUR B Cahier des charges fonctionnel C Mod`le conceptuel des donnes e e II IV XIII
Annexe A
Partenaires de REAUMUR
Partenaires pour le rseau de campus : e Universit Bordeaux I Sciences et Technologies, e Universit Victor Segalen Bordeaux II (facults des sciences du sport, dnologie et e e des services interuniversitaires rattachs), e Universit Michel de Montaigne Bordeaux III, e Universit Montesquieu Bordeaux IV, e CNRS (Dlgation rgionale), ee e ENSEIRB, ENSCPB, IEP, ENSAM, Maison des Sciences de lHomme dAquitaine. Partenaires pour la plaque urbaine : Rectorat (Carayon Latour, ses annexes et les services acadmiques), e Bordeaux Ecole de Management, Ecole darchitecture et de paysage de Bordeaux, ENITA, INRA Aquitaine (Grande Ferrade), IUFM (Caudran, Mrignac), e e Universit Bordeaux I (Observatoire de Bordeaux, rue Lamartine, IMA) e Universit Bordeaux II (Carreire, Victoire), e Universit Bordeaux III (Renaudel) e Universit Bordeaux IV (IAE, Biblioth`que Universitaire Pluridisciplinaire, IUT GLT) e e Ple Universitaire de Bordeaux, o CROUS (rue du Hamel), DRRT, Ecole Nationale de la Magistrature, INSERM (Haut-Lvque unit 441 et IFR cardiologie). e e e Partenaires pour la plaque rgionale : e INRA Aquitaine (St Pe sur Nivelle), e CEMAGREF, IUFM (Agen, Mont de Marsan, Pau, Prigueux), e
Annexe A. Partenaires de REAUMUR
III/XIV
Universit Bordeaux I (Agen Michel Serres, Arcachon Station Marine, Prigueux e e EPCA), Universit Bordeaux II (Agen, Dax), e Universit Bordeaux III (Agen Centre du Pin), e Universit Bordeaux IV (Agen Centre du Pin, Prigueux IUT et IEJE), e e Universit de Pau et des Pays de lAdour, e Rectorat (Pau), Conseil Rgional dAquitaine (RAP), e Turbomca, e Institut du Dveloppement Local ` Agen. e a
Annexe B
Cahier des charges fonctionnel

Situations de vie
Voyons tout dabord les direntes situations dans lesquelles va se trouver le syst`me : e e installation, exploitation, maintenance, volution. e
Ces direntes situations reprsentent les dirents cas quil faut prvoir dans le cadre e e e e de la vie du syst`me. e
Dnition des fonctions du syst`me e e

Dnissons quelques termes : e FP est une fonction principale, celle-ci dnit la rponse ` un besoin, e e a FC est une fonction contrainte. FP1 Le syst`me permet ` lquipe REAUMUR dautomatiser partiellement la gestion de e a e la scurit. e e FP2 Le syst`me permet aux correspondants de grer les leves de ltrages les concernant. e e e FP3 Le syst`me permet ` lquipe REAUMUR de visualiser tous les vnements et infore a e e e mations collects de lensemble du rseau. e e FP4 Le syst`me permet aux correspondants de visualiser les vnements et informations e e e collects de la partie du rseau les concernant. e e FP5 Le syst`me permet ` lquipe REAUMUR de choisir une ou plusieurs actions pour un e a e vnement non trait automatiquement. e e e FP6 Le syst`me permet aux correspondants de personnaliser le comportement de celui-ci e pour leur domaine.
Annexe B. Cahier des charges fonctionnel
V/XIV
FP7 Le syst`me permet aux utilisateurs naux de lever un ltrage concernant leur machine. e
FC1 Le syst`me doit respecter les r`gles de scurit informatique. e e e e FC2 Le syst`me doit avoir une interface homme/machine intuitive et ergonomique. e FC3 Le syst`me doit disposer dune interface machine/machine (option). e FC4 Le syst`me doit utiliser des standards libres et ouverts. e FC5 Le syst`me doit disposer doutils de mesure sur son utilisation. e FC6 Le syst`me doit pouvoir sinterfacer avec les outils utiliss. e e FC7 Le syst`me doit signaler les vnements. e e e FC8 Le syst`me doit avoir son code source et sa documentation technique en anglais. e FC11 Le syst`me doit tre disponible sous forme de paquet Debian (option). e e FC21 Le syst`me doit pouvoir tre maintenu par dautres personnes que le dveloppeur e e e initial. FC22 Le syst`me doit tre modulaire. e e FC31 Le syst`me doit pouvoir sadapter aux volutions du rseau. e e e FC32 Le syst`me doit pouvoir disposer dune interface en plusieurs langues (option). e
Crit`res de performance par fonction e
FP1 Le syst`me permet ` lquipe de REAUMUR dautomatiser partiellement e a e la gestion de la scurit. e e Equipe de REAUMUR : Lquipe technique est compose de deux techniciens, trois ingnieur rseaux et un e e e e apprenti. Automatiser partiellement : Dtecter les probl`mes de scurit et les signaler ` lquipe et aux correspondants e e e e a e concerns. e Si possible, les traiter (mise en place de ltrage : isolation de la machine par rapport a ` Internet). Si pas de dcision automatique possible, le signaler ` lquipe et prsenter le probl`me e a e e e de mani`re synthtique avec un maximum dlments permettant la prise de dcision. e e ee e Pouvoir ajouter de nouveaux probl`mes avec le comportement que doit avoir le e syst`me par rapport ` ceux-ci. e a Probl`me de scurit : e e e Piratages, utilisations abusives du rseau, propagation de virus. e
VI/XIV
Linformation sur les probl`mes de scurit est strictement conserve en interne e e e e et transmise uniquement aux correspondants qui sont concerns. La dure de e e conservation des informations est de 1 an. Donnes ncessaires ` la gestion de la scurit : e e a e e Informations provenant de direntes sources : netMET (dbits des ux rseaux du e e e campus et informations sur leur source et destination), Snort (dtection dintrusions e et dabus), whitelist (liste des machines ayant un traitement de faveur : serveurs, etc.), journaux des quipements (serveur de courrier, routeurs Cisco). e Donnes ` extraire : e a Filtrage, informations sur le probl`me justiant le ltrage, courrier lectronique au e e correspondant, dure de ltrage. Dans le cas dun probl`me non traitable automatie e quement, demande dassistance aupr`s de lquipe REAUMUR. e e Scurits ` prvoir : e e a e Ne pas ltrer les machines vitales du campus. Vrier si la machine ` ltrer nest pas e a dj` ltre. Vrier, si possible, que le probl`me nest plus prsent avant de lever un ea e e e e ltrage. Mode dacc`s ` la gestion de la scurit : e a e e Navigation ou recherche suivant un ou plusieurs crit`res : heure et date, adresse ip, e sous-rseau, type de probl`me (abus, virus, piratage, etc.). e e Temps de prise de dcision du syst`me : e e Une fois que toutes les informations sont rcoltes, prise de dcision en moins de 5 e e e minutes. Frquence : alatoire. e e Temps dacc`s ` linformation : e a Moins de 5 secondes pour accder ` la page de synth`se et moins dune minute pour e a e obtenir le dtail sur un vnement. e e e
FP2 Le syst`me permet aux correspondants de grer les leves de ltrages les e e e concernant. Correspondants : Sur le campus, ce sont les interlocuteurs de REAUMUR au niveau des sous-rseaux. e Dans certains cas, ils sont administrateurs syst`me ou rseau, sinon ce sont des e e personnels de laboratoire dont le domaine dactivit na pas forcment grand chose ` e e a voir avec linformatique. Leur niveau va donc du dbutant ` lexpert. e a Grer : e Permettre aux correspondants la leve des ltrages de scurit automatiques concere e e nant leur rseau. e Leve de ltrage : e
VII/XIV
Celui-ci tant mis en place automatiquement lors dun comportement suspect e (virus, piratage, abus), une fois la machine nettoye (logiciel dsinstall, virus e e e radiqu, etc.) ou lutilisateur ` lorigine dun abus averti, le correspondant peut le e e a signaler directement au syst`me qui l`ve alors directement le ltrage qui tait en place. e e e Donnes ncessaires : e e Filtrages en cours, raison du ltrage, donnes dauthentication du correspondant, e raisons de la leve et commentaire. e Donnes ` extraire : e a Leve du ltrage. e Scurit ` prvoir : e ea e Pas dabus de leve de ltrage (pas plus de 3 leves de ltrages pour une mme e e e machine dans un intervalle de 30 minutes) sinon interdiction de leve temporaire. e Authentication sre. u Mode dacc`s ` la leve de ltrage : e a e Navigation ou recherche sur un ou plusieurs crit`res : date et heure, adresse ip, raison e de ltrage. Temps dacc`s : e Infrieur ` 5 secondes pour voir tous les ltrages sur le rseau du correspondant, leve e a e e du ltrage en moins de 5 minutes.
FP3 Le syst`me permet ` lquipe REAUMUR de visualiser tous les vnements et e a e e e informations collects de lensemble du rseau. e e e Evnements : Les probl`mes de scurit dtects, les ltrages eectus automatiquement en attente e e e e e e de leve par un correspondant, les traitements ` faire manuellement et les leves de e a e ltrage eectues par les correspondants. e Informations : Les statistiques et les archives dvnements. Conservation : 1 an e e Donnes ncessaires : e e e Evnements, informations. Donnes ` extraire : e a Synth`se, mise en forme. e Scurit ` prvoir : e ea e Authentication sre. u Mode dacc`s aux informations : e
VIII/XIV
Navigation ou recherche suivant un ou plusieurs crit`res : type dvnement, date et e e e heure, adresse ip, rseau. e Temps dacc`s : e Infrieur ` 5 secondes pour la page daccueil (synth`se), infrieur ` 5 minutes pour des e a e e a informations prcises sur un vnement. e e e
FP4 Le syst`me permet aux correspondants de visualiser les vnements et informae e e tions collects de la partie du rseau les concernant. e e Reprend FP3 mais est destin aux correspondants donc les vnements et informations e e e ne sont que celles de leur rseau respectif. e Au niveau de la scurit : pas de visibilit sur le rseau des autres correspondants. e e e e Authentication sre. u
FP5 Le syst`me permet ` lquipe REAUMUR de choisir une ou plusieurs actions e a e pour un probl`me non trait automatiquement. e e Choisir une ou plusieurs actions : Dterminer le comportement du syst`me : bloquer, demander un traitement manuel, e e avertir lquipe REAUMUR, avertir le correspondant. e Donnes ncessaires : e e Probl`me non trait automatiquement, choix de comportement de la part de lutilie e sateur. Donnes ` extraire : e a Traitement automatique choisi. Scurit ` prvoir : e ea e Authentication sre. u Mode dacc`s aux informations : e Navigation. Temps dacc`s : e Infrieur ` 5 secondes. e a
FP6 Le syst`me permet aux correspondants de personnaliser le comportement e de celui-ci pour leur domaine. Personnaliser le comportement : Le correspondant peut choisir quelles actions associer ` un probl`me donn pour leur a e e
IX/XIV
domaine. Donnes ncessaires : e e Comportement pour chaque probl`me, choix de comportement de la part de lutilisae teur. Donnes ` extraire : e a Comportement choisi. Scurit ` prvoir : e ea e Authentication sre. Ne pas pouvoir choisir un traitement plus faible que le u traitement dni par REAUMUR (par exemple, un probl`me qui entra le blocage e e ne dune machine ne peut pas avoir une action moins forte que le blocage). Cependant, il peut y avoir des exceptions mais cela ncessite un contact direct avec lquipe e e REAUMUR qui apportera la modication. Mode dacc`s aux informations : e Navigation. Temps dacc`s : e Infrieur ` 5 secondes. e a
FP7 Le syst`me permet aux utilisateurs naux de lever un ltrage concernant leur e machine. Utilisateurs naux : Les utilisateurs du rseau sur le campus, quel que soit leur organisme de rattachement. e Donnes ncessaires : e e Filtrages en cours, raison du ltrage, raisons de la leve et commentaire. e Donnes ` extraire : e a Leve du ltrage. e Scurit ` prvoir : e ea e Pas dabus de leve de ltrage : 1 leve possible par jour uniquement. Visibilit e e e uniquement des informations concernant la machine de lutilisateur. Temps dacc`s : e Leve du ltrage en moins de 5 minutes. e
X/XIV
Fonctions contraintes en exploitation

FC1 Le syst`me doit respecter les r`gles de scurit informatique. e e e e Condentialit du syst`me : e e Les informations et manipulations oertes par le syst`me ne doivent tre accessibles e e quaux personnes autorises : quipe REAUMUR et correspondants. Pour chaque utie e lisateur, lacc`s est restreint ` son domaine. e a Autorisation dacc`s au syst`me : e e Une authentication sre est mise en place de mani`re ` distinguer sans erreur ,ni u e a usurpation possible, lutilisateur qui utilise le syst`me. Cette authentication sera e faite par certicats, voire SSO1 . Protection du syst`me : e Le syst`me doit pouvoir rsister ` des dnis de services : ne pas scrouler sous une e e a e e charge anormale et rsister aux maximum ` des piratages ventuels aussi bien externes e a e quinternes au rseau campus. e
FC2 Le syst`me doit avoir une interface homme/machine intuitive et ergonomique. e Temps de formation : 1/2 journe. e Linterface doit pouvoir tre utilise par des non informaticiens (rappelons que certains e e correspondants ne sont pas informaticiens) mais cependant rester compl`te. e Linterface doit respecter les crit`res dergonomie. e
FC3 Le syst`me doit disposer dune interface machine/machine (option). e Communications entre machines pour intgration plus facile dans des syst`mes tiers. e e Communication dpendant de lutilisateur qui le demande : acc`s restreint de la mme e e e mani`re que pour linterface homme/machine. e
FC4 Le syst`me doit utiliser des standards libres et ouverts. e Les standards utiliss devront tre ouverts de mani`re ` ne pas dpendre dun produit e e e a e propritaire. e
FC5 Le syst`me doit disposer doutils de mesure sur son utilisation. e

1 SSO : Single Sign On. Lauthentication est faite une fois et permet daller sans avoir ` ressaisir a son mot de passe sur toutes les applications utilisant cette mthode dauthentication. e
XI/XIV
Des journaux dutilisations (logs) seront mis en place et des statistiques faites ` partir a de ceux-ci. La prsentation de ces statistiques sera faite sous forme de graphiques. e
FC6 Le syst`me doit pouvoir sinterfacer avec les outils utiliss. e e Snort : version 2. NetMET : toutes versions . Journaux dquipements Cisco : toutes versions. e Journaux syst`me Linux. e Possibilit dautres outils pas encore connus mais qui seront libres et ouverts : on e retrouve donc FC4.
FC7 Le syst`me doit signaler les vnements. e e e Signal sonore audible par toute lquipe. e Signal visuel au niveau de linterface graphique.
FC8 Le syst`me doit avoir son code source et sa documentation technique en anglais. e De mani`re ` pouvoir tre lu par tout programmeur et pas uniquement en France. e a e
Fonctions contraintes en installation
FC11 Le syst`me doit tre disponible sous forme de paquet Debian (option). e e Debian est la seule distribution GNU/Linux utilise ` REAUMUR. e a Le syst`me mis sous forme de paquet Debian (format de paquet libre et ouvert), e permettra une installation simple et rapide.
Fonctions contraintes en maintenance

FC21 Le syst`me doit pouvoir tre maintenu par dautres personnes que le e e dveloppeur initial. e Rdaction de documentations techniques compl`tes (en franais et en anglais). e e c
XII/XIV
Les autres personnes peuvent tre les ingnieurs de lquipe REAUMUR mais aussi des e e e dveloppeurs o` quils soient dans le monde (dans ce cas, videment, il y a vrication e u e e des contributions externes). Ceci justie le fait davoir une documentation et un code source en anglais.
FC22 Le syst`me doit tre modulaire. e e La conception et le dveloppement du syst`me doivent tre faits de mani`re ` poue e e e a voir ajouter facilement des modules et permettre une maintenance aise des modules e existants.
Fonctions contraintes en volution e
FC31 Le syst`me doit pouvoir sadapter aux volutions du rseau. e e e Les volutions de dbits du rseau doivent pouvoir tre prises en charge avec pour e e e e maximum 1000Mbit/s. La rponse en terme de performance du syst`me doit pouvoir e e tre mesure. e e Les volutions de protocole du rseau : passage de IPV4 ` IPV6. e e a
FC32 Le syst`me doit pouvoir disposer dune interface en plusieurs langues (option). e En vue de proposer le syst`me ` la communaut des logiciels libres, il peut tre e a e e intressant de prvoir une interface qui puisse tre traduite en plusieurs langues. Dans e e e un premier temps ce serait langlais.
Annexe C
Mod`le conceptuel des donnes e e
Annexe C. Mod`le conceptuel des donnes e e
XIV/XIV
A pour action
decisions id_action: character varying(16) ip: inet comment: text rst: timestamp without time zone update: timestamp without time zone delete_me: boolean
exception
white_list ip: inet date: timestamp without time zone comment: text service: character varying(16)
action id_action: character varying (16) lter: boolean mail: boolean ask: boolean hierarchy: integer subnet subnet: inet name: text
Li
ack_user id_type: character varying(16) ip: inet comment: text date: timestamp without time zone username: character varying(16) ackornotack: character varying(8) Acquitt pour
Pour le subnet
type id_type: character varying(16) id_action: character varying (16) subnet: inet
Pour le subnet
type gnrique users username : character varying (128) level : integer typeinfo id_type: character varying(16) msg: text name: text Li exception_patmatch ip: inet sid: bigint port: integer peer: inet
A pour type
logs id_type: character varying(16) ip: inet id_action: character varying(16) action_done: boolean subnet: inet isnew: boolean modied: boolean rst: timestamp without time zone update: timestamp without time zone expire: timestamp without time zone number: integer ack_active: boolean comment: text manual_action: boolean delete_me: boolean Li Li
Exception pour
rules sid: bigint type: text ligne: text msg: text md5: text actif: boolean statut: text update: timestamp without time zone parent: bigint id_type: character varying(20) comment: text
patmatch sid: bigint ip: inet origin: character varying(16) peer: inet position: character(1) port: integer portpeer: integer number: integer isnew: boolean modied: boolean rst: timestamp without time zone update: timestamp without time zone expire: timestamp without time zone delete_me: boolean rst_payload: text last_payload: text
portscan type: character varying(16) ip: inet origin: character varying(16) rst: timestamp without time zone update: timestamp without time zone number: integer ipmiss: integer tcpmiss: integer ports: text ips: text modied: boolean isnew: boolean
mail ip: inet virus: text dest: text orig: text date: timestamp without time zone probe: character varying(16) number: integer rst: timestamp without time zone id: character(16) isnew: boolean modied: boolean
Li
Li
Pour la rgle
typescan name: character varying(16) port: integer threshold: integer id_type: character varying(16)
exception_mail pattern: text id_type: character varying (16)
Fig. C.1 Mod`le conceptuel des donnes e e

2005 Apprentissage Moreau OSAE

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

2005 Apprentissage Moreau OSAE

Diunggah oleh

Hak Cipta:

Format Tersedia

INSTITUT DES TECHNIQUES DINGENIEUR DE LINDUSTRIE DAQUITAINE

MEMOIRE DE FIN DETUDES

LE DIPLOME DINGENIEUR DES TECHNIQUES DE LINDUSTRIE Dans la Spcialit Rseaux et Tlcommunications e e e ee

` CONCEPTION ET MISE EN PRODUCTION DUN SYSTEME AUTOMATISE DE SECURISATION DU RESEAU REAUMUR

SOUTENU LE 19 SEPTEMBRE 2005

REAUMUR, 351 cours de la libration e 33405 TALENCE

ANNEES : 2004 2005

AUTEUR : Grgoire Moreau e

ENTREPRISE PARTENAIRE : REAUMUR, Universit Bordeaux I e

MAITRE DAPPRENTISSAGE : Laurent Facq, Directeur technique

TUTEUR PEDAGOGIQUE : Michel Pallard

NOMBRE DE PAGES : 53 pages sans lappareil de rfrence. ee NOMBRE DE REFERENCES BIBLIOGRAPHIQUES : 5

Table des mati`res e

Table des mati`res e

3.3.5 Dimensionnement du matriel . . . . . . . . . . . . . . . . . . . . . . e Faisabilit du dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . e e

Table des mati`res e

Gestion du changement et de la mise en quarantaine . . . . . . . . . Documentations, prsentation et formation . . . . . . . . . . . . . . e

REAUMUR, un rseau de campus, un service e

Chapitre 1. Prsentation de REAUMUR e

Fig. 1.1 Rseau Renater e

Chapitre 1. Prsentation de REAUMUR e

Petit laboratoire, petit site

Coeur de rseau REAUMUR

Partenaire possdant son propre routeur

Partenaires utilisant le routeur de REAUMUR

Fig. 1.2 Diversit des connexions sur REAUMUR e

Chapitre 1. Prsentation de REAUMUR e

REAUMUR et le rseau rgional et urbain e e

Chapitre 1. Prsentation de REAUMUR e

Chapitre 2. Situation initiale

Chapitre 2. Situation initiale

Objectifs viss par le projet e

Chapitre 2. Situation initiale

Expression des besoins

Chapitre 2. Situation initiale

Perte de temps sur le traitement des probl`mes de e scurit e e

Interaction plus rapide avec les correspondants

Risques associs aux absences de personnel e

Chapitre 2. Situation initiale

Fig. 2.1 Planning prvisionnel du projet e

Recherche des solutions

Tout dabord, examinons le principe de fonctionnement gnral de la solution recherche. e e e

Principe de fonctionnement gnral e e

Chapitre 3. Recherche des solutions

Chapitre 3. Recherche des solutions

Chapitre 3. Recherche des solutions

Choix des outils logiciels et matriels pour le e syst`me e

Quelle sonde de dtection dintrusion ? e

Quel format de stockage utiliser pour Snort ?

Chapitre 3. Recherche des solutions

Chapitre 3. Recherche des solutions

Quelle base de donnes ? e

Quels langages de programmation ?

Chapitre 3. Recherche des solutions

Chapitre 3. Recherche des solutions

Les tapes de la ralisation e e

Prsentation du cahier des charges fonctionnel e pour le dveloppement e

Dnition des fonctions du syst`me e e

Analyse et principe de fonctionnement

Access List sur Routeur

Prise de dcision Actions par catgorie

Table dans la base de donnes

Traitement des scans de ports