Vous êtes sur la page 1sur 116

Table des matières 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 :_____________________________________________________14
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] :________________________________________________________________17
2.2.4. Protocoles [7] :_________________________________________________________________17
3. La sécurité des systèmes d’informations___________________________________________18
3.1. Vulnérabilités et risques :____________________________________________________________19
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 :_______________________________________________________20
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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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_____________________________________________________________35
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]_____________________________________________________57
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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Liste des figures 5

Figure IV.3 : Identifiant incorrecte_____________________________________________________________81


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Introduction générale 8

Liste des abréviations

ALS  : Analyseur de Logs pour SNORT


IDS  : Intrusion Detection System
IPS  : 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Introduction générale 9

Introduction générale

Le présent rapport entre dans le cadre de la réalisation d’un mémoire de projet de fin
d’é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).

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Introduction générale 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 une
varié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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Introduction générale 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre I : La sécurité des réseaux informatiques 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 une
dé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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

2. Les réseaux informatiques :

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 (centre
europé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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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


d'utilisateurs dans 146 pays » [3].

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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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


est moins facile à assurer.

 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 une
architecture N -tiers.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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:

 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 nœud central de haut


niveau est connecté à plusieurs nœuds 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

 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
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.

2
3
4
5

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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
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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

3.1.4. Les risques informatiques :


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

«  Risques humains

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 

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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.

 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 cœur 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 le

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

niveau 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

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 ordre
alé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 cette
technique IP protocol scan.

3.2.4. Remote to Local access (R2L) [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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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

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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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é.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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ées
transitant 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 (HoneyPot)

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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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 si
l’utilisation de l’un des deux suffit pour assurer la sécurité du système.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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.

Internet

Pare-feu
IDS SNORT

Switch

Workstation Workstation Workstation Workstation

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.

Internet

IDS SNORT

Pare-feu

Switch

Workstation Workstation Workstation Workstation

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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.

Internet
IDS SNORT

Mainframe

Pare-feu

Servers

DMZ Switch

Workstation Workstation Workstation Workstation

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.

IDS SNORT IDS SNORT

Mainframe Internet

Pare-feu

Servers
IDS SNORT

DMZ Switch

Workstation Workstation Workstation Workstation

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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 comportement
actuel 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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 une
généralisation de l’algorithme Knuth-Morris et Pratt, sa particularité réside dans la
recherche parallèle de plusieurs motifs.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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

- Pas besoin d’une base d’attaques. - Prise en compte des comportements


exacts des attaquants potentiels :
- Détection d’intrusions inconnues
Avantages
possible.  peu de faux positifs

« Rien n’est jamais sûr ! »

- Pour un utilisateur au - Base de scénarios, difficile à


comportement erratique (irrégulier), construire et à maintenir :
toute activité est normale.
 risque de faux négatifs
- En cas de profonde modification
de l’environnement du système cible,
déclenchement d’un flot ininterrompu - Pas de détection d’attaques non
d’alarmes : connues :
Inconvénients
 gros risque de faux positifs  risque de faux négatifs

- Utilisateur pouvant changer


lentement de comportement afin - Détection de scénarios complexes
d’habituer le système à un difficile.
comportement intrusif :

 risque de faux négatifs

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 »

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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 :

ETHERNET

Packet Pre Detection Loging and


Decoder Processor Engine alerting
system

Output
Packet plugins
Is dropped Output Alert
or log to a file

Figure II.5 : Architecture de Snort

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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 plus
loin encor avec l’application « ALS ».

1 : Capture des paquets


APPLICATION « ALS » 2 : Analyse des paquets
4

3 : Enregistrement dans la
5

SNORT base de données


2 WinPcap
4 : Configuration de
SNORT par « ALS »,
Système démarrage/arrêt, retour
des résultats.
1

D’exploitation 3
5 : Analyse des logs
Base de données enregistrés dans la base
de données

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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 selon
certains 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 du
trafic, 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 ses
composants 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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 des
activité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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

6.3. Comparatif Snort, Prelude et Bro :

Critères Snort Prelude Bro

Année de création 1998 1998 1998

Auteur Martin Roesch Yoann Vern Paxson


Vanndoorselaere

Licence Open source Open source Open source

Plateforme Toutes les plateformes Linux, FreeBSD et Unix


Windows

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

Difficulté de Moyenne, nécessite Facile Facile grâce à un script


Configuration des compétences interactif

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


informations

Moteur d’analyse Confrontation avec une Confrontation avec une Confrontation avec une
base des signatures base des signatures base des signatures

Informations dans les Alertes bien détaillées Alertes bien détaillées Alertes mal détaillées
alertes

Popularité (Nombre Très populaire (grand Popularité moyenne Un peu


de téléchargements) nombre) (nombre moyen)

Intégration d’outils Ne permet pas Permet l’intégration Permet l’intégration


externes l’intégration d’outils

Documentation Très bien documenté Peu de documentation Peu de documentation


et avec des erreurs

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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre II : Les systèmes de détection d’intrusions 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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 se
chapitre. 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.

 « 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.

 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

 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.

 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.

 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 Unified
Process », 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 :


 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é.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

 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 :
 La capture des besoins techniques, qui recense toutes les contraintes et les choix
dimensionnant 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 ;
 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 :
 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 ;
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
 L’étape de codage, qui produit ces composants et teste au fur et à mesure les unités de
code réalisées ;
 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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 son
adaptation 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 »

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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]

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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 mode interpréteur SQL, et
aussi ajouter/supprimer des utilisateurs.

 Network_manager : Cet acteur peut gérer SNORT, dont ses signatures et 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 de fonctionnalités en vue, il


ne peut consulter que les statistiques et les données qui leurs correspondent.

Liste préliminaire des cas d’utilisations :

Cas d’utilisation Acteurs Messages

Consulter les statistiques Super_user Requêtes SQL


Network_manager
User_without_privileges
S’authentifier Super_user Requêtes SQL
Network_manager
User_without_privileges
Gérer les signatures Super_user Message de modification
Network_manager d’état
Editer un rapport d’audit Super_user Message de demande d’état
Network_manager
Gérer la base de données Super_user Requêtes SQL
Network_manager
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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.3 : Diagramme des cas d’utilisations

Remarque : pour le reste des diagrammes concernant cette section, tous les acteurs
seront représentés par un seul, ayant pour nom ACTEUR (Figure III.4 : Acteurs du
système).

Figure
III.4 : Acteur

Acteurs du
système

Diagramme
de
séquences

A ce stade,
les Super-user Network_manager User_without_privilege

fonctionnalités du système sont celle principalement 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 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

ALS Base de
données

Acteur

Demandes par des instructions

Requêtes SQL

Réponses par affichage ou modification

Réponses concernant l'état ou la modification d'état

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]

Diagramme de séquences

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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.

S'authentifier

L'accès aux fontionnalités


(Consulter , Gérer , Modifier)
se fait selon les privilèges que
Accéder aux différentes fonctionnalités de l'application possèdent les différents
utilisateurs

Deconnexion

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.
La classe « Auth » : Assure l’accès aux différents utilisateurs selon les privilèges que chacun
d’eux possèdent.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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 :

Auth

Start

Sqlbd Paramsnort

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 un
diagramme d’état. (Figure III.8)

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Récuperation de l'identité de l'utilisateur


Deconnexion de l'utilisateur en cours

[Notifier
le refus]

[Accéder à l'application]

Etablissement des paramètres de SNORT

[Etablir un nouveau
[Déconnexion] profil pour consulter
les alertes]

[Accès aux fonctionnalités]

Démarrer SNORT

Choix pour solliciter les alertes enregistrées

Ecoute du trafic réseau [ Visualiser


les alertes ]

Comparer le flux de données aux signatures d'attaques


[Aucune alerte]

[ Détecter des flux


de données corrompues]
Enregistrement dans la table `log` de la BD

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

4.2. Analyse technique :


4.2.1. Capture des besoins techniques :

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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 comportant
des 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 :

Saisir login
Consulter les
statistiques
«include»
«include»
«extends» «extends» Saisir mot de passe
«include»
Acteur

S'authentifier
Choisir le type de Choisir les
statistiques critères d'affichage

«include»

«include»
Editer un rapport
d'Audit
Network_manager User_without_privilege
Super-user

Gérer les
signatures «include»

«include»

Créer Ajouter Modifier Supprimer


Network_manager
«extends»
«extends» «extends»
«extends»

Supprimer les
Supprimer la
fichiers des signatures
Modifier les Modifier les signature
fichiers des signatures signatures

Confiurer
l'application
«extends»
«extends»
Gérer la base de
Super_user données
Configurer le
tableau de bord
Configurer le
lancement de SNORT

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

4.2.2. Conception générique :

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


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.

ALS SNORT

API API

IHM Interface_Réseau

Ethernet
Acteur

Base_de_données Base_de_données

BD

Figure III.13 : Diagramme de déploiement

4.3. Conception :
Afin d’entamer la phase de conception qui consiste à fusionner notre étude
fonctionnelle 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

4.3.1. Conception préliminaire :

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

Diagramme de classes
Vue 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.

Authentification Base de données

Gérer les signaturer

Consulter les alertes

Accueil Consulter les statistiques

Analyse temporelle

Gérer et configurer SNORT

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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre III : Atelier de génie logiciel & Conception 2TUP 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 :

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

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

Dans cette partie, les concepts provenant de l’analyse vont être transformés en techniques
disponibles selon les outils et langages de développement conventionnés.
La conception des associations, trainera les classes participantes 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 attributs se voit principalement définir le type et la visibilité des attributs.
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 attributs.

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.

Figure III.17 : La classe Main

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.18 : La classe Panel

Figure III.19 : La classeLance

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.20 : La classe Start

Figure III.21 : La classe Auth

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.22 : La classeSqlbd

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.23 : La classe Abds

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.24: La classe Videbd

Figure III.25 : La classe User

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.26 : La classe Aalerte

Figure III.27 : La classe Calerte

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.28 : La classe Atemp

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.29 : La classe Aport

Figure III.30 : La classe Aprdst

Figure III.31 : La classe Aprsrc

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.32 : La classe Aprotocol

Figure III.33 : La classe Apudp

Figure III.34 : La classe Aptcp

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.35 : La classe Asonde

Figure III.36 : La classe Ajoutr

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.37 : La classe Assieditr

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.38 : La classe Editr

Figure III.39 : La classe Modiffr

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.40 : La classe Modifr

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.41 : La classe Suppr

Figure III.42 : La classe Suppfr

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.43 : La classe Paramsnort

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.44 : La classe Ageneral

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Figure III.45 : La classe Rapport

5. Conclusion :

La conception de « ALS » a suivi un processus de renommé dans le domaine du


développement logiciel. Le processus 2TUP a permis de Spécifier les contraintes
fonctionnelles et techniques, sur les quelles s’est basé la conception. Cette méthodologie a
donnée une forme préliminaire modélisée en diagrammes UML, facilitant la tâche du codage.

Le chapitre suivant, intitulé « L’application ALS » permet de comprendre le


fonctionnement de l’application, et ce à travers des schémas bien détaillés.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 77

Chapitre IV : L’application « A L S »

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 de


SNORT, 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 à SNORT


 Il a fallu chercher la version de SNORT qui supporte une base de données MySQL.
 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.
 Il a fallu installer correctement les règles de détection et ensuite les définir dans le
fichier de configuration.
 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 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’application


 L’utilisation des fenêtres internes (JInternalFrame) en Java à posé des soucis durant la
phase de codage, puisqu’elles sont difficile à manœuvrer.
 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é.
 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 SNORT. 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 80

Figure IV.1 : Programmation Batch

4.3. Authentification :
La première interface qui apparait, permet à un utilisateur ayant un accès de s’authentifier à
l’aide d’un identifiant ‘Login’ et ‘Mot de passe‘ (Figure IV.1). Si l’identifiant est incorrecte
un message d’erreur apparait, après trois tentatives échouées, l’application se referme
automatiquement (Figure IV.2).

Figure IV.2 : Interface d’authentification de « ALS »


Si l’identifiant est incorrecte un message d’erreur apparait ; Après trois tentatives échouées,
l’application se referme automatiquement (Figure IV.2).

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 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).

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 83

Figure IV.6 : Analyse des sondes


4.4.4. Analyse des alertes :
On peut consulter les alertes d’une manière générale,

Figure IV.7 : Consultation 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 : Classification des alertes selon les adresses IP

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 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éros
de ports. Les graphes joints à chaque type de consultation, donneront une allure aux
statistiques des alertes.

Figure IV.9 : Classification 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 86

Figure IV.13 : Ajout de fichiers de signatures

Figure IV.14 : Suppression de fichiers de signatures

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 87

Figure IV.15 : Activation désactivation de fichiers de signatures

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 : Configuration de SNORT

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 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 :

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L S » 89

Figure IV.19 : Execution de requêtes SQL


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 « ALS »

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Chapitre IV : L’application « A L 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 la
robustesse 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Perspectives 92

PERSPECTIVES

Malgré ce qu’offre « ALS » comme facilités pour gérer SNORT, on ne peut


s’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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 93

Annexes

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 bien
connaitre 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 qui
communiquent 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 machine
de destination

 Numéro d'ordre (ou séquence) (32 bits): Lorsque le drapeau SYN est à 0, le
numéro d'ordre est celui du premier mot du segment en cours.Lorsque SYN est à 1, le
numéro d'ordre est égal au numéro d'ordre initial utilisé pour synchroniser les numéros
de séquence (ISN)

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 prochain
segment 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 informations


supplé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 le


ré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 faisant


la somme des champs de données de l'en-tête, afin de pouvoir vérifier l'intégrité de
l'en-tête

 Pointeur d'urgence (16 bits): Indique le numéro d'ordre à partir duquel


l'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. Il


implémente deux tâches de base : la fragmentation et l’adressage.
La fragmentation consiste à « briser » les données en petits paquets appelés
datagrammes. 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 de
remise. Autrement dit, lorsqu’on envoie un datagramme IP sur le réseau, rien ne peut nous
assurer que celui-ci se rendra bel et bien à destination.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 nombre
de mots de 32 bits constituant l'en-tête (nota : la valeur minimale est 5). Ce champ est
codé sur 4 bits.

 Type de service (8 bits) : il indique la façon selon laquelle le datagramme doit être
traité.

 Longueur totale (16 bits): il indique la taille totale du datagramme en octets. La


taille de ce champ étant de 2 octets, la taille totale du datagramme ne peut
dé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
nombre
maximal de routeurs à travers lesquels le datagramme peut passer. Ainsi ce champ est
dé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 les
datagrammes perdus.

 Protocole (8 bits) : ce champ, en notation décimale, permet de savoir de quel protocole


est issu le datagramme
ICMP : 1 IGMP : 2 TCP : 6 UDP : 17

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 97

 Somme de contrôle de l'en-tête, ou en anglais header checksum (16 bits) : ce


champ contient une valeur codée sur 16 bits qui permet de contrôler l'intégrité de
l'en-tête afin de déterminer si celui-ci n'a pas été altéré pendant la transmission. La
somme 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 nombre
avec 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 du


segment UDP.

 Port Destination: Ce champ contient le port correspondant à l'application de la


machine 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 99

Annexe B : Attaques par VIRUS [Complément au chapitre II]

En ayant des connaissances basiques en programmation, toute personne peut créer des
virus à l’aide d’outils mis à la porté, en téléchargement (gratuit la plupart du temps). Le code
source, ainsi que les missions cibles diffèrent d’un logiciel malveillant à un autre.

Il existe une diversité de virus circulant sur nos réseaux et systèmes d’informations.
On note, dans cette annexe, les plus populaires d’entre eux.

B.1 Les Chevaux de Troie [2]

Un Cheval de Troie est un programme informatique effectuant des opérations à l’insu de


l’utilisateur. Il s’agit donc d’un programme caché dans un autre qui exécute des commandes,
sournoises et qui, généralement, donne accès à la machine sur laquelle il est exécuté.

A l’heure actuelle, il existe plusieurs Chevaux de Troie particulièrement dangereux qui


permettent la prise de contrôle d’un système à distance. Ils se présentent sous la forme d’un
programme-client et d’un programme-serveur.

Dans un premier temps, le programme serveur est envoyé à la victime dans un courrier
électronique sous la forme d’une pièce jointe. Lorsque ce fichier est exécuté, le programme
ouvre un port sur la machine attaquée et s’installe de façon résidente et invisible dans le
système victime.

Ensuite programme client initialise une connexion avec la machine attaquée et permet ainsi le
contrôle de l’ordinateur de la victime. Au préalable, et afin de s’infiltrer dans une machine, le
pirate doit en connaitre l’adresse IP.

Les plus célèbres des Chevaux de Troie sont :


BackOrifice (www.bo2k.com)
NetBus (www.netbus.org)
SubSeven (http://subseven.slak.org)

B.2 Les bombes logiques [2]

Les bombes logiques sont des programmes ou commandes programmés d’une façon
insidieuse et contenant généralement un mode de déclenchement différé en fonction
d’événements ou de dates déterminées. Ces bombes exploitent donc des informations comme
la date système, le lancement d’une procédure, une commande du shell, un call système
(appel système). Les mécanismes utilisés sont, dans certains cas, conçus de manière à
répondre à une commande télé programmée (RTC, accès à un PAVI, à un PAD…)

La bombe logique la plus connue, qui a, manifestement, fait des ravages qu’encourent encor
les utilisateurs les moins protégés est :
Tchernobyle (CIH) : il a fait son apparition en 1998 à Taïwan, c’est un virus qu’on
appelle « Résident  », il se cache au sein de la machine infectée, en attendant la date
de son déclenchement connue pour 26 Avril (relative à la catastrophe nucléaire
Tchernobyle 26 Avril 1986). Ainsi il infecte les exécutables, détruit les données et il va
même jusqu’à effacer le BIOS.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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èmes
informatiques 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 vers
de 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 une
machine différente. Le réseau constitue alors un support de communication et de
propagation. Certains vers possèdent un segment principal qui coordonne les actions
des 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 des
virus 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 message
auquel il est attaché à chacune des adresses du répertoire.
Melissa : Célèbre par ces ravages en 2002, lui, attaque les fonctions d’automatisation
du traitement de texte Word. D’autres virus se sont transmis via le tableur Microsoft
Excel.

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 fichiers
et ne se propagent pas à travers le réseau. Ils tournent en boucle infinie en créant de nouvelles
tâches (par exemple variables) qui saturent la mémoire et provoquent l’erreur.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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és


dans 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 ce
qui 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 de
la Sécurité des Systèmes d'Information Français) depuis 1995, elle est dérivée des méthodes
Melisa et Marion. Existant en langue française et en anglais, elle est utilisée par de
nombreuses 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 les
scénarios redoutés, et en la classification préalable des entités du SI en fonction de trois
critères de sécurité de base (confidentialité, intégrité, disponibilité). Ces enjeux expriment les
dysfonctionnements 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çais
objectifs de commande pour information et la technologie relative) est un ensemble des
meilleures pratiques mondiales en audit et maîtrise des systèmes informatiques.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 102

Créé par l'association d'audit et de commande de systèmes d'information (ISACA) en


1992, 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 à la
ré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 informatiques
et 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 processus


informatiques 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é des
Systèmes d'Information), du Ministrère de la Défence (France). Elle est destinée avant tout
aux 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ée
dans 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 des
organismes publics français. Un club d'utilisateurs EBIOS a été créé en 2003 et
constitue une communauté experts permettant le partage des expériences. Une base de
connaissances à laquelle se connecte le logiciel EBIOS permet d'avoir à accès à la
description d'un ensemble de vulnérabilités spécifiques, de contraintes de sécurité, de
mé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, des
contraintes 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 mise
en évidence des impacts en cas de sinistre.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 103

3. étude des menaces : Recensement des scénarios pouvant porter atteinte aux
composants (techniques ou non) du SI.

4. identification des objectifs de sécurité : Mise en évidence des risques réels et


expression de la volonté de les traiter en cohérence avec le contexte particulier de
l’organisme.

5. détermination des exigences de sécurité : Spécification des mesures concrètes à mettre en


œuvre 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'un
questionnaire, elle donne une évaluation chiffrée du risque informatique.
Marion repose sur l'évaluation des aspects organisationnels et techniques de la sécurité de
l'entreprise à auditer.
Elle utilise 27 indicateurs classés en 6 thématiques. Chaque indicateur se voit attribuer une
note 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 de
l'audit et le découpage fonctionnel du SI à adopter pour simplifier la réalisation de
l'étude.

2. Audit des vulnérabilités : consiste à répondre aux questionnaires. Ces réponses


donné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 27
indicateurs à la valeur 3 (niveau de sécurité satisfaisant) de l'audit des vulnérabilités et
atteindre 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éristiques


MEHARI MEthode CLUSIF Succède à la méthode
Harmonisée Marion.
d’Analyse des S'articule autour de 3 plans.
Risques Permet désormais d'apprécier
les risques au regard des
objectifs "business" de
l'entreprise.
COBIT Control ISACA Méthode accessible à tous,
Objectives for dans un langage simple. Les
Information outils fournis permettent la
and mesure des performances
Technology mais la méthode est
aujourd'hui davantage
assimilée à une méthode de
gouvernance des SI.
EBIOS Expression des DCSSI Notamment déployée au
Besoins et sein de l'administration
Identification française, cette méthode
des Objectifs de comprend une base de
Sécurité. connaissances et un recueil
de bonnes pratiques. Elle
est téléchargeable sur le site
de la DCSSI et s'accompagne
d'un logiciel.
MARION Méthodologie CLUSIF Fonctionne par
d’Analyse des questionnaires
Risques débouchant sur 27 indicateurs
Informatiques répartis en

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 105

Orientée par 6 catégories. 2 phases


Niveaux (audit des
vulnérabilités et analyse des
risques)
permettent la définition et
la 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é, elles
ne se réfèrent pas, néanmoins, à un standard commun. Contrairement, par exemple, à la norme
ISO/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é de
l'information constituant au total 41 catégories (objectifs de sécurité).

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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édure
d’installation et les techniques de configuration changent bien sûr mais le fonctionnement de
SNORT 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.1
o WinPcap 3.1
o 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 MySQL


On 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 le
script 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 en
copiant toutes les requêtes dans le champ qui apparait lorsqu’on clique sur SQL dans la base
de 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.

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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 ».

Fonctionnement 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;);

Fichier 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.x


var HOME_NET 192.168.0.0/24
# Valeur par défaut
var HOME_NET any

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


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.config
include 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 le
ré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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 109

Modes d’utilisation de SNORT  :

Mode Sniffer
 snort –v : Cette commande permet d’exécuter et d’afficher les entêtes des paquets
TCP/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 logs
directement 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 de
SNORT (dans le quel nous avons déjà inclus les noms des règles souhaitées). SNORT va
analyser 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 110

Annexe E : Algorithmes de recherche de motif [21]

La recherche de motif (Pattern Matching en anglais) permet de localiser une occurrence d’un
mot (motif) dans un texte. Parmi les algorithmes utilisés nous citons :

E.1 Algorithme naïf

Le code de cet algorithme est en langage C:


void BF(char *x, int m, char *y, int n) {
int i, j;

/* Searching */
for (j = 0; j <= n - m; ++j) {
for (i = 0; i < m && x[i] == y[i + j]; ++i);
if (i >= m)
OUTPUT(j);
}
}
This algorithm can be rewriting to give a more efficient algorithm in practice as follows:
#define EOS '\0'

void BF(char *x, int m, char *y, int n) {


char *yb;
/* Searching */
for (yb = y; *y != EOS; ++y)
if (memcmp(x, y, m) == 0)
OUTPUT(y - yb);
}

E.2 Algorithme Knuth-Morris-Pratt

Cet algorithme est un algorithme de recherche de sous-chaîne, permettant de trouver les


occurrences d'une chaîne P dans un texte S. Il a été inventé par Knuth et Pratt, et
indépendamment par J. H. Morris en 1975.

Son code écrit en C est le suivant :


void preKmp(char *x, int m, int kmpNext[]) {
int i, j;

i = 0;
j = kmpNext[0] = -1;
while (i < m) {
while (j > -1 && x[i] != x[j])
j = kmpNext[j];
i++;
j++;
if (x[i] == x[j])
kmpNext[i] = kmpNext[j];
else
kmpNext[i] = j;
}
}
void KMP(char *x, int m, char *y, int n) {
int i, j, kmpNext[XSIZE];

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 111

/* Preprocessing */
preKmp(x, m, kmpNext);

/* Searching */
i = j = 0;
while (j < n) {
while (i > -1 && x[i] != y[j])
i = kmpNext[i];
i++;
j++;
if (i >= m) {
OUTPUT(j - i);
i = kmpNext[i];
}
}
}

E.3 Algorithme Boyer-Moore

L'algorithme de Boyer-Moore est un algorithme de recherche de sous-chaîne


particulièrement efficace. Il a été développé par Bob Boyer et J. Strother Moore en 1977.

Son code écrit en C est le suivant :


void preBmBc(char *x, int m, int bmBc[]) {
int i;

for (i = 0; i < ASIZE; ++i)


bmBc[i] = m;
for (i = 0; i < m - 1; ++i)
bmBc[x[i]] = m - i - 1;
}
void suffixes(char *x, int m, int *suff) {
int f, g, i;

suff[m - 1] = m;
g = m - 1;
for (i = m - 2; i >= 0; --i) {
if (i > g && suff[i + m - 1 - f] < i - g)
suff[i] = suff[i + m - 1 - f];
else {
if (i < g)
g = i;
f = i;
while (g >= 0 && x[g] == x[g + m - 1 - f])
--g;
suff[i] = f - g;
}
}
}
void preBmGs(char *x, int m, int bmGs[]) {
int i, j, suff[XSIZE];

suffixes(x, m, suff);

for (i = 0; i < m; ++i)


bmGs[i] = m;
j = 0;

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 112

for (i = m - 1; i >= 0; --i)


if (suff[i] == i + 1)
for (; j < m - 1 - i; ++j)
if (bmGs[j] == m)
bmGs[j] = m - 1 - i;
for (i = 0; i <= m - 2; ++i)
bmGs[m - 1 - suff[i]] = m - 1 - i;
}

void BM(char *x, int m, char *y, int n) {


int i, j, bmGs[XSIZE], bmBc[ASIZE];

/* Preprocessing */
preBmGs(x, m, bmGs);
preBmBc(x, m, bmBc);

/* Searching */
j = 0;
while (j <= n - m) {
for (i = m - 1; i >= 0 && x[i] == y[i + j]; --i);
if (i < 0) {
OUTPUT(j);
j += bmGs[0];
}
else
j += MAX(bmGs[i], bmBc[y[i + j]] - m + 1 + i);
}
}

E.4 Algorithme Aho-Corasick

L’algorithme d'Aho-Corasick est un algorithme de recherche de chaîne de caractère (ou


motif) dans un texte dû à Alfred Aho et Margaret Corasick et publié en 1975.

Son code écrit en langage C est le suivant :


#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
void triSelection(int tab[], int n) {
int i, j, x, min;
for(i = 0; i < (n - 1); i++) {
min = i;
for(j = (i + 1); j < n; j++) {
if(tab[j] < tab[min]) {
min = j;
}
}
if(min != i) {
x = tab[i];
tab[i] = tab[min];
tab[min] = x;
}
}
}
int main (int argc, char *argv[]) {

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Annexes 113

FILE *file;
char **mots; // Ensemble de mots a chercher
int alpha;
char buffer[256];
int i;

if(argc<4) {
printf("Generateur de motif dans le fichier fic.txt\n");
printf("Usage : %s fic.txt taille(Mo) motif1 [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;
}

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Bibliographie & Webographie 114

Bibliographie & Webographie

[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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Bibliographie & Webographie 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

Analyseur de Logs pour SNORT Omar Kaïs El KAMEL


Analyseur de Logs pour SNORT Omar Kaïs El KAMEL

Vous aimerez peut-être aussi