Mise en Place D'un Système de Détection D'intrusion Dans L'architecture Réseau de La Sodecoton

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON
Paix- Travail-Patrie Peace-Work- Fatherland

********** **********
MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR MINISTRY OF HIGHER EDUCATION
********** **********
UNIVERSITE DE MAROUA UNIVERSITY OF MAROUA
********** **********
ECOLE NATIONALE SUPERIEURE POLYTECHNIQUE NATIONAL ADVANCED SCHOOL OF
DE MAROUA ENGINEERING OF MAROUA
********** **********
DEPARTEMENT D’INFORMATIQUE ET DEPARTMENT OF COMPUTER SCIENCE AND
TELECOMMUNICATIONS TELECOMMUNICATIONS
INFORMATIQUE ET TÉLÉCOMMUNICATIONS
MISE EN PLACE D’UN SYSTÈME DE DÉTECTION D’INTRUSION DANS

L’ARCHITECTURE RÉSEAU DE LA SODECOTON
Mémoire présenté et soutenu en vue de l’obtention du Diplôme d’ingénieur

EN RÉSEAUX ET TÉLÉCOMMUNICATIONS
Par
MOUSSA AHIDJO
Ingénieur des Travaux en INFORMATIQUE ET TÉLÉCOMMUNICATIONS
Matricule : 15E004S
Sous la Direction de
Prof. MOHAMADOU ALIDOU
Professeur
Devant le jury composé de :
Président : Pr. HAMBATÉ Gomdje Valery
Rapporteur : Prof. MOHAMADOU Alidou
Examinateur : Dr. MOULLA Donatien Koulla
Invité : M. MOUSSA DEMBA
Année Académique 2022/2023

MÉMOIRE DE FIN D’ÉTUDE D’INGÉNIEUR
DÉDICACE
À la grande famille AHIDJO
RÉDIGÉ PAR: MOUSSA AHIDJO page i

REMERCIEMENTS
Ce travail est l’aboutissement d’un processus auquel plusieurs ont contribué. Mes remerciements vont respec-
tivement :
• Au Directeur de l’École Nationale Supérieure Polytechnique de Maroua, ainsi qu’à mon encadreur acadé-
mique, Prof. MOHAMADOU Alidou. Je le remercie chaleureusement pour avoir créé un cadre propice à
notre formation et pour leur disponibilité, leurs conseils et les remarques précieuses qu’ils ont apportées
tout au long de notre parcours ;
• À notre Chef de Département Pr. KALADZAVI Guidedi pour sa disponibilité, ses conseils, ses remarques
apportées à notre égard ;
• Au Pr. HAMBATÉ Gomdje Valery pour avoir accepté de présider ce jury ;
• Au Dr. MOULLA Donatien Koulla pour avoir accepté d’examiner ce mémoire ;
• À tout le corps enseignant du Département d’Informatique et Télécommunications de l’École Nationale
Supérieure Polytechnique de Maroua en particulier a Dr. DJORWE TEMOA et M. TERDAM Valentin
pour tous les enseignements reçus, les conseils et sa disponibilité ;
• À mon encadreur professionnel, M. MOUSSA Demba pour son soutien, ses précieux conseils et les clarifi-
cations apportées dans ce travail ;
• Au Directeur Général de la SODECOTON M. MOHAMADOU Bayero, pour m’avoir accordé le stage
académique ;
• À Mme OUMMOU KALTOUM Epse ABOU ABBA, Directrice du Système d’informatique ;
• À M. MOUSSA Ahmadou chef division application et digitalisation ;
• À M. MOUSSA Demba, chef division infrastructure ;
• À tous le personnel de la direction générale de la SODECOTON ;
• À toute la famille AHIDJO pour le soutien moral et financier ;
• À mon père AHIDJO Djaboulé pour le soutien moral et financier ;
• À la mémoire de ma mère HALIMATOU Djibrilla, qui a souhaité vivre longtemps juste pour voir ce que
nous allions devenir, puisse ALLAH l’accueillir dans son infinie Miséricorde ;
• À la mémoire de mon Grand-frère MOHAMMADOU Laminou, qui a souhaité vivre longtemps juste pour
voir ce que nous allions devenir, puisse ALLAH l’accueillir dans son infinie Miséricorde ;
• À la mémoire de ma petite-sœur RAHIMATOU Ahidjo, qui a souhaité vivre longtemps juste pour voir ce
que nous allions devenir, puisse ALLAH l’accueillir dans son infinie Miséricorde ;
• À la mémoire de ma grand-mère IYABANO Djaboulé, qui a souhaité vivre longtemps juste pour voir ce
que nous allions devenir, puisse ALLAH l’accueillir dans son infinie Miséricorde ;
• À toute la famille ABOUBAKARY Abdoulaye pour le soutien moral et financier ;
• À tout le corps enseignant et administratif de l’École Nationale Supérieure Polytechnique de Maroua pour
l’effort fourni pour notre formation ;
• À tous mes camarades de promotion pour leur esprit de solidarité, de partage et de fraternité ;
• À tous mes amis et proches pour m’avoir toujours soutenu pendant ma formation.
RÉDIGÉ PAR: MOUSSA AHIDJO page ii

Table des matières
Dédicace i
Rémerciements ii
Sigles et abréviations vii
Résumé ix
Abstract x
Liste des tableaux xi
Liste des figures xii
INTRODUCTION GÉNÉRALE 1
1 CONTEXTE ET PROBLÉMATIQUE 2
1.1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Historique de la SODECOTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Missions de la SODECOTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Valeurs de la SODECOTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Stratégie d’action de la SODECOTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Organigramme de la SODECOTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 Situation Géographique de la SODECOTON . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Contexte et Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Objectif principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Objectifs spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 GÉNÉRALITÉS SUR LES RÉSEAUX INFORMATIQUES 11

2.1 Réseaux informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Classification des réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
iii
2.2.1 Classification selon l’étendue géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Classification selon l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Classification selon la topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Modèle OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Caractérisation des différentes couches : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Encapsulation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Routage IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.1 Deux modes de routages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Protocoles de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8.1 Protocole ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.2 Protocole DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.3 Protocole FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.4 Protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.5 Protocole RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.6 Protocole TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.7 Protocole DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.8 Protocole UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Équipements réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.1 Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.2 Carte réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.3 Concentrateur ou hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9.4 Commutateur réseau ou switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9.5 Routeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9.6 Passerelle ou gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9.7 Répéteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9.8 Pont ou bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 SÉCURITÉ DES RÉSEAUX INFORMATIQUES ET SYSTÈME

DE DÉTECTION D’INTRUSIONS DANS L’ARCHITECTURE
RÉSEAU 25
3.1 Définition et critères de la sécurité informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Critères de la sécurité informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3 Politique de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.4 Types de politique de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Menaces indirectes et les attaques pernicieuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Types de menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Types d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Attaques indirectes par réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Techniques d’attaques et attaques réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Techniques d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Attaques réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Contre-mesures de différentes attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 Mécanismes de chiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
RÉDIGÉ PAR: MOUSSA AHIDJO page iv

3.4.3 Pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.6 Certificat électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Protocoles de Sécurité et VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Protocoles de Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Types et caractéristiques des systèmes de détection d’intrusions . . . . . . . . . . . . . . . . . . . 37
3.6.1 Types des systèmes de détection d’intrusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2 Caractéristiques des systèmes de détection d’intrusions . . . . . . . . . . . . . . . . . . . . 40
3.7 Architecture et le Déploiement d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . . 40
3.7.1 Architecture d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . . . . . . . . 40
3.7.2 Déploiement d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . . . . . . . . 42
3.8 Fonctionnement, méthodes de détection, détection d’un IDS et critères de test d’un IDS . . . . . 43
3.8.1 Mode de Fonctionnement d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . 43
3.8.2 Méthodes de détections d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . . 44
3.8.3 Détecteur d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . . . . . . . . . . 46
3.8.4 Critères de tests d’un Système de Détection d’Intrusions (IDS) . . . . . . . . . . . . . . . 47
3.9 Techniques de contournement des IDS, Limitations des IDS et Systèmes de prévention d’intrusion
(IPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9.1 Techniques de contournement des IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9.2 Limitations des IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9.3 Efficacité des systèmes de détection d’intrusions . . . . . . . . . . . . . . . . . . . . . . . . 49
3.9.4 Systèmes de prévention d’intrusion (IPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 IMPLÉMENTATION ET INTÉGRATION DU SYSTÈME DE

DÉTECTION D’INTRUSION POUR LA SÉCURISATION L’AR-
CHITECTURE RÉSEAU DE LA SODECOTON 54
4.1 Evaluation de la solution avant et après déploiement . . . . . . . . . . . . . . . . . . . . 54
4.2 Architecture réseau de la Sodecoton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Zones réseaux de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Architecture centralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.3 Architecture décentralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.4 Architecture hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Présentation de Snort : Un aperçu de système détection d’intrusion dans l’architecture réseau . . 63
4.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2 Raison de choix du Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.3 Architecture de Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.4 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.5 Fonctionnement de Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Mise en place d’un système de détection d’intrusion . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.1 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.2 But du test d’intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.3 Outils de détection d’intrusion réseau utilisés pour la détection d’intrusions . 74
4.4.4 Installation et configuration du snort . . . . . . . . . . . . . . . . . . . . . . . . . . 74
RÉDIGÉ PAR: MOUSSA AHIDJO page v

5 RÉSULTATS ET COMMENTAIRES 92
5.1 Test de fonctionnement sur le serveur snort . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2 Test de fonctionnement sur splunk entreprise . . . . . . . . . . . . . . . . . . . . . . . . . 98
CONCLUSION GÉNÉRALE ET PERSPECTIVES . . . . . . . 101
BIBLIOGRAPHIE I
RÉDIGÉ PAR: MOUSSA AHIDJO page vi

SIGLES ET ABRÉVIATIONS
IDS Intrusion Detection System (Système de détection d’intrusion)
IPS Intrusion Prevention System (Système de prévention d’intrusion)
SIEM Security Information and Event Management (Gestion de l’information et des événements de sécurité)
GPU Graphics Processing Unit
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IP Internet Protocol (Protocole Internet)
IPC Inter-Process Communication
DPI Deep Packet Inspection (Inspection en profondeur des paquets)
CPU Central Processing Unit
RAM Random Access Memory
OS Operating System
OSINT Open Source Intelligence (Renseignement à source ouverte)
NIDS Network-based Intrusion Detection System (Système de détection d’intrusion basé sur le réseau)
HIDS Host-based Intrusion Detection System (Système de détection d’intrusion basé sur l’hôte)
CVE Common Vulnerabilities and Exposures (Expositions et vulnérabilités communes)
TCP Transmission Control Protocol (Protocole de contrôle de transmission)
UDP User Datagram Protocol (Protocole de datagramme utilisateur)
TLS Transport Layer Security
IDS/IPS Intrusion Detection and Prevention System (Système de détection et de prévention d’intrusion)
LAN Local Area Network (Réseau local)
WAN Wide Area Network (Réseau étendu)
VPN Virtual Private Network (Réseau privé virtuel)
ACL Access Control List (Liste de contrôle d’accès)
TCP/IP Transmission Control Protocol/Internet Protocol
VLAN Virtual Local Area Network
VPN Virtual Private Network
SSH Secure Shell
DNS Domain Name System (Système de noms de domaine)
HTTP Hypertext Transfer Protocol (Protocole de transfert hypertexte)
HTTPS Hypertext Transfer Protocol Secure (Protocole de transfert hypertexte sécurisé)
FTP File Transfer Protocol (Protocole de transfert de fichiers)
SMTP Simple Mail Transfer Protocol (Protocole simple de transfert de courrier)
QoS Quality of Service
CDN Content Delivery Network
LDAP Lightweight Directory Access Protocol
SSH Secure Shell (Shell sécurisé)
RÉDIGÉ PAR: MOUSSA AHIDJO page vii

NTP Network Time Protocol

DNSSEC Domain Name System Security Extensions
IPsec Internet Protocol Security
NAC Network Access Control
SSO Single Sign-On
ICMP Internet Control Message Protocol
SDLC Software Development Life Cycle
API Gateway Application Programming Interface Gateway
LB Load Balancer
VPC Virtual Private Cloud
DoS Denial of Service (Déni de service)
DDoS Distributed Denial of Service (Déni de service distribué)
VPC Peering Virtual Private Cloud Peering
API Application Programming Interface (Interface de programmation d’application)
VLAN Virtual Local Area Network (Réseau local virtuel)
MAC Media Access Control (Contrôle d’accès au support)
ICMP Internet Control Message Protocol (Protocole de message de contrôle Internet)
ICMP Internet Control Message Protocol (Protocole de message de contrôle Internet)
NAT Network Address Translation (Traduction d’adresse réseau)
DMZ Demilitarized Zone (Zone démilitarisée)
RAT Remote Access Trojan (Cheval de Troie d’accès à distance)
MITM Man-in-the-Middle (Homme du milieu)
XSS Cross-Site Scripting (Injection de script côté client)
SQLI SQL Injection (Injection SQL)
RCE Remote Code Execution (Exécution de code à distance)
SOC Security Operations Center (Centre des opérations de sécurité)
IOCs Indicators of Compromise (Indicateurs de compromission)
APT Advanced Persistent Threat (Menace persistante avancée)
CPU Central Processing Unit
RÉDIGÉ PAR: MOUSSA AHIDJO page viii

RÉSUMÉ
Ce mémoire présente en détail les résultats du projet réalisé au sein de la direction informatique de la
Sodecoton, dans le cadre du projet de fin de formation en cycle d’ingénieur. L’objectif principal de ce projet
était l’implémentation d’un système de détection d’intrusion dans l’architecture réseau de la Sodecoton. Pour
cela, deux composants clés ont été utilisés : Snort, en tant que serveur de détection d’intrusion, et Splunk,
en tant qu’outil de visualisation des données logs générées par Snort. Après la mise en place du système de
détection d’intrusion, les résultats ont été extrêmement satisfaisants, démontrant l’efficacité du système avec
un taux de détection optimal de 93%. L’analyse des données révèle que 99,515% des paquets ont été analysés
avec succès, générant un total de 96 665 alertes enregistrées. Parmi ces alertes, 104 795 ont été autorisées et 303
410 ont été identifiées comme étant de la liste blanche. L’analyse des données a révélé les détails suivants : 408
340 paquets Ethernet (100%), 335 118 paquets TCP (82,068 %), 32 295 paquets UDP (7,909 %), 93 paquets
IPv6 (0,023 %), 93 paquets IPv6 externes (0,023 %), 89 paquets UDP IPv6 (0,022 %), 406 097 paquets IPv4
(99,451%). Au total, 410 195 paquets ont été reçus, 408 205 ont été analysés (99,515 %), 1 982 ont été rejetés
(0,481 %), et 1 990 restent en attente (0,485 %). Le système Snort a fonctionné pendant 6 heures, 33 minutes
et 8 secondes. La vitesse moyenne de paquets était de 68 034 paquets par heure, 1 038 paquets par minute et
17 paquets par seconde. Sur les sessions détectées, il y avait 18 sessions au total : 15 sessions TCP et 3 sessions
UDP. De plus, 38 segments TCP étaient en file d’attente. Les types de paquets détectés étaient les suivants :
38 684 paquets ICMP (9,473 %), 32 295 paquets UDP (7,909 %), 2 150 paquets ARP (0,527 %). Un total de
96 665 alertes ont été générées, toutes ayant été enregistrées. Aucune alerte n’a été classée comme étant passée.
Parmi les alertes, 104 795 ont été autorisées et 303 410 ont été identifiées comme faisant partie de la liste
blanche. En ce qui concerne les méthodes HTTP, 165 requêtes POST et 63 requêtes GET ont été identifiées.
Enfin, 228 en-têtes de requête HTTP ont été extraits et 14 815 paquets SSL ont été décryptés, dont 3 152
étaient des messages "Server Hello", 1 980 étaient des messages "Server Done", et 3 280 étaient des messages
"Server Application". Un total de 1 014 détections ont été désactivées, il est crucial de continuer à surveiller
activement l’évolution des menaces et de mettre à jour régulièrement la base de données des règles de détection
pour maintenir l’efficacité du système face aux nouvelles attaques. Pour résoudre ces problèmes, il est essentiel
de mettre à jour le système pour gérer plus efficacement les paquets rejetés et en attente, ainsi que d’améliorer
la prise en charge d’IPv6. Une optimisation des méthodes de détection HTTP pourrait également être envisagée
pour mieux identifier les requêtes POST et GET, et éventuellement réduire le nombre de détections désactivées.
Ces résultats démontrent clairement l’efficacité du système de détection d’intrusion et son rôle essentiel dans la
protection et la sécurisation du réseau de l’entreprise. Grâce à ces données, des mesures proactives peuvent être
prises pour renforcer la sécurité du réseau et répondre aux menaces potentielles de manière rapide et efficace, en
mettant en évidence les succès significatifs obtenus grâce à l’utilisation de Snort et Splunk dans l’architecture
réseau de la Sodecoton, il est essentiel de rester vigilant face aux défis en constante évolution de la sécurité
informatique.
Mots clés : Optimisation, Architecture, réseau, sécurité, Sodecoton.
RÉDIGÉ PAR: MOUSSA AHIDJO page ix

ABSTRACT
This thesis presents in detail the results of the project carried out within the IT department of Sodecoton,
as part of the final engineering cycle training project. The main objective of this project was to implement
an intrusion detection system in Sodecoton’s network architecture. For this purpose, two key components were
used : Snort as the intrusion detection server, and Splunk as the tool for visualizing the log data generated
by Snort. After the implementation of the intrusion detection system, the results were highly satisfactory,
demonstrating the system’s efficiency with an optimal detection rate of 93%. The data analysis revealed that
99.515% of the packets were successfully analyzed, generating a total of 96,665 recorded alerts. Among these
alerts, 104,795 were authorized, and 303,410 were identified as whitelist entries. The data analysis further
revealed the following details : 408,340 Ethernet packets (100%), 335,118 TCP packets (82.068%), 32,295 UDP
packets (7.909%), 93 IPv6 packets (0.023%), 93 external IPv6 packets (0.023%), 89 IPv6 UDP packets (0.022%),
and 406,097 IPv4 packets (99.451%). In total, 410,195 packets were received, 408,205 were analyzed (99.515%),
1,982 were rejected (0.481%), and 1,990 are still pending (0.485%). The Snort system operated for 6 hours, 33
minutes, and 8 seconds. The average packet rate was 68,034 packets per hour, 1,038 packets per minute, and 17
packets per second. Among the detected sessions, there were a total of 18 sessions : 15 TCP sessions and 3 UDP
sessions. Additionally, 38 TCP segments were in the queue. The detected packet types were as follows : 38,684
ICMP packets (9.473%), 32,295 UDP packets (7.909%), and 2,150 ARP packets (0.527%). In total, 96,665 alerts
were generated, all of which were recorded. None of the alerts were classified as false positives. Among the alerts,
104,795 were authorized, and 303,410 were identified as whitelist entries. Concerning HTTP methods, 165 POST
requests and 63 GET requests were identified. Finally, 228 HTTP request headers were extracted, and 14,815
SSL packets were decrypted, including 3,152 "Server Hello" messages, 1,980 "Server Done" messages, and 3,280
"Server Application" messages. A total of 1,014 detections were disabled. These results clearly demonstrate the
effectiveness of the intrusion detection system and its crucial role in protecting and securing the company’s
network. Thanks to this data, proactive measures can be taken to strengthen network security and respond to
potential threats quickly and effectively. Highlighting the significant successes achieved through the use of Snort
and Splunk in Sodecoton’s network architecture, it is essential to remain vigilant in the face of the ever-evolving
challenges of cybersecurity.
Keywords : Optimization, Network, Architecture, Security, Sodecoton.
RÉDIGÉ PAR: MOUSSA AHIDJO page x

Liste des tableaux
2.1 Modèle OSI [10]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Standard du modèle OSI et modèle TCP [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Espace d’adresse [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Tableau comparatif de systèmes de détection d’intrusions (NIDS) [25]. . . . . . . . . . . . . . . . 38

3.2 Tableau comparatif des systèmes de détection d’intrusions (HIDS) [26]. . . . . . . . . . . . . . . . 39
5.1 Alertes générées par Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
RÉDIGÉ PAR: MOUSSA AHIDJO page xi

Liste des figures

1.1 Organigramme de la Sodecoton [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Localisation de la Sodecoton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Différents réseaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Réseau poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Réseau poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Architecture en étoile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Architecture en anneau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Architecture en bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Encapsulation des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 Cinq classes d’adresses IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Attaque directe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Attaque indirecte par rebond. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Attaque indirecte par rebond. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Chiffrement symétrique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Chiffrement asymétrique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Fonctionnement d’un Pare feu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8 Système de détection d’intrusion réseau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9 Système de détection d’intrusion hôte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.10 Architecture d’un IDS [34]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.11 Position des IDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.12 Emplacement d’un IPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.13 Architecture fonctionnelle d’un IPS [43]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.14 Différence entre IDS et IPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.15 Figure comparatif entre IDS et IPS [45]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1 Architecture centralisée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 Architecture décentralisée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Architecture hybride. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4 Plateformes pour installer SNORT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5 Architecture de SNORT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6 Le décodeur de paquets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7 Partie du fichier snort.conf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8 Répertoire /var/log/snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.9 Topologie de l’architecture hybride. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10 Fichier local.rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.11 Builds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.12 Architecture retenue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.13 Les Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.14 Différents dépendances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.15 Installation du serveur snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.16 Extraction de l’archive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.17 Configuration de snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
RÉDIGÉ PAR: MOUSSA AHIDJO page xii

4.18 Création de la base de donnée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.19 Base de données Mysqladmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.20 Interface d’installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.21 Choisir le mode de démarrage de snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.22 Choisir une interface réseau par défaut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.23 Récupération d’adresse du sous réseau par défaut. . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.24 Paramétrage du mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.25 Suggestion d’ajout d’autres options pour snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.26 Status du snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.27 Preprocessor du snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.28 Fichier de configuration de snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.29 Répertoire de configuration de rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.30 Remplissage du fichier local.rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.31 Création de la base de donnée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.32 Installation du splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.33 Status du splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.34 Login du splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.35 Page d’accueil du splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.36 Ajouter de données du splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.37 Configuration des entrées de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.38 Indexation des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.39 Résumé des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.1 Démarrage des services de la machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2 Interface réseau du serveur snort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3 Ping sur le serveur snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4 Recevoir une alerte ICMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Processing packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.6 POST methods http. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7 SSL Preprocessor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.8 Stream statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.9 Action Stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.10 Différents tâches Splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.11 Configurations Splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.12 Présentation générale de évènements Splunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
RÉDIGÉ PAR: MOUSSA AHIDJO page xiii

INTRODUCTION GÉNÉRALE
Dans le domaine de la sécurité informatique, aucun système d’information n’est à l’abri à 100%. Il est large-
ment reconnu qu’une entreprise connectée à l’Internet est susceptible de subir des attaques, et la question n’est
plus de savoir si cela se produira, mais quand. Afin de retarder ces risques, les entreprises cherchent à accroître
leur niveau de sécurité en mettant en place diverses mesures. Pour lutter contre les intrusions, de plus en plus
d’entreprises se tournent vers les solutions de détection d’intrusion. Dans ce contexte, notre projet de détection
d’intrusions vise à identifier et à prévenir ces activités malveillantes en renforçant la sécurité du réseau de la
Sodecoton.
Une intrusion est couramment définie comme l’action de pénétrer sans autorisation dans un lieu dont l’individu
n’est pas propriétaire [1]. Cette notion s’applique également au domaine de l’informatique lorsqu’un tiers s’in-
troduit dans un système et accède illégitimement à ses données. Les intrusions peuvent résulter de différentes
intentions, telles qu’un pirate cherchant à nuire à une organisation, un ver cherchant à se propager ou une
attaque automatisée, parmi d’autres. Les attaques d’intrusion peuvent être classées en trois types :
— les attaques réseau,
— les attaques par portes dérobées (backdoors),
— canaux de communication cachés (cover channels), ainsi que les attaques ciblant les services, qui connaissent
une importance croissante.
Il est important de noter qu’actuellement, environ 60% des intrusions se produisent via le Web [2].
De plus, il offre un aperçu des techniques et familles de détection et de prévention d’intrusion, ainsi que de
leurs principales limites. Bien qu’il ne prétende pas être exhaustif ni répondre à toutes les questions, il vise à
mettre en évidence les principales limites technologiques des solutions actuelles. Ce travail propose une analyse
approfondie des fonctionnalités et limites des outils de détection d’intrusions dans l’architecture réseau d’une
entreprise, en s’appuyant sur des recherches récentes et des retours d’expérience d’administrateurs système. Au
cours de notre stage au sein de la direction de l’informatique, notre mission principale consistait à analyser les
vulnérabilités du réseau existant et à proposer des mesures efficaces pour renforcer sa sécurité.
Le présent mémoire s’articule autour de cinq chapitres, chacun abordant des aspects clés de notre travail.
Dans le premier chapitre, nous situons le contexte et exposons la problématique liée à notre projet. Le deuxième
chapitre présente des notions générales sur la sécurité informatique et la tolérance aux pannes dans un réseau
informatique. Nous poursuivons avec le troisième chapitre, consacré à une étude approfondie de l’existant, où
nous identifions les limites et les risques liés au réseau en place, tout en proposant des solutions adaptées pour
répondre aux exigences spécifiques de la Sodecoton. Le quatrième chapitre est dédié à la conception et à la réa-
lisation de l’architecture sécurisée que nous avons élaborée. Enfin, le cinquième chapitre présente les résultats
obtenus lors de nos analyses et propose des commentaires pertinents sur ces résultats.
En Outre, ma mission consistait à analyser les risques potentiels auxquels le réseau de la Sodecoton était ex-
posé, à identifier les vulnérabilités existantes et à concevoir une architecture sécurisée pour garantir l’intégrité,
la confidentialité et la disponibilité des données. Dans ce mémoire, nous partageons notre démarche, nos décou-
vertes et les solutions que nous avons mises en œuvre pour renforcer la sécurité des services informatiques de
l’entreprise.
En fin, ce mémoire offre un aperçu complet du travail réalisé pour améliorer la sécurité des services infor-
matiques au sein de la Sodecoton. Nous soulignons également les perspectives futures pour renforcer davantage
la sécurité et assurer une protection optimale des données de l’entreprise.
RÉDIGÉ PAR: MOUSSA AHIDJO page 1

Chapitre 1
CONTEXTE ET PROBLÉMATIQUE
Introduction
Dans ce chapitre, nous commencerons par fournir une présentation détaillée de l’environnement dans le-
quel s’est déroulé notre stage. Nous décrirons en détail le contexte dans lequel notre projet a été étudié, en
mettant en évidence les problématiques auxquelles nous avons été confrontés. De plus, nous présenterons les
objectifs que nous avons fixés et nous expliquerons en détail la méthodologie que nous avons suivie pour mener
à bien la réalisation de notre projet.
1.1 Présentation de l’entreprise
1.1.1 Historique de la SODECOTON

Créée par décret n° 74-457 du 10 mai 1974, modifié et complété par décret n° 81-302 du 24 juillet 1981,
la Société de Développement du Coton du Cameroun est une société anonyme d’économie mixte, dotée d’une
Direction Générale et d’un Conseil d’Administration. Les statuts de la SODECOTON, qui sont conformes à
l’Acte uniforme OHADA relatif au droit des sociétés commerciales et du groupement d’intérêt économique d’une
part et aux dispositions de la loi N° 099/016 du 22 décembre 1999 portant statut général des établissements
publics et des entreprises du secteur public et parapublic d’autre part, assignent à cette Société une mission
générale de développement [3].
1.1.2 Missions de la SODECOTON

La SODECOTON, depuis sa création conformément au décret n° 74-457 du 10 mai 1974, s’est engagée
dans une mission principale qui consiste à garantir la production et la commercialisation du produit cotonier.
Au fil des années, cette entreprise a joué un rôle clé dans le développement de l’industrie cotonnière nationale.
Premièrement, la SODECOTON s’est attachée à soutenir les producteurs de coton en leur fournissant des in-
trants agricoles de qualité, tels que des semences certifiées, des engrais et des pesticides. Grâce à ces efforts, la
production de coton au Cameroun a connu une augmentation significative. Par exemple, en 2020, la SODECO-
TON a enregistré une production totale de 267 000 tonnes de coton brut, ce qui représente une hausse de 12
pour cent par rapport à l’année précédente.
Deuxièmement, la SODECOTON s’est engagée à assurer la commercialisation du coton produit par les agricul-
teurs. En tant qu’intermédiaire, elle veille à la transparence des transactions et à l’équité des prix. En 2020, la
SODECOTON a réalisé des ventes de coton d’une valeur totale de 235 milliards de francs CFA, soit environ 426
millions de dollars américains. Ces chiffres témoignent de l’importance de la SODECOTON dans l’économie

nationale et de son rôle dans la promotion du secteur cotonnier.

En fin, la mission principale de la SODECOTON est de garantir la production et la commercialisation du coton
au Cameroun. Grâce à ses actions soutenues auprès des producteurs, elle contribue à la croissance économique
du pays en générant des revenus importants. De plus, la SODECOTON joue un rôle crucial dans la création
d’emplois dans les zones rurales, en fournissant des opportunités d’emploi à des milliers de travailleurs agricoles.
Ces chiffres démontrent l’impact concret de la SODECOTON dans le secteur cotonnier et son engagement en-
vers le développement durable de l’industrie [4].
1.1.3 Valeurs de la SODECOTON

• Esprit d’équipe
La SODECOTON accorde une grande importance aux valeurs du Esprit d’équipe, reconnaissant que la
collaboration efficace et harmonieuse est essentielle pour atteindre les objectifs communs. Au sein de
l’entreprise, la coopération est encouragée et valorisée, favorisant un environnement propice à la commu-
nication ouverte, à la confiance mutuelle et au partage des connaissances. Les valeurs de respect, d’écoute
active et de collaboration sont ancrées dans la culture de l’entreprise, permettant aux employés de tra-
vailler ensemble de manière synergique pour résoudre les problèmes, prendre des décisions éclairées et
atteindre l’excellence dans leurs performances collectives. La SODECOTON favorise également la diver-
sité des compétences et des perspectives au sein des équipes, reconnaissant que cela stimule l’innovation et
la créativité. En mettant l’accent sur le travail d’équipe, la SODECOTON crée un environnement favorable
où chaque individu est encouragé à contribuer activement, à collaborer et à s’épanouir professionnellement
au sein d’une équipe solide et unifiée.
• Travail de qualité
La Sodecoton considère que la qualité du travail est la clé de la satisfaction des clients et de la réalisation
de ses objectifs. La SODECOTON valorise l’excellence, la rigueur et l’efficacité dans toutes ses activités.
Elle encourage la créativité, l’innovation et l’amélioration continue. La transparence, l’intégrité et le res-
pect des normes éthiques sont également des valeurs fondamentales pour la SODECOTON. L’entreprise
promeut un environnement de travail où chaque employé est encouragé à donner le meilleur de lui-même,
à s’investir pleinement et à contribuer à l’atteinte des résultats de manière responsable et professionnelle.
Grâce à ces valeurs, la SODECOTON s’efforce de fournir des produits et services de qualité, tout en
garantissant une relation solide et durable avec ses clients et partenaires.
• Satisfaction
La satisfaction des clients est une valeur primordiale pour la SODECOTON. L’entreprise s’engage à four-
nir des produits et des services de haute qualité répondant aux besoins et aux attentes de ses clients. Pour
atteindre cet objectif, la SODECOTON met en œuvre des politiques et des processus axés sur la satisfac-
tion client. Elle accorde une attention particulière à l’écoute active des clients, à la compréhension de leurs
besoins et à la recherche continue d’amélioration. La SODECOTON vise à établir des relations durables
avec ses clients en offrant un service personnalisé, une assistance technique et un suivi après-vente. Elle
valorise également la transparence, l’intégrité et la responsabilité dans toutes ses interactions avec les
clients. La satisfaction des clients est perçue comme un indicateur clé de la réussite de la SODECOTON
et constitue une motivation constante pour fournir des produits et des services de la plus haute qualité
[5].

1.1.4 Stratégie d’action de la SODECOTON

La SODECOTON déploie une stratégie d’action bien définie pour assurer la production et la commercia-
lisation du coton au Cameroun. Cette stratégie vise à garantir la qualité du produit, à optimiser les rendements
agricoles et à favoriser des pratiques durables tout au long de la chaîne de valeur. Tout d’abord, la SODECO-
TON met en œuvre des programmes d’accompagnement des producteurs de coton. Elle fournit des semences
certifiées et adapte les variétés aux conditions locales, ce qui permet d’améliorer la productivité et la résistance
des cultures. De plus, la SODECOTON offre des formations techniques aux agriculteurs, notamment sur les
bonnes pratiques agricoles, la gestion de l’eau et l’utilisation responsable des intrants agricoles. Cette approche
contribue à accroître les rendements et à garantir la qualité du coton produit. Ensuite, la SODECOTON met
en place des dispositifs de suivi et de contrôle tout au long de la chaîne de production et de commercialisation.
Des équipes sont chargées d’effectuer des inspections régulières sur les exploitations agricoles pour s’assurer
du respect des normes de production. De plus, des laboratoires sont utilisés pour tester la qualité du coton à
différents stades, de la récolte au stockage. Ces contrôles rigoureux permettent de maintenir des standards élevés
et d’assurer la satisfaction des clients. En ce qui concerne la commercialisation, la SODECOTON joue un rôle
central en tant qu’acheteur et intermédiaire entre les producteurs et les acheteurs internationaux. Elle organise
des enchères et des ventes de coton, en veillant à ce que les prix soient justes et équitables pour les producteurs.
De plus, elle met en place des partenariats solides avec des entreprises de transformation et des exportateurs
pour assurer la vente du coton sur les marchés nationaux et internationaux.
En fin, la stratégie d’action de la SODECOTON repose sur l’accompagnement des producteurs, le contrôle
qualité rigoureux et la gestion efficace de la commercialisation. Cette approche globale permet d’optimiser la
production de coton, d’assurer la satisfaction des clients et de contribuer au développement économique du
Cameroun dans le secteur cotonnier [6].
1.1.5 Organigramme de la SODECOTON
Figure 1.1 – Organigramme de la Sodecoton [7].

1.1.6 Situation Géographique de la SODECOTON

Sur le plan géographique, la SODECOTON s’étend principalement sur presque tout le grand Nord Came-
roun. Son siège social était implanté à Kaélé. Cependant, elle s’est vue déportée à Garoua quartier Marouaré
depuis 1979. I1 s’agit de la Direction Générale et l’huilerie située dans la zone industrielle à l’ouest de la ville
plus précisément au quartier Djamboutou et enfin du site abritant les magasins et Services Électriques entre les
quartiers Yelwa et Camp chinois dénommée Garoua 2. La SODECOTON compte neuf (09) régions (Maroua 1
, Maroua 2, Tchatibali, Kaélé, Guider, Garoua, Ngong, Mayo-Galké, Touboro et Homé qui dépend de la région
de Touboro). Dans chaque région est installé une usine d’égrainage dont le rôle est la transformation du coton
graine en coton fibre. Elle compte également de (02) huileries, la première étant dans la ville de Garoua et
la seconde dans la ville de Maroua. Par ailleurs, la SODECOTON est répartie en quarante-six (46) secteurs
agricoles, trois (03) équipes de génie civil basées à Garoua, Maroua, Touboro et deux cent soixante-seize (276)
zones agricoles. En outre, il existe une délégation de la SODECOTON à Yaoundé, une représentation à Douala,
un bureau à N’Gaoundéré et enfin une correspondance en France. La situation géographique de la Direction
Générale de la SODECOTON est schématisée à la page suivante [8] :
Figure 1.2 – Localisation de la Sodecoton.

— Les objectifs du sécurité de l’architecture réseau de la Sodecoton sont les suivants :

• Étendre le réseau de l’entreprise à tous les sites de la Sodecoton, en veillant à ce qu’il soit accessible
et connecté de manière optimale.
• Développer les différentes architectures des réseaux informatiques tels que LAN, MAN, WAN, etc.,
afin de garantir une connectivité optimale pour les personnels.
• Améliorer la fiabilité et la qualité de l’infrastructure pour garantir un fonctionnement stable.
• Améliorer la fiabilité et la qualité de l’architecture réseau pour assurer un fonctionnement stable et
éviter les interruptions de service.
• Mettre en place des solutions de sauvegarde pour assurer la sécurité des systèmes et des applications,
permettant ainsi de restaurer rapidement les données en cas de problème.
• Garantir la disponibilité des serveurs de base de données, assurant ainsi un accès continu aux infor-
mations cruciales pour les opérations de l’entreprise.
• Veiller à la disponibilité de l’architecture électrique afin de maintenir le bon fonctionnement du réseau
sans interruption due à des problèmes d’alimentation électrique.
— Le service Réseau et Télécom est responsable des tâches suivantes :
• Configuration et bon fonctionnement des équipements réseau tels que les imprimantes, les switches
et les routeurs.
• Intervention rapide en cas de problème sur le réseau, afin de minimiser les perturbations et de rétablir
les services rapidement.
• Surveillance constante du réseau informatique pour détecter d’éventuelles anomalies ou activités
suspectes, en mettant en place un système de détection d’intrusion efficace.
• Maintenance du réseau téléphonique interne de l’entreprise, en veillant à ce que les communications
téléphoniques soient opérationnelles et sécurisées.
L’objectif global est d’assurer un niveau élevé de sécurité et de disponibilité de l’architecture réseau, en pro-
tégeant les informations sensibles de l’entreprise, en prévenant les attaques et en garantissant une connectivité
optimale pour les personnels de la Sodecoton.
1.2 Contexte et Problématique
1.2.1 Contexte
L’architecture réseau de la Sodecoton se compose de trois grandes parties. La première partie, appelée
Edge, assure l’interconnexion des différents sites distants dans toutes les regions du cameroun en utilisant MPLS
via des Fournisseurs d’Accès Internet. CAMTEL fournit la connexion Internet au Datacenter. La deuxième
partie, le cœur du réseau, assure l’interconnexion des bâtiments de la direction de la Sodecoton et d’autres sites
en utilisant la fibre optique entre le datacenter et les commutateurs. Le Datacenter est considéré comme le cœur
de l’entreprise car il abrite tous les serveurs, les applications et les outils de surveillance du réseau. Enfin, la
partie sécurité est dédiée à la protection de l’entreprise contre les attaques provenant de l’internet. FortiGate,
une plateforme de sécurité réseau développée par Fortinet, joue un rôle essentiel dans cette protection en offrant
des fonctionnalités de sécurité telles que la sécurisation des VLAN (Virtual Local Area Networks) dans un
environnement d’entreprise. Elle comprend également deux pare-feux pour le contrôle et la filtration du trafic
réseau entrant/sortant, ainsi que des fonctionnalités de haute disponibilité et de continuité des services.
Cependant, l’architecture réseau de la Sodecoton présente actuellement plusieurs problèmes de sécurité. Les
principales vulnérabilités comprennent les équipements réseau, les accès non autorisés, les attaques par déni de

service (DDoS), les fuites de données, les logiciels malveillants et le manque de surveillance et de contrôle. De
plus, l’évolutivité de l’architecture réseau est limitée et il n’y a pas de serveur de sécurité dédié, ce qui constitue
un point faible dans la protection globale de l’entreprise.
Il est important pour la Sodecoton de prendre des mesures pour renforcer la sécurité de son architecture
réseau en remédiant aux vulnérabilités existantes, en renforçant les mécanismes de contrôle d’accès, en mettant
en place des systèmes de détection et de prévention des intrusions, en effectuant des analyses régulières des
vulnérabilités, et en augmentant la surveillance et la visibilité du réseau. L’introduction d’un serveur de sécurité
dédié peut également renforcer la posture de sécurité globale de l’entreprise. Cependant, il est important de
noter que malgré les problèmes actuels de l’architecture réseau de la Sodecoton, l’entreprise joue un rôle majeur
dans le secteur cotonnier et contribue de manière significative à l’économie nationale. En reconnaissant ces défis
de sécurité, la Sodecoton est déjà sur la bonne voie pour améliorer son architecture réseau en utilisant une
meilleure solution de sécurité réseau.
L’architecture réseau de la Sodecoton fait face à plusieurs défis en termes de sécurité et de gestion des menaces.
Afin de relever ces défis, la Sodecoton est à la recherche de solutions innovantes pour optimiser son architecture
réseau et répondre aux besoins croissants de l’entreprise. L’utilisation de solutions de sécurité avancées, telles
que des solutions de sécurité et d’alertes et de préventions des menaces, représente une opportunité intéressante
pour renforcer la protection du réseau de l’entreprise. Ces solutions peuvent aider à détecter et à prévenir les
menaces émergentes, à améliorer la visibilité du réseau, à renforcer les mécanismes de contrôle d’accès, et à
garantir une surveillance proactive et une réponse rapide aux incidents de sécurité. En adoptant ces solutions
innovantes, Sodecoton peut renforcer la sécurité de son architecture réseau et assurer la continuité des opéra-
tions tout en protégeant les données et les actifs de l’entreprise. L’objectif principal est de veiller à ce que les
ressources matérielles et logicielles de l’entreprise ne soient utilisées que dans le cadre du réseau informatique.
Avec la prolifération de la technologie, de nouvelles formes d’attaques ont été identifiées, et de nombreuses
entreprises font actuellement face à des intrusions dans leurs systèmes et bases de données. Cette situation
constitue un problème majeur, car la compromission de données confidentielles peut entraîner la faillite de
l’entreprise. Les attaques peuvent provenir à la fois de l’intérieur et de l’extérieur (Internet). Afin de faire face
à ces menaces, les administrateurs doivent déployer des solutions de sécurité efficaces capables de protéger le
réseau de l’entreprise. Dans ce contexte, les systèmes de détection d’intrusions (IDS) représentent une solution
intéressante pour renforcer la sécurité du réseau informatique.
1.2.2 Problématique
Notre travail vise à proposer des solutions à la problématique suivante :
• Comment optimiser la sécurité de l’architecture réseau de la Sodecoton en mettant en place un système

de détection d’intrusions performant, capable de détecter, analyser et prévenir les attaques potentielles,
afin de protéger efficacement les données sensibles et les ressources de l’entreprise ?
Dans le cadre de la protection des actifs du réseau de la Sodecoton, il est essentiel de prendre en compte
les actifs à protéger ainsi que leurs propriétés spécifiques. Les actifs concernés comprennent les serveurs, les
bases de données, les données sensibles, les applications métier, les équipements réseau, etc. Les propriétés des
actifs à protéger peuvent inclure la confidentialité, l’intégrité, la disponibilité et l’authenticité des données et
des services.
Pour évaluer les risques liés à la sécurité du réseau, il est nécessaire de mettre en place des mesures représen-
tant les risques potentiels. Cela peut inclure l’identification des vulnérabilités du réseau, les menaces potentielles
auxquelles il est exposé, ainsi que l’estimation de la probabilité d’occurrence de ces menaces et de leur impact

sur les actifs du réseau. Ces mesures permettent d’évaluer la criticité des risques et de prioriser les actions de
sécurité à entreprendre.
Une fois que les mesures représentant les risques ont été établies, il est important de les évaluer pour
déterminer l’efficacité des mesures de sécurité mises en place. L’évaluation des risques résiduels permet de
mesurer l’impact des risques restants sur les objectifs initiaux de sécurité fixés par l’entreprise. Cette évaluation
permet de déterminer si les mesures de sécurité actuelles sont adéquates pour protéger les actifs du réseau et si
des ajustements ou des améliorations supplémentaires sont nécessaires.
En fin, l’implémentation d’un système de détection d’intrusions dans l’architecture réseau de la Sodecoton
nécessite une analyse approfondie des besoins de sécurité, la protection des actifs du réseau en fonction de leurs
propriétés spécifiques, l’évaluation des risques potentiels et l’évaluation des risques résiduels pour assurer une
sécurité optimale du réseau.
1.3 Objectifs
Notre travail vise à accomplir divers objectifs qui peuvent être résumés de la manière suivante :
1.3.1 Objectif principal

L’objectif principal est d’améliorer la sécurité dans l’architecture réseau de la Sodecoton en mettant en
place un système de détection d’intrusions capable de détecter et d’analyser les attaques, afin de protéger de
manière proactive les données sensibles et les ressources de l’entreprise contre les menaces potentielles.
1.3.2 Objectifs spécifiques

Les objectifs spécifiques à atteindre sont :
• Sélection d’une solution de détection d’intrusions adaptée : Identifier et choisir la solution de détection
d’intrusions la mieux adaptée aux besoins de sécurité de la Sodecoton, en prenant en compte les fonction-
nalités, les performances, la compatibilité avec l’architecture existante et les contraintes budgétaires.
• Configuration et déploiement efficaces : Configurer correctement le système de détection d’intrusions en
fonction des spécificités de l’architecture réseau de la Sodecoton, en définissant les règles de détection, les
seuils de sensibilité et les paramètres appropriés pour garantir une surveillance efficace du réseau.
• Intégration avec les dispositifs de sécurité existants : Assurer une intégration harmonieuse entre le système
de détection d’intrusions et les autres dispositifs de sécurité déjà en place, tels que les pare-feu et les
systèmes de prévention d’intrusions, afin de bénéficier d’une approche de sécurité globale et cohérente.
• Surveillance proactive : Mettre en place une surveillance en temps réel des activités réseau afin de détecter
rapidement les activités suspectes ou malveillantes, et de prendre des mesures appropriées pour prévenir
les attaques et minimiser les dommages potentiels.
• Analyse et réponse aux incidents : Mettre en œuvre des mécanismes d’analyse avancés pour évaluer
les alertes générées par le système de détection d’intrusions, afin d’identifier et d’analyser les schémas
d’attaque, de prendre des décisions éclairées et de répondre efficacement aux incidents de sécurité.
• Sensibilisation et formation des utilisateurs : Sensibiliser et former les utilisateurs de l’architecture réseau
de la Sodecoton aux bonnes pratiques de sécurité, aux risques potentiels et aux procédures à suivre en cas
d’incident de sécurité, afin de renforcer la culture de la sécurité au sein de l’entreprise.

1.4 Méthodologie
Afin d’accomplir ce projet et de répondre à la question posée par la problématique, nous suivrons les
grandes étapes de travail suivantes :
❖ Étude préliminaire :
— Analyser l’architecture réseau actuelle de la Sodecoton : Comprendre la configuration du réseau, les équi-
pements utilisés, les protocoles en place, les zones de sécurité, etc.
— Identifier les besoins spécifiques en matière de sécurité : Consulter les parties prenantes, l’administrateur
réseau et les responsables de la sécurité pour définir les objectifs de détection d’intrusion, les contraintes
budgétaires, les exigences de conformité, etc.
❖ Recherche et choix des solutions de détection d’intrusion :
— Effectuer une recherche approfondie sur les différents systèmes de détection d’intrusion disponibles sur le
marché, leurs fonctionnalités, leurs performances et leurs coûts.
— Sélectionner la ou les solutions de détection d’intrusion les mieux adaptées aux besoins spécifiques de la
Sodecoton en prenant en compte des facteurs tels que la compatibilité avec l’infrastructure existante, la
facilité de gestion, l’évolutivité, etc.
❖ Planification de l’implémentation :
— Définir un plan détaillé pour la mise en place du système de détection d’intrusion, y compris les étapes
spécifiques, les responsabilités des membres de l’équipe, le calendrier et les ressources nécessaires.
— Prévoir une approche progressive pour minimiser l’impact sur les opérations en production et faciliter la
transition vers le nouveau système de détection d’intrusion.
❖ Mise en œuvre du système de détection d’intrusion :
— Installer et configurer les composants matériels et logiciels du système de détection d’intrusion en fonction
du plan établi.
— Intégrer le système de détection d’intrusion dans l’architecture réseau existante de la Sodecoton en prenant
soin de garantir une compatibilité optimale avec les autres équipements et logiciels.
❖ Tests et validation :
— Effectuer des tests rigoureux pour vérifier le bon fonctionnement du système de détection d’intrusion.
— Valider le système en le soumettant à une période de surveillance en conditions réelles pour s’assurer de
sa stabilité et de sa capacité à répondre aux menaces potentielles.

Conclusion
Dans ce chapitre, nous avons exploré les enjeux liés à la sécurité de l’architecture réseau de la Sodecoton
et nous avons identifié la nécessité de mettre en place un système de détection d’intrusions. Nous avons exa-
miné les problématiques liées au choix, à la configuration, à l’intégration et à la sensibilisation des utilisateurs.
En mettant en œuvre ce système, la Sodecoton pourra détecter, analyser et prévenir les attaques potentielles,
assurant ainsi une meilleure protection de ses ressources et de ses données sensibles. Dans le chapitre suivant,
nous approfondirons les concepts généraux des réseaux informatiques dans le contexte spécifique de l’entreprise
Sodecoton.

Chapitre 2
GÉNÉRALITÉS SUR LES RÉSEAUX INFORMATIQUES
2.1 Réseaux informatiques

Un réseau informatique se compose d’un groupe d’ordinateurs ou d’équipements informatiques intercon-
nectés grâce à des protocoles de communication standardisés. Son rôle principal est de faciliter l’échange de
données numériques et le partage de ressources telles que des imprimantes ou des disques, entre différents sys-
tèmes et applications informatiques, tels que les logiciels de traitement de texte ou les navigateurs Web. Un
système de détection d’intrusions (IDS - Intrusion Detection System), est constitué d’un ensemble de compo-
sants logiciels et/ou matériels qui ont pour rôle principal de repérer et analyser des activités inhabituelles ou
suspectes sur la cible étudiée, que ce soit un réseau ou un hôte. Son objectif est de fournir une visibilité sur les
tentatives d’intrusion, qu’elles soient réussies ou non [9].
2.2 Classification des réseaux

Il est possible de classifier les réseaux informatiques en plusieurs types en fonction de leur étendue, de leur
architecture et de leur topologie [9]. Cette classification est illustrée dans la figure 2.1.
2.2.1 Classification selon l’étendue géographique

• Un réseau personnel (PAN : Personal Area Network), est une interconnexion, souvent sans fil,
d’équipements personnels tels qu’un ordinateur portable, un agenda électronique, etc. Il est généralement
utilisé à l’intérieur d’un espace restreint d’environ une dizaine de mètres.
• Un réseau local (LAN : Local Area Network), est un réseau qui couvre une zone restreinte, allant
de quelques mètres à quelques kilomètres, et qui est généralement utilisé au sein d’une entreprise. Il peut
s’étendre sur plusieurs bâtiments de cette entreprise.
• Un réseau métropolitain (MAN : Metropolitan Area Network), relie plusieurs emplacements
situés dans une même ville, tels que les différents sites d’une université ou d’une administration, chacun
ayant son propre réseau local.
• Un réseau WAN (Wide Area Network), est un type de réseau informatique qui couvre une vaste
zone géographique, généralement étendue sur plusieurs sites géographiquement dispersés. Contrairement à
un réseau local (LAN) qui relie des périphériques au sein d’une seule localisation, un réseau WAN permet
la connectivité entre des sites distants, parfois situés dans différentes villes, régions ou pays.

Figure 2.1 – Différents réseaux.
2.2.2 Classification selon l’architecture

En général, on peut identifier deux types courants de réseaux locaux :
• Réseau poste à poste (peer to peer) :

Les ordinateurs sont interconnectés physiquement, permettant à chaque poste de partager ses données et
ressources avec le réseau. Chaque poste peut jouer le rôle de client et de serveur, ce qui le rend particulièrement
adapté aux petites structures. Dans un réseau poste à poste, les ressources telles que les imprimantes, les fax
et les modems sont généralement connectées à un ordinateur central qui les partage avec les autres ordinateurs
du réseau. Vous pouvez consulter la Figure 2.2 pour visualiser cette configuration.
Figure 2.2 – Réseau poste à poste.
Dans ce type de réseau, chaque utilisateur est responsable de l’administration de son propre ordinateur,
permettant ainsi aux autres utilisateurs d’y accéder. Cependant, cela pose des problèmes de sécurité des don-
nées, et l’utilisateur n’aura pas accès au réseau distant ni à la messagerie Internet.
• Réseau client / serveur :
Dans une architecture client/serveur, l’un des ordinateurs du réseau est désigné comme le serveur, et il est
généralement doté d’une puissance de traitement élevée. Ce serveur est responsable de fournir les informations,
telles que les connexions, aux autres ordinateurs qui agissent en tant que postes clients. Vous pouvez vous référer
à la Figure 2.3 pour visualiser cette configuration.

Figure 2.3 – Réseau poste à poste.
Les architectures client-serveur sont typiquement gérées par des administrateurs système, et leur mainte-
nance est relativement simple lorsqu’ils sont situés dans le même lieu physique. Cette architecture est extensible
et facilite la détection des pannes, car lorsque plusieurs ordinateurs rencontrent le même problème, le serveur
est souvent identifié comme la source du problème. Un aspect essentiel est la sauvegarde des données.
2.2.3 Classification selon la topologie

Il existe deux types de topologies distinctes qui diffèrent dans leur utilisation :
• La topologie logique décrit le mode de fonctionnement du réseau, la répartition des nœuds et la manière
dont les données circulent dans les lignes de communication.
• La topologie physique indique comment les différentes stations sont connectées physiquement (par le biais
du câblage)
En ce qui concerne les réseaux informatiques, la topologie peut être divisée en trois groupes distincts :
a. Réseaux en étoile :
Dans cette topologie, chaque nœud est directement connecté à un nœud central, qui agit comme un concen-
trateur (hubs). Les données circulent des nœuds périphériques vers le nœud central, qui doit gérer chaque
liaison individuellement. (Voir figure 2.4).
Figure 2.4 – Architecture en étoile.

L’ajout de ce hub entraîne une légère augmentation des coûts du réseau, mais il renforce sa fiabilité. En
cas d’interruption de la connexion vers une machine, seule cette dernière sera déconnectée, tandis que le
reste du réseau continuera de fonctionner normalement.
b. Réseaux en anneau :
Dans cette topologie, chaque nœud est connecté au nœud suivant et au nœud précédent, créant ainsi une
boucle fermée ou un anneau. Le flux d’information, représenté par un jeton, circule à travers chaque nœud
et retourne à l’expéditeur en indiquant quel ordinateur a le droit d’émettre. Les ordinateurs capturent le
jeton lorsqu’ils ont des données à transmettre ou le passent au nœud suivant s’ils n’ont rien à envoyer.
Cette organisation prévient les collisions entre les transmissions de données (voir figure 2.5).
Figure 2.5 – Architecture en anneau.
En cas de défaillance d’une des entités actives, cela entraîne une paralysie du trafic réseau et rend difficile
l’ajout d’une nouvelle station.
c. Réseaux en bus : Dans cette topologie, tous les nœuds sont connectés à un bus, c’est-à-dire une ligne
physique commune. Les informations sont transmises à travers chaque nœud et atteignent finalement l’ex-
trémité du bus. Les transmissions se font donc par un seul lien, permettant à un seul ordinateur d’émettre
des données à la fois. Afin de prévenir les perturbations causées par l’écho du signal, des terminateurs ou
"bouchons" sont placés aux extrémités du câble, absorbant le signal. Cette configuration est illustrée dans
la figure 2.6.
Figure 2.6 – Architecture en bus.
Ce type de réseau présente l’avantage de sa simplicité, car il ne nécessite aucun autre équipement en
dehors de la connexion des cartes réseau des différentes machines. Cependant, l’inconvénient est que ce
type de liaison est relativement fragile, car toute défaillance de connexion affecte l’ensemble du réseau.

2.3 Modèle OSI

L’OSI (Open Systems Interconnection) est un modèle normalisé par l’Organisation internationale de nor-
malisation (ISO) pour faciliter la communication et l’interopérabilité entre différents systèmes informatiques. Ce
modèle est basé sur une architecture en 7 couches numérotées, qui regroupent différentes fonctions nécessaires
à la communication. Parfois, ces couches sont réparties en deux groupes distincts, comme le montre le tableau
d’architecture ci-dessous.
Table 2.1 – Modèle OSI [10].
Les réseaux informatiques sont composés de plusieurs couches qui jouent des rôles spécifiques dans le
transfert et le traitement des informations. Les couches inférieures (1, 2, 3 et 4) sont essentielles pour acheminer
les données entre les points de communication et dépendent du support physique utilisé. Les couches supérieures
(5, 6 et 7) sont responsables du traitement des informations liées à la gestion des échanges entre systèmes in-
formatiques. Les couches 1 à 3 agissent entre des machines voisines, tandis que les couches 4 à 7 interviennent
entre des hôtes distants. Il est important de noter que ces couches peuvent être séparées par plusieurs routeurs
lorsqu’il s’agit de machines d’extrémité.
2.3.1 Caractérisation des différentes couches :

Le modèle OSI se compose de sept couches, chacune ayant des fonctions spécifiques pour la manipulation
de commandes et de données. Voici une description détaillée de ces couches [11] :
• La couche physique est responsable de la transmission effective des signaux entre les interlocuteurs. Son
service se limite à l’émission et à la réception d’un bit ou d’un train de bits continus.
• La couche liaison de données gère les communications entre deux machines directement connectées ou
connectées à un équipement qui émule une connexion directe, comme un commutateur. Elle joue un rôle
important dans la détection et la correction d’erreurs survenues au niveau de la couche physique.
• La couche réseau gère les communications entre les machines, y compris les sous-réseaux, le routage et
l’adressage des paquets.
• La couche transport est l’une des plus importantes, car elle assure la gestion des communications de
bout en bout entre les processus en cours d’exécution. Elle est responsable de l’acheminement correct des

messages complets vers le destinataire. Son rôle principal est de prendre les messages de la couche session,
de les découper si nécessaire en unités plus petites, et de les transmettre à la couche réseau tout en veillant
à ce que les morceaux arrivent correctement de l’autre côté. Elle effectue également le réassemblage du
message à la réception des morceaux.
• La couche session gère la synchronisation des échanges et des transactions, permettant l’ouverture et la
fermeture de session.
• La couche liaison de données établit la corrélation entre les adresses logiques et physiques des tâches
réparties, ainsi qu’une liaison entre deux programmes d’application nécessitant une coopération et un
dialogue.
• La couche présentation est responsable du codage des données applicatives, convertissant les données du
niveau applicatif en chaînes d’octets transmises. Elle peut également reformater, crypter et compresser les
données.
• La couche application fournit un point d’accès aux services réseau, sans avoir de service spécifique propre
dans le cadre de la norme.
2.4 TCP/IP
TCP/IP est un ensemble de protocoles utilisés pour le transfert de données sur Internet. Il est couramment
appelé TCP/IP en référence à ses deux premiers protocoles, TCP (Transmission Control Protocol) et IP (Internet
Protocol) [12].
Dans cette suite, le modèle TCP/IP comprend quatre couches principales. La couche IP, également appelée
couche basse, se concentre sur l’adressage logique et l’acheminement des paquets d’un nœud à un autre. La
couche TCP, quant à elle, est la couche haute du modèle et gère les erreurs et le contrôle du flux en mettant en
place des mécanismes de répétition de paquets et d’ajustement de la fenêtre de réception.
Il convient de noter que bien que certaines couches du modèle TCP/IP portent le même nom que les couches
du modèle OSI, elles ont des fonctions distinctes. Le modèle TCP/IP est composé des couches suivantes :
application, transport, Internet et accès au réseau.
Cette structure en couches permet à TCP/IP de fournir des fonctionnalités essentielles pour le transfert de
données sur Internet, en garantissant un acheminement fiable et en contrôlant les erreurs et le flux des données.
• Couche application : La couche application se trouve au sommet de la pile de protocoles TCP/IP. Elle
comprend des applications réseau qui facilitent la communication en utilisant les couches inférieures. La
couche application gère les protocoles de haut niveau, y compris la représentation, le codage et le contrôle
des dialogues.
• Couche transport : Tout d’abord, la couche transport assure une communication directe entre l’émetteur
et le destinataire, ignorant les machines intermédiaires. Deux protocoles sont utilisés dans cette couche
pour l’échange de données : TCP (Transmission Control Protocol) régule le flux de données et garantit
un transport fiable, tandis que UDP (User Datagram Protocol) assure un transport non fiable. Dans le
cas d’UDP, il n’y a aucune garantie que les datagrammes parviennent à destination, la responsabilité de
s’en assurer revient à la couche application.
• Couche internet : La couche Internet joue un rôle essentiel dans l’acheminement des paquets de données
d’un réseau source vers leur destination, quel que soit le chemin emprunté ou les réseaux traversés. Le
protocole qui gère cette couche est appelé protocole IP (Internet Protocol). C’est à ce niveau que se déroule

l’identification du chemin optimal et la commutation des paquets.
• Couche accès réseau : La première couche de la pile TCP/IP, également connue sous le nom de couche
physique, s’occupe de toutes les opérations nécessaires pour établir une connexion physique entre les ap-
pareils. Elle gère les tâches suivantes :
— Acheminement des données sur la liaison. Coordination de la transmission des données pour assurer
la synchronisation.
— Conversion des signaux entre le format analogique et numérique.
— Contrôle des erreurs lors de la réception des données.
Table 2.2 – Standard du modèle OSI et modèle TCP [12].
2.5 Encapsulation des données

Pendant une transmission, les données passent par chaque couche au niveau de la machine émettrice. À
chaque couche, une entête contenant des informations est ajoutée au paquet de données pour assurer la trans-
mission. Lorsque le paquet atteint la machine réceptrice, chaque couche lit et supprime l’entête correspondante.
Ainsi, à la réception, le message est dans son état original, comme illustré dans la (’)figure 2.8) [12].

Figure 2.7 – Encapsulation des données.
2.6 Adressage
Chaque ordinateur au sein d’un réseau est identifié par une adresse IP unique de 32 bits. Cette adresse
est représentée en notation décimale, composée de quatre octets (0-255) séparés par des points. Une adresse IP
est composée d’un identifiant de réseau et d’un identifiant de machine, et elle appartient à l’une des classes (A,
B, C, D ou E) en fonction de la valeur de son premier octet, comme illustré dans la (figure 2.9) [12].

Figure 2.8 – Cinq classes d’adresses IP.
Le tableau ci-dessous présente les plages d’adresses disponibles pour chaque classe :
Certaines adresses IP sont considérées comme spéciales et ne doivent pas être utilisées dans un réseau. Voici
Table 2.3 – Espace d’adresse [12].
quelques exemples :
• L’adresse 0.0.0.0 est utilisée par une machine pour connaître sa propre adresse IP.
• Les adresses de la forme <partie réseau>.<partie machine nulle> ne sont jamais attribuées à une machine
car elles désignent le réseau lui-même.
• Les adresses de la forme <partie réseau>.<partie machine avec tous ses bits à 1> sont des adresses de
diffusion ou de broadcasting, elles permettent d’envoyer des messages à toutes les machines du réseau
concerné.
• L’adresse 255.255.255.255 est une adresse de diffusion locale car elle désigne toutes les machines du réseau.
• L’adresse de la forme 127.X.Y.Z (où X, Y et Z sont des nombres) est une adresse de rebouclage utilisée
pour les communications inter-processus sur un même ordinateur ou pour effectuer des tests de logiciels.
2.7 Routage IP
Le routage est une fonction essentielle dans un réseau maillé pour déterminer le chemin optimal vers une
destination spécifiée par une adresse IP. Il implique trois fonctions distinctes [12] :

• Le relayage (forwarding) : il consiste à calculer le port de sortie en analysant l’adresse de destination du

paquet et en consultant une table de routage appropriée.
• La commutation (switching) : cette fonction transfère les fragments de paquets d’un port d’entrée vers un
port de sortie à travers un bus de communication
• L’ordonnancement (scheduling) : elle détermine l’ordre d’émission des paquets sur la liaison de sortie.
En combinant ces trois fonctions, le routage permet d’acheminer efficacement les paquets de données vers leur
destination en utilisant le chemin le plus approprié, contribuant ainsi au bon fonctionnement et à la performance
du réseau maillé.
Le routage peut être divisé en deux grandes catégories pour faciliter la compréhension et la gestion :
❖ Le routage direct :
— L’objectif est de transmettre un datagramme à une machine connectée au même réseau local (LAN).
— L’émetteur effectue une résolution d’adresse physique (ARP) pour trouver l’adresse physique du destina-
taire, puis il encapsule le datagramme dans une trame et l’envoie.
❖ Le routage indirect :
Lorsque le destinataire n’est pas situé sur le même réseau local (LAN) que l’émetteur, il devient nécessaire de
passer par une passerelle préalablement définie ou d’utiliser un chemin par défaut pour acheminer les données.
En effet, toutes les machines cibles ne se trouvent pas nécessairement sur le même réseau physique, notamment
sur Internet qui regroupe de nombreux réseaux distincts. Cependant, cette opération est plus complexe que
précédemment, car il faut choisir judicieusement une passerelle appropriée pour assurer le bon acheminement
des données.
2.7.1 Deux modes de routages

Lorsque nous envisageons de mettre en place un protocole de routage, il existe deux modes de routage
clairement distincts : le routage statique et le routage dynamique.
a. Rroutage statique : Dans le routage statique, les administrateurs configurent individuellement chaque
routeur du réseau pour y saisir les itinéraires à suivre (via le port de sortie ou l’adresse IP de destination)
afin d’atteindre les différents réseaux. De manière concrète, chaque routeur agit comme un pont entre
deux réseaux, et le routeur suivant fait office de pont entre deux autres réseaux.
b. Rroutage dynamiquee :
Le routage dynamique offre l’avantage d’une mise à jour automatique. En définissant un protocole de
routage, les routeurs peuvent communiquer entre eux de manière périodique ou en réponse à des événe-
ments, permettant ainsi à chaque routeur d’être informé des changements dans le réseau sans nécessiter
d’intervention manuelle de l’administrateur réseau. En substance, le protocole de routage établit les règles
de communication entre les routeurs et détermine également comment ils calculent les meilleures routes à
prendre.
2.8 Protocoles de communication

Un protocole réseau désigne un ensemble de règles et de procédures permettant aux stations de commu-
nication d’échanger des données sur un réseau. Il existe différents protocoles réseau, chacun ayant un rôle et

une méthode de fonctionnement spécifiques. Certains protocoles opèrent à plusieurs niveaux du modèle OSI,
tandis que d’autres se spécialisent dans une tâche précise correspondant à une seule couche du modèle OSI.
Lorsqu’un paquet est transmis sur le réseau, il est composé de plusieurs couches d’informations correspondant
aux différents traitements effectués par les protocoles de la pile [13].
2.8.1 Protocole ARP

L’Address Resolution Protocol (ARP) est un protocole qui permet de traduire une adresse de protocole
de couche réseau (généralement une adresse IPv4) en une adresse MAC (généralement une adresse Ethernet) ou
toute autre adresse matérielle de couche de liaison. Il agit comme une interface entre la couche réseau (couche
3 du modèle OSI) et la couche de liaison (couche 2 du modèle OSI).
2.8.2 Protocole DHCP

Le Dynamic Host Configuration Protocol (DHCP) est un protocole réseau qui permet la configuration
automatique des paramètres IP d’une station. Son rôle principal est d’assigner automatiquement une adresse
IP et un masque de sous-réseau à la station, facilitant ainsi sa connectivité au réseau.
2.8.3 Protocole FTP

Le protocole de transfert de fichiers (FTP) est utilisé pour partager des fichiers sur un réseau TCP/IP. Il
permet à un ordinateur de copier, supprimer ou modifier des fichiers sur un autre ordinateur du réseau. FTP suit
un modèle client-serveur, où le client envoie des requêtes au serveur. Le serveur FTP est un logiciel fonctionnant
sur un ordinateur dédié. FTP est un protocole de la couche application du modèle OSI et utilise une connexion
TCP.
2.8.4 Protocole HTTP

L’HyperText Transfer Protocol (HTTP) est un protocole de communication de la couche application. Il
est conçu pour fonctionner sur des connexions fiables et permet l’échange de données de divers types. Les navi-
gateurs Web sont parmi les clients HTTP les plus couramment utilisés, permettant aux utilisateurs d’accéder à
des serveurs contenant les données souhaitées.
2.8.5 Protocole RIP

Le Routing Information Protocol (RIP) est un protocole de routage IP basé sur le vecteur de distances.
Son rôle est de permettre à chaque routeur de partager avec ses routeurs voisins la métrique, qui représente
la distance jusqu’à un réseau IP spécifique. Chaque routeur conserve l’adresse du routeur voisin qui offre la
métrique la plus faible pour chaque réseau IP connu. Ces informations de routage sont diffusées toutes les 30
secondes pour assurer la mise à jour régulière des meilleures routes.

2.8.6 Protocole TELNET

Le réseau de terminaux, également connu sous le nom de réseau de télécommunication, est un protocole
utilisé sur les réseaux TCP/IP. Il facilite la communication avec un serveur distant en échangeant des lignes de
texte et en recevant des réponses sous forme de texte. Ce protocole est situé dans la couche d’application du
modèle OSI.
2.8.7 Protocole DNS

Le système de noms de domaine (DNS) est un service essentiel qui associe une adresse IP à un nom de
domaine. Il joue un rôle vital dans le fonctionnement d’Internet. En utilisant des noms conviviaux plutôt que des
adresses IP numériques, le DNS facilite l’apprentissage et la mémorisation des informations pour les utilisateurs.
En d’autres termes, il permet aux utilisateurs d’ordinateurs clients d’identifier des hôtes distants en utilisant
des noms plutôt que des adresses IP.
2.8.8 Protocole UDP

L’User Datagram Protocol (UDP), également connu en français sous le nom de protocole de datagramme
utilisateur, est l’un des principaux protocoles de télécommunication utilisés par Internet. Il fait partie de la
couche transport du modèle OSI, plus précisément de la couche 4, tout comme TCP.
Le rôle principal de ce protocole est de permettre une transmission de données simple entre deux entités
identifiées par une adresse IP et un numéro de port. Contrairement à TCP, UDP fonctionne sans négociation
préalable avant l’envoi des données. Ainsi, UDP ne garantit ni la bonne livraison des datagrammes à destination
ni leur ordre d’arrivée. De plus, il est possible que des datagrammes soient reçus en plusieurs exemplaires.
2.9 Équipements réseaux

L’infrastructure d’un réseau comprend à la fois les équipements qui le composent et les connexions entre
ces éléments. Elle permet d’établir les liaisons possibles entre les équipements et assure l’interconnexion des
moyens physiques grâce à l’utilisation de protocoles de communication. Les principaux équipements qui font
partie de cette infrastructure sont [13] :
2.9.1 Serveur
Un serveur est un système informatique équipé de logiciels conçus pour répondre automatiquement à des
demandes et offrir des services. Il est utilisé par plusieurs clients simultanément et permet de stocker, partager
et échanger des informations.
2.9.2 Carte réseau

Une carte réseau est un dispositif permettant de connecter un équipement, tel qu’un ordinateur ou une
imprimante, à un réseau. Chaque carte possède une adresse MAC (Media Access Control) fixée par le fabricant,
qui identifie de manière unique l’équipement au sein du réseau.

2.9.3 Concentrateur ou hub

Cet équipement, qui fonctionne comme un simple répéteur de données, a pour rôle de diffuser la trame
reçue à tous les équipements connectés, permettant ainsi la création d’un réseau local Ethernet.
2.9.4 Commutateur réseau ou switch

Le commutateur réseau a la capacité de déterminer l’adresse à laquelle une trame est destinée, ce qui lui
permet de diffuser la trame reçue vers l’équipement correspondant. Il se base sur une table d’adresses MAC
pour acheminer la trame vers l’équipement approprié. Le concentrateur et le commutateur réseau interviennent
au niveau de la couche de liaison des données du modèle OSI.
2.9.5 Routeur
Le rôle du routeur est d’acheminer les paquets de données entre deux réseaux, qu’ils utilisent le même
protocole ou non. Il est nécessaire d’avoir une connexion à deux réseaux afin de permettre le routage des trames.
Le routeur opère au niveau de la couche réseau du modèle OSI.
2.9.6 Passerelle ou gateway

Une passerelle est un dispositif qui permet la connexion de deux réseaux informatiques hétérogènes, en
agissant entre les niveaux 4 et 7 du modèle OSI. En général, une passerelle intègre des composants tels qu’un
pare-feu ou un serveur mandataire.
2.9.7 Répéteur
Un commutateur est un dispositif électronique simple qui amplifie un signal et étend la portée d’un ré-
seau en augmentant la taille du support physique. Contrairement à un élément intelligent, il ne fournit pas de
fonctionnalités supplémentaires, mais se limite à l’extension physique. Son fonctionnement est uniquement basé
sur la couche physique du modèle OSI.
2.9.8 Pont ou bridge

Un commutateur réseau est un dispositif qui permet de connecter des réseaux fonctionnant avec le même
protocole. Son rôle principal est de fournir une interconnexion logique entre deux segments de réseaux distincts,
qu’ils utilisent des technologies différentes ou la même technologie, mais sont physiquement séparés pour des
raisons telles que la géographie ou l’extension d’un site.

Conclusion
Dans ce chapitre, nous avons abordé les concepts fondamentaux des réseaux informatiques, tels que les
architectures, les types, les topologies, ainsi que les modèles de standardisation tels que l’OSI et le TCP/IP.
Nous avons examiné en détail les protocoles associés à chaque couche de ces modèles et nous avons également
discuté du routage IP. Nous avons également présenté les composants clés du réseau, tels que les commutateurs,
les concentrateurs et les serveurs, qui jouent un rôle essentiel dans le transfert des informations. Malgré les avan-
tages offerts par ces éléments réseau, leur développement a également engendré des défis majeurs, notamment
en termes de complexité croissante et de vulnérabilités aux attaques informatiques. Dans le deuxième chapitre,
nous aborderons en détail ces vulnérabilités et proposerons des mesures de précaution spécifiques à mettre en
place pour garantir la sécurité du réseau de la Sodecoton.

Chapitre 3
SÉCURITÉ DES RÉSEAUX INFORMATIQUES ET SYSTÈME DE
DÉTECTION D’INTRUSIONS DANS L’ARCHITECTURE
RÉSEAU
Introduction
Dans l’architecture réseau de la Sodecoton, l’échange de données comporte des risques significatifs en ma-
tière de sécurité informatique. Les ordinateurs connectés à des réseaux externes, tels qu’Internet, présentent des
vulnérabilités exploitées par des pirates pour mener leurs attaques. Les conséquences de ces attaques peuvent
être graves, allant du vol d’informations à l’accès à des données confidentielles, voire à la paralysie des services.
Ainsi, il est essentiel de mettre en place des mesures de sécurité pour se prémunir contre ces attaques. Dans ce
chapitre, nous examinerons les différentes formes d’attaques et les moyens mis à la disposition de la direction
informatique de la Sodecoton pour sécuriser les données informatiques.
3.1 Définition et critères de la sécurité informatique
3.1.1 Définition
La sécurité informatique englobe toutes les mesures prises pour minimiser la vulnérabilité d’un système
face aux menaces, qu’elles soient accidentelles ou intentionnelles. Il est essentiel d’identifier les exigences fonda-
mentales en matière de sécurité informatique, qui définissent les attentes des utilisateurs en termes de sécurité
pour les systèmes informatiques [14].
3.1.2 Critères de la sécurité informatique

Les objectifs d’une politique de sécurité sont d’assurer la protection des informations et des réseaux de
l’entreprise. Ces objectifs peuvent être définis à différents niveaux pour répondre aux exigences de sécurité.
• Intégrité : est un processus visant à déterminer si les données n’ont pas été altérées. Il s’agit de s’assurer
que les données reçues sont bien celles que l’on pense être, garantissant ainsi leur authenticité et leur
intégrité.
• Confidentialité : est de garantir que seules les personnes autorisées puissent accéder aux ressources
échangées.

• Disponibilité : est d’assurer l’accès continu à un service ou à des ressources, permettant de maintenir
le fonctionnement optimal du système d’information en rendant les informations accessibles au moment
souhaité.
• Non répudiation : est un concept qui garantit qu’une transaction ne peut être niée. La non-répudiation de
l’origine atteste que les données ont été envoyées, tandis que la non-répudiation de l’arrivée prouve qu’elles
ont été reçues. Ainsi, la non-répudiation assure l’intégrité et la fiabilité des transactions en empêchant
toute contestation ultérieure de leur réalisation ou de leur réception.
• Authentification : vise à garantir que seules les personnes autorisées ont accès aux ressources. Elle assure
l’identification d’un utilisateur, c’est-à-dire qu’elle assure à chaque partie que son interlocuteur est bien
la personne qu’elle prétend être. Le contrôle d’accès permet d’autoriser l’accès aux ressources uniquement
aux personnes autorisées [15].
3.1.3 Politique de sécurité

Une politique de sécurité, également appelée stratégie de sécurité, est un ensemble de règles formelles qui
doivent être suivies par les personnes ayant accès aux ressources et aux données de l’entreprise. Son objectif
principal est de protéger le réseau contre les attaques, qu’elles proviennent de l’intérieur ou de l’extérieur de
l’organisation[15].
En d’autres termes, une politique de sécurité établit des règles, des procédures et des bonnes pratiques
visant à garantir un niveau de sécurité conforme aux besoins de l’entreprise :
• Identifier les risques informatiques et comprendre les conséquences potentielles qui en découlent.
• Élaborer des règles et des procédures spécifiques à mettre en place au sein des services de l’organisation
pour faire face à ces risques identifiés.
• Assurer une surveillance régulière et détecter les éventuelles vulnérabilités du système informatique.
3.1.4 Types de politique de sécurité

a. Politique qui autorise tout par défaut :
Dans cette approche, le principe est que tout ce qui n’est pas explicitement interdit est considéré comme
autorisé. Elle implique d’analyser les risques associés aux applications qui doivent être exécutées, de
déterminer les restrictions à appliquer en conséquence, et de permettre toutes les autres actions qui ne
sont pas spécifiquement interdites.
b. Politique qui interdit tout par défaut :
Implique que seules les actions explicitement autorisées sont permises. Cela suppose de définir les services
qui seront autorisés, tels que l’accès HTTP au Web, et de spécifier les droits attribués à chaque utilisateur
[16].
3.2 Menaces indirectes et les attaques pernicieuses

Une menace informatique se réfère à des actions potentiellement préjudiciables à un système informatique.
En matière de sécurité informatique, ces menaces peuvent résulter de différentes actions, provenant d’adversaires
déterminés capables d’exploiter les vulnérabilités existantes [16].

3.2.1 Types de menaces

a. Menaces accidentelles
Font référence à des erreurs non intentionnelles commises par les utilisateurs, telles que la perte acci-
dentelle de données, la détérioration ou la destruction involontaire de matériel, ainsi que la copie illicite
de logiciels.
b. Menaces intentionnelles
Fait référence à une action délibérée entreprise par une entité dans le but de compromettre la sécurité
des informations et d’utiliser les ressources de manière non autorisée. Ces menaces peuvent prendre des
formes passives ou actives.
c. Menaces passives
Se réfèrent à l’écoute du trafic d’un réseau ou d’une machine cible. L’attaquant configure son interface
en mode d’écoute pour capturer des trames du réseau cible, dans le but de découvrir et de collecter des
informations sensibles telles que des clés de cryptage, des mots de passe ou d’autres données confidentielles.
Les outils utilisés pour ces attaques incluent les sniffeurs et les scanners.
d. Menaces actives :
quant à elles, impliquent une modification de données ou de messages, une intrusion dans les équipements
réseau, une perturbation du bon fonctionnement du réseau, ou encore une interrogation du réseau ou de
la machine cible. Les attaquants cherchent à contourner les dispositifs de sécurité existants en utilisant
différentes méthodes telles que le déni de service et les virus.
3.2.2 Types d’attaques

Les hackers déploient diverses techniques d’attaque, qui peuvent être regroupées en deux catégories distinctes
selon :
a. Attaques directes
Il s’agit d’une attaque directe où le pirate informatique cible directement sa victime à partir de son
propre ordinateur. Les outils de piratage utilisés dans ce cas sont souvent peu personnalisables, et de
nombreux logiciels envoient les paquets de manière directe à la victime, comme illustré dans la (Figure
3.1).
Dans ce scénario, il est généralement possible de remonter jusqu’à l’origine de l’attaque, ce qui permet
également d’identifier l’identité de l’attaquant.
Figure 3.1 – Attaque directe.
b. Attaques indirectes
— Attaques indirectes par rebond :

Le rebond est une méthode d’attaque très prisée par les hackers en raison de ses deux avantages
distincts :
— Dissimuler l’identité du pirate informatique en masquant son adresse IP.

— Utiliser éventuellement les ressources d’un ordinateur intermédiaire plus puissant en termes de capa-
cités (CPU, bande passante, etc.) pour mener l’attaque.
L’attaquant utilise un ordinateur intermédiaire pour envoyer les paquets d’attaques à la victime, mas-
quant ainsi ses propres traces telles que son adresse IP. Cette méthode permet également à l’attaquant
d’exploiter les ressources de l’ordinateur intermédiaire en tant que rebond. Vous pouvez vous référer à la
Figure 3.2 pour une illustration visuelle.
Figure 3.2 – Attaque indirecte par rebond.
3.2.3 Attaques indirectes par réponse

Cette attaque est une variante de l’attaque par rebond, offrant les mêmes avantages pour le hacker. Ce-
pendant, au lieu d’envoyer une attaque directe à l’ordinateur intermédiaire pour qu’il la transmette, l’attaquant
envoie une requête à cet ordinateur. La réponse à cette requête est ensuite redirigée vers l’ordinateur ciblé,
constituant ainsi l’attaque (voir figure 3.3).
Figure 3.3 – Attaque indirecte par rebond.

3.3 Techniques d’attaques et attaques réseau
3.3.1 Techniques d’attaques

a. Attaques applicatives
• Virus : c’est un code malveillant intégré à un programme qui se duplique de lui-même dans d’autres
programmes. Il se propage en infectant des fichiers légitimes appelés "hôtes" et peut se propager à
d’autres ordinateurs. Son objectif est de causer des dommages en détruisant des données, en rendant
certaines fonctions de l’ordinateur inutilisables ou en ralentissant les opérations.
• Vers : c’est un petit programme qui se propage d’un ordinateur à un autre. Contrairement à un
virus, un ver ne peut pas s’attacher à un autre programme pour l’infecter. Il se copie simplement
d’ordinateur en ordinateur via un réseau tel qu’Internet ou même par le biais de lecteurs de disquettes
ou de graveurs. Les vers peuvent donc non seulement affecter un ordinateur, mais aussi dégrader les
performances des réseaux. Comme les virus, les vers peuvent contenir des actions nuisibles, telles que
le formatage du disque dur ou l’envoi de données confidentielles, ce qui peut avoir des conséquences
très graves.
• Cheval de Troie : c’est un programme exécutable qui se présente initialement comme bénéfique
pour un ordinateur, tel qu’un logiciel gratuit ou sous licence. Cependant, une fois lancé, ce programme
effectue des actions malveillantes plus ou moins graves, telles que la suppression de mots de passe, le
vol d’informations confidentielles, l’envoi de données au créateur du programme ou même le formatage
du disque dur de l’ordinateur.
• Bombe logique : c’est un code intégré dans des programmes légitimes qui s’active à un moment
précis en exploitant la date du système, le déclenchement d’une commande ou tout autre appel au
système.
• Trappes (portes dérobées) : sont des points d’entrée secrets, généralement codés, qui permettent
aux développeurs d’accéder et de tester des programmes lorsqu’il y a des bugs, par exemple. Cepen-
dant, ces portes dérobées peuvent également être exploitées par des utilisateurs non autorisés, ce qui
pose un risque de sécurité.
• Exploit : c’est une composante logicielle ou un code permettant à un individu ou à un logiciel
malveillant de tirer parti d’une vulnérabilité de sécurité présente dans un système d’exploitation ou
un logiciel. Cette exploitation peut se faire à distance ou localement sur la machine ciblée, dans le
but de compromettre un ordinateur ou un réseau, d’augmenter les privilèges d’un logiciel ou d’un
utilisateur, ou encore de réaliser une attaque par déni de service.
• Logiciel espion : également connu sous le nom de spyware, est un programme malveillant qui
collecte des informations personnelles sur l’ordinateur d’un utilisateur sans son consentement, puis
les envoie à un tiers non autorisé.
• Enregistreur de frappe : également connu sous le nom de keylogger, est un programme installé
discrètement sur l’ordinateur d’un utilisateur dans le but d’enregistrer secrètement toutes les frappes
de clavier effectuées.
• Déni de service : survient lorsqu’un pirate désactive ou altère intentionnellement un réseau, des
systèmes ou des services afin d’empêcher leur utilisation normale par les utilisateurs légitimes. Les
attaques par déni de service peuvent entraîner une panne du système ou le ralentir au point de le
rendre inutilisable. Ces attaques peuvent consister en la suppression ou la modification de données.
Dans la plupart des cas, elles impliquent l’exécution d’un programme ou d’un script malveillant.
C’est pourquoi les attaques par déni de service sont considérées comme extrêmement dangereuses et
préoccupantes [17].

• Attaques de mot de passe : peuvent être réalisées à l’aide d’un analyseur de paquets pour inter-
cepter les comptes et les mots de passe des utilisateurs transmis en clair. Ces attaques se réfèrent
généralement aux tentatives répétées de connexion à une ressource partagée, comme un serveur ou un
routeur, dans le but de découvrir un compte utilisateur, un mot de passe, ou les deux. Ces tentatives
répétées sont communément appelées attaques par dictionnaire ou attaques par force brute.
• Attaque l’homme au milieu : également connue sous le nom d’attaque "man in the middle"
ou "attaque de l’intercepteur", est un scénario d’attaque où un pirate écoute une communication
entre deux parties et altère les échanges pour se faire passer pour l’une d’entre elles. Ces attaques,
couramment réalisées à l’aide d’un outil appelé sniffer, impliquent généralement l’écoute du réseau
pour intercepter les données échangées.
3.3.2 Attaques réseaux

a. Sniffing
C’est une technique utilisée par les hackers pour examiner le contenu de paquets de données et récupérer
des informations transitant sur un réseau qui ne leur étaient pas initialement destinées. Cette méthode
est fréquemment utilisée pour récupérer les mots de passe d’applications qui ne chiffrent pas leurs com-
munications, ainsi que pour identifier les machines communiquant sur le réseau.
b. Mystification
Également connue sous le terme de spoofing en anglais, est une technique qui implique de se faire passer
pour une autre personne ou une autre machine. Son objectif principal est de récupérer des informations
sensibles auxquelles on n’aurait pas normalement accès.
c. Usurpation d’adresse IP
Également connue sous le nom de mystification ou de spoofing IP en anglais, est une technique qui implique
le remplacement de l’adresse IP de l’expéditeur d’un paquet IP par celle d’une autre machine.
Cette technique permet à un pirate d’envoyer des paquets de manière anonyme, sans réellement changer
l’adresse IP, mais en masquant l’adresse IP dans les paquets émis. Il est important de noter que l’utilisa-
tion d’un proxy, qui permet de masquer partiellement l’adresse IP, est souvent confondue avec le spoofing
IP. Cependant, un proxy se contente de relayer les paquets, ce qui signifie qu’un pirate peut être facile-
ment identifié en examinant les fichiers journaux (logs) du proxy, même si son adresse semble être masquée.
d. ARP Poisoning
Également connu sous le nom d’empoisonnement ARP, est une attaque bien connue qui exploite une
vulnérabilité du protocole ARP (Address Resolution Protocol). Ce protocole est utilisé pour résoudre les
adresses IP en adresses MAC dans un réseau. L’objectif de cette attaque est d’intercepter le trafic entre
deux machines en falsifiant les informations d’adresse MAC. L’attaquant envoie des paquets ARP falsifiés
à chaque machine, indiquant que l’adresse MAC de l’autre machine a changé. Ainsi, lorsque l’une des
machines tente de communiquer avec l’autre, les paquets sont redirigés vers l’attaquant qui les transmet
ensuite de manière transparente à la machine destinataire [17].

3.4 Contre-mesures de différentes attaques
3.4.1 Antivirus
Les logiciels antivirus sont conçus pour détecter, éliminer, mettre en quarantaine et éventuellement réparer
les fichiers infectés par des virus sur un ordinateur, sans causer de dommages aux fichiers affectés.
Pour atteindre cet objectif, ils font appel à diverses techniques, notamment :
— Le contrôle exhaustif du système informatique.

— La surveillance des lecteurs de supports amovibles.
Il est généralement recommandé d’utiliser des antivirus sous licence et de les maintenir à jour, car cela permet
de corriger les vulnérabilités identifiées par les utilisateurs ou les développeurs de ces systèmes informatiques [18].
3.4.2 Mécanismes de chiffrement

a. Chiffrement symétrique
Le chiffrement symétrique repose sur l’utilisation d’une clé unique partagée entre les deux parties commu-
nicantes. Cette clé est utilisée à la fois pour le processus de chiffrement et de déchiffrement du message,
et doit rester secrète. Cependant, lorsque l’on souhaite envoyer un message chiffré à plusieurs personnes,
la gestion des clés symétriques devient complexe. Plus le nombre de destinataires augmente, plus il est
difficile de gérer les clés et de garantir leur sécurité lors de leur transmission.
Pour résoudre ce problème, un algorithme couramment utilisé consiste à effectuer des substitutions et des
transpositions successives sur les lettres du message. Par exemple, en appliquant le principe de substitution
décrit comme suit : "la première lettre devient la troisième, la seconde devient la première, la troisième
devient la quatrième et la quatrième devient la deuxième", le mot "MICROAPPLICATION" deviendrait
"IRMCAPOPIALCINTO". Cette illustration montre le concept du chiffrement symétrique.
Figure 3.4 – Chiffrement symétrique.
Ce système de chiffrement présente les inconvénients suivants :
— Il nécessite un nombre équivalent de paires de clés que de correspondants.

— Il ne garantit pas la non-répudiation. Si mon correspondant possède la même clé que moi, il peut
créer un message en se faisant passer pour moi.
— Il est nécessaire de transmettre la clé au départ sans utiliser le canal de communication à sécuriser.
b. Le chiffrement asymétrique
Le chiffrement asymétrique repose sur l’utilisation de deux clés générées individuellement :
— L’encodage avec la première clé permet le décodage avec la deuxième clé.

— L’encodage avec la deuxième clé permet le décodage avec la première clé. Selon la convention, l’une
des deux clés est appelée clé privée et l’autre clé publique. La clé privée est conservée de manière
confidentielle et ne doit jamais être transmise à quiconque, tandis que la clé publique peut être libre-
ment diffusée sans aucune restriction. Dans un processus de transmission simple, ce système permet
d’accomplir deux fonctions essentielles :
— Le premier objectif est de garantir la confidentialité d’un message transmis, c’est-à-dire que seul le
destinataire ait la capacité de le lire,
— tandis que le deuxième objectif est de permettre au destinataire de vérifier l’authenticité du message
en s’assurant qu’il provient bien de l’expéditeur légitime [19].
Figure 3.5 – Chiffrement asymétrique.
3.4.3 Pare-feu
Un pare-feu, également connu sous le nom de coupe-feu, garde-barrière ou firewall en anglais, est un
système qui assure la protection d’un ordinateur ou d’un réseau d’ordinateurs contre les intrusions prove-
nant d’un réseau tiers, notamment Internet. Le pare-feu agit comme une passerelle filtrante en contrôlant
les paquets de données échangés avec le réseau. Il est composé d’au moins deux interfaces réseau : une
interface pour le réseau à protéger (le réseau interne) et une interface pour le réseau externe. Cette confi-
guration permet de filtrer le trafic et de sécuriser les communications entre les deux réseaux. (Voir figure
3.6) [20].
Un système pare-feu est composé d’un ensemble de règles préétablies qui permettent les actions sui-
vantes :

Figure 3.6 – Fonctionnement d’un Pare feu.
— Autoriser la connexion (allow) : permettre l’établissement de la connexion entre deux entités.

— Bloquer la connexion (deny) : empêcher l’établissement de la connexion entre deux entités.
— Rejeter la demande de connexion sans avertir l’émetteur (drop) : refuser la demande de connexion
sans envoyer de notification à l’émetteur.
Ces règles permettent de mettre en place une méthode de filtrage qui dépend de la politique de
sécurité adoptée par l’entité. On distingue généralement deux types de politiques de sécurité qui
permettent :
— Autoriser uniquement les communications qui ont été explicitement autorisées : Cela signifie que
seules les connexions préalablement autorisées sont permises, suivant le principe de "Tout ce qui
n’est pas explicitement autorisé est interdit". Cette méthode est considérée comme la plus sûre, mais
elle nécessite une définition précise et contraignante des besoins en communication.
— Empêcher les échanges qui ont été explicitement interdits : Cette approche vise à bloquer les commu-
nications qui ont été explicitement interdites, tout en permettant toutes les autres connexions. Bien
que moins restrictive, cette méthode peut être moins sûre, car elle repose sur l’identification précise
des échanges interdits.
3.4.4 DMZ
Une zone démilitarisée (DMZ) est une partie du réseau local spécifiquement conçue pour être accessible
depuis l’extérieur du réseau, que ce soit avec ou sans authentification préalable. Elle est créée à des fins à la fois
techniques et stratégiques. La DMZ est un sous-réseau distinct du réseau local principal et est isolée de celui-ci
ainsi que d’Internet (ou d’un autre réseau) par le biais d’un pare-feu. Les machines hébergées dans cette DMZ
sont celles qui peuvent être accessibles depuis Internet. Le pare-feu assure un contrôle complet des communica-
tions, autorisant ou bloquant les accès au réseau local afin de garantir sa sécurité. Les services accessibles depuis
Internet sont spécifiquement positionnés dans la DMZ [21].
3.4.5 Proxy
Un serveur proxy, également connu sous le nom de "serveur mandataire", agit comme un intermédiaire
entre les ordinateurs d’un réseau local et Internet. En général, le serveur proxy est principalement utilisé pour
les connexions web, où il fonctionne en tant que proxy HTTP. Cependant, il existe également des serveurs proxy

pour d’autres protocoles applicatifs tels que FTP. Le principe de fonctionnement d’un serveur proxy est simple :
lorsque l’utilisateur se connecte à Internet à l’aide d’une application configurée pour utiliser un serveur proxy,
celle-ci établit d’abord une connexion avec le serveur proxy et lui transmet sa requête. Le serveur proxy se
connecte ensuite au serveur auquel l’application cliente souhaite accéder et lui transmet la requête. Le serveur
renvoie ensuite sa réponse au proxy, qui la transmet à son tour à l’application cliente.
Les serveurs proxy restent pertinents grâce à leur capacité à offrir un ensemble de fonctionnalités supplémen-
taires telles que :
• La fonction cache : Le cache, dans le domaine informatique, joue un rôle crucial en conservant en
mémoire les pages fréquemment consultées par les utilisateurs du réseau local, permettant ainsi de les
fournir rapidement. Cependant, pour assurer cette fonction, le proxy doit régulièrement comparer les
données en cache avec les données distantes pour vérifier leur validité. Ainsi, le cache agit comme un espace
de stockage temporaire de données, contribuant à optimiser les performances du réseau en réduisant les
temps de réponse.
• Le filtrage : D’autre part, l’utilisation d’un proxy permet de mettre en place un suivi des connexions en
enregistrant les requêtes des utilisateurs lors de leurs demandes de connexion à Internet, ce qui permet
de constituer des journaux d’activité (logs). Cette approche offre la possibilité de filtrer les connexions
en analysant à la fois les requêtes des clients et les réponses des serveurs. Lorsque le filtrage se base sur
une liste de requêtes autorisées, on parle de liste blanche, tandis que si une liste de sites interdits est
utilisée, on parle de liste noire. Par ailleurs, l’analyse des réponses des serveurs selon des critères prédéfinis
(mots-clés, etc.) est connue sous le nom de filtrage de contenu.
• L’authentification : Étant donné que le proxy joue un rôle essentiel en tant qu’intermédiaire pour
permettre aux utilisateurs du réseau interne d’accéder aux ressources externes, il offre parfois la possibilité
d’utiliser l’authentification des utilisateurs. Cela signifie qu’il est possible de demander aux utilisateurs
de s’identifier en utilisant un nom d’utilisateur et un mot de passe, par exemple. Ainsi, il devient facile
de restreindre l’accès aux ressources externes aux seules personnes autorisées et de consigner les accès
identifiés dans les fichiers journaux.
• Le reverse proxy : Le reverse-proxy, comme son nom l’indique, agit en tant qu’intermédiaire pour les
utilisateurs Internet qui souhaitent accéder à un site web interne. Il achemine les requêtes de manière
indirecte vers le serveur web, offrant ainsi une protection contre les attaques directes de l’extérieur et
renforçant la sécurité du réseau interne. De plus, le reverse-proxy peut répartir la charge en redirigeant
les requêtes vers plusieurs serveurs équivalents, ce qui permet un équilibrage de charge efficace (load
balancing).
3.4.6 Certificat électronique

La signature électronique est un ajout aux fichiers qui sert de preuve tangible de l’approbation du contenu
d’un document. Elle permet de vérifier l’auteur d’un fichier et de s’assurer qu’aucune altération n’a été apportée
au document. Sans une signature numérique, il est possible de remettre en question l’authenticité de la source
du document et de soupçonner qu’il ait été falsifié depuis sa publication. Par conséquent, il est préférable de ne
pas ouvrir un fichier, surtout si l’identité de l’auteur n’est pas certaine et que son contenu présente un potentiel
risque. La signature électronique offre plusieurs avantages, notamment une authentification solide de l’émetteur
et une garantie d’intégrité du document. En effet, le système permet de détecter facilement toute modification
apportée au document après sa signature, assurant ainsi sa fiabilité et sa non-altération [21].

3.5 Protocoles de Sécurité et VPN
3.5.1 Protocoles de Sécurité
a. Protocole HTTPS
L’HyperText Transfer Protocol Secure (HTTPS) est une version sécurisée du protocole HTTP qui in-
tègre une couche de chiffrement telle que SSL (Secure Sockets Layer) ou TLS (Transport Layer Security).
HTTPS permet aux visiteurs de vérifier l’authenticité du site web qu’ils visitent en utilisant un certifi-
cat d’authentification. Il offre une protection théorique de la confidentialité et de l’intégrité des données
échangées entre l’utilisateur et le serveur. Cela est rendu possible grâce à l’utilisation de méthodes de
cryptographie asymétrique pour l’authentification et de méthodes de cryptographie symétrique pour le
chiffrement des données. En résumé, HTTPS garantit une connexion sécurisée en utilisant des techniques
de cryptage avancées pour assurer la confidentialité et l’intégrité des informations échangées entre le na-
vigateur et le serveur web.
HTTPS est communément employé pour effectuer des transactions financières en ligne, telles que le com-
merce électronique, la banque en ligne, le courtage en ligne, etc. De plus, il est également utilisé pour
accéder à des données privées, comme les courriers électroniques [22].
b. Protocole SSH
Secure Shell (SSH) est un protocole qui assure des connexions sécurisées entre deux systèmes via une
architecture client/serveur, permettant aux utilisateurs de se connecter à distance à des serveurs hôtes.
Contrairement à d’autres protocoles de communication à distance tels que FTP ou Telnet, SSH chiffre
la session de connexion, offrant ainsi une protection contre la collecte des mots de passe non chiffrés par
d’éventuels attaquants.
SSH a été développé dans le but de remplacer les anciennes applications de terminal, telles que Telnet,
qui étaient moins sécurisées. Contrairement à ces anciennes applications, SSH chiffre les mots de passe
échangés entre le client et le serveur lors d’une connexion à distance. Par conséquent, il est fortement
recommandé d’éviter autant que possible l’utilisation de ces anciennes méthodes. Opter pour des méthodes
de connexion sécurisées, telles que SSH, réduit considérablement les risques tant pour le client que pour
l’hôte distant.
c. Protocole IPsec
IP Security (IPsec) est un protocole conçu pour sécuriser les échanges de données au niveau de la couche
réseau. Il repose sur deux mécanismes distincts. Le premier, l’Authentification Header (AH), garantit l’in-
tégrité et l’authenticité des datagrammes IP, mais n’offre pas de confidentialité car les données transmises
ne sont pas chiffrées. Le second, l’Encapsulating Security Payload (ESP), permet également l’authentifi-
cation des données, mais son principal objectif est le chiffrement des informations. Ces deux mécanismes
sont souvent utilisés ensemble pour une protection plus complète.

d. Protocole TLS/SSL
Le protocole TLS (Transport Layer Security), également connu sous le nom de sécurité de couche de trans-
mission, succède au protocole SSL (Secure Sockets Layer), qui assure la sécurité des sockets. Lorsqu’un
client visite un site web sécurisé par HTTPS, le client et le serveur doivent suivre un processus appelé "né-
gociation TLS" avant de pouvoir établir une communication sécurisée. Ce processus aboutit à la création
d’une clé de session symétrique sécurisée, qui permet le chiffrement des transmissions de données entre
le serveur et le client. La clé de session est symétrique car elle est utilisée à la fois par le client et par le
serveur pour chiffrer et déchiffrer les transmissions. En d’autres termes, une clé de session est une série
d’instructions informatiques spécifiques qui masquent (ou, pour simplifier, chiffrent) les données originales
d’une transmission de données. Cela garantit que seules les personnes disposant de la même clé de session
peuvent déchiffrer et lire ces données.
3.5.2 VPN
Un réseau VPN utilise un protocole de tunneling pour assurer la transmission sécurisée des informations
de l’entreprise. Ce protocole permet de crypter les données lorsqu’elles circulent à travers le tunnel, offrant ainsi
aux utilisateurs la sensation de se connecter directement au réseau de leur entreprise. (Voir figure 3.7).
Le principe du tunneling repose sur la création d’un chemin virtuel entre l’émetteur et le destinataire.
Une fois ce chemin établi, les données sont chiffrées par la source et acheminées à travers ce chemin virtuel. Les
réseaux privés virtuels d’accès, quant à eux, simulent un réseau privé pour offrir un accès facile et économique aux
intranets ou aux extranets d’une entreprise. Bien qu’ils utilisent en réalité une infrastructure d’accès partagée
telle qu’Internet [23].
Figure 3.7 – VPN.

3.6 Types et caractéristiques des systèmes de détection d’intrusions

L’IDS fournit une visibilité approfondie sur les tentatives d’intrusions, qu’elles soient réussies ou échouées.
Lorsque l’on évoque les IDS, certains termes reviennent fréquemment [24] :
• Faux positif : une alerte générée par un système de détection d’intrusions (IDS) qui ne correspond pas à
une véritable attaque ou intrusion.
• Faux négatif : une intrusion réelle qui n’a pas été détectée par le système de détection d’intrusions (IDS)
et qui est donc passée inaperçue.
3.6.1 Types des systèmes de détection d’intrusions

En raison de la multitude d’attaques mises en œuvre par les pirates informatiques, il est essentiel d’avoir
une détection d’intrusions multi-niveaux. Ainsi, il existe plusieurs types d’IDS [31] :
a. NIDS
Les NIDS (Systèmes de Détection d’Intrusion Réseau) sont des outils spécialisés dans la surveillance des
réseaux. Ils se composent généralement d’une machine qui écoute le trafic sur le segment réseau à surveiller,
d’un capteur et d’un moteur d’analyse en temps réel. Le NIDS analyse l’ensemble du trafic réseau, détecte
les intrusions et génère des alertes lorsque des paquets suspects sont identifiés. La figure 3.8 illustre cette
architecture.
Figure 3.8 – Système de détection d’intrusion réseau.
L’implémentation d’un NIDS (Système de Détection d’Intrusion Réseau) dans un réseau suit une mé-
thodologie claire : des capteurs, souvent des hôtes simples, sont positionnés aux emplacements stratégiques
du réseau pour détecter les attaques. Lorsqu’une attaque est détectée, les capteurs génèrent des alertes
qui sont ensuite transmises à une console sécurisée. Cette console analyse les alertes et prend les mesures
nécessaires. Généralement, la console est située sur un réseau isolé qui relie exclusivement les capteurs et
la console.
Il est possible de positionner les capteurs dans deux emplacements distincts :
— A l’intérieur du pare-feu : Lorsque les capteurs sont positionnés à l’intérieur du pare-feu, il devient
plus simple de déterminer si ce dernier a été configuré de manière incorrecte. Cette disposition permet
également de détecter si une attaque a été lancée à travers ce pare-feu spécifique.
A l’extérieur du pare-feu : A l’extérieur du pare-feu : A l’extérieur du pare-feu :

— Les capteurs positionnés à l’extérieur du pare-feu ont pour rôle de détecter et d’analyser les attaques.
Ils présentent l’avantage d’enregistrer les informations dans les journaux (logs), ce qui permet à
l’administrateur de visualiser les éléments à modifier dans la configuration du pare-feu en fonction
des attaques détectées.
Voici un tableau comparatif des systèmes de détection d’intrusions (NIDS) mentionnés :
Table 3.1 – Tableau comparatif de systèmes de détection d’intrusions (NIDS) [25].
b. HIDS
Les systèmes de détection d’intrusions basés sur l’hôte se concentrent exclusivement sur l’analyse des
informations liées à cet hôte spécifique. Ils ne sont pas chargés de contrôler le trafic du réseau, mais se
concentrent plutôt sur les activités de l’hôte lui-même, ce qui les rend généralement plus précis pour dé-
tecter certains types d’attaques. De plus, ces systèmes ont un impact immédiat sur la machine ciblée, ce
qui signifie qu’ils peuvent réagir rapidement si un utilisateur réussit à l’attaquer. Pour fournir des infor-
mations sur l’activité, ces IDS utilisent deux types de sources : les logs et les traces d’audit du système
d’exploitation. Chacune de ces sources présente ses avantages : les traces d’audit offrent une précision
et une granularité supérieures, fournissant ainsi des informations plus détaillées, tandis que les logs, plus
succincts, se limitent à l’information essentielle et occupent moins d’espace. (Voir figure 3.9).

Figure 3.9 – Système de détection d’intrusion hôte.
Table 3.2 – Tableau comparatif des systèmes de détection d’intrusions (HIDS) [26].
Ces outils sont utilisés dans le domaine de la sécurité informatique pour renforcer la surveillance, la
détection et l’analyse des incidents de sécurité, contribuant ainsi à la protection des systèmes et des
données sensibles.

c. IDS hybride
C’est un système de détection d’intrusions qui combine les caractéristiques de plusieurs types de systèmes
de détection. En utilisant à la fois des NIDS (systèmes de détection d’intrusions réseau) et des HIDS
(systèmes de détection d’intrusions sur l’hôte), l’IDS hybride permet de surveiller à la fois le réseau et
l’hôte.
Dans un système d’IDS hybride, les sondes sont utilisées pour recueillir des informations à partir de
différentes parties du réseau. Ces sondes peuvent agir comme des NIDS ou des HIDS, en fonction de leur
emplacement et de leur fonction. Un exemple populaire d’IDS hybride dans le domaine Open-Source est
le système Prelude.
L’utilisation d’un IDS hybride offre l’avantage de pouvoir détecter les activités suspectes à la fois au niveau
du réseau et de l’hôte, ce qui permet une meilleure couverture de détection. Cela permet également une
meilleure corrélation des événements et une analyse plus approfondie des intrusions potentielles.
Dans le cadre de cette mise en place d’un système de détection d’intrusions (IDS), il est possible de stocker
les alertes provenant de divers systèmes dans une base de données centralisée. En utilisant des outils tels
que Snort en tant que système de détection d’intrusions réseau (NIDS) et Samhain en tant que système
de détection d’intrusions sur l’hôte (HIDS), il est possible de combiner ces solutions pour obtenir une
visualisation centralisée des attaques. Ainsi, cet IDS permet l’intégration d’outils puissants, assurant une
meilleure visibilité et un suivi efficace des activités suspectes au sein du réseau.
3.6.2 Caractéristiques des systèmes de détection d’intrusions

Parmi les caractéristiques souhaitables identifiées dans un système de détection d’intrusions, voici quelques
exemples :
— Résister aux tentatives de corruption en détectant toute modification indésirable subie par le système
lui-même.
— Utiliser un minimum de ressources système pour assurer une surveillance efficace.
— S’adapter aux évolutions du système surveillé et aux changements de comportement des utilisateurs au fil
du temps.
— Offrir une configuration facile afin de mettre en place une politique de sécurité spécifique adaptée au
réseau.
3.7 Architecture et le Déploiement d’un Système de Détection d’In-

trusions (IDS)
3.7.1 Architecture d’un Système de Détection d’Intrusions (IDS)
Dans cette section, nous présenterons les trois composants essentiels qui composent généralement un sys-
tème de détection d’intrusions. La Figure 3.10 permettra d’illustrer de manière visuelle les interactions qui
existent entre ces différents composants.

Figure 3.10 – Architecture d’un IDS [34].
• Capteur : joue un rôle essentiel en observant l’activité du système à partir d’une source de données
et en fournissant à l’analyseur une séquence d’événements représentant l’évolution de l’état du système.
Bien que le capteur puisse simplement transmettre ces données brutes, il est généralement soumis à un
prétraitement. On peut distinguer trois types de capteurs couramment utilisés en fonction des sources
de données utilisées pour observer l’activité du système : les capteurs système, les capteurs réseau et les
capteurs applicatifs. Trois types de capteurs sont généralement distingués en fonction des sources de
données utilisées pour observer l’activité du système : les capteurs système, les capteurs réseau et les
capteurs applicatifs.
• Analyseur : L’objectif de l’analyseur est d’examiner le flux d’événements provenant du capteur afin
d’identifier la présence d’éléments spécifiques pouvant indiquer une activité malveillante.
• Manager : Le rôle du manager consiste à recueillir les alertes générées par le capteur, les organiser et les
présenter à l’opérateur. Le manager peut également être responsable de définir la réaction appropriée à
adopter, en fonction de la nature et de la gravité des alertes.
— Confinement de l’attaque : Cette étape vise à limiter les dommages causés par l’attaque en isolant
les éléments compromis du reste du système.
— Éradication de l’attaque : L’objectif de cette étape est d’arrêter complètement l’attaque en éliminant
toutes les sources de compromission et en éradiquant les logiciels malveillants.
— Recouvrement : Cette étape consiste à restaurer le système dans un état sain en rétablissant les
fonctionnalités affectées et en remettant en place les mesures de sécurité appropriées.
— Diagnostic : Cette phase a pour but d’identifier la nature de l’attaque, les vulnérabilités exploitées
et les mesures correctives à prendre pour prévenir de futures attaques similaires.

3.7.2 Déploiement d’un Système de Détection d’Intrusions (IDS)
a. Positionnement de l’IDS
C’est crucial pour assurer une surveillance efficace du réseau. Il est essentiel de déterminer les emplacements
stratégiques où un IDS peut être déployé. Dans le schéma ci-dessous, nous présentons un réseau local avec
trois positions possibles pour l’IDS, qui permettent de couvrir différents segments du réseau et d’identifier
les activités suspectes ou malveillantes.
Figure 3.11 – Position des IDS.
— Position ( 1 ) : Dans cette configuration, l’IDS est positionné en amont du pare-feu, ce qui lui
permet de détecter toutes les attaques frontales provenant de l’extérieur. Cependant, cette position
peut générer un grand nombre d’alertes, rendant les logs difficiles à consulter.
— Position ( 2 ) : Si l’IDS est positionné sur la DMZ, il sera en mesure de détecter les attaques
qui ont contourné le pare-feu et qui nécessitent un certain niveau de compétence. Cela permettra
une meilleure lisibilité des journaux de surveillance, car les attaques seront distinguées des activités
normales qui sont déjà filtrées.
— Position ( 3 ) : l’IDS permet de détecter les attaques internes provenant du réseau local de l’en-
treprise, étant donné que la majorité des attaques (80/100) proviennent de l’intérieur. C’est un
emplacement stratégique pour identifier facilement les trojans qui pourraient infecter les systèmes
informatiques de l’entreprise en raison d’une navigation peu méfiante sur Internet. Une fois identifiés,
ces trojans peuvent être rapidement éliminés.

3.8 Fonctionnement, méthodes de détection, détection d’un IDS et

critères de test d’un IDS
3.8.1 Mode de Fonctionnement d’un Système de Détection d’Intrusions (IDS)

Nous pouvons identifier deux modes de détection distincts :
• La détection d’anomalies :
Il s’agit de repérer des comportements inhabituels ou des schémas anormaux dans le trafic réseau, ce qui
peut indiquer une tentative d’intrusion ou une activité malveillante.
• La reconnaissance de signature :
Cela consiste à identifier des signatures spécifiques correspondant à des attaques connues ou à des acti-
vités malveillantes préalablement répertoriées. Ces signatures sont comparées aux modèles existants pour
détecter et signaler les menaces potentielles.
Il est important de souligner que la méthode de reconnaissance de signatures est la plus largement utilisée par
les IDS disponibles sur le marché. Cependant, les nouveaux produits tendent à adopter une approche combinée
des deux méthodes afin d’améliorer la précision de la détection des intrusions.
a. Détection d’anomalies
Implique la détection de comportements inhabituels par rapport à un profil de trafic considéré comme
normal. Cette méthode nécessite une phase d’apprentissage au cours de laquelle les systèmes de détection
d’intrusions (IDS) apprennent le fonctionnement régulier des éléments surveillés. En conséquence, lorsqu’ils
identifient des divergences par rapport à ce comportement de référence, ils peuvent les signaler. Les
modèles comportementaux sont construits grâce à des analyses statistiques, ce qui leur permet de détecter
efficacement de nouveaux types d’attaques. Néanmoins, ces modèles nécessitent des ajustements réguliers
pour évoluer en fonction de l’activité normale des utilisateurs, afin de réduire les fausses alertes générées.
Dans le cas d’un système de détection d’intrusions basé sur l’hôte (HIDS), la détection peut s’appuyer sur
des informations telles que l’utilisation du processeur (CPU), l’activité du disque, les heures de connexion
ou l’utilisation de certains fichiers (par exemple, pendant les heures de bureau) [27].
b. Reconnaissance de signatures
Dans un système de détection d’intrusions (IDS) implique la recherche d’empreintes ou de signatures

d’attaques connues dans l’activité surveillée. Ce type d’IDS est réactif et ne peut détecter que les attaques
pour lesquelles il dispose de la signature correspondante. Par conséquent, il est essentiel de maintenir
régulièrement à jour le système de détection d’intrusions. De plus, l’efficacité de ce système repose en
grande partie sur la précision de sa base de signatures. Cependant, les pirates sont capables de contourner
ces systèmes en utilisant des techniques d’évasion qui altèrent les attaques utilisées. Ces techniques visent
à modifier les signatures des attaques, les rendant ainsi méconnaissables pour l’IDS. Il est possible de
créer des signatures plus générales pour détecter les variations d’une même attaque, mais cela nécessite
une connaissance approfondie des attaques et du réseau afin de stopper ces variations sans perturber le
trafic légitime du réseau. Une signature permet de spécifier les caractéristiques d’une attaque, que ce soit
au niveau des paquets (jusqu’au niveau TCP ou UDP) ou au niveau des protocoles (HTTP, FTP, etc.).
• L’IDS analyse les paramètres des paquets qui transitent à travers le réseau et les compare aux
signatures d’attaques connues.

• Au niveau du protocole, si les commandes envoyées sont valides et ne contiennent pas d’attaques.
Cette fonctionnalité est particulièrement développée pour le protocole HTTP à l’heure actuelle.
Il est important de noter que les signatures sont régulièrement mises à jour pour prendre en compte
les nouvelles attaques identifiées. Cependant, il est important de noter que l’augmentation du nombre
de signatures à tester rallonge le temps de traitement. Paradoxalement, l’utilisation de signatures plus
complexes peut en réalité accélérer considérablement le processus. Cependant, il est important de noter
que la création de signatures mal conçues peut conduire à l’ignorance d’attaques réelles ou à l’identification
erronée du trafic normal comme étant une attaque. Par conséquent, il est essentiel de manipuler avec
précaution l’élaboration de signatures et de posséder une connaissance approfondie du réseau surveillé et
des attaques existantes.
Une fois qu’une attaque est détectée, un système de détection d’intrusions (IDS) a plusieurs options de
réponse à sa disposition, que nous allons maintenant expliquer en détail.
c. Réponses actives et passives
Il y a deux types de réponses possibles selon les IDS utilisés. La réponse passive est disponible pour tous
les IDS, tandis que la réponse active peut être plus ou moins implémentée.
• Réponse passive : Lorsqu’un IDS détecte une intrusion, il enregistre les informations relatives à
cette intrusion dans un fichier de log. Ce fichier est ensuite analysé par le responsable de sécurité,
qui peut prendre les mesures appropriées pour remédier aux failles de sécurité identifiées. Bien que
cette réponse passive aide à prévenir les attaques futures en empêchant la répétition des attaques
enregistrées, elle ne constitue pas une mesure directe pour empêcher une attaque de se produire.
• Réponse active : a pour objectif d’interrompre une attaque dès sa détection. Pour cela, une possibilité
est de procéder à une reconfiguration du firewall. La reconfiguration du firewall permet de bloquer
le trafic malveillant en fermant le port utilisé ou en interdisant l’adresse de l’attaquant. Il est impor-
tant de noter que cette fonctionnalité dépend du modèle de firewall utilisé, car tous les modèles ne
permettent pas une reconfiguration via un IDS. Dans le cas d’une réponse active, il est essentiel de
s’assurer que le trafic détecté comme malveillant est réellement nuisible, afin d’éviter de déconnecter
des utilisateurs légitimes par erreur. En règle générale, les systèmes de détection d’intrusions (IDS) ne
réagissent pas de manière proactive à toutes les alertes. Ils n’interviennent que lorsque ces alertes sont
confirmées comme étant des attaques avérées. Par conséquent, il est essentiel d’analyser les fichiers
d’alerte générés afin de traiter l’ensemble des attaques détectées de manière appropriée [28].
3.8.2 Méthodes de détections d’un Système de Détection d’Intrusions (IDS)

Afin de gérer efficacement un système de détection d’intrusions, il est essentiel de comprendre son fonction-
nement. Une question fondamentale se pose quant à la détection d’un tel système et à la manière de différencier
un flux contenant une attaque d’un flux normal.
Pour répondre à ces interrogations, nous avons étudié en profondeur le fonctionnement interne d’un IDS. À
partir de là, nous avons identifié deux techniques utilisées dans la détection des attaques. La première consiste
à détecter les signatures d’attaques connues dans les paquets circulant sur le réseau. La seconde technique
vise à repérer une activité suspecte dans le comportement de l’utilisateur. Bien que ces deux approches soient
distinctes, elles peuvent être combinées au sein d’un même système pour renforcer la sécurité [29].

a. Approche par scénario (mésuse détection)
Repose sur la compréhension des techniques employées par les attaquants afin de déduire des scénarios
types. Cette méthode ne prend pas en compte les actions antérieures de l’utilisateur et se base sur des
signatures d’attaques, qui sont un ensemble de caractéristiques permettant d’identifier une activité in-
trusive. Ces caractéristiques peuvent inclure une chaîne alphanumérique spécifique, une taille de paquet
anormale ou une trame formatée de manière suspecte [30].
Différentes méthodes d’analyse peuvent être utilisées pour la détection par scénario :
• Recherche de motifs (pattern matching) : est une méthode largement utilisée et facile à comprendre.
Elle consiste à rechercher des motifs, tels que des chaînes de caractères ou des séquences d’octets, au
sein du flux de données. L’IDS utilise une base de signatures qui contient des informations sur les
protocoles et les ports utilisés par l’attaque, ainsi qu’un motif spécifique permettant de reconnaître
les paquets suspects. Un inconvénient majeur de cette méthode est sa limitation à la détection
des attaques reconnues uniquement par les signatures. Par conséquent, il est essentiel de maintenir
régulièrement à jour la base de signatures pour rester efficace. De plus, cette méthode présente un
autre inconvénient : les motifs des attaques étant généralement fixes, toute variation même minime
par rapport à la signature peut entraîner une non-détection de l’attaque. Pour les IDS utilisant
cette approche, il est nécessaire d’adapter la base de signatures en fonction du système à protéger,
permettant ainsi une réduction des ressources nécessaires, une amélioration des performances et une
diminution significative des fausses alertes, facilitant ainsi le travail des administrateurs réseau lors
de l’analyse des alertes.
• La recherche de motifs dynamiques : implique l’utilisation d’une méthode similaire à celle précédem-
ment décrite, mais avec des signatures d’attaques qui évoluent de manière dynamique. Ainsi, l’IDS
est capable de s’adapter et d’apprendre de nouvelles menaces en continu.
• Analyse de protocoles :repose sur la vérification de la conformité des flux ainsi que sur l’observation
des champs et paramètres suspects dans les paquets. Cette méthode implique l’utilisation d’un en-
semble de préprocesseurs dédiés à l’analyse de protocoles spécifiques tels que FTP, HTTP, ICMP, etc.
Cependant, la présence de ces nombreux préprocesseurs peut entraîner une dégradation significative
des performances du système. L’avantage majeur de l’analyse protocolaire est sa capacité à détecter
des attaques inconnues, contrairement à la correspondance de motifs qui nécessite une connaissance
préalable de l’attaque pour pouvoir la détecter.
• L’analyse heuristique et la détection d’anomalies : consistent en une méthode intelligente visant à
détecter les activités suspectes ou les comportements anormaux. Par exemple, en utilisant l’analyse
heuristique, il est possible de déclencher une alarme lorsque le nombre de sessions vers un port
spécifique dépasse un seuil défini dans un intervalle de temps prédéterminé.
b. Approche comportementale (Anomalie Detection)
Repose sur l’analyse du comportement historique de l’utilisateur afin de détecter les activités anormales.
Pour cela, il est nécessaire de créer un profil utilisateur en se basant sur ses habitudes, puis de générer une
alerte lorsque des événements en dehors de ce profil surviennent. Cette approche peut être appliquée non
seulement aux utilisateurs, mais aussi aux applications et aux services. Différentes métriques peuvent être
utilisées, telles que la charge CPU, le volume de données échangées, le temps de connexion aux ressources,
la répartition statistique des protocoles et applications utilisés, ainsi que les heures de connexion [31].
Néanmoins, elle présente quelques désavantages :

• Le système de détection d’intrusions peut être peu fiable car il génère des alertes chaque fois qu’il y a
un changement dans les habitudes de l’utilisateur, ce qui peut entraîner un grand nombre de fausses
alertes.
• La mise en place des mécanismes d’auto-apprentissage nécessite une période de non-fonctionnement.
Pendant cette période, si un pirate lance une attaque, ses actions peuvent être assimilées à un profil
utilisateur, ce qui permettrait à l’attaque de passer inaperçue une fois que le système de détection
sera pleinement opérationnel.
• L’établissement du profil utilisateur doit être flexible pour éviter un trop grand nombre de fausses
alertes. Un pirate pourrait discrètement intervenir pour modifier le profil de l’utilisateur au fil du
temps, afin de préparer une attaque qui ne serait pas détectée par le système de détection.
Il existe différentes approches qui peuvent être utilisées pour la détection comportementale :
• Approche probabiliste, des probabilités sont utilisées pour représenter les comportements typiques
d’une application ou d’un protocole. Si une activité ne correspond pas au modèle probabiliste établi,
une alerte sera générée.
• Approche statistique pour la détection d’intrusions : L’objectif est de mesurer de manière quantitative
les paramètres associés à l’utilisateur, tels que le taux d’occupation de la mémoire, l’utilisation des
processeurs, la charge réseau, le nombre d’accès à l’Intranet par jour, la vitesse de frappe au clavier,
les sites les plus visités, etc. Cependant, cette méthode est complexe à mettre en œuvre et est
principalement utilisée dans la recherche, où les chercheurs exploitent des réseaux neuronaux afin
d’obtenir des résultats concluants.
3.8.3 Détecteur d’un Système de Détection d’Intrusions (IDS)

Il est crucial de noter qu’il est extrêmement risqué si un pirate découvre la présence d’un IDS. Dans ce
cas, il fera tout son possible pour recueillir des informations sur l’IDS en place, comme sa version, afin de le
contourner et de mener des attaques sans éveiller les soupçons [31]. Voici quelques techniques utilisées pour la
détection des systèmes de détection d’intrusions (IDS) :
• Usurpation d’adresse MAC : peut être détectée en exploitant le mode promiscuité des NIDS, où l’interface
de capture est configurée pour capturer tout le trafic réseau. Pour repérer un NIDS, il est possible d’envoyer
un ICMP "echo request" à la machine suspectée d’être un NIDS avec une adresse MAC inexistante. Si la
machine répond, cela indique qu’elle est en mode promiscuité et peut donc être un NIDS.
• Mesure des temps de latence : En raison de l’utilisation du mode promiscuous de l’interface, les temps
de réponse sont rallongés lors de la mesure des temps de latence. Voici une approche pour tirer parti de
ces délais de latence : Le processus suivi par le pirate est le suivant : tout d’abord, il envoie une série de
pings à l’adresse qu’il souhaite tester, puis il mesure et enregistre les temps de réponse. Ensuite, le pirate
effectue une saturation du réseau en envoyant des paquets en broadcast, dans le but de ralentir l’IDS qui
va recevoir tous ces paquets. Enfin, le pirate renvoie la même série de pings et mesure les nouveaux temps
de réponse. Si ces temps de réponse sont considérablement plus élevés que les premiers, il est très probable
que la machine soit en mode promiscuous.
• Utilisation des mécanismes de réponses actives, tels que les IPS, permet de réagir à des attaques spécifiques
en prenant des mesures telles que la fermeture de session ou le blocage de port. Cependant, il est important
de noter que ces actions laissent généralement des traces, telles que des empreintes dans les en-têtes des
paquets, qui peuvent être utilisées pour identifier le type d’IPS utilisé.

• L’observation des requêtes DNS, permet de détecter la présence d’un IDS lors d’alertes générées. En
analysant le comportement du DNS primaire lors de fausses attaques, il est possible de repérer la présence
d’un système de détection d’intrusions.
3.8.4 Critères de tests d’un Système de Détection d’Intrusions (IDS)
Lorsque vous déployez un IDS, il est important de prendre en compte plusieurs critères pour choisir le
meilleur IDS. Tester un IDS à l’aide de scanners de vulnérabilités est une étape nécessaire pour évaluer son
efficacité, mais cela ne suffit pas à garantir sa performance optimale. Il est important de prendre en considération
d’autres critères :
• Méthodes et capacités de détection : Évaluer le taux de faux positifs et la qualité des informations fournies
par l’IDS. Il est essentiel de s’assurer que l’IDS peut détecter de manière fiable les intrusions tout en
minimisant les alertes erronées.
• Rapidité : Tester l’IDS dans des conditions de charge élevée pour évaluer sa capacité à traiter efficacement
un grand volume de trafic réseau. Il est crucial de réaliser ces tests dans des environnements réalistes
plutôt que de simplement utiliser des générateurs de paquets.
• Ouverture : Vérifier si l’IDS permet de modifier les signatures pour éviter certains faux positifs et s’il
offre la possibilité d’ajouter de nouvelles signatures spécifiques à l’environnement de l’entreprise. Cette
flexibilité est importante pour adapter l’IDS aux besoins spécifiques de l’entreprise.
• Architecture logicielle : Pour les grandes entreprises, il peut être intéressant de pouvoir séparer les fonctions
d’administration de l’IDS. Une architecture logicielle modulaire permet de déléguer les responsabilités
d’administration à différents utilisateurs tout en maintenant un contrôle centralisé sur la sécurité.
• Exploitabilité des données : Disposer d’outils permettant de retrouver et d’analyser facilement les évé-
nements suspects générés par l’IDS est essentiel. Étant donné le volume important de données générées,
il peut être avantageux de disposer de consoles de reporting ou de tableaux de bord pour centraliser et
visualiser les informations pertinentes.
• Ergonomie : L’interface de l’IDS doit être adaptée à différents types d’utilisateurs. Cela peut inclure des
interfaces graphiques conviviales pour les utilisateurs non spécialisés, des interfaces Web ou même des
interfaces en ligne de commandes pour les experts. Dans tous les cas, l’interface doit offrir de nombreuses
fonctionnalités pour faciliter la gestion et l’exploitation de l’IDS.
Lors de l’évaluation d’un IDS (système de détection d’intrusions), d’autres critères doivent être pris en
compte, tels que la réactivité de l’éditeur en termes de mises à jour des signatures et de correctifs, ainsi
que le prix de la solution (qu’elle soit libre ou non). Il est utile de donner un poids différent à chacun de
ces critères en fonction de leur importance respective.

3.9 Techniques de contournement des IDS, Limitations des IDS et

Systèmes de prévention d’intrusion (IPS)
3.9.1 Techniques de contournement des IDS

Comme pour la plupart des systèmes informatiques, les IDS ne sont pas à l’abri de vulnérabilités ou de tech-
niques permettant de contourner leur détection. Si un pirate détecte la présence d’un IDS, il peut le désactiver
ou, encore plus problématique, générer de fausses attaques pour passer inaperçu pendant qu’il commet ses mé-
faits en toute tranquillité [32]. Trois catégories d’attaques peuvent cibler les systèmes de détection d’intrusions
(IDS) :
• Attaque par déni de service : Cette attaque vise à rendre l’IDS inopérant en le submergeant de trafic, ce
qui peut entraîner une incapacité à détecter les activités malveillantes réelles.
• Attaque par insertion : Dans cette attaque, le pirate injecte des paquets de leurres qui sont ignorés par le
système d’exploitation de la cible, mais pris en compte par l’IDS. En conséquence, l’IDS ne détecte aucune
anomalie, alors que l’attaque est effectivement en cours sur le système cible, car les paquets superflus sont
ignorés.
• Attaque par évasion : Contrairement à l’attaque par insertion, cette technique consiste à envoyer des
données superflues qui sont ignorées par l’IDS, mais prises en compte par le système d’exploitation de la
cible. Ainsi, l’attaque peut contourner la détection de l’IDS et compromettre le système cible.
3.9.2 Limitations des IDS

Les systèmes de détection d’intrusions (IDS), tout comme tout système informatique, présentent certaines
limites. Voici quelques exemples de ces limites [32] :
• Pollution/surcharge : Les systèmes de détection d’intrusions (IDS) peuvent être affectés par des problèmes
de pollution ou de surcharge. Cela peut se produire lorsque des attaquants génèrent un trafic excessif et
complexe dans le but de rendre les alertes de l’IDS difficiles à analyser. Cette surcharge peut entraîner
des conséquences telles que la saturation des ressources du système (disque, CPU, mémoire), la perte de
paquets ou même un déni de service partiel ou total.
• Consommation de ressources : En plus de générer des fichiers de logs de grande taille (de l’ordre du
Go), la détection d’intrusion nécessite une utilisation intensive des ressources. Les systèmes IDS doivent
enregistrer et analyser en permanence les activités anormales ou suspectes du réseau, ce qui demande une
grande capacité de traitement et de stockage des données. Cette consommation élevée de ressources peut
avoir un impact sur les performances globales du système et nécessite une infrastructure adéquate pour
assurer un fonctionnement efficace.
• Perte de paquets (impact sur les performances) : En raison de la vitesse élevée de transmission des données,
il peut arriver que les disques durs ou les processeurs ne puissent pas traiter tous les paquets reçus par
l’IDS. Par conséquent, certains paquets ne sont pas analysés, ce qui peut créer des vulnérabilités dans la
détection d’intrusions et permettre à certains paquets d’atteindre la machine destinataire sans être filtrés.
• Vulnérabilité aux attaques de déni de service : Les attaquants peuvent cibler le système de détection
d’intrusions lui-même, voire le système d’exploitation de la machine qui héberge l’IDS, dans le but de
provoquer un déni de service. Lorsque l’IDS est désactivé ou hors service, l’attaquant peut exploiter cette
situation pour mener des attaques sans être détecté. Lorsque l’IDS est désactivé ou mis "hors service",
cela laisse l’attaquant libre de tenter toutes les actions qu’il souhaite, sans être détecté ni bloqué par le
système de détection d’intrusions.

3.9.3 Efficacité des systèmes de détection d’intrusions

Les mesures suivantes déterminent l’efficacité d’un système de détection d’intrusions [33] :
— Exactitude, le système de détection d’intrusions est considéré comme non exact lorsqu’il classe les actions
légitimes des utilisateurs comme atypiques ou intrusives, engendrant ainsi de faux positifs.
— Performances, Réaliser une détection en temps réel.
— Tolérance aux pannes est essentielle pour un système de détection d’intrusions afin de garantir sa résistance
face aux attaques.
— Rapidité est essentielle dans un système de détection d’intrusions, car il doit être capable d’effectuer
rapidement son analyse et de propager les résultats. Cela permet une réaction rapide en cas de détection
d’une attaque, permettant à l’agent de sécurité de prendre des mesures appropriées.
— Complétude se réfère à la capacité d’un système de détection d’intrusion à détecter toutes les attaques.
3.9.4 Systèmes de prévention d’intrusion (IPS)

Les systèmes de prévention d’intrusions (IPS) sont conçus pour empêcher toute activité suspecte détectée
au sein d’un système, en prévenant une attaque avant qu’elle n’atteigne sa destination. Contrairement aux
systèmes de détection d’intrusions (IDS), les IPS sont des outils "actifs" qui, en plus de détecter une intrusion,
tentent de la bloquer. Les IPS fonctionnent de manière similaire aux IDS, mais ils analysent également les
contextes de connexion, automatisent l’analyse des journaux et coupent les connexions suspectes. Contrairement
aux IDS traditionnels, ils n’utilisent pas de signatures pour détecter les attaques. Avant d’agir, une décision en
temps réel est prise en comparant l’activité aux règles existantes|8|. Si l’action est conforme aux règles, elle est
autorisée et exécutée. En revanche, si l’action est illégale, une alarme est générée. Dans la plupart des cas, les
autres détecteurs du réseau (ou une console centrale connectée à l’IPS) sont également informés pour empêcher
les autres ordinateurs d’ouvrir ou d’exécuter des fichiers spécifiques.
Figure 3.12 – Emplacement d’un IPS.
a. Les différents types d’IPS
Les systèmes de prévention d’intrusions (IPS) peuvent être classés en trois catégories : les IPS orientés
hôtes (Host IPS), les IPS orientés réseaux (Network IPS) et les IPS orientés noyau (Kernel IPS). Cepen-
dant, il n’existe pas d’IPS spécifiquement conçu pour surveiller une application en particulier.
• Le système de prévention d’intrusion réseau (NIPS) :

réagit en modifiant l’environnement du système attaqué lorsqu’une attaque est détectée. Cela peut
se traduire par le blocage de certains flux ou ports, voire l’isolation complète de systèmes spécifiques
du réseau. Cependant, il est crucial de minimiser les faux positifs, car toute erreur peut directement

affecter le trafic du système. Les erreurs doivent être évitées autant que possible, car elles peuvent
avoir un impact direct sur la disponibilité des systèmes.
• Le système de prévention d’intrusion hôte (HIPS) :
Joue un rôle crucial dans la sécurité en prévenant les attaques avant qu’elles ne se produisent.
Contrairement au système de détection d’intrusion hôte (HIDS) qui agit après l’événement, le HIPS
est résident et actif en permanence dès le démarrage du système jusqu’à son arrêt. Il protège l’intégrité
du système d’exploitation, des logiciels applicatifs en cours d’exécution et des données stockées en
mémoire RAM ou dans le système de fichiers. Il vérifie constamment que le contenu reste intègre et
surveille en temps réel toute modification sur l’ordinateur, s’assurant ainsi qu’aucune tentative ne
contrecarre la politique de sécurité établie.
• Les systèmes de prévention d’intrusions orientés noyau (KIPS) :
Se distinguent par leur capacité à s’exécuter directement dans le noyau d’une machine, ce qui leur
permet de bloquer toute activité suspecte. Un KIPS peut détecter des motifs caractéristiques de
débordement de mémoire et empêcher l’exécution de code malveillant. Il peut également interdire
au système d’exploitation d’exécuter des appels système qui ouvriraient un terminal de commande.
Cependant, étant donné que le KIPS analyse les appels système, cela peut entraîner un ralentissement
de l’exécution, ce qui explique pourquoi ils sont moins couramment utilisés.
b. Architecture fonctionnelle d’IPS
Le fonctionnement d’un IPS est similaire à celui d’un IDS. Il consiste à capturer et analyser le trafic
réseau. Cependant, contrairement à un IDS qui alerte simplement l’utilisateur d’une intrusion ou d’une
attaque, un IPS réagit automatiquement sans intervention de l’utilisateur en bloquant directement les
intrusions en supprimant les paquets illégitimes. En outre, pour informer l’utilisateur, un IPS peut éga-
lement générer un fichier de journalisation qui répertorie les paquets supprimés et éventuellement fournir
un message expliquant la raison de cette suppression [34].
Figure 3.13 – Architecture fonctionnelle d’un IPS [43].

L’IPS détecte et génère des alertes en fonction de plusieurs facteurs, qui sont classés dans l’une des
catégories suivantes :
— Un vrai positif se produit lorsqu’une signature détecte avec précision un trafic intrusif sur le réseau,
ce qui indique un fonctionnement normal et optimal de la détection des intrusions.
— Un faux positif se produit lorsque l’activité normale déclenche une alerte ou une réponse erronée, ce
qui correspond à une erreur.
— Un vrai négatif se produit lorsqu’une signature ne génère pas d’alerte pendant l’utilisation normale du
trafic réseau, ce qui indique qu’aucune activité malveillante n’est présente. Cela reflète une opération
normale et optimale.
— Un faux négatif se produit lorsque le système de détection ne parvient pas à détecter un trafic
intrusif malgré la présence d’une activité malveillante, et que le système de sécurité ne réagit pas en
conséquence. Dans ce cas, il s’agit d’une erreur, car le système n’a pas réussi à identifier une menace
réelle, ce qui compromet la sécurité de l’environnement.
c. Points forts
— Les logiciels IPS sont généralement compatibles avec plusieurs plateformes, notamment Linux, FreeBSD,
Windows, etc.
— Similaire au pare-feu qui bloque le trafic en fonction des adresses IP, Snort empêche la transmission
des paquets en se référant à ses règles.
— La liberté de création des règles permet de définir les actions à exécuter selon les besoins et les
préférences spécifiques.
— Réduire le coût de l’installation de plusieurs instances.
— Cette approche implique l’interaction de différentes technologies hétérogènes telles que les pare-feu,
les VPN, les IDS, les antivirus, les anti-spam, et autres.
— Grâce à sa vaste base de données, Snort est capable de détecter des attaques visant divers types de
logiciels d’exploitation et d’applications. Sa couverture étendue lui permet de repérer et d’analyser
les attaques sur une large gamme de systèmes et de logiciels.
— Le déploiement d’un dispositif simple capable d’analyser le trafic à grande échelle des centres serveurs
sur le réseau présente plusieurs avantages. Cela fait du NIPS (Network Intrusion Prevention System)
une solution efficace qui réduit les coûts de maintenance et de déploiement.
— L’utilisation d’un dispositif simple pour analyser le trafic et assurer la sécurité d’un réseau étendu
rend l’IPS (Système de prévention d’intrusions) ou le NIPS (Système de prévention d’intrusions
réseau) une solution avantageuse en termes de coût de déploiement et de maintenance réduits[34].
d. Points faibles
— Les systèmes de prévention d’intrusions (IPS) ont la capacité de couper les connexions suspectes
et même de reconfigurer le pare-feu pour refuser tout trafic provenant du site incriminé lors d’une
attaque externe. Cependant, il est important de noter que cette fonctionnalité automatique présente
un potentiel de danger, car elle peut entraîner des dénis de service provoqués par l’IDS. Un attaquant
déterminé peut par exemple tromper l’IDS en usurpant des adresses IP du réseau local, ce qui amène-
rait l’IDS à considérer ces adresses comme la source de l’attaque. Par conséquent, il est recommandé
d’offrir une réaction facultative, soumise à la décision finale d’un opérateur humain, pour éviter de
telles situations.

— La consommation des ressources telles que la mémoire et le CPU.

— La paralysie du réseau due à de faux positifs se produit lorsque des systèmes de détection d’intrusion
signalent à tort des activités normales comme étant des menaces potentielles, entraînant ainsi une
surcharge et une perturbation du réseau.
e. Différence entre IDS et IPS

Les IDS (systèmes de détection d’intrusions) et les IPS (systèmes de prévention d’intrusions) analysent
tous deux les paquets réseau et les comparent à une base de menaces connues. La distinction principale
entre les deux réside dans les actions entreprises par la suite.
Figure 3.14 – Différence entre IDS et IPS.
Figure 3.15 – Figure comparatif entre IDS et IPS [45].

Conclusion
La plupart des systèmes de détection d’intrusions (IDS) sont considérés comme fiables, ce qui explique
leur intégration fréquente dans les solutions de sécurité. Leurs avantages par rapport à d’autres outils de sécurité
sont indéniables, cependant, même les meilleurs IDS peuvent présenter des lacunes et des inconvénients. Il est
donc clair qu’ils sont indispensables, mais ils ne peuvent pas se substituer à l’utilisation d’autres outils de sécu-
rité visant à combler leurs défauts. Cependant, comme tout outil technologique, les IDS présentent des limites
et des vulnérabilités qui nécessitent une analyse humaine pour les compenser, tandis que les IPS peuvent être
confrontés à des limitations et à des faiblesses qui ne permettent pas de contrer toutes les attaques inconnues et
peuvent potentiellement affecter l’intégrité d’un système. Dans le chapitre suivant, nous examinerons de près un
système open source de détection d’intrusions réseau, le Snort, qui est l’un des plus populaires dans le domaine
de la détection d’intrusions.

Chapitre 4
IMPLÉMENTATION ET INTÉGRATION DU SYSTÈME DE
DÉTECTION D’INTRUSION POUR LA SÉCURISATION
L’ARCHITECTURE RÉSEAU DE LA SODECOTON
Introduction
Dans de nombreux cas, les réseaux informatiques sont sécurisés par des pare-feux (firewalls). Tout d’abord,
nous examinerons les différentes architectures réseau de l’entreprise et nous choisirons celle qui nécessite une
sécurisation particulière. Bien que cette protection soit nécessaire, elle ne permet pas de détecter les attaques
provenant de l’extérieur. En effet, un pare-feu est conçu pour bloquer les flux de données non autorisés tout en
laissant passer le "trafic légitime".
Cependant, la question qui se pose est de savoir comment analyser les données potentiellement dangereuses
à l’intérieur de ce trafic et se prémunir contre les attaques. Dans le cadre de notre projet, nous avons choisi
d’utiliser Snort, une solution de détection d’intrusions. Snort est un outil puissant qui permet d’analyser en
temps réel le trafic réseau et de rechercher des correspondances dans sa base de données de profils d’attaques
connues.
Il enregistre également les résultats de cette analyse dans des journaux (logs). Ainsi, Snort nous offre une ap-
proche proactive pour détecter et signaler les tentatives d’intrusion dans le réseau, améliorant ainsi la sécurité
de l’architecture de la Sodecoton. Enfin, nous procéderons à des tests en lançant différentes attaques à partir
de diverses sources dans le réseau, afin d’évaluer l’efficacité du système en termes de détection de ces attaques.
Bien que ces pare-feux soient essentiels pour bloquer les flux de données non autorisés et laisser passer le trafic
légitime, ils ne sont pas suffisants pour détecter les attaques provenant de l’extérieur du réseau. La question
cruciale est de savoir comment analyser les données potentiellement dangereuses à l’intérieur de ce trafic légitime
et comment se protéger efficacement contre les attaques ?
4.1 Evaluation de la solution avant et après déploiement

Dans cette partie, nous aborderons l’évaluation de la solution de détection d’intrusion avant et après son
déploiement au sein de l’architecture réseau de la Sodecoton. L’évaluation joue un rôle essentiel dans la valida-
tion de l’efficacité et de la pertinence de Snort en tant qu’outil de détection d’intrusion. Avant le déploiement,
nous analyserons la situation initiale du réseau, en évaluant les vulnérabilités potentielles et en identifiant les
risques liés à la sécurité. Cette étape nous permettra de définir les objectifs spécifiques que nous cherchons à
atteindre avec la mise en place de Snort. Après le déploiement, nous procéderons à des tests approfondis en
simulant différentes attaques pour évaluer la capacité de Snort à détecter ces intrusions et à fournir des alertes

pertinentes. Nous comparerons également les résultats obtenus avec les objectifs définis au préalable, afin de
déterminer l’efficacité réelle de la solution. L’évaluation avant et après déploiement nous permettra de mesurer
l’impact de Snort sur la sécurité du réseau de la Sodecoton et de prendre les mesures nécessaires pour améliorer
encore davantage la protection du système informatique.
❖ Avant le déploiement
Avant le déploiement de Snort, une évaluation approfondie du réseau de la Sodecoton est essentielle pour
identifier les éventuelles vulnérabilités et risques liés à la sécurité. Le réseau de l’entreprise est structuré en
deux sous-réseaux distincts. Le premier sous-réseau est un réseau local virtuel (LAN) qui est subdivisé en
trois zones distinctes pour une meilleure gestion des domaines réseau. Le découpage en zones permet de
séparer les différentes parties du réseau en fonction de leurs niveaux de sensibilité et d’accès aux ressources.
Cette segmentation facilite également la gestion des droits d’accès et renforce la sécurité globale du réseau.
Le deuxième sous-réseau est le réseau externe WAN, qui assure la connectivité avec l’Internet. Cela permet
à la Sodecoton de communiquer avec le monde extérieur tout en assurant un certain niveau de contrôle
sur le trafic entrant et sortant. Cependant, cette ouverture vers Internet expose également le réseau à un
plus grand nombre de menaces potentielles, rendant la détection d’intrusion d’autant plus cruciale pour
prévenir et contrer les attaques.
Avant le déploiement de Snort, il est donc primordial d’effectuer une analyse approfondie de ces sous-
réseaux pour déterminer les points faibles et les éventuelles failles de sécurité. Cela implique d’identifier
les flux de données, les services actifs, les applications en cours d’exécution, ainsi que les droits d’accès
accordés aux utilisateurs. Une telle évaluation permettra de mieux comprendre les risques potentiels et de
définir des objectifs spécifiques pour le déploiement de Snort en termes de détection d’intrusion. L’analyse
approfondie du réseau de la Sodecoton avant le déploiement de Snort a mis en évidence certains points
faibles et éventuelles failles de sécurité qui nécessitent une attention particulière :
— Manque de détection proactive : Le réseau actuel de la Sodecoton ne dispose pas d’un système de détection
d’intrusion en temps réel. Cela signifie qu’en cas d’attaque, l’entreprise risque de ne pas être avertie
immédiatement, retardant ainsi la prise de mesures correctives.
— Vulnérabilités dans les zones LAN : Les différentes zones du réseau local virtuel (LAN) peuvent présenter
des niveaux de sécurité différents, ce qui pourrait permettre à une attaque réussie dans une zone moins
sécurisée de compromettre l’ensemble du réseau.
— Manque de visibilité sur le trafic interne : Le réseau interne de la Sodecoton peut être sujet à des activités
suspectes ou malveillantes, mais sans outil de détection, il est difficile d’identifier ces comportements
anormaux.
— Exposition au trafic Internet : La connectivité avec l’Internet ouvre le réseau de la Sodecoton à un large
éventail de menaces externes, telles que les attaques DDoS, les tentatives de phishing et les logiciels
malveillants provenant de sources extérieures.
— Insuffisance des mesures de sécurité existantes : Bien que des pare-feux soient en place pour bloquer les
flux de données non autorisés, ils ne peuvent pas détecter les tentatives d’intrusion à l’intérieur du trafic
légitime.
— Absence de journalisation centralisée : Sans un système de journalisation centralisé, il peut être difficile
de suivre et d’analyser efficacement les activités réseau, ce qui peut rendre plus difficile la détection
d’intrusion.
❖ Aprés le déploiement
Après le déploiement du système de détection d’intrusion (IDS) dans l’architecture réseau de la Sodecoton,

une évaluation complète des emplacements stratégiques où l’IDS a été positionné révèle son efficacité et
son impact sur la sécurité globale du réseau.
Dans cette architecture, l’IDS a été positionné à plusieurs emplacements clés pour assurer une surveillance
exhaustive du trafic et une détection proactive des attaques.
— La position (1) correspond au point d’entrée de l’entreprise et joue un rôle essentiel dans la sécurité du
réseau. Équivalente à la position (1) de l’architecture centralisée, elle permet de filtrer et de bloquer les
attaques dès leur entrée dans le réseau.
— La position (2) est un autre emplacement stratégique où l’IDS est déployé pour surveiller et capturer
toutes les attaques qui traversent le pare-feu. Cela garantit la sécurité de l’ensemble de l’architecture
réseau, y compris les serveurs situés dans la zone démilitarisée (DMZ), qui sont des cibles potentielles
pour les attaques extérieures.
— La position (3) est similaire à la position (2) mais ne contrôle pas les menaces dirigées vers la zone DMZ
ni celles qui proviennent de cette zone. Ainsi, la deuxième position (2) est privilégiée car elle assure une
surveillance complète du trafic entrant et sortant, améliorant ainsi la détection des intrusions.
— La position (4) est idéale pour le placement de l’IDS car elle offre une couverture optimale de la zone de
travail tout en optimisant l’utilisation des ressources. Le flux entrant analysé passe par plusieurs obstacles
tels que deux pare-feu et les systèmes de prévention d’intrusion (IPS) situés aux positions (1) et (2). Cela
permet de réduire le volume de données à traiter par l’IDS, ce qui garantit son bon fonctionnement et une
détection précise des intrusions.
— la position (5) correspond au placement d’un IDS dans la zone publique, permettant ainsi de sécuriser et
surveiller cette zone spécifique. Son rôle essentiel est de détecter toute donnée sortante potentiellement
dangereuse, dans le cas où un intrus parviendrait à infiltrer cette zone.
Grâce à cette disposition stratégique de l’IDS, l’architecture réseau de la Sodecoton bénéficie d’une sécu-
rité renforcée et d’une détection proactive des attaques. L’IDS joue un rôle essentiel dans la protection
du réseau contre les menaces potentielles, tout en minimisant l’impact sur les performances du système.
En surveillant de manière continue le trafic réseau, l’IDS permet à l’entreprise de réagir rapidement aux
tentatives d’intrusion et de prévenir efficacement les attaques, assurant ainsi la stabilité et la sécurité
du réseau de la Sodecoton. Après le déploiement du Snort dans l’architecture réseau de la Sodecoton,
plusieurs points forts ont été observés :
— Détection proactive des intrusions : Snort permet une détection en temps réel des attaques potentielles
grâce à sa base de connaissances étendue sur les schémas d’attaques connues. Cela permet à l’entreprise de
réagir rapidement aux tentatives d’intrusion et de prendre des mesures correctives efficaces pour prévenir
les dommages potentiels.
— Surveillance complète du trafic réseau : Snort surveille de manière exhaustive le trafic entrant et sortant
du réseau, ce qui permet de détecter les activités suspectes et les comportements anormaux. Cela garantit
une visibilité accrue sur l’ensemble du réseau et permet d’identifier les menaces potentielles.
— Génération d’alertes et de journaux détaillés : Snort enregistre les résultats de ses analyses dans des
journaux (logs) détaillés, ce qui facilite l’identification et l’analyse des attaques détectées. Les alertes
générées permettent à l’équipe de sécurité de réagir rapidement aux incidents de sécurité et de prendre
les mesures appropriées.
— Positionnement stratégique de l’IDS : L’IDS a été positionné à plusieurs emplacements stratégiques, no-
tamment aux points d’entrée du réseau et dans les zones sensibles telles que la zone DMZ. Cela assure
une surveillance complète et une protection efficace de l’ensemble de l’architecture réseau.

— Optimisation des ressources : Grâce au positionnement stratégique de l’IDS, les ressources du système sont
utilisées de manière optimale. En réduisant le volume de données à traiter par l’IDS, le système fonctionne
de manière efficace et réactive, sans compromettre les performances du réseau.
— Réduction des risques d’attaques : La détection précoce des intrusions et la réponse rapide aux incidents
de sécurité permettent de réduire les risques d’attaques réussies. En détectant les attaques à un stade
précoce, l’entreprise peut prendre des mesures pour empêcher leur propagation et minimiser les dommages
potentiels.
— Renforcement global de la sécurité du réseau : En combinant Snort avec d’autres mesures de sécurité
telles que les pare-feux et les systèmes de prévention d’intrusion (IPS), l’entreprise bénéficie d’une sécurité
globale renforcée. Cette approche proactive contribue à protéger l’intégrité et la confidentialité des données
de l’entreprise.
4.2 Architecture réseau de la Sodecoton

La mise en place et la configuration d’un réseau informatique au sein d’une entreprise sont d’une impor-
tance primordiale. Elles permettent aux utilisateurs d’accéder à Internet et de partager des données confiden-
tielles entre eux. Ces étapes jouent un rôle fondamental dans la facilitation du travail et sont essentielles pour
garantir la sécurité des informations.
Dans cette section, nous allons exposer les différentes zones réseaux de la Sodecoton et procéder à leur
sécurisation en utilisant le système de détection d’intrusions Snort, qui sera installé sur la plateforme Ubuntu
18.04 LTS. Nous effectuerons cette sécurisation sur trois types d’architectures distinctes.
4.2.1 Zones réseaux de l’entreprise

Le réseau de la Sodecoton est composé de deux sous-réseaux distincts. Le premier est un réseau local vir-
tuel (LAN) qui est à son tour divisé en trois sous-réseaux ou zones. Le deuxième sous-réseau est le réseau externe
WAN (Internet), qui permet l’échange de données entre le réseau LAN et l’Internet. Ainsi, cette configuration
permet à la Sodecoton de séparer et de gérer efficacement ses différents domaines réseau tout en facilitant la
connectivité avec l’Internet.
• La zone centrale de l’entreprise, également connue sous le nom de cœur de l’entreprise, est l’endroit où se
déroule la majeure partie des activités. C’est là que l’on retrouve des dispositifs tels que des imprimantes,
des téléphones fixes, des postes de travail, ainsi que le(s) poste(s) administrateur(s) bénéficiant de privilèges
élevés. Ces administrateurs ont la capacité de contrôler les serveurs de la zone DMZ, les routeurs, les pare-
feu et pratiquement l’ensemble du réseau de l’entreprise.
• Les domaines d’utilisation publics des entreprises, tels que les espaces communs, sont conçus pour per-
mettre aux employés d’utiliser leurs propres appareils personnels tels que des ordinateurs portables, des
smartphones, des tablettes, etc. Cependant, il est essentiel de maintenir une séparation entre cette zone
et la zone de travail principale afin d’assurer une sécurité adéquate.
• La zone démilitarisée, également appelée "demilitarized zone" (DMZ) en anglais, est un emplacement
dédié aux serveurs tels que les serveurs web, les serveurs VPN, les serveurs proxy, etc. Ces serveurs sont
utilisés pour fournir des services, tels que des sites web, des proxies, des connexions VPN, des serveurs
virtuels privés, etc., aux utilisateurs situés en dehors du réseau local de l’entreprise. La DMZ est spécia-
lement conçue pour être accessible depuis Internet, offrant ainsi une séparation entre le réseau interne de
l’entreprise et les services accessibles au public. La zone démilitarisée (DMZ) est une méthode de sécurité

qui agit comme un pont entre le réseau Internet (WAN) et les autres réseaux locaux de l’entreprise. Son
objectif est d’empêcher les attaquants externes de pénétrer le cœur de l’entreprise, tel que la zone prin-
cipale. Ainsi, la DMZ offre une couche de protection supplémentaire en séparant les ressources sensibles
de l’entreprise de l’accès direct depuis Internet, réduisant ainsi les risques potentiels liés aux attaques
externes.
• La zone d’accès à l’extérieur de l’entreprise, également appelée zone DMZ (Demilitarized Zone), est spécia-
lement conçue pour permettre l’accès et le partage des données avec l’Internet. Cette zone est connectée à
l’aide de connexions à fibre optique, offrant ainsi une large bande passante. Pour garantir des performances
élevées, de nombreuses entreprises utilisent des fibres optiques ou agrègent plusieurs interfaces réseau en
une seule interface logique (Bonding). Cette approche permet d’optimiser les capacités de connexion à
Internet et d’assurer une connectivité fiable et rapide pour les opérations d’échange de données avec
l’extérieur de l’entreprise.
4.2.2 Architecture centralisée
Figure 4.1 – Architecture centralisée.
La (Figure 4.1) illustre que tous les réseaux locaux (DMZ, principal et PUBLIC) sont directement connec-
tés à un serveur de contrôle (nœud central). Chaque sous-réseau local est relié à une des interfaces du nœud
central, qui à son tour est connecté à Internet (WAN) via un routeur.
NB : Le serveur de contrôle désigne une machine ou un ordinateur puissant où Snort ainsi que d’autres services
tels que le pare-feu, le routeur et Snort lui-même seront installés.
❖ Placement des systèmes de détection d’intrusions (IDS) au sein d’une architecture centrali-
sée :
Les positions des IDS sont représentées par des cercles rouges sur la (figure 4.1) :
• La première idée, qui vient à l’esprit est de positionner l’IDS de manière à couvrir l’ensemble de
l’architecture, afin de détecter toutes les attaques frontales. Cependant, cette approche peut générer

un grand nombre d’alertes, ce qui peut entraîner une consommation importante de ressources et
rendre les logs difficiles à consulter.
• En position (2), le placement d’un IDS limite sa capacité à détecter les attaques frontales et se
limite à la couverture de la zone publique. Cela se traduit par une consommation de ressources
réduite, mais son utilité est limitée car il ne sécurise pas les zones principales et DMZ, qui sont les
zones critiques de l’architecture réseau.
• La position (3), de l’installation d’un système de détection d’intrusion (IDS) joue un rôle crucial
en couvrant une zone essentielle, ce qui permet de réduire considérablement les erreurs humaines. Il
contribue à minimiser les activités indésirables, qu’elles soient accidentelles ou intentionnelles de la
part des employés.
• En position (4), la sécurité est uniquement assurée pour la zone DMZ, sans prendre en compte
le flux qui transite vers la zone PUBLIC et la zone principale. Dans le sous-réseau DMZ, il est
recommandé d’installer un HIDS (Système de Détection d’Intrusion basé sur l’hôte) sur les serveurs
plutôt que d’utiliser un NIDS, surtout s’il y a un nombre restreint de serveurs. En effet, la zone DMZ
est généralement automatisée et ne présente pas d’activités humaines significatives.
Il y a trois options disponibles pour équiper cette architecture avec un système de détection d’intrusions
afin de sécuriser l’ensemble de l’architecture réseau de la Sodecoton.
— Le déploiement d’une unique sonde à l’emplacement (1).

— Le déploiement de sondes aux emplacements numéros un, deux et trois.
— Le déploiement de sondes sur toutes les positions peut entraîner des coûts élevés et une surcharge du
serveur central.
❖ Avantages de l’architecture centralisée :

— Le déploiement et la configuration de Snort sont simples et faciles à réaliser.
— L’ensemble du trafic entrant et sortant de l’entreprise est acheminé à travers une seule machine, ce qui
centralise la gestion du flux et offre un point unique pour contrôler l’ensemble des échanges.
❖ Inconvénients d’architecture centralisée :

— En cas de défaillance du nœud central, l’intégralité de l’architecture se trouve impactée et ne fonctionne
plus.
— Étant donné que le traitement des paquets implique la conservation des connexions en cours, il existe des
attaques ciblant ces équipements dans le but de saturer leur mémoire.
— Lorsqu’un attaquant prend le contrôle du nœud central, il obtient le contrôle total de toutes les zones de
l’entreprise, y compris la zone principale, la zone publique et la zone DMZ.
— La bande passante est limitée en raison du contrôle centralisé du trafic par le nœud principal.

4.2.3 Architecture décentralisée
Figure 4.2 – Architecture décentralisée.
L’architecture illustrée dans la Figure 4.2 se compose de zones isolées, où chaque zone dispose de son
propre serveur de contrôle. Chaque serveur de contrôle est directement connecté au réseau WAN via le même
routeur.
❖ Positionnement des IDS dans l’architecture décentralisée :

Selon la figure 4.2, il est essentiel de positionner l’IDS à plusieurs emplacements stratégiques au sein de
cette architecture.
• La Position (1), l’IDS aura la capacité de détecter toutes les attaques venant de l’extérieur, principa-
lement ciblant la zone DMZ de l’entreprise. Cependant, cette approche peut entraîner un grand nombre
d’alertes, rendant les logs difficiles à consulter. Il convient de noter que cette mesure de sécurité ne couvre
qu’un tiers (1/3) du réseau de l’entreprise.
• La position (2), présente plus d’inconvénients que d’avantages lorsqu’il s’agit de positionner un IDS à
cet endroit, car il génère les mêmes inconvénients que la position (1) et ne couvre pas les zones essentielles
de l’entreprise, telles que la zone DMZ et le réseau principal.
• La position (3), est similaire à la position (1), à la différence que la zone sécurisée n’est pas la DMZ,
mais plutôt la zone principale, où les erreurs humaines sont fréquentes.
• La Position (4), En positionnant l’IDS dans la DMZ, il sera en mesure de détecter les attaques qui ont
échappé à la filtration du pare-feu et qui nécessitent un certain niveau de compétence. Cependant, il ne
sera pas en mesure de diagnostiquer toutes les menaces ciblant l’entreprise depuis l’extérieur. Dans ce cas,
il sera plus facile de consulter les logs, car les attaques mineures ne seront pas enregistrées.
• La position (5), se limite à la zone publique et ne permet pas la détection des attaques frontales.
• La Position (6), En positionnant l’IDS dans la zone principale, il est possible de détecter les attaques
internes provenant du réseau local de l’entreprise. Cette stratégie peut s’avérer judicieuse, étant donné

que la majorité des attaques proviennent de l’intérieur. De plus, en plaçant l’IDS à cet endroit, il sera plus
facile d’identifier et d’éliminer les chevaux de Troie qui pourraient avoir infecté la zone principale.
Pour sécuriser toutes les zones de cette architecture, il est recommandé de déployer un minimum de
trois systèmes de détection d’intrusions (IDS), et chacun d’entre eux fonctionnera à pleine capacité.
❖ Avantages d’architecture décentralisée :

• Au lieu de surcharger un seul serveur de contrôle avec l’ensemble du flux, nous optons pour une approche
décentralisée en répartissant le flux sur trois serveurs de contrôle afin de réduire la charge.
• La tolérance aux pannes signifie que si l’un des trois serveurs de contrôle tombe en panne, le réseau subira
une dégradation de performance, mais ne sera pas totalement hors service.
❖ Inconvénients d’architecture décentralisée :
• La mise en place et l’installation de Snort peuvent présenter certaines difficultés.
• Il est difficile de gérer la surveillance et le contrôle de trois serveurs simultanément.
• La redondance des règles de configuration des pare-feu et des systèmes de détection d’intrusions (IDS)
fait référence à la situation où certaines règles ou fonctionnalités se chevauchent ou se répètent entre les
deux systèmes.
• Il peut être difficile de déterminer les emplacements optimaux pour l’IDS (système de détection d’intru-
sions).
• Déployer plusieurs systèmes de détection d’intrusions (IDS) afin de garantir la sécurité de l’ensemble de
l’entreprise.
• Il peut être facile de se retrouver submergé par le flux constant de notifications et de logs générés par les
IDS.
4.2.4 Architecture hybride

La combinaison d’une architecture centralisée et décentralisée est illustrée dans la Figure 4.3. Cette ap-
proche implique la décentralisation du contrôle du réseau DMZ ainsi que des réseaux Principal et PUBLIC, qui
se déroule en trois étapes distinctes :
— Configurer un serveur de contrôle 1 pour établir la connexion entre le réseau Internet et la zone démilitarisée
(DMZ).
— Nous établissons une centralisation des deux zones, Principal et PUBLIC, en les reliant à un autre serveur
de contrôle 2 via deux interfaces réseau distinctes.
— Pour permettre l’accès aux services du serveur de contrôle 2 ainsi qu’à Internet, il est nécessaire de
connecter l’interface WAN de ce serveur à la zone démilitarisée (DMZ). Cette configuration permettra
d’établir une liaison entre le serveur et la DMZ, autorisant ainsi l’accès aux services du serveur depuis
cette zone, tout en garantissant également la connectivité Internet.

Figure 4.3 – Architecture hybride.
❖ Positionnement des IDS dans l’architecture hybride :

Dans cette architecture, il est essentiel de positionner l’IDS à plusieurs emplacements stratégiques. La
figure 4.3 identifie clairement ces emplacements.
• La position (1), correspond à un point d’entrée de l’entreprise et est équivalente à la position (1) de
l’architecture centralisée.
• La position (2), consiste à déployer un système de détection d’intrusions (IDS) à cet emplacement, ce
qui lui permet de surveiller et de capturer toutes les attaques qui traversent le pare-feu. Cela permet de
sécuriser l’ensemble de l’architecture, y compris les serveurs situés dans la zone démilitarisée (DMZ).
• La position (3), est similaire à la position (2), à la différence qu’elle ne contrôle pas les menaces dirigées
vers la zone DMZ ni celles qui proviennent de cette zone. Par conséquent, il est préférable de placer l’IDS
à la deuxième position plutôt qu’à cette position.
• La position (4), est idéale pour placer un système de détection d’intrusions (IDS) car elle offre une
couverture efficace de la zone de travail tout en minimisant la consommation de ressources. Étant donné
que le flux entrant analysé passe par plusieurs obstacles tels que deux pare-feu et les IPS situés aux
positions une et deux, cela réduit le volume de données à traiter par l’IDS. Ainsi, cette position permet
à l’IDS de fonctionner de manière optimale en détectant les intrusions tout en conservant une utilisation
efficace des ressources.
• La position (5), correspond à la placement d’un IDS dans cette zone spécifique, permettant ainsi de
sécuriser et surveiller la zone publique. Son rôle est de détecter toute donnée sortante potentiellement
dangereuse dans le cas où un intrus parviendrait à infiltrer cette zone.
Il existe trois options pour protéger l’ensemble de l’entreprise en équipant cette architecture avec un système
de détection d’intrusions :
• En plaçant un IDS à la position (1), on peut s’attendre à ce qu’il présente à la fois les avantages et les
inconvénients de l’architecture centralisée à cette position.

• Il est recommandé de placer trois IDS aux positions (1), (4) et (5) pour assurer une configuration optimale.
❖ Avantages d’architecture hybride :
• Placer le réseau DMZ entre les zones Principal et PUBLIC ajoute une couche supplémentaire de sécurité,
créant ainsi une barrière supplémentaire entre ces deux zones.
• La zone automatisée DMZ joue le rôle d’intermédiaire entre les zones Principal et PUBLIC, en filtrant
tout le flux provenant de ces deux zones. Son objectif est de masquer la zone principale, qui représente le
cœur de l’entreprise, vis-à-vis du réseau WAN afin de prévenir les attaques directes.
• La distribution du flux de contrôle permet de réduire la charge sur les nœuds de contrôle. En effet, le
serveur de contrôle 1 se concentre uniquement sur le contrôle du flux de réseau DMZ, tandis que le serveur
de contrôle 2 prend en charge le contrôle du flux des zones Principal et Public. Cette répartition du contrôle
permet d’optimiser les performances et d’éviter une surcharge excessive sur un seul nœud de contrôle.
• Optimiser la configuration en évitant la duplication des règles.
• En cas de panne du serveur de contrôle 1, le réseau interne de l’entreprise continuera à fonctionner
normalement. De même, si le serveur de contrôle 2 tombe en panne, les services de domaine DMZ resteront
opérationnels pour les clients situés dans le réseau WAN grâce au premier serveur de contrôle 1.
• En utilisant seulement deux IDS pour surveiller trois zones, cela permet de réduire les coûts par rapport
à une architecture décentralisée.
❖ Inconvénients d’architecture hybride :

• L’architecture hybride engendre un coût supplémentaire par rapport à d’autres alternatives.
• En cas de défaillance du premier serveur de contrôle, l’ensemble du réseau perd sa connexion Internet.
4.3 Présentation de Snort : Un aperçu de système détection d’intru-

sion dans l’architecture réseau
4.3.1 Définition
Snort est un système de détection d’intrusions open source qui permet d’analyser en temps réel le trafic
réseau et de journaliser les paquets sur un réseau IP. Il offre des fonctionnalités telles que l’analyse de pro-
tocole, la recherche et la correspondance de contenu, et peut être utilisé pour détecter diverses attaques et
tentatives, notamment les balayages de port dissimulés, les tentatives d’empreinte de système d’exploitation,
et bien d’autres. Snort est un système de détection d’intrusions qui permet de détecter différentes méthodes
d’attaques telles que les attaques de déni de service, les attaques CGI et les balayages de ports furtifs. Lorsque
Snort identifie des comportements suspects, il génère des alertes en temps réel qui peuvent être envoyées à sys-
log ou enregistrées dans un fichier d’alertes dédié. Snort s’appuie sur la bibliothèque libpcap pour capturer les
paquets, ce qui en fait un outil populaire pour les détecteurs de trafic TCP/IP et les analyseurs en raison de sa
capacité à analyser les protocoles et à rechercher des contenus spécifiques. Snort a trois principales utilisations.
Tout d’abord, il peut être utilisé comme un renifleur de paquets (sniffer), similaire à tcpdump(1), pour capturer
et analyser le trafic réseau. Deuxièmement, il peut servir d’enregistreur de paquets (logs), utile pour l’analyse
du trafic réseau, la résolution de problèmes, etc. Enfin, Snort peut fonctionner comme un système complet de
détection d’intrusion réseau, permettant de détecter et de prévenir les activités malveillantes sur le réseau .

Figure 4.4 – Plateformes pour installer SNORT.
4.3.2 Raison de choix du Snort

❖ Disponibilité gratuite
Le choix de Snort pour l’analyse en temps réel repose sur ses capacités à détecter les attaques potentielles
de manière rapide et efficace. Snort est un système de détection d’intrusion réseau largement reconnu pour
sa performance dans l’analyse en temps réel du trafic réseau. Grâce à sa conception optimisée, Snort peut
surveiller en temps réel les paquets entrants et sortants dans l’architecture réseau de la Sodecoton.
Lorsque le trafic circule à travers le réseau, Snort analyse chaque paquet en utilisant des règles de détection
spécifiques préconfigurées. Ces règles définissent les modèles de comportement et les signatures des attaques
connues. Lorsqu’un paquet correspond à l’une de ces règles, une alerte est déclenchée instantanément,
signalant une possible tentative d’intrusion.
La capacité de Snort à effectuer cette analyse en temps réel offre un avantage crucial pour la sécurité
du réseau. En détectant rapidement les attaques potentielles, il permet aux administrateurs de réagir
immédiatement et de prendre des mesures pour contrer les menaces avant qu’elles ne puissent causer des
dommages. Cette réactivité est essentielle pour minimiser les risques de sécurité et protéger les données
sensibles de l’entreprise.
De plus, Snort offre une grande flexibilité en permettant aux administrateurs de créer et de personnaliser
leurs propres règles de détection pour répondre à des menaces spécifiques ou émergentes. Cela permet
d’adapter le système de détection aux besoins spécifiques de l’architecture réseau de la Sodecoton et de
rester à jour face aux nouvelles méthodes d’attaques.
❖ Analyse en temps réel

Le choix du Snort pour effectuer une analyse en temps réel s’est avéré judicieux pour plusieurs raisons
essentielles. Tout d’abord, Snort est réputé pour sa capacité à surveiller en continu le trafic réseau entrant et
sortant, ce qui garantit une détection rapide et proactive des attaques potentielles. Grâce à sa fonctionnalité
d’analyse en temps réel, Snort est en mesure d’inspecter chaque paquet de données en temps réel, ce qui
lui permet de réagir instantanément à toute activité suspecte.
De plus, la nature en temps réel de Snort offre un avantage crucial en termes de sécurité informatique.
Les attaques peuvent survenir à tout moment et de manière inattendue. C’est pourquoi une détection
rapide est indispensable pour minimiser les risques de dommages et de compromissions. Snort excelle dans
cette tâche en effectuant une analyse continue et en générant des alertes immédiates dès qu’il détecte une
activité suspecte ou malveillante.

Un autre aspect positif de Snort est sa capacité à s’adapter aux nouvelles menaces et à évoluer en même
temps que les techniques d’attaque. Grâce à sa communauté active et engagée, Snort bénéficie de mises à
jour régulières de ses règles de détection, ce qui lui permet de rester à jour face aux nouvelles vulnérabilités
et aux tactiques utilisées par les cybercriminels.
Enfin, Snort offre une grande flexibilité et personnalisabilité dans la configuration des règles de détection.
Les administrateurs peuvent ajuster les paramètres selon les besoins spécifiques de leur réseau et défi-
nir des seuils d’alerte adaptés à leur environnement. Cette capacité à personnaliser les règles de détection
garantit une plus grande précision et réduit les faux positifs, améliorant ainsi l’efficacité globale du système.
❖ Compatibilité multiplateforme
Le choix de Snort pour sa compatibilité multiplateforme a été déterminant dans la mise en place du système
de détection d’intrusion. En effet, Snort est conçu pour être disponible sur plusieurs systèmes d’exploita-
tion, ce qui inclut non seulement Windows, mais aussi différentes distributions Linux telles qu’Ubuntu,
Debian et CentOS. Cette polyvalence permet une intégration aisée de Snort dans divers environnements
réseau, qu’ils soient basés sur des systèmes Windows ou Linux. Cette caractéristique est particulièrement
avantageuse pour la Sodecoton, car elle offre la flexibilité nécessaire pour déployer le système de détection
d’intrusion sur l’ensemble de son infrastructure réseau, quelle que soit la diversité des systèmes d’exploi-
tation utilisés. De plus, cette compatibilité multiplateforme assure une interopérabilité fluide entre les
différents composants du réseau, ce qui facilite la gestion et la surveillance centralisées du système de dé-
tection d’intrusion. Grâce à cette adaptabilité, Snort se positionne comme une solution robuste et adaptée
aux besoins spécifiques de la Sodecoton, offrant ainsi une meilleure protection contre les menaces et les
attaques potentielles, indépendamment du système d’exploitation sur lequel il est déployé. En optant pour
Snort en raison de sa compatibilité multiplateforme, la Sodecoton renforce la sécurité de son architecture
réseau et s’assure d’une surveillance proactive et efficace de son infrastructure, contribuant ainsi à la pré-
servation de l’intégrité et de la confidentialité de ses données sensibles.
❖ Mises à jour gratuites des règles

Le choix du Snort pour ses mises à jour gratuites des règles de détection est un élément essentiel qui a
grandement influencé la décision d’opter pour ce système de détection d’intrusion au sein de l’architecture
réseau de la Sodecoton. En effet, la sécurité informatique est une préoccupation majeure dans le paysage
numérique en constante évolution, avec l’émergence continue de nouvelles menaces et attaques sophisti-
quées. Grâce aux mises à jour régulières des règles de détection de Snort, l’entreprise peut bénéficier d’une
protection renforcée contre les dernières vulnérabilités et les attaques les plus récentes.
Ces mises à jour fréquentes garantissent que Snort dispose des connaissances et des signatures les plus
récentes pour détecter et prévenir efficacement les menaces émergentes. Les experts en sécurité qui sou-
tiennent et développent Snort travaillent sans relâche pour identifier et analyser les nouvelles méthodes
utilisées par les attaquants, ce qui se traduit par une mise à jour constante de la base de données des
règles de détection.
En utilisant Snort, la Sodecoton peut s’assurer que son système de détection d’intrusion est toujours à la
pointe de la sécurité informatique, même face aux menaces les plus récentes et complexes. Cette approche
proactive permet à l’entreprise de renforcer sa posture de sécurité globale en réduisant considérablement
les risques potentiels liés aux cyberattaques.
❖ Connaissance préexistante des attaques

Le choix de Snort repose sur sa connaissance préexistante des attaques, qui constitue un atout majeur
pour la sécurité du réseau. En effet, Snort est équipé d’une base de connaissances exhaustive sur les

différentes formes d’attaques qui peuvent cibler un système informatique. Grâce à cette base de données,
Snort est capable de reconnaître et d’identifier des schémas d’attaques connus, ce qui lui permet de réagir
de manière proactive dès qu’une menace est détectée.
Lorsque Snort détecte une activité suspecte correspondant à une attaque répertoriée dans sa base de
connaissances, il génère automatiquement des notifications, alertant ainsi les administrateurs du réseau de
la présence potentielle d’une menace. Cette capacité de détection préventive aide grandement à réduire le
temps de réaction face aux attaques, ce qui est essentiel pour contrer rapidement les tentatives d’intrusion
et minimiser les dommages éventuels.
En outre, la base de connaissances de Snort est continuellement mise à jour, ce qui lui permet de rester
à jour face aux nouvelles méthodes et variantes d’attaques qui émergent constamment dans le paysage
de la cybercriminalité. Cette adaptabilité renforce encore davantage la capacité de Snort à fournir une
protection efficace contre un large éventail de menaces potentielles.
Grâce à la connaissance préexistante des attaques et à sa capacité à générer des notifications en temps
réel, Snort devient un allié essentiel dans la lutte contre les cyberattaques. En choisissant Snort comme
système de détection d’intrusion, l’entreprise peut bénéficier d’une sécurité accrue et d’une meilleure pré-
paration pour faire face aux tentatives d’intrusion, assurant ainsi l’intégrité et la confidentialité de son
réseau informatique.
4.3.3 Architecture de Snort
L’architecture de SNORT est conçue de manière modulaire, se composant de quatre principaux modules :
le décodeur de paquets, les préprocesseurs, le moteur de détection et le système d’alerte et d’enregistrement
de journaux|10|. Cette structure permet une organisation claire et efficace des différentes fonctionnalités de
SNORT, facilitant ainsi la détection et la réponse aux activités suspectes dans les réseaux. La figure 4.5 illustre
cette architecture.
Figure 4.5 – Architecture de SNORT.
• Décodeur de paquets : tel que celui utilisé par SNORT, fonctionne en mode espion (promiscuous mode)
sur une ou plusieurs interfaces réseau de la machine. Cela lui permet de lire et d’analyser tous les paquets
transitant par le lien de communication. Pour capturer ces paquets, SNORT utilise la bibliothèque libpcap.

Le décodeur de paquets est constitué de plusieurs sous-décodeurs organisés par protocole (Ethernet, IP,
TCP, etc.). Ces sous-décodeurs transforment les éléments spécifiques à chaque protocole en une structure
de données interne, permettant ainsi une analyse plus approfondie. Vous pouvez voir une représentation
de cette structure dans la (figure 4.6).
Figure 4.6 – Le décodeur de paquets.
• Préprocesseurs : jouent un rôle essentiel dans la détection d’intrusions en identifiant les anomalies.
Contrairement aux règles de détection, les préprocesseurs sont des programmes qui permettent une analyse
plus approfondie du trafic. Ils sont exécutés avant le moteur de détection, après le décodage du paquet
IP. Les préprocesseurs peuvent modifier ou analyser les paquets IP de différentes manières, en utilisant le
mécanisme spécifique des préprocesseurs. Ils sont chargés et configurés à l’aide du mot-clé "préprocessor".
• Moteur de détection : joue un rôle crucial au sein d’un système de détection d’intrusions (IDS). Il
utilise des règles pour analyser les activités de réseau et détecter les intrusions. Lorsqu’un paquet réseau
correspond à une règle spécifique, une alerte est générée. Les règles sont organisées en fichiers regroupés
par catégories. Par défaut, SNORT est livré avec un ensemble de règles prédéfinies. Cependant, ces règles
ne sont pas activées automatiquement et nécessitent une activation manuelle dans le fichier de configura-
tion snort.conf. Chaque fichier de règles contient des instructions pour signaler un type spécifique de trafic
(voir figure 4.7).

Figure 4.7 – Partie du fichier snort.conf.
• Système d’alerte et d’enregistrement des logs

Le système d’alerte et d’enregistrement des logs est responsable de la génération des logs et des alertes,
qui sont stockées par défaut dans le répertoire sur le figure 4.5
Figure 4.8 – Répertoire /var/log/snort.
Une fois le système opérationnel, les alertes générées peuvent être consultées directement dans les fichiers
texte ou via une console de gestion telle que ACID (Analysis Console for Intrusion Detection) ou une ver-
sion améliorée comme BASE. ACID offre une interface graphique permettant la visualisation des alertes

et stocke celles-ci dans une base de données MySQL.
❖ Raison de choix du Snort
• Disponibilité gratuite : Snort est un logiciel gratuit, ce qui le rend accessible pour les entreprises ayant
des contraintes budgétaires.
• Analyse en temps réel : Snort est capable d’effectuer une analyse en temps réel du trafic entrant et sortant,
ce qui permet une détection rapide des attaques potentielles.
• Compatibilité multiplateforme : Snort est disponible pour plusieurs systèmes d’exploitation, notamment
Windows et diverses distributions Linux telles qu’Ubuntu, Debian et CentOS. Cela facilite son intégration
dans différents environnements réseau.
• Mises à jour gratuites des règles : Snort bénéficie de mises à jour régulières des règles de détection,
permettant de rester à jour face aux nouvelles menaces et attaques.
• Connaissance préexistante des attaques : Snort dispose d’une base de connaissances étendue sur les at-
taques et peut générer des notifications lorsqu’il détecte des schémas d’attaques connus.
4.3.4 Choix de l’architecture

Dans notre présentation, nous avons examiné les trois architectures standard d’entreprise : centralisée,
décentralisée et hybride. Étant donné que notre sujet porte sur la sécurité et la mise en place d’un système
de détection d’intrusions IDS, nous avons choisi l’architecture hybride en raison de ses nombreux avantages en
termes de sécurité.
L’objectif de cette architecture hybride est de tirer parti des avantages des autres architectures mentionnées
dans la partie (4.1). En plaçant les zones "Principal" et "PUBLIC" dans un seul serveur de contrôle centralisé,
tout en isolant le réseau DMZ avec son propre serveur de contrôle, nous pouvons atténuer les inconvénients
associés et ajouter d’autres avantages à notre système.
Cette architecture présente plusieurs avantages par rapport à d’autres architectures, notamment en faisant pas-
ser le flux entrant par plusieurs barrières de sécurité, ce qui permet un filtrage plus efficace. La figure suivante
illustre cette configuration.
Le concept de cette architecture consiste à mettre en place quatre niveaux de sécurité essentiels (deux
pare-feu et deux systèmes de détection d’intrusions - IDS), ainsi qu’une optionnelle (redirection du trafic via un
proxy ou un VPN), comme illustré dans la figure ci-dessous :

Figure 4.9 – Topologie de l’architecture hybride.
Selon l’illustration précédente, les communications entre le réseau Internet et les deux zones (Principal et
PUBLIC) sont contrôlées à travers quatre points d’accès placés en série. Chaque point de contrôle joue un rôle
complémentaire et est décrit comme suit :
— Première barrière, représentée par la configuration du pare-feu 1, autorise le passage des requêtes SYN
entrantes pour la synchronisation, tout en bloquant les paquets et les domaines indésirables conformément
à la politique de la Sodecoton. Cette approche réduit le volume du trafic entrant, facilite l’analyse du flux
de données à la prochaine barrière et prévient la surcharge du serveur.
— Barrière 2 : Après avoir passé la première barrière et réduit le volume des données, la deuxième barrière
intervient, où l’IDS joue un rôle clé. Son objectif est d’analyser le flux de données provenant de la première
barrière en comparant les paquets réseau à une base de données de cybermenaces. Il est chargé de bloquer
les paquets potentiellement dangereux, ce qui permet de réduire une fois de plus le volume du trafic avant
d’atteindre la prochaine barrière.
— Barrière 3 : est constituée du pare-feu 2, qui joue un rôle de protection pour les zones inaccessibles via
Internet, à savoir les zones principale et publique. Il est configuré de manière à bloquer les requêtes SYN
qui ont déjà traversé le Pare-feu 1 et qui sont destinées à pénétrer les zones principale et publique. De
plus, le pare-feu peut également bloquer d’autres types de paquets en fonction des besoins spécifiques de
l’entreprise. Cette configuration permet de réduire le flux une troisième fois en vue de la prochaine barrière
de sécurité.
— Barrière 4 : constitue la dernière ligne de défense, protégeant à la fois les zones principales et la zone
publique contre les menaces provenant d’Internet. Elle joue également un rôle essentiel en tant que première
ligne de défense contre les attaques provenant de la zone publique, dans le cas où un intrus parviendrait
à s’infiltrer dans cette zone.
— Barrière 5 : a pour principale fonction d’assurer la sécurité et la surveillance des échanges de données,
en mettant particulièrement l’accent sur les données sortantes.

4.3.5 Fonctionnement de Snort

Le fonctionnement de Snort repose sur le passage des données à travers quatre blocs qui remplissent des
rôles complémentaires, décrits de la manière suivante :
— Bloc 1 (sniffer de paquets) : consiste à intercepter toutes les trames qui transitent sur le réseau et à
les lire à l’aide d’un décodeur basé sur la librairie "libpcap".
— Le bloc 2 du préprocesseur : peut détecter les malformations, anomalies et autres problèmes, et
effectuer les corrections nécessaires.
— Bloc 3, également connu sous le nom de moteur de détection, utilise des flux normalisés et
réassemblés afin de détecter d’éventuelles anomalies ou intrusions.
— Le Bloc 4, qui concerne les événements, enregistre les informations sous différentes formes telles
que des logs au format unifié, des bases de données, etc. Snort dispose d’un moteur de détection qui
utilise des règles pour identifier les intrusions. Ces règles peuvent être téléchargées à partir du site officiel
de Snort en tant que règles prédéfinies, ou nous avons également la possibilité de créer nos propres règles
personnalisées en utilisant un langage de description simple et léger. Ce langage offre une flexibilité et une
puissance suffisantes pour programmer des règles adaptées à nos besoins spécifiques .
❖ La structure des règles :

Pour que les règles de Snort soient correctement interprétées par l’analyseur, il est essentiel de les écrire
sur une seule ligne, car l’analyseur de règles de Snort ne peut pas traiter des règles réparties sur plusieurs
lignes. Les règles Snort sont généralement divisées en deux sections logiques distinctes pour faciliter leur
gestion et leur compréhension.
— La section d’en-tête de règle comprend les éléments suivants : l’action de la règle (alerte, journalisa-
tion, autorisation, etc.), le protocole utilisé, les adresses IP source et destination avec leurs masques
réseau, ainsi que les ports source et destination.
— La section "options" d’une règle contient les messages d’alerte et les informations concernant les
parties spécifiques du paquet qui doivent être inspectées afin de déterminer si l’action de la règle doit
être acceptée.
Figure 4.10 – Fichier local.rules.

❖ Les entêtes de règle
L’entête de règle contient les informations qui définissent le "qui, où et quoi" d’un paquet. Dans cette
partie de la règle, nous pouvons identifier :
— L’action de règle est le premier élément de l’en-tête d’une règle. Elle spécifie à Snort quelle action effectuer
lorsqu’un paquet correspond aux critères définis par la règle.
Snort dispose de cinq actions préconfigurées par défaut :
— Lorsqu’une alerte est générée, cela signifie qu’un système de détection d’intrusions a détecté une activité
suspecte ou malveillante et a signalé cet événement pour attirer l’attention des administrateurs ou des
analystes de sécurité.
— Le processus de journalisation enregistre les informations relatives au paquet.
— Lorsqu’un paquet est ignoré, il est simplement omis ou exclu du traitement.
— L’activation d’une règle dynamique (dynamic) permet de mettre en action une autre règle active.
— Le mode "Dynamic" reste inactif jusqu’à ce qu’il soit activé par une règle "activate".
Figure 4.11 – Builds.
— Les protocoles permettent de spécifier le type de communication à analyser, tels que TCP, UDP, ICMP,
ARP, etc.

4.4 Mise en place d’un système de détection d’intrusion

Un test d’intrusion, également appelé "pentest" en anglais, est une approche utilisée pour évaluer la sécu-
rité d’un système ou d’un réseau informatique. Cette méthode consiste généralement à simuler une attaque afin
de détecter des vulnérabilités exploitables, permettant ainsi de proposer un plan d’actions visant à améliorer la
sécurité du système.
4.4.1 Choix de l’architecture

Nous avons examiné les trois architectures standard de l’entreprise, à savoir centralisée, décentralisée
et hybride. Étant donné que notre thème de sécurité porte sur la mise en place d’un système de détection
d’intrusions (IDS), nous avons choisi l’architecture hybride en raison de ses avantages en termes de sécurité.
Figure 4.12 – Architecture retenue.
4.4.2 But du test d’intrusion

L’objectif d’un test d’intrusion dans l’architecture réseau de la Sodecoton peut varier en fonction du
contexte et des besoins spécifiques, mais il vise généralement à évaluer la robustesse de la sécurité du réseau en
détectant les vulnérabilités, en identifiant les failles de sécurité et en évaluant la capacité du système à résister
à des attaques potentielles :
• Recenser une série d’informations, obtenues de différentes sources, qui peuvent être sensibles ou critiques.
• Établir une liste des vulnérabilités ou faiblesses du système de sécurité qui pourraient être exploitées.
• Tester l’efficacité des systèmes de détection d’intrusion en place.
• Préparer un rapport détaillé et une présentation finale pour le client, en exposant l’avancement des travaux
et les découvertes réalisées.
• Fournir des recommandations et des conseils sur les méthodes de résolution et de correction des vulnéra-
bilités identifiées.

4.4.3 Outils de détection d’intrusion réseau utilisés pour la détection d’in-

trusions
• Un PC LENOVO équipé d’un système d’exploitation 64 bits, GNOME 3.28.2 et 4 Go de RAM.

• Le système d’exploitation utilisé est Ubuntu 18.04.6 LTS.
• Le logiciel de détection d’intrusions utilisé est Snort, accompagné de ses règles.
• Avant d’installer le logiciel, les prérequis nécessaires ont été installés conformément aux exigences du
système.
4.4.4 Installation et configuration du snort
❖ Installation des pré-requis

L’installation des prérequis peut être complexe, car ils dépendent souvent d’autres paquets à installer. Par
conséquent, avant de procéder à l’installation de ces prérequis, nous effectuerons une mise à jour système
pour nous assurer d’avoir au moins les outils de base nécessaires pour commencer.
Pour réaliser cette tâche, nous procédons en ouvrant un terminal et en nous connectant en tant que « root
». Ensuite, nous exécutons les commandes suivantes :
# apt-get update
# apt-get upgrade
Figure 4.13 – Les Update.
❖ Installation des dépendances

Il est recommandé de prendre des précautions particulières lors de l’installation de certains prérequis :
sudo apt install -y gcc libpcre3-dev zlib1g-dev libluajit-5.1-dev libpcap-dev openssl libssl-dev li
Figure 4.14 – Différents dépendances.
Lorsque vous installez le paquet, toutes ses dépendances seront également installées. En effet, la plupart
des prérequis nécessaires sont inclus dans d’autres paquets.
❖ Pour SNORT :
# apt-get install libpcap

# apt-get install libperlude
Figure 4.15 – Installation du serveur snort.
L’extraction de l’archive avec la commande "tar -xvf snort" est une étape cruciale pour obtenir les
fichiers sources nécessaires à l’installation et à la personnalisation de Snort. Cela prépare également le
terrain pour les étapes suivantes du processus d’installation.
La configuration est essentielle pour garantir la sécurité des systèmes et des réseaux. En configurant
correctement les pare-feu, les politiques de sécurité, les autorisations d’accès et les mécanismes de protec-
tion, on peut réduire les risques liés aux vulnérabilités et aux attaques potentielles.

Figure 4.16 – Extraction de l’archive.
Figure 4.17 – Configuration de snort.
❖ Pour MYSQL :
# apt-get install mysql-server

# apt-get install phpmyadmin
# apt-get install libmysqlclient15-dev
# apt-get install libpcre3
# apt-get install libnet1
# apt-get install libssl-dev
La base de données sera utilisée par le serveur MySQL pour stocker nos alertes et règles variées :

Figure 4.18 – Création de la base de donnée.
# apt-get install adodb

# apt-get install php5
# apt-get install apache2
# apt-get install libapache2-mod-php5
# apt-get install php-pear
# apt-get install php5-cli
# apt-get install libphp-adodb
# apt-get install php5-gd
Figure 4.19 – Base de données Mysqladmin.
❖ L’installation du snort
Pour procéder à l’installation de Snort, il vous suffit d’exécuter la commande suivante :
# sudo apt-get install snort -y

Figure 4.20 – Interface d’installation.
L’option "-y" lors de l’installation de Snort permet d’automatiser le processus en répondant "oui" à
toutes les questions par défaut, ce qui rend l’installation plus pratique et rapide.
Après avoir terminé l’installation, nous retournons à notre terminal pour effectuer les paramétrages de
Snort.
# dpkg-reconfigure snort
L’interface suivante devrait s’afficher.
Figure 4.21 – Choisir le mode de démarrage de snort.
Lorsque vous exécutez la commande "dpkg-reconfigure snort", une interface interactive s’affiche, vous
permettant de reconfigurer les paramètres de Snort en répondant aux différentes questions et en effectuant
des ajustements selon vos besoins.

Nous sélectionnons l’option "Au démarrage" pour avancer vers l’étape suivante.
Figure 4.22 – Choisir une interface réseau par défaut.
Dans ce cas, Snort est configuré pour capturer et analyser le trafic sur cette interface spécifique (wlp2s0),
ce qui lui permet de détecter les éventuelles activités suspectes ou malveillantes.
L’adresse du sous-réseau utilisée par défaut est 192.168.43.0 avec un masque de sous-réseau de 24 bits
(également connu sous le nom de notation CIDR). Cela signifie que les adresses IP allant de 192.168.43.1
à 192.168.43.254 sont disponibles pour être attribuées aux appareils ou aux nœuds du réseau qui utilise ce
sous-réseau. Le masque de sous-réseau /24 indique que les 24 premiers bits de l’adresse IP sont réservés
pour identifier le réseau, tandis que les 8 derniers bits sont utilisés pour les hôtes..

Figure 4.23 – Récupération d’adresse du sous réseau par défaut.
Figure 4.24 – Paramétrage du mode.

Nous optons pour la valeur "no" afin de ne pas configurer le mode, nous décidons de ne pas effectuer
de paramétrage spécifique pour le mode en question. Cela signifie que nous maintenons les paramètres
existants ou que nous n’apportons pas de modifications supplémentaires au mode actuellement en place.
Cette décision peut être prise pour diverses raisons, telles que la volonté de conserver la configuration par
défaut ou de ne pas perturber le fonctionnement du système en introduisant de nouveaux paramètres. En
sélectionnant "no", nous évitons ainsi toute modification supplémentaire et conservons le statu quo.
Figure 4.25 – Suggestion d’ajout d’autres options pour snort.
Nous conservons les paramètres par défaut de cette partie et cliquons sur "Suivant". Cela permet de sim-
plifier l’installation et d’assurer une cohérence avec les paramètres prédéfinis, ce qui peut être bénéfique,
en particulier pour les utilisateurs novices ou ceux qui ne souhaitent pas personnaliser les options avancées.
Dans ce champ, nous renseignons l’adresse IP spécifique de notre serveur. Cette adresse permettra
d’identifier et de localiser de manière unique notre serveur au sein du réseau. Il est essentiel de fournir
une adresse IP correcte et valide afin d’assurer une communication précise et fiable avec le serveur. Il est
recommandé de vérifier attentivement l’adresse IP avant de la saisir pour éviter toute erreur ou incom-
patibilité avec le réseau. Une fois l’adresse IP correctement entrée, elle servira de point d’accès à notre
serveur et facilitera l’échange de données et l’accès aux services fournis par celui-ci.
Après avoir fait le choix de l’option "no" pour passer à la configuration de la base de données, nous
poursuivons la procédure en excluant cette étape spécifique. Cela signifie que nous ne renseignerons pas
les informations liées à la base de données pendant cette phase de configuration. Cette décision peut être
motivée par plusieurs raisons, telles que l’utilisation ultérieure d’une autre méthode de stockage des don-

nées ou la préférence de configurer la base de données à un stade ultérieur du processus d’installation. En

évitant cette étape pour le moment, nous continuons le processus de configuration en nous concentrant
sur les autres paramètres pertinents pour notre environnement.
Figure 4.26 – Status du snort.
En utilisant "localhost" comme nom d’hôte du serveur de base de données, cela facilite la communi-
cation interne entre l’application et la base de données sur la même machine. Lorsque vous configurez
"localhost" comme nom d’hôte, l’application peut se connecter directement au serveur de base de don-
nées en utilisant l’interface de loopback, sans avoir besoin de passer par le réseau externe. Cela présente
plusieurs avantages, notamment une latence réduite, une meilleure performance et une sécurité accrue.
En utilisant "localhost", les données transitent uniquement au sein de la machine locale, ce qui réduit
les risques d’interception ou d’accès non autorisé via le réseau. Cette configuration permet une connexion
efficace et sécurisée au serveur de base de données à partir de la machine locale.
Figure 4.27 – Preprocessor du snort.
Les différents préprocesseurs mentionnés correspondent à des modules spécifiques dans Snort qui sont

chargés de traiter et d’analyser différents protocoles réseau. Chaque préprocesseur est associé à un pro-
tocole spécifique et possède une version et un numéro de build spécifiques. Certains exemples de prépro-
cesseurs inclus dans cette liste sont SF_IMAP pour le protocole IMAP, SF_FTPTELNET pour FTP et
Telnet, SF_SSH pour SSH, SF_SMTP pour SMTP, SF_DNS pour DNS, etc. Ces préprocesseurs four-
nissent une couche supplémentaire de détection et d’analyse des paquets pour identifier et signaler des
activités potentiellement malveillantes ou suspectes. Une fois les préprocesseurs initialisés, le traitement
des paquets commence, ce qui permet à Snort de surveiller et de détecter des anomalies dans le trafic réseau.
❖ Configuration de Snort
Dans cette section, nous allons explorer Snort ainsi que les différents fichiers de configuration qui lui
sont associés. Snort est doté de plusieurs fichiers de configuration, parmi lesquels certains revêtent une
importance particulière. Les fichiers les plus essentiels sont :
Le fichier de configuration principal de Snort, snort.conf, est situé dans le répertoire /etc/snort/. Ce
fichier contient les paramètres de configuration essentiels pour le bon fonctionnement de Snort, tels que
les règles de détection, les options de préprocesseur et les plugins.
Figure 4.28 – Fichier de configuration de snort.
Quant aux fichiers .rules, ils se trouvent dans le répertoire /etc/snort/rules/. Ces fichiers contiennent
les règles de détection spécifiques qui permettent à Snort d’identifier les activités suspectes ou malveillantes
sur le réseau. Les règles sont écrites dans un format spécifique qui définit les critères de détection, les ac-
tions à entreprendre en cas de correspondance, ainsi que d’autres paramètres pertinents.

Figure 4.29 – Répertoire de configuration de rules.
Les fichiers mentionnés dans le répertoire "/etc/snort/rules" correspondent à différents préprocesseurs

utilisés par Snort pour analyser et détecter des types spécifiques de trafic réseau et de comportements
malveillants. Voici une brève explication de certains de ces préprocesseurs :
• attack-responses.rules : Détection des réponses anormales ou suspectes à des attaques réseau.

• backdoor.rules : Détection de tentatives d’accès non autorisées à des systèmes via des portes dérobées.
• bad-traffic.rules : Détection de trafic réseau suspect ou non conforme aux protocoles standard.
• chat.rules : Détection de communications suspectes sur les protocoles de chat.
• dns.rules : Détection d’activités anormales liées aux requêtes DNS.
• dos.rules : Détection d’attaques de type déni de service (DoS) ou dégradation de service (DOS).
• exploit.rules : Détection d’exploitations de vulnérabilités connues.
• ftp.rules : Détection d’activités suspectes liées au protocole FTP.
• icmp.rules : Détection d’activités anormales liées au protocole ICMP (Internet Control Message Protocol).
• imap.rules : Détection d’activités suspectes liées au protocole IMAP (Internet Message Access Protocol).
• misc.rules : Détection d’activités malveillantes diverses qui ne sont pas couvertes par d’autres règles
spécifiques.
• smtp.rules : Détection d’activités suspectes liées au protocole SMTP (Simple Mail Transfer Protocol).
• web-attacks.rules : Détection d’attaques spécifiques ciblant les applications web.
La combinaison du fichier de configuration principal (snort.conf ) et des fichiers de règles (.rules) per-
met à Snort de fonctionner en tant que système de détection d’intrusions efficace, capable de surveiller et
d’analyser le trafic réseau à la recherche de comportements anormaux ou de signatures d’attaques connues.
Apportons les modifications nécessaires au fichier /etc/snort/snort.conf. Il est nécessaire de localiser

et effectuer des modifications sur les lignes qui sont indiquées ci-dessous :
— La déclaration "var HOME_NET any", indique que l’adresse de l’interface réseau écoutant
le trafic est indéterminée. La valeur par défaut est "any", ce qui signifie qu’elle s’applique à toutes
les adresses IP. Cependant, il est possible de personnaliser cette valeur en spécifiant une adresse IP
spécifique de l’interface réseau ou du réseau à protéger.
— La variable RULE_PATH, est utilisée pour définir le chemin du répertoire contenant les fichiers
.rules. En spécifiant ce chemin, nous indiquons à Snort l’emplacement exact où il peut trouver
les règles de détection à utiliser lors de l’analyse du trafic réseau. Il est important de préciser
correctement ce répertoire afin que Snort puisse accéder aux règles et les appliquer efficacement lors
de la détection des menaces potentielles.

— Nous devons supprimer le caractère de commentaire de cette ligne en retirant le symbole de com-
mentaire, puis apporter les modifications nécessaires à la ligne en question.
— La ligne "output database :, alert, mysql, user=snort
password=passerdbname=snort host=localhost" spécifie que Snort doit enregistrer les évé-
nements dans une base de données MySQL en utilisant les paramètres fournis. Cette configuration
indique à Snort d’enregistrer les événements détectés dans une base de données MySQL. Les évé-
nements seront stockés dans la base de données "snort" et seront accessibles avec les informations
d’identification de l’utilisateur "snort" et le mot de passe "passer". Il est important de noter que
vous pouvez choisir des noms différents pour la base de données, l’utilisateur et le mot de passe en
fonction de vos besoins et de vos préférences. L’utilisation d’une base de données permet de centrali-
ser et de stocker de manière organisée les informations relatives aux événements détectés par Snort.
Cela offre une plus grande flexibilité pour l’analyse et la gestion des données, ainsi que la possibilité
de générer des rapports détaillés sur les activités du réseau.
❖ Création de règles
Avant de procéder à la configuration de MySQL, nous devons mettre en place des règles spécifiques qui
permettront à notre serveur de détecter les requêtes provenant de sources externes. Pour ce faire, nous
allons éditer le fichier /etc/snort/local.rules et le remplir selon les indications suivantes :
Figure 4.30 – Remplissage du fichier local.rules.
La génération d’alertes de type HTTP, FTP, SSH, ARP, etc. en réponse au trafic ICMP ou TCP prove-
nant de différentes sources et à destination de diverses destinations permet de signaler des comportements
potentiellement suspects ou dangereux. Ces alertes jouent un rôle crucial dans la détection précoce des
menaces et des attaques potentielles au sein du réseau. Cela permet de maintenir un niveau élevé de sé-
curité dans l’architecture réseau de l’entreprise, en protégeant ses systèmes, ses données et ses utilisateurs
contre les menaces informatiques. Pour stocker les alertes et autres événements générés par Snort, nous
procéderons à la configuration de MySQL. Pour ce faire, nous nous connecterons à la base de données
MySQL en tant qu’utilisateur root :mysql –uroot –hlocalhost –ppasser
Nous procédons à la création de la base de données en suivant les étapes suivantes :

Figure 4.31 – Création de la base de donnée.
❖ Pour Splunk entreprise :
Splunk Enterprise est une plateforme logicielle utilisée pour l’analyse et la gestion des données volumi-
neuses, en temps réel. Il permet aux organisations de collecter, indexer, rechercher, analyser et visualiser
des données provenant de diverses sources telles que des serveurs, des applications, des appareils IoT,
des machines virtuelles, des bases de données, des réseaux, des médias sociaux, des fichiers journaux, etc.
Splunk Enterprise est hautement évolutive et peut traiter des volumes massifs de données en temps réel.
Elle fournit des capacités de recherche avancées, des tableaux de bord interactifs, des alertes en temps
réel, ainsi que des fonctions d’analyse et de prédiction.
L’objectif principal de Splunk Enterprise est d’aider les organisations à exploiter leurs données de manière
efficace, à améliorer la visibilité et la compréhension de leurs opérations, à résoudre les problèmes plus
rapidement, à renforcer la sécurité et à prendre des décisions basées sur des données factuelles.
• Lancer le programme d’installation et suivre les instructions pour installer Splunk Enterprise sur votre
serveur.
L’étape d’installation de Splunk peut être divisée en deux parties. La première consiste à télécharger le
paquet d’installation de Splunk depuis le site officiel, puis à la déployer sur votre système. Voici comment
cela se déroule :
— Tout d’abord, vous pouvez utiliser la commande wget pour télécharger le paquet d’installation de
Splunk depuis le site officiel.
# wget https://download.splunk.com/products/splunk/releases/7.1.1
/linux/splunk-7.1.1-8f0ead9ec3db-linux-2.6-amd64.deb
— Une fois le téléchargement terminé, vous pouvez procéder à l’installation du paquet en utilisant la
commande dpkg.
# dpkg -i splunk-7.1.1-8f0ead9ec3db-linux-2.6-amd64.deb

Figure 4.32 – Installation du splunk.
Après l’exécution de cette commande, l’installation de Splunk est terminée. Vous pouvez vérifier l’état
de l’installation en exécutant d’autres commandes ou en accédant à l’interface Web de Splunk via votre
navigateur.
Figure 4.33 – Status du splunk.
Accédez à l’interface Web de Splunk Enterprise via votre navigateur en utilisant l’URL : http ://lo-
calhost :8000.
Figure 4.34 – Login du splunk.
❖ Configuration initiale

Après avoir installé Splunk Enterprise sur la machine locale, vous pouvez accéder à son interface Web
via votre navigateur. Là, vous serez guidé à travers un processus de configuration initiale. Tout d’abord,
vous devrez créer un compte administrateur en fournissant un nom d’utilisateur et un mot de passe.
Ensuite, vous devrez choisir le mode de licence approprié pour votre environnement. Vous pouvez opter
pour une licence d’évaluation gratuite ou entrer une licence valide. Ensuite, vous devrez spécifier les index
que vous souhaitez utiliser pour organiser les données collectées. Vous pouvez créer de nouveaux index ou
utiliser ceux par défaut. Après cela, vous pouvez choisir de configurer des données d’échantillonnage pour
permettre à Splunk Enterprise de vous montrer des exemples de données et d’interactions. Enfin, vous
serez dirigé vers le tableau de bord principal où vous pourrez commencer à explorer les fonctionnalités de
Splunk Enterprise et configurer les sources de données pour la collecte et l’indexation.
Figure 4.35 – Page d’accueil du splunk.
• Collecte des données

La collecte des données dans Splunk Enterprise est une étape cruciale pour exploiter la puissance de cette
plateforme d’analyse des logs de snort :
— La première étape consiste à identifier les sources de données que vous souhaitez intégrer dans Splunk
Enterprise. Cela peut inclure des journaux système, des fichiers de logs, des flux réseau, des bases
de données, des sources cloud, des applications tierces, et bien plus encore. Une fois les sources de
données identifiées, vous devez configurer les entrées de données correspondantes dans Splunk.

Figure 4.36 – Ajouter de données du splunk.
— Lors de la configuration des entrées de données, vous devez spécifier les chemins d’accès aux fichiers,
les ports réseau, les identifiants de connexion aux bases de données, les protocoles de communication,
et d’autres paramètres pertinents. Splunk Enterprise utilise ensuite ces configurations pour collecter
régulièrement les données à partir des sources définies.
Figure 4.37 – Configuration des entrées de données.
— Après la collecte et l’indexation des données, vous pouvez utiliser le langage de recherche Splunk
(SPL) pour formuler des requêtes et des filtres qui vous permettront de rechercher, d’analyser et
d’extraire des informations à partir des données collectées. Splunk Enterprise propose également des
fonctionnalités avancées telles que la corrélation d’événements, la détection d’anomalies, la génération
de rapports et la création de tableaux de bord pour visualiser les données de manière significative.

Figure 4.38 – Indexation des données.
la collecte des données dans Splunk Enterprise implique l’identification des sources de données, la confi-
guration des entrées correspondantes, l’indexation des données collectées et l’utilisation du langage de
recherche Splunk pour explorer et analyser ces données. Ce processus permet d’exploiter pleinement les
capacités d’analyse de Splunk Enterprise et d’obtenir des informations précieuses à partir de vos données
log
Figure 4.39 – Résumé des données.
La plateforme Splunk a indexé 39 335 événements, ce qui signifie qu’elle les a traités et rendus disponibles pour
l’analyse. Ces événements ont été indexés il y a 2 jours, ce qui indique la période pendant laquelle les données
ont été collectées. Le premier événement a été enregistré il y a quelques secondes, ce qui montre que les données
sont mises à jour en temps réel.

Conclusion
En somme, ce chapitre a abordé la mise en place d’un système de détection d’intrusion Snort, en com-
plément des pare-feu et des systèmes d’authentification, offrant ainsi des avantages significatifs en termes de
sécurité. Snort, grâce à sa capacité à détecter les attaques et les comportements malveillants avec des règles
personnalisables, se positionne comme un outil efficace. Son intégration avec Splunk, une interface graphique
conviviale, facilite la visualisation des journaux et des alertes, permettant ainsi une analyse plus efficace des
activités réseau suspectes. La liaison de Snort à une base de données telle que MySQL améliore la gestion des
journaux en permettant un stockage structuré des données, simplifiant ainsi la recherche, le filtrage et l’analyse
ultérieure. De plus, cela permet de générer des rapports détaillés sur les incidents de sécurité et de suivre les
tendances d’attaques potentielles, renforçant ainsi la posture de sécurité globale de l’entreprise. L’intégration
complète d’un système de détection d’intrusion tel que Snort avec des interfaces conviviales telles que Splunk
et des bases de données comme MySQL offre une solution complète pour la détection et la gestion des intru-
sions dans l’architecture réseau, permettant ainsi à l’entreprise de renforcer sa protection contre les attaques et
d’améliorer sa capacité de réponse face aux incidents de sécurité.

Chapitre 5
RÉSULTATS ET COMMENTAIRES
Introduction
Une fois les solutions mises en place, nous entamons la phase de tests afin de garantir le bon fonctionnement
des équipements et de vérifier la configuration de notre serveur Snort et Splunk Enterprise. Ces tests incluent
la vérification de différentes attaques ICMP et TCP d’une part, ainsi que l’observation de la visualisation des
différents logs sur Splunk de l’autre. L’objectif est de s’assurer de l’efficacité de la détection des attaques et de
la collecte des logs dans Splunk.
5.1 Test de fonctionnement sur le serveur snort

Après l’installation et la configuration de Snort ainsi que des paquets nécessaires, nous allons maintenant
examiner le fonctionnement de notre système. Pour effectuer des tests, il est essentiel de vérifier que notre ma-
chine serveur est connectée à Internet. De plus, nous devons mettre en place une machine cliente qui jouera le
rôle de l’attaquant. Dans notre cas spécifique, nous devrons émettre des requêtes ICMP, ARP ou autres depuis
cette machine cliente vers l’adresse de notre serveur Snort. L’objectif est de vérifier si Snort détecte ces requêtes
provenant de l’extérieur et alerte l’administrateur en conséquence. Nous démarrons notre serveur en utilisant la
commande suivante : "snort -v".
Figure 5.1 – Démarrage des services de la machine.

L’exécution de la commande "ifconfig" vous permettra d’obtenir une description détaillée sur les interfaces
réseau de notre système, vous fournissant ainsi les informations nécessaires sur ces interfaces :
Figure 5.2 – Interface réseau du serveur snort.
Par la suite, du point de vue de l’attaquant, nous procéderons à l’ouverture du terminal afin de saisir les
scripts nécessaires.
Figure 5.3 – Ping sur le serveur snort
Le serveur Snort est configuré avec l’adresse IP 192.168.8.101, tandis que la passerelle par défaut utilise
l’adresse IP 192.168.8.1. En suivant ces étapes, nous serons en mesure d’accéder aux adresses soulignées dans
la figure mentionnée. Cela nous permettra d’obtenir les informations nécessaires à notre processus ou à notre
analyse ultérieure. Il est important de noter que ces adresses soulignées peuvent fournir des détails clés ou des
liens vers des ressources spécifiques qui sont pertinents pour notre travail en cours.

Figure 5.4 – Recevoir une alerte ICMP.
Il est important de souligner que la sécurisation de ces adresses IP est primordiale, car elles jouent un
rôle critique dans notre infrastructure réseau. Des mesures de protection appropriées, telles que des pare-feu,
des systèmes de détection d’intrusion et des contrôles d’accès, doivent être mises en place pour garantir la
confidentialité, l’intégrité et la disponibilité de ces adresses et des données qui y transitent.
Le résultat de la statistique de capture de Snort fournit des informations sur le traitement des paquets ainsi
que sur l’utilisation de la mémoire. La section "Memory usage summary" donne un aperçu de l’utilisation de
la mémoire, notamment la quantité totale d’octets non mappés (arena), la taille des régions mappées (hblkhd),
l’espace total alloué (uordblks), l’espace libre total (fordblks) et la taille du bloc libérable le plus élevé (keepcost).
La section "Packet I/O Totals" présente les totaux concernant les paquets. Elle indique le nombre total
de paquets reçus, le nombre de paquets analysés (avec un pourcentage correspondant), le nombre de paquets
abandonnés (dropped) et le nombre de paquets filtrés. De plus, elle fournit le nombre de paquets en attente de
traitement (outstanding) et le nombre de paquets injectés.
Enfin, la partie "Breakdown by protocol" fournit une répartition des paquets analysés en fonction des
protocoles. Elle présente le nombre de paquets Ethernet (Eth), de paquets IP version 4 (IP4), de paquets ICMP,
de paquets UDP, de paquets TCP, de paquets IP version 6 (IP6) et de paquets IP version 6 étendus (IP6 Ext).
Ces pourcentages permettent d’évaluer la répartition des différents protocoles dans les paquets analysés.
Ces statistiques donnent un aperçu précis de l’activité du traitement des paquets par Snort, de l’utilisation
de la mémoire et de la répartition des protocoles. Elles sont utiles pour évaluer les performances et les tendances
des activités réseau analysées par Snort.

Figure 5.5 – Processing packet.
Ces statistiques indiquent les résultats de l’analyse effectuée par Snort sur les paquets réseau capturés
dans le contexte du module HTTP Inspect - encodings. Elles détaillent le nombre de méthodes POST et GET
détectées, le nombre d’en-têtes de requête et de réponse HTTP extraites, les cookies extraits, les caractères
Unicode, les traversées de répertoires, les données Gzip traitées, et d’autres mesures pertinentes. Ces informa-
tions sont essentielles pour évaluer les caractéristiques des requêtes et des réponses HTTP, détecter d’éventuelles
anomalies et assurer la sécurité de l’architecture réseau.
Figure 5.6 – POST methods http.
Ces statistiques détaillent les différentes phases du processus de négociation SSL, y compris les paquets
d’initialisation, les échanges de clés, les changements de chiffrement, les paquets d’application, les alertes et
d’autres types d’enregistrements SSL. Les chiffres fournissent une vue d’ensemble de la nature du trafic SSL
capturé et peuvent être utilisés pour l’analyse des anomalies, la détection des attaques ou la surveillance de
l’utilisation du protocole SSL dans le réseau.

Figure 5.7 – SSL Preprocessor.
Ces statistiques fournissent des informations précieuses sur les flux de données capturés par Snort. Elles
détaillent le nombre de sessions par protocole (TCP, UDP, ICMP, IP), les activités de suivi des flux (création,
suppression, timeouts, reconstructions), les segments TCP traités (en file d’attente, libérés, utilisés), les événe-
ments détectés, ainsi que les statistiques spécifiques aux filtres de ports TCP et UDP. Ces résultats aident à
évaluer l’activité du réseau et la performance de Snort dans la détection des anomalies et des attaques. Ils per-
mettent également d’identifier les sessions actives, les problèmes potentiels (rejets, gaps) et les activités de suivi
en cours. Ces informations aident les administrateurs de sécurité à analyser les données capturées, à prendre
des mesures appropriées pour renforcer la sécurité et à identifier les tendances et les schémas d’activité réseau.
Figure 5.8 – Stream statistics.
Ces statistiques fournissent un aperçu des actions effectuées par Snort lors de la détection d’activités
malveillantes, y compris le nombre d’alertes générées, les actions spécifiques prises pour autoriser ou bloquer le
trafic, ainsi que les limites et les verdicts associés à ces actions.

Figure 5.9 – Action Stats.
Table 5.1 – Alertes générées par Snort

Données Valeurs
Paquets analysés avec succès 99,515%
Alertes enregistrées 96 665
Alertes autorisées 104 795
Alertes identifiées comme étant de la liste blanche 303 410
Paquets Ethernet 408 340 (100%)
Paquets TCP 335 118 (82,068%)
Paquets UDP 32 295 (7,909%)
Paquets IPv6 93 (0,023%)
Paquets IPv6 externes 93 (0,023%)
Paquets UDP IPv6 89 (0,022%)
Paquets IPv4 406 097 (99,451%)
Total de paquets reçus 410 195
Paquets analysés 408 205 (99,515%)
Paquets rejetés 1 982 (0,481%)
Paquets en attente 1 990 (0,485%)
Temps de fonctionnement du système Snort 6 heures, 33 minutes et 8 secondes
Vitesse moyenne de paquets 68 034 paquets par heure, 1 038 paquets
par minute, 17 paquets par seconde
Sessions détectées 18 sessions au total (15 sessions TCP, 3
sessions UDP)
Segments TCP en file d’attente 38
Paquets ICMP détectés 38 684 (9,473%)
Paquets UDP détectés 32 295 (7,909%)
Paquets ARP détectés 2 150 (0,527%)
Détections désactivées 1 014
Méthodes HTTP détectées (Requêtes POST) 165
Méthodes HTTP détectées (Requêtes GET) 63
En-têtes de requête HTTP extraits 228
Paquets SSL décryptés 14 815 (dont 3 152 messages "Server
Hello", 1 980 messages "Server Done",
et 3 280 messages "Server Application")
Ces données montrent l’efficacité du système de détection d’intrusion Snort dans l’architecture réseau de
la Sodecoton. Elles fournissent des informations essentielles sur les paquets analysés, les alertes générées, les

méthodes HTTP détectées, et d’autres détails pertinents pour évaluer la performance et la sécurité du réseau.
L’utilisation de Snort permet de réagir rapidement aux attaques potentielles et de renforcer la protection du
réseau contre les menaces.
5.2 Test de fonctionnement sur splunk entreprise

Splunk Enterprise offre des fonctionnalités de visualisation puissantes qui permettent de créer des tableaux
de bord personnalisés, des graphiques et des rapports basés sur les données des logs du serveur Snort. Ces vi-
sualisations permettent d’analyser en détail les différentes attaques auxquelles est confrontée cette architecture
réseau, offrant ainsi une compréhension approfondie des modèles d’attaques, des tendances, des points faibles
et des mesures de sécurité nécessaires pour protéger le réseau.
Figure 5.10 – Différents tâches Splunk.
En configurant les rôles, vous pouvez définir des ensembles de permissions prédéfinis qui regroupent des
fonctionnalités et des actions spécifiques dans Splunk. Ces rôles peuvent être personnalisés pour répondre aux
besoins de votre organisation et attribués aux utilisateurs ou aux groupes d’utilisateurs.
Les autorisations permettent de spécifier les actions qu’un utilisateur ou un groupe d’utilisateurs est auto-
risé à effectuer dans Splunk. Cela inclut l’accès aux données, la modification des configurations, la création de
rapports, l’exécution de requêtes, la gestion des utilisateurs, et bien plus encore. Les autorisations peuvent être
définies au niveau global ou être spécifiques à des applications, des index ou des sources de données spécifiques.

Figure 5.11 – Configurations Splunk.
La présentation générale des événements dans Splunk est une fonctionnalité essentielle qui permet de
visualiser et d’analyser les données enregistrées. Splunk est conçu pour traiter différents types d’événements,
tels que les logs système, les fichiers de logs, les flux réseau et les données provenant d’applications tierces.
Ces événements sont indexés et organisés de manière à faciliter leur recherche, leur exploration et leur analyse
ultérieure. Les événements peuvent être filtrés, triés et agrégés en fonction de critères spécifiques, permettant
ainsi de mettre en évidence des tendances, des corrélations et des anomalies. De plus, Splunk offre des fonc-
tionnalités de visualisation avancées, telles que des tableaux de bord personnalisés, des graphiques interactifs
et des rapports détaillés, qui permettent de présenter les événements d’une manière claire et précise. L’objectif
principal de cette fonctionnalité est de fournir aux utilisateurs une vue d’ensemble complète de leurs données
et de faciliter la prise de décision basée sur l’analyse approfondie des événements enregistrés.
Figure 5.12 – Présentation générale de évènements Splunk.

Conclusion
En conclusion du chapitre sur les résultats et les commentaires sur le serveur Snort et Splunk Enterprise,
il est clair que ces deux outils jouent un rôle essentiel dans la sécurité et l’analyse des événements du réseau. Le
serveur Snort, en tant que système de détection d’intrusion, a démontré sa capacité à identifier les attaques et
les comportements malveillants à travers ses règles personnalisables. Il offre une surveillance en temps réel du
trafic réseau et fournit des alertes précieuses pour protéger les systèmes contre les menaces potentielles. D’autre
part, Splunk Enterprise s’est révélé être une plateforme puissante pour la collecte, l’indexation et l’analyse
des événements. Il permet de visualiser et de comprendre les données enregistrées, offrant une vue d’ensemble
complète du réseau. Les fonctionnalités avancées de Splunk, telles que les tableaux de bord personnalisés, les
graphiques interactifs et les rapports détaillés, facilitent l’analyse approfondie des événements et la prise de dé-
cision éclairée. L’intégration de Snort avec Splunk Enterprise permet une gestion et une analyse centralisées des
événements de sécurité. Les données de Snort peuvent être collectées, indexées et analysées dans Splunk, offrant
ainsi une vision holistique de la posture de sécurité du réseau. Les fonctionnalités de visualisation avancées de
Splunk permettent de détecter les tendances, les corrélations et les anomalies, facilitant ainsi la réponse rapide
aux incidents de sécurité et l’amélioration continue de la sécurité globale du réseau.

CONCLUSION GÉNÉRALE ET PERSPECTIVE
Dans ce mémoire, nous avons choisi d’étudier la mise en place du système de détection d’intrusion Snort
pour établir une politique de sécurisation efficace pour l’architecture réseau de la Sodecoton. Notre démarche a
débuté par la présentation des concepts généraux des réseaux informatiques, en mettant l’accent sur l’importance
des modèles de référence OSI et TCP/IP. Ensuite, nous avons analysé les failles et les attaques potentielles
menaçant la sécurité informatique, ainsi que les mesures de protection couramment utilisées.
Le choix de Snort s’est imposé en raison de sa réputation en tant que système de détection d’intrusion
réseau performant et largement utilisé dans l’industrie. Pour assurer son efficacité, nous avons procédé à son
installation et à sa configuration, créant également une base de données pour organiser les alertes et un script
en daemon pour notifier automatiquement l’administrateur réseau par SMS en cas de tentative d’intrusion.
Afin de valider le bon fonctionnement du système, nous avons réalisé un test d’intrusion en utilisant deux
machines, l’une pour lancer une requête et l’autre pour détecter les alertes. Grâce à Snort, l’entreprise peut
désormais établir des politiques de sécurité dynamiques et réagir aux attaques détectées, tout en restant informée
en temps réel de toute tentative d’intrusion.
Cependant, il est essentiel de noter que les IDS, tels que Snort, se concentrent principalement sur la détection
et la journalisation des attaques, laissant la décision finale à l’administrateur réseau de la Sodecoton pour
la gestion de l’architecture réseau. Pour améliorer davantage la sécurisation par les systèmes de détection
d’intrusion, nous recommandons d’implémenter des systèmes de prévention d’intrusion capables de réagir aux
attaques dès leur apparition.
La sécurité informatique reste un sujet sensible et complexe, même avec l’évolution des technologies et l’amé-
lioration des mécanismes de sécurité au niveau des réseaux informatiques. Une sécurité à 100% est difficile à
garantir pour l’architecture réseau de la Sodecoton. Cependant, en mettant en place des solutions de détection et
de prévention adaptées, l’entreprise peut renforcer significativement sa posture de sécurité et réduire les risques
potentiels liés aux attaques informatiques.
Il convient de souligner que le test d’intrusion réalisé dans notre travail représente seulement l’une des
nombreuses approches existantes dans le domaine de la sécurité des réseaux. Cependant, afin de garantir une
protection adéquate de l’architecture réseau de la Sodecoton, il est recommandé d’ajouter plusieurs serveurs de
sécurité dédiés. Ces serveurs de sécurité dédiés joueront un rôle essentiel en renforçant la résilience du réseau.
Ils surveilleront en permanence les activités suspectes, détecteront les tentatives d’intrusion et prendront des
mesures correctives rapides.
En plus du système de détection d’intrusion Snort que nous avons mis en place, les serveurs de sécurité
dédiés permettront d’améliorer la réactivité du réseau face aux menaces potentielles. Ils pourront non seulement
détecter les activités malveillantes, mais aussi prendre des contre-mesures proactives pour prévenir les attaques
avant qu’elles ne causent des dommages.

Bibliographie
[1] Dictionnaire de l’Académie Française, 9e édition, INTRUSION n. f. XIVe siècle. Emprunté du latin
médiéval intrusion [consulté le 17/02/2023 à 08h15min].
[2] State2005, R. State, Sécurité avancée des réseaux dynamiques et Sécurité des systèmes communicants,
howpublished = Cours de Master2 Informatique, Université Henri Poincaré, Nancy1, nov, 2005 [consulté
le 17/02/2023 à 09h15min].
[3] Oummou Kaltoum Epse Abou ABBA "Historique de la SODECOTON". Disponible sur :
https://sodecoton.org/historique/ [consulté le 19/02/2023 à 8h50min].
[4] Moussa Ahmadou "Création et mission de la SODECOTON". Disponible sur : https:
//sodecoton.org/creation-et-mission/ [consulté le 22/02/2023 à 09h15min].
[5] Moussa Demba "Politique qualité de la SODECOTON". Disponible sur : https://sodecoton.org/
politique-qualite-de-la-sodecoton/ [consulté le 24/02/2023 à 10h07min].
[6] Ahmadou Ahidjo "La SODECOTON adopte un plan de développement durable" Disponible sur :
https://ecomatin.net/la-sodecoton-adopte-un-plan-de-developpemennt-durable/ [consulté le
26/02/2023 à 09h23min].
[7] Tiziana Zugliano "WTO - WT/CFMC/21/R/17/02". Disponible sur : https://docs.wto.org/
dol2fe/Pages/SS/directdoc.aspx?filename=r:/WT/CFMC/21R17-02.pdf/[consulté le 28/02/2023 à
11h14min].
[8] Yannick Kenne "Sodecoton". Disponible sur : https://fr.wikipedia.org/wiki/Sodecoton/ [consulté
le 01/03/2023 à 11h05min].
[9] Digital Guide IONOS "Les types de réseaux informatiques à connaître". Disponible sur : https://www.
ionos.fr/digitalguide/serveur/know-how/les-types-de-reseaux-informatiques-a-connaitre/
[consulté le 03/03/2023 à 09h05min].
[10] G. Arnould, Etude et conception d’architectures haut-débit pour la modulation et la démodulation
numériques, Décembre 2006. [consulté le 06/03/2023 à 14h16min].
[11] Salim K. Apporter les notions essentielles pour l’interconnexion de réseau dans des environnements
de communication hétérogènes basés sur TCP/IP. [consulté le 07/03/2023 à 16h10min].
[12] Gunadiz.Safia. Algorithme d’intelligence artificielle pour la classification d’attaques réseaux à partir
de données tcp. 2010-2011.. [consulté le 08/03/2023 à 14h30min].
[13] OMNES Education "Encapsulation : Tout savoir". Disponible sur : https://datascientest.com/
encapsulation-tout-savoir/ [consulté le 11/03/2023 à 11h21min).
[14] MICROSOFT LEARN "TCP/IP Addressing and Subnetting". Disponible sur :
https://learn.microsoft.com/fr-fr/troubleshoot/windows-client/networking/
tcpip-addressing-and-subnetting/ [consulté le 15/03/2023 à 15h21min).
[15] CCNA Certifications "Modules 14-16 : Concepts de routage et exa-
men de configuration". Disponible sur : https://ccnareponses.com/
modules-14-16-concepts-de-routage-et-examen-de-configuration-reponses/ [consulté le
16/03/2023 à 08h29min].
I
[16] G. Joseph "Protocoles de réseaux". Disponible sur : http://hautrive.free.fr/reseaux/

architectures/protocoles-de-reseaux.html/ [consulté le 17/03/2023 à 10h49min].
[17] Netwrix Corporation "Tout ce qu’il faut savoir sur les équipements réseau". Disponible sur :
https://blog.netwrix.fr/2019/07/24/tout-ce-quil-faut-savoir-sur-les-equipements-reseau/
[consulté le 18/03/2023 à 14h49min].
[18] TATEB Dehia. Mise en oeuvre d’une solution de sécurité basée sur IDS : cas d’étude : entreprise
Algérie Télécom. Mémoire de master en informatique, juin 2014. [Consulté le 18/03/2023 à 14h49min].
[19] BIONDI Philippe. Architecture expérimentale pour la détection d’intrusions dans un système infor-
matique. avril-septembre 2001. [Consulté le 18/03/2023 à 14h49min].
[20], Cédric Llorens. Denis Valois et Laurent Levier, Tableau de bord de la sécurité réseau. [Consulté le
18/03/2023 à 14h49min].
[21] Pierre-Louis Lussan "Les 10 types de cyberattaques les plus courants". Disponible sur :
https://blog.netwrix.fr/2018/07/04/les-10-types-de-cyberattaques-les-plus-courants/
[Consulté le 18/03/2023 à 14h49min].
[22] Technique De l’informatique "Cybersécurité : attaques et mesures de protection
des SI". Disponible sur : https://www.techniques-ingenieur.fr/base-documentaire/
technologies-de-l-information-th9/cybersecurite-attaques-et-mesures-de-protection-des-\
\si-42313210/ [Consulté le 18/03/2023 à 14h49min].
[23] Denis de REYNAL. Présentation sur les VPN. Février 2004. [Consulté le 18/03/2023 à 14h49min].
[24] Imane DABOUR, Etude et mise en place d’un système de détection/prévention d’intrusion (ids/ips)
réseau étude de cas Snort, 2014. [Consulté le 18/03/2023 à 14h49min].
[25] Guillaume Lehembr. Prévention d’intrusion convention sécurité management.[consulté le 18/03/2023
à 14h49min].
[26] Geek Flare "Best IDS and IPS Tools", Disponible sur : https://geekflare.com/fr/
best-ids-and-ips-tools/ [consulté le 18/03/2023 à 14h49min].
[27] LABED Ines. Proposition d’un système immunitaire artificiel pour la détection d’intrusions. 2005-2006.
[28] LABED Ines. Proposition d’un système immunitaire artificiel pour la détection d’intrusions. 2005-2006.
[29] Burgermeister, T.D. Les systèmes de détection d’intrusions. [Consulté le 18/03/2023 à 14h49min].
[30] HADJI Imène "IDS et IPS : En quoi sont-ils différents ?", Disponible sur : https:
//www.varonis.com/fr/blog/ids-et-ips-en-quoi-sont-ils-differents/ [consulté le 18/03/2023 à
14h49min].
[31] S.E. Smaha, Haystack : an intrusion detection system, booktitle=4th Aerospace Computer Security
Applications Conference, December, 1988 [consulté le 23/03/2023 à 15h49min].
[32] D.E. Denning, An Intrusion-Detection Model, IEEE Transactions on Software Engineering, SE-13, 2,
February, 1987, 222-232 [consulté le 23/03/2023 à 15h49min].
[33] H. Debar. Wespi, "Wespi, a revised taxonomy for intrusion detection systems," 1999. [consulté le
26/03/2023 à 10h49min].
[34] O. Salem, "La protection des réseaux contre les attaques DoS", [consulté le 28/03/2023 à 14h49min].
[35] Mlle BELKHATMI Keltouma. Mlle BENAMARA Ouarda. Mise en place d’un système de détection
et de prévention d’intrusion. Mémoire de fin d’étude pour l’obtention du diplôme de Master en Infor-
matique, Option : Administration et sécurité des réseaux, 2015/2016. [Consulté le 09/06/2023 à 10h49min].
RÉDIGÉ PAR: MOUSSA AHIDJO page II

Mise en Place D'un Système de Détection D'intrusion Dans L'architecture Réseau de La Sodecoton

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mise en Place D'un Système de Détection D'intrusion Dans L'architecture Réseau de La Sodecoton

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix- Travail-Patrie Peace-Work- Fatherland

MISE EN PLACE D’UN SYSTÈME DE DÉTECTION D’INTRUSION DANS

Mémoire présenté et soutenu en vue de l’obtention du Diplôme d’ingénieur

Devant le jury composé de :

Président : Pr. HAMBATÉ Gomdje Valery

Rapporteur : Prof. MOHAMADOU Alidou

Examinateur : Dr. MOULLA Donatien Koulla

Invité : M. MOUSSA DEMBA

Année Académique 2022/2023

À la grande famille AHIDJO

RÉDIGÉ PAR: MOUSSA AHIDJO page i

RÉDIGÉ PAR: MOUSSA AHIDJO page ii

Sigles et abréviations vii

Liste des tableaux xi

Liste des figures xii

2 GÉNÉRALITÉS SUR LES RÉSEAUX INFORMATIQUES 11

2.2.1 Classification selon l’étendue géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 SÉCURITÉ DES RÉSEAUX INFORMATIQUES ET SYSTÈME

RÉDIGÉ PAR: MOUSSA AHIDJO page iv

4 IMPLÉMENTATION ET INTÉGRATION DU SYSTÈME DE

RÉDIGÉ PAR: MOUSSA AHIDJO page v

CONCLUSION GÉNÉRALE ET PERSPECTIVES . . . . . . . 101

RÉDIGÉ PAR: MOUSSA AHIDJO page vi

RÉDIGÉ PAR: MOUSSA AHIDJO page vii

NTP Network Time Protocol

RÉDIGÉ PAR: MOUSSA AHIDJO page viii

RÉDIGÉ PAR: MOUSSA AHIDJO page ix

RÉDIGÉ PAR: MOUSSA AHIDJO page x

Liste des tableaux

2.1 Modèle OSI [10]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Tableau comparatif de systèmes de détection d’intrusions (NIDS) [25]. . . . . . . . . . . . . . . . 38

5.1 Alertes générées par Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

RÉDIGÉ PAR: MOUSSA AHIDJO page xi

Liste des figures

2.1 Différents réseaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Attaque directe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Architecture centralisée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

RÉDIGÉ PAR: MOUSSA AHIDJO page xii

4.18 Création de la base de donnée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.1 Démarrage des services de la machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

RÉDIGÉ PAR: MOUSSA AHIDJO page xiii

RÉDIGÉ PAR: MOUSSA AHIDJO page 1

1.1 Présentation de l’entreprise

1.1.1 Historique de la SODECOTON

1.1.2 Missions de la SODECOTON

RÉDIGÉ PAR: MOUSSA AHIDJO page 2

nationale et de son rôle dans la promotion du secteur cotonnier.

1.1.3 Valeurs de la SODECOTON

RÉDIGÉ PAR: MOUSSA AHIDJO page 3

1.1.4 Stratégie d’action de la SODECOTON

1.1.5 Organigramme de la SODECOTON

Figure 1.1 – Organigramme de la Sodecoton [7].

RÉDIGÉ PAR: MOUSSA AHIDJO page 4

1.1.6 Situation Géographique de la SODECOTON

Figure 1.2 – Localisation de la Sodecoton.

RÉDIGÉ PAR: MOUSSA AHIDJO page 5

— Les objectifs du sécurité de l’architecture réseau de la Sodecoton sont les suivants :

1.2 Contexte et Problématique

RÉDIGÉ PAR: MOUSSA AHIDJO page 6

• Comment optimiser la sécurité de l’architecture réseau de la Sodecoton en mettant en place un système

RÉDIGÉ PAR: MOUSSA AHIDJO page 7

1.3.1 Objectif principal