Rapport 23-05-2009 CopieFINALE

8/6/2019 Rapport 23-05-2009 CopieFINALE

http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 1/116

Table des matières

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL

1

Table des matières

Table des matières _____________________________________________________________1 Liste des figures _______________________________________________________________4

Liste des tableaux______________________________________________________________6

Liste des Annexes______________________________________________________________7

Liste des abréviations __________________________________________________________8

Introduction générale __________________________________________________________9

Chapitre I : La sécurité des réseaux informatiques _________________________________ 12

1. Introduction : _______________________________________________________________ 13

2. Les réseaux informatiques : ____________________________________________________ 13 2.1. Historique : ______________________________________________________________________ 14 2.2. Administration des réseaux informatiques : _____________________________________________ 15

2.2.1. Définition : __________________________________________________________________ 15 2.2.2. Architecture des réseaux [5] : ____________________________________________________ 15 2.2.3. Topologies [6] : ______________________________________________________________16 2.2.4. Protocoles [7] : _______________________________________________________________17

3. La sécurité des systèmes d¶informations _________________________________________ 18 3.1. Vulnérabilités et risques : ___________________________________________________________ 18

3.1.1. Définitions : _________________________________________________________________ 19 3.1.2. Causes des vulnérabilités : ______________________________________________________ 19 3.1.3. L¶exploitation malicieuse des failles : _____________________________________________ 19 3.1.4. Les risques informatiques : ______________________________________________________ 19

3.2. Les attaques : ____________________________________________________________________ 20 3.2.1. Déni de Service (DoS) [12] : ____________________________________________________ 20 3.2.2. User to Root (U2R) [12] : _______________________________________________________ 21 3.2.3. Probing [12] : ________________________________________________________________21 3.2.4. Remote to Local access (R2L) [12] : ______________________________________________ 22

3.3. Les politiques de sécurité : __________________________________________________________ 23

4. Conclusion :_________________________________________________________________ 23

Chapitre II : Les systèmes de détection d¶intrusions ________________________________24

1. Introduction : _______________________________________________________________ 25

2. Systèmes de Détection d¶Intrusions : ____________________________________________ 25 2.1. Présentation et Définitions : _________________________________________________________ 26

2.1.1. Présentation d¶un Système de Détection d¶Intrusions : ________________________________26

2.1.2. Définitions : _________________________________________________________________ 26 2.2. Types des IDS : __________________________________________________________________ 27 2.2.1. NIDS : _____________________________________________________________________ 28 2.2.2. HIDS : _____________________________________________________________________ 28 2.2.3. IDS hybrides (NIDS+HIDS) : ___________________________________________________ 28

3. IDS versus Firewall : _________________________________________________________ 28 3.1. Comparaison entre Firewall et IDS : __________________________________________________ 29 3.2. Comparaison entre IDS et IPS : ______________________________________________________ 29

3.2.1. Placement des IDS : ___________________________________________________________ 29

4. Méthodes de détection d'intrusions : ____________________________________________ 32



Table des matières


2

4.1. Approche comportementale : ________________________________________________________ 32 4.2. Approche par scénario : ____________________________________________________________ 33 4.3. Tableau comparatif : ______________________________________________________________34

5. SNORT : ___________________________________________________________________ 34 5.1. Présentation : ____________________________________________________________________ 34 5.2. Architecture et Composants : ________________________________________________________ 35 5.3. Modes de détection d¶intrusions : ____________________________________________________ 36 5.4. Implémentation de SNORT : ________________________________________________________ 36

6. Comparatif entre IDS Open source : ____________________________________________ 37 6.1. Prelude [16] : ____________________________________________________________________ 37

6.1.1. Présentation : ________________________________________________________________37 6.1.2. Architecture et Composants : ____________________________________________________ 37

6.2. Bro [14] : _______________________________________________________________________ 38 6.2.1. Présentation : ________________________________________________________________38 6.2.2. Architecture et composants : ___________________________________________________ 38

6.3. Comparatif Snort, Prelude et Bro : ___________________________________________________ 39

7. Conclusion :_________________________________________________________________ 40

Chapitre III : Atelier de génie logiciel & Conception 2TUP _________________________41

1. Introduction : _______________________________________________________________ 42 2. Modélisation et Méthodologie adoptées : _________________________________________ 42

2.1. Langage de modélisation unifié (UML) : _______________________________________________ 42 2.2. Processus Unifié (UP) et sa variante 2TUP : ____________________________________________ 42

3. Choix des langages et des outils de programmation : _______________________________ 45

4. Conception 2TUP de ALS : ____________________________________________________ 46 4.1. Analyse fonctionnelle : ____________________________________________________________ 46

4.1.1. Capture des besoins fonctionnels : ________________________________________________ 46 4.1.2. Analyse : ____________________________________________________________________ 49

4.2. Analyse technique : _______________________________________________________________52 4.2.1. Capture des besoins techniques : _________________________________________________ 52 4.2.2. Conception générique : _________________________________________________________ 55

4.3. Conception : _____________________________________________________________________ 55 4.3.1. Conception préliminaire : _______________________________________________________ 56 4.3.2. Conception détaillée : __________________________________________________________ 57

5. Conclusion :_________________________________________________________________ 76

Chapitre IV : L¶application « A L S » ____________________________________________ 77

1. Introduction : _______________________________________________________________ 78

2. SNORT : ___________________________________________________________________ 78

3. Résumé des difficultés rencontrées : _____________________________________________ 78

4. Test de l¶application : _________________________________________________________ 79 4.1. Présentation de « ALS » : ___________________________________________________________ 79 4.2. Tâches automatisés de SNORT : _____________________________________________________ 79 4.3. Authentification : _________________________________________________________________ 80 4.4. Accueil : ________________________________________________________________________ 81

4.4.1. Démarrage de SNORT : ________________________________________________________ 82 4.4.2. Ecoute du trafic : _____________________________________________________________ 82 4.4.3. Choix de la sonde : ____________________________________________________________ 82 4.4.4. Analyse des alertes : ___________________________________________________________ 83

4.5. Gestion des signatures : ____________________________________________________________ 85 4.6. Paramétrage de SNORT : ___________________________________________________________ 87

4.6.1. Configuration : _______________________________________________________________87 4.6.2. Installation et désinstallation : ___________________________________________________ 88



Table des matières


3

4.7. Paramétrage des utilisateurs : ________________________________________________________ 88 4.8. Gestion de la base de données : ______________________________________________________ 88

4.8.1. Exécution de requêtes SQL : ____________________________________________________ 88 4.8.2. Vidage de la base de données : ___________________________________________________ 89

4.9. Aide : __________________________________________________________________________ 89

5. Conclusion :_________________________________________________________________ 90

CONCLUSION ______________________________________________________________91 PERSPECTIVES _____________________________________________________________92

Annexes ____________________________________________________________________ 93

Bibliographie & Webographie _________________________________________________ 114



Liste des figures


4

Liste des figures

Figure II.1 : IDS installé avant le Firewall _____________________________________________________ 30 Figure II.2 : IDS installé après le Firewall _____________________________________________________ 30 Figure II.3 : IDS installé dans la DMZ ________________________________________________________ 31 Figure II.4 : Sondes SNORT placées de part et d¶autre sur le réseau _________________________________ 31 Figure II.5 : Architecture de Snort ____________________________________________________________ 36 Figure II.6 : Interactions au sein du système ____________________________________________________ 36 Figure III.1 : Processus de développement en Y [25] _____________________________________________ 43 Figure III.2 : Etape actuelle du processus 2TUP [26] _____________________________________________ 46 Figure III.3 : Diagramme des cas d¶utilisations _________________________________________________ 48 Figure III.4 : Acteurs du système _____________________________________________________________ 48 Figure III.5 : Diagramme de séquence géneralisé ________________________________________________ 49 Figure III.6 : Etape actuelle du 2TUP [26] _____________________________________________________ 49 Figure III.7 : Diagramme d¶activités de point de vue fonctionnel ___________________________________ 50 Figure III.8 : Diagramme de classe de point de vue fonctionnel _____________________________________ 51 Figure III.9 : Diagramme d¶état généralisé _____________________________________________________ 52 Figure III.10 : Etape actuelle du 2TUP [26] ____________________________________________________ 52 Figure III.11 : Diagramme des cas d¶utilisations raffiné ___________________________________________ 54 Figure III.12 : Etape actuelle du 2TUP [26] ____________________________________________________ 55 Figure III.13 : Diagramme de déploiement _____________________________________________________ 55 Figure III.14 : Etape actuelle du 2TUP [26] ____________________________________________________ 56 Figure III.15 :Diagramme de classes __________________________________________________________ 56 Figure III.16 : Etape actuelle du 2TUP [26] ____________________________________________________ 58 Figure III.17 : La classe Main _______________________________________________________________58 Figure III.18 : La classe Panel _______________________________________________________________59 Figure III.19 : La classeLance _______________________________________________________________59 Figure III.20 : La classe Start _______________________________________________________________60 Figure III.21 : La classe Auth________________________________________________________________61 Figure III.22 : La classeSqlbd _______________________________________________________________62 Figure III.23 : La classe Abds _______________________________________________________________63 Figure III.24: La classe Videbd ______________________________________________________________64 Figure III.25 : La classe User _______________________________________________________________64 Figure III.26 : La classe Aalerte _____________________________________________________________ 65 Figure III.27 : La classe Calerte _____________________________________________________________ 65 Figure III.28 : La classe Atemp ______________________________________________________________66 Figure III.29 : La classe Aport _______________________________________________________________67 Figure III.30 : La classe Aprdst ______________________________________________________________67 Figure III.31 : La classe Aprsrc ______________________________________________________________67 Figure III.32 : La classe Aprotocol ___________________________________________________________ 68 Figure III.33 : La classe Apudp ______________________________________________________________68 Figure III.34 : La classe Aptcp _______________________________________________________________68 Figure III.35 : La classe Asonde _____________________________________________________________ 69 Figure III.36 : La classe Ajoutr ______________________________________________________________69 Figure III.37 : La classe Assieditr ____________________________________________________________ 70 Figure III.38 : La classe Editr _______________________________________________________________71 Figure III.39 : La classe Modiffr _____________________________________________________________ 71 Figure III.40 : La classe Modifr ______________________________________________________________72 Figure III.41 : La classe Suppr _______________________________________________________________73 Figure III.42 : La classe Suppfr ______________________________________________________________73 Figure III.43 : La classe Paramsnort __________________________________________________________ 74 Figure III.44 : La classe Ageneral ____________________________________________________________ 75 Figure III.45 : La classe Rapport _____________________________________________________________ 76 Figure IV.1 : Programmation Batch___________________________________________________________ 80 Figure IV.2 : Interface d¶authentification de « ALS » _____________________________________________ 80 Figure IV.3 : Identifiant incorrecte ___________________________________________________________ 81



Liste des figures


5

Figure IV.4 : Vue d¶ensemble ________________________________________________________________81 Figure IV.5 : Etat de SNORT ________________________________________________________________82 Figure IV.5 : Ecoute de SNORT ______________________________________________________________82 Figure IV.6 : Analyse des sondes _____________________________________________________________ 82 Figure IV.7 : Consultation des alertes _________________________________________________________ 83 Figure IV.8 : Classification des alertes selon les adresses IP _______________________________________ 83 Figure IV.9 : Classification des alertes selon les ports source et destination ___________________________ 84

Figure IV.10 : Analyse temporelle ____________________________________________________________ 84 Figure IV.11 : Edition d¶une signature ________________________________________________________ 85 Figure IV.12 : Edition d¶une nouvelle signature à l¶aide de l¶assistant ________________________________85 Figure IV.13 : Ajout de fichiers de signatures ___________________________________________________ 86 Figure IV.14 : Suppression de fichiers de signatures ______________________________________________ 86 Figure IV.15 : Activation désactivation de fichiers de signatures ____________________________________ 86 Figure IV.16 : Activation désactivation de signatures d¶un fichier ___________________________________ 87 Figure IV.17 : Configuration de SNORT _______________________________________________________ 87 Figure IV.18 : Gestion des utilisateurs _________________________________________________________ 88 Figure IV.19 : Execution de requêtes SQL ______________________________________________________ 88 Figure IV.20 : Vidage de la base de données ___________________________________________________ 89 Figure IV.21 : A propos de « ALS » ___________________________________________________________ 89



Liste des tableaux


6

Liste des tableaux

Tableau II.1 : Comparaison entre les approches adoptées dans la détection d¶intrusion __________________ 34 Tableau II.2 : Comparaison entre IDS¶s OpenSource _____________________________________________ 39 Tableau III.1 : Utilisation des diagrammes UML en fonction du point de vue du modèle. [25] _____________ 45 Tableau III.2 : Tableau des cas d¶utilisations préliminaires ________________________________________ 47



Liste des Annexes


7

Liste des Annexes

Annexe A : Protocoles réseaux [23] ................................ ................................ ................................ ................. 94 Annexe B : Attaques par VIRUS [Complément au chapitre II] ................................ ................................ .......... 99 Annexe C : Politiques de sécurité adoptées après une mission d¶Audit ................................ ............................ 101 Annexe D : Installation et Configuration de Snort ................................ ................................ .......................... 106 Annexe E : Algorithmes de recherche de motif [21]................................ ................................ ........................ 110



Introduction générale


8

Liste des abréviations

ALS : Analyseur de Logs pour SNORT

IDS : Intrusion Detection SystemIPS : Intrusion Prevention System

NIDS : Network IDS

HIDS : Host IDS

TCP : Transmission Control Protocol

UDP : User Datagram Protocol

IP : Internet Protocol

ARP : Address Resolution Protocol

ICMP : Internet Control Message Protocol

FTP : File Transfer Protocol

ARPANET : Advanced Research Projects Agency NETwork

DoS : Denied of Service

U2R : User to Root

R2L : Remote to Local access

GNU : General Public License

SQL : Structured Query Language

UML : Unified Modelling Language

UP : Unified Process

2TUP : 2 Track Unified Process

JEE : Java Enterprise Edition

CPU : Central Processing Unit

RAM : Random Access Memory

ACID : Analysis Console for Intrusion Database

MEHARI : MEthode Harmonisée d¶Analyse des RIsques

COBIT : Control Objectives for Information and related Technology

EBIOS : Expression des besoins et Identification des Objectifs de Sécurité

MARION : Méthodologie d¶Analyse de Risques Informatiques Orientés par Niveaux

ISO : Organisation internationale de normalisation





9


présent rapport entre dans le cadre de la réalisation d¶un mémoire de projet de find¶études à la faculté des sciences de Bizerte, pour l¶obtention d¶une licence

appliquée en technologies des Réseaux et Télécommunications.

La sécurité des systèmes d¶informations est indispensable quel que soit le domaine

d¶utilisation et l¶importance de l¶information à manipuler, puisqu¶une simple attaque de

débutants, peut s¶avérer parfois destructrice ainsi la méconnaissance des vulnérabilités de tels

systèmes met en péril leur intégrité. C¶est pour cela qu¶on cherche de nouvelles solutions de

sécurité, le plus souvent les moins coûteuses mais qui permettent d¶améliorer les solutions

déjà existantes et renforcent toute entité du réseau en matière de protection.

C¶est dans le cadre du projet: « Développement d¶un système d¶administration et

d¶analyse de Logs pour l¶IDS SNORT », que les problèmes majeurs de l¶insécurité des

systèmes d¶informations vont être mis en cause afin de palier aux attaques des pirates. Ces

derniers qui tentent de pénétrer des entités du réseau en provoquant par la suite des atteintes

de différents niveaux de gravité. Ces niveaux peuvent être une simple écoute du trafic ou bien

une violation de vie privée dans le cas de vols de mots de passe, de numéros de cartes de

crédit ou d¶autres informations secrètes.

En complément pour les politiques de sécurité déjà existantes qui consistent à mettre

en place des pare-feux et des systèmes d¶authentification. Il existe d¶autres outils de

surveillance de trafic qui offrent des fonctionnalités pour auditer le réseau et détecter

d¶éventuelles intrusions tentant à compromettre la confidentialité, l¶intégrité ou bien la

disponibilité d¶une ressource, ces dispositifs sont appelés systèmes de détection d¶intrusions

(en anglais Intrusion Detection Systems IDS).

Opter pour une solution de sécurité fiable est important pour réduire les risques, qui

peuvent avoir un impact sur un réseau informatique lors d¶intrusions (prémédités ou non).

Le





10

Un système de détection d¶intrusions est un ensemble de composants matériels et

logiciels dont la fonction principale est de dépister et analyser toute tentative d¶effraction.

Parmi les IDS les plus populaires, citons à titre d¶exemple Bro, Prelude, SNORT, Tripwire,

etc.

Comme il a été indiqué ci-dessus, le présent projet traite seulement l¶IDS SNORT

Open Source vu sa gratuité, l¶évolution qu¶il a subi depuis sa création ainsi que sa portabilité,

tous ces facteurs l¶ont rendu un pionnier parmi les autres outils standards de détection

d¶intrusions. Il est disponible à l¶adresse www.snort.org.

SNORT est un logiciel libre, capable d¶effectuer une analyse du trafic et une

journalisation des paquets en temps réel sur les réseaux IP. Il supporte l¶analyse de protocoles

et la recherche/mise en correspondance de contenus et peut être employé pour détecter unevariété d¶attaques et d¶explorations : débordement de tampon, scan furtif de ports, attaque

CGI, probe SMB identification du système d¶exploitation, ect.

C¶est en 1998 que Martin Roesch, le fondateur de SourceFire, décide de publier un

logiciel de sa conception, développé pour et autour du milieu Open Source : un programme

qu¶il appellera finalement « SNORT » [1].

Malgré ce qu¶offre SNORT comme fonctionnalités, cet IDS reconnu parmi les

meilleurs pose deux problèmes, coïncidant avec la gestion du programme lui-même. En

premier lieu, c¶est l¶administration de ses modules, pauvre en elle-même (les responsables

de réseaux qui ont des connaissances limitées en programmation ne parviendront pas a la

configuration exacte de l¶outil). En second lieu, SNORT, comme tous les IDS, génère une

base de Logs qui ne cesse de grandir d¶une manière exponentielle rendant l¶interprétation

manuelle des alertes difficile, voir des fois impossible.

Les deux problèmes déjà évoqués ont induit l¶idée, qui est de concevoir un mini

programme qui assure automatiquement une bonne gestion de l¶outil SNORT entre autres son

administration et l¶interprétation des Logs qu¶il génère. C¶est dans ce sens, que ce travail a

pris chemin pour donner naissance à un outil complémentaire à SNORT, baptisé « ALS », qui

interprétera les Logs et facilitera l¶administration de cet IDS à travers une interface homme-

machine conviviale et simple à utiliser.





11

Au cours du stage d¶intégration que j¶ai effectué, certaines tâches m¶ont été confiées et

m¶ont permis d¶apprendre bien plus que la réalisation d¶un programme de gestion pour l¶IDS

SNORT. Ainsi il a été décidé que le rapport soit structuré en quatre chapitres incluant trois

parties ; la première étant théorique et la seconde s¶intéresse à l¶application créée.

Le premier chapitre est consacré à la définition de la notion des réseaux informatiques

ainsi que leur sécurité en insistant sur les risques menaçants.

Le deuxième chapitre traite, en général les IDS ainsi que les techniques et méthodes de

détection d¶intrusions, et SNORT en particulier. Une comparaison entre quelques IDS

présents sur le marché pour clore ce chapitre.

Le troisième chapitre est réservé à la spécification fonctionnelle des besoins ainsi que

l¶analyse et la conception de l¶outil. Ce qui permettra de préciser la méthodologie qui va

conduire au développement de l¶application.

Le quatrième chapitre aura pour but de détailler les fonctionnalités de notre système

baptisé « ALS ». Et pour couronner le tout, une mise en marche démonstrative complétée par

des figures.

Les informations complémentaires au rapport seront saisies au niveau des annexes, à

savoir : les protocoles réseaux, l¶installation et la configuration de SNORT, les politiques de

sécurité, etc.

Ci-joint, le complément DVD de données qui contient les différents composants logiciels

utilisés, une copie numérique de ce rapport, et la version d¶« ALS



Chapitre I : La sécurité des réseaux informatiques


12






13

1. Introduction :

« L¶importance de l¶informatique et de l¶internet en particulier, pour nos entreprises,

nos industries, nos gouvernements, nos moyens de transport, notre société entière, et pour

chacun de nous en tant qu¶individu et citoyen, poursuit une progression fulgurante depuis unedécennie. Ceci paraît évident, mais il serait salutaire de réfléchir un instant à cette dépendance

presque totale qui s¶installe insidieusement dans nos vies. L¶informatique, dans nos esprits et

dans nos habitudes quotidiennes est devenue comme l¶eau potable, l¶air pur, l¶électricité et le

téléphone : elle est là, partout, omniprésente et nous en avons constamment besoin. Mais si

d¶aventure elle n¶est plus là, ou si elle est µµpolluée¶¶, c¶est alors au mieux la consternation et

le dérangement, au pire la panique et la catastrophe pouvant entraîner des pertes financières.

Et pourtant, tous les services informatiques dont nous dépendons sont des denrées

fragiles, constituées d¶innombrables composants matériels, logiciels et humains, devant

fonctionner en parfaite symbiose jour après jour, heure après heure, microseconde par

microseconde. Ces services doivent assurer des niveaux de disponibilité, de fiabilité, de

performance et de garanties d¶intégrité comparables aux exigences rencontrées dans les

domaines tels que ceux de l¶énergie nucléaire et de l¶exploration spatiale, mais doivent les

réaliser à une échelle infiniment plus grande.

Ces divers composants sont sujets à des défaillances matérielles et humaines, mais

aussi à des attaques d¶intention criminelle, malveillante ou de simple divertissement

technique. La fraude financière, l¶espionnage industriel, le terrorisme et la bêtise humaine

sont tous des domaines où l¶informatique est devenue à la fois une cible et une arme via

l¶Internet » [2].

Ce chapitre est divisé en deux grandes parties, la première définira les réseaux

informatiques et invoquera les architectures et les protocoles les plus utilisés. La deuxième

partie aura pour objectifs les vulnérabilités des systèmes, les types d¶attaques ainsi que les

politiques de sécurité adoptées.

2. Les réseaux informatiques :





14

2.1. Historique :

« Internet est issu du réseau ARPANET (de l'Advanced Research Projects Agency), créé en

1968 par le département américain de la Défense, dans un but stratégique, pour relier ses

centres de recherche.

Le réseau initial ne permettait que l'envoi de courrier électronique. C'est en 1972 que

commencèrent les spécifications des protocoles TCP/IP avec l'expérience de l'usage de X25

sur ARPANET. Le but était de concevoir un réseau qui résiste à des attaques militaires telles

que des bombardements. Ainsi, il ne devait pas y avoir de point névralgique dans le réseau,

dont l'arrêt aurait provoqué le blocage complet de celui-ci, et les données devaient pouvoir

automatiquement prendre un chemin différent en cas de coupure de liaison. D'où l'absence de

contrôle centralisé dans l'internet et un cheminement dynamique des données.

Mis dans le domaine public (libre d'utilisation), il fut repris par les universitaires en

1979 (La Duke University à Durham Caroline du Nord), qui y virent le moyen d'échanger des

informations.

Après les militaires et les universitaires (La National Science Foundation finance leurs

mises en réseau), Internet devient aux États-Unis l'affaire des grandes entreprises privées, des

P.M.E. et des particuliers.

En 1983, c'est au tour de l'Europe (par le biais en France du C.N.A.M. Conservatoire

national des arts et métiers) et du reste du monde de se connecter à ce réseau de réseaux.

Selon le principe d'internet, le réseau IP français pour la recherche s'est construit par le

bas, en partant des laboratoires puis des campus et en passant ensuite par la région, avant de

passer au projet national. Actuellement, le développement de l'infrastructure internet en

France se fait surtout du côté des opérateurs privés qui offrent les services de l'internet aux

entreprises et aux particuliers.

L'outil qui rendit populaire l'internet à partir de 1993 est le WWW, le World Wide

Web en un mot le Web. Le mot Web désigne la toile d'araignée et World Wide Web désigne

donc la toile d'araignée couvrant le monde entier.

Le premier navigateur WEB graphique a été mis aux points au CERN (centreeuropéen de recherche nucléaire) en 1993.

Un navigateur Web permet de se connecter à une multitude de sites diffusant des

informations sans connaissances des règles de communication propre au réseau.

L'internet reliait en 1995 plus de 2 millions d'ordinateurs et plus de 30 millions

d'utilisateurs dans 146 pays » [3].





15

2.2. Administration des réseaux informatiques :

L¶administrateur des réseaux informatiques est une activité qui s¶avère indispensable

pour toute entreprise ; les outils utilisés au cours d¶une telle mission ne cesseront de croître du

point de vue qualité afin qu¶ils puissent munir les concernés d¶une multitude de choix et de

méthodes qui les aide à s¶acquérir un niveau maximum de sécurité et de qualité de service.

2.2.1. Définition :

Un Réseau: Il s¶agit d¶« un ensemble de lignes entrecroisées ». Réseau informatique:

« Système d¶ordinateurs géographiquement éloignés les uns des autres, interconnectés par

des télécommunications, généralement permanentes » [4].

L¶utilisation d¶un réseau est primordiale pour l¶entreprise afin de satisfaire ses besoins dont le

partage des ressources (aide diminuer les coûts), la communication entre personnes et la

facilité d¶administration.

2.2.2. Architecture des réseaux [5] :

Il existe généralement deux types d'architecture réseau: l'architecture « égal à égal », et

l'architecture « Client ±Serveur ». Le choix de l'architecture à utiliser dépend de plusieurs

critères:

Type d'activité ;

Nombre d'ordinateurs à connecter ;

Volume du trafic ;

Les droits d'accès ;

Le budget, etc.

L'architecture « égal à égal »

Dans ce type d'architecture, il n'y a pas de serveur dédié. De ce fait, chaque ordinateur

connecté sur le réseau possède tous les droits d'accès. Ainsi, il est libre de partager ses

ressources.

Ce type d'architecture peut être utilisé dans les petites entreprises, vu la simplicité de

son installation. En effet, on peut utiliser le Peer to Peer pour un nombre maximum de dix

ordinateurs situés dans la même zone géographique et relié par un simple système de câblage.

L'inconvénient de cette architecture, c'est que l'administration est difficile et la sécurité

est moins facile à assurer.





16

L'architecture « client ±serveur »

Elle consiste à relier des ordinateurs (clients) à un ordinateur central généralement plus

puissant (serveur). Ce serveur offre aux clients plusieurs services selon leurs droits d'accès,

tels que les accès aux bases de données, la connexion à Internet, etc.

Cette architecture est recommandée pour les moyennes et grandes entreprises

nécessitant un niveau de sécurité très élevé. L'avantage de cette architecture est la possibilité

d'administrer le réseau au niveau du serveur et donc d'assurer la sécurité.

Il existe plusieurs niveaux d'architectures client -serveur:

L'architecture du site central (Mainframe) : Le mainframe représente un ordinateur

central de grande puissance chargé de gérer les sessions utilisateurs des différents terminaux

qui lui étaient reliés. C'est un serveur central qui prend en charge l'intégralité des traitements,

y compris l'affichage qui est simplement déporté sur des terminaux passifs.

Cependant, dans le modèle mainframe, la performance du système tout entier repose sur

les capacités de traitement de l¶ordinateur central, c¶est la raison pour laquelle ce modèle est

parfois qualifié d¶informatique lourde. Par ailleurs, dans un environnement mainframe, les

terminaux du réseau ne peuvent voir que le serveur central.

L'architecture 2 -tiers: appelée aussi architecture à deux niveaux, caractérise les

systèmes clients -serveur où le client envoie des requêtes qui seront traitées par le serveur

directement sans l'aide d'une autre application.

L'architecture 3 -tiers: appelée aussi architecture à trois niveaux, caractérise les

systèmes client -serveur qui nécessitent l'existence d¶une partie intermédiaire appelée

« serveur d'application » ou également « middleware » pour le traitement des requêtes

utilisateurs.

L'architecture N -tiers: ou à plusieurs (N) niveaux, utilise N serveurs destinés chacun

à réaliser des requêtes précises. On peut donc constater que l'architecture 3 -tiers est unearchitecture N -tiers.

2.2.3. Topologies [6] :

« La topologie est l'arrangement physique des ordinateurs constituant un réseau

(configuration spatiale). » On distingue généralement cinq topologies:





17

Topologie en bus: C'est l'organisation la plus simple. Elle consiste à relier tous les

ordinateurs du réseau à un même câble (notamment coaxial). Ce genre de connexion est

fragile puisqu¶une faille dans la connexion affecte tout le réseau.

Topologie en étoile: Les ordinateurs du réseau sont connectés à un concentrateur

(Hub). Contrairement à une topologie en bus, une connexion défaillante ne paralyse pas tout

le réseau.

Topologie en anneau: Les ordinateurs du réseau sont connectés à un répartiteur

nommé MAU (Multi stations Access Unit) qui gère la communication entre eux en accordant

à chacun d'entre eux un "temps de parole".

Topologie en arbre ou hiérarchique: constituée de niveaux, le nud central de haut

niveau est connecté à plusieurs nuds de niveau inférieur, et ainsi de suite jusqu'à atteindre

les feuilles au dernier niveau.

Topologie maillée: correspond à plusieurs liaisons Point à Point, où chaque

ordinateur est relié à tous les autres.

2.2.4. Protocoles [7] :

Un protocole est une méthode standard qui permet la communication entre des

processus (s'exécutant éventuellement sur différentes machines), c'est-à-dire un ensemble de

règles et de procédures à respecter pour émettre et recevoir des données sur un réseau. Il en

existe plusieurs selon ce que l'on attend de la communication. Certains protocoles seront par exemple spécialisés dans l'échange de fichiers (le FTP), d'autres pourront servir à gérer

simplement l'état de la transmission et des erreurs (c'est le cas du protocole ICMP), etc.

[Voir Annexe A]

Le protocole TCP

Le protocole de contrôle de transmission (soit Transmission Control Protocol), est l¶un

des principaux protocoles de la couche transport du modèle TCP/IP. TCP est un protocole

orienté connexion, c'est-à-dire qu¶il permet à deux machines qui communiquent de contrôler l¶état de la transmission et ce à travers l¶ordonnancement des datagrammes en provenance du

protocole IP, le multiplexage des données, etc.

Le protocole IP

Le protocole IP (Internet Protocol) fait partie de la couche Internet du modèle TCP/IP.

Il permet l¶élaboration et le transport des datagrammes IP, sans pour autant en assurer la





18

livraison. En réalité, le protocole IP traite les datagrammes IP indépendamment les uns des

autres en définissant leur représentation, leur routage et leur expédition.

Le protocole UDP

Le protocole UDP (User Datagram Protocol) est un protocole non orienté connexion

de la couche transport du modèle TCP/IP. Vu que le protocole UDP ne fait de contrôle

d¶erreur, l¶entête du segment est donc très simple.

Le protocole ICMP

Le protocole ICMP (Internet Control Message Protocol) est un protocole qui permet de

gérer les informations relatives aux erreurs aux machines connectées. Etant donné le peu de

contrôles que le protocole IP réalise, il permet non pas de corriger ces erreurs mais de faire

part de ces erreurs aux protocoles des couches voisines.

Le protocole ARP

Le protocole ARP (Address Resolution Protocol) a un rôle phare parmi les protocoles

de la couche Internet de la suite TCP/IP, car il permet de connaître l'adresse physique d'une

carte réseau correspondant à une adresse IP.

3. La sécurité des systèmes d¶informations

Alors que les systèmes d¶informations grandissent et sont de plus en plus ouverts sur

Internet, cette ouverture constitue une source imprévisible d¶attaques, la mise en place de

politiques de sécurité est non seulement importante dans ce cas mais primordiale afin de bien

garder la confidentialité1, l¶authenticité2, l¶intégrité3, le contrôle d¶accès4 et la non-répudiation

de l¶information5.

3.1. Vulnérabilités et risques :

Lorsque des pirates veulent s¶introduire dans les systèmes, ils cherchent généralement les

failles de sécurité et les bogues connus pour les exploiter. Pour conduire une véritable attaque,c'est-à-dire pénétrer dans un système cible en vue de le contrôler, l¶attaquant doit se faire une

idée la plus précise et complète possible de la sécurité de l¶entreprise. A mesure qu¶il évalue

1 2 3 4 5





19

le réseau, il exploite ses vulnérabilités pour déterminer exactement comment contrôler ses

ressources.

3.1.1. Définitions :

Vulnérabilité: « Assimilée à une faille de sécurité. Caractéristique permettant de l¶utiliser

pour mettre en péril la sécurité d¶un programme ou d¶un système » [8]

Risques informatiques: « On qualifie généralement les risques informatiques, toutes les

causes externes qui peuvent compromettre l¶efficacité d¶un système, à l¶exclusion de toute

anomalie fonctionnelle (panne machine, bug, erreur de programmation...). » [9]

3.1.2. Causes des vulnérabilités :

« Un système se révèle relativement facile à pénétrer ou à casser s¶il n¶est pas sécurisé

ou mis à jour avec les « patchs » correctifs. Mettre à jour et protéger les systèmes devient de

plus en plus difficile compte tenu du nombre varié des systèmes d¶exploitation (SE) et des

ressources budgétaires et personnelles restreintes dans la plus part des entreprises » [2].

Les administrateurs rencontrent couramment des problèmes de mises à jour des systèmes

surtout que celles-ci nécessitent un suivi journalier puisque mensuellement un grand nombre

de vulnérabilités est détecté dans le monde. Ainsi tout pronostic négligé par un responsable du

réseau peut s¶avérer compromettant pour la sécurité.

3.1.3. L¶exploitation malicieuse des failles :

Les failles de sécurité constituent de l¶or pour certains fous épris de piratage, qu¶ils

soient débutants ou chevronnés, l¶exploitation des vulnérabilités d¶un système de sécurité

pour quelconques fins et à l¶insu du propriétaire met en péril les informations protégées. Pour

cela, les malveillants de l¶informatique, se munissent d¶outils et de bonnes connaissances en

réseaux leur permettant la prise de contrôle des machines, l¶injection de virus ou même la

propagation dans tout un réseau.

3.1.4. Les risques informatiques :

Parmi les risques les plus connus dans le domaine de la sécurité informatiques, nous

citons :

« Risques humains





20

Les risques humains sont les plus importants, même s'ils sont le plus souvent ignorés ou

minimisés. Ils concernent les utilisateurs mais également les informaticiens eux-mêmes.

Parmi les risques les plus répandus on cite: la maladresse, l'inconscience et l'ignorance, la

malveillance, l'espionnage, etc.

Risques techniques

Les risques techniques sont tout simplement ceux liés aux défauts et pannes inévitables

que connaissent tous les systèmes matériels et logiciels. Ces incidents sont évidemment plus

ou moins fréquents selon le soin apporté lors de la fabrication et des tests effectués avant que

les ordinateurs et les programmes ne soient mis en service. Cependant les pannes ont parfois

des causes indirectes, voire très indirectes, donc difficiles à prévoir. Citons à titre d¶exemples

les incidents liés au matériel ou au logiciel, voire même à l'environnement. » [8]

3.2. Les attaques :

L¶anatomie d¶une attaque réside dans sa manière d¶évoluer, elle est la même qu¶elle

soit réalisée par un individu ou de manière automatique par un logiciel malveillant. Basés sur

le concept des cinq P : Prospecter, Pénétrer, Perdurer, Propager et Paralyser, les attaques

présentent un risque majeur pour les systèmes d¶information.

Tout système informatique peut présenter une menace pour différentes types

d¶attaques [Voir Annexe B] qu¶on peut classer en quatre grandes catégories comme suit :

3.2.1. Déni de Service (DoS) [12] :

L¶attaque Déni de Service (Denial of Service : DoS) a pour principe d'envoyer des

paquets ou des données de taille ou de constitution inhabituelle, afin de provoquer une

saturation ou un état instable des équipements victimes et de les empêcher ainsi de se servir

des ressources disponibles en temps normal. Ce type d¶attaque est très simple à mettre en

place, cependant il s¶avère un dispositif énormément destructeur. Parmi les exemples

d¶attaque de type DoS, on peut citer :

Smurf

Cette attaque consiste à usurper une adresse IP source et à envoyer un ICMP Echo

Request sur une adresse de diffusion d'un réseau. Toutes les machines de ce réseau, se pensant

concernées, répondront à cet appel. Ceci a deux effets. Le premier est de saturer la machine

dont on aura usurpé l'adresse IP, le deuxième est de ralentir, voire saturer le trafic sur le

réseau.





21

Land

Cette attaque s'appuie sur une mauvaise gestion des droits d'accès au réseau. La

machine attaquée s'autorise à recevoir des paquets externes avec son adresse IP. C'est ce qu'on

appelle du Spoofing (technique d'usurpation d'identité ou d'adresse). Le système ciblé, s'il est

faillible, risque dans ce cas de se voir bloqué (utilisation 100% CPU, crash mémoire, etc.) ou

perdre sa couche réseau. Pour se faire, on commence par scanner tous les ports de la machine

que l'on souhaite attaquer. Par la suite, On envoie une requête avec l'adresse IP source

identique à l'adresse IP destination, sur chaque port ouvert, avec le drapeau SYN activé.

3.2.2. User to Root (U2R) [12] :

Dans ce type d¶attaque, le pirate essaie d¶accéder au système à partir d¶un poste. Pour se

faire, il exploite la vulnérabilité du système afin d¶élever ses privilèges et obtenir les droits

d¶accès administrateur (root). Parmi les attaques qui reposent sur ce principe, nous citons :

Le Rootkit

C¶est un programme ou ensemble de programmes qui, après avoir obtenu les droits

d'administrateur (root) sur une machine, met en place une ou plusieurs portes dérobées. Celles

-ci permettent au pirate de s¶introduire à nouveau au cur de la machine en tant que root et

d'effacer les traces laissées par l'opération dans les journaux système.

Buffer overflow ( Le dépassement de tampon)

Il s¶agit d¶une attaque très efficace et assez compliquée à réaliser. Le fonctionnement

général d'un buffer overflow est de faire anéantir un programme en écrivant dans un tampon

plus de données qu'il ne peut en contenir, dans le but d'écraser des parties du code de

l'application et d'injecter des instructions ouvrant un interpréteur de commande (en anglais

shell ) et permettant au pirate de prendre la main sur le système.

3.2.3. Probing [12] :

La vérification (Probing) est une technique qui consiste à vérifier ou à tester, à l'aide

d'un logiciel approprié, l'état d'un système informatique ou d'un réseau, afin d'en évaluer leniveau de sécurité et d'en déterminer les vulnérabilités. Cependant, cette technique est utilisée

par les pirates informatiques pour repérer les failles de sécurité d'un système ou d'un réseau,

pouvant mener une attaque de plus grande envergure plus tard.

Le Portscan TCP





22

Le balayage de port en informatique, appelé Portscan en anglais, est une technique qui

permet de chercher les ports ouverts chez un hôte du réseau. Elle est souvent utilisée par les

pirates informatiques pour tenter de compromettre la sécurité d¶un hôte. Le balayage de ports

est l¶une des activités considérées comme suspectes par un Système de détection d'intrusion.

Pour tromper la vigilance de ces systèmes, les balayages peuvent se faire dans un ordrealéatoire, avec une vitesse excessivement lente, ou à partir de plusieurs adresses IP.

Un balayage de ports le plus réputé vise typiquement le protocole TCP car c'est celui

qui est utilisé par la majorité des applications. L'objectif est de savoir si un logiciel est en

écoute sur un numéro de port donné ou non. Si un logiciel écoute, on dit que le port est

ouvert , sinon on dit qu'il est fermé. Le balayage d'un port se passe en deux étapes :

- Envoi d'un paquet sur le port testé ;

- Analyse de la réponse.

Il existe de nombreuses variantes pour le paquet émis. Il y a le paquet valide selon la

norme TCP, le paquet « TCP SYN », et les paquets invalides. L'intérêt des paquets non

standards est de tromper les systèmes de détection d'intrusion pour passer inaperçu.

Autre type de Portscan

Pour le protocole UDP, on envoie un paquet UDP vide (de longueur nulle). Si le port est

fermé, un message ICMP de type 3 (destinataire inaccessible) et code 3 est envoyé. Il est

également possible de lister les protocoles IP supportés par un hôte. On appelle cettetechnique IP protocol scan.

3.2.4. Remote to Local access (R 2L) [12] :

Dans ce type d¶attaque, le pirate exploite les failles du système afin de gagner un accès

local dans la machine distante. Parmi les nombreux exemples d¶attaques de type R2L, nous

citons :

SQL Injection

Il s¶agit d¶une faille de sécurité d¶une application Web (généralement au niveau des

formulaires), qui consiste à modifier et insérer des données (code malveillant) dans les

chaînes transmises ultérieurement à une instance de SQL Server en vue de les exécuter. Ainsi,

l¶attaquant peut accéder à un compte local sans pour autant avoir le droit.

Cracking des mots de passe





23

Cette attaque prouve qu¶aucun mot de passe n¶est inviolable. En effet, il existe trois

méthodes pour cracker un mot de passe, soit avec le dictionnaire (un simple fichier texte

contenant un mot par ligne, les uns à la suite des autres), soit par brut force (à essayer toutes

les combinaisons possibles suivant un certain nombre de caractères), soit combiner les deux

précédentes méthodes.

3.3. Les politiques de sécurité :

Toutes les politiques de sécurité sont basées sur le fait de mettre en évidence les

objectifs attendus ainsi que les moyens de l¶entreprise, ensuite analyser le tout afin de générer

les procédures à mettre en pratique pour atteindre le niveau de sécurité conforme aux besoins

auparavant étudiés.

Parmi les nombreuses méthodes permettant de mettre au point une politique de sécurité,

nous pouvons citer à titre d¶exemple la méthode MEHARI [10], MARION [10], EBIOS [10],

COBIT [11], etc. [Voir Annexe C]

4. Conclusion :

Dans ce chapitre il y a eu définition des réseaux informatiques (architectures, topologies

et protocoles) suivie d¶une concrétisation des types de risques et d¶attaques qui pèsent sur ces

réseaux, ainsi que les politiques de sécurité permettant de palier aux différents problèmes de

l¶insécurité.

Une unique méthode pour sécuriser un réseau n¶existe pas. Ainsi le déploiement de

plusieurs entités (pare-feux, mise-à-jours quotidiennes, systèmes de détection d¶intrusion ),

visant à renforcer la sécurité, est primordial.

Le chapitre suivant portera l¶attention aux systèmes de détection d¶intrusions.



Chapitre II : Les systèmes de détection d·intrusions


24

Chapitre II : Les systèmes de détection d¶intrusions





25

1. Introduction :

Comme l¶a invoqué le premier chapitre, tout système d¶information doit être sécurisé.

C'est-à-dire, tout trafic sur le système, doit être contrôlé. Cette fonctionnalité est offerte par

les systèmes de détection d¶intrusions (IDS).

« Comparativement à Internet, le concept de détection d¶intrusion est relativement

récent. Les recherches ont débuté dans les années 80 avec les travaux d¶Anderson et Denning.

A cette époque, le gouvernement américain commençait à utiliser des fonctions IDS

élémentaires sur le réseau Arpanet. Quelques années plus tard, des membres du Haystack

Project ont fondé la société commerciale Haystack Labs dans le but de développer des IDS de

niveau hôte (HIDS). Les IDS de niveau réseau (NIDS) ont suivi dans les années 90, avec

Todd Heberlein à la tête du mouvement. Entre-temps, d¶autres sociétés se sont lancées dans la

création d¶IDS, telles que SAIC. L¶US Air Force a même développé le système ASIM

(Automated Security Incident Measurement), et l¶équipe responsable du projet a par la suite

formé le Wheel Group en 1994. Puis, en 1998, Cisco rachète le Wheel Group, cette

acquisition formant la base de ses produits IDS et services de sécurité » [1].

Les systèmes de détection d¶intrusions sont devenus un composant essentiel et critique

dans une architecture réseau sécurisée.

Dans ce qui suit, les systèmes de détection d¶intrusions vont être définis sur le plan

général, ainsi que l¶IDS SNORT en particulier. Une comparaison entre IDS fera en sorte de

choisir le bon de point de vue qualité et besoins.

2. Systèmes de Détection d¶Intrusions :

Toute violation de la politique de sécurité d'un système informatique est considérée

comme un objectif potentiel d'intrusion. D¶où la nécessité de mettre en place un système de

détection d¶intrusions (IDS) qui surveillera continuellement le trafic acheminé sur le système

ou sur le réseau concerné.





26

2.1. Présentation et Définitions :

2.1.1. Présentation d¶un Système de Détection d¶Intrusions :

On appelle IDS ( Intrusion Detection System) un mécanisme écoutant le trafic réseau de

manière furtive afin de repérer des activités anormales ou suspectes et permettant ainsi d'avoir

une action de prévention sur les risques d'intrusions.

Les IDS sont répartis en deux catégories de base : les systèmes de détection d¶intrusions

basés sur les signatures et les systèmes de détection d¶anomalies.

Chaque intrus a une signature, tout comme les virus. Lors de l¶analyse d¶un paquet de

données, le système de détection d¶intrusions se réfère à une base de signatures et de règles

afin de détecter, enregistrer dans un fichier log6 et générer des alertes.

Les systèmes basés sur la détection d¶anomalies, dépendent généralement des anomalies

de paquet présentes dans les entêtes des protocoles. Dans certains cas, cette méthode est plus

efficace que les systèmes de détection d¶intrusions basés sur les signatures.

2.1.2. Définitions :

Des notions qui seront utilisées dans le reste du rapport devront être saisies, voilà leurs

définitions :

« Signatures

Il s¶agit du modèle qu¶on cherche à l¶intérieur d¶un paquet de données. Une signature

est utilisée pour détecter un ou plusieurs types d¶attaques. Par exemple, la présence de

« cmd32.exe » dans un paquet envoyé vers un serveur web, peut indiquer l¶existence d¶une

intrusion de type « web application attack ».

La performance d¶un IDS dépend du nombre, de l¶efficacité et de précision des

signatures prédéfinies. En effet, les IDS ont recours à la base des signatures pour pouvoir

reconnaître les intrusions. C¶est pour cette raison qu¶il est recommandé de les mettre à jour

pour ajouter de nouvelles signatures et détecter ainsi les nouvelles attaques découvertes.

Alertes

Lorsqu¶un IDS détecte une intrusion, il doit le signaler à l¶administrateur, et ce à travers

les alertes. Ces alertes peuvent être enregistrées dans des fichiers logs ou dans une base de

données où il est possible de les consulter plus tard par un expert de sécurité.

6 Log : ce terme sera défini dans le paragraphe qui suit.





27

En prenant comme exemple l¶IDS SNORT, nous constatons qu¶il génère les alertes sous

plusieurs formes contrôlées par l¶instruction « output ». Voici un exemple :

³Output database: log, mysql, user=root dbname=snort host=localhost´

Parfois, les systèmes de détection d¶intrusions commettent des erreurs que nous pouvons

répartir en deux catégories :

� Les faux positifs : cette erreur signifie que l¶IDS détecte une intrusion qui n¶a pas

été perpétrée réellement.

� Les faux négatifs : à l¶inverse de « faux positives », l¶IDS ne signale aucune

intrusion alors qu¶il y en a au moins une.

Logs

Les logs sont des lignes d¶un fichier dans lesquelles un IDS enregistre les donnéestransitant sur un système pour les analyser et faire des statistiques. Le fichier dans lequel ces

informations sont sauvegardées est appelé fichier log qui peut être en format texte ou binaire.

Sondes

La machine sur laquelle le système de détection d¶intrusions est lancé, est appelée

« sonde » puisqu¶elle est utilisée pour écouter le trafic du réseau.

Pot de miel ( H oneyPot)

Les pots de miels sont des systèmes utilisés pour leurrer les pirates en exposant

volontairement des vulnérabilités. Lorsqu¶un attaquant trouve un pot de miel, il va passer un

certain temps à « pirater », ce qui permettra d¶enregistrer ses activités, de les étudier et les

anticiper afin de connaître ses actions et techniques. Les informations recueillies sont utiles

pour renforcer la sécurité de notre système. La tâche principale d'un pot de miel consiste à

analyser le trafic, c'est-à-dire à informer du démarrage de certains processus, de la

modification de fichiers, etc. permettant ainsi de créer un profil élaboré des attaquants

potentiels sans qu¶ils ne s'en doutent. »

2.2. Types des IDS :

Il existe plusieurs types d¶IDS et le point commun entre tous c¶est la détection

d¶intrusion. Le choix d¶un IDS coïncide avec son mode d¶utilisation ainsi que

l¶environnement qu¶il va le contenir.





28

2.2.1. NIDS :

Un NIDS ou Network IDS, est un système de détection d¶intrusions qui capture les

données circulant dans un réseau, les compare avec sa base de signatures. Si un paquet

correspond à la signature d¶un intrus, une alerte est générée et le paquet est enregistré dans un

fichier log ou dans une base de données. A titre d¶exemple nous citons : « SNORT » [13],« BRO » [14], etc.

2.2.2. HIDS :

Un HIDS ou Host IDS, est un système de détection d¶intrusions qui travaille sur une

seule machine (hôte). Il récupère les informations du système d¶exploitation et des journaux

afin de détecter d¶éventuelles intrusions. Prenons comme exemple de HIDS : « AIDE » [15],

etc.

2.2.3. IDS hybrides (NIDS+HIDS) :

Les IDS hybrides rassemblent les caractéristiques de NIDS et HIDS. Généralement

utilisés dans un environnement décentralisé, ils permettent, en un seul outil, de surveiller les

réseaux et les terminaux. Les sondes sont placées en des points stratégiques, et agissent

comme NIDS et/ou HIDS suivant leurs emplacements. Toutes ces sondes remontent alors les

alertes à une machine qui va centraliser le tout, et agréger/lier les informations d'origines

multiples. Tel est l¶exemple de « Prelude » [16].

3. IDS versus Firewall :

Chaque ordinateur connecté à Internet (ou à n'importe quel réseau informatique) est

susceptible d'être victime d'une attaque d'un pirate informatique.

Ainsi, il est indispensable, autant pour les réseaux d'entreprises que pour les internautes,

de se protéger des intrusions réseaux en installant un dispositif de protection, à savoir un pare-

feu (Firewall), et/ou un système de détection d¶intrusions (IDS).

Il est donc intéressant de connaître la différence entre ces deux dispositifs et de savoir sil¶utilisation de l¶un des deux suffit pour assurer la sécurité du système.





29

3.1. Comparaison entre Firewall et IDS :

Un pare-feu (appelé aussi coupe-feu, garde-barrière ou Firewall en anglais), est une

passerelle filtrante qui se situe entre le réseau interne et le réseau externe permettant de filtrer

les flux entrants et sortants en fonction de la politique de sécurité choisie.

Le pare-feu empêchera donc certains protocoles non autorisés et peut également

détecter certaines attaques, comme le Spoofing par exemple. En revanche, le pare-feu, va

accepter le trafic « autorisé » qui, eux-mêmes peuvent être porteurs d'attaques, voire même de

virus.

Ainsi, suivant le degré de risque du système d'information, il est très utile de détecter

en temps réel les attaques et de remonter une alerte à l¶administrateur. D¶où l¶importance

d¶implémenter un IDS qui fonctionnera au niveau du réseau interne.

En d¶autres termes, les systèmes de détection d'intrusions sont complémentaires aux

pare-feux. Ils permettent ainsi la détection d¶intrusions, que celles-ci soient menées de

l¶extérieur ou bien de l¶intérieur (ce qui n¶est pas un cas rare)

3.2. Comparaison entre IDS et IPS :

A l¶instar du traditionnel IDS, une nouvelle génération de systèmes voit le jour, sous

l¶appellation de « Systèmes de Prévention d¶Intrusions » et comme le nom l¶indique, ses

systèmes permettent non seulement la détection mais aussi la prévention, qui consiste à

bloquer les trafics qui semblent corrompus ou mal intentionnés.

Malheureusement, certains cas parlent d¶eux même, on ne peut pas s¶assurer d¶une

parfaite fiabilité lors de l¶identification des attaques, puisque des faux positifs, lorsqu¶on les

bloque, peuvent paraitre dangereux pour un IPS, générant ainsi un dysfonctionnement du

système. C¶est entre autres, pour cela qu¶on a opté pour un IDS

3.2.1. Placement des IDS :

L¶emplacement des systèmes de détection d¶intrusions dépend de la topologie du

réseau, et surtout du type d¶intrusion que nous voulons détecter : interne, externe, ou les deux

en même temps.

Dans le cas où nous voulons détecter les intrusions externes seulement, nous devons

placer le NIDS avant (en amont) le pare-feu ou le routeur filtrant comme le monter la ( Figure

II.1). Dans cette position, la sonde occupe une place de premier choix dans la détection des

attaques de sources extérieures visant l¶entreprise. Cependant, il faut savoir qu¶un trafic très





30

important peut engendrer des pertes de fiabilité et que dans cette position, le NIDS est exposé

à des éventuelles attaques puisqu¶il n¶est plus protégé par le pare-feu.

Figure II.1 : IDS installé avant le Firewall

Si par contre, nous voulons détecter les intrusions à l¶intérieur du réseau de l¶entreprise,

nous devons placer le NIDS dans le réseau interne, soit sur chaque segment du réseau ou juste

sur les zones sensibles du réseau comme le monter la ( Figure II.2).

Cet emplacement nous permet d¶observer les tentatives d¶intrusion parvenues à

l¶intérieur du réseau d¶entreprise ainsi que les tentatives d¶attaques à partir de l'intérieur.

Figure II.2 : IDS installé après le Firewall





31

On peut aussi placer l¶IDS dans une zone connue comme étant la plus sensible du réseau,

cette zone peut contenir : des serveurs (web, fichiers, ase de données), des mainframes, ).

On appelle cette zone DMZ, ou bien Zone démilitarisée.

Figure II.3 : IDS installé dans la DMZ

Comme on peut aussi admettre le cas d¶une mise en place de plusieurs sondes SNORT,

chacune sur un segment sachant que, plus le nombre de NIDS est grand, leur gestion devient

difficile et coûteuse.

Figure II.4 : Sondes SNORT placées de part et d¶autre sur le réseau





32

4. Méthodes de détection d'intrusions :

En général, il existe deux grandes familles de détection d'intrusions, à savoir

l'approche comportementale et l'approche par scénario.

4.1. Approche comportementale :

« Cette approche, proposée par Anderson dès 1980 et reprise par Denning et Whiterhurst en

1987 est basée sur l¶hypothèse qu¶une intrusion implique un usage anormal du système et

donc un comportement inhabituel d¶un utilisateur. On parle alors de profil utilisateur ou

comportement d'une application. » [17]

Dans cette approche, il s¶agit de décrire le profil utilisateur et modéliser son

comportement afin de détecter par la suite toute déviation de son comportement habituel ainsi

appris. Ainsi, cette approche cherche à répondre à la question suivante : « Le comportementactuel de l¶utilisateur est-il cohérent avec son comportement passé ? »

Parmi les approches comportementales les plus utilisées [18], nous citons :

L¶approche statistique : consiste à quantifier de manière fine toute une série de

paramètres liés à l¶utilisateur tels que : taux d¶occupation mémoire, utilisation du

processeur, valeur de la charge réseau, nombre d¶accès a l¶Intranet par jour, sites web

les plus visités, vitesse moyenne de frappe au clavier, etc. Toutes fois, la complexité de

cette approche ainsi que son faible niveau de fiabilité, font qu¶elle n¶est présente que

dans le domaine de la recherche.

L¶approche probabiliste : définit le fonctionnement d¶une application à partir

d¶événements observés. Il y aura un établissement des règles et un apprentissage des

probabilités liés à chaque séquence d¶événements. L¶approche par réseaux de neurones : permet de surveiller directement le

comportement d¶un utilisateur (chacun peut être identifié par son comportement tel que

ses habitudes de travail, ses activités, ses outils de travail, etc.). Donc pour construire le

profil de chaque utilisateur, on utilise les réseaux de neurones dont chacun reconnaît

une suite d¶opérations effectuée par cet utilisateur. Ceci va nous permettre de prédire

l¶opération suivante, en cas d¶échec une alerte est levée. L¶immunologie : analogique à l¶immunologie biologique, consiste à observer les

services (et non pas les utilisateurs) pendant un temps suffisamment représentatif de

manière à établir un modèle de comportement normal. Le comportement observé sera

donc comparé avec le modèle de comportement normal.





33

Les graphes : c¶est une approche à base de graphes qui permettent de mettre en

évidence des propriétés et des relations entre ces propriétés. Son intérêt, c¶est qu¶elle

permet de traiter plus facilement des événements rares.

4.2. Approche par scénario :Cette approche, « proposée pour pallier les inconvénients de l¶approche

comportementale, cherche à retrouver des attaques connues dans le fichier d'audit. Elle

nécessite donc une connaissance préalable des attaques bien définies. Cette approche cherche

alors à répondre à la question suivante : « Le comportement actuel de l'utilisateur contient-il

une attaque connue?". Dans ce cas, il est nécessaire de construire une base de données

d'attaques ou de scénarios d'attaques. » [19]

D¶une manière générale, la recherche des attaques dans les données se fait par

application de techniques d¶analyse de signature (appelée recherche de motif).

La recherche de motif [20] ( Pattern Matching en anglais), permet de localiser une

occurrence d¶un mot (motif) dans un texte. Il existe deux catégories de recherche de motif,

une avec motifs fixes et texte variant (c¶est le cas des NIDS), et l¶autre avec motifs variants et

texte fixe (comme la recherche dans un dictionnaire). Parmi les algorithmes [Voir Annexe E]

utilisés dans cette approche nous citons :

Algorithme naïf (appelé en anglais Brute Force Algorithm), consiste à vérifier pour

chaque position dans le texte si une occurrence de motif commence à cette position ou

pas. Si oui, il le signale. Sinon il recommence en avançant d¶une position à droite.

Algorithme de Knuth-Morris-Pratt : cet algorithme effectue un pré traitement du

motif, qui fournit une information suffisante pour déterminer ou continuer la recherche

en cas de non correspondance. Cela permet à l¶algorithme de ne pas réexaminer les

caractères qui ont été précédemment vérifiés, et donc de limiter le nombre de

comparaisons nécessaires.

Algorithme de Boyer-Moore : cet algorithme effectue un pré traitement du motif, et

au lieu d¶effectuer la recherche de la gauche vers la droite, il l¶effectue à l¶inverse. Cette

particularité s¶avère rentable vu la rapidité de cet algorithme.

Algorithme Aho-Corasick : le fonctionnement de cet algorithme est unegénéralisation de l¶algorithme Knuth-Morris et Pratt, sa particularité réside dans la

recherche parallèle de plusieurs motifs.





34

4.3. Tableau comparatif :

Le tableau qui suit présente les avantages et les inconvénients des deux approches

définies précédemment :

Approche comportementale Approche par scénario

Avantages

- Pas besoin d¶une base d¶attaques.

- Détection d¶intrusions inconnues

possible.

- Prise en compte des comportements

exacts des attaquants potentiels :

peu de faux positifs

« Rien n¶est jamais sûr ! »

Inconvénients

- Pour un utilisateur au

comportement erratique (irrégulier),

toute activité est normale.

- En cas de profonde modification

de l¶environnement du système cible,déclenchement d¶un flot ininterrompu

d¶alarmes :

gros risque de faux positifs

- Utilisateur pouvant changer

lentement de comportement afin

d¶habituer le système à un

comportement intrusif :

risque de faux négatifs

- Base de scénarios, difficile à

construire et à maintenir :


- Pas de détection d¶attaques non

connues :


- Détection de scénarios complexes

difficile.

Tableau II.1 : Comparaison entre les approches adoptées dans la détection d¶intrusion

5. SNORT :

Alors que les attaques des réseaux prennent de l¶ampleur, et que les failles de sécurités

de cessent d¶augmenter, seul une multitude de mécanismes de sécurité permettra de tirer du

néant l¶insécurité des systèmes d¶informations. En complément pour les pare-feux, les

systèmes d¶authentifications et autres dispositifs de sureté, le choix de l¶IDS Open source

« SNORT » est fait car il est considéré parmi les meilleurs dans le domaine de la détection

d¶intrusions [Voir Annexe D].

5.1. Présentation :

SNORT est un NIDS écrit par Martin Roesch, disponible sous licence GNU, son code

source est accessible et modifiable à partir de l¶URL : « http://www.snort.org »





35

5.2. Architecture et Composants :

SNORT est divisé en plusieurs composants qui interagissent entre eux pour détecter

des attaques particulières et générer des alertes sous des formes spécifiées par le système de

détection d¶intrusions. L¶architecture de SNORT est organisée en modules [ Figure II.5], qui

sont : Décodeur de paquet ( Packet Decoder ) : il capture les paquets de données des interfaces

réseaux, les prépare afin d¶être prétraitées ou envoyées au moteur de détection.

Pré processeurs ( Pre processors) : ce sont des composants utilisés avec Snort afin

d¶améliorer les possibilités d¶analyse, et de recomposition du trafic capturé. Ils reçoivent

les paquets, les retraitent et les envoient au moteur de détection.

Moteur de détection ( Detection Engine) : c¶est le composant le plus important de Snort.

Son rôle consiste à détecter les éventuelles intrusions qui existent dans un paquet. Pour

se faire, le moteur de recherche se base sur les règles de Snort. En effet, ce moteur consulte ces règles et les compare une à une avec le paquet de données. S¶il y a

conformité, le détecteur l¶enregistre dans le fichier log et/ou génère une alerte. Sinon le

paquet est laissé tomber.

Système d¶alerte et d¶enregistrement des logs ( Logging and Alerting System) : il

permet de générer les alertes et les messages log suivant ce que le moteur de détection a

trouvé dans le paquet analysé.

Output modules (ou plug-ins) : permet de traiter l¶intrusion générée par le système

d¶alerte et de notation de plusieurs manières : envoie vers un fichier log, génère un

message d¶alerte vers un serveur syslog, et stocke cette intrusion dans une base de

données comme MySQL ou Oracle.

La figure suivant décrit l¶architecture de Snort :





36

Figure II.5 : Architecture de Snort

5.3. Modes de détection d¶intrusions :

SNORT permet d¶analyser le trafic réseau de type IP, il peut être configuré

pour fonctionner en quatre modes :

Le mode Sniffer : dans ce mode, SNORT lit les paquets circulant sur le réseau et les

affiche d¶une façon continue sur l¶écran.

Le mode « Packet Logger » : dans ce mode SNORT journalise le trafic réseau sur

le disque.

Le mode détecteur d¶intrusion réseau (NIDS) : dans ce mode, SNORT analyse le

trafic du réseau, compare ce trafic à des règles déjà définies par l¶utilisateur et établi

des actions à exécuter (Alertes).

Le mode Prévention des intrusions réseau (IPS).

5.4. Implémentation de SNORT :

SNORT est un IDS spécialement conçu pour s¶exécuter sur différents systèmes

d¶exploitation, le cas du projet traité dans ce rapport, implique son installation sur un

environnement Windows, pour qu¶ensuite il s¶approvisionne de l¶application en cours de

développement baptisé « ALS ».

Afin de comprendre son fonctionnement en termes d¶adaptation logicielle, la figure qui

suit ( Figure II.6 ) montre les interactions entre SNORT ainsi que sa base de données, et plusloin encor avec l¶application « ALS ».

1 : Capture des paquets

2 : Analyse des paquets

3 : Enregistrement dans la

base de données

4 : Configuration deSNORT par ALS »,

démarrage/arrêt, retour

des résultats.5 : Analyse des logs

enregistrés dans la base

de données

Figure II.6 : Interactions au sein du système





37

6. Comparatif entre IDS Open source :

Afin de confirmer le choix fait pour l¶IDS SNORT, une recherche a été effectuée sur

d¶autres IDS Open Source célèbre, ainsi des comparaisons avec SNORT ont eu lieu seloncertains critères. Les IDS choisis pour cette partie sont Prelude et Bro. Ceci a permis de

distinguer SNORT parmi ces siens.

6.1. Prelude [16] :

6.1.1. Présentation :

Prelude IDS est un système de détection d¶intrusions sous licence GPL disponible sur

les plateformes Linux, FreeBSD et Windows. La détection d¶intrusions est réalisée par

l¶analyse du trafic réseau, et l¶utilisation d¶une base de signatures. Lors d¶une analyse dutrafic, l¶analyseur de Prelude confronte les données aux signatures. S¶il détecte une intrusion,

il génère une alerte détaillée contenant l¶adresse IP source et destination, le degré de criticité

et d¶autres informations.

Prelude est un IDS hybride très performant surtout avec sa configuration facile et son

architecture client/serveur qui permet à un manager de gérer plusieurs sondes. Mais il faut

noter que la documentation sur Prelude et parsemée et contient parfois des erreurs.

6.1.2. Architecture et Composants :

Prelude possède une architecture modulaire, distribuée et sécurisée. Modulaire, car sescomposants sont indépendants, d¶où il est plus facile d¶intégrer ou de développer de nouvelles

fonctionnalités grâce à des « plugins ». Distribuée, car ses composants autonomes

interagissent les uns avec les autres, cela permet d¶avoir des composants installés sur

différentes machines ainsi nous pouvons réduire la surcharge d¶applications. Sécurisée avec

l¶utilisation du support SSL7 pour l¶authentification et le chiffrement des communications.

Les différents composants de Prelude sont les sondes et les managers. Les sondes

signalent les tentatives d¶attaques par les alertes. Le manager reçoit ces alertes, les interprète

et les stocke. Prelude a l¶avantage d¶être très modulaire de par son architecture Client -

Serveur. Un manager peut gérer plusieurs sondes et une sonde peut envoyer ses alertes à

plusieurs managers. Cependant, le filtrage au niveau de la sonde pour savoir à quel manager

est envoyée telle alerte n¶est pas encore opérationnel.

7 SSL (Secure Sockets Layers) est un procédé de sécurisation des transactions effectuées via Internet.





38

6.2. Bro [14] :

6.2.1. Présentation :

Bro est un système de détection d¶intrusions sous licence libre disponible seulement

sous Unix. Bro se base sur un ensemble de règles décrivant des signatures d¶attaques ou desactivités inhabituelles. Le comportement de Bro lors de la détection d¶une intrusion, peut être

paramétré. En effet, il peut alerter l¶administrateur en temps réel, enregistrer dans un fichier

log ou même exécuter une commande du système d¶exploitation (arrêter la connexion,

bloquer l¶attaquant, etc.).

Bro utilise son propre langage qui permet d¶exprimer les signatures comme étant des

expressions régulières et non pas des chaînes de caractères fixes. Ceci permet de renforcer son

analyseur, puisqu¶en plus d¶analyser le trafic, l¶analyseur de Bro peut comprendre le contenu

des paquets, ce qui permet de minimiser les fausses alertes. L¶inconvénient avec les alertes de

Bro, c¶est qu¶elles ne sont pas bien détaillées et donc difficiles à interpréter.

6.2.2. Architecture et composants :

Bro possède une architecture composée de trois couches. La première contient le capteur

de paquet qui est chargé de sniffer le trafic réseau, de capturer les paquets et de les transmettre

à la couche supérieure. Cette dernière, contient le moteur d¶événement (Event Engine) qui est

chargé d¶effectuer une analyse protocolaire dynamique, contrôler l¶intégrité des paquets,

émettre des alertes en cas d¶anomalies et rassembler les paquets fragmentés si nécessaires. La

troisième couche est la couche de politique, traite les événements reçus de l¶Event Engine, et

applique les politiques écrites dans les scripts Bro.





39

6.3. Comparatif Snort, Prelude et Bro :

Critères Snort Prelude Bro

Année de création 1998 1998 1998

Auteur Martin Roesch YoannVanndoorselaere

Vern Paxson

Licence Open source Open source Open source

Plateforme Toutes les plateformes Linux, FreeBSD etWindows

Unix

Base de signatures Riches et à jour Limitée Limitée

Difficulté deConfiguration

Moyenne, nécessitedes compétences

Facile Facile grâce à un scriptinteractif

Remontée desinformations En continu Pulsation (Batch) En continu

Moteur d¶analyse Confrontation avec unebase des signatures

Confrontation avec unebase des signatures

Confrontation avec unebase des signatures

Informations dans lesalertes

Alertes bien détaillées Alertes bien détaillées Alertes mal détaillées

Popularité (Nombrede téléchargements)

Très populaire (grandnombre)

Popularité moyenne(nombre moyen)

Un peu

Intégration d¶outilsexternes

Ne permet pasl¶intégration d¶outils

Permet l¶intégration Permet l¶intégration

Documentation Très bien documenté Peu de documentationet avec des erreurs

Peu de documentation

TCP connect scan Résultat correct Pas de résultat Résultat correct

TCP SYN scan Résultat correct Pas de résultat Résultat correct

TCP NULL scan Résultat correct Pas de résultat Pas de résultat

Tableau II.2 : Comparaison entre IDS¶s OpenSource

Les résultats relevés de cette comparaison coïncident avec les besoins demandés et ont permis, entre autres, de choisir SNORT qui s¶avère le plus efficace parmi les autres IDS Open

Source.





40

7. Conclusion :

Ce chapitre a permis de détailler la présentation des systèmes de détection d¶intrusions

tout en mettant l¶intonation sur l¶IDS SNORT. Une présentation accouplée a une comparaison

avec deux autres IDS Open Source à savoir Prelude et Bro.

Le choix de l¶IDS SNORT, étant fait, pour travailler avec et pour développer

l¶application

Le chapitre suivant traitera l¶approche, basée sur une conception UML, tout en

s¶intéressant aux langages et outils de programmation utilisés.



Chapitre III : Atelier de génie logiciel & Conception 2TUP


41






42

1. Introduction :

Ce projet conduit a la réalisation d¶une application de gestion et d¶analyse de Logs

pour l¶IDS SNORT ; une réalisation qui adopte une méthodologie connue et supporté par la

conception UML. Le choix du langage de programmation, lui aussi, aura sa place dans sechapitre. Ainsi tous les composants impliqués dans ce projet seront mis en évidence afin de

bâtir le tout sur de bonnes bases.

2. Modélisation et Méthodologie adoptées :

2.1. Langage de modélisation unifié (UML) :

« Uml : Langage d'analyse et de conception orienté objet défini par l'OMG (Object

Management Group). UML homogénéise les représentations graphiques des objets issues des

travaux de Grady Booch chez Rational Software, de Rumbaugh et d'Ivar Jacobson. » [24]

UML est conforme aux besoins de la programmation orientée objet ; l¶un des points

forts de ce langage, c¶est qu¶il peut être intégré dans n¶importe quel processus de

développement logiciel de manière transparente.

2.2. Processus Unifié (UP) et sa variante 2TUP :

Pour veiller à produire une bonne modélisation avec le langage UML, il convient

d¶utiliser un Processus Unifié (UP). Ce dernier est porté par une grande considération dans le

développement logiciel.

y « Il est itératif et incrémental. La définition d¶itérations de réalisation est en effet la

meilleure pratique de gestion des risques d¶ordre à la fois technique et fonctionnel.

On peut estimer qu¶un projet qui ne produit rien d¶exécutable dans les 9 mois court

un risque majeur d¶échec. Chaque itération garantit que les équipes sont capables

d¶intégrer l¶environnement technique pour développer un produit final et fournit

aux utilisateurs un résultat tangible de leurs spécifications. Le suivi des

itérations constitue par ailleurs un excellent contrôle des coûts et des délais.y Il est piloté par les risques. Dans ce cadre, les causes majeures d¶échec d¶un

projet logiciel doivent être écartées en priorité. Nous identifions une première cause

provenant de l¶incapacité de l¶architecture technique à répondre aux contraintes

opérationnelles, et une seconde cause liée à l¶inadéquation du développement aux

besoins des utilisateurs.





43

y Il est construit autour de la création et de la maintenance d¶un modèle, plutôt que de

la production de montagnes de documents. Le volume d¶informations de ce modèle

nécessite une organisation stricte qui présente les différents points de vue du

logiciel à différents degrés d¶abstraction. L¶obtention de métriques sur le

modèle fournit par ailleurs des moyens objectifs d¶estimation.

y Il est orienté composant. Tant au niveau modélisation que production, c¶est

une garantie de souplesse pour le modèle lui-même et le logiciel qu¶il représente.

Cette pratique constitue le support nécessaire à la réutilisation logicielle et offre des

perspectives de gains non négligeables.

y Il est orienté utilisateur, car la spécification et la conception sont construites à partir

des modes d¶utilisation attendus par les acteurs du système. » [25]

L¶une des variantes du processus unifié, est le processus 2TUP « 2 Track UnifiedProcess », c¶est un processus qui vise à fusionner les résultats évolutifs du modèle fonctionnel

et de l¶architecture technique, pour y parvenir, après fusion, à l¶obtention d¶un processus en

forme de Y (Figure III.1).

Figure III.1 : Processus de développement en Y [25]

La branche gauche (contraintes fonctionnelles) comporte :

y la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé

sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système

inadapté aux utilisateurs. De son côté, la maîtrise d¶uvre consolide les

spécifications et en vérifie la cohérence et l¶exhaustivité.





44

y L¶analyse, qui consiste à étudier précisément la spécification fonctionnelle de

manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les

résultats de l¶analyse ne dépendent d¶aucune technologie particulière.

La branche droite (contraintes technique) comporte :

y La capture des besoins techniques, qui recense toutes les contraintes et les choixdimensionnant la conception du système. Les outils et les matériels sélectionnés

ainsi que la prise en compte de contraintes d¶intégration avec l¶existant

conditionnent généralement des pré requis d¶architecture technique ;

y La conception générique, qui définit ensuite les composants nécessaires à la

construction de l¶architecture technique. Cette conception est la moins dépendante

possible des aspects fonctionnels. Elle a pour objectif d¶uniformiser et de réutiliser

les mêmes mécanismes pour tout un système. L¶architecture technique construit le

squelette du système informatique et écarte la plupart des risques de niveau technique.

L¶importance de sa réussite est telle qu¶il est conseillé de réaliser un prototype pour

assurer sa validité.

La branche du milieu comporte :

y La conception préliminaire, qui représente une étape délicate, car elle intègre le

modèle d¶analyse dans l¶architecture technique de manière à tracer la cartographie des

composants du système à développer ;

y La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;

y L¶étape de codage, qui produit ces composants et teste au fur et à mesure les unités de

code réalisées ;

y L¶étape de recette, qui consiste enfin à valider les fonctions du système

développé.

Comme on l¶a indiqué précédemment, on ne peut utiliser 2TUP qu¶en ayant recours à

UML, ceci dit, il va falloir indiquer chaque un des diagrammes à utiliser dans chaque étape du

processus de développement. Le tableau (Tableau III.1) qui fait correspondre les diagrammes

d¶UML aux différents points de vue du modèle.





45

Tableau III.1 : Utilisation des diagrammes UML en fonction du point de vue du modèle. [25]

En complément pour le tableau ci-dessus :

Capture des besoins fonctionnels : les diagrammes de cas d¶utilisation, de

séquence, de collaboration, d¶activités et de classes (en option).

Analyse : les diagrammes de classe, d¶états et d¶objets (en option).

Capture des besoins techniques : les diagrammes de classes (en option), de cas

d¶utilisation, de séquence (en option), de collaboration (en option) et d¶activités.

Conception générique : les diagrammes de composants et de déploiement.

Conception préliminaire : les diagrammes de classes, d¶objets (en option), de

séquence, de collaboration et d¶états avec une complémentarité par le diagramme

de composants.

Conception détaillée : mêmes diagrammes que ceux de la conception détaillée

mais avec un niveau d¶analyse plus détaillé.

3. Choix des langages et des outils de programmation :

Java est un langage de programmation objet, reconnu pour ces qualités en termes de

portabilité ; l¶une des raisons pour lesquelles il a été choisi comme langage, c¶est sonadaptation facile aux différents systèmes d¶exploitation, pourvu qu¶on doive se munir de la

machine virtuelle Java (JVM : Java Virtual Machine) correspondante aux critères que le

logiciel possède.

Le code source de l¶application ALS à été implémenté avec l¶outil de programmation

NetBeans IDE en sa version 6.5.1, incluant la JVM de version 1.5.0_09-b03. Disponible en

téléchargement à l¶adresse « http://www.netbeans.org »





46

La plateforme JEE (JEE : Java Entreprise Edition) étant nécessaire pour le

fonctionnement de NetBeans, le choix s¶est orienté vers la dernière version, la JEE 5.

Pour l¶ajout des graphes définis dans le cahier des charges du projet, il a été décidé de

recourir aux bibliothèques JFreeChart et JCommon, disponibles en téléchargement gratuit sur

le site « http://www.jfree.org », en leur version commune 1.0.12.Pour satisfaire le besoin de connecter SNORT et ALS à une base de données MySQL,

la bibliothèque à été téléchargé en sa version 5.1.5 et a été ajouté à l¶application.

La base de données MySQL a été crée au dépend de SNORT, elle comprend 16 tables

indispensables au fonctionnement de SNORT, ainsi que trois autres imposées pour faire

fonctionner l¶application ALS ; elle a été créée avec EasyPHP en sa version 2.0b1, cet outil

comprend un module d¶administration MySQL.

UML est adapté a une programmation objet, il permet une décomposition modulaire et

structurée d¶un problème et ce en localisant les parties intervenantes (objets) ainsi que les

fonctionnalités. Le choix pour la modélisation des diagrammes s¶est orienté vers l¶outil Visio

de MS Office.

4. Conception 2TUP de ALS :

4.1. Analyse fonctionnelle :

4.1.1. Capture des besoins fonctionnels :

Le but de cette phase consiste à préciser la vue fonctionnelle du système, et de montrer

la manière dont les acteurs vont utiliser ce dernier.

Figure III.2 : Etape actuelle du processus 2TUP [26]





47

Identification des acteurs8

:

Super_user : Utilisateur ayant toutes les fonctionnalités en main pour modifier les règles, créer de nouvelles, accéder à toute la base de données en modeinterpréteur SQL, et aussi ajouter/supprimer des utilisateurs.

Network_manager : Cet acteur peut gérer SNORT, dont ses signatureset les logs qu¶il stocke, peut aussi accéder à la base de données en mode interpréteur SQL.

User_without_privileges : C¶est l¶acteur ayant le moins defonctionnalités en vue, il ne peut consulter que les statistiques et les données qui leurscorrespondent.

Liste préliminaire des cas d¶utilisations :

Cas d¶utilisation Acteurs Messages

Consulter les statistiques Super_user

Network_manager

User_without_privileges

Requêtes SQL

S¶authentifier Super_user

Network_manager

User_without_privileges

Requêtes SQL

Gérer les signatures Super_user

Network_manager

Message de modification

d¶état

Editer un rapport d¶audit Super_user Network_manager

Message de demande d¶état

Gérer la base de données Super_user

Network_manager

Requêtes SQL

Configurer l¶application Super_user Message de modification

d¶état

Tableau III.2 : Tableau des cas d¶utilisations préliminaires

Diagramme des cas d¶utilisations

Après identifications des acteurs ainsi que des cas d¶utilisation de notre application,l¶illustration qui suit ( Figure III.3 : Diagramme des cas d¶utilisations) fait son apparition pour

schématiser les interactions entre les différentes entités et les cas dµutilisations

correspondants. Cette figure indique les privilèges que chaque acteur possède, autrement dit,

les cas d¶utilisations qui lui sont propre.

8 Intervenant direct sur un système



Chap¡ ¢

£ e III

¤

¥ ¢

e¦

¡

e£

de gén¡

e¦ og

¡

c¡

e¦ & Concep

¢ ¡

on 2§

¨ ©

¥

na¦

eu£

de Log

pou£

§

a

£ a

¦

¥

L

48

F i ! " # $ III. % & ' i ( ! # ( mm$ ) $ 0 1 ( 0 ) ¶ " 2 ili 0 ( 2 i 3 4 0

Remarque : pour le reste des diagrammes concernant cette section, tous les acteurs

seront représentés par un seul, ayant pour nom AC 5 E 6 R ( F i7 8 9 @

A A A

B

C

D

E

F t @ 8 9 G

H

8

G I G t P

Q @ ).

F i R S T U III. V W X

Y ` U S T a b S a

c

a ` d mU

Diagramme de séquences

A ce st e, les fonctionnalit s du syst e sont celle pr inci palement effectuées par

l application ainsi que la base de données qu¶elle gère, ceci dit, il est nécessaire de préciser

que le modèle de cette application suit celui du Client serveur. En effet, ALS gère l¶outil, qui

Super-user User_without_privilegeNetwork_manager

Acteur





49

est caché derrière, SNORT ; En acceptant les demandes qu¶elle reçoit, effectue les traitements

nécessaires, et renvoie les résultats associés.

Figure III.5 : Diagramme de séquence géneralisé

4.1.2. Analyse :

L¶analyse est la deuxième phase de la branche fonctionnelle du processus 2TUP. Visant à

étudier la spécification fonctionnelle et induisant une idée sur les accomplissements du

système.

Figure III.6 : Etape actuelle du 2TUP [26]





50

Diagramme de séquences

Afin de comprendre l¶accessibilité aux différents cas d¶utilisations du système, le schéma qui

suit ( Figure III.5 : Diagramme d¶ activités géneralisé) exprime le comportement de « ALS »

vis-à-vis de l¶utilisateur final tout en généralisant les cas d¶utilisations en un seul.

Figure III.7 : Diagramme d¶activités de point de vue fonctionnel

Développement du modèle statique

Le modèle statique, est fondé sur le fait de schématiser un diagramme de classes, comportant

les classes participantes à la phase « Capture des besoins fonctionnels ». La concentration sera

portée au dialogue entre L¶utilisateur et l¶application qui gère SNORT, intitulé ALS.

Les classes solliciteuses :

La classe « Start » : Sert d¶interface de dialogue entre SNORT et l¶utilisateur en offrant les

menus permettant d¶assurer le démarrage/arrêt des services de SNORT, ainsi que les services

proposés par l¶application elle-même.

La classe « Sqlbd » : permet de gérer la base de données imposée par SNORT et résultante

d¶ALS ; tout en stockant, modifiant ou affichant le contenu.





51

La classe « Auth » : Assure l¶accès aux différents utilisateurs selon les privilèges que chacun

d¶eux possèdent.

La classe « Paramsnort » : Paramètre SNORT selon les demandes de l¶utilisateur, ces

demandes peuvent concerner : Le mode de fonctionnement de SNORT ; l¶ajout, la création,

ou la suppression des règles ; la consultation des alertes selon des critères définies.

Ainsi, succinctement, le diagramme des classes généralisé sera le suivant :

Figure III.8 : Diagramme de classe de point de vue fonctionnel

Développement du modèle dynamique

Il s¶agit d¶étudier le système d¶un point de vue dynamique afin de préciser les interactions

entre les objets et les états des classes. Il est alors primordial de schématiser ce relais par undiagramme d¶état. ( Figure III.8)





52

Figure III.9 : Diagramme d¶état généralisé

4.2. Analyse technique :

4.2.1. Capture des besoins techniques :






53

Cette phase du processus implique les contraintes, orientant la conception du système, qui

répondent aux exigences techniques recensées précédemment. Pour cela, les contraintes

matérielles ainsi que logicielles vont être mises en considération afin de s¶approvisionner pour

poursuivre la méthodologie 2TUP adoptée.

CONTRAINTES : Comme exprimé dans le chapitre « systèmes de détection d¶intrusion »,

la détection d¶intrusion est assurée par SNORT ; Ce dernier est installé dans les zones

sensibles du réseau afin de détecter les flux de données externes et internes.

Les différentes sondes SNORT sont installées sur le réseau pour collecter les flux de

données en les comparants aux signatures d¶intrusions, et dès qu¶il y a détection de flux

corrompu, les sondes enregistrent les alertes dans une base de données. Cette base de logs

est accessible à n¶importe quel endroit du réseau, en introduisant l¶adresse de cette

dernière et après authentification.

Contraintes matérielles :

L¶étude de cette section va débuter à partir d¶une analyse de la figure ( Figure II.4 Chapitre2)

schématisant les différents emplacements de SNORT, pourvu que l¶application en cours de

conception « ALS » est accessible à n¶importe quel endroit du réseau (Serveurs ou hôtes).

Les stations contenant SNORT devront se munir de cartes réseaux Ethernet GigaByte,

afin de pouvoir contrôler la quantité de données variables et majoritairement grande.

Les stations devront contenir assez de mémoire vive (RAM) pour supporter les

traitements que fait SNORT.

Les stations doivent avoir des supports de stockage d¶assez grandes tailles afin de

pouvoir y stocker les logs que génère SNORT.

Contraintes logicielles :

Afin de comprendre le fonctionnement de l¶application dans son contexte global, il faudrait se

référer au schéma (Figure II.5 Chapitre2) qui indique toutes les interactions possibles entre les

composantes logicielles présentes.





54

L¶application « ALS » sera la tierce partie d¶un ensemble (SNORT + Base de Données) déjà

existant, d¶où la première intension d¶implémenter les tables crées par « ALS » dans la base

de données même de SNORT, et ce pour assurer l¶accès aux données aux deux entités

principalement intervenantes.

Dans un premier temps, SNORT analyse le trafic en recherchant des flux comportantdes paquets semblables aux signatures d¶attaques et rempli sa base de logs.

Ensuite, « ALS » analyse les logs enregistrés pour en tirer des statistiques.

« ALS », peut aussi intervenir sur SNORT même en démarrant/arrêtant ou en

changeant ses critères de configuration selon la façon voulue d¶analyse de trafic.

Diagramme de cas d¶utilisations :

Figure III.11 : Diagramme des cas d¶utilisations raffiné





55

4.2.2. Conception générique :


C¶est à cette étape là du 2TUP qu¶on doit élaborer la solution qui répond aux spécifications

techniques. Il est donc intéressant d¶élaborer un modèle logique de conception, sous forme de

diagramme de déploiement, permettant de mieux orienter la réalisation de l¶application.

Figure III.13 : Diagramme de déploiement

4.3. Conception :

Afin d¶entamer la phase de conception qui consiste à fusionner notre étudefonctionnelle avec l¶étude technique. Il va falloir passer de l¶analyse objet à la conception.

Les interactions entre classes de conception permettent de consolider et de vérifier à terme

la conception des cas d¶utilisation fonctionnels tenant compte des contraintes

opérationnelles.





56

4.3.1. Conception préliminaire :


Diagramme de classesVue que le nombre de classes est grand, il serait préférable de donner un vue d¶ensemble à

l¶application, en schématisant le fonctionnement de cette dernière par un diagramme de classe

( Figure III.16 ) tout en sachant que les vrais noms des classes ne sont pas les mêmes indiqués

sur cette figure.

Figure III.15 :Diagramme de classes

Pour l¶authentification c¶est la classe « Auth » qui a été définie pour établir une

connexion avec la base de donnée et faire la correspondance entre l¶identifiant de





57

l¶utilisateur qui veut se connecter et les donner ce trouvant dans la table `user` de la

base de données intitulé `snort`. La classe qui conduit cette phase de connexion à la

BD est « User ».

L¶accueil de l¶application est assuré par deux classes « Lance » et « Start ».

La classe « Start » permet l¶accès à toutes les fonctionnalités du système dont : la configuration de SNORT assurée par « Paramsnort » ;

le traitement des règles (ajout, modification, création, suppression) guidé par les

classes « Ajoutr », « Editr », « Assiseditr », « Modiffr », « Modifr », « Suppfr »,

« Suppr ».

La consultation des statistiques, en d¶autres termes les logs de SNORT, implique

plusieurs classes faite selon les différents choix qui existent (sonde, protocoles, ports

[source ; destination ; TCP ; UDP], @IP, analyse temporelle) ; Les classes

participantes sont donc : « Aalerte », « Calerte », « Atemp », « Aport », « Aprsrc »,« Aprsrc », « Aprotocol », « Asonde », « Aptcp », « Apudp ».

L¶aide de l¶application est assuré par la classe « Ageneral »

L¶accès à la base de données implique les classes : « Sqlbd », « Abds », « Videbd » ;

Selon les choix faits, ces classes sont utilisées pour apporter des modifications,

suppression ou un simple affichage à l¶utilisateur de l¶application

La classe « Rapport » permet l¶impression d¶un rapport de situation détaillé

concernant l¶analyse faite.

Les classes « Main » et « Panel » épaulent l¶application pour le démarrage et

l¶affichage des fenêtres.

4.3.2. Conception détaillée :



Chape

f

g e III

h

i f

ep e e

g de gén

e e

p og

e c

e e

p & Concep

f

e on 2

q

r s

i

nap

t u

eug

de Logu

poug

v

w x y

q

x � a

g � a

�

u

� p �

i

� � L

58

F i � � � � III.

� �

� E

� �

�

�

� � � � � ll

�

� �

� � � P [26]

Dans cette par tie, les concepts provenant de l¶analyse vont être transformés en techniques

disponi bles selon les outils et langages de développement conventionnés.

La conception des associations, trainera les classes par tici pantes vues à l¶analyse, les

accompagne aux opérations de gestion et autres classes dont on a discuté l¶existence à la

conception préliminaire.

La conception des attr i buts se voit pr inci palement déf inir le type et la visi bilité des attr i buts.

Diagrammes des classes

Les deux étapes successives et précédentes permettront d¶aboutir à des diagrammes de classes

remarquables sur le plan des associations et des attr i buts.

Remarque :

Pour des soucis d¶impression concernant les diagrammes de classes, on va à chaque fois

focaliser sur une classe, la détailler et présenter les éventuels liens qu¶elle possède avec les

autres classes.

F i

III.

j

Lk

l l

k m m

n k i

o



Chap

e III

e e

de gén

e

og

c

e

& Concep

on 2

na

z

eu

de Logz

pou

{

| } ~

} a

a

z

L

59

F i III. � L � � l � � � P � � l

F i III.

�

� L

�

� l

� � � L

� � �



Chap

e III

e e

de gén

e

og

c

e

& Concep

on 2

na

�

eu

de Log�

pou

�

� � �

� � a

a

�

L

60

F i

III.

ª

L«

¬ l

« S

® « ®



Chap ̄

°

± e III

²

³ °

e´ ̄e

± de gén

̄e

́og

̄c

̄e

́& Concep

°

̄on 2

µ

¶ ·

³

na ́

̧ ¹

eu±

de Log¹

pou±

º

» ¼ ½

µ

¼ ¾ a

± ¿ a

À

¹

Á ´ ¿

³

Â Á L

61

F i Ã Ä Å Æ

III.Ç È

É

LÊ

Ë

l Ê Ì Ì Æ

Í

Ä Î Ï





62

Figure III.22 : Ð a classeSqlbd



ChapÑ

Ò

Ó e III

Ô

Õ Ò

eÖ Ñ e

Ó de gén

Ñ e

Ö og

Ñ c

Ñ e

Ö & Concep

Ò

Ñ on 2

×

Ø Ù

Õ

naÖ

Ú Û

euÓ

de LogÛ

pouÓ

Ü

Ý Þ ß

×

Þ à a

Ó á a

â

Û

ã Ö á

Õ

ä ã L

63

F i å æ ç è III. é ê ë L ì í l ì î î è ï

ð ñ î



Chapò

ó

ô e III

õ

ö ó

e÷ ò e

ô de gén

ò e

÷ og

ò c

ò e

÷ & Concep

ó

ò on 2

ø

ù ú

ö

na÷

û ü

euô

de Logü

pouô

ý

þ ÿ

ø

ÿ ¡ a

ô ¢ a

£

ü

¤ ÷ ¢

ö

¥ ¤ L

64

F i ¦ § ¨ © III. L l © Vi ©

F i ¦ § ¨ ©

III.

L

l

©

© ¨



Chap

!

" e III

#

$ !

e% e

" de gén

e

% og

c

e

% & Concep

!

on 2

&

' (

$

na%

) 0

eu"

de Log0

pou"

1

2 3 4

&

3 5 a

" 6 a

7

0

8 % 6

$

9 8 L

65

F i @ A B C III. D E F L G H l G I I C P

G l C B Q C

F i @ A B C III. D R F L G H l G I I C C G l C B Q C



ChapS

T

U e III

V

W T

eX S e

U de gén

S e

X og

S c

S e

X & Concep

T

S on 2

Y

` a

W

naX

b c

euU

de Logc

pouU

d

e f g

Y

f h a

U i a

p

c

q X i

W

r q L

66

F i s t u v

III.w x

y

L�

� l

� � � v

�

� v m

�



Chap�

�

� e III

�

� �

e� � e

� de gén

� e

� og

� c

� e

� & Concep

�

� on 2

�

� �

�

na�

� �

eu�

de Log�

pou�

�

� �

�

� a

� a

�

�

�

L

67

F i j k l m III. n o L l m

l

F i z {

III.| }

~

L

l

{

z

F i III. � � � L � � l � � �

� �



Chap

e III

e e

de gén

e

og

c

e

& Concep

on 2

�

na

� �

eu

de Log�

pou

�

� �

� a

a

�

L

68

F i III. ª « ¬ L ® l ̄ ¯ °

±

² ³ ² ® ² l

F i

III.ª ª

¬

L ® l ̄

¯

°

±

́

±

F i III. ª µ ¬ L ® l ̄ ¯ °

±

³ ®

±



Chap¶

·

̧ e III

¹

º ·

e» ¶ e

̧ de gén

¶ e

» og

¶ c

¶ e

» & Concep

·

¶ on 2

¼

½ ¾

º

na»

¿ À

eu ̧

de LogÀ

pou ̧

Á

Â Ã Ä

¼

Ã Å a

¸ Æ a

Ç

À

È » Æ

º

É È L

69

F i Ê Ë Ì Í

III.Î Ï

Ð

LÑ

Ò l

Ñ Ó Ó Í

Ô

Ó Õ Ö × Í

F i Ê Ë Ì Í III. Î Ø Ð L Ñ Ò l Ñ Ó Ó Í Ô

j Õ Ë Ù Ì



ChapÚ

Û

Ü e III

Ý

Þ Û

eß Ú e

Ü de gén

Ú e

ß og

Ú c

Ú e

ß & Concep

Û

Ú on 2

à

á â

Þ

naß

ã ä

euÜ

de Logä

pouÜ

å

æ ç è

à

ç é a

Ü ê a

ë

ä

ì ß ê

Þ

í ì L

70

F i î ï ð ñ III. ò ó ô L õ ö l õ ÷ ÷ ñ ø

÷ ÷ i ñ ù i ú ð



Chapû

ü

ý e III

þ

ÿ ü

e û e

ý de gén

û e

og

û c

û e

& Concep

ü

û on 2

¡

¢ £

ÿ

na

¤ ¥

euý

de Log¥

pouý

¦

§ ¨ ©

¡

¨ a

ý a

¥

ÿ

L

71

F i III. ! L " # l " $ $ E % i &

F i III. ' ! L " # l " $ $ ( ) % i 0 0



Chap1

2

3 e III

4

5 2

e6 1 e

3 de gén

1 e

6 og

1 c

1 e

6 & Concep

2

1 on 2

7

8 9

5

na6

@ A

eu3

de LogA

pou3

B

C D E

7

D F a

3 G a

H

A

I 6 G

5

P I L

72

F i Q R S T III. U V W L X Y l X ` ` T a b c i d S



Chape

f

g e III

h

i f

ep e e

g de gén

e e

p og

e c

e e

p & Concep

f

e on 2

q

r s

i

nap

t u

eug

de Logu

poug

v

w x y

q

x � a

g � a

�

u

� p �

i

� � L

73

F i � � � � III.

� �

� L

�

� l

� � � � S

�

� �

�

F i � � � �

III.

L

l

� S

�

j j

k �



Chapl

m

n e III

o

m

e l e

n de gén

l e

og

l c

l e

& Concep

m

l on 2

na

eun

de Log

poun

z

{ a

n | a

}

~ |

~ L

74

F i

III.

L

l

P

m

� � �



Chap�

�

� e III

�

e � e

� de gén

� e

og

� c

� e

& Concep

�

� on 2

na

eu�

de Log

pou�

� �

� � a

� � a

�

� �

� L

75

F i

III.

L

l

ª

« l





Chapitre IV : L·application « A L S »


77

Chapitre IV : L¶application « A L S »





78

1. Introduction :

Le chapitre précédent, a traité la conception de « ALS », adoptant la méthodologie

2TUP. La conception, elle-même, demande au développeur une certaine clairvoyance, tandis

que le codage met le plus dévoué des programmeurs face à des difficultés imprévisibles.

Toute application qui voit le jour, conduit son utilisateur à rechercher et essayer les

fonctionnalités qu¶elle cache. Ce chapitre, permet de dénombrer les fonctionnalités de

« ALS », tout en gardant l¶il sur les techniques utilisées lors du codage de l¶application.

2. SNORT :

L¶environnement de travail, qui élit le projet en cour, se compose principalement deSNORT, un IDS Open Source, très connu pour ses innombrables qualités dans le domaine de

la sécurité informatique et précisément dans la détection d¶intrusions.

SNORT est, sans doute, compétent mais il présente des lacunes concernant sa

configuration, la gestion de ses règles et la consultation de ses logs.

ALS vient compléter SNORT pour n¶en former qu¶un seul système, IDS et analyseur

de logs. L¶installation et la configuration de SNORT sont détaillées à l¶Annexe D.

3. Résumé des difficultés rencontrées :

Difficultés liées à SNORTy Il a fallu chercher la version de SNORT qui supporte une base de données MySQL.

y La documentation de SNORT, disponible en téléchargement, n¶inclus que le système

d¶exploitation Linux. Il a donc fallu procéder par logique et des fois par tâtonnement

afin de pouvoir l¶installer correctement sur un environnement Windows.

y Il a fallu installer correctement les règles de détection et ensuite les définir dans le

fichier de configuration.

y Il a fallu aussi indiquer l¶emplacement qui va accueillir les logs, dans le fichier de

configuration.

Difficultés liées à la conception de l¶application





79

La décomposition de l¶application en plusieurs sous application s¶est opposé à la

qualité des diagrammes. Il a, donc, fallu généraliser et des fois décomposer les diagrammes

pour éviter l¶encombrement.

Difficultés liées au codage de l¶applicationy L¶utilisation des fenêtres internes (JInternalFrame) en Java à posé des soucis durant la

phase de codage, puisqu¶elles sont difficile à manuvrer.

y La communication en temps réel avec SNORT à imposé l¶utilisation d¶un thread qui

permet la récupération des données de la base afin de les analyser de façon claire et

sensé.

y SNORT utilise une façon bien particulière pour certaines information qu¶il récupère,

leur décodage à posé des problèmes qui ont demandés de l¶effort. A titre d¶exemple,

les adresses IP qu¶il récupère sont codées en Hexadécimal. Permet

4. Test de l¶application :

4.1. Présentation de « ALS » :

Comme son nom l¶indique, ALS, est un Analyseur de Logs pour S NORT. Il permet à ses

utilisateurs une manipulation automatisée de l¶IDS SNORT.

ALS admet les fonctionnalités suivantes :

La configuration de SNORT ;

La gestion des signatures de SNORT ;

L¶analyse des logs que génères SNORT ;

La gestion d¶une base de données commune à SNORT et ALS.

4.2. Tâches automatisés de SNORT :

L¶ajout de fichiers µBatch¶ a permis de rendre automatique certaines tâches tels que :

Le démarrage de SNORT qui est assuré par le fichier « test.bat » ;

L¶installation peut être faite à travers le fichier « install.bat » ;

Et enfin la désinstallation par le fichier « desinstall.bat ».

La figure qui suit, montre un exemple de code contenu dans le fichier permettant le démarrage

de SNORT.



ChapÎ

Ï

Ð e IV

Ñ L·app

Ò Î ca

Ï

Î on «

Ó

LÔ

»

Ó

naÒ

Õ Ö

euÐ

de LogÖ

pouÐ

Ô

× Ø Ù

Ú

Ø Û a

Ð Ü a

Ý

Ö

Þ Ò Ü

Ó

ß Þ L

80

F i à á â ã

IV.ä

å P

â æ à â ç mm

ç è i

æ é B

ç è ê ë

4.3. Authenti ication :

La première interface qui apparait, permet à un utilisateur ayant un accès de s¶authentif ier à

l¶aide d¶un identif iant µLogin¶ et µMot de passeµ (Figure IV.1). Si l¶identif iant est incorrecte

un message d¶erreur apparait, après trois tentatives échouées, l¶application se referme

automatiquement (Figure IV.2).

F i ì í î ï

IV.ð

ñ I

ò ó ï î ô õ ö ï

÷ ¶

õ í ó ø ï ò ó i

ô i

ö õ ó i

ù ò

÷ ï «

ú

LS »

Si l¶identif iant est incorrecte un message d¶erreur apparait ; Après trois tentatives échouées,l¶application se referme automatiquement (Figure IV.2).





81

Figure IV.3 : Identifiant incorrecte

4.4. Accueil :

En saisissant un identifiant et un mot de passe valides, l¶utilisateur peut accéder à la page

d¶accueil de ALS, lui permettant d¶approcher toutes les autres fonctionnalités. (Figure IV.3)

Figure IV.4 : Vue d¶ensemble





82

4.4.1. Démarrage de SNORT :

En démarrant SNORT, le voyant « etat de snort » passe du rouge au vert comme le montre la

figure ci-dessus (Figure IV.5).

Figure IV.5 : Etat de SNORT

4.4.2. Ecoute du trafic :

A son démarrage, SNORT commence à sniffer les paquets de données. La fenêtre qui assure

la fonctionnalité de l¶écoute est la suivante :

Figure IV.5 : Ecoute de SNORT

4.4.3. Choix de la sonde :

Le choix de l¶analyse peut se faire, à travers le choix d¶une sonde (s¶il en existe plusieurs).

Figure IV.6 : Analyse des sondes





83

4.4.4. Analyse des alertes :

On peut consulter les alertes d¶une manière générale,

Figure IV.7 :û

onsultation des alertes

En fonction des adresses IP source et destination :

L¶analyse peut se faire d¶une façon plus minutieuse et ceci en fonction des adresses IP source

et destination, à travers lesquels, un responsable réseau peut reconnaitre l¶origine de l¶attaque,

ainsi il peut prendre les décisions adéquates pour repousser l¶attaque.

Figure IV.8 :û

lassification des alertes selon les adresses IP





84

En fonction des ports TCP et UDP

L¶analyse, des ports impliqués dans les alertes, sert à indiquer d¶une manière plus précise la

cause de l¶attaque. Ainsi on peut fermer les ports susceptibles de donner un accès au réseau ou

aux ressources.

La figure qui suit permet au responsable du réseau de traquer les attaquants par leurs numérosde ports. Les graphes joints à chaque type de consultation, donneront une allure aux

statistiques des alertes.

Figure IV.9 :ü

lassification des alertes selon les ports source et destination

Analyse temporelle :Cette analyse permet de donner un aspect réparti des alertes suivant un intervalle de temps

que l¶utilisateur choisit. Ça peut être vu par heure, par jour, ou par mois.

Figure IV.10 : Analyse temporelle





85

4.5. Gestion des signatures :

La gestion des signatures, comporte la création, la suppression et la modification

(activation/désactivation des fichiers). Cette fonctionnalité comble l¶utilisateur en termes

d¶automatisation, puisque chaque activité est automatiquement ajoutée au fichier

« snort.conf » et chaque nouvelle règle créée, porte des changements au répertoire

« c:\snort\rules ».

Les figures qui suivent (Figures IV.11 jusqu¶à Figure IV.16) porteront l¶attentions aux

différentes facettes de la gestion des signatures.

Figure IV.11 : Edition d¶une signature

Figure IV.12 : Edition d¶une nouvelle signature à l¶aide de l¶assistant





86

Figure IV.13 : Ajout de fichiers de signatures

Figure IV.14 : Suppression de fichiers de signatures

Figure IV.15 : Activation désactivation de fichiers de signatures





87

Figure IV.16 : Activation désactivation de signatures d¶un fichier

4.6. Paramétrage de SNORT :

4.6.1. Configuration :

La configuration de SNORT se fait à travers un assistant inclus dans l¶application « ALS »,

tout enregistrement de configuration, fera diriger les informations vers le fichier

« snort.conf ».

Figure IV.17 :ý

onfiguration de SNORT





88

4.6.2. Installation et désinstallation :

L¶installation et la désinstallation, deux fonctionnalités guidées, indépendamment de « ALS »,

par des fichiers batch.

4.7. Paramétrage des utilisateurs :Cette fonctionnalité permet de supprimer, ajouter ou modifier un utilisateur. La figure qui suit

illustre ces trois cas possible.

Figure IV.18 : Gestion des utilisateurs

4.8. Gestion de la base de données :

4.8.1. Exécution de requêtes SQL :

Figure IV.19 : Execution de requêtes SQ þ





89

4.8.2. Vidage de la base de données :

Cette fonctionnalité n¶est accessible que pour un « super_utilisateur », avant son execution

elle est notifiée par un message de prévention Figure IV.20

Figure IV.20 : Vidage de la base de données

4.9. Aide :

L¶application comporte un menu d¶aide, pauvre en lui-même, mais qui offre une vision

génerale de « ALS ».

Figure IV.21 : A propos de ÿ A S ¡





90

5. Conclusion :

Ce chapitre a permis de dénombrer, succinctement, les fonctionnalités de « ALS », et ceci à

travers des schémas claire en provenance de captures d¶écrans.

Comme il a été défini à la conception, le logiciel « ALS » est maintenant conforme aux études

fonctionnelle et technique ; Ce dernier laisse, aux responsables réseaux ayant la crainte devant

la configuration manuelle de SNORT, une opportunité qui est celle de gérer toutes les

composantes liées à SNORT à travers une interface Homme-machine remarquable.



Conclusion


91

CONCLUSION

Le succès de la sécurité des réseaux diffère d¶une technologie à une autre ; il a vu naitre de

nouvelles solutions sécurisantes, comme il a apprécié la croissance distinguée dans larobustesse d¶autres.

Ce mémoire de fin d¶études ayant pour objectif, le développement d¶une application

complémentaire à l¶IDS SNORT et qui permet la gestion et l¶analyse des logs de ce dernier.

Cette application a été baptisée « ALS » relativement à Analyseur de Logs pour SNORT.

Offrant une multitude de fonctionnalités qui permettent une gestion complète de l¶outil

SNORT, dont ses règles, sa base de logs, et son mode de fonctionnement.

La définition d¶une première version de « ALS » exprime la possibilité de son développement

ultérieur en termes de qualité ou de fonctionnalités.Ce projet m¶a permis une exploration concrète des différentes facettes de la sécurité

informatique dont le piratage ainsi que les outils de détection et de prévention. L¶assiduité et

la disponibilité de mon parrain m¶ont fait gagner une forte confiance en soi et des ambitions

inégalés.

Arrivant à ces fins, qui s¶avèrent débutantes pour les perspectives d¶avenir, le projet « ALS »

a su défier les autres outils s¶orientant dans le même sens que lui, tel qu¶ACID.



Perspectives


92

PERSPECTIVES

Malgré ce qu¶offre « ALS » comme facilités pour gérer SNORT, on ne peuts¶empêcher de proposer une continuité à ce projet :

Intégration de « ALS » à la nouvelles de pare-feux, tels que

« smoothwall » ou l¶inéluctable « Endian » en leurs versions Open

Source.

Réécriture de « ALS » de telle façon qu¶il soit accessible via une interface

Web, tout en assurant l¶authentification qui s¶avère délicate dans ce cas.

Intégration de ¶iptables¶ à SNORT afin de le transformer en IPS et mettre

à jour « ALS » pour qu¶il puisse supporter ce nouveau mode de

fonctionnement.



Annexes


93

Annexes



Annexes


94

Annexe A : Protocoles réseaux [23]

Afin de mieux comprendre la détection d¶intrusion, ces procédés et technique, il faut bienconnaitre et savoir manipuler les protocoles réseau.Dans cette annexe il y aura définition des protocoles les plus utilisés.

A.1 Le protocole TCP

TCP est un protocole orienté connexion, c'est-à-dire qu¶il permet à deux machines quicommuniquent de contrôler l¶état de la transmission et ce à travers :

L¶ordonnancement des datagrammes en provenance du protocole IP ; La vérification des flots pour éviter la saturation du réseau ; Le formatage des données en segments de longueur variable afin de les remettre

au protocole IP ; Le multiplexage des données ; L¶initialisation et la fin de la communication de manière courtoise, etc.

Un segment TCP est constitué comme suit :

Figure A.1 : Format du segment TCP

La signification des différents champs est :

Port Source (16 bits): Port relatif à l'application en cours sur la machine source

Port Destination (16 bits): Port relatif à l'application en cours sur la machinede destination

Numéro d'ordre (ou séquence) (32 bits): Lorsque le drapeau SYN est à 0, lenuméro d'ordre est celui du premier mot du segment en cours.Lorsque SYN est à 1, lenuméro d'ordre est égal au numéro d'ordre initial utilisé pour synchroniser les numérosde séquence (ISN)



Annexes


95

Numéro d'accusé de réception (32 bits): Le numéro d'accusé de réceptionégalement appelé numéro d'acquittement correspond au numéro (d'ordre) du prochainsegment attendu, et non le numéro du dernier segment reçu.

Décalage des données (4 bits): il permet de repérer le début des données dans le paquet.

Le décalage est ici essentiel car le champ d'options est de taille variable

Réservé (6 bits): Champ inutilisé actuellement mais prévu pour l'avenir

Drapeaux (flags) (6x1 bit): Les drapeaux représentent des informationssupplémentaires :

o URG: si ce drapeau est à 1 le paquet doit être traité de façon urgente.o ACK: si ce drapeau est à 1 le paquet est un accusé de réception.o PSH (PUSH): si ce drapeau est à 1, le paquet fonctionne suivant la méthode

PUSH.o RST: si ce drapeau est à 1, la connexion est réinitialisée.o SYN: Le Flag TCP SYN indique une demande d'établissement de connexion.o FIN: si ce drapeau est à 1 la connexion s'interrompt.

Fenêtre (16 bits): Champ permettant de connaître le nombre d'octets que lerécepteur souhaite recevoir sans accusé de réception

Somme de contrôle (Checksum ou CRC): La somme de contrôle est réalisée en faisantla somme des champs de données de l'en-tête, afin de pouvoir vérifier l'intégrité del'en-tête

Pointeur d'urgence (16 bits): Indique le numéro d'ordre à partir duquell'information devient urgente

Options (Taille variable): Des options diverses

Remplissage: On remplit l'espace restant après les options avec des zéros pour avoir une longueur multiple de 32 bits

A.2 Le protocole IP

Le protocole IP (Internet Protocol) est à la base des communications sur Internet. Ilimplémente deux tâches de base : la fragmentation et l¶adressage.La fragmentation consiste à « briser » les données en petits paquets appelésdatagrammes. Cette opération est nécessaire avant d¶envoyer les données sur le réseau. Bien

entendu, au niveau du récepteur, il faut faire l¶opération inverse afin de reconstituer les données. En ce qui concerne l¶adressage, il s¶agit de transmettre les datagrammes jusqu¶au destinataire. Notons que le protocole IP transmet les données sans garantie deremise. Autrement dit, lorsqu¶on envoie un datagramme IP sur le réseau, rien ne peut nousassurer que celui-ci se rendra bel et bien à destination.



Annexes


96

Un segment IP est constitué comme suit :

Figure A.2 : Format du segment IP (version 4)

Voici la signification des différents champs :

Version (4 bits) : il s'agit de la version du protocole IP que l'on utilise(actuellement on utilise la version 4 IPv4) afin de vérifier la validité du datagramme.Elle est codée sur 4 bits.

Longueur d'en-tête, ou IHL pour Internet Header Length (4 bits) : il s'agit du nombrede mots de 32 bits constituant l'en-tête (nota : la valeur minimale est 5). Ce champ estcodé sur 4 bits.

Type de service (8 bits) : il indique la façon selon laquelle le datagramme doit êtretraité.

Longueur totale (16 bits): il indique la taille totale du datagramme en octets. Lataille de ce champ étant de 2 octets, la taille totale du datagramme ne peutdépasser 65536 octets. Utilisé conjointement avec la taille de l'en-tête, ce champ

permet de déterminer où sont situées les données.

Identification, drapeaux (flags) et déplacement de fragment sont des champs qui permettent la fragmentation des datagrammes, ils sont expliqués plus bas.

Durée de vie appelée aussi TTL, pour Time To Live (8 bits) : ce champ indique le

nombremaximal de routeurs à travers lesquels le datagramme peut passer. Ainsi ce champ estdécrémenté à chaque passage dans un routeur, lorsque celui-ci atteint la valeur critique de 0,le routeur détruit le datagramme. Cela évite l'encombrement du réseau par lesdatagrammes perdus.

Protocole (8 bits) : ce champ, en notation décimale, permet de savoir de quel protocoleest issu le datagramme

ICMP : 1 IGMP : 2 TCP : 6 UDP : 17



Annexes


97

Somme de contrôle de l'en-tête, ou en anglais header checksum (16 bits) : cechamp contient une valeur codée sur 16 bits qui permet de contrôler l'intégrité del'en-tête afin de déterminer si celui-ci n'a pas été altéré pendant la transmission. Lasomme de contrôle est le complément à un de tous les mots de 16 bits de l'en-tête(champ somme de contrôle exclu). Celle-ci est en fait telle que lorsque l'on fait la

somme des champs de l'en-tête (somme de contrôle incluse), on obtient un nombreavec tous les bits positionnés à 1

Adresse IP source (32 bits) : Ce champ représente l'adresse IP de la machineémettrice, il permet au destinataire de répondre

Adresse IP destination (32 bits) : adresse IP du destinataire du message

A.3 Le protocole UDP

Un segment UCP est constitué comme suit :

Figure A.3 : Format du segment UDP

La signification des différents champs est la suivante :

Port Source: il s'agit du numéro de port correspondant à l'application émettrice dusegment UDP.

Port Destination: Ce champ contient le port correspondant à l'application de lamachine destinataire à laquelle on s'adresse.

Longueur: Ce champ précise la longueur totale du segment, en-tête comprise,

Somme de contrôle: Il s'agit d'une somme de contrôle réalisée de telle façon à

pouvoir contrôler l'intégrité du segment.



Annexes


98

A.4 Le protocole ICMP :

Voici à quoi ressemble un message ICMP encapsulé dans un datagramme IP :

Figure A.4 : Un message ICMP encapsulé dans un datagramme IP





Annexes


100

B.3 Les vers [2]

Un ver est un programme complet (ou un ensemble de programmes) capable de se multiplier en plusieurs copies fonctionnelles ou de dupliquer ses segments sur d¶autres systèmesinformatiques en règle générale à travers un réseau. Contrairement aux virus, les vers n¶ont

pas besoin de programme hôte. Il existe deux types : les vers de station de travail et les versde réseau.

Les vers de station s¶attaquent à un seul système et utilisent les connexions réseau pour se copier sur toutes les machines du réseau. On parle à leur propos de « lapins » par analogie avec l¶animal prolifique. Les vers de réseau sont constitués de plusieurs segments, tournant chacun sur unemachine différente. Le réseau constitue alors un support de communication et de

propagation. Certains vers possèdent un segment principal qui coordonne les actionsdes autres segments ou sous-segments. Ce type de vers est appelé « pieuvre » par analogie avec cet animal tentaculaire.

B.4 Les virus créés sous Visual Basic [2]

Toutes les applications Microsoft sont liées les uns aux autres par leur langage de programmation Visual Basic et son dérivé VB script. Ce fait a poussé certains à écrire desvirus macros en utilisant les mêmes logiciels.

Les plus célèbres sont : I Love You: une fois en contact avec Outlook, logiciel de gestion de courrier électronique de l¶ensemble Office, il lui commande d¶envoyer une copie du messageauquel il est attaché à chacune des adresses du répertoire.

Melissa : Célèbre par ces ravages en 2002, lui, attaque les fonctions d¶automatisationdu traitement de texte Word. D¶autres virus se sont transmis via le tableur MicrosoftExcel.

B.5 Les wabbist [22]

Ce sont des programmes conçus pour épuiser les ressources d¶un système (Horloge CPU,RAM, Espace disque, ). Contrairement aux virus et aux vers, ils n¶infectent pas les fichierset ne se propagent pas à travers le réseau. Ils tournent en boucle infinie en créant de nouvellestâches (par exemple variables) qui saturent la mémoire et provoquent l¶erreur.



Annexes


101

Annexe C : Politiques de sécurité adoptées après une mission

d¶Audit

La notion de sécurité devient une obligation vu l¶importance des flux communiquésdans les réseaux informatiques. La mise au point d¶une politique de sécurité passe tout

d¶abord par une étape d¶analyse des risques qui se fait selon plusieurs méthodologies. Dans cequi suit, nous présentons quelques méthodes considérées parmi les plus répandues.

C.1 MEHARI [10] Mehari (MEthode Harmonisée d'Analyse de RIsques) est dévelopée par le CLUSIF (Club dela Sécurité des Systèmes d'Information Français) depuis 1995, elle est dérivée des méthodesMelisa et Marion. Existant en langue française et en anglais, elle est utilisée par denombreuses entreprises publiques ainsi que par le secteur privé.La démarche générale de Mehari consiste en l'analyse des enjeux de sécurité : quels sont lesscénarios redoutés, et en la classification préalable des entités du SI en fonction de troiscritères de sécurité de base (confidentialité, intégrité, disponibilité). Ces enjeux expriment lesdysfonctionnements ayant un impact direct sur l'activité de l'entreprise. Puis, des audits

identifient les vulnérabilités du SI. Enfin, l'analyse des risques proprement dite est réalisée.

Figure C.1 : Schéma général de la méthode MEHARI

Mehari s'articule autour de 3 types de livrables :

1. le Plan Stratégique de Sécurité (PSS)2. les Plans Opérationnels de Sécurité (POS)3. le Plan Opérationnel d'Entreprise (POE)

C.2 COBIT [11] La méthode Control OBjectives for Information and related Technology (en françaisobjectifs de commande pour information et la technologie relative) est un ensemble desmeilleures pratiques mondiales en audit et maîtrise des systèmes informatiques.



Annexes


102

Créé par l'association d'audit et de commande de systèmes d'information (ISACA) en1992, le COBIT aide les dirigeants à comprendre et à gérer les risques relatifs àl¶informatique et fait le lien entre les processus de gestion, les questions techniques,les besoins de contrôle et les risques.

Le modèle COBIT décompose tout système informatique en 34 processus regroupés en 4

domaines :

� Planification et organisation :- Couvre la stratégie et les tactiques ;- Concerne l¶identification des moyens permettant à l¶informatique de contribuer à laréalisation des objectifs commerciaux de l¶entreprise.

� Acquisition et mise en place : concerne la réalisation de la stratégie informatique,l¶identification, l¶acquisition, le développement et l¶installation des solutions informatiqueset leur intégration dans les processus commerciaux.

� Distribution et Support : concerne la livraison des prestations informatiques exigées, ce

qui comprend l¶exploitation, la sécurité, les plans d¶urgence et la formation.

� Surveillance : permet au management d¶évaluer la qualité et la conformité des processusinformatiques aux exigences de contrôle.

C.3 EBIOS [10] EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) permet d'identifier les risques d'un SI et de proposer une politique de sécurité adaptée aux besoins de l'entreprise(ou d'une administration). Elle a été créée par la DCSSI (Direction Centrale de la Sécurité desSystèmes d'Information), du Ministrère de la Défence (France). Elle est destinée avant toutaux administrations françaises et aux entreprises.

La méthode EBIOS se compose de 5 guides (Introduction, Démarche, Techniques,Outillages) et d'un logiciel permettant de simplifier l'application de la méthodologie explicitéedans ces guides. Le logiciel libre et gratuit (les sources sont disponibles) permet de simplifier l'application de la méthode et d'automatiser la création des documents de synthèse. La DCSSI

possède un centre de formation où sont organisés des stages à destination desorganismes publics français. Un club d'utilisateurs EBIOS a été créé en 2003 etconstitue une communauté experts permettant le partage des expériences. Une base deconnaissances à laquelle se connecte le logiciel EBIOS permet d'avoir à accès à ladescription d'un ensemble de vulnérabilités spécifiques, de contraintes de sécurité, deméthodes d'attaques. Elle peut être enrichie via le logiciel.

La méthode EBIOS est découpée en 5 étapes :1. étude du contexte : Vision globale et explicite du système étudié, des enjeux, descontraintes et référentiels applicables.

2. expression des besoins de sécurité : Positionnement des éléments à protéger (patrimoine informationnel) en terme de disponibilité, intégrité, confidentialité et miseen évidence des impacts en cas de sinistre.



Annexes


103

3. étude des menaces : Recensement des scénarios pouvant porter atteinte auxcomposants (techniques ou non) du SI.

4. identification des objectifs de sécurité : Mise en évidence des risques réels etexpression de la volonté de les traiter en cohérence avec le contexte particulier del¶organisme.

5. détermination des exigences de sécurité : Spécification des mesures concrètes à mettre enuvre pour traiter les risques sur la base d¶une négociation argumentée.

Figure C.2 : Démarche EBIOS globale

C.4 MARION [10] Marion (Méthodologie d'Analyse de Risques Informatiques Orientée par Niveaux) a étédéveloppée par le CLUSIF dans les années 1980 mais a été abandonnée en 1998 au

profit de la méthode Mehari. C'est une méthode d'audit de la sécurité d'une entreprise, elle ne permet pas de mettre en oeuvre une politique de sécurité en tant que tel. A base d'unquestionnaire, elle donne une évaluation chiffrée du risque informatique.Marion repose sur l'évaluation des aspects organisationnels et techniques de la sécurité del'entreprise à auditer.Elle utilise 27 indicateurs classés en 6 thématiques. Chaque indicateur se voit attribuer unenote entre 0 (insécurité) et 4 (excellent), la valeur 3 indiquant une sécurité correcte.

Thématiques des indicateurs de la méthode Marion� Sécurité organisationnelle� Sécurité physique� Continuité� Organisation informatique� Sécurité logique et exploitation� Sécurité des applications



Annexes


104

La méthode se déroule en 4 phases :

1. Préparation : définir les objectifs de sécurité à atteindre ainsi que le champs d'action del'audit et le découpage fonctionnel du SI à adopter pour simplifier la réalisation del'étude.

2. Audit des vulnérabilités : consiste à répondre aux questionnaires. Ces réponsesdonnées vont permettre de recenser les risques du SI et les contraintes de l'entreprise.

3. Analyse des risques : permet de classer les risques selon leur criticité (en classes :Risques Majeurs et Risques Simples). Elle procède au découpage fonctionnel du SI pour une analyse détaillée des menaces, de leur impact respectif et de leur probabilité.

4. Plan d'action : propose les solutions à mettre en uvre pour élever la valeur des 27indicateurs à la valeur 3 (niveau de sécurité satisfaisant) de l'audit des vulnérabilités etatteindre les objectifs fixés en préparation.

C.5 Tableau récapitulatif

Le tableau suivant liste les principales normes utilisées:

Nom Signification Origine CaractéristiquesMEHARI MEthode

Harmoniséed¶Analyse desRisques

CLUSIF Succède à la méthodeMarion.S'articule autour de 3 plans.Permet désormais d'apprécier les risques au regard desobjectifs "business" del'entreprise.

COBIT ControlObjectives for InformationandTechnology

ISACA Méthode accessible à tous,dans un langage simple. Lesoutils fournis permettent lamesure des performancesmais la méthode estaujourd'hui davantageassimilée à une méthode degouvernance des SI.

EBIOS Expression desBesoins etIdentificationdes Objectifs de

Sécurité.

DCSSI Notamment déployée ausein de l'administrationfrançaise, cette méthodecomprend une base de

connaissances et un recueilde bonnes pratiques. Elleest téléchargeable sur le sitede la DCSSI et s'accompagned'un logiciel.

MARION Méthodologied¶Analyse desRisquesInformatiques

CLUSIF Fonctionne par questionnairesdébouchant sur 27 indicateursrépartis en



Annexes


105

Orientée par Niveaux

6 catégories. 2 phases(audit desvulnérabilités et analyse desrisques)

permettent la définition etla mise en

oeuvre de plans d'actions personnalisés.

Tableau C.1 : Résumée des normes utilisées dans le domaine de la sécurité

Remarque :Bien que ces méthodologies ont un grand succès dans le domaine de la sécurité, ellesne se réfèrent pas, néanmoins, à un standard commun. Contrairement, par exemple, à la normeISO/CEI 27002 qui est une norme internationale concernant la sécurité de l'information,

publiée en juillet 2007 par l'ISO et qui définit douze domaines (Articles) de sécurité del'information constituant au total 41 catégories (objectifs de sécurité).



Annexes


106

Annexe D : Installation et Configuration de Snort

SNORT est un IDS Open Source disponible en téléchargement à l¶adresse « www.snort.org »,il est destiné à fonctionner dans des réseaux de type IP. Cette Annexe saura satisfaire les

manques, en termes d¶installation et de configuration, que pose SNORT.D.1 Installation

L¶installation passe par plusieurs étapes à savoir :

Installation de l'outil SNORT ; Installation de WinPcap ; Installation des règles SNORT ; Configuration de snort.conf ; Liaison Mysql et SNORT ; Installation d¶ACID.

D.1.1 Les paquetages nécessaires

On peut aussi bien installer SNORT sous Windows que sous Linux. La procédured¶installation et les techniques de configuration changent bien sûr mais le fonctionnement deSNORT reste lui-même.

Remarque : Pour ce qui va suivre, il y aura l¶installation dédiée à Windows.

Les packages installés au cours du projet sont les suivants :

o

SNORT 2.8.4.1o WinPcap 3.1o EasyPHP 2.0b1 Contient : Apache ; MySQL ; PHP ; PHPmyAdmin.o ntwdblib.dll à télécharger puis à copier dans c:\snort\bin

NB : ntwdblib.dll est la bibliothèque SQL Server spécifique au client (SQL Server

Client library), elle est en téléchargement libre sur Internet.

D.1.2 Configuration

D.1.2.1 Configuration de MySQLOn commence tout d¶abord par créer la base de données `snort` dans « phpmyadmin ».

Par la suite, il y aura création des tables de Snort dans la base de données Snort selon lescript SQL fourni avec le package Snort qui se trouve dans« C:\Snort\schemas\create_mysql.sql », en explorant ce fichier à l¶aide du Bloc-Notes et encopiant toutes les requêtes dans le champ qui apparait lorsqu¶on clique sur SQL dans la basede donnée `snort` déjà créée comme le montre la figure « Figure D.1 : SQL dans

PHPmyAdmin » on obtiendra 16 tables, dont celle qui va accueillir les alertes qu¶il va stocker.



Annexes


107

Figure D.1 : SQL dans PHPmyAdmin

D.1.2.2 Configuration de SNORT

Afin de détecter les intrusions, SNORT utilise des règles qui sont téléchargeables à partir du site « http://www.snort.org ». Il faut placer ces règles d¶extension «.rules » dans le dossier de Snort selon le chemin suivant : « C:\Snort\rules ».

F onctionnement des règles

Les règles de Snort sont décrites dans un langage simple et sont composées de deux parties comme suit :

L'en-tête de règle (header) qui contient L'action de la règle Le protocole qui est utilisé pour la transmission des données (TCP, UDP et

ICMP); Les adresses IP source et destination et leur masque; Les ports source et destination sur lesquels il faudra vérifier les paquets.

Les options de la règle (doivent être écrites entre parenthèses) qui contiennent Le message d'alerte; Les conditions qui déterminent l'envoi de l'alerte en fonction du paquet inspecté.

Voici un exemple de règles :alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"Ping Windows

détecté"; content:" ISSPNGRQ´; depth:16;);

F ichier de configuration de Snort

Le fichier de configuration de SNORT se trouvant dans le dossier «C:\Snort\etc\snort.conf» doit être mis à jour comme suit :

Définir la classe d'adresses du réseau ou bien mettre la valeur par défaut :

# Valeur pour un réseau en 192.168.0.xvar HOME_NET 192.168.0.0/24# Valeur par défautvar HOME_NET any



Annexes


108

Donner le chemin complet du répertoire de règles :var RULE_PATH c:\snort\rules

Activer la ligne suivante :

output alert_syslog: host=hostname, LOG_AUTH LOG_ALERT

Modifier les paramètres de sortie (output) pour que Snort journalise dans la base MySQL :output database: log, mysql, user=root dbname=snort host=localhost

Inclure les fichiers de configuration suivants:include classification.configinclude reference.config

Activer ou désactiver les règles voulues afin de spécifier le niveau de sécurité souhaité

Activer la ligne suivante :include threshold.conf

D.2 Lancement de Snort

Avant de lancer Snort, il est utile de spécifier l¶interface qu¶il va utiliser pour l¶analyse.Pour ce faire, il faut ouvrir une fenêtre de commande DOS et se déplacer dans lerépertoire« bin » du dossier d'installation de Snort. L¶option « -W » (en majuscule) permet,sous Windows seulement, de lister ces interfaces comme le montre la figure suivante:

Figure D.2 : Spécification de l¶interface réseau à utiliser



Annexes


109

M odes d¶utilisation de SNORT :

Mode Sniffer

snort ±v : Cette commande permet d¶exécuter et d¶afficher les entêtes des paquetsTCP/IP.

snort ±vd : Cette commande permet d¶exécuter Snort et d¶afficher tout le paquet

TCP/IP (entête et données). snort ±vde : Cette commande permet d¶exécuter Snort et d¶afficher tout le paquet

TCP/IP (entête et données) ainsi que de l¶entête de la couche liaison de données.

Mode Logger (log de paquet) Ce mode est presque similaire au précédent avec la possibilité d¶enregistrer les logsdirectement dans un fichier de logs dont il faut préciser le chemin complet.SNORT offre également la possibilité d¶enregistrer directement un fichier binaire, ce qui

permet d¶enregistrer les données sous une forme compressée. La lecture d¶un tel fichier binaire peut se faire avec un logiciel tel que tcpdump.La commande est écrit donc comme la suivante : snort ±vde ±l c:\snort\log ±b ±i2

Mode NIDS (Mode de détecteur d¶intrusion réseau) Ce mode nécessite, contrairement aux autres, l'utilisation du fichier de configuration deSNORT (dans le quel nous avons déjà inclus les noms des règles souhaitées). SNORT vaanalyser les paquets, comparer le trafic à des règles prédéfinies par l¶utilisateur et réagir ainsià d¶éventuelles tentatives d¶intrusions qu¶il détecterait. La commande est la suivante :snort ±vde ±A full ±c c:\snort\etc\snort.conf ±l c:\snort\log ±i2

La figure suivante montre le fonctionnement de Snort en mode NIDS :

Figure D.3 : Fonctionnement en mode NIDS









Annexes


113

if(argc<4) {printf("Generateur de motif dans le fichier fic.txt\n");printf("Usage : %s fic.txt taille(Mo) motif 1 [motif2] [motif3] ... \n",argv[0]);exit(1);

}int nbMot = argc - 3;

char *dest = argv[1];int size = atoi(argv[2]);

srand(time(NULL));

char car[] = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm','n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'};mots = (char**) malloc(sizeof(char*)*nbMot);printf("Ajout de %d mot(s) dans le fichier\n",nbMot);for(alpha=3;alpha<argc;alpha++){

strcpy(buffer,argv[alpha]);mots[alpha-3] = (char*) malloc(sizeof(char)*(1+strlen(buffer)));strcpy(mots[alpha-3], buffer);

}int pos[nbMot];

for (i = 0; i < nbMot; i++) {pos[i] = (int) (rand() / (double) RAND_MAX * ((size*1000000)-10));}triSelection(pos, nbMot);file = fopen(dest, "w");int nbAlea, nbChar;for (nbChar = 0, i = 0; nbChar * sizeof(char) < (size*1000000); ) {

if (pos[i] == nbChar) {printf("Ajout du mot %s en position %d dans le texte\n",mots[i],pos[i]);fprintf(file, "%s", mots[i]);nbChar += strlen(mots[i]);if (i < nbMot) {

i++;}

} else {nbAlea = (int)(rand() / (double)RAND_MAX * (sizeof(car) - 1));fprintf(file, "%c", car[nbAlea]);nbChar++;

}}fclose(file);printf("Le fichier %s a ete correctement genere\n",dest);return 0;

}



Bibliographie & Webographie


114


[1] : Livre « La sécurité des réseaux First-Step » (cisco press et Campus press) -2004-

Auteur : Tom Thomas

[2] : Livre « La sécurité sur Internet » (LAVOISIER) -2005- Auteurs : Henri Ly et Zouheir

Trabelsi

[3] : Site web http://www.grappa.univ-lille3.fr/polys/systreseaux/ch01s02.html

[4] : Dictionnaire Le Petit Larousse (Grand format) -1995-

[5] : Site web

www.metz.supelec.fr/~vialle/course/SI/ntiers/remi.leblond.free.fr_probatoire_probatoire.pdf

[6] : Site web http://www.kh.refer.org/cours_en_lignes/cours_reseau/Page/chap1_lecon5.htm[7] : Site web http://www.ssi.gouv.fr/fr/documentation/650/650.pdf

[8] : Site web www.guideinformatique.com

[9] : Site web www.alaide.com

[10] : Site web http://cyberzoide.developpez.com/securite/methodes-analyse-risques/

[11] : Site web http://www.adele.gouv.fr/it06/leblog/wp-content/cobit.pdf

[12] : Livre « Réseaux bayésiens naïfs et arbres de décision dans les systèmes de détection

d¶intrusions » Volume 25 ± n°2/2006, pages 167 à 196 Auteurs: Nahla Ben Amor, Salem

Benferhat, Zied Elouedi, RSTI-TSI,[13] : Site web www.snort.org

[14] : Site web www.bro-ids.org

[15] : Site web www.ossir.org/resist/supports/cr/200205/ids-logs.pdf

[16] : Site web http://www.prelude-ids.org/

[17] :Site web http://actes.sstic.org/SSTIC03/Profils_propres/SSTIC03-article-Bouzida-

Profils_propres.pdf

[18] : Site web http://dbprog.developpez.com/securite/ids/IDS.pdf

[19] : Site web http://www.supelec-rennes.fr/rennes/si/equipe/lme/[20] : Site web http://papini.univ-tln.fr/sources/MASTER2-PRO/cours-log-sec-4.pdf

[21] : Site web http://www-igm.univ-mlv.fr

[22] : Livre « Hacker¶s Guide » CampusPress -2004- Auteur : Eric Charton

[23] : Site web www.commentcamarche.net

[24] : Site web http://www.agrojob.com/dictionnaire/definition-uml-3870.html





115

[25] : Livre « UML en action » Groupe Eyrolles -2003- Chapitre 2 Auteurs: Pascal Roques et

Franck Vallée

[26] : Rapport de Projet de Fin d¶Etudes Aos Aouini ISSAT-Sousse 2007



Documents

Rapport 23-05-2009 CopieFINALE