Upload
oussama-gouader
View
222
Download
0
Embed Size (px)
Citation preview
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 1/116
Table des matières
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
1
Table des matières
Table des matières _____________________________________________________________1 Liste des figures _______________________________________________________________4
Liste des tableaux______________________________________________________________6
Liste des Annexes______________________________________________________________7
Liste des abréviations __________________________________________________________8
Introduction générale __________________________________________________________9
Chapitre I : La sécurité des réseaux informatiques _________________________________ 12
1. Introduction : _______________________________________________________________ 13
2. Les réseaux informatiques : ____________________________________________________ 13 2.1. Historique : ______________________________________________________________________ 14 2.2. Administration des réseaux informatiques : _____________________________________________ 15
2.2.1. Définition : __________________________________________________________________ 15 2.2.2. Architecture des réseaux [5] : ____________________________________________________ 15 2.2.3. Topologies [6] : ______________________________________________________________16 2.2.4. Protocoles [7] : _______________________________________________________________17
3. La sécurité des systèmes d¶informations _________________________________________ 18 3.1. Vulnérabilités et risques : ___________________________________________________________ 18
3.1.1. Définitions : _________________________________________________________________ 19 3.1.2. Causes des vulnérabilités : ______________________________________________________ 19 3.1.3. L¶exploitation malicieuse des failles : _____________________________________________ 19 3.1.4. Les risques informatiques : ______________________________________________________ 19
3.2. Les attaques : ____________________________________________________________________ 20 3.2.1. Déni de Service (DoS) [12] : ____________________________________________________ 20 3.2.2. User to Root (U2R) [12] : _______________________________________________________ 21 3.2.3. Probing [12] : ________________________________________________________________21 3.2.4. Remote to Local access (R2L) [12] : ______________________________________________ 22
3.3. Les politiques de sécurité : __________________________________________________________ 23
4. Conclusion :_________________________________________________________________ 23
Chapitre II : Les systèmes de détection d¶intrusions ________________________________24
1. Introduction : _______________________________________________________________ 25
2. Systèmes de Détection d¶Intrusions : ____________________________________________ 25 2.1. Présentation et Définitions : _________________________________________________________ 26
2.1.1. Présentation d¶un Système de Détection d¶Intrusions : ________________________________26
2.1.2. Définitions : _________________________________________________________________ 26 2.2. Types des IDS : __________________________________________________________________ 27 2.2.1. NIDS : _____________________________________________________________________ 28 2.2.2. HIDS : _____________________________________________________________________ 28 2.2.3. IDS hybrides (NIDS+HIDS) : ___________________________________________________ 28
3. IDS versus Firewall : _________________________________________________________ 28 3.1. Comparaison entre Firewall et IDS : __________________________________________________ 29 3.2. Comparaison entre IDS et IPS : ______________________________________________________ 29
3.2.1. Placement des IDS : ___________________________________________________________ 29
4. Méthodes de détection d'intrusions : ____________________________________________ 32
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 2/116
Table des matières
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 3/116
Table des matières
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 4/116
Liste des figures
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
4
Liste des figures
Figure II.1 : IDS installé avant le Firewall _____________________________________________________ 30 Figure II.2 : IDS installé après le Firewall _____________________________________________________ 30 Figure II.3 : IDS installé dans la DMZ ________________________________________________________ 31 Figure II.4 : Sondes SNORT placées de part et d¶autre sur le réseau _________________________________ 31 Figure II.5 : Architecture de Snort ____________________________________________________________ 36 Figure II.6 : Interactions au sein du système ____________________________________________________ 36 Figure III.1 : Processus de développement en Y [25] _____________________________________________ 43 Figure III.2 : Etape actuelle du processus 2TUP [26] _____________________________________________ 46 Figure III.3 : Diagramme des cas d¶utilisations _________________________________________________ 48 Figure III.4 : Acteurs du système _____________________________________________________________ 48 Figure III.5 : Diagramme de séquence géneralisé ________________________________________________ 49 Figure III.6 : Etape actuelle du 2TUP [26] _____________________________________________________ 49 Figure III.7 : Diagramme d¶activités de point de vue fonctionnel ___________________________________ 50 Figure III.8 : Diagramme de classe de point de vue fonctionnel _____________________________________ 51 Figure III.9 : Diagramme d¶état généralisé _____________________________________________________ 52 Figure III.10 : Etape actuelle du 2TUP [26] ____________________________________________________ 52 Figure III.11 : Diagramme des cas d¶utilisations raffiné ___________________________________________ 54 Figure III.12 : Etape actuelle du 2TUP [26] ____________________________________________________ 55 Figure III.13 : Diagramme de déploiement _____________________________________________________ 55 Figure III.14 : Etape actuelle du 2TUP [26] ____________________________________________________ 56 Figure III.15 :Diagramme de classes __________________________________________________________ 56 Figure III.16 : Etape actuelle du 2TUP [26] ____________________________________________________ 58 Figure III.17 : La classe Main _______________________________________________________________58 Figure III.18 : La classe Panel _______________________________________________________________59 Figure III.19 : La classeLance _______________________________________________________________59 Figure III.20 : La classe Start _______________________________________________________________60 Figure III.21 : La classe Auth________________________________________________________________61 Figure III.22 : La classeSqlbd _______________________________________________________________62 Figure III.23 : La classe Abds _______________________________________________________________63 Figure III.24: La classe Videbd ______________________________________________________________64 Figure III.25 : La classe User _______________________________________________________________64 Figure III.26 : La classe Aalerte _____________________________________________________________ 65 Figure III.27 : La classe Calerte _____________________________________________________________ 65 Figure III.28 : La classe Atemp ______________________________________________________________66 Figure III.29 : La classe Aport _______________________________________________________________67 Figure III.30 : La classe Aprdst ______________________________________________________________67 Figure III.31 : La classe Aprsrc ______________________________________________________________67 Figure III.32 : La classe Aprotocol ___________________________________________________________ 68 Figure III.33 : La classe Apudp ______________________________________________________________68 Figure III.34 : La classe Aptcp _______________________________________________________________68 Figure III.35 : La classe Asonde _____________________________________________________________ 69 Figure III.36 : La classe Ajoutr ______________________________________________________________69 Figure III.37 : La classe Assieditr ____________________________________________________________ 70 Figure III.38 : La classe Editr _______________________________________________________________71 Figure III.39 : La classe Modiffr _____________________________________________________________ 71 Figure III.40 : La classe Modifr ______________________________________________________________72 Figure III.41 : La classe Suppr _______________________________________________________________73 Figure III.42 : La classe Suppfr ______________________________________________________________73 Figure III.43 : La classe Paramsnort __________________________________________________________ 74 Figure III.44 : La classe Ageneral ____________________________________________________________ 75 Figure III.45 : La classe Rapport _____________________________________________________________ 76 Figure IV.1 : Programmation Batch___________________________________________________________ 80 Figure IV.2 : Interface d¶authentification de « ALS » _____________________________________________ 80 Figure IV.3 : Identifiant incorrecte ___________________________________________________________ 81
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 5/116
Liste des figures
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
5
Figure IV.4 : Vue d¶ensemble ________________________________________________________________81 Figure IV.5 : Etat de SNORT ________________________________________________________________82 Figure IV.5 : Ecoute de SNORT ______________________________________________________________82 Figure IV.6 : Analyse des sondes _____________________________________________________________ 82 Figure IV.7 : Consultation des alertes _________________________________________________________ 83 Figure IV.8 : Classification des alertes selon les adresses IP _______________________________________ 83 Figure IV.9 : Classification des alertes selon les ports source et destination ___________________________ 84
Figure IV.10 : Analyse temporelle ____________________________________________________________ 84 Figure IV.11 : Edition d¶une signature ________________________________________________________ 85 Figure IV.12 : Edition d¶une nouvelle signature à l¶aide de l¶assistant ________________________________85 Figure IV.13 : Ajout de fichiers de signatures ___________________________________________________ 86 Figure IV.14 : Suppression de fichiers de signatures ______________________________________________ 86 Figure IV.15 : Activation désactivation de fichiers de signatures ____________________________________ 86 Figure IV.16 : Activation désactivation de signatures d¶un fichier ___________________________________ 87 Figure IV.17 : Configuration de SNORT _______________________________________________________ 87 Figure IV.18 : Gestion des utilisateurs _________________________________________________________ 88 Figure IV.19 : Execution de requêtes SQL ______________________________________________________ 88 Figure IV.20 : Vidage de la base de données ___________________________________________________ 89 Figure IV.21 : A propos de « ALS » ___________________________________________________________ 89
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 6/116
Liste des tableaux
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 7/116
Liste des Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 8/116
Introduction générale
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
8
Liste des abréviations
ALS : Analyseur de Logs pour SNORT
IDS : Intrusion Detection SystemIPS : Intrusion Prevention System
NIDS : Network IDS
HIDS : Host IDS
TCP : Transmission Control Protocol
UDP : User Datagram Protocol
IP : Internet Protocol
ARP : Address Resolution Protocol
ICMP : Internet Control Message Protocol
FTP : File Transfer Protocol
ARPANET : Advanced Research Projects Agency NETwork
DoS : Denied of Service
U2R : User to Root
R2L : Remote to Local access
GNU : General Public License
SQL : Structured Query Language
UML : Unified Modelling Language
UP : Unified Process
2TUP : 2 Track Unified Process
JEE : Java Enterprise Edition
CPU : Central Processing Unit
RAM : Random Access Memory
ACID : Analysis Console for Intrusion Database
MEHARI : MEthode Harmonisée d¶Analyse des RIsques
COBIT : Control Objectives for Information and related Technology
EBIOS : Expression des besoins et Identification des Objectifs de Sécurité
MARION : Méthodologie d¶Analyse de Risques Informatiques Orientés par Niveaux
ISO : Organisation internationale de normalisation
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 9/116
Introduction générale
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
9
Introduction générale
présent rapport entre dans le cadre de la réalisation d¶un mémoire de projet de find¶études à la faculté des sciences de Bizerte, pour l¶obtention d¶une licence
appliquée en technologies des Réseaux et Télécommunications.
La sécurité des systèmes d¶informations est indispensable quel que soit le domaine
d¶utilisation et l¶importance de l¶information à manipuler, puisqu¶une simple attaque de
débutants, peut s¶avérer parfois destructrice ainsi la méconnaissance des vulnérabilités de tels
systèmes met en péril leur intégrité. C¶est pour cela qu¶on cherche de nouvelles solutions de
sécurité, le plus souvent les moins coûteuses mais qui permettent d¶améliorer les solutions
déjà existantes et renforcent toute entité du réseau en matière de protection.
C¶est dans le cadre du projet: « Développement d¶un système d¶administration et
d¶analyse de Logs pour l¶IDS SNORT », que les problèmes majeurs de l¶insécurité des
systèmes d¶informations vont être mis en cause afin de palier aux attaques des pirates. Ces
derniers qui tentent de pénétrer des entités du réseau en provoquant par la suite des atteintes
de différents niveaux de gravité. Ces niveaux peuvent être une simple écoute du trafic ou bien
une violation de vie privée dans le cas de vols de mots de passe, de numéros de cartes de
crédit ou d¶autres informations secrètes.
En complément pour les politiques de sécurité déjà existantes qui consistent à mettre
en place des pare-feux et des systèmes d¶authentification. Il existe d¶autres outils de
surveillance de trafic qui offrent des fonctionnalités pour auditer le réseau et détecter
d¶éventuelles intrusions tentant à compromettre la confidentialité, l¶intégrité ou bien la
disponibilité d¶une ressource, ces dispositifs sont appelés systèmes de détection d¶intrusions
(en anglais Intrusion Detection Systems IDS).
Opter pour une solution de sécurité fiable est important pour réduire les risques, qui
peuvent avoir un impact sur un réseau informatique lors d¶intrusions (prémédités ou non).
Le
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 10/116
Introduction générale
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
10
Un système de détection d¶intrusions est un ensemble de composants matériels et
logiciels dont la fonction principale est de dépister et analyser toute tentative d¶effraction.
Parmi les IDS les plus populaires, citons à titre d¶exemple Bro, Prelude, SNORT, Tripwire,
etc.
Comme il a été indiqué ci-dessus, le présent projet traite seulement l¶IDS SNORT
Open Source vu sa gratuité, l¶évolution qu¶il a subi depuis sa création ainsi que sa portabilité,
tous ces facteurs l¶ont rendu un pionnier parmi les autres outils standards de détection
d¶intrusions. Il est disponible à l¶adresse www.snort.org.
SNORT est un logiciel libre, capable d¶effectuer une analyse du trafic et une
journalisation des paquets en temps réel sur les réseaux IP. Il supporte l¶analyse de protocoles
et la recherche/mise en correspondance de contenus et peut être employé pour détecter unevariété d¶attaques et d¶explorations : débordement de tampon, scan furtif de ports, attaque
CGI, probe SMB identification du système d¶exploitation, ect.
C¶est en 1998 que Martin Roesch, le fondateur de SourceFire, décide de publier un
logiciel de sa conception, développé pour et autour du milieu Open Source : un programme
qu¶il appellera finalement « SNORT » [1].
Malgré ce qu¶offre SNORT comme fonctionnalités, cet IDS reconnu parmi les
meilleurs pose deux problèmes, coïncidant avec la gestion du programme lui-même. En
premier lieu, c¶est l¶administration de ses modules, pauvre en elle-même (les responsables
de réseaux qui ont des connaissances limitées en programmation ne parviendront pas a la
configuration exacte de l¶outil). En second lieu, SNORT, comme tous les IDS, génère une
base de Logs qui ne cesse de grandir d¶une manière exponentielle rendant l¶interprétation
manuelle des alertes difficile, voir des fois impossible.
Les deux problèmes déjà évoqués ont induit l¶idée, qui est de concevoir un mini
programme qui assure automatiquement une bonne gestion de l¶outil SNORT entre autres son
administration et l¶interprétation des Logs qu¶il génère. C¶est dans ce sens, que ce travail a
pris chemin pour donner naissance à un outil complémentaire à SNORT, baptisé « ALS », qui
interprétera les Logs et facilitera l¶administration de cet IDS à travers une interface homme-
machine conviviale et simple à utiliser.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 11/116
Introduction générale
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 12/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
12
Chapitre I : La sécurité des réseaux informatiques
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 13/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
13
1. Introduction :
« L¶importance de l¶informatique et de l¶internet en particulier, pour nos entreprises,
nos industries, nos gouvernements, nos moyens de transport, notre société entière, et pour
chacun de nous en tant qu¶individu et citoyen, poursuit une progression fulgurante depuis unedécennie. Ceci paraît évident, mais il serait salutaire de réfléchir un instant à cette dépendance
presque totale qui s¶installe insidieusement dans nos vies. L¶informatique, dans nos esprits et
dans nos habitudes quotidiennes est devenue comme l¶eau potable, l¶air pur, l¶électricité et le
téléphone : elle est là, partout, omniprésente et nous en avons constamment besoin. Mais si
d¶aventure elle n¶est plus là, ou si elle est µµpolluée¶¶, c¶est alors au mieux la consternation et
le dérangement, au pire la panique et la catastrophe pouvant entraîner des pertes financières.
Et pourtant, tous les services informatiques dont nous dépendons sont des denrées
fragiles, constituées d¶innombrables composants matériels, logiciels et humains, devant
fonctionner en parfaite symbiose jour après jour, heure après heure, microseconde par
microseconde. Ces services doivent assurer des niveaux de disponibilité, de fiabilité, de
performance et de garanties d¶intégrité comparables aux exigences rencontrées dans les
domaines tels que ceux de l¶énergie nucléaire et de l¶exploration spatiale, mais doivent les
réaliser à une échelle infiniment plus grande.
Ces divers composants sont sujets à des défaillances matérielles et humaines, mais
aussi à des attaques d¶intention criminelle, malveillante ou de simple divertissement
technique. La fraude financière, l¶espionnage industriel, le terrorisme et la bêtise humaine
sont tous des domaines où l¶informatique est devenue à la fois une cible et une arme via
l¶Internet » [2].
Ce chapitre est divisé en deux grandes parties, la première définira les réseaux
informatiques et invoquera les architectures et les protocoles les plus utilisés. La deuxième
partie aura pour objectifs les vulnérabilités des systèmes, les types d¶attaques ainsi que les
politiques de sécurité adoptées.
2. Les réseaux informatiques :
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 14/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
14
2.1. Historique :
« Internet est issu du réseau ARPANET (de l'Advanced Research Projects Agency), créé en
1968 par le département américain de la Défense, dans un but stratégique, pour relier ses
centres de recherche.
Le réseau initial ne permettait que l'envoi de courrier électronique. C'est en 1972 que
commencèrent les spécifications des protocoles TCP/IP avec l'expérience de l'usage de X25
sur ARPANET. Le but était de concevoir un réseau qui résiste à des attaques militaires telles
que des bombardements. Ainsi, il ne devait pas y avoir de point névralgique dans le réseau,
dont l'arrêt aurait provoqué le blocage complet de celui-ci, et les données devaient pouvoir
automatiquement prendre un chemin différent en cas de coupure de liaison. D'où l'absence de
contrôle centralisé dans l'internet et un cheminement dynamique des données.
Mis dans le domaine public (libre d'utilisation), il fut repris par les universitaires en
1979 (La Duke University à Durham Caroline du Nord), qui y virent le moyen d'échanger des
informations.
Après les militaires et les universitaires (La National Science Foundation finance leurs
mises en réseau), Internet devient aux États-Unis l'affaire des grandes entreprises privées, des
P.M.E. et des particuliers.
En 1983, c'est au tour de l'Europe (par le biais en France du C.N.A.M. Conservatoire
national des arts et métiers) et du reste du monde de se connecter à ce réseau de réseaux.
Selon le principe d'internet, le réseau IP français pour la recherche s'est construit par le
bas, en partant des laboratoires puis des campus et en passant ensuite par la région, avant de
passer au projet national. Actuellement, le développement de l'infrastructure internet en
France se fait surtout du côté des opérateurs privés qui offrent les services de l'internet aux
entreprises et aux particuliers.
L'outil qui rendit populaire l'internet à partir de 1993 est le WWW, le World Wide
Web en un mot le Web. Le mot Web désigne la toile d'araignée et World Wide Web désigne
donc la toile d'araignée couvrant le monde entier.
Le premier navigateur WEB graphique a été mis aux points au CERN (centreeuropéen de recherche nucléaire) en 1993.
Un navigateur Web permet de se connecter à une multitude de sites diffusant des
informations sans connaissances des règles de communication propre au réseau.
L'internet reliait en 1995 plus de 2 millions d'ordinateurs et plus de 30 millions
d'utilisateurs dans 146 pays » [3].
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 15/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
15
2.2. Administration des réseaux informatiques :
L¶administrateur des réseaux informatiques est une activité qui s¶avère indispensable
pour toute entreprise ; les outils utilisés au cours d¶une telle mission ne cesseront de croître du
point de vue qualité afin qu¶ils puissent munir les concernés d¶une multitude de choix et de
méthodes qui les aide à s¶acquérir un niveau maximum de sécurité et de qualité de service.
2.2.1. Définition :
Un Réseau: Il s¶agit d¶« un ensemble de lignes entrecroisées ». Réseau informatique:
« Système d¶ordinateurs géographiquement éloignés les uns des autres, interconnectés par
des télécommunications, généralement permanentes » [4].
L¶utilisation d¶un réseau est primordiale pour l¶entreprise afin de satisfaire ses besoins dont le
partage des ressources (aide diminuer les coûts), la communication entre personnes et la
facilité d¶administration.
2.2.2. Architecture des réseaux [5] :
Il existe généralement deux types d'architecture réseau: l'architecture « égal à égal », et
l'architecture « Client ±Serveur ». Le choix de l'architecture à utiliser dépend de plusieurs
critères:
Type d'activité ;
Nombre d'ordinateurs à connecter ;
Volume du trafic ;
Les droits d'accès ;
Le budget, etc.
L'architecture « égal à égal »
Dans ce type d'architecture, il n'y a pas de serveur dédié. De ce fait, chaque ordinateur
connecté sur le réseau possède tous les droits d'accès. Ainsi, il est libre de partager ses
ressources.
Ce type d'architecture peut être utilisé dans les petites entreprises, vu la simplicité de
son installation. En effet, on peut utiliser le Peer to Peer pour un nombre maximum de dix
ordinateurs situés dans la même zone géographique et relié par un simple système de câblage.
L'inconvénient de cette architecture, c'est que l'administration est difficile et la sécurité
est moins facile à assurer.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 16/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
16
L'architecture « client ±serveur »
Elle consiste à relier des ordinateurs (clients) à un ordinateur central généralement plus
puissant (serveur). Ce serveur offre aux clients plusieurs services selon leurs droits d'accès,
tels que les accès aux bases de données, la connexion à Internet, etc.
Cette architecture est recommandée pour les moyennes et grandes entreprises
nécessitant un niveau de sécurité très élevé. L'avantage de cette architecture est la possibilité
d'administrer le réseau au niveau du serveur et donc d'assurer la sécurité.
Il existe plusieurs niveaux d'architectures client -serveur:
L'architecture du site central (Mainframe) : Le mainframe représente un ordinateur
central de grande puissance chargé de gérer les sessions utilisateurs des différents terminaux
qui lui étaient reliés. C'est un serveur central qui prend en charge l'intégralité des traitements,
y compris l'affichage qui est simplement déporté sur des terminaux passifs.
Cependant, dans le modèle mainframe, la performance du système tout entier repose sur
les capacités de traitement de l¶ordinateur central, c¶est la raison pour laquelle ce modèle est
parfois qualifié d¶informatique lourde. Par ailleurs, dans un environnement mainframe, les
terminaux du réseau ne peuvent voir que le serveur central.
L'architecture 2 -tiers: appelée aussi architecture à deux niveaux, caractérise les
systèmes clients -serveur où le client envoie des requêtes qui seront traitées par le serveur
directement sans l'aide d'une autre application.
L'architecture 3 -tiers: appelée aussi architecture à trois niveaux, caractérise les
systèmes client -serveur qui nécessitent l'existence d¶une partie intermédiaire appelée
« serveur d'application » ou également « middleware » pour le traitement des requêtes
utilisateurs.
L'architecture N -tiers: ou à plusieurs (N) niveaux, utilise N serveurs destinés chacun
à réaliser des requêtes précises. On peut donc constater que l'architecture 3 -tiers est unearchitecture N -tiers.
2.2.3. Topologies [6] :
« La topologie est l'arrangement physique des ordinateurs constituant un réseau
(configuration spatiale). » On distingue généralement cinq topologies:
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 17/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
17
Topologie en bus: C'est l'organisation la plus simple. Elle consiste à relier tous les
ordinateurs du réseau à un même câble (notamment coaxial). Ce genre de connexion est
fragile puisqu¶une faille dans la connexion affecte tout le réseau.
Topologie en étoile: Les ordinateurs du réseau sont connectés à un concentrateur
(Hub). Contrairement à une topologie en bus, une connexion défaillante ne paralyse pas tout
le réseau.
Topologie en anneau: Les ordinateurs du réseau sont connectés à un répartiteur
nommé MAU (Multi stations Access Unit) qui gère la communication entre eux en accordant
à chacun d'entre eux un "temps de parole".
Topologie en arbre ou hiérarchique: constituée de niveaux, le nud central de haut
niveau est connecté à plusieurs nuds de niveau inférieur, et ainsi de suite jusqu'à atteindre
les feuilles au dernier niveau.
Topologie maillée: correspond à plusieurs liaisons Point à Point, où chaque
ordinateur est relié à tous les autres.
2.2.4. Protocoles [7] :
Un protocole est une méthode standard qui permet la communication entre des
processus (s'exécutant éventuellement sur différentes machines), c'est-à-dire un ensemble de
règles et de procédures à respecter pour émettre et recevoir des données sur un réseau. Il en
existe plusieurs selon ce que l'on attend de la communication. Certains protocoles seront par exemple spécialisés dans l'échange de fichiers (le FTP), d'autres pourront servir à gérer
simplement l'état de la transmission et des erreurs (c'est le cas du protocole ICMP), etc.
[Voir Annexe A]
Le protocole TCP
Le protocole de contrôle de transmission (soit Transmission Control Protocol), est l¶un
des principaux protocoles de la couche transport du modèle TCP/IP. TCP est un protocole
orienté connexion, c'est-à-dire qu¶il permet à deux machines qui communiquent de contrôler l¶état de la transmission et ce à travers l¶ordonnancement des datagrammes en provenance du
protocole IP, le multiplexage des données, etc.
Le protocole IP
Le protocole IP (Internet Protocol) fait partie de la couche Internet du modèle TCP/IP.
Il permet l¶élaboration et le transport des datagrammes IP, sans pour autant en assurer la
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 18/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
18
livraison. En réalité, le protocole IP traite les datagrammes IP indépendamment les uns des
autres en définissant leur représentation, leur routage et leur expédition.
Le protocole UDP
Le protocole UDP (User Datagram Protocol) est un protocole non orienté connexion
de la couche transport du modèle TCP/IP. Vu que le protocole UDP ne fait de contrôle
d¶erreur, l¶entête du segment est donc très simple.
Le protocole ICMP
Le protocole ICMP (Internet Control Message Protocol) est un protocole qui permet de
gérer les informations relatives aux erreurs aux machines connectées. Etant donné le peu de
contrôles que le protocole IP réalise, il permet non pas de corriger ces erreurs mais de faire
part de ces erreurs aux protocoles des couches voisines.
Le protocole ARP
Le protocole ARP (Address Resolution Protocol) a un rôle phare parmi les protocoles
de la couche Internet de la suite TCP/IP, car il permet de connaître l'adresse physique d'une
carte réseau correspondant à une adresse IP.
3. La sécurité des systèmes d¶informations
Alors que les systèmes d¶informations grandissent et sont de plus en plus ouverts sur
Internet, cette ouverture constitue une source imprévisible d¶attaques, la mise en place de
politiques de sécurité est non seulement importante dans ce cas mais primordiale afin de bien
garder la confidentialité1, l¶authenticité2, l¶intégrité3, le contrôle d¶accès4 et la non-répudiation
de l¶information5.
3.1. Vulnérabilités et risques :
Lorsque des pirates veulent s¶introduire dans les systèmes, ils cherchent généralement les
failles de sécurité et les bogues connus pour les exploiter. Pour conduire une véritable attaque,c'est-à-dire pénétrer dans un système cible en vue de le contrôler, l¶attaquant doit se faire une
idée la plus précise et complète possible de la sécurité de l¶entreprise. A mesure qu¶il évalue
1 2 3 4 5
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 19/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
19
le réseau, il exploite ses vulnérabilités pour déterminer exactement comment contrôler ses
ressources.
3.1.1. Définitions :
Vulnérabilité: « Assimilée à une faille de sécurité. Caractéristique permettant de l¶utiliser
pour mettre en péril la sécurité d¶un programme ou d¶un système » [8]
Risques informatiques: « On qualifie généralement les risques informatiques, toutes les
causes externes qui peuvent compromettre l¶efficacité d¶un système, à l¶exclusion de toute
anomalie fonctionnelle (panne machine, bug, erreur de programmation...). » [9]
3.1.2. Causes des vulnérabilités :
« Un système se révèle relativement facile à pénétrer ou à casser s¶il n¶est pas sécurisé
ou mis à jour avec les « patchs » correctifs. Mettre à jour et protéger les systèmes devient de
plus en plus difficile compte tenu du nombre varié des systèmes d¶exploitation (SE) et des
ressources budgétaires et personnelles restreintes dans la plus part des entreprises » [2].
Les administrateurs rencontrent couramment des problèmes de mises à jour des systèmes
surtout que celles-ci nécessitent un suivi journalier puisque mensuellement un grand nombre
de vulnérabilités est détecté dans le monde. Ainsi tout pronostic négligé par un responsable du
réseau peut s¶avérer compromettant pour la sécurité.
3.1.3. L¶exploitation malicieuse des failles :
Les failles de sécurité constituent de l¶or pour certains fous épris de piratage, qu¶ils
soient débutants ou chevronnés, l¶exploitation des vulnérabilités d¶un système de sécurité
pour quelconques fins et à l¶insu du propriétaire met en péril les informations protégées. Pour
cela, les malveillants de l¶informatique, se munissent d¶outils et de bonnes connaissances en
réseaux leur permettant la prise de contrôle des machines, l¶injection de virus ou même la
propagation dans tout un réseau.
3.1.4. Les risques informatiques :
Parmi les risques les plus connus dans le domaine de la sécurité informatiques, nous
citons :
« Risques humains
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 20/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
20
Les risques humains sont les plus importants, même s'ils sont le plus souvent ignorés ou
minimisés. Ils concernent les utilisateurs mais également les informaticiens eux-mêmes.
Parmi les risques les plus répandus on cite: la maladresse, l'inconscience et l'ignorance, la
malveillance, l'espionnage, etc.
Risques techniques
Les risques techniques sont tout simplement ceux liés aux défauts et pannes inévitables
que connaissent tous les systèmes matériels et logiciels. Ces incidents sont évidemment plus
ou moins fréquents selon le soin apporté lors de la fabrication et des tests effectués avant que
les ordinateurs et les programmes ne soient mis en service. Cependant les pannes ont parfois
des causes indirectes, voire très indirectes, donc difficiles à prévoir. Citons à titre d¶exemples
les incidents liés au matériel ou au logiciel, voire même à l'environnement. » [8]
3.2. Les attaques :
L¶anatomie d¶une attaque réside dans sa manière d¶évoluer, elle est la même qu¶elle
soit réalisée par un individu ou de manière automatique par un logiciel malveillant. Basés sur
le concept des cinq P : Prospecter, Pénétrer, Perdurer, Propager et Paralyser, les attaques
présentent un risque majeur pour les systèmes d¶information.
Tout système informatique peut présenter une menace pour différentes types
d¶attaques [Voir Annexe B] qu¶on peut classer en quatre grandes catégories comme suit :
3.2.1. Déni de Service (DoS) [12] :
L¶attaque Déni de Service (Denial of Service : DoS) a pour principe d'envoyer des
paquets ou des données de taille ou de constitution inhabituelle, afin de provoquer une
saturation ou un état instable des équipements victimes et de les empêcher ainsi de se servir
des ressources disponibles en temps normal. Ce type d¶attaque est très simple à mettre en
place, cependant il s¶avère un dispositif énormément destructeur. Parmi les exemples
d¶attaque de type DoS, on peut citer :
Smurf
Cette attaque consiste à usurper une adresse IP source et à envoyer un ICMP Echo
Request sur une adresse de diffusion d'un réseau. Toutes les machines de ce réseau, se pensant
concernées, répondront à cet appel. Ceci a deux effets. Le premier est de saturer la machine
dont on aura usurpé l'adresse IP, le deuxième est de ralentir, voire saturer le trafic sur le
réseau.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 21/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
21
Land
Cette attaque s'appuie sur une mauvaise gestion des droits d'accès au réseau. La
machine attaquée s'autorise à recevoir des paquets externes avec son adresse IP. C'est ce qu'on
appelle du Spoofing (technique d'usurpation d'identité ou d'adresse). Le système ciblé, s'il est
faillible, risque dans ce cas de se voir bloqué (utilisation 100% CPU, crash mémoire, etc.) ou
perdre sa couche réseau. Pour se faire, on commence par scanner tous les ports de la machine
que l'on souhaite attaquer. Par la suite, On envoie une requête avec l'adresse IP source
identique à l'adresse IP destination, sur chaque port ouvert, avec le drapeau SYN activé.
3.2.2. User to Root (U2R) [12] :
Dans ce type d¶attaque, le pirate essaie d¶accéder au système à partir d¶un poste. Pour se
faire, il exploite la vulnérabilité du système afin d¶élever ses privilèges et obtenir les droits
d¶accès administrateur (root). Parmi les attaques qui reposent sur ce principe, nous citons :
Le Rootkit
C¶est un programme ou ensemble de programmes qui, après avoir obtenu les droits
d'administrateur (root) sur une machine, met en place une ou plusieurs portes dérobées. Celles
-ci permettent au pirate de s¶introduire à nouveau au cur de la machine en tant que root et
d'effacer les traces laissées par l'opération dans les journaux système.
Buffer overflow ( Le dépassement de tampon)
Il s¶agit d¶une attaque très efficace et assez compliquée à réaliser. Le fonctionnement
général d'un buffer overflow est de faire anéantir un programme en écrivant dans un tampon
plus de données qu'il ne peut en contenir, dans le but d'écraser des parties du code de
l'application et d'injecter des instructions ouvrant un interpréteur de commande (en anglais
shell ) et permettant au pirate de prendre la main sur le système.
3.2.3. Probing [12] :
La vérification (Probing) est une technique qui consiste à vérifier ou à tester, à l'aide
d'un logiciel approprié, l'état d'un système informatique ou d'un réseau, afin d'en évaluer leniveau de sécurité et d'en déterminer les vulnérabilités. Cependant, cette technique est utilisée
par les pirates informatiques pour repérer les failles de sécurité d'un système ou d'un réseau,
pouvant mener une attaque de plus grande envergure plus tard.
Le Portscan TCP
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 22/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
22
Le balayage de port en informatique, appelé Portscan en anglais, est une technique qui
permet de chercher les ports ouverts chez un hôte du réseau. Elle est souvent utilisée par les
pirates informatiques pour tenter de compromettre la sécurité d¶un hôte. Le balayage de ports
est l¶une des activités considérées comme suspectes par un Système de détection d'intrusion.
Pour tromper la vigilance de ces systèmes, les balayages peuvent se faire dans un ordrealéatoire, avec une vitesse excessivement lente, ou à partir de plusieurs adresses IP.
Un balayage de ports le plus réputé vise typiquement le protocole TCP car c'est celui
qui est utilisé par la majorité des applications. L'objectif est de savoir si un logiciel est en
écoute sur un numéro de port donné ou non. Si un logiciel écoute, on dit que le port est
ouvert , sinon on dit qu'il est fermé. Le balayage d'un port se passe en deux étapes :
- Envoi d'un paquet sur le port testé ;
- Analyse de la réponse.
Il existe de nombreuses variantes pour le paquet émis. Il y a le paquet valide selon la
norme TCP, le paquet « TCP SYN », et les paquets invalides. L'intérêt des paquets non
standards est de tromper les systèmes de détection d'intrusion pour passer inaperçu.
Autre type de Portscan
Pour le protocole UDP, on envoie un paquet UDP vide (de longueur nulle). Si le port est
fermé, un message ICMP de type 3 (destinataire inaccessible) et code 3 est envoyé. Il est
également possible de lister les protocoles IP supportés par un hôte. On appelle cettetechnique IP protocol scan.
3.2.4. Remote to Local access (R 2L) [12] :
Dans ce type d¶attaque, le pirate exploite les failles du système afin de gagner un accès
local dans la machine distante. Parmi les nombreux exemples d¶attaques de type R2L, nous
citons :
SQL Injection
Il s¶agit d¶une faille de sécurité d¶une application Web (généralement au niveau des
formulaires), qui consiste à modifier et insérer des données (code malveillant) dans les
chaînes transmises ultérieurement à une instance de SQL Server en vue de les exécuter. Ainsi,
l¶attaquant peut accéder à un compte local sans pour autant avoir le droit.
Cracking des mots de passe
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 23/116
Chapitre I : La sécurité des réseaux informatiques
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
23
Cette attaque prouve qu¶aucun mot de passe n¶est inviolable. En effet, il existe trois
méthodes pour cracker un mot de passe, soit avec le dictionnaire (un simple fichier texte
contenant un mot par ligne, les uns à la suite des autres), soit par brut force (à essayer toutes
les combinaisons possibles suivant un certain nombre de caractères), soit combiner les deux
précédentes méthodes.
3.3. Les politiques de sécurité :
Toutes les politiques de sécurité sont basées sur le fait de mettre en évidence les
objectifs attendus ainsi que les moyens de l¶entreprise, ensuite analyser le tout afin de générer
les procédures à mettre en pratique pour atteindre le niveau de sécurité conforme aux besoins
auparavant étudiés.
Parmi les nombreuses méthodes permettant de mettre au point une politique de sécurité,
nous pouvons citer à titre d¶exemple la méthode MEHARI [10], MARION [10], EBIOS [10],
COBIT [11], etc. [Voir Annexe C]
4. Conclusion :
Dans ce chapitre il y a eu définition des réseaux informatiques (architectures, topologies
et protocoles) suivie d¶une concrétisation des types de risques et d¶attaques qui pèsent sur ces
réseaux, ainsi que les politiques de sécurité permettant de palier aux différents problèmes de
l¶insécurité.
Une unique méthode pour sécuriser un réseau n¶existe pas. Ainsi le déploiement de
plusieurs entités (pare-feux, mise-à-jours quotidiennes, systèmes de détection d¶intrusion ),
visant à renforcer la sécurité, est primordial.
Le chapitre suivant portera l¶attention aux systèmes de détection d¶intrusions.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 24/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
24
Chapitre II : Les systèmes de détection d¶intrusions
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 25/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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é.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 26/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 27/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
27
En prenant comme exemple l¶IDS SNORT, nous constatons qu¶il génère les alertes sous
plusieurs formes contrôlées par l¶instruction « output ». Voici un exemple :
³Output database: log, mysql, user=root dbname=snort host=localhost´
Parfois, les systèmes de détection d¶intrusions commettent des erreurs que nous pouvons
répartir en deux catégories :
� Les faux positifs : cette erreur signifie que l¶IDS détecte une intrusion qui n¶a pas
été perpétrée réellement.
� Les faux négatifs : à l¶inverse de « faux positives », l¶IDS ne signale aucune
intrusion alors qu¶il y en a au moins une.
Logs
Les logs sont des lignes d¶un fichier dans lesquelles un IDS enregistre les donnéestransitant sur un système pour les analyser et faire des statistiques. Le fichier dans lequel ces
informations sont sauvegardées est appelé fichier log qui peut être en format texte ou binaire.
Sondes
La machine sur laquelle le système de détection d¶intrusions est lancé, est appelée
« sonde » puisqu¶elle est utilisée pour écouter le trafic du réseau.
Pot de miel ( H oneyPot)
Les pots de miels sont des systèmes utilisés pour leurrer les pirates en exposant
volontairement des vulnérabilités. Lorsqu¶un attaquant trouve un pot de miel, il va passer un
certain temps à « pirater », ce qui permettra d¶enregistrer ses activités, de les étudier et les
anticiper afin de connaître ses actions et techniques. Les informations recueillies sont utiles
pour renforcer la sécurité de notre système. La tâche principale d'un pot de miel consiste à
analyser le trafic, c'est-à-dire à informer du démarrage de certains processus, de la
modification de fichiers, etc. permettant ainsi de créer un profil élaboré des attaquants
potentiels sans qu¶ils ne s'en doutent. »
2.2. Types des IDS :
Il existe plusieurs types d¶IDS et le point commun entre tous c¶est la détection
d¶intrusion. Le choix d¶un IDS coïncide avec son mode d¶utilisation ainsi que
l¶environnement qu¶il va le contenir.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 28/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
28
2.2.1. NIDS :
Un NIDS ou Network IDS, est un système de détection d¶intrusions qui capture les
données circulant dans un réseau, les compare avec sa base de signatures. Si un paquet
correspond à la signature d¶un intrus, une alerte est générée et le paquet est enregistré dans un
fichier log ou dans une base de données. A titre d¶exemple nous citons : « SNORT » [13],« BRO » [14], etc.
2.2.2. HIDS :
Un HIDS ou Host IDS, est un système de détection d¶intrusions qui travaille sur une
seule machine (hôte). Il récupère les informations du système d¶exploitation et des journaux
afin de détecter d¶éventuelles intrusions. Prenons comme exemple de HIDS : « AIDE » [15],
etc.
2.2.3. IDS hybrides (NIDS+HIDS) :
Les IDS hybrides rassemblent les caractéristiques de NIDS et HIDS. Généralement
utilisés dans un environnement décentralisé, ils permettent, en un seul outil, de surveiller les
réseaux et les terminaux. Les sondes sont placées en des points stratégiques, et agissent
comme NIDS et/ou HIDS suivant leurs emplacements. Toutes ces sondes remontent alors les
alertes à une machine qui va centraliser le tout, et agréger/lier les informations d'origines
multiples. Tel est l¶exemple de « Prelude » [16].
3. IDS versus Firewall :
Chaque ordinateur connecté à Internet (ou à n'importe quel réseau informatique) est
susceptible d'être victime d'une attaque d'un pirate informatique.
Ainsi, il est indispensable, autant pour les réseaux d'entreprises que pour les internautes,
de se protéger des intrusions réseaux en installant un dispositif de protection, à savoir un pare-
feu (Firewall), et/ou un système de détection d¶intrusions (IDS).
Il est donc intéressant de connaître la différence entre ces deux dispositifs et de savoir sil¶utilisation de l¶un des deux suffit pour assurer la sécurité du système.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 29/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 30/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
30
important peut engendrer des pertes de fiabilité et que dans cette position, le NIDS est exposé
à des éventuelles attaques puisqu¶il n¶est plus protégé par le pare-feu.
Figure II.1 : IDS installé avant le Firewall
Si par contre, nous voulons détecter les intrusions à l¶intérieur du réseau de l¶entreprise,
nous devons placer le NIDS dans le réseau interne, soit sur chaque segment du réseau ou juste
sur les zones sensibles du réseau comme le monter la ( Figure II.2).
Cet emplacement nous permet d¶observer les tentatives d¶intrusion parvenues à
l¶intérieur du réseau d¶entreprise ainsi que les tentatives d¶attaques à partir de l'intérieur.
Figure II.2 : IDS installé après le Firewall
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 31/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
31
On peut aussi placer l¶IDS dans une zone connue comme étant la plus sensible du réseau,
cette zone peut contenir : des serveurs (web, fichiers, ase de données), des mainframes, ).
On appelle cette zone DMZ, ou bien Zone démilitarisée.
Figure II.3 : IDS installé dans la DMZ
Comme on peut aussi admettre le cas d¶une mise en place de plusieurs sondes SNORT,
chacune sur un segment sachant que, plus le nombre de NIDS est grand, leur gestion devient
difficile et coûteuse.
Figure II.4 : Sondes SNORT placées de part et d¶autre sur le réseau
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 32/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
32
4. Méthodes de détection d'intrusions :
En général, il existe deux grandes familles de détection d'intrusions, à savoir
l'approche comportementale et l'approche par scénario.
4.1. Approche comportementale :
« Cette approche, proposée par Anderson dès 1980 et reprise par Denning et Whiterhurst en
1987 est basée sur l¶hypothèse qu¶une intrusion implique un usage anormal du système et
donc un comportement inhabituel d¶un utilisateur. On parle alors de profil utilisateur ou
comportement d'une application. » [17]
Dans cette approche, il s¶agit de décrire le profil utilisateur et modéliser son
comportement afin de détecter par la suite toute déviation de son comportement habituel ainsi
appris. Ainsi, cette approche cherche à répondre à la question suivante : « Le comportementactuel de l¶utilisateur est-il cohérent avec son comportement passé ? »
Parmi les approches comportementales les plus utilisées [18], nous citons :
L¶approche statistique : consiste à quantifier de manière fine toute une série de
paramètres liés à l¶utilisateur tels que : taux d¶occupation mémoire, utilisation du
processeur, valeur de la charge réseau, nombre d¶accès a l¶Intranet par jour, sites web
les plus visités, vitesse moyenne de frappe au clavier, etc. Toutes fois, la complexité de
cette approche ainsi que son faible niveau de fiabilité, font qu¶elle n¶est présente que
dans le domaine de la recherche.
L¶approche probabiliste : définit le fonctionnement d¶une application à partir
d¶événements observés. Il y aura un établissement des règles et un apprentissage des
probabilités liés à chaque séquence d¶événements. L¶approche par réseaux de neurones : permet de surveiller directement le
comportement d¶un utilisateur (chacun peut être identifié par son comportement tel que
ses habitudes de travail, ses activités, ses outils de travail, etc.). Donc pour construire le
profil de chaque utilisateur, on utilise les réseaux de neurones dont chacun reconnaît
une suite d¶opérations effectuée par cet utilisateur. Ceci va nous permettre de prédire
l¶opération suivante, en cas d¶échec une alerte est levée. L¶immunologie : analogique à l¶immunologie biologique, consiste à observer les
services (et non pas les utilisateurs) pendant un temps suffisamment représentatif de
manière à établir un modèle de comportement normal. Le comportement observé sera
donc comparé avec le modèle de comportement normal.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 33/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
33
Les graphes : c¶est une approche à base de graphes qui permettent de mettre en
évidence des propriétés et des relations entre ces propriétés. Son intérêt, c¶est qu¶elle
permet de traiter plus facilement des événements rares.
4.2. Approche par scénario :Cette approche, « proposée pour pallier les inconvénients de l¶approche
comportementale, cherche à retrouver des attaques connues dans le fichier d'audit. Elle
nécessite donc une connaissance préalable des attaques bien définies. Cette approche cherche
alors à répondre à la question suivante : « Le comportement actuel de l'utilisateur contient-il
une attaque connue?". Dans ce cas, il est nécessaire de construire une base de données
d'attaques ou de scénarios d'attaques. » [19]
D¶une manière générale, la recherche des attaques dans les données se fait par
application de techniques d¶analyse de signature (appelée recherche de motif).
La recherche de motif [20] ( Pattern Matching en anglais), permet de localiser une
occurrence d¶un mot (motif) dans un texte. Il existe deux catégories de recherche de motif,
une avec motifs fixes et texte variant (c¶est le cas des NIDS), et l¶autre avec motifs variants et
texte fixe (comme la recherche dans un dictionnaire). Parmi les algorithmes [Voir Annexe E]
utilisés dans cette approche nous citons :
Algorithme naïf (appelé en anglais Brute Force Algorithm), consiste à vérifier pour
chaque position dans le texte si une occurrence de motif commence à cette position ou
pas. Si oui, il le signale. Sinon il recommence en avançant d¶une position à droite.
Algorithme de Knuth-Morris-Pratt : cet algorithme effectue un pré traitement du
motif, qui fournit une information suffisante pour déterminer ou continuer la recherche
en cas de non correspondance. Cela permet à l¶algorithme de ne pas réexaminer les
caractères qui ont été précédemment vérifiés, et donc de limiter le nombre de
comparaisons nécessaires.
Algorithme de Boyer-Moore : cet algorithme effectue un pré traitement du motif, et
au lieu d¶effectuer la recherche de la gauche vers la droite, il l¶effectue à l¶inverse. Cette
particularité s¶avère rentable vu la rapidité de cet algorithme.
Algorithme Aho-Corasick : le fonctionnement de cet algorithme est unegénéralisation de l¶algorithme Knuth-Morris et Pratt, sa particularité réside dans la
recherche parallèle de plusieurs motifs.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 34/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
34
4.3. Tableau comparatif :
Le tableau qui suit présente les avantages et les inconvénients des deux approches
définies précédemment :
Approche comportementale Approche par scénario
Avantages
- Pas besoin d¶une base d¶attaques.
- Détection d¶intrusions inconnues
possible.
- Prise en compte des comportements
exacts des attaquants potentiels :
peu de faux positifs
« Rien n¶est jamais sûr ! »
Inconvénients
- Pour un utilisateur au
comportement erratique (irrégulier),
toute activité est normale.
- En cas de profonde modification
de l¶environnement du système cible,déclenchement d¶un flot ininterrompu
d¶alarmes :
gros risque de faux positifs
- Utilisateur pouvant changer
lentement de comportement afin
d¶habituer le système à un
comportement intrusif :
risque de faux négatifs
- Base de scénarios, difficile à
construire et à maintenir :
risque de faux négatifs
- Pas de détection d¶attaques non
connues :
risque de faux négatifs
- Détection de scénarios complexes
difficile.
Tableau II.1 : Comparaison entre les approches adoptées dans la détection d¶intrusion
5. SNORT :
Alors que les attaques des réseaux prennent de l¶ampleur, et que les failles de sécurités
de cessent d¶augmenter, seul une multitude de mécanismes de sécurité permettra de tirer du
néant l¶insécurité des systèmes d¶informations. En complément pour les pare-feux, les
systèmes d¶authentifications et autres dispositifs de sureté, le choix de l¶IDS Open source
« SNORT » est fait car il est considéré parmi les meilleurs dans le domaine de la détection
d¶intrusions [Voir Annexe D].
5.1. Présentation :
SNORT est un NIDS écrit par Martin Roesch, disponible sous licence GNU, son code
source est accessible et modifiable à partir de l¶URL : « http://www.snort.org »
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 35/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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 :
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 36/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
36
Figure II.5 : Architecture de Snort
5.3. Modes de détection d¶intrusions :
SNORT permet d¶analyser le trafic réseau de type IP, il peut être configuré
pour fonctionner en quatre modes :
Le mode Sniffer : dans ce mode, SNORT lit les paquets circulant sur le réseau et les
affiche d¶une façon continue sur l¶écran.
Le mode « Packet Logger » : dans ce mode SNORT journalise le trafic réseau sur
le disque.
Le mode détecteur d¶intrusion réseau (NIDS) : dans ce mode, SNORT analyse le
trafic du réseau, compare ce trafic à des règles déjà définies par l¶utilisateur et établi
des actions à exécuter (Alertes).
Le mode Prévention des intrusions réseau (IPS).
5.4. Implémentation de SNORT :
SNORT est un IDS spécialement conçu pour s¶exécuter sur différents systèmes
d¶exploitation, le cas du projet traité dans ce rapport, implique son installation sur un
environnement Windows, pour qu¶ensuite il s¶approvisionne de l¶application en cours de
développement baptisé « ALS ».
Afin de comprendre son fonctionnement en termes d¶adaptation logicielle, la figure qui
suit ( Figure II.6 ) montre les interactions entre SNORT ainsi que sa base de données, et plusloin encor avec l¶application « ALS ».
1 : Capture des paquets
2 : Analyse des paquets
3 : Enregistrement dans la
base de données
4 : Configuration deSNORT par ALS »,
démarrage/arrêt, retour
des résultats.5 : Analyse des logs
enregistrés dans la base
de données
Figure II.6 : Interactions au sein du système
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 37/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
37
6. Comparatif entre IDS Open source :
Afin de confirmer le choix fait pour l¶IDS SNORT, une recherche a été effectuée sur
d¶autres IDS Open Source célèbre, ainsi des comparaisons avec SNORT ont eu lieu seloncertains critères. Les IDS choisis pour cette partie sont Prelude et Bro. Ceci a permis de
distinguer SNORT parmi ces siens.
6.1. Prelude [16] :
6.1.1. Présentation :
Prelude IDS est un système de détection d¶intrusions sous licence GPL disponible sur
les plateformes Linux, FreeBSD et Windows. La détection d¶intrusions est réalisée par
l¶analyse du trafic réseau, et l¶utilisation d¶une base de signatures. Lors d¶une analyse dutrafic, l¶analyseur de Prelude confronte les données aux signatures. S¶il détecte une intrusion,
il génère une alerte détaillée contenant l¶adresse IP source et destination, le degré de criticité
et d¶autres informations.
Prelude est un IDS hybride très performant surtout avec sa configuration facile et son
architecture client/serveur qui permet à un manager de gérer plusieurs sondes. Mais il faut
noter que la documentation sur Prelude et parsemée et contient parfois des erreurs.
6.1.2. Architecture et Composants :
Prelude possède une architecture modulaire, distribuée et sécurisée. Modulaire, car sescomposants sont indépendants, d¶où il est plus facile d¶intégrer ou de développer de nouvelles
fonctionnalités grâce à des « plugins ». Distribuée, car ses composants autonomes
interagissent les uns avec les autres, cela permet d¶avoir des composants installés sur
différentes machines ainsi nous pouvons réduire la surcharge d¶applications. Sécurisée avec
l¶utilisation du support SSL7 pour l¶authentification et le chiffrement des communications.
Les différents composants de Prelude sont les sondes et les managers. Les sondes
signalent les tentatives d¶attaques par les alertes. Le manager reçoit ces alertes, les interprète
et les stocke. Prelude a l¶avantage d¶être très modulaire de par son architecture Client -
Serveur. Un manager peut gérer plusieurs sondes et une sonde peut envoyer ses alertes à
plusieurs managers. Cependant, le filtrage au niveau de la sonde pour savoir à quel manager
est envoyée telle alerte n¶est pas encore opérationnel.
7 SSL (Secure Sockets Layers) est un procédé de sécurisation des transactions effectuées via Internet.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 38/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
38
6.2. Bro [14] :
6.2.1. Présentation :
Bro est un système de détection d¶intrusions sous licence libre disponible seulement
sous Unix. Bro se base sur un ensemble de règles décrivant des signatures d¶attaques ou desactivités inhabituelles. Le comportement de Bro lors de la détection d¶une intrusion, peut être
paramétré. En effet, il peut alerter l¶administrateur en temps réel, enregistrer dans un fichier
log ou même exécuter une commande du système d¶exploitation (arrêter la connexion,
bloquer l¶attaquant, etc.).
Bro utilise son propre langage qui permet d¶exprimer les signatures comme étant des
expressions régulières et non pas des chaînes de caractères fixes. Ceci permet de renforcer son
analyseur, puisqu¶en plus d¶analyser le trafic, l¶analyseur de Bro peut comprendre le contenu
des paquets, ce qui permet de minimiser les fausses alertes. L¶inconvénient avec les alertes de
Bro, c¶est qu¶elles ne sont pas bien détaillées et donc difficiles à interpréter.
6.2.2. Architecture et composants :
Bro possède une architecture composée de trois couches. La première contient le capteur
de paquet qui est chargé de sniffer le trafic réseau, de capturer les paquets et de les transmettre
à la couche supérieure. Cette dernière, contient le moteur d¶événement (Event Engine) qui est
chargé d¶effectuer une analyse protocolaire dynamique, contrôler l¶intégrité des paquets,
émettre des alertes en cas d¶anomalies et rassembler les paquets fragmentés si nécessaires. La
troisième couche est la couche de politique, traite les événements reçus de l¶Event Engine, et
applique les politiques écrites dans les scripts Bro.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 39/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
39
6.3. Comparatif Snort, Prelude et Bro :
Critères Snort Prelude Bro
Année de création 1998 1998 1998
Auteur Martin Roesch YoannVanndoorselaere
Vern Paxson
Licence Open source Open source Open source
Plateforme Toutes les plateformes Linux, FreeBSD etWindows
Unix
Base de signatures Riches et à jour Limitée Limitée
Difficulté deConfiguration
Moyenne, nécessitedes compétences
Facile Facile grâce à un scriptinteractif
Remontée desinformations En continu Pulsation (Batch) En continu
Moteur d¶analyse Confrontation avec unebase des signatures
Confrontation avec unebase des signatures
Confrontation avec unebase des signatures
Informations dans lesalertes
Alertes bien détaillées Alertes bien détaillées Alertes mal détaillées
Popularité (Nombrede téléchargements)
Très populaire (grandnombre)
Popularité moyenne(nombre moyen)
Un peu
Intégration d¶outilsexternes
Ne permet pasl¶intégration d¶outils
Permet l¶intégration Permet l¶intégration
Documentation Très bien documenté Peu de documentationet avec des erreurs
Peu de documentation
TCP connect scan Résultat correct Pas de résultat Résultat correct
TCP SYN scan Résultat correct Pas de résultat Résultat correct
TCP NULL scan Résultat correct Pas de résultat Pas de résultat
Tableau II.2 : Comparaison entre IDS¶s OpenSource
Les résultats relevés de cette comparaison coïncident avec les besoins demandés et ont permis, entre autres, de choisir SNORT qui s¶avère le plus efficace parmi les autres IDS Open
Source.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 40/116
Chapitre II : Les systèmes de détection d·intrusions
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 41/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
41
Chapitre III : Atelier de génie logiciel & Conception 2TUP
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 42/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
42
1. Introduction :
Ce projet conduit a la réalisation d¶une application de gestion et d¶analyse de Logs
pour l¶IDS SNORT ; une réalisation qui adopte une méthodologie connue et supporté par la
conception UML. Le choix du langage de programmation, lui aussi, aura sa place dans sechapitre. Ainsi tous les composants impliqués dans ce projet seront mis en évidence afin de
bâtir le tout sur de bonnes bases.
2. Modélisation et Méthodologie adoptées :
2.1. Langage de modélisation unifié (UML) :
« Uml : Langage d'analyse et de conception orienté objet défini par l'OMG (Object
Management Group). UML homogénéise les représentations graphiques des objets issues des
travaux de Grady Booch chez Rational Software, de Rumbaugh et d'Ivar Jacobson. » [24]
UML est conforme aux besoins de la programmation orientée objet ; l¶un des points
forts de ce langage, c¶est qu¶il peut être intégré dans n¶importe quel processus de
développement logiciel de manière transparente.
2.2. Processus Unifié (UP) et sa variante 2TUP :
Pour veiller à produire une bonne modélisation avec le langage UML, il convient
d¶utiliser un Processus Unifié (UP). Ce dernier est porté par une grande considération dans le
développement logiciel.
y « Il est itératif et incrémental. La définition d¶itérations de réalisation est en effet la
meilleure pratique de gestion des risques d¶ordre à la fois technique et fonctionnel.
On peut estimer qu¶un projet qui ne produit rien d¶exécutable dans les 9 mois court
un risque majeur d¶échec. Chaque itération garantit que les équipes sont capables
d¶intégrer l¶environnement technique pour développer un produit final et fournit
aux utilisateurs un résultat tangible de leurs spécifications. Le suivi des
itérations constitue par ailleurs un excellent contrôle des coûts et des délais.y Il est piloté par les risques. Dans ce cadre, les causes majeures d¶échec d¶un
projet logiciel doivent être écartées en priorité. Nous identifions une première cause
provenant de l¶incapacité de l¶architecture technique à répondre aux contraintes
opérationnelles, et une seconde cause liée à l¶inadéquation du développement aux
besoins des utilisateurs.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 43/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
43
y Il est construit autour de la création et de la maintenance d¶un modèle, plutôt que de
la production de montagnes de documents. Le volume d¶informations de ce modèle
nécessite une organisation stricte qui présente les différents points de vue du
logiciel à différents degrés d¶abstraction. L¶obtention de métriques sur le
modèle fournit par ailleurs des moyens objectifs d¶estimation.
y Il est orienté composant. Tant au niveau modélisation que production, c¶est
une garantie de souplesse pour le modèle lui-même et le logiciel qu¶il représente.
Cette pratique constitue le support nécessaire à la réutilisation logicielle et offre des
perspectives de gains non négligeables.
y Il est orienté utilisateur, car la spécification et la conception sont construites à partir
des modes d¶utilisation attendus par les acteurs du système. » [25]
L¶une des variantes du processus unifié, est le processus 2TUP « 2 Track UnifiedProcess », c¶est un processus qui vise à fusionner les résultats évolutifs du modèle fonctionnel
et de l¶architecture technique, pour y parvenir, après fusion, à l¶obtention d¶un processus en
forme de Y (Figure III.1).
Figure III.1 : Processus de développement en Y [25]
La branche gauche (contraintes fonctionnelles) comporte :
y la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé
sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système
inadapté aux utilisateurs. De son côté, la maîtrise d¶uvre consolide les
spécifications et en vérifie la cohérence et l¶exhaustivité.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 44/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
44
y L¶analyse, qui consiste à étudier précisément la spécification fonctionnelle de
manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les
résultats de l¶analyse ne dépendent d¶aucune technologie particulière.
La branche droite (contraintes technique) comporte :
y La capture des besoins techniques, qui recense toutes les contraintes et les choixdimensionnant la conception du système. Les outils et les matériels sélectionnés
ainsi que la prise en compte de contraintes d¶intégration avec l¶existant
conditionnent généralement des pré requis d¶architecture technique ;
y La conception générique, qui définit ensuite les composants nécessaires à la
construction de l¶architecture technique. Cette conception est la moins dépendante
possible des aspects fonctionnels. Elle a pour objectif d¶uniformiser et de réutiliser
les mêmes mécanismes pour tout un système. L¶architecture technique construit le
squelette du système informatique et écarte la plupart des risques de niveau technique.
L¶importance de sa réussite est telle qu¶il est conseillé de réaliser un prototype pour
assurer sa validité.
La branche du milieu comporte :
y La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d¶analyse dans l¶architecture technique de manière à tracer la cartographie des
composants du système à développer ;
y La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
y L¶étape de codage, qui produit ces composants et teste au fur et à mesure les unités de
code réalisées ;
y L¶étape de recette, qui consiste enfin à valider les fonctions du système
développé.
Comme on l¶a indiqué précédemment, on ne peut utiliser 2TUP qu¶en ayant recours à
UML, ceci dit, il va falloir indiquer chaque un des diagrammes à utiliser dans chaque étape du
processus de développement. Le tableau (Tableau III.1) qui fait correspondre les diagrammes
d¶UML aux différents points de vue du modèle.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 45/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
45
Tableau III.1 : Utilisation des diagrammes UML en fonction du point de vue du modèle. [25]
En complément pour le tableau ci-dessus :
Capture des besoins fonctionnels : les diagrammes de cas d¶utilisation, de
séquence, de collaboration, d¶activités et de classes (en option).
Analyse : les diagrammes de classe, d¶états et d¶objets (en option).
Capture des besoins techniques : les diagrammes de classes (en option), de cas
d¶utilisation, de séquence (en option), de collaboration (en option) et d¶activités.
Conception générique : les diagrammes de composants et de déploiement.
Conception préliminaire : les diagrammes de classes, d¶objets (en option), de
séquence, de collaboration et d¶états avec une complémentarité par le diagramme
de composants.
Conception détaillée : mêmes diagrammes que ceux de la conception détaillée
mais avec un niveau d¶analyse plus détaillé.
3. Choix des langages et des outils de programmation :
Java est un langage de programmation objet, reconnu pour ces qualités en termes de
portabilité ; l¶une des raisons pour lesquelles il a été choisi comme langage, c¶est sonadaptation facile aux différents systèmes d¶exploitation, pourvu qu¶on doive se munir de la
machine virtuelle Java (JVM : Java Virtual Machine) correspondante aux critères que le
logiciel possède.
Le code source de l¶application ALS à été implémenté avec l¶outil de programmation
NetBeans IDE en sa version 6.5.1, incluant la JVM de version 1.5.0_09-b03. Disponible en
téléchargement à l¶adresse « http://www.netbeans.org »
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 46/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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]
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 47/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
47
Identification des acteurs8
:
Super_user : Utilisateur ayant toutes les fonctionnalités en main pour modifier les règles, créer de nouvelles, accéder à toute la base de données en modeinterpréteur SQL, et aussi ajouter/supprimer des utilisateurs.
Network_manager : Cet acteur peut gérer SNORT, dont ses signatureset les logs qu¶il stocke, peut aussi accéder à la base de données en mode interpréteur SQL.
User_without_privileges : C¶est l¶acteur ayant le moins defonctionnalités en vue, il ne peut consulter que les statistiques et les données qui leurscorrespondent.
Liste préliminaire des cas d¶utilisations :
Cas d¶utilisation Acteurs Messages
Consulter les statistiques Super_user
Network_manager
User_without_privileges
Requêtes SQL
S¶authentifier Super_user
Network_manager
User_without_privileges
Requêtes SQL
Gérer les signatures Super_user
Network_manager
Message de modification
d¶état
Editer un rapport d¶audit Super_user Network_manager
Message de demande d¶état
Gérer la base de données Super_user
Network_manager
Requêtes SQL
Configurer l¶application Super_user Message de modification
d¶état
Tableau III.2 : Tableau des cas d¶utilisations préliminaires
Diagramme des cas d¶utilisations
Après identifications des acteurs ainsi que des cas d¶utilisation de notre application,l¶illustration qui suit ( Figure III.3 : Diagramme des cas d¶utilisations) fait son apparition pour
schématiser les interactions entre les différentes entités et les cas dµutilisations
correspondants. Cette figure indique les privilèges que chaque acteur possède, autrement dit,
les cas d¶utilisations qui lui sont propre.
8 Intervenant direct sur un système
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 48/116
Chap¡ ¢
£ e III
¤
¥ ¢
e¦
¡
e£
de gén¡
e¦ og
¡
c¡
e¦ & Concep
¢ ¡
on 2§
¨ ©
¥
na¦
eu£
de Log
pou£
§
a
£ a
¦
¥
L
48
F i ! " # $ III. % & ' i ( ! # ( mm$ ) $ 0 1 ( 0 ) ¶ " 2 ili 0 ( 2 i 3 4 0
Remarque : pour le reste des diagrammes concernant cette section, tous les acteurs
seront représentés par un seul, ayant pour nom AC 5 E 6 R ( F i7 8 9 @
A A A
B
C
D
E
F t @ 8 9 G
H
8
G I G t P
Q @ ).
F i R S T U III. V W X
Y ` U S T a b S a
c
a ` d mU
Diagramme de séquences
A ce st e, les fonctionnalit s du syst e sont celle pr inci palement effectuées par
l application ainsi que la base de données qu¶elle gère, ceci dit, il est nécessaire de préciser
que le modèle de cette application suit celui du Client serveur. En effet, ALS gère l¶outil, qui
Super-user User_without_privilegeNetwork_manager
Acteur
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 49/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
49
est caché derrière, SNORT ; En acceptant les demandes qu¶elle reçoit, effectue les traitements
nécessaires, et renvoie les résultats associés.
Figure III.5 : Diagramme de séquence géneralisé
4.1.2. Analyse :
L¶analyse est la deuxième phase de la branche fonctionnelle du processus 2TUP. Visant à
étudier la spécification fonctionnelle et induisant une idée sur les accomplissements du
système.
Figure III.6 : Etape actuelle du 2TUP [26]
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 50/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
50
Diagramme de séquences
Afin de comprendre l¶accessibilité aux différents cas d¶utilisations du système, le schéma qui
suit ( Figure III.5 : Diagramme d¶ activités géneralisé) exprime le comportement de « ALS »
vis-à-vis de l¶utilisateur final tout en généralisant les cas d¶utilisations en un seul.
Figure III.7 : Diagramme d¶activités de point de vue fonctionnel
Développement du modèle statique
Le modèle statique, est fondé sur le fait de schématiser un diagramme de classes, comportant
les classes participantes à la phase « Capture des besoins fonctionnels ». La concentration sera
portée au dialogue entre L¶utilisateur et l¶application qui gère SNORT, intitulé ALS.
Les classes solliciteuses :
La classe « Start » : Sert d¶interface de dialogue entre SNORT et l¶utilisateur en offrant les
menus permettant d¶assurer le démarrage/arrêt des services de SNORT, ainsi que les services
proposés par l¶application elle-même.
La classe « Sqlbd » : permet de gérer la base de données imposée par SNORT et résultante
d¶ALS ; tout en stockant, modifiant ou affichant le contenu.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 51/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
51
La classe « Auth » : Assure l¶accès aux différents utilisateurs selon les privilèges que chacun
d¶eux possèdent.
La classe « Paramsnort » : Paramètre SNORT selon les demandes de l¶utilisateur, ces
demandes peuvent concerner : Le mode de fonctionnement de SNORT ; l¶ajout, la création,
ou la suppression des règles ; la consultation des alertes selon des critères définies.
Ainsi, succinctement, le diagramme des classes généralisé sera le suivant :
Figure III.8 : Diagramme de classe de point de vue fonctionnel
Développement du modèle dynamique
Il s¶agit d¶étudier le système d¶un point de vue dynamique afin de préciser les interactions
entre les objets et les états des classes. Il est alors primordial de schématiser ce relais par undiagramme d¶état. ( Figure III.8)
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 52/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
52
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]
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 53/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 54/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
54
L¶application « ALS » sera la tierce partie d¶un ensemble (SNORT + Base de Données) déjà
existant, d¶où la première intension d¶implémenter les tables crées par « ALS » dans la base
de données même de SNORT, et ce pour assurer l¶accès aux données aux deux entités
principalement intervenantes.
Dans un premier temps, SNORT analyse le trafic en recherchant des flux comportantdes paquets semblables aux signatures d¶attaques et rempli sa base de logs.
Ensuite, « ALS » analyse les logs enregistrés pour en tirer des statistiques.
« ALS », peut aussi intervenir sur SNORT même en démarrant/arrêtant ou en
changeant ses critères de configuration selon la façon voulue d¶analyse de trafic.
Diagramme de cas d¶utilisations :
Figure III.11 : Diagramme des cas d¶utilisations raffiné
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 55/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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.
Figure III.13 : Diagramme de déploiement
4.3. Conception :
Afin d¶entamer la phase de conception qui consiste à fusionner notre étudefonctionnelle avec l¶étude technique. Il va falloir passer de l¶analyse objet à la conception.
Les interactions entre classes de conception permettent de consolider et de vérifier à terme
la conception des cas d¶utilisation fonctionnels tenant compte des contraintes
opérationnelles.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 56/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
56
4.3.1. Conception préliminaire :
Figure III.14 : Etape actuelle du 2TUP [26]
Diagramme de classesVue que le nombre de classes est grand, il serait préférable de donner un vue d¶ensemble à
l¶application, en schématisant le fonctionnement de cette dernière par un diagramme de classe
( Figure III.16 ) tout en sachant que les vrais noms des classes ne sont pas les mêmes indiqués
sur cette figure.
Figure III.15 :Diagramme de classes
Pour l¶authentification c¶est la classe « Auth » qui a été définie pour établir une
connexion avec la base de donnée et faire la correspondance entre l¶identifiant de
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 57/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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 :
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 58/116
Chape
f
g e III
h
i f
ep e e
g de gén
e e
p og
e c
e e
p & Concep
f
e on 2
q
r s
i
nap
t u
eug
de Logu
poug
v
w x y
q
x � a
g � a
�
u
� p �
i
� � L
58
F i � � � � III.
� �
� E
� �
�
�
� � � � � ll
�
� �
� � � P [26]
Dans cette par tie, les concepts provenant de l¶analyse vont être transformés en techniques
disponi bles selon les outils et langages de développement conventionnés.
La conception des associations, trainera les classes par tici pantes vues à l¶analyse, les
accompagne aux opérations de gestion et autres classes dont on a discuté l¶existence à la
conception préliminaire.
La conception des attr i buts se voit pr inci palement déf inir le type et la visi bilité des attr i buts.
Diagrammes des classes
Les deux étapes successives et précédentes permettront d¶aboutir à des diagrammes de classes
remarquables sur le plan des associations et des attr i buts.
Remarque :
Pour des soucis d¶impression concernant les diagrammes de classes, on va à chaque fois
focaliser sur une classe, la détailler et présenter les éventuels liens qu¶elle possède avec les
autres classes.
F i
III.
j
Lk
l l
k m m
n k i
o
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 59/116
Chap
e III
e e
de gén
e
og
c
e
& Concep
on 2
na
z
eu
de Logz
pou
{
| } ~
} a
a
z
L
59
F i III. � L � � l � � � P � � l
F i III.
�
� L
�
� l
� � � L
� � �
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 60/116
Chap
e III
e e
de gén
e
og
c
e
& Concep
on 2
na
�
eu
de Log�
pou
�
� � �
� � a
a
�
L
60
F i
III.
ª
L«
¬ l
« S
® « ®
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 61/116
Chap ̄
°
± e III
²
³ °
e´ ̄e
± de gén
̄e
́og
̄c
̄e
́& Concep
°
̄on 2
µ
¶ ·
³
na ́
̧ ¹
eu±
de Log¹
pou±
º
» ¼ ½
µ
¼ ¾ a
± ¿ a
À
¹
Á ´ ¿
³
 Á L
61
F i Ã Ä Å Æ
III.Ç È
É
LÊ
Ë
l Ê Ì Ì Æ
Í
Ä Î Ï
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 62/116
Chapitre III : Atelier de génie logiciel & Conception 2TUP
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
62
Figure III.22 : Ð a classeSqlbd
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 63/116
ChapÑ
Ò
Ó e III
Ô
Õ Ò
eÖ Ñ e
Ó de gén
Ñ e
Ö og
Ñ c
Ñ e
Ö & Concep
Ò
Ñ on 2
×
Ø Ù
Õ
naÖ
Ú Û
euÓ
de LogÛ
pouÓ
Ü
Ý Þ ß
×
Þ à a
Ó á a
â
Û
ã Ö á
Õ
ä ã L
63
F i å æ ç è III. é ê ë L ì í l ì î î è ï
ð ñ î
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 64/116
Chapò
ó
ô e III
õ
ö ó
e÷ ò e
ô de gén
ò e
÷ og
ò c
ò e
÷ & Concep
ó
ò on 2
ø
ù ú
ö
na÷
û ü
euô
de Logü
pouô
ý
þ ÿ
ø
ÿ ¡ a
ô ¢ a
£
ü
¤ ÷ ¢
ö
¥ ¤ L
64
F i ¦ § ¨ © III. L l © Vi ©
F i ¦ § ¨ ©
III.
L
l
©
© ¨
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 65/116
Chap
!
" e III
#
$ !
e% e
" de gén
e
% og
c
e
% & Concep
!
on 2
&
' (
$
na%
) 0
eu"
de Log0
pou"
1
2 3 4
&
3 5 a
" 6 a
7
0
8 % 6
$
9 8 L
65
F i @ A B C III. D E F L G H l G I I C P
G l C B Q C
F i @ A B C III. D R F L G H l G I I C C G l C B Q C
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 66/116
ChapS
T
U e III
V
W T
eX S e
U de gén
S e
X og
S c
S e
X & Concep
T
S on 2
Y
` a
W
naX
b c
euU
de Logc
pouU
d
e f g
Y
f h a
U i a
p
c
q X i
W
r q L
66
F i s t u v
III.w x
y
L�
� l
� � � v
�
� v m
�
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 67/116
Chap�
�
� e III
�
� �
e� � e
� de gén
� e
� og
� c
� e
� & Concep
�
� on 2
�
� �
�
na�
� �
eu�
de Log�
pou�
�
� �
�
� a
� a
�
�
�
L
67
F i j k l m III. n o L l m
l
F i z {
III.| }
~
L
l
{
z
F i III. � � � L � � l � � �
� �
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 68/116
Chap
e III
e e
de gén
e
og
c
e
& Concep
on 2
�
na
� �
eu
de Log�
pou
�
� �
� a
a
�
L
68
F i III. ª « ¬ L ® l ̄ ¯ °
±
² ³ ² ® ² l
F i
III.ª ª
¬
L ® l ̄
¯
°
±
́
±
F i III. ª µ ¬ L ® l ̄ ¯ °
±
³ ®
±
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 69/116
Chap¶
·
̧ e III
¹
º ·
e» ¶ e
̧ de gén
¶ e
» og
¶ c
¶ e
» & Concep
·
¶ on 2
¼
½ ¾
º
na»
¿ À
eu ̧
de LogÀ
pou ̧
Á
 à Ä
¼
à Ša
¸ Æ a
Ç
À
È » Æ
º
É È L
69
F i Ê Ë Ì Í
III.Î Ï
Ð
LÑ
Ò l
Ñ Ó Ó Í
Ô
Ó Õ Ö × Í
F i Ê Ë Ì Í III. Î Ø Ð L Ñ Ò l Ñ Ó Ó Í Ô
j Õ Ë Ù Ì
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 70/116
ChapÚ
Û
Ü e III
Ý
Þ Û
eß Ú e
Ü de gén
Ú e
ß og
Ú c
Ú e
ß & Concep
Û
Ú on 2
à
á â
Þ
naß
ã ä
euÜ
de Logä
pouÜ
å
æ ç è
à
ç é a
Ü ê a
ë
ä
ì ß ê
Þ
í ì L
70
F i î ï ð ñ III. ò ó ô L õ ö l õ ÷ ÷ ñ ø
÷ ÷ i ñ ù i ú ð
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 71/116
Chapû
ü
ý e III
þ
ÿ ü
e û e
ý de gén
û e
og
û c
û e
& Concep
ü
û on 2
¡
¢ £
ÿ
na
¤ ¥
euý
de Log¥
pouý
¦
§ ¨ ©
¡
¨ a
ý a
¥
ÿ
L
71
F i III. ! L " # l " $ $ E % i &
F i III. ' ! L " # l " $ $ ( ) % i 0 0
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 72/116
Chap1
2
3 e III
4
5 2
e6 1 e
3 de gén
1 e
6 og
1 c
1 e
6 & Concep
2
1 on 2
7
8 9
5
na6
@ A
eu3
de LogA
pou3
B
C D E
7
D F a
3 G a
H
A
I 6 G
5
P I L
72
F i Q R S T III. U V W L X Y l X ` ` T a b c i d S
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 73/116
Chape
f
g e III
h
i f
ep e e
g de gén
e e
p og
e c
e e
p & Concep
f
e on 2
q
r s
i
nap
t u
eug
de Logu
poug
v
w x y
q
x � a
g � a
�
u
� p �
i
� � L
73
F i � � � � III.
� �
� L
�
� l
� � � � S
�
� �
�
F i � � � �
III.
L
l
� S
�
j j
k �
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 74/116
Chapl
m
n e III
o
m
e l e
n de gén
l e
og
l c
l e
& Concep
m
l on 2
na
eun
de Log
poun
z
{ a
n | a
}
~ |
~ L
74
F i
III.
L
l
P
m
� � �
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 75/116
Chap�
�
� e III
�
e � e
� de gén
� e
og
� c
� e
& Concep
�
� on 2
na
eu�
de Log
pou�
� �
� � a
� � a
�
� �
� L
75
F i
III.
L
l
ª
« l
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 76/116
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 77/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
77
Chapitre IV : L¶application « A L S »
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 78/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
78
1. Introduction :
Le chapitre précédent, a traité la conception de « ALS », adoptant la méthodologie
2TUP. La conception, elle-même, demande au développeur une certaine clairvoyance, tandis
que le codage met le plus dévoué des programmeurs face à des difficultés imprévisibles.
Toute application qui voit le jour, conduit son utilisateur à rechercher et essayer les
fonctionnalités qu¶elle cache. Ce chapitre, permet de dénombrer les fonctionnalités de
« ALS », tout en gardant l¶il sur les techniques utilisées lors du codage de l¶application.
2. SNORT :
L¶environnement de travail, qui élit le projet en cour, se compose principalement deSNORT, un IDS Open Source, très connu pour ses innombrables qualités dans le domaine de
la sécurité informatique et précisément dans la détection d¶intrusions.
SNORT est, sans doute, compétent mais il présente des lacunes concernant sa
configuration, la gestion de ses règles et la consultation de ses logs.
ALS vient compléter SNORT pour n¶en former qu¶un seul système, IDS et analyseur
de logs. L¶installation et la configuration de SNORT sont détaillées à l¶Annexe D.
3. Résumé des difficultés rencontrées :
Difficultés liées à SNORTy Il a fallu chercher la version de SNORT qui supporte une base de données MySQL.
y La documentation de SNORT, disponible en téléchargement, n¶inclus que le système
d¶exploitation Linux. Il a donc fallu procéder par logique et des fois par tâtonnement
afin de pouvoir l¶installer correctement sur un environnement Windows.
y Il a fallu installer correctement les règles de détection et ensuite les définir dans le
fichier de configuration.
y Il a fallu aussi indiquer l¶emplacement qui va accueillir les logs, dans le fichier de
configuration.
Difficultés liées à la conception de l¶application
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 79/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
79
La décomposition de l¶application en plusieurs sous application s¶est opposé à la
qualité des diagrammes. Il a, donc, fallu généraliser et des fois décomposer les diagrammes
pour éviter l¶encombrement.
Difficultés liées au codage de l¶applicationy L¶utilisation des fenêtres internes (JInternalFrame) en Java à posé des soucis durant la
phase de codage, puisqu¶elles sont difficile à manuvrer.
y La communication en temps réel avec SNORT à imposé l¶utilisation d¶un thread qui
permet la récupération des données de la base afin de les analyser de façon claire et
sensé.
y SNORT utilise une façon bien particulière pour certaines information qu¶il récupère,
leur décodage à posé des problèmes qui ont demandés de l¶effort. A titre d¶exemple,
les adresses IP qu¶il récupère sont codées en Hexadécimal. Permet
4. Test de l¶application :
4.1. Présentation de « ALS » :
Comme son nom l¶indique, ALS, est un Analyseur de Logs pour S NORT. Il permet à ses
utilisateurs une manipulation automatisée de l¶IDS SNORT.
ALS admet les fonctionnalités suivantes :
La configuration de SNORT ;
La gestion des signatures de SNORT ;
L¶analyse des logs que génères SNORT ;
La gestion d¶une base de données commune à SNORT et ALS.
4.2. Tâches automatisés de SNORT :
L¶ajout de fichiers µBatch¶ a permis de rendre automatique certaines tâches tels que :
Le démarrage de SNORT qui est assuré par le fichier « test.bat » ;
L¶installation peut être faite à travers le fichier « install.bat » ;
Et enfin la désinstallation par le fichier « desinstall.bat ».
La figure qui suit, montre un exemple de code contenu dans le fichier permettant le démarrage
de SNORT.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 80/116
ChapÎ
Ï
Ð e IV
Ñ L·app
Ò Î ca
Ï
Î on «
Ó
LÔ
»
Ó
naÒ
Õ Ö
euÐ
de LogÖ
pouÐ
Ô
× Ø Ù
Ú
Ø Û a
Ð Ü a
Ý
Ö
Þ Ò Ü
Ó
ß Þ L
80
F i à á â ã
IV.ä
å P
â æ à â ç mm
ç è i
æ é B
ç è ê ë
4.3. Authenti ication :
La première interface qui apparait, permet à un utilisateur ayant un accès de s¶authentif ier à
l¶aide d¶un identif iant µLogin¶ et µMot de passeµ (Figure IV.1). Si l¶identif iant est incorrecte
un message d¶erreur apparait, après trois tentatives échouées, l¶application se referme
automatiquement (Figure IV.2).
F i ì í î ï
IV.ð
ñ I
ò ó ï î ô õ ö ï
÷ ¶
õ í ó ø ï ò ó i
ô i
ö õ ó i
ù ò
÷ ï «
ú
LS »
Si l¶identif iant est incorrecte un message d¶erreur apparait ; Après trois tentatives échouées,l¶application se referme automatiquement (Figure IV.2).
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 81/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 82/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
82
4.4.1. Démarrage de SNORT :
En démarrant SNORT, le voyant « etat de snort » passe du rouge au vert comme le montre la
figure ci-dessus (Figure IV.5).
Figure IV.5 : Etat de SNORT
4.4.2. Ecoute du trafic :
A son démarrage, SNORT commence à sniffer les paquets de données. La fenêtre qui assure
la fonctionnalité de l¶écoute est la suivante :
Figure IV.5 : Ecoute de SNORT
4.4.3. Choix de la sonde :
Le choix de l¶analyse peut se faire, à travers le choix d¶une sonde (s¶il en existe plusieurs).
Figure IV.6 : Analyse des sondes
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 83/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
83
4.4.4. Analyse des alertes :
On peut consulter les alertes d¶une manière générale,
Figure IV.7 :û
onsultation des alertes
En fonction des adresses IP source et destination :
L¶analyse peut se faire d¶une façon plus minutieuse et ceci en fonction des adresses IP source
et destination, à travers lesquels, un responsable réseau peut reconnaitre l¶origine de l¶attaque,
ainsi il peut prendre les décisions adéquates pour repousser l¶attaque.
Figure IV.8 :û
lassification des alertes selon les adresses IP
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 84/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
84
En fonction des ports TCP et UDP
L¶analyse, des ports impliqués dans les alertes, sert à indiquer d¶une manière plus précise la
cause de l¶attaque. Ainsi on peut fermer les ports susceptibles de donner un accès au réseau ou
aux ressources.
La figure qui suit permet au responsable du réseau de traquer les attaquants par leurs numérosde ports. Les graphes joints à chaque type de consultation, donneront une allure aux
statistiques des alertes.
Figure IV.9 :ü
lassification des alertes selon les ports source et destination
Analyse temporelle :Cette analyse permet de donner un aspect réparti des alertes suivant un intervalle de temps
que l¶utilisateur choisit. Ça peut être vu par heure, par jour, ou par mois.
Figure IV.10 : Analyse temporelle
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 85/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 86/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
86
Figure IV.13 : Ajout de fichiers de signatures
Figure IV.14 : Suppression de fichiers de signatures
Figure IV.15 : Activation désactivation de fichiers de signatures
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 87/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
87
Figure IV.16 : Activation désactivation de signatures d¶un fichier
4.6. Paramétrage de SNORT :
4.6.1. Configuration :
La configuration de SNORT se fait à travers un assistant inclus dans l¶application « ALS »,
tout enregistrement de configuration, fera diriger les informations vers le fichier
« snort.conf ».
Figure IV.17 :ý
onfiguration de SNORT
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 88/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
88
4.6.2. Installation et désinstallation :
L¶installation et la désinstallation, deux fonctionnalités guidées, indépendamment de « ALS »,
par des fichiers batch.
4.7. Paramétrage des utilisateurs :Cette fonctionnalité permet de supprimer, ajouter ou modifier un utilisateur. La figure qui suit
illustre ces trois cas possible.
Figure IV.18 : Gestion des utilisateurs
4.8. Gestion de la base de données :
4.8.1. Exécution de requêtes SQL :
Figure IV.19 : Execution de requêtes SQ þ
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 89/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
89
4.8.2. Vidage de la base de données :
Cette fonctionnalité n¶est accessible que pour un « super_utilisateur », avant son execution
elle est notifiée par un message de prévention Figure IV.20
Figure IV.20 : Vidage de la base de données
4.9. Aide :
L¶application comporte un menu d¶aide, pauvre en lui-même, mais qui offre une vision
génerale de « ALS ».
Figure IV.21 : A propos de ÿ A S ¡
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 90/116
Chapitre IV : L·application « A L S »
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 91/116
Conclusion
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
91
CONCLUSION
Le succès de la sécurité des réseaux diffère d¶une technologie à une autre ; il a vu naitre de
nouvelles solutions sécurisantes, comme il a apprécié la croissance distinguée dans larobustesse d¶autres.
Ce mémoire de fin d¶études ayant pour objectif, le développement d¶une application
complémentaire à l¶IDS SNORT et qui permet la gestion et l¶analyse des logs de ce dernier.
Cette application a été baptisée « ALS » relativement à Analyseur de Logs pour SNORT.
Offrant une multitude de fonctionnalités qui permettent une gestion complète de l¶outil
SNORT, dont ses règles, sa base de logs, et son mode de fonctionnement.
La définition d¶une première version de « ALS » exprime la possibilité de son développement
ultérieur en termes de qualité ou de fonctionnalités.Ce projet m¶a permis une exploration concrète des différentes facettes de la sécurité
informatique dont le piratage ainsi que les outils de détection et de prévention. L¶assiduité et
la disponibilité de mon parrain m¶ont fait gagner une forte confiance en soi et des ambitions
inégalés.
Arrivant à ces fins, qui s¶avèrent débutantes pour les perspectives d¶avenir, le projet « ALS »
a su défier les autres outils s¶orientant dans le même sens que lui, tel qu¶ACID.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 92/116
Perspectives
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
92
PERSPECTIVES
Malgré ce qu¶offre « ALS » comme facilités pour gérer SNORT, on ne peuts¶empêcher de proposer une continuité à ce projet :
Intégration de « ALS » à la nouvelles de pare-feux, tels que
« smoothwall » ou l¶inéluctable « Endian » en leurs versions Open
Source.
Réécriture de « ALS » de telle façon qu¶il soit accessible via une interface
Web, tout en assurant l¶authentification qui s¶avère délicate dans ce cas.
Intégration de ¶iptables¶ à SNORT afin de le transformer en IPS et mettre
à jour « ALS » pour qu¶il puisse supporter ce nouveau mode de
fonctionnement.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 93/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
93
Annexes
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 94/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
94
Annexe A : Protocoles réseaux [23]
Afin de mieux comprendre la détection d¶intrusion, ces procédés et technique, il faut bienconnaitre et savoir manipuler les protocoles réseau.Dans cette annexe il y aura définition des protocoles les plus utilisés.
A.1 Le protocole TCP
TCP est un protocole orienté connexion, c'est-à-dire qu¶il permet à deux machines quicommuniquent de contrôler l¶état de la transmission et ce à travers :
L¶ordonnancement des datagrammes en provenance du protocole IP ; La vérification des flots pour éviter la saturation du réseau ; Le formatage des données en segments de longueur variable afin de les remettre
au protocole IP ; Le multiplexage des données ; L¶initialisation et la fin de la communication de manière courtoise, etc.
Un segment TCP est constitué comme suit :
Figure A.1 : Format du segment TCP
La signification des différents champs est :
Port Source (16 bits): Port relatif à l'application en cours sur la machine source
Port Destination (16 bits): Port relatif à l'application en cours sur la machinede destination
Numéro d'ordre (ou séquence) (32 bits): Lorsque le drapeau SYN est à 0, lenuméro d'ordre est celui du premier mot du segment en cours.Lorsque SYN est à 1, lenuméro d'ordre est égal au numéro d'ordre initial utilisé pour synchroniser les numérosde séquence (ISN)
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 95/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
95
Numéro d'accusé de réception (32 bits): Le numéro d'accusé de réceptionégalement appelé numéro d'acquittement correspond au numéro (d'ordre) du prochainsegment attendu, et non le numéro du dernier segment reçu.
Décalage des données (4 bits): il permet de repérer le début des données dans le paquet.
Le décalage est ici essentiel car le champ d'options est de taille variable
Réservé (6 bits): Champ inutilisé actuellement mais prévu pour l'avenir
Drapeaux (flags) (6x1 bit): Les drapeaux représentent des informationssupplémentaires :
o URG: si ce drapeau est à 1 le paquet doit être traité de façon urgente.o ACK: si ce drapeau est à 1 le paquet est un accusé de réception.o PSH (PUSH): si ce drapeau est à 1, le paquet fonctionne suivant la méthode
PUSH.o RST: si ce drapeau est à 1, la connexion est réinitialisée.o SYN: Le Flag TCP SYN indique une demande d'établissement de connexion.o FIN: si ce drapeau est à 1 la connexion s'interrompt.
Fenêtre (16 bits): Champ permettant de connaître le nombre d'octets que lerécepteur souhaite recevoir sans accusé de réception
Somme de contrôle (Checksum ou CRC): La somme de contrôle est réalisée en faisantla somme des champs de données de l'en-tête, afin de pouvoir vérifier l'intégrité del'en-tête
Pointeur d'urgence (16 bits): Indique le numéro d'ordre à partir duquell'information devient urgente
Options (Taille variable): Des options diverses
Remplissage: On remplit l'espace restant après les options avec des zéros pour avoir une longueur multiple de 32 bits
A.2 Le protocole IP
Le protocole IP (Internet Protocol) est à la base des communications sur Internet. Ilimplémente deux tâches de base : la fragmentation et l¶adressage.La fragmentation consiste à « briser » les données en petits paquets appelésdatagrammes. Cette opération est nécessaire avant d¶envoyer les données sur le réseau. Bien
entendu, au niveau du récepteur, il faut faire l¶opération inverse afin de reconstituer les données. En ce qui concerne l¶adressage, il s¶agit de transmettre les datagrammes jusqu¶au destinataire. Notons que le protocole IP transmet les données sans garantie deremise. Autrement dit, lorsqu¶on envoie un datagramme IP sur le réseau, rien ne peut nousassurer que celui-ci se rendra bel et bien à destination.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 96/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
96
Un segment IP est constitué comme suit :
Figure A.2 : Format du segment IP (version 4)
Voici la signification des différents champs :
Version (4 bits) : il s'agit de la version du protocole IP que l'on utilise(actuellement on utilise la version 4 IPv4) afin de vérifier la validité du datagramme.Elle est codée sur 4 bits.
Longueur d'en-tête, ou IHL pour Internet Header Length (4 bits) : il s'agit du nombrede mots de 32 bits constituant l'en-tête (nota : la valeur minimale est 5). Ce champ estcodé sur 4 bits.
Type de service (8 bits) : il indique la façon selon laquelle le datagramme doit êtretraité.
Longueur totale (16 bits): il indique la taille totale du datagramme en octets. Lataille de ce champ étant de 2 octets, la taille totale du datagramme ne peutdépasser 65536 octets. Utilisé conjointement avec la taille de l'en-tête, ce champ
permet de déterminer où sont situées les données.
Identification, drapeaux (flags) et déplacement de fragment sont des champs qui permettent la fragmentation des datagrammes, ils sont expliqués plus bas.
Durée de vie appelée aussi TTL, pour Time To Live (8 bits) : ce champ indique le
nombremaximal de routeurs à travers lesquels le datagramme peut passer. Ainsi ce champ estdécrémenté à chaque passage dans un routeur, lorsque celui-ci atteint la valeur critique de 0,le routeur détruit le datagramme. Cela évite l'encombrement du réseau par lesdatagrammes perdus.
Protocole (8 bits) : ce champ, en notation décimale, permet de savoir de quel protocoleest issu le datagramme
ICMP : 1 IGMP : 2 TCP : 6 UDP : 17
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 97/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
97
Somme de contrôle de l'en-tête, ou en anglais header checksum (16 bits) : cechamp contient une valeur codée sur 16 bits qui permet de contrôler l'intégrité del'en-tête afin de déterminer si celui-ci n'a pas été altéré pendant la transmission. Lasomme de contrôle est le complément à un de tous les mots de 16 bits de l'en-tête(champ somme de contrôle exclu). Celle-ci est en fait telle que lorsque l'on fait la
somme des champs de l'en-tête (somme de contrôle incluse), on obtient un nombreavec tous les bits positionnés à 1
Adresse IP source (32 bits) : Ce champ représente l'adresse IP de la machineémettrice, il permet au destinataire de répondre
Adresse IP destination (32 bits) : adresse IP du destinataire du message
A.3 Le protocole UDP
Un segment UCP est constitué comme suit :
Figure A.3 : Format du segment UDP
La signification des différents champs est la suivante :
Port Source: il s'agit du numéro de port correspondant à l'application émettrice dusegment UDP.
Port Destination: Ce champ contient le port correspondant à l'application de lamachine destinataire à laquelle on s'adresse.
Longueur: Ce champ précise la longueur totale du segment, en-tête comprise,
Somme de contrôle: Il s'agit d'une somme de contrôle réalisée de telle façon à
pouvoir contrôler l'intégrité du segment.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 98/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 99/116
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 100/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
100
B.3 Les vers [2]
Un ver est un programme complet (ou un ensemble de programmes) capable de se multiplier en plusieurs copies fonctionnelles ou de dupliquer ses segments sur d¶autres systèmesinformatiques en règle générale à travers un réseau. Contrairement aux virus, les vers n¶ont
pas besoin de programme hôte. Il existe deux types : les vers de station de travail et les versde réseau.
Les vers de station s¶attaquent à un seul système et utilisent les connexions réseau pour se copier sur toutes les machines du réseau. On parle à leur propos de « lapins » par analogie avec l¶animal prolifique. Les vers de réseau sont constitués de plusieurs segments, tournant chacun sur unemachine différente. Le réseau constitue alors un support de communication et de
propagation. Certains vers possèdent un segment principal qui coordonne les actionsdes autres segments ou sous-segments. Ce type de vers est appelé « pieuvre » par analogie avec cet animal tentaculaire.
B.4 Les virus créés sous Visual Basic [2]
Toutes les applications Microsoft sont liées les uns aux autres par leur langage de programmation Visual Basic et son dérivé VB script. Ce fait a poussé certains à écrire desvirus macros en utilisant les mêmes logiciels.
Les plus célèbres sont : I Love You: une fois en contact avec Outlook, logiciel de gestion de courrier électronique de l¶ensemble Office, il lui commande d¶envoyer une copie du messageauquel il est attaché à chacune des adresses du répertoire.
Melissa : Célèbre par ces ravages en 2002, lui, attaque les fonctions d¶automatisationdu traitement de texte Word. D¶autres virus se sont transmis via le tableur MicrosoftExcel.
B.5 Les wabbist [22]
Ce sont des programmes conçus pour épuiser les ressources d¶un système (Horloge CPU,RAM, Espace disque, ). Contrairement aux virus et aux vers, ils n¶infectent pas les fichierset ne se propagent pas à travers le réseau. Ils tournent en boucle infinie en créant de nouvellestâches (par exemple variables) qui saturent la mémoire et provoquent l¶erreur.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 101/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
101
Annexe C : Politiques de sécurité adoptées après une mission
d¶Audit
La notion de sécurité devient une obligation vu l¶importance des flux communiquésdans les réseaux informatiques. La mise au point d¶une politique de sécurité passe tout
d¶abord par une étape d¶analyse des risques qui se fait selon plusieurs méthodologies. Dans cequi suit, nous présentons quelques méthodes considérées parmi les plus répandues.
C.1 MEHARI [10] Mehari (MEthode Harmonisée d'Analyse de RIsques) est dévelopée par le CLUSIF (Club dela Sécurité des Systèmes d'Information Français) depuis 1995, elle est dérivée des méthodesMelisa et Marion. Existant en langue française et en anglais, elle est utilisée par denombreuses entreprises publiques ainsi que par le secteur privé.La démarche générale de Mehari consiste en l'analyse des enjeux de sécurité : quels sont lesscénarios redoutés, et en la classification préalable des entités du SI en fonction de troiscritères de sécurité de base (confidentialité, intégrité, disponibilité). Ces enjeux expriment lesdysfonctionnements ayant un impact direct sur l'activité de l'entreprise. Puis, des audits
identifient les vulnérabilités du SI. Enfin, l'analyse des risques proprement dite est réalisée.
Figure C.1 : Schéma général de la méthode MEHARI
Mehari s'articule autour de 3 types de livrables :
1. le Plan Stratégique de Sécurité (PSS)2. les Plans Opérationnels de Sécurité (POS)3. le Plan Opérationnel d'Entreprise (POE)
C.2 COBIT [11] La méthode Control OBjectives for Information and related Technology (en françaisobjectifs de commande pour information et la technologie relative) est un ensemble desmeilleures pratiques mondiales en audit et maîtrise des systèmes informatiques.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 102/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
102
Créé par l'association d'audit et de commande de systèmes d'information (ISACA) en1992, le COBIT aide les dirigeants à comprendre et à gérer les risques relatifs àl¶informatique et fait le lien entre les processus de gestion, les questions techniques,les besoins de contrôle et les risques.
Le modèle COBIT décompose tout système informatique en 34 processus regroupés en 4
domaines :
� Planification et organisation :- Couvre la stratégie et les tactiques ;- Concerne l¶identification des moyens permettant à l¶informatique de contribuer à laréalisation des objectifs commerciaux de l¶entreprise.
� Acquisition et mise en place : concerne la réalisation de la stratégie informatique,l¶identification, l¶acquisition, le développement et l¶installation des solutions informatiqueset leur intégration dans les processus commerciaux.
� Distribution et Support : concerne la livraison des prestations informatiques exigées, ce
qui comprend l¶exploitation, la sécurité, les plans d¶urgence et la formation.
� Surveillance : permet au management d¶évaluer la qualité et la conformité des processusinformatiques aux exigences de contrôle.
C.3 EBIOS [10] EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) permet d'identifier les risques d'un SI et de proposer une politique de sécurité adaptée aux besoins de l'entreprise(ou d'une administration). Elle a été créée par la DCSSI (Direction Centrale de la Sécurité desSystèmes d'Information), du Ministrère de la Défence (France). Elle est destinée avant toutaux administrations françaises et aux entreprises.
La méthode EBIOS se compose de 5 guides (Introduction, Démarche, Techniques,Outillages) et d'un logiciel permettant de simplifier l'application de la méthodologie explicitéedans ces guides. Le logiciel libre et gratuit (les sources sont disponibles) permet de simplifier l'application de la méthode et d'automatiser la création des documents de synthèse. La DCSSI
possède un centre de formation où sont organisés des stages à destination desorganismes publics français. Un club d'utilisateurs EBIOS a été créé en 2003 etconstitue une communauté experts permettant le partage des expériences. Une base deconnaissances à laquelle se connecte le logiciel EBIOS permet d'avoir à accès à ladescription d'un ensemble de vulnérabilités spécifiques, de contraintes de sécurité, deméthodes d'attaques. Elle peut être enrichie via le logiciel.
La méthode EBIOS est découpée en 5 étapes :1. étude du contexte : Vision globale et explicite du système étudié, des enjeux, descontraintes et référentiels applicables.
2. expression des besoins de sécurité : Positionnement des éléments à protéger (patrimoine informationnel) en terme de disponibilité, intégrité, confidentialité et miseen évidence des impacts en cas de sinistre.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 103/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
103
3. étude des menaces : Recensement des scénarios pouvant porter atteinte auxcomposants (techniques ou non) du SI.
4. identification des objectifs de sécurité : Mise en évidence des risques réels etexpression de la volonté de les traiter en cohérence avec le contexte particulier del¶organisme.
5. détermination des exigences de sécurité : Spécification des mesures concrètes à mettre enuvre pour traiter les risques sur la base d¶une négociation argumentée.
Figure C.2 : Démarche EBIOS globale
C.4 MARION [10] Marion (Méthodologie d'Analyse de Risques Informatiques Orientée par Niveaux) a étédéveloppée par le CLUSIF dans les années 1980 mais a été abandonnée en 1998 au
profit de la méthode Mehari. C'est une méthode d'audit de la sécurité d'une entreprise, elle ne permet pas de mettre en oeuvre une politique de sécurité en tant que tel. A base d'unquestionnaire, elle donne une évaluation chiffrée du risque informatique.Marion repose sur l'évaluation des aspects organisationnels et techniques de la sécurité del'entreprise à auditer.Elle utilise 27 indicateurs classés en 6 thématiques. Chaque indicateur se voit attribuer unenote entre 0 (insécurité) et 4 (excellent), la valeur 3 indiquant une sécurité correcte.
Thématiques des indicateurs de la méthode Marion� Sécurité organisationnelle� Sécurité physique� Continuité� Organisation informatique� Sécurité logique et exploitation� Sécurité des applications
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 104/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
104
La méthode se déroule en 4 phases :
1. Préparation : définir les objectifs de sécurité à atteindre ainsi que le champs d'action del'audit et le découpage fonctionnel du SI à adopter pour simplifier la réalisation del'étude.
2. Audit des vulnérabilités : consiste à répondre aux questionnaires. Ces réponsesdonnées vont permettre de recenser les risques du SI et les contraintes de l'entreprise.
3. Analyse des risques : permet de classer les risques selon leur criticité (en classes :Risques Majeurs et Risques Simples). Elle procède au découpage fonctionnel du SI pour une analyse détaillée des menaces, de leur impact respectif et de leur probabilité.
4. Plan d'action : propose les solutions à mettre en uvre pour élever la valeur des 27indicateurs à la valeur 3 (niveau de sécurité satisfaisant) de l'audit des vulnérabilités etatteindre les objectifs fixés en préparation.
C.5 Tableau récapitulatif
Le tableau suivant liste les principales normes utilisées:
Nom Signification Origine CaractéristiquesMEHARI MEthode
Harmoniséed¶Analyse desRisques
CLUSIF Succède à la méthodeMarion.S'articule autour de 3 plans.Permet désormais d'apprécier les risques au regard desobjectifs "business" del'entreprise.
COBIT ControlObjectives for InformationandTechnology
ISACA Méthode accessible à tous,dans un langage simple. Lesoutils fournis permettent lamesure des performancesmais la méthode estaujourd'hui davantageassimilée à une méthode degouvernance des SI.
EBIOS Expression desBesoins etIdentificationdes Objectifs de
Sécurité.
DCSSI Notamment déployée ausein de l'administrationfrançaise, cette méthodecomprend une base de
connaissances et un recueilde bonnes pratiques. Elleest téléchargeable sur le sitede la DCSSI et s'accompagned'un logiciel.
MARION Méthodologied¶Analyse desRisquesInformatiques
CLUSIF Fonctionne par questionnairesdébouchant sur 27 indicateursrépartis en
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 105/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
105
Orientée par Niveaux
6 catégories. 2 phases(audit desvulnérabilités et analyse desrisques)
permettent la définition etla mise en
oeuvre de plans d'actions personnalisés.
Tableau C.1 : Résumée des normes utilisées dans le domaine de la sécurité
Remarque :Bien que ces méthodologies ont un grand succès dans le domaine de la sécurité, ellesne se réfèrent pas, néanmoins, à un standard commun. Contrairement, par exemple, à la normeISO/CEI 27002 qui est une norme internationale concernant la sécurité de l'information,
publiée en juillet 2007 par l'ISO et qui définit douze domaines (Articles) de sécurité del'information constituant au total 41 catégories (objectifs de sécurité).
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 106/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
106
Annexe D : Installation et Configuration de Snort
SNORT est un IDS Open Source disponible en téléchargement à l¶adresse « www.snort.org »,il est destiné à fonctionner dans des réseaux de type IP. Cette Annexe saura satisfaire les
manques, en termes d¶installation et de configuration, que pose SNORT.D.1 Installation
L¶installation passe par plusieurs étapes à savoir :
Installation de l'outil SNORT ; Installation de WinPcap ; Installation des règles SNORT ; Configuration de snort.conf ; Liaison Mysql et SNORT ; Installation d¶ACID.
D.1.1 Les paquetages nécessaires
On peut aussi bien installer SNORT sous Windows que sous Linux. La procédured¶installation et les techniques de configuration changent bien sûr mais le fonctionnement deSNORT reste lui-même.
Remarque : Pour ce qui va suivre, il y aura l¶installation dédiée à Windows.
Les packages installés au cours du projet sont les suivants :
o
SNORT 2.8.4.1o WinPcap 3.1o EasyPHP 2.0b1 Contient : Apache ; MySQL ; PHP ; PHPmyAdmin.o ntwdblib.dll à télécharger puis à copier dans c:\snort\bin
NB : ntwdblib.dll est la bibliothèque SQL Server spécifique au client (SQL Server
Client library), elle est en téléchargement libre sur Internet.
D.1.2 Configuration
D.1.2.1 Configuration de MySQLOn commence tout d¶abord par créer la base de données `snort` dans « phpmyadmin ».
Par la suite, il y aura création des tables de Snort dans la base de données Snort selon lescript SQL fourni avec le package Snort qui se trouve dans« C:\Snort\schemas\create_mysql.sql », en explorant ce fichier à l¶aide du Bloc-Notes et encopiant toutes les requêtes dans le champ qui apparait lorsqu¶on clique sur SQL dans la basede donnée `snort` déjà créée comme le montre la figure « Figure D.1 : SQL dans
PHPmyAdmin » on obtiendra 16 tables, dont celle qui va accueillir les alertes qu¶il va stocker.
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 107/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
107
Figure D.1 : SQL dans PHPmyAdmin
D.1.2.2 Configuration de SNORT
Afin de détecter les intrusions, SNORT utilise des règles qui sont téléchargeables à partir du site « http://www.snort.org ». Il faut placer ces règles d¶extension «.rules » dans le dossier de Snort selon le chemin suivant : « C:\Snort\rules ».
F onctionnement des règles
Les règles de Snort sont décrites dans un langage simple et sont composées de deux parties comme suit :
L'en-tête de règle (header) qui contient L'action de la règle Le protocole qui est utilisé pour la transmission des données (TCP, UDP et
ICMP); Les adresses IP source et destination et leur masque; Les ports source et destination sur lesquels il faudra vérifier les paquets.
Les options de la règle (doivent être écrites entre parenthèses) qui contiennent Le message d'alerte; Les conditions qui déterminent l'envoi de l'alerte en fonction du paquet inspecté.
Voici un exemple de règles :alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"Ping Windows
détecté"; content:" ISSPNGRQ´; depth:16;);
F ichier de configuration de Snort
Le fichier de configuration de SNORT se trouvant dans le dossier «C:\Snort\etc\snort.conf» doit être mis à jour comme suit :
Définir la classe d'adresses du réseau ou bien mettre la valeur par défaut :
# Valeur pour un réseau en 192.168.0.xvar HOME_NET 192.168.0.0/24# Valeur par défautvar HOME_NET any
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 108/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
108
Donner le chemin complet du répertoire de règles :var RULE_PATH c:\snort\rules
Activer la ligne suivante :
output alert_syslog: host=hostname, LOG_AUTH LOG_ALERT
Modifier les paramètres de sortie (output) pour que Snort journalise dans la base MySQL :output database: log, mysql, user=root dbname=snort host=localhost
Inclure les fichiers de configuration suivants:include classification.configinclude reference.config
Activer ou désactiver les règles voulues afin de spécifier le niveau de sécurité souhaité
Activer la ligne suivante :include threshold.conf
D.2 Lancement de Snort
Avant de lancer Snort, il est utile de spécifier l¶interface qu¶il va utiliser pour l¶analyse.Pour ce faire, il faut ouvrir une fenêtre de commande DOS et se déplacer dans lerépertoire« bin » du dossier d'installation de Snort. L¶option « -W » (en majuscule) permet,sous Windows seulement, de lister ces interfaces comme le montre la figure suivante:
Figure D.2 : Spécification de l¶interface réseau à utiliser
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 109/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
109
M odes d¶utilisation de SNORT :
Mode Sniffer
snort ±v : Cette commande permet d¶exécuter et d¶afficher les entêtes des paquetsTCP/IP.
snort ±vd : Cette commande permet d¶exécuter Snort et d¶afficher tout le paquet
TCP/IP (entête et données). snort ±vde : Cette commande permet d¶exécuter Snort et d¶afficher tout le paquet
TCP/IP (entête et données) ainsi que de l¶entête de la couche liaison de données.
Mode Logger (log de paquet) Ce mode est presque similaire au précédent avec la possibilité d¶enregistrer les logsdirectement dans un fichier de logs dont il faut préciser le chemin complet.SNORT offre également la possibilité d¶enregistrer directement un fichier binaire, ce qui
permet d¶enregistrer les données sous une forme compressée. La lecture d¶un tel fichier binaire peut se faire avec un logiciel tel que tcpdump.La commande est écrit donc comme la suivante : snort ±vde ±l c:\snort\log ±b ±i2
Mode NIDS (Mode de détecteur d¶intrusion réseau) Ce mode nécessite, contrairement aux autres, l'utilisation du fichier de configuration deSNORT (dans le quel nous avons déjà inclus les noms des règles souhaitées). SNORT vaanalyser les paquets, comparer le trafic à des règles prédéfinies par l¶utilisateur et réagir ainsià d¶éventuelles tentatives d¶intrusions qu¶il détecterait. La commande est la suivante :snort ±vde ±A full ±c c:\snort\etc\snort.conf ±l c:\snort\log ±i2
La figure suivante montre le fonctionnement de Snort en mode NIDS :
Figure D.3 : Fonctionnement en mode NIDS
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 110/116
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 111/116
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 112/116
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 113/116
Annexes
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
113
if(argc<4) {printf("Generateur de motif dans le fichier fic.txt\n");printf("Usage : %s fic.txt taille(Mo) motif 1 [motif2] [motif3] ... \n",argv[0]);exit(1);
}int nbMot = argc - 3;
char *dest = argv[1];int size = atoi(argv[2]);
srand(time(NULL));
char car[] = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm','n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'};mots = (char**) malloc(sizeof(char*)*nbMot);printf("Ajout de %d mot(s) dans le fichier\n",nbMot);for(alpha=3;alpha<argc;alpha++){
strcpy(buffer,argv[alpha]);mots[alpha-3] = (char*) malloc(sizeof(char)*(1+strlen(buffer)));strcpy(mots[alpha-3], buffer);
}int pos[nbMot];
for (i = 0; i < nbMot; i++) {pos[i] = (int) (rand() / (double) RAND_MAX * ((size*1000000)-10));}triSelection(pos, nbMot);file = fopen(dest, "w");int nbAlea, nbChar;for (nbChar = 0, i = 0; nbChar * sizeof(char) < (size*1000000); ) {
if (pos[i] == nbChar) {printf("Ajout du mot %s en position %d dans le texte\n",mots[i],pos[i]);fprintf(file, "%s", mots[i]);nbChar += strlen(mots[i]);if (i < nbMot) {
i++;}
} else {nbAlea = (int)(rand() / (double)RAND_MAX * (sizeof(car) - 1));fprintf(file, "%c", car[nbAlea]);nbChar++;
}}fclose(file);printf("Le fichier %s a ete correctement genere\n",dest);return 0;
}
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 114/116
Bibliographie & Webographie
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 115/116
Bibliographie & Webographie
Analyseur de Logs pour SNORT Omar Kaïs El KAMEL
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
8/6/2019 Rapport 23-05-2009 CopieFINALE
http://slidepdf.com/reader/full/rapport-23-05-2009-copiefinale 116/116