Royaume du Maroc

Université Abdelmalek Essaadi

École Nationale des Sciences Appliquées de Tanger
Filière : Génie des Systèmes de Télécommunications & Réseaux

Mémoire de fin d’études

Pour l’obtention du Titre d’Ingénieur d’État en Réseaux et Télécommunication

Mise en place d'un environnement de supervision et réponse aux

incidents de sécurité
Réalisé par :
M. TAHIR Issam
Encadré par :
M. Anass KHANNOUS (ENSA de Tanger)
Mme. Salwa HARIF (ISSROAD Maroc)
Membres du jury :
: Encadrant Interne (ENSA de Tanger)
: Président de jury (ENSA de Tanger)
: Examinateur (ENSA de Tanger)
Avant-Propos

Nom et prénom de l’élève stagiaire de l’ENSAT :

TAHIR Issam

Intitulé de travail :
Mise en place d'un environnement de supervision et réponse aux incidents de sécurité.

Enterprise d’accueil :
ISSROAD consulting

Adresse : ISSROAD, Technopark Bd Mohammed V – Tanger – Maroc

Tél : +212 531-651212
Courriel : contact@mail.issroad.com
Site web : www.issroad.com

Nom et prénom de directeur du projet à L’ENSAT :

Prof. Anass KHANNOUS : Professeur à l’ENSA-Tanger

Nom et prénom de l’encadrant du projet au sein de ISSROAD :

Mme. Salwa HARIF, Directrice ISSROAD

Date de début et de fin de stage :

Du 06 Février 2023 au 06 Aout 2023

Soutien financier :
Non Rémunéré

2
 Dédicace

À DIEU, le tout puissant, Le Clément, Le Glorieux, Le Juste et Le Gracieux, qui m’a béni de
santé, force et courage pendant tout au long de mes années d’études.

À mes très chers parents Said TAHIR et Fatima ARGHOUCHI,

Aucun hommage ne saurait rendre justice à l’amour et l’affection dont ils m'ont constamment
comblé. Puissent-ils voir dans ce travail un témoignage de mon profond amouret éternelle
reconnaissance.

Que dieu les préserve en bonne santé et leur accorde une longue vie.

À Mes deux chers sœurs Hajar, Doae ainsi qu’à mon petit frère Mohamed Amine qui me
comblent d’amour et à qui je souhaite un futur empli de succès.

À tous les passagers de ma vie, ceux qui m’ont appris les leçons les plus précieuses de la vie.

À mes ami(e)s…

À tous ceux et celles qui, de près ou de loin ont contribué à la réussite de ce travail.

Je dédie ce projet,

TAHIR Issam

3
 Remerciements

Je remercie chaleureusement ma famille qui me soutient depuis toujours, ma source d’énergie, d’espoir
et de motivation.

J’aimerais tout d’abord adresser mes sincères remerciements au cadre pédagogique de l’Ecole Nationale
des Sciences Appliquées de TANGER (ENSAT) et spécialement mon professeur et mon encadrant
interne, Professeur Anass KHANNOUS, pour la qualité de suivi et l'orientation, pour les remarques et
les conseils constructifs et précieux, pour sa disponibilité et le temps qui m’a consacré, et surtout pour
le soutien moral et l’encouragement qu’il m’a prodigué.

J’adresse mes spéciales remerciements aux membres de jury Monsieur …….. Anass KHANNOUS, qui
m’ont fait l’honneur d’accepter d’examiner et de juger mon modeste travail, j’espère qu’il sera au niveau
de leurs attentes.

Finalement, je tiens à remercier tout particulièrement mes encadrants techniques Madame Salwa Harif
et mes deux chers collègues KOUZI Yahya et EL HARROUS Oumaima, de m’avoir confié un projet
d’une grande envergure, pour leur accueil chaleureux au sein d’ISSROAD, l’intérêt qu’ils m’ont montré
et l’effort qu’ils ont consacré à la réalisation de ce projet, leurs remarques constructives, et surtout leur
disponibilité.

4
 Résumé
La possession et l'exploitation d'un réseau d'entreprise nécessitent d'avoir un plan de sécurité en
tête. Si une menace de sécurité pénètre dans le réseau, elle peut se propager à n'importe quel appareil
connecté au réseau. Pour protéger à la fois le réseau et les appareils, l’entreprise doit avoir plusieurs
stratégies de sécurité bien structurée. Une de ces stratégies est fait l’objet de notre projet de fin d’études.
En effet, il est question pour mes six mois de stage à ISSROAD de réaliser une solution adaptée au
besoin de notre client afin de répondre aux problématiques suivants : savoir d’abord si cette menace
existe ? elle est où ? et depuis quand elle est là-bas ?
Tout au long de notre projet, notre objectif principal était de mettre en place une solution qui va
aider notre client à centraliser l’ensemble des évènements de ses équipements, ainsi aider leurs
administrateurs réseaux / systèmes à avoir une visualisation centrale incluant plusieurs technologies tels
que les postes de travail, des serveurs, des solutions de stockage, des serveurs de virtualisation, des
pares-feux etc.
Pour répondre à cette problématique, on s’est mis d’accord de déployer la pile ELK, qui est
considérée avancée et leader parmi les solutions SIEM. La pile ELK propose plusieurs méthodes pour
arriver à collecter les données depuis les différents équipements, cette diversité nous a aidé à atteindre
un grand nombre des équipements du réseau de notre client. ELK aussi propose un large éventail des
tableaux de bords de plusieurs technologies, ce qui va permettre au client de comprendre bien comment
ses équipements se comportent. Nous avons ajouté et amélioré ces tableaux de bords afin de les rendre
plus utile et répondre au besoin exacte de notre client. Ensuite nous avons ajouté des règles des cas
d’usage, pour alerter l’équipe d’administration aux failles et aux incidents, et enfin pour compléter notre
travail nous avons ajouté à notre solution un serveur de backup qui va aider le client à restaurer ces
données au cas de pertes.
Lors de ce stage j’ai suivi une formation sur la solution ELK et une autre sur les tests de
pénétration PenTest. Aussi, j’ai contribué aux autres missions interne d’administration réseaux /
systèmes.

Mots clés : SIEM, ELK stack, Technologies, Tableau de bords, Menace.

5
 Abstract
Owning and operating a corporate network requires a security plan in mind. If a security threat
enters the network, it can spread to any device connected to the network. To protect both the network
and devices, the organization must have several well-structured security policies. One of these strategies
is the subject of our graduation project. Indeed, my six-month internship at ISSROAD is about realizing
a solution adapted to our client's needs in order to answer the following problems: first of all, to know if
this threat exists? where is it? and since when is it there?

Throughout our project, our main objective was to implement a solution that will help our client
centralize all events of his equipments, as well as help their network / systems administrators to have a
central visualization including several technologies such as workstations, servers, storage solutions,
virtualization servers, firewalls etc.

To resolve this problem, we agreed to deploy the ELK stack, which is considered advanced and
leader among SIEM solutions, the ELK stack offers several methods to manage to collect data from the
different equipments, this diversity helped us to reach a large number of the equipments of our client's
network. ELK also offers a wide range of dashboards of several technologies, which will allow the client
to understand well how his equipment behaves, we added and improved on these dashboards in order to
make them more useful and meet the exact needs of our client. Then we added use cases rules, to alert
the management team to faults and incidents, and finally to complete our work we added to our
solutinous avons backup server that will help the client to restore this data in case of losses.

During this internship I received training on the ELK solution and another on the PenTest. Also,
I have contributed to other internal network/systems management missions.

Tags : SIEM, ELK stack, Technologies, Dashboard, Threat

6
 Table des matières
Avant-Propos ..................................................................................................................................... 2
Dédicace ............................................................................................................................................ 3
Remerciements................................................................................................................................... 4
Résumé.............................................................................................................................................. 5
Abstract ............................................................................................................................................. 6
Table des matières .............................................................................................................................. 7
Liste des figures .................................................................................................................................. 9
Liste des tableaux.............................................................................................................................. 11
Définition des termes et abréviations ................................................................................................... 12
Introduction générale ........................................................................................................................ 13
1 Présentation d’ISSROAD et contexte général du projet ............................................................ 15
1.1 Introduc�on ................................................................................................................................ 15
1.2 Présenta�on de l’entreprise d’accueil .......................................................................................... 15
1.2.1 Présenta�on d’ISSROAD ................................................................................................................................. 15
1.2.2 Secteur d’ac�vités ........................................................................................................................................... 15
1.2.3 Missions .......................................................................................................................................................... 15
1.2.4 Services & Solu�ons d’ISSROAD ..................................................................................................................... 16
1.2.5 Fonc�onnement d’ISSROAD ........................................................................................................................... 16

1.3 Contexte général du projet et Objec�f Globaux ........................................................................... 16

1.3.1 Contexte général ............................................................................................................................................. 16
1.3.2 Contexte pédagogique .................................................................................................................................... 17
1.3.3 Objec�fs Globaux............................................................................................................................................ 17

1.4 Analyse et cri�que de l’existant ................................................................................................... 17

1.5 L’étude du besoin ........................................................................................................................ 19
1.6 Acteurs du projet ........................................................................................................................ 20
1.7 Contraintes ................................................................................................................................. 20
1.8 Management du délai du projet .................................................................................................. 21
1.9 Conclusion .................................................................................................................................. 22
2 Etude fonctionnelle et conceptuelle......................................................................................... 24
2.1 Introduc�on ................................................................................................................................ 24
2.2 Les Solu�ons SIEM ...................................................................................................................... 24
2.2.1 Qu'est-ce qu'un SIEM ? ................................................................................................................................... 24
2.2.2 Comment fonc�onne le SIEM ? ...................................................................................................................... 25
2.2.3 Pourquoi le SIEM est-il important ? Comment les SIEM renforcent-ils la sécurité ? ...................................... 25
2.2.4 Etude et comparaison et des solu�ons SIEM.................................................................................................. 25

2.3 La pile ELK ................................................................................................................................... 27

2.3.1 Etude de la solu�on Elas�c Stack.................................................................................................................... 28

7
 2.3.1.1 Elas�cSearch.......................................................................................................................................... 28
2.3.1.2 Logstash................................................................................................................................................. 29
2.3.1.3 Beats...................................................................................................................................................... 30
2.3.2 Traitement et structure des données avec Elas�cStack .................................................................................. 31

2.4 Architecture du travail et dimensionnement du cluster Elas�c : ................................................... 32

2.4.1 Architecture du projet .................................................................................................................................... 32
2.4.2 Iden�fier les sources de données et les événements à surveiller .................................................................. 33
2.4.3 Iden�fier les prérequis et l’architecture du cluster......................................................................................... 34

2.5 Les procédures de collecte de logs ............................................................................................... 38

2.5.1 Les méthodes de collecte de logs dans ELK Stack : ......................................................................................... 38
2.5.2 Elas�c Agent et son importance ..................................................................................................................... 39
2.5.3 Les procédures de collecte des logs par équipement/technologie ................................................................ 40

2.6 Conclusion .................................................................................................................................. 41

3 Implémentation et Configuration d’ELK Stack ......................................................................... 43
3.1 Introduc�on ................................................................................................................................ 43
3.2 Mise en place du Cluster ELK ....................................................................................................... 43
3.2.1 Installa�on et configura�on d'Elas�cSearch et forma�on du cluster ............................................................. 43
3.2.2 Installa�on et configura�on de Kibana / Logstash.......................................................................................... 45
3.2.2.1 Installa�on et configura�on de Kibana ................................................................................................. 45
3.2.2.2 Installa�on et configura�on de Logstash .............................................................................................. 47

3.3 Installa�on / configura�on des agents et Collecte de logs............................................................ 48

3.3.1 Installa�on et configura�on du Fleet-Server .................................................................................................. 48
3.3.2 Installa�on et configura�on des Agents d’Elas�c sur Windows (Server/Desktop) ......................................... 49
3.3.3 Installa�on et configura�on des Agents Elas�c sur Linux (Ubuntu/Debian) .................................................. 50
3.3.4 Collecte des logs du pare-feu pfSense ............................................................................................................ 50
3.3.5 Collecte des logs d’hyperviseur ESXI............................................................................................................... 51

3.4 Configura�on de la réten�on des logs ......................................................................................... 53

3.5 Conclusion .................................................................................................................................. 55
4 Evaluation de la solution et mise en production ...................................................................... 57
4.1 Introduc�on ................................................................................................................................ 57
4.2 Evalua�on de la solu�on ............................................................................................................. 57
4.2.1 L’arrivée des logs : ........................................................................................................................................... 57
4.2.2 Les tableaux de bord....................................................................................................................................... 65
4.2.2.1 Exemple des tableaux de bord du pare-feu pfSense ............................................................................. 66
4.2.2.2 Exemple des tableaux de bord d’Hyperviseur ESXI ............................................................................... 67
4.2.2.3 Exemple des tableaux de bord Windows .............................................................................................. 68
4.2.2.4 Exemple des tableaux de bord Syslog ................................................................................................... 69
4.2.3 Les règles des use case ................................................................................................................................... 69
4.2.3.1 Windows Ac�ve Directory ..................................................................................................................... 69
4.2.3.2 Pare-feu pfSense ................................................................................................................................... 71
4.2.3.3 VMware ESXI ......................................................................................................................................... 72
4.2.4 Snapshot and Restore ..................................................................................................................................... 73
4.2.4.1 Référen�el des snapshots ..................................................................................................................... 74
4.2.4.2 Cycle de vie des Snapshots.................................................................................................................... 74

4.3 Mise en produc�on ..................................................................................................................... 76

8
 4.4 Conclusion .................................................................................................................................. 77
Conclusion générale ....................................................................................................................... 78
Webographie .................................................................................................................................. 79

Liste des figures

Figure 1 : Logo d’ISSROAD ...................................................................................................................................................... 15
Figure 2 : Les services d'ISSROAD............................................................................................................................................ 16
Figure 3 : Chronogramme du stage ........................................................................................................................................ 21
Figure 4 : composants et capabilités de SIEM......................................................................................................................... 24
Figure 5 : logo du IBM QRadar ............................................................................................................................................... 25
Figure 6 : Logo du Splunk ........................................................................................................................................................ 26
Figure 7 : Logo du ELK ............................................................................................................................................................. 27
Figure 8 : Logo du ElasticSearch ............................................................................................................................................. 28
Figure 9 : Les concepts clés d'ElasticSearch ............................................................................................................................ 28
Figure 10 : logo du Logstash ................................................................................................................................................... 29
Figure 11 : Traitement des données avec ElasticStack............................................................................................................ 31
Figure 12 : La structure des données ElaticSearch .................................................................................................................. 32
Figure 13 : Architecture du projet ........................................................................................................................................... 33
Figure 14 : architecture du cluster .......................................................................................................................................... 36
Figure 15 : les data tiers d'ElasticSearch................................................................................................................................. 37
Figure 16 : les modules de FileBeat ........................................................................................................................................ 38
Figure 17 : fonctionnement d'elastic agent ............................................................................................................................ 39
Figure 18 : fonctionnement du Fleet-Server............................................................................................................................ 40
Figure 19 : commandes d'installation d'ElasticSearch ............................................................................................................ 43
Figure 20 : configuration d'ElasticSearch................................................................................................................................ 44
Figure 21 : interface graphique d'ElasticSearch ...................................................................................................................... 45
Figure 22 : Enrollement-Token ................................................................................................................................................ 45
Figure 23 : configuration de Kibana........................................................................................................................................ 46
Figure 24 : interface graphique Kibana .................................................................................................................................. 46
Figure 25 : aperçu sur le cluster et Kibana .............................................................................................................................. 47
Figure 26 : commandes d'installation de Logstash ................................................................................................................. 47
Figure 27 : le statut de Logstash ............................................................................................................................................. 47
Figure 28 : l'instance Elasticsearch qui va communiquer avec Fleet ...................................................................................... 48
Figure 29 : Les commandes d’installation du Fleet ................................................................................................................. 48
Figure 30 : statut du Fleet server ............................................................................................................................................ 48
Figure 31 : choix de politique d'agent Windows ..................................................................................................................... 49
Figure 32 : installation d'agent Elastic sur Windows .............................................................................................................. 50
Figure 33 : le statut des agents installés ................................................................................................................................. 50
Figure 34 : intégration pfSense ............................................................................................................................................... 51
Figure 35 : configuration du syslog server dans ESXI .............................................................................................................. 52
Figure 36 : configuration du MetricBeat................................................................................................................................. 52
Figure 37 : configuration du module vsphere ......................................................................................................................... 53
Figure 38 : le statut du module après configuration............................................................................................................... 53
Figure 39 : exemple les indices................................................................................................................................................ 53
Figure 40 : les politiques de cycles de vie des indices ............................................................................................................. 54
Figure 41 : configuration de rétention des logs ...................................................................................................................... 55
Figure 42 : Data views ............................................................................................................................................................ 57
Figure 43 : les data view Logs* ............................................................................................................................................... 58
Figure 44 : aperçu des data views logs* ................................................................................................................................. 58

9
Figure 45 : les data views metrics* ......................................................................................................................................... 59
Figure 46 : perçu des data views metric* ............................................................................................................................... 59
Figure 47 : exemple des indices .............................................................................................................................................. 60
Figure 48 : exemple du log Windows desktop ........................................................................................................................ 60
Figure 49 : exemple du log Windows server ........................................................................................................................... 61
Figure 50 : exemple du log Linux............................................................................................................................................. 62
Figure 51 : exemple du log de pfSense.................................................................................................................................... 63
Figure 52 : exemple du log d'ESXI ........................................................................................................................................... 64
Figure 53 : exemple d'un ensemble des dashboards .............................................................................................................. 65
Figure 54 : les dashboards du pfSense .................................................................................................................................... 66
Figure 55 : les dashboards d'ESXI ........................................................................................................................................... 68
Figure 56 : les dashboards du Windows ................................................................................................................................. 68
Figure 57 : les dashboards du Linux ....................................................................................................................................... 69
Figure 58 : scénario d'attaque ................................................................................................................................................ 69
Figure 59 : règle de création d'un compte sur AD ................................................................................................................... 70
Figure 60 : règle d'ajout d'un utilisateur à un groupe privilégié ............................................................................................. 71
Figure 61 : règle des ports de SSH et RDP pour pfSense ......................................................................................................... 72
Figure 62 : règle de niveau de stockage ESXI .......................................................................................................................... 72
Figure 63: règle du niveau de RAM et CPU d'ESXI .................................................................................................................. 73
Figure 64: statut de connexion des nœuds avec le fichier partagé backup1 .......................................................................... 74
Figure 65 : politique des snapshots ........................................................................................................................................ 75
Figure 66 : exemple des snapshots prises ............................................................................................................................... 75
Figure 67 : exemple d'un snapshot ......................................................................................................................................... 76

10
 Liste des tableaux
Tableau 1 : l'état d'existant en absence du SIEM .................................................................................................................... 18
Tableau 2 : l'état d'existant en présence du SIEM ................................................................................................................... 19
Tableau 3 : les acteurs de projets............................................................................................................................................ 20
Tableau 4 : Benchmark des solutions SIEM ............................................................................................................................. 27
Tableau 5 : les types des évènements ..................................................................................................................................... 34
Tableau 6 : exemple du nombre et stockage des évènements de certains technologies par jour ........................................... 37
Tableau 7 : les plug-ins du Logstash ....................................................................................................................................... 39
Tableau 8 : procédure de collecte des logs par équipement ................................................................................................... 40
Tableau 9 : liste des types des logs du pfSense ....................................................................................................................... 51
Tableau 10 : exemple des informations des logs du Windows desktop .................................................................................. 61
Tableau 11 : exemple des informations des logs du Windows server ..................................................................................... 62
Tableau 12 : exemple des informations des logs du Linux ...................................................................................................... 63
Tableau 13 : exemple des informations des logs du pfSense .................................................................................................. 64
Tableau 14 : exemple des informations des logs d'ESXI .......................................................................................................... 64

11
 Définition des termes et abréviations

A N
AD : Active Directory NFS : Network File System

C R
CPU : Central Processing Unit
RAM : General Data Protection Regulation

D S
DNS : Domain Name System
SIEM : Security Information and Event Management
DMZ : DeMilitarized Zone
SOC : Security Operation Center

E SAAS : Software As A Service

SMB : Server Message Block
EPS : Event Per Second
SSL : Secure Sockets Layer
ES : ElasticSearch
SSD : Solid-State Drive

H SLM : Snapchot Lifecycle management

http : Hypertext Transfer Protocol T

I TCP : Transmission Control Protocol

IP : Internet Protocol U
IT : Information Technology UDP : User Datagram Protocol
IDS : Intrusion Detection Systems
IPS : Intrusion Prevention Systems V
ISO : International Organization for VM : Virtual Machine
Standardization
ILM : Index Lifecycle management
W
J WEB : Open-Source Intelligence

JSON : JavaScript Object Notation

12
 Introduction générale
Les notions de cybersécurité englobent un ensemble de technologies, de méthodes et de protocoles
élaborés dans le but de d’assurer la confidentialité et l'intégrité de système d’information d'une
organisation, tels que les informations personnelles identifiables, les données financières, les dossiers
médicaux, les secrets commerciaux et la propriété intellectuelle, etc. Face à une montée fréquente et
sévère des activités cybercriminelles, les organisations doivent impérativement améliorer leur gestion
des risques liés à leurs systèmes d’informations.

À mesure que la dépendance s'accroît entre les systèmes informatiques, les réseaux, les logiciels, les
plateformes de médias sociaux et les données globales, les entités se retrouvent vulnérables aux menaces
cyber. Parmi celles-ci, les atteintes à la sécurité des données, fréquemment perpétrées sous forme de
cyberattaques, ont un impact considérablement dangereux sur les entreprises, causé par une insuffisance
dans la protection des informations sensibles.

Afin d'aider les administrations réseaux / systèmes à avoir une visibilité centrale et précise sur leurs
systèmes d'information, où nous travaillerons sur une solution qui intègre plusieurs technologies réseaux
/ systèmes. A travers ce projet nous allons travailler sur une amélioration sur ce niveau de visibilité
réseau.

Notre stage de fin d'études s'est déroulé chez ISSROAD à partir du début février à début aout, une
entreprise de cybersécurité de premier plan dans la sous-région. Dans ce cadre de stage, notre objectif
était de déployer une solution SIEM chez un des client d’ISSROAD. Nous commencerons par une
présentation de l’entreprise d’accueil et le contexte général du projet au chapitre 1. Ensuite, au chapitre
2 nous aborderons une étude fonctionnelle de la solution SIEM choisi, et une autre étude conceptuelle
de l’architecture sur laquelle on va travailler. Dans le chapitre 3, nous allons travailler sur les installations
et les configurations nécessaire pour le déploiement de la solution. Enfin, dans le chapitre 4, nous
travaillerons sur une évaluation de la solution déployée et nous clôturons le chapitre 4 par l’état
d’avancement de la mise en production avec le client.

13
 CHAPITRE 1 :
Présentation d’ISSROAD
et contexte général du
projet

14
1 Présentation d’ISSROAD et contexte général du projet
1.1 Introduction

Dans ce chapitre nous essaierons de présenter d’une façon détaillée l’entreprise où a été effectué
le projet de fin d’études, en mettant en lumière son secteur d’activités, ses missions ainsi que quelques
les services et solutions d’entreprise. Par la suite, nous présenterons le contexte général, Etude de
l’existant et les objectifs du projet et enfin nous allons présenter le chronogramme du projet.

1.2 Présentation de l’entreprise d’accueil

1.2.1 Présentation d’ISSROAD

ISSROAD Consulting est une société marocaine de conseils, ayant des bureaux situés à Tanger,
Casablanca et Toulouse, qui fournit une gamme complète de solutions et de services de cybersécurité
couvrant les différents aspects de la technologie. ISSROAD se tient à côtés de ses clients pour éliminer
les menaces et les risques potentiels en matière de cybersécurité, en proposant des stratégies
personnalisées et des solutions innovantes pour protéger leur architecture.

Figure 1 : Logo d’ISSROAD

1.2.2 Secteur d’activités

Actuellement, ISSROAD se positionne en tant qu'expert en matière de cybersécurité, offrant une

gamme complète de services de conseil, de déploiement et de support.

1.2.3 Missions
La mission d’ISSROAD est de veiller à ce que les entreprises de toutes tailles, les organisations
publiques et les particuliers comprennent les cyber-risques et adoptent une approche plus sensée lorsqu'il
s'agit de protéger leurs données et celles des autres.

Afin d'atteindre ses objectifs, ISSROAD fournit une gamme de services de sensibilisation, de formation,
de conseil en audit et architecture ainsi que le déploiement de solutions de cybersécurité et de services
managés.

15
1.2.4 Services & Solutions d’ISSROAD

Les Services & Solutions d’ISSROAD

Figure 2 : Les services d'ISSROAD

1.2.5 Fonctionnement d’ISSROAD

• Clients : Les clients sont en générale des sociétés françaises et marocaines.
• Références : Pour des raisons de bonnes pratiques et d’hygiène cybersécurité, la liste des
références ne peut être communiquée ici.
• Projets traités : Projets IAM (IGA + PAM), Endpoint Protection, Firewalls, MDM, Cloud, O365,
Tests d’intrusion, Audit, SIEM, ISO27001, etc.

1.3 Contexte général du projet et Objectif Globaux

1.3.1 Contexte général
Notre client de ce projet est une entreprise française qui travaille sur l’obtention de sa certification
ISO 27001 et doit donc mettre en place une solution de monitoring et de gestion d'évènements et
d'incidents en cybersécurité. Pour cela l’équipe pilotage d’ISSROAD a suggéré de mettre en place une
solution SIEM en implémentant la pile de solutions ELK Stack dans un environnement pilote. Après
validation de la version de démonstration en interne, le client a contacté l'équipe ISSROAD pour passer
à l'étape d'implémentation et de déploiement en production.

16
 Un plan de travail a été élaboré pour mener à bien ce projet. Le déploiement de la solution
nécessite d’étudier l'architecture puis le dimensionnement de cette architecture pour prendre en charge
tous les équipements de production, ainsi que le déploiement et la connexion de tous les logiciels,
modules et serveurs. Enfin, des tableaux de bord de visualisation de l'information et des alertes seront
mis en place pour détecter les incidents de sécurité.

1.3.2 Contexte pédagogique

Ce projet sera mené dans le cadre du projet de fin d’études, programmé dans la formation Génie
des Systèmes de Télécommunications et Réseaux à l’Ecole Nationale des Sciences Appliquées de
Tanger. L’objectif principal derrière ce travail est d’intégrer le monde professionnel par la réalisation
d’un projet réel dans une société, afin de développer les atouts acquis lors de la formation pédagogique
et obtenir le diplôme d’ingénieur d’état.

1.3.3 Objectifs Globaux

 Objectif 1 : Acquérir une expertise dans SIEM (Security Information and Event Management) Pour
renforcer les compétences de l'équipe ISSROAD dans la sécurité des systèmes d'information.
 Objectif 2 : Accompagner ISSROAD dans son processus de certification ISO27001 en effectuant
des tests d’intrusion. Afin que ISSROAD valide son niveau de sécurité et de renforcer la confiance
de ses clients.
 Objectif 3 : Assister les ingénieurs confirmés dans le raccordement d'applications aux SIEM des
clients.
 Objectif 4 : La réalisation des tests d’intrusions, de scans et de la rédaction de rapports de sécurité.

1.4 Analyse et critique de l’existant

Afin de garantir une continuité de production ininterrompue et à jour dans le domaine IT, il est
essentiel de maintenir le bon fonctionnement des équipements et de résoudre les incidents et pannes le
plus rapidement possible.

Cependant, dans certains cas, la résolution de ces problèmes peut prendre beaucoup de temps, non pas
en raison de difficultés techniques, mais en raison de la complexité de localiser précisément l'origine de
panne, quelle machine ? quel service ? quel port ? …, cela devient plus dur lorsque l'architecture est
étendue, comme c'est le cas avec de la société cliente qui dispose d'une grande infrastructure, composée
de différentes technologies, sans une centralisation des logs de suivi.

17
C’est pour cela la mise en place d'un système de gestion des informations de sécurité (SIEM) est une
nécessité d’abord afin d'obtenir la certification ISO 27001 de plus le SIEM permet également d'obtenir
une vue globale du réseau grâce aux différents tableaux de bord générés. Cela facilite la détection et la
prévention rapide des vulnérabilités, permettant ainsi à l'administration réseau de garantir une continuité
de service optimal.

Dans les tableaux ci-dessous on fait une étude comparative aux cas où la solution SIEM est déployé ou
bien non déployé :

 En absence du SIEM :

Avantages Inconvénients

• Économies de coûts. • Difficulté de détecter les menaces et les

attaques.
• Simplification de la configuration.
• Perte de visibilité de l’ensemble de
• Réduction de la complexité. l’architecture et de ses composants.

• Difficulté à détecter les problèmes, les erreurs

et les pannes dans l'architecture.

• Difficulté à effectuer des analyses les logs pour

l’obtention des informations sur l’architecture
et son fonctionnement.

• Difficulté de répondre rapidement aux

incidents de sécurité.

• Charge de travail accrue sur l’équipe

d’administration réseaux.
Tableau 1 : l'état d'existant en absence du SIEM

18
 En présence du SIEM :
Avantages Inconvénients

• La centralisation des informations de sécurité • Le cout élevé de la mise en place et de suivi.

de divers sources (les postes de travail, les
serveurs, les pares-feux, les IDS …). • Le SIEM génère beaucoup d’alertes et de
messages, ce qui est difficile à trier et à
• Détection des menaces potentielles et des interpréter.
incidents de sécurité.
• Le SIEM peut générer des alertes pour des
• Analyse des données en temps réel évènements qui ne sont pas réellement des
menaces.
• Automatisation en réponse des événements de
sécurité (Interdire l’accès d’un utilisateur,
Avertir les administrateurs système ...).

• Visualisation améliorée d’état de la sécurité des

composants du réseau en temps réel.

• Facilitation de la collaboration et la
coordination entre les différents départements
de l’entreprise.

• Le SIEM peut aider les entreprises à se

conformer aux exigences réglementaires et les
certifications ISO.
Tableau 2 : l'état d'existant en présence du SIEM

1.5 L’étude du besoin

L’étude du besoin est le point de départ de tout projet. Avant d’imposer un « comment » ou une
solution, il faut s’orienter vers l’utilisateur pour aboutir de manière structurée à la solution car un projet
n’a pas de sens que s’il satisfait le besoin. Il s’agit d’expliciter l’exigence fondamentale qui justifie la
réalisation de ce projet Pour cela, il est essentiel de répondre aux 3 questions suivantes :

 A qui le projet rend-il service ?

 Sur quoi agit-il ?
 Pourquoi, dans quel but ?

19
 • Mise en place • Infrastructure
d'une solution réseau de
SIEM et réponse l'entreprise cliente.
aux incidents de
sécurité. Sur
Service
quoi
?
agit-il ?

Qui
dans
rend le
quel
service
but ?
• ISSROAD ? • Centraliser les logs
et avoir un vision
globale du réseau.

1.6 Acteurs du projet

Maitre d’œuvre Maitre d’ouvrage Encadrant Encadrants professionnels

pédagogique

La filière Génie des Systèmes Salwa HARIF :

de Télécommunications et ISSROAD Directrice d’ISSROAD
Réseaux à l’ENSA de Tanger Consulting
représentée par l’étudiant Anass KHANNOUS
Ingénieur TAHIR Issam. Oumaima EL HARROUS :
Consultante en cybersécurité

Tableau 3 : les acteurs de projets

1.7 Contraintes

La gestion de ce projet doit tenir compte des contraintes suivantes :

Contraintes pédagogiques :

• Appliquer les techniques et méthodes de gestion de projet.

• Apprendre à être autonome dans la réalisation d’un projet
• Acquérir de nouvelles connaissances.
Contraintes de temps :

20
• Le temps dédié à ce travail est limité principalement en 6 mois.

Contraintes de réalisation :

• Un tel projet exige une implication totale afin de le mener à bien et d’assurer une amélioration
continue au sein de l’entreprise.

1.8 Management du délai du projet

Afin d’assurer le bon déroulement du projet, nous avons eu recours à la gestion du projet qui
permet la planification de toutes les étapes et tâches à réaliser. Le diagramme de GANTT du projet
réalisé est représenté :

Figure 3 : Chronogramme du stage

21
1.9 Conclusion

Dans ce premier chapitre, nous avons effectué une présentation de la société d’accueil « ISSROAD
» et ses différents services avec les contextes et les objectifs globaux. Ensuite, nous avons présenté une
étude du système existant, ses lacunes ainsi que les avantages et les inconvénients d’implémenter une
solution SIEM. Par la suite nous avons mentionné les acteurs du projet et enfin nous avons mis en place
le chronogramme à suivre dans l’étape de la réalisation.

Le deuxième chapitre sera consacré à la littérature et aux études des solutions SIEM et de notre solution
choisie et une autre étude conceptuelle de la solution at de l’architecture du travail.

22
 CHAPITRE 2 :
Etude fonctionnelle et
conceptuelle

23
2 Etude fonctionnelle et conceptuelle
2.1 Introduction

Dans ce chapitre nous allons faire une littérature des concepts et des termes qui englobent notre
sujet tels que les notions de base du SIEM. Ainsi une étude comparative des solutions leaders SIEM,
puis nous allons traiter le choix de la solution, pourquoi ce choix ? Et comment cette solution fonctionne
? Après Nous allons présenter l’architecture générale du travail et le dimensionnement du cluster Elastic
et enfin on essayera de mettre en place les procédures de collecte de logs que nous allons suivre dans le
chapitre 3.

2.2 Les Solutions SIEM

2.2.1 Qu'est-ce qu'un SIEM ?

La gestion des informations et des événements de sécurité (SIEM) est une approche de la gestion
de la sécurité qui combine les fonctions SEM (gestion des événements de sécurité) en un seul système
de gestion de la sécurité et SIM (gestion des informations de sécurité). Les bases fondamentales de tout
système SIEM consistent à centraliser les données pertinentes provenant de diverses sources, à détecter
les anomalies par rapport aux normes établies, puis à entreprendre les actions nécessaires en
conséquence. Par exemple, lorsqu'un problème potentiel est détecté, un système SIEM peut enregistrer
des informations supplémentaires, générer une alerte et donner des instructions à d'autres contrôles de
sécurité pour arrêter la progression d'une activité.

Au niveau le plus élémentaire, un système SIEM peut être basé sur des règles ou utiliser un moteur
de corrélation statistique pour établir des relations entre les entrées du journal des événements. Les
systèmes SIEM avancés ont évolué pour inclure l'analyse du comportement des utilisateurs et des entités
(UEBA) et l'orchestration, l'automatisation et la réponse en matière de sécurité (SOAR).

Figure 4 : composants et capabilités de SIEM

24
2.2.2 Comment fonctionne le SIEM ?
Les systèmes SIEM fonctionnent en déployant plusieurs agents de collecte d’une manière
hiérarchique pour recevoir des événements liés à la sécurité provenant des équipements des utilisateurs
finaux, des serveurs et des équipements réseaux, et des équipements de sécurité spécialisés, tels que les
pares feux, les antivirus ou les systèmes de prévention/détection des intrusions (IPS/IDS). Les
collecteurs ou les agents transmettent les événements à la console de gestion centralisée, où les analystes
de sécurité passent au crible le bruit, relient les points et classent les incidents de sécurité par ordre de
priorité.

2.2.3 Pourquoi le SIEM est-il important ? Comment les SIEM renforcent-ils la sécurité ?
Le SIEM joue un rôle essentiel dans la sécurité des systèmes informatiques et des réseaux,
d’abord à cause de sa fonction principale, qui est la gestion des événements, il propose une large gamme
de fonctionnalités et de services. Parmi ceux-ci, on retrouve la détection des menaces, la prévention des
menaces, la surveillance en temps réel, ainsi qu'une visualisation complète et améliorée des activités du
réseau.

Bien que ces fonctionnalités soient généralement proposées par différentes solutions et technologies, le
SIEM se distingue en les centralisant et en facilitant leur communication fluide entre ces fonctionnalités.

2.2.4 Etude et comparaison et des solutions SIEM

Il existe plusieurs grandes entreprises du domaine IT qui fournissent leurs produits SIEM sur le
marché, mais nous concentrerons uniquement sur les leaders du marché de la gestion des évènements
des systèmes d’information tels que :

 QRadar SIEM :
QRadar est une solution plutôt orientée grandes entreprises d'où peut-être une utilisation un peu plus
complexe lorsqu'il s'agit de la personnaliser. IBM QRadar a la possibilité de collecter les logs et les flux
venant d'applications sur le Cloud. La solution peut être déployée en SAAS (Software As A Service)
grâce à l'offre « IBM Cloud ».

L'offre « IBM QRadar Security Intelligence » inclut les modules de gestion des risques, de gestion des
vulnérabilités, d'analyse d'investigation numérique et les réponses aux incidents.

Figure 5 : logo du IBM QRadar

25
Dans un système tout-en-un, toutes les données sont collectées, traitées et stockées sur l’Appliance tout-
en-un. Dans les environnements distribués, la console QRadar n'effectue pas le traitement des
événements et des flux, ni le stockage. Au lieu de cela, la console QRadar est principalement utilisée
comme interface utilisateur où les utilisateurs peuvent l'utiliser pour des recherches, des rapports, des
alertes et des enquêtes.

Le fonctionnement de la plateforme de renseignement de sécurité QRadar se compose de trois couches

et s'applique à toute structure de déploiement QRadar, quelle que soit sa taille et sa complexité :

• La Collecte de données avec QRadar

• Traitement des données
• QRadar et la recherches de données

 Splunk :
L'un des leaders du marché, SPLUNK est relativement simple à utiliser et rapide à mettre en œuvre.
Il existe sur le marché depuis 2006. Il possède une interface graphique conviviale. De plus SPLUNK
rime avec évolutivité : Votre réseau peut s'agrandir, Splunk suivra.

Figure 6 : Logo du Splunk

La plateforme Splunk regroupe et analyse les échappements numériques provenant de diverses sources,
notamment les pulls d'interface de programme d'application (API) et les logs des applications, des
serveurs, des appareils mobiles et des sites Web.

Les principales caractéristiques de Splunk sont :

1. Surveillance de la sécurité.
2. Détection avancée des menaces.
3. Analyse du comportement de l'utilisateur.
4. Réponse aux incidents.
5. Recherche d'incidents.

 Elastic (ELK Stack)

ELK est une suite open source comprenant 3 composants principaux : ElasticSearch, Logstash et
Kibana. Beats a été ajouté ensuite pour former la Stack ELK. ELK permet l’indexation et l’analyse des
données. Logstash est un outil qui ingère différentes données du parc informatique d'une organisation :

26
 fichiers de logs, base de données, services web, etc. ElasticSearch est un moteur de recherche qui permet
de retrouver les données que l'on recherche dans Logstash. Kibana est l'interface graphique qui permet
de naviguer dans les données d'ElasticSearch où on peut ensuite générer des tableaux, des graphiques,
etc.

Figure 7 : Logo du ELK

Bien que Elastic est gratuit et libre et à code source ouvert, l'installation d'ELK et sa configuration sont
un peu complexes, ELK repose sur trois solutions libres et à codes sources ouverts mais si l'on veut
profiter de plusieurs fonctionnalités comme les alertes, le monitoring, etc.

 Comparaison des solutions

Le tableau ci-dessous présente une comparaison entre trois solutions SIEM populaires : QRadar,
Splunk et ELK Stack :
Capacité Installation Traitement des Interface web et Coût
données recherche

QRadar Hautement Moyenne Complexe Moins complète Plus couteux

personnalisable

Splunk Moins Simple Facile Moins complète Couteux

personnalisable

ELK Stack Modérément Complexe Complexe Plus complète Open source

personnalisable

Tableau 4 : Benchmark des solutions SIEM

2.3 La pile ELK

Dans ce projet nous allons travailler avec la solution open source ELK qui est un ensemble d'outils
open source d'ingestion de données, d'enrichissement, de stockage, d'analyse et de visualisation aussi
qui permet la supervision de logs et la détection des alertes. En effet, avec ELK Stack nous pouvons
obtenir un système puissant pour analyser l'état et répondre rapidement aux incidents de sécurité de

27
l'information dans une organisation. ELK, acronyme issu des trois composants principaux de la suite
(ElasticSearch, Logstash, Kibana).

2.3.1 Etude de la solution Elastic Stack

2.3.1.1 ElasticSearch

ElasticSearch est le cœur de l'ensemble du système, qui combine les fonctions d'une base de
données, c’est un moteur Open source de recherche et d’analyse distribué pour tout type de données, y
compris les données textuelles, numériques, géo- spatiales, structurées et non structurées. ElasticSearch,
au cœur de la Suite Elastic, joue un rôle central dans la découverte et l'analyse des données.

Figure 8 : Logo du ElasticSearch

Les concepts clés d'ElasticSearch sont les suivants :

Figure 9 : Les concepts clés d'ElasticSearch

• Node :

Il s'agit d'une instance unique d'ElasticSearch. Un seul serveur physique ou virtuel accueille plusieurs
nœuds en fonction des capacités de leurs ressources physiques comme la RAM, le stockage et la
puissance de traitement.
• Cluster :

28
 Un cluster ElasticSearch est un groupe d'une ou plusieurs instances de nœuds ElasticSearch qui sont
connectées ensemble. La puissance d'un cluster ElasticSearch réside dans la répartition des tâches, la
recherche et l'indexation, sur tous les nœuds du cluster.
• Index :

Un index ElasticSearch est un ensemble des documents liés les uns aux autres. ElasticSearch stocke
les données sous forme de documents JSON dans ces indices.
• Documents :

Ce sont essentiellement des enregistrements dans un index, tout comme une ligne dans une base de
données relationnelle. Chaque document a un format JSON, un _id unique qui lui est associé et se
rapporte à un schéma spécifique dans l'index.
• Shard :

Un shard ou fragment est une instance unique de Lucene. C'est l’unité du travail qui est
automatiquement gérée par ElasticSearch qui distribue les partitions entre tous les nœuds du cluster et
peut déplacer automatiquement les partitions d'un nœud à un autre en cas de défaillance d'un nœud ou
d'ajout de nouveaux nœuds.
• Replicas :

Il s’agit d’une copie d’un shard principale existant. Il y a deux raisons principales derrière la
conservation des répliques :
 Une partition de réplique peut être promue en partition principale en cas de défaillance.
 Les requêtes d'obtention et de recherche peuvent être gérées par des fragments primaires ou de
réplicas, donc le fait d'avoir des réplicas peut améliorer les performances.

2.3.1.2 Logstash

Logstash est une solution open source de traitement de données et de logs côté serveur. Elle peut
recueillir des données provenant d’une multitude de sources pour les filtrer, les transformer, les enrichir,
et enfin les transmettre à un autre système pour des traitements additionnels ou stockage.

Figure 10 : logo du Logstash

Logstash, joue un rôle essentiel dans le transfert des données collectées vers ElasticSearch. Son
fonctionnement est défini dans des fichiers de configuration qui comprend trois étapes principales :

29
 Input :

Il s’agit de la première étape du pipeline Logstash, qui sert à introduire les données, en vue d’un
traitement ultérieur. Logstash utilise différents plugins pour recueillir des données issues de diverses
plateformes à tout type de source de données (fichiers, base de données...).

 Filter :

La phase de transformation des données est considérée comme la partie la plus "intelligente" de
Logstash. Cette étape permet d'adapter les données collectées selon les besoins spécifiques de la
destination finale, en effectuant des modifications, des filtrages ou des enrichissements, garantissant
ainsi une cohérence et une compatibilité optimales avec ElasticSearch.

 Output

C’est la dernière étape du pipeline Logstash. Les événements de sortie sont structurés selon un format
prédéfini, attendu par les systèmes de destination.

2.3.1.3 Beats

Agents et collectionneurs d'événements. Elastic dispose d'un ensemble d'agents prenant en charge
différents ensembles de données de différents systèmes tels que Windows, Linux, Metrics, Uptime...

 FileBeat :

Agent de logs appartenant à la famille Beats - un groupe d'expéditeurs légers installés

sur des hôtes.

 WinlogBeat :

WinlogBeat est un agent d'expédition de logs d'événements spécifique à Windows,

installé comme un service Windows.

 MetricBeat :

MetricBeat vous aide à surveiller vos serveurs et les services qu'ils hébergent en
collectant des métriques à partir du système d'exploitation et des services.

 AuditBeat :

AuditBeat est un Agent de collecte de log d’audit et système sur linux.

30
 PacketBeat :

PacketBeat est un agent qui collecte des logs réseau (flux, Bytes, SMB, DNS,
SSL, HTTP, Géolocalisation, …etc.).

 HeartBeat :

HeartBeat est un agent de collecte des données de disponibilité (uptime, Statuts

des sources de logs et systèmes, Healthcheck).

2.3.2 Traitement et structure des données avec ElasticStack

 Traitement des données avec ElasticStack :

ElasticSearch reçoit des données brutes depuis une multitude de sources. Une fois reçu, Logstash
se charge de l'ingestion des données, et indexe le résultat dans ElasticSearch. Une fois indexées, les
administrateurs peuvent effectuer des recherches et agrégations sur leurs données, créer des
visualisations et des tableaux de bord, depuis Kibana.

Figure 11 : Traitement des données avec ElasticStack

31
  La structure des données dans ElaticSearch :

L'indexation est la méthode par laquelle les moteurs de recherche organisent les données pour une
récupération rapide. La structure résultante est appelée un index. Chaque index est divisé en plusieurs
shards. En divisant les indices en shards ou fragments une partition contiendra un sous-ensemble des
données et est en elle-même entièrement fonctionnelle et indépendante.

L’index est divisé en shards primaires et réplicas, l’allocation des shards primaires se fait dans un nœuds
et l’allocation des réplicas se fait dans les autres nœuds.

Il y a deux raisons principales pour lesquelles le sharding est important, la première étant qu'il nous
permet de diviser et de mettre à l'échelle des volumes de données. Ainsi, si nous avons des quantités
croissantes de données, car nous pouvons toujours modifier le nombre de partitions pour un index
particulier.

La figure suivante détaille la structure des indexes et shards au sein d’un cluster ElasticSearch.

Figure 12 : La structure des données ElaticSearch

2.4 Architecture du travail et dimensionnement du cluster Elastic :

2.4.1 Architecture du projet

Tout d'abord, voici une présentation de l'environnement dans lequel nous allons déployer notre
solution afin de la développer :

32
 Figure 13 : Architecture du projet

NB : les noms des nœuds : Node 1 - Data Hot / Node 2 – Kibana / Node 3 - Data Warm.

2.4.2 Identifier les sources de données et les événements à surveiller

D’après l'architecture présentée ci-dessus, les sources de logs sélectionnées comprennent
différentes machines et technologies, telles qu’un pare-feu, un serveur de virtualisation, des machines
Linux (Debian/Ubuntu) et des machines Windows (serveur et poste du travail). L'objectif de cette
approche est de diversifier les sources de logs et de couvrir un large éventail de technologies. Toutefois,
dans le cadre du projet avec le client, le nombre de machines impliquées est considérablement plus élevé,
reflétant ainsi l'ampleur et la complexité de l'environnement à prendre en compte.

 Les événements à surveiller :

33
Source de Windows server Windows Ubuntu Debian 11 pfSense Esxi
Logs desktop Server Server

Types des ▪ Security logs ▪ Application ▪ System ▪ System ▪ System Events ▪ System
événements ▪ Directory Service logs logs logs ▪ Firewall Events logs
▪ Sécurité logs ▪ DNS Events
logs /WSUS
▪ Installation ▪
▪ DNS Server logs DHCP Events
▪ File Replication
logs ▪ General
▪ Système logs Authentication
Service logs
Events
▪ Group Policy
logs ▪ VPN Events
▪ Active Directory ▪ Gateway Monitor
Web Services Events
logs ▪ Network Time
Protocol Events
Tableau 5 : les types des évènements

2.4.3 Identifier les prérequis et l’architecture du cluster

 Les prérequis systèmes :

Lorsque nous définissons l'architecture d'un système, nous devons avoir une vision claire des cas
d'utilisation et des fonctionnalités que nous offrons. En outre, l'architecture peut être influencée par les
contraintes que nous pouvons confronter, comme le matériel disponible, la stratégie globale de
l’entreprise et bien d'autres contraintes qu'il est important de prendre en compte dans notre exercice de
dimensionnement. Mais de la part des prérequis on peut dire que les facteurs à déterminer sont les
suivants :

1) Stockage :

 Les disques SSD sont recommandés dans la mesure du possible, en particulier pour les nœuds
exécutant des opérations de recherche et d'indexation.
 ElasticSearch n'a pas besoin d'un stockage redondant, il a au moins un shard et replica, ce qui est
le minimum pour assurer la tolérance aux pannes tout en minimisant le nombre d'écritures.

2) Memory :

 JVM Heap : stocke les métadonnées sur le cluster, les index, les fragments, les segments et les
données de champ. Ceci est idéalement réglé à 50% de la RAM disponible.

34
  Cache du OS : ElasticSearch utilisera le reste de la mémoire disponible pour mettre les données
en cache, ce qui améliorera considérablement les performances en évitant les lectures sur disque
pendant la recherche en texte intégral, les agrégations sur les valeurs des docs et les tris.

Une machine avec 64GB de RAM est le point idéal, mais les machines de 32GB et 16GB sont
également courantes. Moins de 8GB a tendance à être contre-productif, et plus de 64GB pose également
des problèmes.

3) Compute :

 Les nœuds ElasticSearch disposent de pools de threads et de files d'attente de threads qui utilisent
les ressources de calcul disponibles.
 La quantité et les performances des cœurs de processeur régissent la vitesse moyenne et le débit
de pointe des opérations de données dans ElasticSearch.

4) Sizing :

Pour les cas d'utilisation de métriques et de log, nous gérons généralement une énorme quantité
de données, il est donc logique d'utiliser le volume de données pour dimensionner initialement notre
cluster ElasticSearch. Au début, nous devons poser quelques questions pour mieux comprendre les
données à gérer dans notre cluster. En général, nous ajoutons 5% ou 10% pour la marge d'erreur et 15%
pour rester sous les filigranes de disque. Il est très important à répondre à ces questions pour avoir le bon
dimensionnement du cluster ELK.

• Combien de jours conserverons-nous les données ?

• Combien de données brutes (Go) indexerons-nous par jour ?

 Dimensionnement :

Avant de répondre aux questions ci-dessus on doit d’abord définir c’est quoi un data tier ou bien le
niveau de données :

Un niveau de données (data tier) est un ensemble de nœuds avec le même rôle de données qui partagent
généralement le même profil matériel. Voici les différents niveaux de données :

1) Les nœuds de Content tier gèrent l'indexation et le chargement des requêtes pour le contenu tel
qu'un catalogue de produits.

2) Les nœuds de Hot tier gèrent la charge d'indexation des données de série chronologique telles que
les journaux ou les mesures et contiennent vos données les plus récentes et les plus fréquemment
consultées.

35
 3) Les nœuds de Warm tier contiennent des données de séries chronologiques qui sont consultées
moins fréquemment et qui nécessitent rarement une mise à jour.

4) Les nœuds de Cold tier contiennent des données de séries chronologiques auxquelles on accède
rarement et qui ne sont normalement pas mises à jour.

5) Les nœuds de Frozen tier contiennent des données de séries temporelles rarement consultées et
jamais ne mises à jour.

Revenant à la 1ère question de "Combien de jours conserverons-nous les données ? " afin de
respecter les exigences de la ISO 27001 on doit conserver les données au minimum pour 6 mois, nous
avons pris la décision de conserver ces données dans le Hot tier pendant les 2 premiers semaines, puis
ces données vont se déplacer vers le Warm tier pour 6 mois.

Dans notre architecture, le cluster ELK contienne 3 nœuds, on va dédier deux nœuds (Node1- Data Hot
et Node2–Kibana) pour qu’ils seront des nœuds de la zone Hot, c’est deux nœuds vont être identiques
et avec les mêmes prérequis car un nœud va être dédié pour stocker les indices primaires et le deuxième
nœud va stocker les répliques de ces indices, ce choix est pour assurer la haute disponibilité et aussi pour
répartir la charge sur ces deux nœuds. Le 3ème nœud (Node1-Data Warm) sera dédié pour stocker les
données durant le Warm tier.

Figure 14 : architecture du cluster

36
Voici un exemple explicatif de la répartition du stockage :

Figure 15 : les data tiers d'ElasticSearch

La réponse de la question Combien de données brutes (GB) indexerons-nous par jour ? Se

base sur le calcul de nombre des événements crée par les sources des logs par seconde puis par jour,
voici quelques exemples approximatifs des événements générés :

Technologie Quantité Evènements /second GB/ jour 6 mois (GB)

Windows Servers - MED 1 3.00 0.29 52.14

EPS (Event Log)

Linux Servers 1 3 0.07 13,04

Hyperviseur 1 15.00 1.21 217.26

(ESXi, Hyper-V etc.)

Network Firewalls (DMZ) 1 50.00 1.01 181.05

Tableau 6 : exemple du nombre et stockage des évènements de certaines technologies par jour

Après ce calcul on utilise La règle Générale proposé par la pile ELK :

Total Data (GB) = Raw data (GB) per day * Number of days retained * (Number of replicas +1).

Total Storage (GB) = Total data (GB) * (1 + 0.15 disk Watermark threshold + 0.1 Margin of error).

37
 Total Data Nodes = ROUNDUP (Total storage (GB) / Memory per data node / Memory : Data Ratio).

2.5 Les procédures de collecte de logs

2.5.1 Les méthodes de collecte de logs dans ELK Stack :

Pour assurer la collecte de données depuis les équipements vers ElasticSearch on peut dire qu’nous
avons deux méthodes principales à suivre, et elles sont Beats et Logstash :

 Beats :

Beats sont des expéditeurs de données légers qu’on installe en tant qu'agents sur les équipements
dans le but d’envoyer des types spécifiques de données opérationnelles à ElasticSearch. Les beats ont
un faible encombrement et utilisent moins de ressources système que Logstash.

Exemple des modules d’agent du types Beat :

Figure 16 : les modules de FileBeat

 Logstash :

Logstash a une plus grande empreinte, mais fournit un large éventail de plug-ins d'entrée, de filtre et
de sortie pour collecter, enrichir et transformer des données provenant de diverses sources.

Exemples des plug-ins du Logstash :

Logstash-input Logstash-filter Logstash-codec Logstash-output

logstash-input-elasticsearch logstash-filter-aggregate logstash-codec-avro logstash-output-csv

logstash-input-exec
logstash-input-file
logstash-input-ganglia
logstash-input-gelf
logstash-input-generator
logstash-input-graphite
logstash-input-heartbeat
logstash-filter-anonymize
logstash-filter-cidr
logstash-filter-clone
logstash-filter-csv
logstash-filter-date
logstash-filter-de_dot
logstash-filter-dissect
logstash-codec-cef logstash-output-elasticsearch
logstash-codec-collectd logstash-output-email
logstash-codec-dots logstash-output-file
logstash-codec-edn logstash-output-graphite
logstash-codec-es_bulk logstash-output-http
logstash-codec-fluent logstash-output-lumberjack
logstash-codec-graphite logstash-output-nagios

38
…. …. …. ….

Tableau 7 : les plug-ins du Logstash

2.5.2 Elastic Agent et son importance

 Elastic Agent

Elastic Agent est un moyen unique et unifié qui peut ajouter à la surveillance des logs, autres mesures
et autres types de données à un hôte, il peut :

- Protéger les hôtes contre les menaces de sécurité,

- Interroger les données des systèmes d'exploitation
- Transférer les données des services ou du matériel distant, etc.

Figure 17 : fonctionnement d'elastic agent

Un agent unique facilite et accélère le déploiement de la surveillance dans l’infrastructure. Chaque agent
dispose d'une stratégie unique que nous pouvons mettre à jour pour ajouter des intégrations pour de
nouvelles sources de données et des protections de sécurité, etc.

 Fleet-Server

Fleet-Server est un composant de la pile Elastic utilisé pour gérer de manière centralisée les agents
Elastic. Il se lance comme un agent Elastic sur un ou plusieurs hôtes destinés à servir comme serveurs.
Le Fleet-Server peut prendre en charge de nombreuses connexions Elastic Agent et sert de plan de
contrôle pour la mise à jour des politiques d'agent, la collecte des informations d'état et la coordination
des actions entre les agents Elastic.

39
 Figure 18 : fonctionnement du Fleet-Server

 Elastic Agent Vs Beats

Elastic Agent et Beats offrent des fonctionnalités similaires pour la collecte des données et la
surveillance de l'hôte, mais Elastic Agent présente des avantages spécifiques par rapport aux Beats.

- Facilité de déploiement et de gestion.

- Plus facile à configurer.
- Gestion centralisée.
- Protection des end-points.
2.5.3 Les procédures de collecte des logs par équipement/technologie

Pour mettre la bonne procédure de collecte des logs, on essayera toujours de trouver le plus court
chemin pour atteindre notre objectif, d’après ce qu’nous avons cité dans les paragraphes ci-dessus, nous
visons à utiliser Elastic-Agent qui est le plus facile et simple par rapport aux Agents Beats puis les Agents
Beat qui sont plus simple par rapport à Logstash, donc on doit essayer de travailler avec Elastic-agent
au premier lieu, si on n’a pas réussi on cherche avec Beats, sinon Logstash est la dernière solution. Avec
cet ordre qu’nous avons arrivé à mettre en place le tableau suivant :

Equipement L’outil de collecte de log

Windows server Elastic Agent + Intégration « Custom Windows Event Logs »

Windows desktop Elastic Agent + Intégration « Custom Windows Event Logs »

Ubuntu Server Elastic Agent

Debian 11 Elastic Agent

pfSense Fleet-Server + Intégration « pfSense »

ESXi Server MetricBeat + module « Vsphere »

Tableau 8 : procédure de collecte des logs par équipement

40
2.6 Conclusion
En conclusion, ce chapitre nous a permis de comprendre les généralités du SIEM, précisément sur
notre choix de solution ELK, où nous avons parlé des composants essentiels d’ELK, ElasticSearch et
ces concepts, Logstash et ses trois étapes principales et Beat et ses différents types de collectionneurs
d’événements. Par la suite nous avons présenté l’architecture et l’environnement du travail aussi le
dimensionnement du cluster ELK et enfin la mise en place des procédures de collecte de logs.

Après la phase des études fonctionnels et de la conception de notre solution dans le prochain chapitre
nous travaillerons sur l’implémentation de notre solution ELK et sur la configuration des procédures de
la collecte des logs.

41
 CHAPITRE 3 :
Implémentation et
Configuration d’ELK
Stack

42
3 Implémentation et Configuration d’ELK Stack
3.1 Introduction

Dans ce chapitre nous aborderons les installations et les configurations nécessaires pour le bon
déploiement de notre solution ELK Stack. On commence par l’installation et la configuration de notre
cluster avec ses différents composants, après nous passerons vers la collecte de logs. Et enfin on passe
vers l’étape de la configuration de la rétention des logs afin d’assurer le passage des données d’un niveau
de donnée à un autre.

3.2 Mise en place du Cluster ELK

3.2.1 Installation et configuration d'ElasticSearch et formation du cluster

 Installation et configuration d'ElasticSearch dans les 3 nœuds

Nous allons voir maintenant comment installer, configurer et déployer Elasticsearch dans les trois
machines Ubuntu Server, voici un exemple d’installation d’ES dans :

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-
8.5.3-amd64.deb

Figure 19 : commandes d'installation d'ElasticSearch

43
Une fois l’installation est terminée, il faut modifier dans le fichier de configuration
«/etc/elasticsearch/elasticsearch.yml » qui fournit des options de configuration pour le cluster, nœud,
chemins, réseau, découverte et passerelle. La plupart de ces options sont par défauts dans le fichier mais
on les modifier selon nos besoins, voici quelques changements effectués :

Figure 20 : configuration d'ElasticSearch

Quand nous terminons, nous sauvegardons le fichier, puis on active et démarre le service. Et par la suite
nous pouvons accéder à l’interface graphique d’ElasticSearch à partir de l’adresse IP qu’nous avons
défini.

44
 Figure 21 : interface graphique d'ElasticSearch

 Formation du cluster
De même façon on installe le package d’ES sur , mais avant
d’activer et démarrer le service d’ElasticSearch on doit lier ces 2 nœuds au cluster « issroad » du 1er
nœud Data Hot cela se fait par les étapes suivantes :
- Dans la machine de Data Hot, On entre dans le dossier /usr/share/elasticsearch/, puis on insère
la commande suivante pour générer jeton d'inscription « enrollement token » qui va permet aux
nœuds de joindre le cluster :

bin/elasticsearch-create-enrollment-token -s node

Figure 22 : Enrollement-Token

- Puis dans la machine Data Warm ou Kibana, on entre à /usr/share/elasticsearch/ on insère la

commande suivante pour reconfigurer le nœud en ajoutant le jeton d'inscription générée par Data
hot.

bin/elasticsearch-reconfigure-node –enrollement-token < >

- De cette manière les nœuds importent la même configuration de notre 1er nœud par la suite ils
joignent notre cluster.
3.2.2 Installation et configuration de Kibana / Logstash
3.2.2.1 Installation et configuration de Kibana
Le package Debian pour Kibana v8.5.3 peut être téléchargé depuis le site web et installé comme suit :

wget https://artifacts.elastic.co/downloads/kibana/kibana-8.5.3-amd64.deb

45
Une fois l’installation est terminée, on doit modifier dans le fichier de configuration «
/etc/elasticsearch/kibana.yml », et ajouter les modifications nécessaires tels que l’adresse IP d’ES qu’on
va attacher à kibana, et spécifier le port de la communication de Kibana 5601.

Figure 23 : configuration de Kibana

Quand nous terminons, nous sauvegardons le fichier, puis on active et démarre le service. Et par la suite
nous pouvons accéder à l’interface graphique de Kibana à partir de l’adresse IP qu’nous avons défini.

Figure 24 : interface graphique Kibana

La première chose à vérifier est d’aller à Management => Stack Monitoring et voir les statuts du
cluster et Kibana :

46
 Figure 25 : aperçu sur le cluster et Kibana

3.2.2.2 Installation et configuration de Logstash

Dans notre environnement nous avons dédié toute une machine pour le service de Logstash. Le
package Debian pour Logstash v8.5.3 peut être téléchargé depuis le site web et installé comme suit :

Figure 26 : commandes d'installation de Logstash

Pour le Logstash on n’a rien à configurer pour le moment, la configuration de l’input ou l’output se fait
dans chaque fichier de configuration séparés les uns aux autres, donc il suffit juste maintenant de
démarrer le service et de vérifier le statut de service :

Figure 27 : le statut de Logstash

47
3.3 Installation / configuration des agents et Collecte de logs
3.3.1 Installation et configuration du Fleet-Server

 Configuration du côté ELK :

On installe d’abord le serveur Fleet dans le nœud Kibana. Le Fleet-Server est celui qui va s’en
occuper de la centralisation de communication avec les agents Elastic qu’on va installer dans les sources
des logs. Avant d’installer notre Fleet-Server on doit préciser Output ou l’instance d’ElasticSearch où le
Fleet va envoyer ses logs. L’instance d’ES est le nœud de Data Hot dans notre cas.

On accède à Management > Fleet > Settings :

Figure 28 : l'instance Elasticsearch qui va communiquer avec Fleet

Les commandes d’installation de Fleet server dans nœud Kibana :

Figure 29 : Les commandes d’installation du Fleet

Le Fleet-Server est bien déployé :

Figure 30 : statut du Fleet server

48
3.3.2 Installation et configuration des Agents d’Elastic sur Windows (Server/Desktop)

 Configuration du côté ELK :

On doit créer des politiques séparés pour les agents selon leurs systèmes d’exploitation ou le type
des logs qu’on cherche à collecter, donc nous avons créé plusieurs politiques pour mieux faciliter et
organiser le travail.

Voici les étapes d’installation d’agent pour Windows :

• On choisit la politique, le type d’OS où on installera l’agent et on suit les instructions :

Figure 31 : choix de politique d'agent Windows

 Configuration du côté hôte :

On saisit les commandes dans notre PowerShell :

49
 Figure 32 : installation d'agent Elastic sur Windows

Et de la même manière avec Windows server mais en changeant la politique.

3.3.3 Installation et configuration des Agents Elastic sur Linux (Ubuntu/Debian)

De même avec Linux on choisit la politique et les commandes d’installation pour Linux et on
saisit les commandes d’installation :

 curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.5.3-linux-
x86_64.tar.gz
 tar xzvf elastic-agent-8.5.3-linux-x86_64.tar.gz
 cd elastic-agent-8.5.3-linux-x86_64
 sudo ./elastic-agent install --url=https://172.17.6.53:8220 --enrollment-
token=aC16SlFvZ0JWWXNSaFhsSWVlTWY6VjlEUHRGa01TbVMyajRSM1Joc0MyQQ== --insecure

Et enfin voilà le statut de nos agents :

Figure 33 : le statut des agents installés

3.3.4 Collecte des logs du pare-feu pfSense

 Configuration du côté ELK :

On ajoute l’intégration du pfSense à la politique du Fleet-Server, et on modifie dans les paramètres

de cette intégration de telle façon que le fleet va écouter sur le port 9001 qui va être dédié pour la
communication entre pfSense et notre cluster.

50
 Figure 34 : intégration pfSense

 Configuration du côté hôte :

Dans notre pfSense, on entre à Status => System Logs => Settings, on active la journalisation à
distance par la suite on ajoute le serveur distant du syslog qui est dans notre cas l’adresse de Fleet-Server
avec le port de communication 172.17.6.53:9001, enfin on ajoute les types des logs à envoyer parmi la
liste suivante :

System Events Firewall Events DNS Events DHCP Events

PPP Events General Authentication Captive Portal Events VPN Events

Events

Gateway Monitor Routing Daemon Network Time Wireless Events

Events Events Protocol Events
Tableau 9 : liste des types des logs du pfSense

3.3.5 Collecte des logs d’hyperviseur ESXI

On va collecter les logs d’ESXI en utilisant l’agent MetricBeat

 Configuration du côté hôte:

On accède à Manage -> Advanced settings, puis on modifie sur la valeur d’option
Syslog.global.logHost en ajoutant l’adresse IP de Fleet-Server :

51
 Figure 35 : configuration du syslog server dans ESXI

Ensuite on doit redémarrer le service du Syslog.

 Configuration du côté ELK :

On utilise le module Vsphere du MetricBeat. On suit la méthode suivante :

 Télécharger et installer Metricbeat :

 curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-8.5.3-amd64.deb
 sudo dpkg -i metricbeat-8.5.3-amd64.deb
 Modifier la configuration dans /etc/metricbeat/metricbeat.yml.

Figure 36 : configuration du MetricBeat

 Activer et configurer le module vsphere.

 sudo metricbeat modules enable vsphere
 sudo service metricbeat start
 Modifier les paramètres du fichier /etc/metricbeat/modules.d/vsphere.yml.

52
 Figure 37 : configuration du module vsphere

Enfin on peut voir le statut de module vsphere :

Figure 38 : le statut du module après configuration

3.4 Configuration de la rétention des logs

Dans la solution ELK, tout type de données soit des données du cluster ELK et ses différents
services ou bien des données reçus depuis les sources des logs se stockent en tant que des indices, par
exemple les indices suivants :

Figure 39 : exemple les indices

À titre d'exemple, nous présentons ici des divers indices. Le premier indice concerne les métriques des
agents Metricbeat, utilisées pour la configuration de l'hyperviseur ESXI. Le deuxième indice regroupe
les métriques des agents Elastic que nous avons déployés dans les sources de logs. Le troisième indice
est dédié au stockage des journaux d'événements du cluster pour la date du 16 août 2023. Ce schéma se

53
répète pour d'autres types de données. Ces indices sont regroupés selon des politiques de cycles de vie,
telles que les suivantes

Figure 40 : les politiques de cycles de vie des indices

Selon les données et la dimension de notre architecture nous avons opté de garder les indices dans la
phase HOT pour 14 jours et 6 mois dans la phase WARM, après la suppression de ces indices
définitivement d’ELK. Pour appliquer ces temps de rétentions sur tous les indice on doit mettre à jour
leurs politiques des cycles de vie des indices, voici un exemple de la configuration :

54
 Figure 41 : configuration de rétention des logs

3.5 Conclusion

À travers ce chapitre nous avons traité la configuration et l’installation de la solution ELK et ses
agents dans notre architecture. En effet ce chapitre est réparti en 2 grands axes, Le premier axe est du
côté de la solution où nous avons mis en place la Stack ELK incluant l’installation des nœuds et leurs
composants ElasticSearch, Logstash et Kibana. Le deuxième axe est du côté des sources de logs où nous
avons installé et configuré les agents Elastic, Beats en suivant les méthodologies de collecte établis dans
le chapitre2. Enfin nous avons configuré la rétention des données des indices afin de respecter les
prérequis systèmes.

Après les étapes d’installation et de configuration nous sommes arrivés à recevoir différents types des
données et d’informations, dans le prochain chapitre on essayera d’analyser ces données et de travailler
sur une évaluation sur notre solution en se basant sur plusieurs critères Aussi de présenter la mise en
production de la solution avec le client.

55
 CHAPITRE 4 :
Evaluation de la solution
et mise en production

56
4 Evaluation de la solution et mise en production
4.1 Introduction

Dans ce chapitre nous aborderons les méthodes d’évaluation de la solution ELK, cette évaluation
reposera sur une analyse des logs reçus et des tableaux de bords ainsi que traitement des alertes en cas
d’incidents mis en place, par la suite une présentation de la solution de sauvegarde déployée de la pile
ELK. Enfin nous clôturerons ce chapitre par le processus de la mise en production avec le client en
mettant en évidence les différences majeures par rapport à l’architecture choisie dans ce rapport.

4.2 Evaluation de la solution

4.2.1 L’arrivée des logs :

 Data Views :

Les Data Views nous aide à distinguer et récupérer les données à partir d'Elasticsearch. On peut créer
nos propres Data Views qui seront liés avec les indices où les logs existent ou bien on peut utiliser les
Data Views par défauts tels que logs.* , metrics.* metricbeat.* , etc.

Figure 42 : Data views

57
 Data View =logs.*
Dans ce Data View on peut voir les logs de tous les indices qui commence par logs :

Figure 43 : les data view Logs*

Voici un exemple des évènements de Data View Logs* arrivé à ELK dans une heure le 20 Aout, 2023
entre 15:14 et 16:14 :

Figure 44 : aperçu des data views logs*

58
 Data View =metrics.*
Dans ce Data View on peut voir les logs de tous les indices qui commence par metrics tels que :

Figure 45 : les data views metrics*

Voici un exemple des évènements de Data View Logs arrivé à ELK dans une heure le 20 Aout, 2023
entre 15:30 et 16:30:

Figure 46 : perçu des data views metric*

59
 Vision globale sur les indices et analyse des logs :

Dans cette partie on essayera d’avoir une idée générale sur les indices crées lors de l’arrivée des
données, voici une partie de ces indices :

Figure 47 : exemple des indices

On va essayer dans les exemples présentés ci-dessous d’avoir une idée sur les différents types de logs
qu’nous avons reçu dans notre solution, on va analyser un log par équipement :

 Source de logs => Windows desktop : DESKTOP-9VHGMK1

Un exemple de log de Windows arrivé à ELK Aug 24, 2023 @ 14:51 :

Figure 48 : exemple du log Windows desktop

60
Les informations du Log :

Indice .ds-logs-system.security-default-2023.08.10-
000001
Temps d’arrivée Aug 24, 2023 @ 14:51:08.868

Data_Stream.Dataset system.security

Data_Stream.Type logs

Catégorie d’évènement authentication

Nom de système d’exploitation de Windows 10 Enterprise Evaluation

l’hôte
Processus exécuté C:\Windows\System32\services.exe

Message An account was successfully logged on.

Subject:
Security ID: S-1-5-18
Account Name: DESKTOP-
9VHGMK1$
Account Domain:
WORKGROUP
Logon ID: 0x3E7
………
Tableau 10 : exemple des informations des logs du Windows desktop

 Source de logs => Windows Server : DC2022

Un exemple de log de Windows Server arrivé à ELK Aug 24, 2023 @ 05:53:

Figure 49 : exemple du log Windows server

61
Les informations du Log :

Indice .ds-logs-winlog.winlog-default-2023.08.10-000001
Temps d’arrivée Aug 24, 2023 @ 05:53:42.341
Data_Stream.Dataset winlog.winlog
Data_Stream.Type logs
Fournisseur Microsoft-Windows-ActiveDirectory_DomainService
d’évènement
Nom de système Windows Server 2022 Datacenter Evaluation
d’exploitation d’hôte
Processus exécuté C:\Windows\System32\services.exe
Message This directory partition has not been backed up since at least
the following number of days.
Directory partition:
CN=Configuration,DC=issroad,DC=lab
'Backup latency interval' (days): 90
………
Tableau 11 : exemple des informations des logs du Windows server

 Source de logs => Ubuntu/Debian :

Un exemple de log de Ubuntu arrivé à ELK Aug 24, 2023 @ 05:53:

Figure 50 : exemple du log Linux

62
Les informations du Log :

Indice .ds-metrics-system.process-default-
2023.08.10-000004
Agent.name ubuntu
Data_Stream.Type Metrics
Process. command_line /usr/bin/perl -
I/opt/BitDefender/share/perl
/opt/BitDefender/bin/sve-config-ui
Process.name sve-config-ui
system.process.cpu.total.value 2,354,610
user.name root
Tableau 12 : exemple des informations des logs du Linux

 Source de logs => PfSense :

Un exemple de log de pfSense arrivé à ELK Aug 25, 2023 @ 15:24:

Figure 51 : exemple du log de pfSense

Les informations du Log :

Indice .ds-logs-pfsense.log-default-2023.08.10-000001
Data_Stream logs
.Type
network.dire inbound
ction
network.tran udp
sport
observer.type firewall

63
 message 4,,,1000000103,vmx1,match,block,in,4,0x0,,128,35997,0,none,17,udp,72,172.17.5.
101,172.17.5.255,57621,57621,52
Tableau 13 : exemple des informations des logs du pfSense

 Source de logs => ESXI :

Un exemple de log de pfSense arrivé à ELK Aug 25, 2023 @ 15:24:

Figure 52 : exemple du log d'ESXI

Les informations du Log :

Indice .ds-metricbeat-8.5.3-2023.07.28-000001
event.module vsphere
vsphere.host.cpu.used.mhz 8,084
vsphere.host.memory.used.bytes 15.4GB
vsphere.host.network_names [LAN, Lab VMs, Virtual Servers, WAN]
Tableau 14 : exemple des informations des logs d'ESXI

Après la réalisation d’objectif de lire et analyser les différents types de logs de notre périmètre, on peut
dire qu’nous avons arrivé à réaliser le but de centralisation des logs depuis plusieurs hôtes et multiples
technologies.

64
4.2.2 Les tableaux de bord

Les tableaux de bord nous aident à avoir une visualisation claire et exploitable des données de
sécurité, la solution ELK nous propose plusieurs tableaux de bord de différentes technologies par
exemple dans notre périmètre on peut utiliser et bénéficier des tableaux suivants :

 ESXI :

 pfSense :

 Windows / Linux / System :

Figure 53 : exemple d'un ensemble des dashboards

On essayera par la suite de prendre quelques informations utiles et exploitable depuis ces tableaux de
bords.

65
4.2.2.1 Exemple des tableaux de bord du pare-feu pfSense
Ces dashboards nous fournit des informations :
• Les top 5 pays de destination : United States, United Kingdom, Spain et Morocco…
• Nombre d’action bloqués et autorisés.

• Statistiques de transport réseaux par temps avec les protocoles utilisés Igmp /Icmp /Udp /Tcp:

• Les opérations DHCP effectués depuis / vers pfSense :

Figure 54 : les dashboards du pfSense

66
4.2.2.2 Exemple des tableaux de bord d’Hyperviseur ESXI
Les Dashboards suivants nous fournit plusieurs informations sur les VM ou bien les hôtes ESXI tels
que :
• La distribution des systèmes d’exploitation utilisés dans l’hôte ESXI.

• La distribution des machines virtuelles sur les différents réseaux :

• Le Niveau de RAM dans l’hôtes ESXI.

67
 • Niveaux de stockage dans les Datastores.

Figure 55 : les dashboards d'ESXI

4.2.2.3 Exemple des tableaux de bord Windows

• Ce Dashboard nous fournit des informations sur le nombre des évènements dans les derniers 90 jours
aussi le type de ces évènements :

• Ce Dashboard par exemple nous affiche des informations sur les services des hôtes Windows :

Figure 56 : les dashboards du Windows

68
4.2.2.4 Exemple des tableaux de bord Syslog
Les tableaux de bords suivants nous fournissent plusieurs informations sur les évènements
Syslog par les machine Linux ainsi les processus Syslog effectués par ces machines :

Figure 57 : les dashboards du Linux

4.2.3 Les règles des use case

Une fois les logs collectés, nous développerons et mettrons en place les cas d'utilisation
spécifiques. Nous allons mettre en place des Uses cases qui vont permettre de détecter des actions
malveillantes en ajoutant des améliorations selon les types de logs reçus.

4.2.3.1 Windows Active Directory

But du premier use case : On vise tester la création d’un nouvel utilisateur et l’attribuer à un
groupe d’administrateur par un attaqueur. Si un attaquant arrive à se faire, une alerte doit être déclenchée.
Le scénario à mettre en place est représenté dans le schéma de travail suivant :

Figure 58 : scénario d'attaque

 Le scénario commence par l’attaquant qui peut intercepter la machine AD et qui essaye de créer

69
 un nouvel utilisateur et l’attribuer à un groupe avec des droits d’admin.
 Les différents logs seront envoyés vers Elastic par l’agent déjà configuré sur la machine AD.
 Des alertes seront déclenchés au niveau d’Elastic et le type d’alerte sera ‘User Account Creation’
et ‘User added to privileged group in active directory’.
 L’analyste peut ensuite étudier l’alerte et choisir la solution convenable.

Les uses case à mettre en place sont les suivantes :

• User Account creation : Identifie les tentatives de création de nouveaux utilisateurs. Cela est parfois
fait par les non-administrateurs ou attaquants pour augmenter l'accès ou établir la persistance sur un
système ou un domaine.
 Règle :

process where host.os.family : "windows" and event.type : "start" and process.name :

"cmd.exe" and process.command_line : "/add"

Figure 59 : règle de création d'un compte sur AD

NB : Si un attaquant lance la commande "net user username password /add" une alerte va être
déclenchée.

• User Added to Privileged Group in Active Directory : Identifie un utilisateur ajouté à un groupe
privilégié dans Active Directory. Les comptes et groupes privilégiés dans Active Directory sont ceux
auxquels sont accordés des droits, des privilèges et des autorisations puissantes qui leur permettent
d'effectuer presque toutes les actions dans Active Directory et sur les systèmes joints à un domaine.

 Règle :

70
 iam where host.os.family : "windows" and event.action : "added-member-to-group" and
group.name : ("Administrateurs")

Figure 60 : règle d'ajout d'un utilisateur à un groupe privilégié

• Inbound connection on port 445 : Cette règle identifie les connexions acceptées sur le port
administratif connu 445 pour SMB. Pour réduire la surface d'attaque, ces ports sont généralement
bloqués sur Internet.
 Règle :

host.os.family : "windows" and event.action : "logged-in" and message : "Port source : 445"

4.2.3.2 Pare-feu pfSense

But 1 : On vise tester la connexion d’un attaqueur sur le port 22 pour SSH, 3389 pour RDP ou
23 pour Telnet. Si un attaquant arrive à se faire, une alerte doit être déclenchée.

Les uses case à mettre en place sont les suivantes :

• Inbound connection on port 22 or 3389 : Cette règle identifie les connexions acceptées sur le port
administratif connu : 22 pour SSH ou 3389 pour RDP. Pour réduire la surface d'attaque, ces ports
sont généralement bloqués sur Internet. Cela peut indiquer une configuration non sécurisée ou un
attaquant contournant les mécanismes de défense.

 Règle :

destination.port : (3389 OR 22) and network.direction : inbound and NOT event.action : block

71
 Figure 61 : règle des ports de SSH et RDP pour pfSense

• Inbound connection on port 23 : Cette règle identifie les connexions acceptées sur le port
administratif connu : 23 pour TELNET. Pour réduire la surface d'attaque, ces ports sont
généralement bloqués sur Internet.
Telnet n'est pas un protocole de communication sécurisé car il n'utilise aucun mécanisme de sécurité
et transfère les données sur le réseau/Internet sous forme de texte brut, y compris les mots de passe,
de sorte que n'importe qui peut renifler les paquets pour obtenir ces informations importantes.

 Règle :
destination.port : 23 and network.direction : "inbound" and NOT event.action : block

4.2.3.3 VMware ESXI

But : On vise contrôler les états des stockage, mémoire et CPU dans les datastores et les hôtes ESXI.
Les uses case à mettre en place sont les suivantes :

• Niveau de stockage supérieur à 85% des datastores.

 Règle :

event.module : "vsphere" and vsphere.datastore.capacity.used.pct >= 0.85

Figure 62 : règle de niveau de stockage ESXI

72
• Niveau de RAM ou CPU supérieur à 85% dans les hôtes ESXI.

 Rule :

event.module : "vsphere" and vsphere.host.name : "ESXI" and (vsphere.host.cpu.used.mhz >= 35610 or

vsphere.host.memory.used.bytes >= 1084600000000)

Figure 63: règle du niveau de RAM et CPU d'ESXI

4.2.4 Snapshot and Restore

Le module Snapshot and Restore est considéré la solution de sauvegarde suggérée par ElasticSearch.
Un snapshot est une sauvegarde d'un cluster ElasticSearch en cours d'exécution. Nous pouvons utiliser
des snapshots pour :

• La sauvegarde régulière d'un cluster sans temps d'inactivité.

• Récupérer des données après la suppression ou une panne matérielle.
• Transférer des données entre les clusters.
• Réduisez les coûts de stockage en utilisant des snapshots interrogeables dans les niveaux de
données inactives et gelées.

ElasticSearch stocke les snapshots dans un emplacement de stockage hors cluster appelé référentiel
de snapshots. ElasticSearch prend en charge plusieurs types de référentiels avec des options de stockage
cloud, notamment AWS S3, Google Cloud Storage (GCS), Microsoft Azure ou on peut utiliser la
méthode classique de stockage de backup par utilisation d’un serveur de partage dans le réseau.

Après avoir enregistré un référentiel de clichés, nous utilisons la gestion du cycle de vie des
snapshots (SLM) pour prendre et gérer automatiquement des snapshots. Nous pouvons ensuite restaurer
un snapshots pour récupérer ou transférer ses données.

73
 Par défaut, un instantané d'un cluster contient l'état du cluster, tous les flux de données standard et
tous les index standard. L'état du cluster comprend :

• Paramètres de cluster persistants.

• Modèles d'index.
• Modèles d'index hérités.
• Ingérer les canalisations.
• Stratégies ILM.

4.2.4.1 Référentiel des snapshots

Dans notre environnement nous avons choisi d’utiliser la méthode classique de stockage de
backup par utilisation d’un serveur de partage dans le réseau, nous avons choisi une machine virtuel
Ubuntu Server avec un serveur de partage de fichier NFS installé dedans, après nous avons passé vers
l’installation des agents de serveur NFS dans les 3 nœuds de notre cluster, puis nous avons monté d'abord
le système de fichiers au même emplacement sur tous les nœuds. Enfin nous avons ajouté le chemin du
système de fichiers ou le répertoire parent au paramètre path.repo dans elasticsearch.yml.

4.2.4.2 Cycle de vie des Snapshots

Après effectué la configuration ci-dessus on doit redémarrez le service Elasticsearch, et on passe
vers la vérification de connexion vers ce fichier partagé qu’nous avons nommé backup1, on voit que
tous les nœuds sont connectés à ce fichier.

Figure 64: statut de connexion des nœuds avec le fichier partagé backup1

74
Par la suite on passe vers la mise en place de la politique du cycle de vie de snapshots daily-snapshot1,
dans cette politique nous avons configuré les horaires des snapshots, le contenu de ces snapshots, la
durée de rétention des snapshots sans oublier d’associer la politique avec le fichier partagé backup1.

Figure 65 : politique des snapshots

Voici un exemple des snapshots pris selon notre politique :

Figure 66 : exemple des snapshots prises

75
Un autre exemple du contenu du dernier Snapshot :

Figure 67 : exemple d'un snapshot

En utilisant ces snapshots on peut restaurer les indices, les data Stream, le statut global du cluster, le
statut de la fonctionnalité, la configuration des nœuds et les alliasses crées.

L’avantage de cette solution de sauvegarde est ces snapshots ne sont pas automatiquement dupliqués
ceci aide à économiser de l’espace de stockage et réduire les coûts de transfert réseau. Pour sauvegarder
un index, le snapshot copie les segments de l'index et les stocke dans le fichier partagé backup1. Les
segments étant immuables, il suffit que le snapshot copie les nouveaux segments créés depuis le dernier
snapshot du référentiel.

4.3 Mise en production

Le projet de déploiement la solution ELK chez le client d’ISSROAD a débuté au mois de juin et
on est maintenant dans ses phases finales., l’architecture du cluster ELK est presque similaire à celle que
nous avons présenté dans ce travail, avec des ajustements au niveau des prérequis système (le stockage,
la RAM et le CPU.).

Le périmètre défini par notre client a été large, englobant plus de 40 équipements réseaux et systèmes
basés sur plus de 15 technologies différentes.

76
Pour collecter efficacement les diverses données de ce périmètre nous a avons utilisé toutes les méthodes
de collecte des logs d’ELK stack Logstash, Beat et Elastic Agent. Cette démarche nous a permis de
rassembler plusieurs types de logs variés.

Nous avons ensuite intégré ces logs dans des tableaux des bords explicatifs et utiles pour notre client, en
outre nous avons ajouté plusieurs règles des use cases spécifiques pour chaque technologie, cette étape
est très significative dans la mise en œuvre de la solution ELK, fournissant à notre client une vue précise
et approfondie de la santé et de la performance de ses systèmes.

4.4 Conclusion
En conclusion dans ce chapitre nous avons exploré en détail des diverses méthodes d’évaluation
de la solution ELK stack, cette évaluation est ancrée sur les objectifs fondamentaux nous visons réaliser
par cette solution. Premièrement nous avons examiné les logs reçus. Ensuite nous avons analysé les
tableaux de bords qui servent au client d’avoir une visualisation centrale de l’état de son système. Par la
suite nous avons traité les alertes en cas d’incidents mis en place, enfin de cette évaluation nous avons
présenté la solution de sauvegarde backup déployée qui va garantir une haute disponibilité continue de
la pile ELK.

Enfin nous avons terminé ce chapitre par le processus de la mise en production avec le client en mettant
en évidence les différences essentielles par rapport l’architecture choisie dans ce rapport en matière de
prérequis système, périmètre choisi du client etc.

77
 Conclusion générale

En conclusion, notre rapport de stage a été axé sur la mise en place et amélioration de la solution
ELK Stack en réponse aux besoins de notre client. Nous avons débuté par présenter ISSROAD, notre
entreprise d'accueil, spécialisée en cybersécurité, et les services qu'elle offre à ses clients. Nous avons
abordé le contexte général du projet, en soulignant la problématique et les objectifs fixés pour notre
stage.

Nous avons exploré c’est quoi le System Information Event Management en détail, en mettant en
avant ses majeures solutions dans le marché ainsi que nous avons étudié notre solution choisie et ses
composants principales. Nous avons également expliqué l’architecture du travail en expliquant les types
logs que nous avons visé à collecter et leurs méthodes de collecte associée.

Nous avons ensuite présenté les configurations et les installations nécessaires pour le déploiement
de la solution, avant de procéder à une évaluation de la solution mise en œuvre.

L’objectif de ce stage était d'être capable de fournir une solution de sécurisation qui permettra à nos
clients de réussir leur projet et d'être capable de mettre en place les solutions de sécurité qui répond aux
besoins des clients. Et ce en se basant sur notre formation académique et sur notre travail durant le stage
qui consistait à faire une étude technique et fonctionnelle des solutions leader dans le domaine de sécurité
d’information.

Ce stage nous a permis de nous familiariser avec le processus de réalisation de projet dans un cadre
plus réaliste et professionnel. Ce fut également l’opportunité, pour nous, de mettre en pratique les
connaissances que nous avons acquises durant notre cursus scolaire à l’ENSA.

Cependant, notre travail ne s'arrête pas ici et il y a assez de places à améliorer, notamment en ce qui
concerne les méthodes automatisées de collecte des logs, l’analyse approfondie des données collectées
l’extraction d’information pertinentes et l’amélioration des alertes en cas d’incidents. Tandis que
généralement en cyber sécurité on doit explorer davantage les techniques d'apprentissage pour détecter
d’une manière proactive les menaces et les failles.

78
Webographie

79