Université Mohamed V Rabat

École Nationale Supérieure

Et D’Analyse Des Systèmes D’Informatique
Filière Sécurité des Systèmes d’Information

Rapport de Stage 2A

Mise en place d’une solution d’un système

SIEM

Réalisé par :
LAKHYAR Hassna Membres de jury :

Encadré par : [Link] BENTALEB

PR. Jamal ELHACHMI

PR. Abdellatif KOBBANE

[Link] [Link] ALAMI
Hanane

Année académique : 2025/2026

Remerciements

Tout d’abord, je rends grâce à Allah le Tout-Puissant de m’avoir accordé la

force, le courage et la patience nécessaires pour mener à bien ce travail.
J’exprime ma profonde reconnaissance à M. Idriss Bouzidi, chef de notre filière
SSI, pour son soutien, ses orientations et la qualité de son suivi.
Je tiens à adresser mes sincères remerciements à mon encadrante, Mme El-
manjaoui Hanane, pour son accompagnement précieux, sa disponibilité et ses
encouragements constants. Son regard attentif et constructif a été d’une grande aide
pour améliorer la qualité et la structure de ce mémoire.
Je remercie également l’ensemble de l’équipe du service Réseau pour leur col-
laboration, leur aide précieuse et pour m’avoir permis d’enrichir mes connaissances
au cours de ce stage.
Un remerciement tout particulier à Mme Bouchra, qui m’a aidé à obtenir ce
stage et dont le soutien m’a été d’une grande importance.
Que les membres de jury trouvent, ici, l’expression de mes sincères remerciements
pour l’honneur qu’ils me font en prenant le temps de lire et d’évaluer ce travail.
Je souhaite aussi remercier l’équipe pédagogique et administrative de l’ENSIAS
pour leurs efforts dans le but de nos offrir une excellente formation.
Enfin, j’adresse mes remerciements à toutes les personnes qui, de près ou de
loin, ont contribué à la réalisation de ce travail et au succès de ce stage.

i
Résumé

Dans le cadre de ce stage de deuxième année à l’École Nationale Supérieure

d’Informatique et d’Analyse des Systèmes (ENSIAS), réalisé au sein du Ministère
du Tourisme, de l’Artisanat et de l’Économie Sociale et Solidaire, ce rapport présente
la mise en place d’une solution SIEM (Security Information and Event Management)
basée sur l’outil open source Wazuh.
Le projet vise à renforcer la sécurité des systèmes d’information en collectant,
analysant et corrélant les logs afin de détecter les menaces en temps réel. Après une
présentation du contexte organisationnel et des problématiques liées à la cybersé-
curité, une étude de l’état de l’art compare plusieurs solutions SIEM open source,
menant au choix de Wazuh pour ses fonctionnalités avancées en SIEM et XDR
(Extended Detection and Response).
Le rapport détaille ensuite l’architecture, l’installation et la configuration de
Wazuh, incluant le déploiement d’agents, la définition de règles personnalisées, et
l’activation de modules tels que le File Integrity Monitoring (FIM), la détection de
vulnérabilités, la réponse active, l’évaluation de la configuration de sécurité (SCA),
ainsi que l’intégration avec VirusTotal pour la détection de malwares et Slack pour
les alertes.
Des tableaux de bord personnalisés ont également été créés pour une visualisation
optimale.
Ce travail met en évidence l’efficacité de Wazuh dans l’amélioration de la posture
de sécurité, tout en ouvrant des perspectives pour des intégrations futures.

Mots-clés
SIEM, Wazuh, cybersécurité, logs, détection de menaces, réponse active, inté-
gration, open source.

ii
Abstract

As part of this second-year internship at the National School of Computer Science

and Systems Analysis (ENSIAS), carried out within the Ministry of Tourism, Handi-
crafts, and Social and Solidarity Economy, this report presents the implementation of
a Security Information and Event Management (SIEM) solution based on the open-
source tool Wazuh. The project aims to strengthen information system security by
collecting, analyzing, and correlating logs in order to detect threats in real time. Fol-
lowing an overview of the organizational context and the cybersecurity challenges,
a state-of-the-art study compares several open-source SIEM solutions, leading to
the selection of Wazuh for its advanced SIEM and XDR (Extended Detection and
Response) features. The report then details the architecture, installation, and confi-
guration of Wazuh, including the deployment of agents, the definition of custom
rules, and the activation of modules such as File Integrity Monitoring (FIM), vulne-
rability detection, active response, security configuration assessment (SCA), as well
as integration with VirusTotal for malware detection and Slack for alerts. Custom
dashboards were also developed for optimal visualization. This work highlights the
effectiveness of Wazuh in improving security posture, while also providing perspec-
tives for future integrations.

Keywords
SIEM, Wazuh, cybersecurity, logs, threat detection, active response, integration,
open source.

iii
Table des matières

Remerciements i

Résumé ii

Abstract iii

Tableau des figures vii

Liste des tableaux viii

Liste des sigles et acronymes ix

Introduction générale 1

1 Cadre Général du Projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 2
1.2.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Missions et attributions–Tourisme . . . . . . . . . . . . . . . 2
1.2.3 Missions et attributions–Artisanat et Economie Sociale et So-
lidaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.4 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.5 Présentation de la Division des Systèmes d’Information . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Problématiques du projet . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Méthodologie de travail adoptée . . . . . . . . . . . . . . . . . . . . . 7
1.6 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 État de l’art 10
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Fonctionne la technologie SIEM . . . . . . . . . . . . . . . . . . . . . 10
2.4 Les avantages du SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Fonctionnement technique d’un SIEM . . . . . . . . . . . . . . . . . . 12
2.5.1 Collecte des logs avec des agents . . . . . . . . . . . . . . . . . 12
2.5.2 Transmission sécurisée des données . . . . . . . . . . . . . . . 12

iv
 2.5.3 Normalisation et unification des formats . . . . . . . . . . . . 13
2.5.4 Corrélation et analyse intelligente . . . . . . . . . . . . . . . . 13
2.5.5 Déclenchement d’alertes . . . . . . . . . . . . . . . . . . . . . 13
2.5.6 Stockage des logs et visualisation . . . . . . . . . . . . . . . . 13
2.5.7 Génération de rapports et conformité . . . . . . . . . . . . . . 13
2.6 Comparaison des solutions SIEM open source . . . . . . . . . . . . . 13
2.6.1 Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6.2 ELK Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.3 OSSIM (AlienVault) . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.4 SIEMonster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Choix de Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Présentation de Wazuh 16
3.1 Fonctionnalités de Wazuh . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Fonctionnalités SIEM . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Fonctionnalités XDR . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Architecture de Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Explication de l’architecture . . . . . . . . . . . . . . . . . . 17
3.3 Installation de Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Exigences Matériel . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2 Méthodes d’Installations . . . . . . . . . . . . . . . . . . . . . 21
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Mise en Place de Wazuh 22

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Installation et configuration . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 Changement de Mot de Passe . . . . . . . . . . . . . . . . . . 22
4.2.2 Déployer les agents . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Configuration des politiques de sécurité efficaces . . . . . . . . . . . . 26
4.3.1 Définir les règles de détection . . . . . . . . . . . . . . . . . . 26
4.4 Activation des modules avancés de Wazuh . . . . . . . . . . . . . . . 29
4.4.1 File Integrity Monitoring (FIM) . . . . . . . . . . . . . . . . . 29
4.4.2 Détecteur de vulnérabilités . . . . . . . . . . . . . . . . . . . . 31
4.4.3 Réponse Active . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.4 Security configuration assessment . . . . . . . . . . . . . . . . 34
4.4.5 VirusTotal pour détecter les logiciels malveillants en temps
réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.6 Intégration Slack . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.7 Creation des tableaux de bord personnalisés . . . . . . . . . . 45
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Bibliographie 49

Bibliographie 49

v
Tableau des figures

1.1 Les organismes sous tutelle du ministère . . . . . . . . . . . . . . . . 4

1.2 Organigramme du ministère du Tourisme . . . . . . . . . . . . . . . . 5
1.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Diagramme du Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Schéma du fonctionnement d’un SIEM . . . . . . . . . . . . . . . . . 11

3.1 wazuh Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Commande d’installation de Wazuh . . . . . . . . . . . . . . . . . . . 22
4.2 Sortie de l’installation de Wazuh . . . . . . . . . . . . . . . . . . . . 22
4.3 Commande de réinitialisation du mot de passe . . . . . . . . . . . . . 23
4.4 Tableau de bord principal de Wazuh . . . . . . . . . . . . . . . . . . 23
4.5 Page d’ajout d’un agent Windows . . . . . . . . . . . . . . . . . . . . 24
4.6 Configuration du serveur et du nom de l’agent . . . . . . . . . . . . . 24
4.7 Commande PowerShell pour installer l’agent Windows . . . . . . . . 25
4.8 Commande d’installation de l’agent Linux . . . . . . . . . . . . . . . 25
4.9 Liste des agents déployés . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.10 Règles personnalisées pour Windows . . . . . . . . . . . . . . . . . . 27
4.11 Règles personnalisées pour Windows . . . . . . . . . . . . . . . . . . 27
4.12 Test de règle avec commande net user . . . . . . . . . . . . . . . . . . 28
4.13 Alertes générées par les règles Windows . . . . . . . . . . . . . . . . . 28
4.14 Règles personnalisées pour Linux . . . . . . . . . . . . . . . . . . . . 29
4.15 Règles personnalisées pour Active Directory . . . . . . . . . . . . . . 29
4.16 Configuration FIM dans [Link] pour Windows . . . . . . . . . . . 30
4.17 Alertes FIM pour modifications de fichiers . . . . . . . . . . . . . . . 30
4.18 Détails des alertes FIM . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.19 Ajout de reportc hangesdanssyscheck . . . . . . . . . . . . . . . . . . 31
4.20 Alerte FIM avec diff de contenu . . . . . . . . . . . . . . . . . . . . . 31
4.21 Configuration FIM pour Linux . . . . . . . . . . . . . . . . . . . . . . 31
4.22 Création de fichier test pour FIM . . . . . . . . . . . . . . . . . . . . 32
4.23 Alerte FIM pour fichier ajouté . . . . . . . . . . . . . . . . . . . . . . 32
4.24 Tableau de bord des vulnérabilités . . . . . . . . . . . . . . . . . . . . 32
4.25 Configuration de la réponse active dans [Link] . . . . . . . . . . . 34
4.26 Test de connexion échouée pour réponse active . . . . . . . . . . . . . 34
4.27 Alerte de compte désactivé et IP bloquée . . . . . . . . . . . . . . . . 34
4.28 Configuration SCA dans [Link] . . . . . . . . . . . . . . . . . . . 35
4.29 Test SCA par suppression de fichier . . . . . . . . . . . . . . . . . . . 35
4.30 Alerte SCA pour non-conformité . . . . . . . . . . . . . . . . . . . . . 35
4.31 Balise MITRE dans les règles personnalisées . . . . . . . . . . . . . . 36

vi
4.32 Configuration VirusTotal dans [Link] pour Linux . . . . . . . . . 36
4.33 Configuration du répertoire FIM pour VirusTotal . . . . . . . . . . . 37
4.34 Règle personnalisée pour analyse VirusTotal . . . . . . . . . . . . . . 37
4.35 Test avec fichier EICAR pour VirusTotal . . . . . . . . . . . . . . . . 38
4.36 Alerte VirusTotal pour fichier malveillant détecté . . . . . . . . . . . 38
4.37 Configuration VirusTotal dans [Link] pour Windows . . . . . . . 38
4.38 Installation de Python pour script de test . . . . . . . . . . . . . . . 39
4.39 Configuration de la réponse active . . . . . . . . . . . . . . . . . . . . 39
4.40 Les régles personnalisées . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.41 Alerte VirusTotal pour fichier malveillant détecté . . . . . . . . . . . 40
4.42 Configuration du fichier [Link] . . . . . . . . . . . . . . . . . . . 40
4.43 Installation du python . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.44 Installation de PyInstaller . . . . . . . . . . . . . . . . . . . . . . . . 41
4.45 Création du script Python . . . . . . . . . . . . . . . . . . . . . . . . 42
4.46 Création des règles personnalisées . . . . . . . . . . . . . . . . . . . . 42
4.47 L’integration avec virustotal . . . . . . . . . . . . . . . . . . . . . . . 42
4.48 Activation de la réponse active . . . . . . . . . . . . . . . . . . . . . . 43
4.49 Téléchargement du fichier de test EICAR . . . . . . . . . . . . . . . . 43
4.50 L’interface des alertes Wazuh . . . . . . . . . . . . . . . . . . . . . . 43
4.51 Creation du compte slack . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.52 Creation du canal slack . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.53 Creation d’application slack . . . . . . . . . . . . . . . . . . . . . . . 45
4.54 Configuration slack dans [Link] . . . . . . . . . . . . . . . . . . . 45
4.55 Les alertes VirusTotal via slack . . . . . . . . . . . . . . . . . . . . . 45
4.56 Tableau de bord personnalisé . . . . . . . . . . . . . . . . . . . . . . 46

vii
Liste des tableaux

3.1 Configuration matérielle par défaut . . . . . . . . . . . . . . . . . . . 20

3.2 Exigences matérielles en fonction du nombre d’agents . . . . . . . . . 20
3.3 Versions de système d’exploitation recommandées par Wazuh . . . . . 21

viii
Liste des sigles et acronymes

Sigle Définition
ENSIAS École Nationale Supérieure d’Informatique et d’Analyse des
Systèmes
SSI Sécurité des Systèmes d’Information
SIEM Security Information and Event Management (Gestion des In-
formations et des Événements de Sécurité)
SIM Security Information Management (Gestion des Informations
de Sécurité)
SEM Security Event Management (Gestion des Événements de Sé-
curité)
SOC Security Operations Center (Centre d’Opérations de Sécurité)
EDR Endpoint Detection and Response (Détection et Réponse aux
Points d’Extrémité)
XDR Extended Detection and Response (Détection et Réponse
Étendues)
SOAR Security Orchestration, Automation and Response (Orchestra-
tion, Automatisation et Réponse en Sécurité)
IDS Intrusion Detection System (Système de Détection d’Intru-
sion)
IPS Intrusion Prevention System (Système de Prévention d’Intru-
sion)
HIDS Host-based Intrusion Detection System (Système de Détection
d’Intrusion Basé sur l’Hôte)
NIDS Network-based Intrusion Detection System (Système de Dé-
tection d’Intrusion Basé sur le Réseau)
OSSEC Open Source HIDS SECur (Système de Détection d’Intrusion
Open Source Sécurisé)
UM5R Université Mohamed V de Rabat

ix
Introduction générale

Dans un monde numérique en constante évolution, où les menaces cybernétiques

se multiplient et deviennent de plus en plus sophistiquées, la sécurisation des sys-
tèmes d’information est devenue une priorité absolue pour les organisations pu-
bliques et privées. Les attaques informatiques, telles que les intrusions, les malwares
ou les fuites de données, peuvent entraîner des conséquences graves, allant de pertes
financières à des atteintes à la réputation. C’est dans ce contexte que les systèmes
SIEM (Security Information and Event Management) émergent comme des outils
essentiels, permettant une surveillance proactive et une réponse rapide aux incidents.
Ce rapport de stage, réalisé dans le cadre de la filière Sécurité des Systèmes
d’Information à l’ENSIAS, documente mon expérience au sein du Ministère du Tou-
risme, de l’Artisanat et de l’Économie Sociale et Solidaire. Le projet porte sur la
mise en place d’une solution SIEM basée sur Wazuh, un outil open source polyvalent
intégrant des fonctionnalités SIEM et XDR. L’objectif principal est de renforcer la
capacité du ministère à détecter et à gérer les menaces en temps réel, en s’appuyant
sur une collecte et une analyse intelligente des logs.
Le premier chapitre présente le cadre général du projet, incluant la présentation
de l’organisme d’accueil, le contexte et les objectifs du stage, ainsi que la méthodo-
logie adoptée.
Le deuxième chapitre expose l’état de l’art des technologies SIEM, avec une com-
paraison des solutions open source et la justification du choix de Wazuh.
Le troisième chapitre détaille la présentation de Wazuh, ses fonctionnalités, son
architecture et les méthodes d’installation.
Le quatrième chapitre décrit la mise en œuvre pratique, de l’installation à l’acti-
vation des modules avancés. Des références et annexes complètent ce document.
À travers ce travail, je vise non seulement à démontrer l’apport concret de cette
solution, mais aussi à contribuer à une meilleure compréhension des enjeux de la
cybersécurité dans un environnement administratif.

1
Chapitre 1

Cadre Général du Projet

1.1 Introduction
Dans ce chapitre, nous présentons d’abord l’établissement d’accueil au sein du-
quel notre stage a été accompli,par une description générale, des objectifs et du
domaine d’activité, ensuite nous allons étudier les problématiques posées, nous pré-
senteronsla solution adoptée pour ces derniers. Enfin la méthodologie de travail
employée.

1.2 Présentation de l’organisme d’accueil

1.2.1 Présentation générale
Le Ministère du Tourisme, de l’Artisanat et de l’Économie Sociale et Solidaire
est une institution gouvernementale marocaine chargée de l’élaboration, de la mise
en œuvre et du suivi des politiques publiques dans les domaines du tourisme, de
l’artisanat et de l’économie sociale et solidaire.

1.2.2 Missions et attributions–Tourisme

La mission du Ministère du Tourisme, de l’Artisanat et de l’Economie Sociale
et Solidaire est définie par l’article 1 du Décret n°2.08.651 du 15 Juin 2009, relatif
à l’organisation et aux attributions du Ministère du Tourisme, qui stipule que : «
l’Autorité gouvernementale chargée du Tourisme a pour mission d’élaborer et de
mettre en œuvre la politique gouvernementale en matière de Tourisme ».
A cet effet, Il est chargé notamment, en coordination avec les administrations
concernées, de :
— Elaborer, mettre en œuvre et évaluer la stratégie du développement touris-
tique.
— Mener les études et enquêtes nécessaires au développement du tourisme aussi
bien au niveau national que régional.
— Elaborer les projets de lois et les textes réglementaires relatifs aux activités
de tourisme et veiller à leur application.
— Encadrer et assurer l’appui aux professions et aux activités touristiques confor-
mément à la réglementation en vigueur.

2
 — Orienter et contrôler les services déconcentrés et évaluer les moyens néces-
saires à leur fonctionnement.
— Participer à l’élaboration et au pilotage de la stratégie de formation hôtelière
et touristique.
— Encadrer les établissements de formation relevant du Ministère du Tourisme.
— Veiller à l’établissement et au renforcement des relations dans le cadre de la
coopération bilatérale ainsi qu’avec les organisations spécialisées.
— Assurer la tutelle des établissements relevant du département du Tourisme.

1.2.3 Missions et attributions–Artisanat et Economie Sociale

et Solidaire
Le Ministère est chargé de préparer et de mettre en œuvre la politique du gou-
vernement relative au secteur de l’artisanat. Il est notamment chargé de :
— Mettre en œuvre la stratégie de développement du secteur de l’artisanat.
— Animer l’économie des entreprises artisanales.
— Réaliser toutes les études, enquêtes et statistiques relatives au secteur de
l’artisanat, tant au niveau national que régional.
— Mettre en place et exécuter des programmes d’action dans le cadre de la
coopération internationale susceptible de contribuer au développement du
secteur.
— Apporter un soutien aux chambres d’artisanat et à leur fédération, en plus
d’assurer le suivi de leurs activités.
— Exercer la tutelle sur les établissements publics relevant du domaine d’attri-
bution du secteur de l’artisanat.

1.2.4 Organisation
Les organismes sous tutelle du Ministère du Tourisme sont les sui-
vants :

3
 Figure 1.1 – Les organismes sous tutelle du ministère

Le Ministère du Tourisme comporte plusieurs structures principales, chacune

étant responsable de missions spécifiques et complémentaires aux autres :
1. Inspection Générale : chargée du contrôle interne, de l’audit et de l’évaluation
des actions du ministère.
2. Cabinet du Ministre : assure l’accompagnement direct du Ministre, le suivi
des dossiers stratégiques et la coordination avec les autres instances gouver-
nementales.
3. Secrétariat Général : joue un rôle central dans la gestion administrative et
organisationnelle du ministère, en assurant la coordination des directions et
unités.
4. Unité des affaires juridiques : responsable de l’étude et du traitement des
questions juridiques, de la préparation des textes législatifs et réglementaires
et de l’appui juridique aux différentes structures.
5. Direction de la Stratégie et de la Coopération : s’occupe de la planification
stratégique, de la coopération nationale et internationale et de l’évaluation
des programmes et publications.

4
 6. Direction de la Réglementation, du Développement et de la Qualité : veille à
l’application des réglementations, au développement des activités touristiques
et artisanales, ainsi qu’à l’encadrement et au soutien des opérateurs.
7. Direction des Ressources et de la Formation : gère la formation profession-
nelle dans le secteur du tourisme, les systèmes d’information, les ressources
humaines, ainsi que le support logistique et financier.

Figure 1.2 – Organigramme du ministère du Tourisme

1.2.5 Présentation de la Division des Systèmes d’Information

La division des Systèmes d’information au Ministère du Tourisme est
organisée en trois services :
• Service du développement des systèmes d’information
• Service Réseaux et Système d’Information
• Service Maintenance et Logistique Informatique
Le Responsable de la Sécurité des Systèmes d’Information (RSSI)
rattaché au secrétariat général est en relation continue avec la Division
des Systèmes d’Information.

5
1.3 Présentation du projet
1.3.1 Contexte du projet
Le projet sur lequel je travaille a pour objectif la mise en place d’un SIEM
(Security Information and Event Management) basé sur Wazuh. Ce système
permet de centraliser, corréler et analyser en temps réel les journaux d’événements
collectés depuis différentes machines grâce à des agents déployés sur des systèmes
Windows et Linux.
L’architecture repose sur l’installation et la configuration du serveur Wazuh (ma-
nager, indexer et dashboard), ainsi que sur l’intégration des agents assurant la re-
montée des logs de sécurité et des informations système.
Cette solution contribue à améliorer la détection des menaces, la surveillance
de l’infrastructure, la gestion des vulnérabilités et la conformité réglementaire, tout
en offrant aux administrateurs une visibilité complète et centralisée sur l’état de
sécurité du système d’information.

1.3.2 Problématiques du projet

La sécurisation des systèmes d’information constitue aujourd’hui un enjeu majeur
face à l’augmentation constante des menaces informatiques et à la complexité des
environnements technologiques.
Les organisations doivent traiter un volume important de journaux d’événements
générés par des machines hétérogènes, ce qui rend leur analyse manuelle difficile et
chronophage. Dans ce contexte, l’absence d’un outil centralisé de supervision et de
corrélation des données de sécurité limite la capacité à détecter rapidement des
intrusions, à identifier des vulnérabilités et à assurer la conformité aux exigences
réglementaires.
Ainsi, la mise en place d’une solution SIEM basée sur Wazuh répond à ce
besoin en offrant une visibilité globale sur l’infrastructure, en facilitant la dé-
tection des menaces et en améliorant la réactivité face aux incidents de
sécurité.

1.3.3 Objectif du projet

Ce projet vise à explorer et à implémenter Wazuh en tant que solution SIEM
open-source afin de démontrer son efficacité dans la surveillance et la protection des
infrastructures informatiques.
Les objectifs spécifiques sont :
1. Comprendre et documenter le fonctionnement d’un SIEM à travers
l’étude de Wazuh, en explorant ses modules tels que la détection d’intrusions,
la surveillance de l’intégrité des fichiers, et l’analyse des logs Windows et
Linux.
2. Déployer une infrastructure SIEM complète avec Wazuh, incluant
l’installation et la configuration des agents sur serveurs Linux et Windows,
la collecte des logs, la configuration des règles personnalisées, et l’activation
des modules avancés comme FIM, Rootkit Detection, Vulnerability Detector
et Active Response.

6
 3. Analyser des scénarios d’attaques simulées(tentatives de connexion
SSH échouées, élévation de privilèges, scans de ports, attaques Kerberos, mo-
difications de comptes Active Directory) afin d’évaluer la capacité de Wazuh
à détecter, alerter et réagir aux incidents de sécurité.
4. Proposer des pistes d’améliorationen optimisant les règles de détection,
la pertinence des alertes, les tableaux de bord Kibana, et la configuration des
réponses automatiques aux incidents.
5. Évaluer les avantages et limites de Wazuhsur la base de son déploie-
ment, de la qualité des alertes générées, de sa capacité à corréler les événe-
ments avec MITRE ATT&CK, et de son adaptabilité à différents environne-
ments, incluant la gestion de serveurs Windows, Linux et Active Directory.
Ce projet s’inscrit dans un contexte où la gestion proactive de la sécurité
informatique est essentielle pour faire face à l’augmentation des cybermenaces.
L’utilisation d’un SIEM performant et bien configuré permet de réduire le temps
de réponse aux incidents, d’améliorer la visibilité sur les menaces et d’assurer la
conformité aux normes et bonnes pratiques de sécurité.

1.4 Méthodologie de travail

1.5 Méthodologie de travail adoptée
Dans le cadre de ce projet, une méthodologie inspirée d’Agile Scrum a été
adoptée. Bien qu’il s’agisse d’un projet individuel, cette approche s’est révélée adap-
tée grâce à sa flexibilité et à sa capacité à s’ajuster continuellement aux besoins
évolutifs.
En mettant l’accent sur une communication ouverte avec l’encadrante et une
adaptation constante aux nouvelles contraintes, cette méthodologie a permis de
suivre de près les avancées et d’ajuster rapidement les actions entreprises. Chaque
itération du travail a donné lieu à un livrable concret (installation de la solution,
configuration des règles, activation des modules avancés, mise en place des tableaux
de bord, etc.), validé progressivement par l’encadrante.
Cette approche favorise ainsi l’agilité et l’efficacité dans la réalisation du projet,
tout en garantissant une amélioration continue jusqu’à l’obtention d’une solution
pleinement opérationnelle.

7
 Figure 1.3 – Scrum

1.6 Planification
Diagramme du Gantt

Un diagramme de Gantt est un outil de gestion de projet qui permet de

visualiser les tâches d’un projet sur une échelle de temps, facilitant ainsi
la planification et le suivi de l’avancement.

Figure 1.4 – Diagramme du Gantt

1.7 Conclusion
Ce chapitre a permis de présenter le cadre général du projet et de situer le
contexte de mon stage au sein du Ministère du Tourisme, de l’Artisanat et de l’Éco-
nomie Sociale et Solidaire. Nous avons décrit l’établissement d’accueil, ses missions
ainsi que son organisation, avant d’exposer les problématiques liées à la sécurité
informatique. Les objectifs du projet, qui consistent à mettre en place un système

8
SIEM basé sur Wazuh, ont été clairement définis, tout comme la méthodologie de
travail et la planification adoptées pour sa réalisation.

9
Chapitre 2

État de l’art

2.1 Introduction
Dans un paysage numérique en constante évolution, les menaces cybernétiques
exigent des solutions robustes pour protéger les systèmes d’information. Ce chapitre,
intitulé “État de l’Art sur les Systèmes SIEM”, propose une analyse approfondie des
Systèmes de Gestion des Informations et des Événements de Sécurité (SIEM). Il
explore leur définition, leur fonctionnement technique, leurs avantages, ainsi qu’une
comparaison des solutions open source disponibles, afin de dresser un panorama
actuel et éclairé de ces outils essentiels pour la sécurité des entreprises.

2.2 Définition
Un système de gestion des informations et des événements de sécurité (SIEM
pour security information and event management) réunit la gestion des informations
de sécurité (SIM) et la gestion des événements de sécurité (SEM) en une solution
de sécurité complète permettant de détecter les menaces et garantir la conformité.
Pour aller plus loin, un SIM collecte, analyse et gère les données des journaux et des
événements des systèmes hôtes ou des applications, tandis qu’un SEM se concentre
sur la surveillance et l’analyse des événements de sécurité en temps réel.

2.3 Fonctionne la technologie SIEM

La technologie SIEM collecte des données (ou journaux), telles que les identifiants
de connexion, les fichiers consultés ou les sites web visités, à partir des systèmes hôtes
et des applications de l’organisation, puis rassemble tous les journaux et vérifie s’il
existe des schémas étranges ou des signes d’un incident de sécurité. De plus en
plus, les SIEM exploitent l’IA en tant qu’analystes automatisés qui regroupent et
hiérarchisent les incidents. Si un incident de sécurité est détecté, le système SIEM
envoie une alerte à l’équipe de sécurité. L’équipe de sécurité utilise alors les outils
du système SIEM pour approfondir ses recherches.

10
 Figure 2.1 – Schéma du fonctionnement d’un SIEM

Le fonctionnement d’un SIEM est comme suite :

1. Collects data (Collecte des données)
Le SIEM récupère automatiquement les logs (journaux d’activité) prove-
nant de serveurs, appareils réseau (switch, firewall, routeur. . .), applications,
systèmes cloud, postes de travail, etc. Afin d’avoir une vue complète de tout
ce qui se passe dans le système informatique.
2. Aggregates the data (Agrégation des données)
Le SIEM centralise toutes ces données collectées dans un même endroit.
Il les regroupe et les organise, peu importe leur format d’origine. Afin de
préparer les données pour une analyse cohérente.
3. Analyzes normalized data (Analyse des données normalisées)
Une fois les données normalisées (standardisées), le SIEM cherche des ano-
malies, détecte des menaces. Afin de comprendre si une activité est normale
ou potentiellement dangereuse.
4. Investigates alerts (Investigation des alertes)
Quand une alerte est déclenchée (ex. : tentative d’intrusion, connexion
suspecte), le SIEM permet d’enquêter dessus, identifie les violations et peut
déclencher des actions (ex. bloquer un accès, envoyer une alerte à l’équipe).
Afin de réagir rapidement face à une menace.
5. Remediates discovered vulnerabilities (Correction des vulnérabili-
tés découvertes)

11
 Le SIEM peut recommander ou déclencher des actions correctives, mettre
à jour un système, corriger une mauvaise configuration et modifier des accès.
Afin de corriger les failles avant qu’elles ne soient exploitées.
6. Reports on risk and compliance (Rapports sur les risques et la
conformité)
Le SIEM génère des rapports automatiques sur les risques détectés et pour
prouver la conformité avec les lois et normes (RGPD, ISO 27001. . .). Afin de
faciliter les audits et prouver que l’entreprise est sécurisée.

2.4 Les avantages du SIEM

La technologie SIEM donne à vos analystes une visibilité sur tout l’environne-
ment IT de votre entreprise pour les aider à repérer les menaces qui échappent aux
autres moyens de détection. Une bonne solution SIEM aide les analystes à travailler
plus efficacement et permet à une entreprise de relever trois défis de sécurité ma-
jeurs : La visibilité : Un SIEM moderne fournit des informations en temps réel sur
votre posture de sécurité. Il extrait et maintient des données contextuelles sur les
utilisateurs, les appareils et les applications de tous vos environnements : locaux,
cloud, multicloud et hybrides. Munis de ces informations, il devient plus facile pour
les analystes de sécurité de repérer les acteurs malveillants et de localiser les me-
naces. Les fausses alertes : Une solution SIEM contribue à réduire le nombre de
faux positifs pour que les analystes puissent rapidement se focaliser sur l’étude des
véritables menaces, sans perdre de temps sur les fausses alertes. Les menaces po-
tentielles peuvent être identifiées, catégorisées et triées à l’aide de tableaux de bord,
puis assignées à un analyste pour qu’il les examine. La flexibilité et l’évolutivité :
De nombreuses solutions SIEM prennent en charge et s’intègrent à un large éventail
d’environnements et de technologies, et sont faites pour être utilisées par des équipes
internes et externes. Un SIEM moderne doit répondre à vos besoins aujourd’hui et
demain, en s’adaptant à l’élargissement de votre empreinte technologique.

2.5 Fonctionnement technique d’un SIEM

2.5.1 Collecte des logs avec des agents
Le SIEM commence par collecter les journaux (logs) provenant de différentes
sources : serveurs, postes, firewalls, applications, etc. Pour cela, on installe des agents
(comme l’agent Wazuh) sur les machines. Ces agents capturent toutes les activités
importantes (connexions, erreurs, accès, changements. . .) et préparent les données
pour les envoyer au serveur SIEM.

2.5.2 Transmission sécurisée des données

Une fois les données collectées, elles sont envoyées vers le serveur central du
SIEM. Cela se fait via le réseau, souvent en utilisant des protocoles sécurisés comme
TLS ou HTTPS. Selon les outils utilisés, la transmission peut aussi passer par des
systèmes de files (comme Kafka) pour gérer un grand volume de logs.

12
2.5.3 Normalisation et unification des formats
Les logs arrivent dans des formats très différents selon leur origine (Linux, Win-
dows, Apache, etc.). Le SIEM les “normalise”, c’est-à-dire qu’il les transforme dans
un format commun et compréhensible, comme du JSON. Cela permet de traiter tous
les logs de manière uniforme, même s’ils viennent de sources très variées.

2.5.4 Corrélation et analyse intelligente

Après normalisation, le SIEM applique des règles de détection pour repérer des
comportements suspects. Par exemple : “5 échecs de connexion en 2 minutes =
tentative de force brute”. Cette étape peut aussi inclure des analyses avancées avec
de l’IA ou du machine learning, qui permettent de détecter des anomalies sans avoir
besoin de règles précises.

2.5.5 Déclenchement d’alertes

Lorsque le SIEM détecte un événement anormal ou dangereux, il déclenche au-
tomatiquement une alerte. Cette alerte peut s’afficher dans le tableau de bord, être
envoyée par email ou SMS à l’équipe sécurité, ou encore activer une réaction auto-
matique (comme bloquer une adresse IP). L’objectif est d’informer rapidement pour
limiter les dégâts.

2.5.6 Stockage des logs et visualisation

Tous les logs collectés sont stockés dans une base de données sécurisée, souvent
indexée (comme Elasticsearch). Les analystes peuvent ensuite utiliser des outils gra-
phiques comme Kibana (dans le cas de Wazuh) pour visualiser les événements, filtrer
les données, explorer les incidents et créer des tableaux de bord personnalisés.

2.5.7 Génération de rapports et conformité

Le SIEM peut générer automatiquement des rapports sur les activités, les alertes,
les accès ou les incidents. Ces rapports sont essentiels pour prouver la conformité
réglementaire (ex. : RGPD, ISO 27001). L’entreprise peut programmer des rapports
hebdomadaires ou mensuels, prêts à être présentés lors d’audits.

2.6 Comparaison des solutions SIEM open source

Dans le cadre de la mise en place d’un système SIEM, plusieurs solutions open
source ont été étudiées. Parmi les plus populaires figurent : Wazuh, ELK Stack, OS-
SIM (AlienVault) et SIEMonster. Cette section présente une comparaison technique
et fonctionnelle de ces outils afin de motiver le choix final.

2.6.1 Wazuh
Wazuh est une solution SIEM open source complète, construite sur la base de
l’ELK Stack (Elasticsearch, Logstash, Kibana), à laquelle elle ajoute une couche

13
de sécurité avancée. Elle intègre des agents légers qui permettent de collecter des
logs à partir de différents systèmes (Linux, Windows, Cloud), et propose un moteur
de corrélation d’événements très puissant. Wazuh dispose également d’un système
de détection d’intrusion (HIDS), d’un tableau de bord Kibana intégré, et d’une
documentation riche et bien maintenue.

2.6.2 ELK Stack

ELK Stack est un ensemble de trois outils : Elasticsearch (moteur de recherche),
Logstash (pipeline de traitement de données) et Kibana (visualisation). C’est une so-
lution très puissante mais elle n’est pas un SIEM à elle seule. Pour en faire un SIEM,
il faut ajouter manuellement des fonctionnalités comme la corrélation, l’alerte et la
sécurité. Cela nécessite des compétences avancées et un développement personnalisé.

2.6.3 OSSIM (AlienVault)

OSSIM est une solution SIEM développée initialement par AlienVault. Elle pro-
pose des fonctionnalités intéressantes comme la gestion des vulnérabilités, la corréla-
tion d’événements et la détection d’intrusion. Cependant, elle est jugée plus lourde à
installer et à maintenir. De plus, sa communauté open source est aujourd’hui moins
active que celle de Wazuh, ce qui limite les mises à jour et le support.

2.6.4 SIEMonster
SIEMonster est une plateforme SIEM open source orientée entreprise. Elle repose
également sur l’ELK Stack et d’autres composants comme Apache NiFi. Elle propose
une interface web complète et des capacités d’automatisation avancées. Toutefois,
son installation est complexe et sa version open source est limitée par rapport à la
version commerciale.

2.7 Choix de Wazuh

Parmi toutes les solutions comparées, Wazuh se démarque pour plusieurs raisons
clés :
Facilité de déploiement : Wazuh propose des scripts d’installation rapide et
une interface conviviale via Kibana.
Fonctionnalités complètes : collecte, analyse, corrélation, détection d’intru-
sion (HIDS), alertes et rapports de conformité sont tous intégrés.
Architecture modulaire et évolutive : idéale pour les environnements petits
ou grands, locaux ou cloud.
Grande communauté et documentation claire : cela facilite l’apprentissage
et la résolution de problèmes. Mises à jour fréquentes : l’équipe de Wazuh assure
une amélioration continue du produit.

2.8 Conclusion
En conclusion, l’état de l’art des systèmes SIEM révèle leur rôle crucial dans la
détection et la gestion des menaces en temps réel, tout en assurant la conformité

14
réglementaire. Parmi les solutions open source étudiées, Wazuh se distingue par sa
facilité d’installation, ses fonctionnalités complètes et son support communautaire
actif. Cette analyse met en lumière l’importance d’adopter un SIEM adapté pour
renforcer la résilience des organisations face aux défis croissants de la cybersécurité,
offrant ainsi une base solide pour des décisions stratégiques futures.

15
Chapitre 3

Présentation de Wazuh

Introduction
Face à l’évolution rapide des cybermenaces, une solution de sécurité centralisée
est essentielle pour les organisations. Wazuh, plateforme open source de type SIEM
(Security Information and Event Management) et XDR (Extended Detection and
Response), permet l’analyse en temps réel des données de télémétrie provenant des
endpoints, des réseaux et du cloud. Ce chapitre présente les fonctionnalités clés de
Wazuh, son architecture modulaire, ses exigences matérielles et les étapes de base
pour son installation, posant ainsi les fondations pour une compréhension approfon-
die avant d’aborder les configurations avancées.

3.1 Fonctionnalités de Wazuh

Wazuh combine des capacités SIEM et XDR pour une protection globale :

3.1.1 Fonctionnalités SIEM

— Analyse des journaux de sécurité : Surveillance en temps réel des logs
système et applicatifs.
— Évaluation de la configuration de sécurité : Vérification des conformités
via des benchmarks.
— Détection de vulnérabilités : Identification des failles connues dans les
systèmes.
— Conformité réglementaire : Rapports pour répondre aux normes (ex. :
GDPR, PCI-DSS).

3.1.2 Fonctionnalités XDR

— Chasse aux menaces : Recherche proactive des anomalies.
— Analyse comportementale : Détection des écarts inhabituels.
— Réponse automatisée (active) : Actions immédiates (blocage IP, arrêt
processus).
— Renseignement sur les menaces : Intégration de bases comme MITRE
ATT&CK.
— Conformité et reporting : Documentation pour audits.

16
3.2 Architecture de Wazuh

Figure 3.1 – wazuh Architecture .

.

Wazuh repose sur une architecture distribuée et modulaire :

— Agents Wazuh : Installés sur les endpoints (Linux, Windows, macOS, conte-
neurs), ils collectent des données système et applicatives, les transmettant
chiffrées au serveur.
— Serveur Wazuh : Centralise l’analyse, gère les agents et intègre des outils
comme Filebeat.
— Indexeur Wazuh : Stocke les données (alertes, archives, monitoring) via
OpenSearch.
— Tableau de Bord Wazuh : Interface web pour visualiser et gérer les alertes.

3.2.1 Explication de l’architecture

Architecture de l’agent
L’agent Wazuh : est compatible avec plusieurs systèmes d’exploitation (Li-
nux, Windows, macOS, etc.) et protège différents types d’environnements (serveurs,
postes, cloud, VM, conteneurs). Il assure la prévention, la détection et la réponse
aux menaces, tout en collectant des données système et applicatives, transmises de
manière chiffrée au serveur Wazuh.
L’agent Wazuh adopte une architecture modulaire, où chaque module remplit
une fonction précise (surveillance de fichiers, journaux, inventaire, détection de mal-
wares). Les utilisateurs peuvent personnaliser son fonctionnement en activant ou
désactivant les modules via la configuration, selon leurs besoins.

Modules d’agent
L’agent Wazuh, grâce à son architecture modulaire configurable, permet aux uti-
lisateurs d’activer uniquement les composants nécessaires à leur stratégie de sécurité.
Chaque module assure une fonction spécifique :

17
 — Collecteur de journaux : Lit les fichiers journaux et les événements Win-
dows, en collectant les messages du journal du système d’exploitation et des
applications. Prend en charge les filtres XPath et reconnaît les formats mul-
tilignes.
— Exécution de commandes : Exécute périodiquement les commandes au-
torisées, rapportant les résultats au serveur Wazuh pour analyse. Utile pour
des tâches telles que la surveillance de l’espace disque ou la récupération des
journaux utilisateur.
— Surveillance de l’intégrité des fichiers (FIM) : Surveille le système de
fichiers, signale les modifications en temps réel et tient à jour une base de
données des états des fichiers pour les requêtes à distance.
— Évaluation de la configuration de la sécurité (SCA) : Offre une éva-
luation continue de la configuration basée sur des benchmarks prédéfinis. Les
utilisateurs peuvent créer des vérifications personnalisées pour appliquer les
stratégies de sécurité.
— Inventaire du système : Analyse et collecte périodiquement les données
d’inventaire, y compris la version du système d’exploitation, les détails du
réseau, les processus en cours d’exécution, les applications installées et les
ports ouverts.
— Détection des logiciels malveillants : Utilise une approche non basée sur
les signatures pour détecter les anomalies, les rootkits, les processus cachés,
les fichiers et les ports tout en surveillant les appels système.
— Réponse active : Prend des mesures automatiques lorsque des menaces sont
détectées, comme le blocage des connexions réseau, l’arrêt des processus ou
la suppression des fichiers malveillants. Les utilisateurs peuvent personnaliser
les réponses.

Architecture de serveur
Le serveur Wazuh : joue un rôle central dans l’analyse des données des agents :
il détecte les menaces, gère les configurations et assure la conformité réglementaire.
Grâce à l’intégration de renseignements sur les menaces (comme MITRE ATTCK)
et à sa compatibilité avec des outils externes (ServiceNow, Jira, PagerDuty, Slack),
il renforce l’efficacité des opérations de sécurité.
Le serveur Wazuh, exécuté sur Linux, regroupe le moteur d’analyse, l’API RES-
Tful, les services d’inscription et de connexion des agents, le démon de cluster et
Filebeat. Il peut être déployé sur des machines physiques, virtuelles, des conteneurs
Docker ou dans le cloud.

Composants du serveur
— Service d’inscription d’agents : Inscrit de nouveaux agents, en fournissant
des clés d’authentification uniques via un service réseau prenant en charge
les certificats TLS/SSL ou les mots de passe fixes.
— Service de connexion de l’agent : Reçoit les données des agents, valide
l’identité de l’agent, crypte les communications et facilite la gestion centralisée
de la configuration.
— Moteur d’analyse : Effectue l’analyse des données, à l’aide de décodeurs
pour identifier les types d’informations et les règles afin de détecter les mo-

18
 dèles déclenchant des alertes ou des contre-mesures automatisées.
— API RESTful de Wazuh : Gère les paramètres de configuration, surveille
l’état de l’infrastructure, modifie les décodeurs et les règles, et facilite les
interactions avec le tableau de bord Wazuh.
— Wazuh Cluster Daemon : Met à l’échelle les serveurs horizontalement,
ce qui permet le clustering pour une haute disponibilité et l’équilibrage de
charge, facilitant ainsi la communication entre les serveurs.
— Filebeat : Envoie des événements et des alertes à l’indexeur Wazuh, en li-
sant les résultats du moteur d’analyse en temps réel et en prenant en charge
l’équilibrage de charge dans les configurations à plusieurs nœuds.

Architecture de L’Indexeur Wazuh

L’indexeur Wazuh : est un moteur de recherche et d’analyse scalable qui
indexe les alertes du serveur Wazuh sous forme de documents JSON. Déployable en
cluster (mono- ou multi-nœuds), il assure redondance et tolérance aux pannes. Il
utilise quatre index distincts pour organiser différents types d’événements.
— wazuh-alerts : Stocke les alertes générées par le serveur Wazuh. Créé lors-
qu’un événement déclenche une règle avec une priorité configurable.
— wazuh-archives : Stocke tous les événements (données archivées) reçus par
le serveur Wazuh, qu’ils déclenchent une règle ou non.
— wazuh-monitoring : Stocke les données liées à l’état des agents Wazuh au
fil du temps. Utilisé par l’interface web pour représenter l’état des agents.
— wazuh-statistics : Stocke les données relatives aux performances du serveur
Wazuh. Utilisé par l’interface web pour afficher les statistiques de perfor-
mance.

Architecture du Tableau de bord Wazuh

Le tableau de bord Wazuh : est une interface utilisateur Web complète qui
fournit une représentation visuelle des informations et des informations relatives à
la sécurité recueillies par l’infrastructure Wazuh. Il sert de hub centralisé pour la
surveillance et la gestion de la posture de sécurité de votre environnement.

Composants du tableau de bord

— Aperçu : Offre un aperçu de l’état général de la sécurité, en mettant en
évidence les indicateurs clés et les événements de sécurité récents.
— Analyse des incidents : Fournit une analyse approfondie des incidents de
sécurité, offrant des détails sur les menaces détectées, les anomalies et les
actions de réponse.
— Statut de l’agent : Affiche l’état en temps réel des agents Wazuh, indiquant
leur activité, leur connectivité ou toute déconnexion.
— Résumé des règles et des alertes : Résume les règles déclenchées et les
alertes générées, ce qui permet d’identifier rapidement les événements de sé-
curité critiques.
— Statistiques de performance : Présente les mesures de performance du
serveur Wazuh, aidant à l’évaluation de son efficacité opérationnelle.

19
 — Tableaux de bord personnalisables : Permet aux utilisateurs de person-
naliser les tableaux de bord en fonction de leurs priorités de sécurité spéci-
fiques et de leurs centres d’intérêt.
Le tableau de bord Wazuh sert de point central aux analystes et aux administra-
teurs de sécurité pour obtenir des informations exploitables, répondre rapidement
aux incidents et maintenir une posture de sécurité proactive.

3.3 Installation de Wazuh

3.3.1 Exigences Matériel
Les exigences suivantes doivent être respectées avant que la VM Wazuh puisse
être importée dans un système d’exploitation hôte :
— Le système d’exploitation hôte doit être un système 64 bits avec une archi-
tecture x86_64/AMD64 ou AARCH64/ARM64.
— La virtualisation matérielle doit être activée dans le firmware de l’hôte.
— Une plateforme de virtualisation, telle que VirtualBox, doit être installée sur
le système hôte.
Par défaut, la VM Wazuh est configurée avec les spécifications suivantes :

Component CPU (cores) RAM (GB) Storage (GB)

Wazuh v4.12.0 OVA 4 8 50

Table 3.1 – Configuration matérielle par défaut

Cependant, cette configuration matérielle peut être modifiée en fonction du

nombre de terminaux protégés et des données d’alertes indexées.

Agents CPU (cores) RAM (GB) Storage (90 days)

1–25 4 vCPU 8 GiB 50 GB

25–50 8 vCPU 8 GiB 100 GB

50–100 8 vCPU 8 GiB 200 GB

Table 3.2 – Exigences matérielles en fonction du nombre d’agents

Les composants centraux de Wazuh nécessitent un processeur Linux 64 bits Intel,

AMD ou ARM (architecture x86_64/AMD64 ou AARCH64/ARM64) pour fonc-
tionner. Wazuh recommande l’une des versions de système d’exploitation suivantes :

20
Amazon Linux 2, Amazon Linux 2023 CentOS 7, 8

Red Hat Enterprise Linux 7, 8, 9 Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04

Table 3.3 – Versions de système d’exploitation recommandées par Wazuh

3.3.2 Méthodes d’Installations

Trois méthodes sont disponibles :
— Machine prête à l’emploi : Téléchargement d’une VM depuis le site officiel.
— Script officiel : Automatisation via
curl -sO [Link]
sudo bash ./[Link] -a

Cela installe tous les composants avec un mot de passe par défaut à modifier.
— Installation manuelle : Étape par étape pour l’indexeur, le serveur et le
dashboard.

3.4 Conclusion
Ce chapitre a présenté les fondamentaux de Wazuh, de ses capacités SIEM et
XDR à son architecture modulaire et à ses exigences d’installation. Ces éléments
constituent une base solide pour exploiter Wazuh efficacement dans la sécurisation
des environnements informatiques.

21
Chapitre 4

Mise en Place de Wazuh

4.1 Introduction
Ce chapitre présente la mise en œuvre opérationnelle de Wazuh au sein du mi-
nistère, incluant l’installation, la configuration initiale, le déploiement des agents
sur Windows et Linux, la définition de règles personnalisées et l’activation de mo-
dules avancés tels que FIM, détection de vulnérabilités, réponse active, SCA, ainsi
que l’intégration avec VirusTotal et Slack. L’objectif est de concrétiser les concepts
théoriques abordés précédemment et de démontrer l’efficacité de Wazuh dans un
environnement réel.

4.2 Installation et configuration

Après l’installation de la machine vertuelle ubuntu on commence l’installation
de wazuh en utilisant le script offeciel.

Figure 4.1 – Commande d’installation de Wazuh

Figure 4.2 – Sortie de l’installation de Wazuh

L’installation de wazuh est réussite on a donc le nom d’utilisateur et le mot de

passe pour se connecter.

4.2.1 Changement de Mot de Passe

Pour sécuriser l’installation initiale de Wazuh, il est impératif de modifier le mot
de passe par défaut de l’utilisateur admin en utilisant les commandes suivantes :

22
cd /usr/share/wazuh-indexer/plugins/opensearch-security/tools/
bash [Link] -u admin -p Secr3tP4ssw*rd
systemctl restart filebeat
systemctl restart wazuh-dashboard

Figure 4.3 – Commande de réinitialisation du mot de passe

Le mot de passe est maintenant modifié. On peut accéder à Wazuh en toute

sécurité. Cette étape prévient les accès non autorisés et assure une base solide pour
les configurations ultérieures.

4.2.2 Déployer les agents

Figure 4.4 – Tableau de bord principal de Wazuh

Lorsqu’on accède a wazuh on peux déployer des agents, dans le cas de notre
projet on fait le déploiement des agents windows, linux et aussi l’acive directory.

déploiement des agents windows

23
 Figure 4.5 – Page d’ajout d’un agent Windows

Figure 4.6 – Configuration du serveur et du nom de l’agent

Le déploiement d’un agent Windows s’effectue via une interface web intuitive,
commençant par la configuration du serveur, ici identifié comme [Link]. Une
étape essentielle consiste à attribuer un nom unique à l’agent, pour assurer sa dis-
tinction

24
 Figure 4.7 – Commande PowerShell pour installer l’agent Windows

Le processus inclut l’exécution d’une commande PowerShell pour télécharger et

installer l’agent, avec des options de personnalisation disponibles. Des privilèges ad-
ministrateurs et une version de PowerShell 3.0 ou supérieure sont requis pour mener
à bien l’opération. Enfin, le démarrage de l’agent est activé grâce à la commande
"NET START WazuhSvc", marquant la mise en service complète.

déploiement des agents Linux

Pour les agents Linux, nous avons suivi le même processus que pour Windows.
La seule différence est qu’au lieu de choisir le système d’exploitation Windows,
nous sélectionnons Linux, puis nous exécutons les commandes d’installation sur la
machine correspondante.

Figure 4.8 – Commande d’installation de l’agent Linux

Maintenant, l’agent Linux est déployé avec succès.

déploiement des agents active directory

Pour intégrer un contrôleur de domaine Windows (Active Directory) dans l’in-
frastructure de supervision, il suffit d’installer l’agent Wazuh de la même manière
que sur un serveur Windows classique. Une fois l’agent déployé, la configuration
se fait dans le fichier [Link] situé dans le répertoire d’installation de l’agent
(C:\Program Files (x86)\ossec-agent\). On y définit l’adresse du serveur Wa-
zuh (manager) ainsi que les paramètres de communication.

25
 Figure 4.9 – Liste des agents déployés

Maintenant les agents sont déployés, le tableau offre une vue d’ensemble de leur
gestion, affichant des informations clés comme l’état (actif ou inactif), les noms,
adresses IP et versions installées. Les indicateurs visuels, tels que les cercles colorés,
permettent une identification rapide des performances et du statut, avec des pour-
centages reflétant leur niveau d’activité. Les détails incluent la dernière connexion
et les alertes associées, facilitant une supervision et une maintenance en temps réel,
cruciales pour un environnement informatique sécurisé.

4.3 Configuration des politiques de sécurité efficaces

4.3.1 Définir les règles de détection
Dans le cadre de ce projet, les règles de détection ont été personnalisées afin
de répondre aux besoins spécifiques de l’infrastructure. Cette personnalisation a
concerné aussi bien les environnements Windows et Linux que l’Active Directory,
permettant ainsi une détection plus fine et adaptée des comportements suspects
propres à chaque système.

Pour les systèmes windows

Nous personnalisons les règles dans local_rules.xml afin de renforcer la sécurité
du système et d’adapter la détection aux besoins essentiels de tout organisme. Même
si Wazuh fournit des règles par défaut, celles-ci sont génériques et ne couvrent pas
toujours de manière précise certains événements critiques. Par exemple, nous avons
défini des règles pour détecter les tentatives d’exécution runas avec des comptes
inexistants, l’usage suspect de runas combiné à des erreurs réseau, les modifica-
tions de comptes utilisateurs via net user, ou l’utilisation d’outils d’administration
à distance. Ces événements représentent des vecteurs d’attaque universels et leur
surveillance est indispensable pour protéger les comptes administratifs, l’intégrité
des systèmes et les données sensibles.
Après l’ajout des règles Windows, il faut redémarrer le manager pour appliquer
ces règles, puis les tester afin de vérifier leur fonctionnement.

26
 Figure 4.10 – Règles personnalisées pour Windows

Figure 4.11 – Règles personnalisées pour Windows

Les règles fonctionnent correctement, car les alertes sont désormais affichées sur
l’interface de Wazuh. Il est maintenant possible de consulter les détails de chaque
alerte, ce qui permet de réagir rapidement et de prendre les mesures nécessaires pour
corriger ou prévenir les incidents.

Pour les systèmes linux

Les règles que nous avons définies dans local_rules.xml sont indispensables car
elles ciblent directement des vecteurs d’attaque universels que tout organisme doit
surveiller en priorité. En effet, la détection des modifications dans le fichier sen-
sible /etc/passwd permet de révéler immédiatement toute tentative d’altération
des comptes système, la surveillance de l’exécution des commandes sudo assure le
suivi des élévations de privilèges souvent utilisées lors d’intrusions, et l’identification
des échecs de connexion SSH avec des utilisateurs illégitimes constitue un moyen
efficace de repérer les att
On constate que les alertes sont envoyées avec succès.

Pour L’active directory

Dans le cas de l’Active Directory, nous définissons des règles spécifiques afin
de renforcer la détection et la prévention des menaces liées à la gestion centralisée
des utilisateurs et des ressources. Ces règles permettent notamment de surveiller les
tentatives de connexion échouées répétitives, la création ou la suppression suspecte

27
 Figure 4.12 – Test de règle avec commande net user

Figure 4.13 – Alertes générées par les règles Windows

de comptes, ainsi que les changements non autorisés dans les groupes à privilèges.
L’objectif est de détecter rapidement toute activité anormale pouvant indiquer une
tentative d’intrusion ou un abus d’accès, afin de protéger l’intégrité et la disponibilité
de l’infrastructure. Grâce à ces règles adaptées, les alertes sont générées automati-
quement et envoyées avec succès à l’interface Wazuh, ce qui facilite la corrélation des
événements et permet une réaction rapide et efficace face aux menaces potentielles.
Les règles ont été correctement ajoutées dans le fichier local_rules.xml. Pour les
tests, seule la règle d’échec de connexion a été vérifiée, le même principe s’appliquant
aux autres règles.

La balise <mitre>
Pour certaines règles liées à Windows, Linux ou Active Directory, nous avons
inséré la balise <mitre> pour les connecter au cadre MITRE ATT&CK, un standard
qui identifie les types d’attaques. Cela améliore la détection des menaces et simplifie
l’analyse des incidents, garantissant une sécurité robuste et conforme.

28
 Figure 4.14 – Règles personnalisées pour Linux

Figure 4.15 – Règles personnalisées pour Active Directory

4.4 Activation des modules avancés de Wazuh

L’activation de ses modules avancés, tels que le File Integrity Monitoring (FIM),
la Rootkit Detection, le Vulnerability Detector, le Policy Monitoring et l’Active
Response, renforce la protection des systèmes en assurant une surveillance proactive
et des réponses automatisées.

4.4.1 File Integrity Monitoring (FIM)

Le module FIM surveille les modifications non autorisées sur les fichiers critiques,
tels que /etc/passwd, /etc/shadow ou d’autres fichiers système essentiels sous Li-
nux, ainsi que les fichiers sensibles sous Windows. Il détecte les ajouts, suppressions
ou modifications, ce qui est crucial pour identifier des compromissions potentielles,
comme l’altération de fichiers par un attaquant.
La configuration se faite dans le fichier de configuration de wazuh [Link]

29
Dans le cas de windows
On active le module FIM en ajoutant les répertoires ou fichiers à surveiller dans
la section <syscheck>.

Figure 4.16 – Configuration FIM dans [Link] pour Windows

Maintenant, le module FIM est activé, et l’option whodata a été activée pour
obtenir des informations détaillées sur les utilisateurs et les processus responsables
des modifications.

Figure 4.17 – Alertes FIM pour modifications de fichiers

Figure 4.18 – Détails des alertes FIM

Les alertes sont envoyées avec succès via l’interface Wazuh, permettant une vi-
sualisation immédiate de leur statut. On peut consulter les détails de chaque alerte,
notamment les informations sur les événements détectés, les agents concernés et les
métadonnées associées, ce qui facilite l’analyse approfondie des incidents de sécurité
et une réponse rapide aux menaces potentielles.
On ajoute l’option report_changes dans la section <syscheck> de Wazuh
pour voir les modifications détaillées effectuées sur les fichiers surveillés.

30
 Figure 4.19 – Ajout de reportc hangesdanssyscheck

Figure 4.20 – Alerte FIM avec diff de contenu

On peut voir avec l’option report_changes la modification précise effectuée

sur le fichier surveillé. Le rapport indique non seulement les attributs modifiés (tels
que mtime, md5, sha1, sha256), mais également la différence de contenu grâce au
champ [Link], qui montre l’ancienne valeur et la nouvelle. Cette fonctionna-
lité permet ainsi de retracer exactement quelles parties d’un fichier ont été altérées,
offrant une visibilité détaillée sur les changements.

Dans le cas de linux

C’est le même principe que sous Windows, on active FIM dans /var/ossec/etc/[Link].

Figure 4.21 – Configuration FIM pour Linux

Ici, /etc/FIM_Test est le répertoire surveillé, avec une vérification toutes les 5
heures, un scan au démarrage, et une surveillance en temps réel avec rapport des
changements.
Après l’activation de FIM, nous créons un fichier FIM_Test afin de vérifier que
les alertes sont bien envoyées à Wazuh.
L’alerte a bien été envoyée et confirme que le fichier test_text a été ajouté dans
le répertoire /etc/FIM_Test.

4.4.2 Détecteur de vulnérabilités

Le module Vulnerability Detector de Wazuh identifie les vulnérabilités connues
(CVEs) sur les systèmes surveillés en comparant les logiciels installés avec les bases

31
 Figure 4.22 – Création de fichier test pour FIM

Figure 4.23 – Alerte FIM pour fichier ajouté

de données de vulnérabilités, comme celles du NIST ou d’autres sources publiques.

Dans ce projet, l’activation est réalisée dans le fichier [Link], ce qui permet
de mettre à jour la base de données NVD toutes les heures et d’analyser les systèmes
toutes les 12 heures.

Figure 4.24 – Tableau de bord des vulnérabilités

Les serveurs analysés présentent des vulnérabilités critiques similaires :

1. Vulnérabilité d’exécution de code à distance du protocole Windows
LDAP
LDAP est un service qui gère les connexions et informations des utilisateurs.
Cette faille permet à un attaquant d’exécuter du code malveillant à distance,
pouvant prendre le contrôle du serveur.
Recommandations : Installer le patch Microsoft. Si le patch ne peut être
appliqué, configurer les contrôleurs de domaine pour interdire l’accès à Inter-
net et bloquer les appels RPC entrants provenant de réseaux non approuvés.
L’application simultanée de ces mesures offre une protection renforcée.
2. Vulnérabilité d’exécution de code à distance du pilote de transport
multidiffusion fiable Windows (RMCAST)
Cette faille concerne le pilote PGM utilisé pour envoyer des données à plu-
sieurs ordinateurs en même temps. Si un programme écoute sur un port PGM,
un attaquant peut exécuter du code à distance.
Recommandations : Vérifier l’utilisation de PGM, protéger les ports utili-
sés par un pare-feu et ne pas exposer ces ports directement sur Internet.

32
 3. Vulnérabilité d’exécution de code à distance TCP/IP Windows
Cette vulnérabilité permet l’exécution de code via un paquet IPv6 spéciale-
ment conçu. Elle n’est active que si IPv6 est activé.
Recommandations : Appliquer le correctif Microsoft. Ne pas désactiver
IPv6 sans analyse préalable, surtout dans des environnements modernes ou
hybrides cloud.
4. Vulnérabilité d’exécution de code à distance du service Windows
Line Printer Daemon (LPD)
LPD permet d’imprimer à distance depuis des systèmes UNIX/Linux vers
Windows. Si activé, un attaquant peut exécuter du code malveillant.
Recommandations : Ne pas installer ni activer LPD. Si actif, désactiver le
service et ne jamais l’exposer sur Internet.
L’un des serveurs présente des vulnérabilités supplémentaires :
1. Vulnérabilité LDAP
Identique à celle décrite pour les autres serveurs.
Recommandations : Installer le patch Microsoft ou appliquer les mesures
de restriction réseau mentionnées précédemment.
2. Vulnérabilité de contournement des fonctionnalités de sécurité de
.NET, .NET Framework et Visual Studio
Cette faille permet de contourner certaines protections de sécurité intégrées
aux plateformes .NET. Elle ne permet pas directement l’exécution de code,
mais peut être utilisée avec d’autres failles pour bypasser les mécanismes de
sécurité.
Recommandations : Appliquer le correctif Microsoft, seule solution fiable
pour sécuriser le système.
3. Script c_rehash ne nettoyant pas correctement les métacaractères
Le script c_rehash d’OpenSSL ne sanitize pas les caractères spéciaux du
shell, ce qui peut permettre l’exécution de commandes arbitraires lorsqu’il
est exécuté automatiquement.
Recommandations : Remplacer le script par openssl rehash et mettre à
jour OpenSSL vers une version corrigée (3.0.3, 1.1.1o ou 1.0.2ze).
L’analyse des vulnérabilités critiques sur les serveurs montre que des mises à jour
régulières et des configurations réseau appropriées sont indispensables pour prévenir
les attaques à distance. L’application systématique des correctifs et la limitation des
services exposés contribuent à renforcer significativement la sécurité des serveurs et
des services critiques.

4.4.3 Réponse Active

a réponse active permet d’exécuter des commandes automatiques en réponse à
des alertes. La configuration dans [Link] inclut des blocs <active-response> avec
des commandes comme firewall-drop pour bloquer des IP.

33
 Figure 4.25 – Configuration de la réponse active dans [Link]

La commande disable-account permet de désactiver automatiquement les comptes

utilisateurs en cas de détection d’une activité suspecte, la commande firewall-drop,
bloque les adresses IP malveillantes au niveau du pare-feu. Ces deux réponses actives
sont déclenchées par les règles 5710 et 5503, avec un timeout de 600 secondes (10
minutes) afin d’éviter tout blocage permanent accidentel.

Figure 4.26 – Test de connexion échouée pour réponse active

Après l’activation de l’active response, on observe que lorsqu’on tente de se

connecter avec un compte en utilisant un mot de passe incorrect, le compte est
automatiquement désactivé, ce qui empêche toute tentative d’accès non autorisée et
renforce la sécurité du système.

Figure 4.27 – Alerte de compte désactivé et IP bloquée

Les alertes sont correctement envoyées, et l’on peut constater que le compte uti-
lisateur est désactivé tandis que l’adresse IP de l’attaquant est bloquée, garantissant
ainsi une protection efficace contre les accès non autorisés.

4.4.4 Security configuration assessment

Le module SCA permet une surveillance continue et automatique des politiques
de sécurité. Les scans se déclenchent dès le démarrage et se répètent toutes les 12
heures, permettant de détecter immédiatement toute non-conformité et de renforcer

34
la sécurité du système.

Figure 4.28 – Configuration SCA dans [Link]

n active le module sur les agents avec un scan toutes les 12 heures pour assurer
une surveillance continue des configurations système, détecter toute non-conformité
aux politiques de sécurité et permettre des interventions rapides en cas de vulnéra-
bilités.

Figure 4.29 – Test SCA par suppression de fichier

Pour tester le bon fonctionnement du module SCA, on supprime le fichier cri-

tique de configuration avec la commande sudo rm /etc/[Link], puis on
redémarre l’agent Wazuh avec sudo systemctl restart wazuh-agent. Cela per-
met de vérifier que le module détecte la non-conformité et génère une
alerte sur le manager, confirmant ainsi l’efficacité du monitoring des politiques
de sécurité.

Figure 4.30 – Alerte SCA pour non-conformité

Après avoir supprimé le fichier /etc/[Link] et redémarré l’agent, le

dashboard Wazuh affiche l’état de conformité pour la politique CIS Ubuntu Li-
nux 24.04 LTS Benchmark v1.0.0.. Le contrôle du fichier /etc/[Link]
est marqué not applicable, indiquant que le module SCA a correctement détecté
l’absence du fichier et généré l’alerte correspondante. Cela confirme l’efficacité du
monitoring des politiques de sécurité.

4.4.5 VirusTotal pour détecter les logiciels malveillants en

temps réel
L’intégration de VirusTotal avec Wazuh permet de détecter les logiciels mal-
veillants en temps réel en analysant les fichiers modifiés via l’API VirusTotal.

Dans le cas de linux

Sur les systèmes Linux, Wazuh utilise la surveillance de l’intégrité des fichiers
(FIM) pour détecter toute modification ou ajout de fichiers sensibles. Lorsqu’un

35
fichier suspect est détecté, l’agent Linux interroge automatiquement l’API VirusTo-
tal afin de déterminer si le fichier est malveillant. En fonction du résultat, Wazuh
peut générer une alerte de sécurité ou déclencher une réponse active pour supprimer
le fichier identifié comme une menace, assurant ainsi une protection en temps réel
contre les logiciels malveillants.
Dans notre cas, nous avons choisi de surveiller le répertoire « /tmp ». Ce réper-
toire est accessible en écriture par tous les utilisateurs et certaines applications, et il
est fréquemment utilisé par des attaquants pour télécharger et installer des logiciels
malveillants. Il est donc essentiel de le superviser afin de détecter toute activité sus-
pecte. Dans cet exemple, nous allons utiliser la fonctionnalité FIM (File Integrity
Monitoring) de Wazuh pour surveiller en temps réel l’ajout et la modification de
fichiers dans « /tmp ».

Figure 4.31 – Balise MITRE dans les règles personnalisées

Pour cela, il est nécessaire de modifier le fichier de configuration de l’agent situé

à « /var/ossec/etc/[Link] » et d’ajouter l’entrée correspondante sous le bloc
<syscheck>.

Figure 4.32 – Configuration VirusTotal dans [Link] pour Linux

Nous allons maintenant tester cette capacité en créant le fichier /tmp/[Link].

L’ID de règle 554 correspond à l’alerte « Fichier ajouté au système ».

36
 Pour plus de précision, nous allons ajouter une règle personnalisée dans /var/
ossec/etc/rules/local_rules.xml sur le serveur Wazuh afin d’indiquer explici-
tement le répertoire où le fichier est ajouté ou modifié.

Figure 4.33 – Configuration du répertoire FIM pour VirusTotal

Figure 4.34 – Règle personnalisée pour analyse VirusTotal

L’alerte est déclenchée correctement, donc les règles sont appliquées avec succès.
Nous pouvons maintenant commencer à intégrer VirusTotal et la réponse active.

Intégration de l’API VirusTotal

Sur le serveur Wazuh, il convient d’ajouter dans /var/ossec/etc/[Link]
le bloc <integration> contenant la clé <api_key> de VirusTotal, en spécifiant
le groupe et les identifiants de règles qui déclencheront l’intégration. Dans notre
exemple, nous utilisons les règles personnalisées 100200 et 100201.

37
 Figure 4.35 – Test avec fichier EICAR pour VirusTotal

L’integration se faite dans le fichier de configurationavec la clé API.

Généreration de la clé API VirusTotal

Pour obtenir cette clé, nous créons notre compte sur [Link].

Figure 4.36 – Alerte VirusTotal pour fichier malveillant détecté

Après la creation du compte on trouve notre clé api, et on peut maintenant

Tester l’intégration de VirusTotal.
Nous allons télécharger un fichier de test EICAR dans le répertoire /tmp sur le
point de terminaison supervisé.

Figure 4.37 – Configuration VirusTotal dans [Link] pour Windows

On constate que l’alerte est envoyée avec succès, ce qui confirme que l’intégration
de VirusTotal fonctionne. Nous devons maintenant créer une réponse active afin de
supprimer automatiquement les fichiers malveillants et d’envoyer les alertes vers le
tableau de bord.

38
Réponse active
Dans cette phase, nous exploitons la capacité de réponse active de Wazuh pour
supprimer automatiquement les fichiers malveillants. Wazuh fournit plusieurs scripts
par défaut pour la réponse active, tels que la désactivation de compte ou le blocage
d’adresses IP. Dans notre cas, nous allons créer un script personnalisé pour supprimer
les fichiers malveillants déposés dans le répertoire /tmp, en nous appuyant sur le
script suggéré par le guide POC de Wazuh.

Figure 4.38 – Installation de Python pour script de test

Sur l’hôte de l’agent, nous créons le script /var/ossec/active-response/bin/[Link]

et nous lui attribuons les permissions appropriées :

sudo chmod 750 /var/ossec/active-response/bin/[Link]

sudo chown root:wazuh /var/ossec/active-response/bin/[Link]
sudo systemctl restart wazuh-agent

Ce script utilise l’utilitaire jq pour analyser les fichiers JSON. Nous devons donc
installer jq :

sudo apt update

sudo apt -y install jq

Sur le serveur, nous modifions le fichier de configuration /var/ossec/etc/[Link]

afin d’activer la réponse active et déclencher le script [Link] lorsqu’une
alerte VirusTotal identifie un fichier comme malveillant (ID de règle : 87105).

Figure 4.39 – Configuration de la réponse active

39
 Pour suivre l’état de la suppression et détecter les erreurs éventuelles, nous ajou-
tons les règles suivantes dans /var/ossec/etc/rules/local_rules.xml :

Figure 4.40 – Les régles personnalisées

Après avoir appliqué ces modifications, nous redémarrons le gestionnaire Wazuh

et nous téléchargeons un fichier de test EICAR malveillant dans le répertoire /tmp :
sudo curl -Lo /tmp/[Link] [Link]

Figure 4.41 – Alerte VirusTotal pour fichier malveillant détecté

Les alertes sont correctement envoyées au tableau de bord et le fichier malveillant

a été supprimé avec succès.

Dans le cas de windows

Pour les systèmes Windows, nous configurons le fichier [Link] partagé situé
sur le serveur Wazuh, ce qui appliquera les modifications à tous les agents Wazuh.

Figure 4.42 – Configuration du fichier [Link]

Cela vérifiera le dossier Téléchargements de l’utilisateur particulier.

Nous devons ensuit télécharger Python. Une fois le programme d’installation
téléchargé, nous l’exécutons en veillant à cocher les options suivantes :
— Install launcher for all users
— Add Python 3.X to PATH (cela ajoute l’interpréteur Python au chemin
d’exécution)
Une fois que Python a terminé le processus d’installation, nous utilisons Power-
Shell administrateur pour installer PyInstaller, ensuit nous créons un script Python
[Link], qui est ensuite converti en exécutable [Link] avec
PyInstaller. Ce script supprime automatiquement les fichiers détectés et écrit les logs
dans [Link].

40
 Figure 4.43 – Installation du python

Figure 4.44 – Installation de PyInstaller

Après la création du script Python permettant l’intégration avec VirusTotal,

nous le convertissons en un fichier exécutable (.exe). Cette conversion facilite son
exécution sur les systèmes Windows sans nécessiter l’installation préalable de Py-
thon, ce qui le rend plus pratique et directement exploitable dans l’environnement de
travail. Ensuite, nous déplaçons l’exécutable dans le répertoire des réponses actives
de Wazuh afin qu’il puisse être appelé automatiquement lors du déclenchement des
règles de sécurité associées.

On redémarre l’agent puis nous passons à la configuration du serveur. En ce

qui concerne ce dernier, la configuration a déjà été effectuée dans le cas de Linux,
puisqu’une seule configuration est nécessaire. Il suffit donc simplement de créer des
règles personnalisées et de les ajouter dans la section integration du fichier [Link]
du serveur.
Ajout des règles de détection

41
 Figure 4.45 – Création du script Python

Figure 4.46 – Création des règles personnalisées

On ajoute ces règles afin de surveiller spécifiquement le répertoire Downloads de

Windows, car il s’agit d’un emplacement fréquemment utilisé pour le téléchargement
de fichiers pouvant potentiellement contenir des logiciels malveillants. Ainsi, toute
modification ou ajout de fichier dans ce dossier génère une alerte, ce qui permet
de détecter rapidement des comportements suspects et de renforcer la sécurité du
système.

Figure 4.47 – L’integration avec virustotal

Maintenant, Wazuh permet d’analyser chaque alerte associée à ces règles. Lors-
qu’un fichier malveillant est ajouté dans le répertoire surveillé, une alerte est im-
médiatement envoyée au tableau de bord. Grâce à l’intégration avec VirusTotal, le
fichier suspect est automatiquement vérifié.
Activation de la réponse active

42
 Dans le fichier [Link], nous ajoutons les configurations nécessaires pour ac-
tiver la réponse active et déclencher le ou les exécutables [Link] créés
chaque fois que VirusTotal signale une correspondance positive de malware.

Figure 4.48 – Activation de la réponse active

Maintenant, la réponse active est activé[Link]’un fichier malveillant est dé-

tecté, il sera automatiquement supprimé et une alerte sera envoyée au tableau de
bord via les règles déjà définies dans local_rules.xml.
vérification du bon fonctionnement de l’integration de virustotal et de
la réponse active :
Pour tester le fonctionnement, nous téléchargeons un fichier de test EICAR dans
le répertoire Downloads du point de terminaison Windows. Cette action déclenche
une requête vers VirusTotal et génère une alerte ; simultanément, le script de réponse
active supprime automatiquement le fichier malveillant.

Figure 4.49 – Téléchargement du fichier de test EICAR

Le fichier est téléchargé avec succès dans le répertoire surveillé.

Figure 4.50 – L’interface des alertes Wazuh

Les alertes sont correctement envoyées et le fichier malveillant est supprimé avec
succès.

4.4.6 Intégration Slack

Comme un analyste de sécurité ne peut pas surveiller et analyser les alertes
24h/24, il est essentiel de disposer d’un mécanisme permettant d’envoyer des noti-
fications en temps réel vers un canal de communication tel que Slack.
Slack est une plateforme de collaboration cloud qui facilite la communication
et le travail d’équipe. Pour envoyer des messages automatisés depuis Wazuh, nous
utilisons des Webhooks entrants, qui permettent de publier des messages via une
URL unique à laquelle on envoie une charge utile JSON contenant le texte et les
options du message.

43
Génération de l’URL du Webhook Slack
On doit d’abord créer un compte Slack, puis créer un espace de travail, que nous
avons nommé Wazuh. Ensuite, il faut créer un canal de communication pour envoyer
les alertes de Wazuh vers Slack.

Figure 4.51 – Creation du compte slack

Figure 4.52 – Creation du canal slack

Après la création du canal, nous devons créer une nouvelle application Slack pour
connecter Wazuh à Slack.
Après la création de l’application, on doit activer les Incoming Webhooks. Cela
permet à Wazuh d’envoyer automatiquement les alertes détectées vers le canal Slack
choisi en utilisant l’URL unique fournie par le webhook, garantissant ainsi une no-
tification en temps réel pour les analystes de sécurité.
Dans le fichier de configuration du manager Wazuh (/var/ossec/etc/[Link]),
nous ajoutons le bloc suivant pour activer l’intégration avec Slack. Ce bloc permet
d’envoyer automatiquement les alertes correspondant aux règles spécifiées vers le
canal Slack.
Chaque alerte correspondant aux règles 87105 et 100092 sera ainsi transmise
au canal Slack, permettant une notification rapide et une réaction immédiate des
analystes de sécurité.

44
 Figure 4.53 – Creation d’application slack

Figure 4.54 – Configuration slack dans [Link]

Figure 4.55 – Les alertes VirusTotal via slack

Après avoir associé les alertes VirusTotal au canal Slack Wazuh_test, nous avons
constaté que les notifications étaient correctement transmises lorsqu’un fichier mal-
veillant, comme [Link], est détecté. De plus, Wazuh peut être configuré pour
envoyer d’autres types d’alertes vers Slack, pas seulement celles liées à VirusTotal,
offrant ainsi une supervision en temps réel et centralisée des événements de sécurité.

4.4.7 Creation des tableaux de bord personnalisés

Pour faciliter la supervision et l’analyse des alertes, il est essentiel de créer des
tableaux de bord personnalisés dans Wazuh. Ces tableaux de bord permettent de
visualiser rapidement les événements critiques, les fichiers malveillants détectés par
VirusTotal, ainsi que les alertes envoyées vers Slack.
Ces tableaux de bord offrent également des graphiques et des visualisations per-
mettant d’identifier les tendances, d’évaluer la fréquence des incidents et de prioriser
les actions correctives. Grâce à ces visualisations, les analystes peuvent réagir rapi-

45
dement et efficacement face aux menaces détectées dans l’environnement Windows
surveillé.
Exemple de tableau de bord
Dans le cadre de notre projet, nous avons créé un tableau de bord permettant
de visualiser les 10 principales alertes, le nombre total d’alertes, ainsi que tous les
fichiers détectés par VirusTotal, et ce, sur les 12 dernières heures.

Figure 4.56 – Tableau de bord personnalisé

Le tableau de bord est donc contient les trois graphiques.

4.5 Conclusion
La mise en œuvre de Wazuh a renforcé la sécurité des systèmes d’information
du ministère. L’installation, le déploiement des agents, la configuration des règles et
l’activation des modules avancés ont permis une meilleure détection et gestion des
menaces. Les tableaux de bord personnalisés ont facilité le suivi quotidien, confir-
mant la pertinence et l’efficacité opérationnelle de Wazuh.

46
Conclusion et perspectives

Conclusion Générale
Le rapport de stage constitue un jalon majeur dans le parcours académique et
professionnel, résultat d’une expérience immersive et enrichissante au sein du Mi-
nistère du Tourisme, de l’Artisanat et de l’Économie Sociale et Solidaire. La mise
en place d’un système SIEM basé sur Wazuh a permis non seulement d’atteindre les
objectifs fixés, mais également d’améliorer significativement la posture de sécurité
de l’organisation, illustrant l’efficacité d’une solution open source face aux menaces
cybernétiques contemporaines. Chaque chapitre a contribué à cette réussite :
Le premier a posé les bases du projet en définissant le cadre, les enjeux et les ob-
jectifs.
Le deuxième a présenté une analyse approfondie de l’état de l’art justifiant le choix
stratégique de Wazuh.
Le troisième a détaillé les aspects techniques et l’architecture de l’outil.
Le quatrième a permis la concrétisation pratique du projet, avec l’activation des
modules avancés et la configuration de tableaux de bord opérationnels. Cette expé-
rience a renforcé les compétences techniques et opérationnelles dans la configuration
de systèmes SIEM, l’analyse de logs, la détection proactive des menaces et la gestion
des réponses aux incidents, tout en mettant en évidence l’importance de l’adaptation
à un environnement professionnel complexe et en constante évolution. La collabo-
ration étroite avec les équipes opérationnelles a également souligné la nécessité de
processus coordonnés pour assurer l’efficacité et la fiabilité des systèmes de cyber-
sécurité.

Perspectives
Les perspectives d’évolution du projet sont multiples et stratégiques. L’intégra-
tion de la solution SIEM aux environnements cloud pourrait permettre une cou-
verture étendue et une surveillance continue des infrastructures hybrides. Le dé-
veloppement de scripts d’automatisation avancés favoriserait une optimisation des
réponses aux incidents, une réduction du temps de réaction et un renforcement de la
résilience du système face aux attaques complexes. La réalisation de tests à grande
échelle sur des infrastructures étendues permettrait d’évaluer les performances, la
scalabilité et la tolérance aux pannes, garantissant une sécurité robuste dans des
contextes critiques.
Par ailleurs, l’analyse continue des données de sécurité et l’enrichissement des
règles de détection pourraient contribuer à l’élaboration d’une approche prédictive
de la cybersécurité, capable d’anticiper et de prévenir les menaces émergentes. Ces

47
perspectives visent à renforcer les pratiques de sécurité au sein du ministère et à
consolider les standards de cybersécurité dans le secteur public, assurant la protec-
tion des données et des infrastructures stratégiques.

48
Bibliographie

[1] Site T&T. [Link]

[2] Dr. Leon Eversberg. "How to Use Hybrid Search for Better LLM RAG Retrie-
val." Towards Data Science, Aug 11, 2024. [Link]
how-to-use-hybrid-search-for-better-llm-rag-retrieval
[3] Florian June. "Advanced RAG 10 : Corrective Retrieval Augmented Generation
(CRAG)." AI Advances, Apr 17, 2024. [Link]
advanced-rag-10-corrective-retrieval-augmented-generation-crag
[4] Site officiel de LlamaIndex. [Link]
[5] GitHub. [Link]
[6] H. Naveed, A. U. Khan, S. Qiu, M. Saqib, S. Anwar, M. Usman, N. Akhtar,
N. Barnes, A. Mian. "A Comprehensive Overview of Large Language Models".
[Link]
[7] K. T. Chitty-Venkata, S. Mittal, M. Emani, V. Vishwanath, A. K. Somani. "A
survey of techniques for optimizing transformer inference". Journal of Systems
Architecture, 144 (2023).
[8] PostgreSQL [Link]
[9] FastApi [Link]
[10] site officiel Ollama. [Link]

49