Déployer Wazuh Dans Une Organisation Publique

26/01/2021 Déployer Wazuh dans une organisation publique
Page 1
U NIVERSITÉ O BERTA DE C ATALUÑA

U NIVERSITÉ A UTÓNOMA DE B ARCELONE
U NIVERSITY R OVIRA I V IRGILI
U NIVERSITÉ DE I SLANDS B ALEARES
MISE EN ŒUVRE DE WAZUH

DANS UNE ORGANISATION PUBLIQUE
PROJET FINAL DU MASTER
DEGRÉ DE MASTER UNIVERSITAIRE EN SÉCURITÉ

DES TIC
Auteur : Javier Polo Cózar

Directeur : Pau del Canto Rodrigo
Responsable régional : Víctor García Font
Juin 2020
Page 2
https://translate.googleusercontent.com/translate_f 1/105
Ce travail est soumis à une licence de

par Creative Commons
Page 3
UN MERCI
"Parce que la gratitude silencieuse ne sert à personne."
À Rosa, pour le soutien, la patience et le temps consacrés à la famille tout en faisant cela
travail en particulier et le Master en général.
À Violeta et Mireia, les deux petites stars de ma vie.
À Pau del Canto Rodrigo, directeur du TFM, pour ses conseils et ses conseils lors de son développement.
À Juan Luis Garrido Castro, pour les conseils donnés et pour m'avoir permis de mener à bien cette
Je travaille dans l'organisation.
Ceux qui sont partis seront toujours dans nos esprits et dans nos cœurs.
Merci beaucoup à tous.
Page 4
FEUILLE DE TRAVAIL FINALE
Titre du poste: Mise en œuvre de Wazuh dans une organisation publique
Nom de l'auteur: Javier Polo Cózar
Nom du consultant: Pau del Canto Rodrigo
Nom de la PRA: Police Víctor García
Date de livraison (mm / aaaa): 06/2020
Diplôme: Master en sécurité des TIC
Zone de travail finale: sécurité de l'entreprise
Langue de travail: espagnol
Mots clés SIEM, Monitoring, Wazuh, HIDS, IDS, menaces,

détection, vulnérabilités, bastion, intrus
Résumé du travail (maximum 250 mots): Avec le but, le contexte d'application,

méthodologie, résultats et conclusions des travaux
L'information est devenue la ressource la plus précieuse au monde et nous devons

s'efforcer de le protéger en améliorant nos capacités de détection des cyberattaques.
Les SIEM peuvent nous aider et peuvent être des éléments très importants pour assurer et
protéger les actifs de l'organisation et tout le trafic réseau.
Dans cette thèse de Master, nous avons mis en œuvre l'architecture de Wazuh et ELK
Empiler dans notre organisation, nous permettant de la protéger de manière multidisciplinaire:
correctif (en détectant les vulnérabilités), préventif (en bastioning
serveurs), proactif (en collectant les journaux, l'intégrité des fichiers ou l'analyse
des malwares en temps réel), informative (via différents types de notifications),
réactif (par des mécanismes de réponse active (réponse active) aux différents
alertes générées) et personnalisées (nous permettant de surveiller les appareils sans agent et
créer nos propres règles et décodeurs).
Nous avons découvert une solution logicielle gratuite très complète. De plus, lors du traitement
notre organisation d'une administration publique, nous aidera à nous conformer au régime
Sécurité nationale (ENS), obligatoire depuis 2010.
Résumé (en anglais, 250 mots ou moins):
Les données sont devenues la ressource la plus précieuse au monde et nous devons faire un effort
pour les protéger, en améliorant nos capacités de détection des cyberattaques. Les SIEM peuvent nous aider à
atteindre cet objectif afin qu'ils deviennent des outils très importants pour sécuriser et protéger les actifs de l'entreprise
et le trafic réseau.
Dans cette thèse de Master, nous avons déployé l'architecture Wazuh et ELK Stack dans notre
organisation, nous permettant de la protéger de manière pluridisciplinaire: corrective (par
détection de vulnérabilité), préventif (via le renforcement du serveur), réactif (via
mécanismes de réponse qui sont déclenchés lorsque des alertes sont générées) et personnalisés
(être capable de surveiller les appareils sans agent et de créer nos propres règles et décodeurs).
Nous avons découvert une solution open source très complète. En raison du fait que notre organisation
zation est une administration publique, elle nous aidera à accomplir avec la sécurité nationale
Cadre (ENS), qui est obligatoire depuis l'année 2010.
Page 5
Í NDEX
XIII
XV
1
.............................1
................................... 2
.......................... 2
......................... 2
.................................. 3
.......................... 3
. . . . . . . . . . . . . . . . . . . . . . . . . sept
. . . . . . . . . . . . . . . . . . . . . . . . . . . sept
. . . . . . . . . . . . . . . . . . . . . . . . . . . sept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sept
........................... 8
9
.................... 9
........................ 9
. . . . . . . . . . . . . . . . . . . . . . . . . dix
. . . . . . . . . . . . . . . . . . dix
. . . . . . . . . . . . . . . . . . . . . Onze
. . . . . . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . 17
. . . . . . . . . . . . . . . . . . . . . . . . 18
vingt et un
. . . . . . . . . . . . . . . . . . . . . vingt et un
. . . . . . . . . . . . 24
. . . . . . . . . . . . . . . . . 24
Page 6
INDICE
. . . . . . . . . . . . . . . 24
. . . . . . . . . . . . . . . . . 25
. . . . . . . . . . . . . . . . 26
. . . . . . . . . . . . . . . . 26
. . . . . . . . . . . . . . . . . . 27
29
. . . . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . . . 30
. . . . . . . . . . . 30
. . . . . . . 30
. . . . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . 39
41
. . . . . . . . . . . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . . . Quatre cinq
. . . . . . . . . . . . . . . Quatre cinq
. . . . . . . . . . . . . . . . . . . . . . . . Quatre cinq
47
. . . . . . . . . . . . . . . . . . . . . . . . . 47
. . . . . . . . . . . . . . . . . . . . . . . . . cinquante
. . . . . . . . . . . . . . . . . . . . . cinquante
. . . . . . . . . . . . . . . . . . . 52
. . . . . . . . . . . . . . . . . . . . . . . . 54
. . . . . . . . 54
. . . . . . . 56
. . . . . . . . . . . . . . . . . . . . . . . . . . 58
. . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . 60
. . . . . . . . . . . . . . . . . . . . 62
. . . . . . . . . . . . . . . . . . . . . . . . . 63
. . . . . . . . . . . . 64
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . . 69
. . . . . . 69
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
. . . . . . . . . . 71
. . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . . . . . . . 76
VU
Page 7
INDICE
. . . . . . . . . . . . . . . . . . . . . 79
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A-1
. . . . . . . . . . . . . . . . . . . . .A-1
. . . . . . . . . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . . . . . . . . . . A-3
. . . . . . . . . . . . . . . . . . . A-3
. . . . . . . . . . . . . . . . . A-3
. . . . . . . . . . . . A-4
B-1
. . . . . . . . . . . . . . B-1
. . . . . . . . . . . . . . . . . . . . . . . B-2
. . . . . . . . . . . . . . . . . . . . . . . . B-2
. . . . . . . . . . . . . . . . . . . . . . . . B-2
. . . . . . . . . . . . . . . . . . . B-3
. . . . . . . . . . . . . . . . . . . . . . . . . B-5
C-1
. . . . . . . . . . . . . . . . . . . . . . . . . . C-1
. . . . . . . . . . . . . . . . . . . . C-1
. . . . . . . . . . . . . . . . . . C-2
. . . . . . . . . . . . . . . . . . . C-2
. . . . . . . . . . C-3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
. . . . . . . . . . . . C-4
J-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . .D-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J-2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J-3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4
. . . . . . . . . . D-4
. . . . . D-4
. . . . . . . . . . . . . . . . . . . . J-5
VII
Page 8
INDICE
. . . . . . . . . . . . . . . . . . . . . . J-5
E-1
. . . . . . . . . . . . . . . . . E-1
. . . . . . . . . . . . . . . . . . E-2
F-1
. . . . . . . . . . . . . . . . . . . . . . . . . . F-1
. . . . . . . . . . . . . . . . . . . . . . . . F-1
G-1
. . . . . . . . . . . . . . . . . . . .G-1
. . . . . . . . . . . . . . . G-1
. . . . . . . . . . . . . G-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-3
H-1
. . . . . . . . . . . . . . . . . . H-1
. . . . . . . . . . . . . . . . . . . H-1
. . . . . . . . . . . . . H-2
VIII
Page 9
Í INDEX DES CHIFFRES
............ 6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . Onze
. . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . . . 18
. . . . . . . . . . . . . . . . . . . . . . 19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vingt
. . . . . . . . . . . . . . . . . . . . . . . . 22
. . . . . . . . . . . . . . . . . . . . . . . 2. 3
. . . . . . . 28
. . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . 38
. . . . . . . . . . . . . . . . . . . 38
. . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . . 43
. . . . . . . . . . . . . . . . . . . . . . . . . . 44
. . . . . . . . . . . . . . . 44
. . . . . . . . . . . . . . Quatre cinq
. . . . . . . . . . . . . . . . 48
. . . . . . . . . . . . . . . . . 49
. . . . . . . . . . . . . . . . . . . . . . . . . . . 51
. . . . . . . . . . 52
. . . . . . . . . . . . . . . . . . . . . . 53
. . . . . . . . . . . . . . . . . 57
. . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . 66
. . 67
. . . . . . . . . . . . . . . . . . . . . . 70
Page 10
INDEX DES CHIFFRES
. . . . . . . . . . . . . 73
. . . . . . . . . . . . 74
. . . . . . . . . . . . . . . . . . . . . 74
. . . . . . . . . . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . 77
. . . . . . . . . . . . . . . . . 78
. . . . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . . . . A-4
. . . . . . . . . . . . . . . . . . . . . . . TO 5
. . . . . . . . . . . . . . . . . . . . TO 5
. . . . . . . . . . . . . . . . . . . B-4
. . . . . . . . . . . . . . . . . . . . B-4
. . . . . . . . . . . . . . . . B-4
. . . . . . . . . . . . . . . . . . . . . . . C-2
. . . . . . . . . . . . . . . . . . . . . . . . . . C-3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J-3
. . . . . . . . . . . . . . . . . . . . . . . . J-5
. . . . . . . . . . . . . . . . . . . F-4
. . . . . . . . . . . . . . . . . . . . F-4
. . . . . . . . . . . . . . . . . . . . . . . G-2
. . . . . . . . G-4
. . . . . . . . . . . . . . . . . . . . . H-2
Page 11
Í INDEX DES TABLES

............................ 5
. . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . . . quinze
. . . . . . . . . . . . . . . . . . . . . . quinze
. . . . . . . . . . . . . . . . . . . . . . . quinze
. . . . . . . . . . . . . . . . . . . . . 63
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
. . . . . . . . . . . . . . . F-3
Page 13
12
L IST D' UN CHRONYMES

BOJA Journal officiel de la Junta de Andalucía
Autorité de certification CA -,
Centre CIS pour la sécurité Internet
Énumération de plate-forme commune CPE
Vulnérabilités et exposition communes à la CVE
ENS EsquemaNacionaldeSeguridad`` ,
Surveillance de l'intégrité des fichiers FIM
Nom de domaine complet FQDN ,
Règlement général sur la protection des données GDPR
Guide de bonnes pratiques GPG13 13
Objet de stratégie de groupe GPO
Haute disponibilité HA
Système de détection d'intrusion d'hôte HIDS ,
Format d'échange de messages de détection d'intrusion IDMEF
Système de détection d'intrusion IDS
Indicateurs de compromis des CIO
Technologie de l'information informatique
Notation d'objets JavaScript JSON
Support à long terme LTS
Page 14
LISTE DES ACRONYMES
Traduction d'adresses réseau NAT
Système de détection d'intrusion réseau NIDS
Système de prévention des intrusions sur le réseau NIPS
NRPE Nagios Remote Plugin Executor ,
Base de données nationale de vulnérabilité NVD ,
OVAL Open Vulnerability Assessment Language
Norme de sécurité des données de l'industrie des cartes de paiement PCI DSS
Protocole RDP Remote Desktop
Évaluation de la configuration de la sécurité SCA
Gestion des événements de sécurité SEM
Gestion des événements et des informations de sécurité SIEM
Gestion des informations de sécurité SIM
Réponse d'orchestration et d'automatisation de la sécurité SOAR
Thèse de maîtrise finale
Analyse comportementale des événements utilisateur UEBA
Réseau privé virtuel VPN
Liste de vérification de la configuration extensible XCCDF Description Format
XIV
Page 15
G LOSARIO
sans agent fait référence aux opérations où aucun service, démon ou
processus (un agent) s'exécutant en arrière-plan sur la machine souhaitée
moniteur.
ensemble solide d'activités menées pour renforcer autant que possible

la sécurité d'une équipe.
Docker Compose Compose est un outil pour définir et exécuter des applications Docker
de plusieurs conteneurs.
Docker Desktop est une application de création et de partage pour MacOS et Windows
applications et microservices conteneurisés.
Docker Toolbox est une solution obsolète pour l'utilisation de Docker sur les systèmes Mac et Windows
les plus anciens qui ne répondent pas aux exigences de Docker Desktop.
endpoint est un périphérique informatique distant qui communique avec un réseau auquel il est
connecté. Par exemple: ordinateurs de bureau, ordinateurs portables, téléphones portables, tablettes,
serveurs, postes de travail, etc. . . ,
Hyper-V est un programme de virtualisation Microsoft basé sur un hyperviseur pour

Systèmes 64 bits avec processeurs basés sur AMD-V ou Virtual-Technology
zation d’Intel . ,,
Le Webhook entrant est un moyen simple d'envoyer des messages depuis des applications vers
Mou. La création d'un Webhook entrant vous donne une URL unique pour envoyer un
Charge utile JSON avec le message texte et certaines options.
Indicateurs de compromis Indicateurs de compromis

(IOCs) font référence à une technologie normalisée qui consiste à définir le
caractéristiques techniques d'une menace grâce à des preuves existantes dans un
ordinateur compromis, afin qu'ils puissent être utilisés pour identifier d'autres ordinateurs
touchés par la même menace ou les en empêcher.
Page 16
GLOSSAIRE
machine learning machine learning.
Nginx est un proxy inverse / serveur Web léger et haute performance et un proxy pour les protocoles
de courrier électronique.
on-premise le terme on-premise ou local fait référence au type d'installation d'une solution
des logiciels. Cette installation est réalisée au sein du serveur et de l'infrastructure ICT
de l'entreprise. C'est le modèle traditionnel des applications métier et l'opposé du
nuage (nuage) . ,
Powershell PowerShell (initialement appelé Windows PowerShell) est une interface de

console (CLI) avec la possibilité d'écrire et de joindre des commandes à l'aide de scripts. Ce
L'interface de la console est conçue pour être utilisée par les administrateurs système,
dans le but d'automatiser les tâches ou de les exécuter de manière plus contrôlée . ,
snapshot un snapshot ou un snapshot de volume est un snapshot ou un snapshot de l'état

d'un système à un instant donné
VirtualBox est un logiciel de virtualisation pour les architectures x86 / amd64 développé par
Oracle Corporation.
VMware est un logiciel de virtualisation multiplateforme (Windows, Linux et MacOS) pour

Processeurs Intel développés par VMware Inc.
solution de contournement, rodéo . ,
X-Pack est une extension d'Elastic Stack qui fournit sécurité, alerte, surveillance,
création de rapports, apprentissage automatique et de nombreuses autres fonctionnalités.
XVI
Page 17
I NTRODUCTION
1
1.1. Contexte et justification
Ces dernières années, les données sont devenues la ressource la plus précieuse au monde.
L'éventail des menaces pour leur sécurité s'est considérablement élargi et la
Les systèmes d'attaque sont devenus de plus en plus sophistiqués. Selon le rapport d'analyse de
Les violations de la sécurité des données de Verizon en 2019,
( ), 69% des attaques ont été menées par des personnes
à l'extérieur de l'organisation. Plus spécifiquement au secteur vers lequel nos travaux sont dirigés,
dans l'administration publique, le pourcentage passe à 75%. De plus, les données
68% étaient des données internes compromises de l'organisation et 68% des attaques
identifiées ont été découvertes au moins un mois après la violation initiale. Cela sans avoir
en tenant compte du fait qu'il existe un nombre élevé d'attaques non détectées, avec lesquelles le pourcentage
ce serait beaucoup plus élevé. En tenant compte de ces informations, nous devons nous efforcer d'améliorer
nos capacités de détection des cyberattaques ( ).
Il ne fait aucun doute que les systèmes de détection d'intrusion ( ) peut nous aider
et sont importants pour sécuriser et protéger les actifs des organisations et l'ensemble
trafic réseau. Ils servent de sauvegarde pour défendre l'accès aux ressources réseau d'un
organisation.
Ce travail cherchera à mettre en œuvre dans notre organisation (une délégation provinciale
d'une administration publique régionale) a , ce qui lui manque actuellement. De cette
forme, cela nous aidera à nous adapter au système de sécurité nationale ( ), de
Conformité obligatoire pour toutes les administrations publiques depuis 2010.
L'idée est que vous fassiez un travail correctif (en détectant les vulnérabilités),
1 Système de détection d'intrusion

2 Gestion des événements d'information système
Page 18
CHAPITRE 1 INTRODUCTION
ventive (en bâtissant des serveurs), proactive (en collectant les logs,
intégrité des fichiers ou analyse des malwares en temps réel) et informative (nous
lorsqu'un incident de sécurité se produit). Pour ce faire, les différentes options seront analysées
existant sur le marché et celui qui correspond le mieux à nos besoins sera choisi,
possibilités et indications du sens de son implantation.
1.2. Objectifs
On peut distinguer les objectifs généraux des objectifs spécifiques.
1.2.1. Objectifs Generals

Les objectifs généraux de ce travail sont:
• Être capable de planifier correctement le travail et de le suivre de manière pratique

dit la planification, en atteignant les objectifs proposés dans chacun des jalons.
• Analyser les caractéristiques des SIEM et les options disponibles sur le marché.
• Déterminer le plus adapté à notre environnement commercial.
• Sécuriser notre organisation avec l'un de ces systèmes, ce qui lui manque actuellement.
1.2.2. Objectifs spécifiques

Les objectifs spécifiques de ce travail sont:
• Etudier et déterminer la meilleure méthode d'implémentation SIEM pour notre organisation.

zation: virtuel vs. physique vs. récipient.
• Etudier et choisir l'architecture de réseau la plus adaptée à la mise en œuvre: centralisée vs.
distribué.
• Mettre en place un SIEM qui permet la surveillance de la plupart des différents appareils
réseau avec lequel nous travaillons (PC, serveurs, commutateurs, baie de stockage,
firewalls, etc ...) ainsi que les différents systèmes d'exploitation (Windows, Linux, etc ...).
• Sécurisation de l’accès aux applications Web que nous utilisons pour effectuer le suivi,
éviter, par exemple, les accès anonymes, les comptes génériques ou le trafic non chiffré.
• Etudier et mettre en œuvre, dans la mesure du possible, des outils d'automatisation

pour la mise en œuvre du système.
• Etudier la possibilité d’utiliser des guides de sécurité avec SIEM pour nous aider
rencontrer le , afin d'effectuer un (durcissement) correct de la
serveurs, à la fois sur Windows et Linux.
• Etudier la possibilité de détecter des vulnérabilités dans les différents systèmes d'exploitation
dont nous avons.
• Intégration de SIEM avec l'outil de surveillance des systèmes déjà implémenté

Dans l'organisation ( ).
Page 19
1.3. Méthodologie
• Réaliser différents cas d’utilisation qui démontrent les avantages du système: l’intégrité
fichiers, détection de logiciels malveillants, détection d'attaques, etc. . .
• Avoir un outil de détection d'intrusion qui nous permet de faire des notifications à
les utilisateurs ou groupes d'utilisateurs correspondants lorsqu'un incident se produit.
1.3. Méthodologie
La méthodologie que nous suivrons dans le présent sera le suivant:
1. Un plan de travail réaliste sera établi et adapté à la planification préétablie

pour le sujet.
2. Les différents SIEM du marché seront analysés et celui qui convient le mieux
convenir à notre organisation.
3. Une fois choisie, la meilleure méthode d'implantation sera conçue (virtuelle, physique ou par
conteneur) et l’architecture de réseau la plus appropriée sera déterminée.
4. Ce système sera installé dans notre organisation, le sécurisant de la meilleure façon

possible et en essayant d'en tirer le meilleur parti; d'abord dans un environnement de test
puis en production.
5. Une fois implantés, les résultats et les bénéfices obtenus avec votre
implantation.
6. Les conclusions pertinentes et les améliorations possibles seront tirées, que nous refléterons dans le
dernier souvenir.
1.4. Planification: phases et tâches

Dans la table Les différentes phases et tâches du travail sont présentées, ainsi que leurs
durée et dates de début et de fin.
Phases et tâches Durée Début La fin
1 PHASE DE DÉFINITION 12 19/02/20 03/01/20
1.1 Contexte et justification du travail 2 19/02/20 20/02/20
1.2 Définition des objectifs 2 21/02/20 22/02/20
1,3 Méthodologie à suivre 2 23/02/20 24/02/20
1,4 Ressources à utiliser 2 25/02/20 26/02/20
1,5 État de l'art 4 27/02/20 03/01/20
2 PHASE DE PLANIFICATION 5 27/02/20 03/02/20
2,1 Identification des tâches 2 27/02/20 28/02/20
Suite à la page suivante
3 Projet de Master final
Page 20
2.2 Calcul de la tâche et des délais de livraison 2 29/02/20 03/01/20
2,3 Développement de diagramme de Gantt 1 03/02/20 03/02/20
2,4 Rédaction de la phase de définition et de planification 8 24/02/20 03/02/20
2,5 Livraison du plan de travail (PEC1) ÉTAPE IMPORTANTE

03/03/20 03/03/20
2.6 Révision et correction du plan de travail par le directeur 4 03/04/20 07/03/20
3 PHASE D'ENQUÊTE ET D'ANALYSE dix 03/04/20 13/03/20
3.1 Etude et analyse générale du SIEM 2 03/04/20 03/05/20
3.2 Besoin d'un SIEM dans l'entreprise 2 03/06/20 07/03/20
3,3 Exigences SIEM à mettre en œuvre 2 08/03/20 03/09/20
3.4 Choix du SIEM 2 10/03/20 11/03/20
3,5 Analyse du SIEM choisi 2 12/03/20 13/03/20
3,6 Rédaction de la phase d'investigation et d'analyse 5 03/09/20 13/03/20
4 PHASE DE CONCEPTION ET DE PRISE DE DÉCISION 6 14/03/20 20/03/20
4.1 Choix du déploiement: virtuel, physique ou conteneur 3 14/03/20 16/03/20
4.2 Choix de l'architecture réseau: centralisée ou distribuée 3 17/03/20 20/03/20
5 PHASE D'INSTALLATION dix 21/03/20 30/03/20
5.1 Installation de test SIEM 4 21/03/20 24/03/20
5.2 Installation en production du SIEM sécurisé 6 25/03/20 30/03/20
5,3 Rédaction des phases de conception et d'installation dix 21/03/20 30/03/20
5,4 Livraison de la phase d'analyse, de conception et d'installation (PEC2) ÉTAPE IMPORTANTE

31/03/20 31/03/20
5.5 Révision et correction du PEC2 par le directeur 4 31/03/20 04/03/20
6 PHASE DE DÉPLOIEMENT ET CAS D'UTILISATION 29 31/03/20 28/04/20
6.1 Déploiement automatique de l'agent 4 31/03/20 04/03/20
6.2 Détection des vulnérabilités 5 04/04/20 08/04/20
6.3 Bastion avec guides de sécurité 6 04/09/20 14/04/20
6,4 Intégration Nagios 2 15/04/20 16/04/20
6,5 Autres cas d'utilisation 9 17/04/20 25/04/20
6,6 Notifications 2 26/04/20 27/04/20
Suite à la page suivante
Page 21
1.4. Planification: phases et tâches
6,7 Rédaction de la phase de déploiement et des cas d'utilisation dix 18/04/20 27/04/20
6,8 Livraison de la phase de déploiement et des cas d'utilisation (PEC3) ÉTAPE IMPORTANTE
28/04/20 28/04/20
6,9 Révision et correction du PEC3 par le directeur 4 29/04/20 05/02/20
sept PHASE DE RÉDACTION ET LIVRAISON DU RAPPORT 35 29/04/20 06/02/20
7,1 Conclusions et améliorations 5 29/04/20 05/03/20
7,2 Rédaction du rapport final 29 05/04/20 06/01/20
7,3 Remise du rapport final ÉTAPE IMPORTANTE

06/02/20 06/02/20
8 PHASE DE PRÉSENTATION ET DE DÉFENSE 17 06/03/20 19/06/20
8.1 Préparation de la présentation vidéo 6 06/03/20 06/08/20
8,2 Livrer une présentation vidéo ÉTAPE IMPORTANTE

06/09/20 06/09/20
8.3 Défense TFM ÉTAPE IMPORTANTE

15/06/19 19/06/19
Tableau 1.1: Planification TFM
Sur la page , dans la figure , nous représentons le diagramme de Gantt avec le calendrier du
TFM.
Page 22 2020
février Mars avril Mai
PHASE DE DÉFINITION
Contexte et justification du travail
Définition des objectifs
Méthodologie à suivre
Ressources à utiliser
État de l'art
PHASE DE PLANIFICATION
Identification des tâches
Calcul de la tâche et des délais de livraison
Développement de diagramme de Gantt
Rédaction de la phase de définition et de planification
Livraison du plan de travail (PEC1)
Révision et correction du plan de travail par le directeur
PHASE D'ENQUÊTE ET D'ANALYSE
Etude et analyse générale du SIEM
Besoin d'un SIEM dans l'entreprise
Exigences SIEM à mettre en œuvre
Choix du SIEM
Analyse du SIEM choisi
Rédaction de la phase de recherche et d'analyse
PHASE DE CONCEPTION ET DE PRISE DE DÉCISION
Choix du déploiement: virtuel, physique ou conteneur
Choix de l'architecture réseau: centralisée ou distribuée
PHASE D'INSTALLATION
Installation de test SIEM
Installation en production du SIEM sécurisé
Rédaction des phases de conception et d'installation
Livraison de la phase d'analyse, de conception et d'installation (PEC2)
Révision et correction du PEC2 par le directeur
PHASE DE DÉPLOIEMENT ET CAS D'UTILISATION
Déploiement automatique de l'agent
Détection des vulnérabilités
Bastion avec guides de sécurité
Intégration Nagios
Autres cas d'utilisation
Notifications
Rédaction de la phase de déploiement et des cas d'utilisation
Livraison de la phase de déploiement et des cas d'utilisation (PEC3)
Révision et correction du PEC3 par le directeur
PHASE DE RÉDACTION ET LIVRAISON DU RAPPORT
Conclusions et améliorations
Rédaction du rapport final
Remise du rapport final
PHASE DE PRÉSENTATION ET DE DÉFENSE
Préparation de la présentation vidéo
Livrer une présentation vidéo
Défense TFM
Définition et planification, analyse, conception et installation Déploiement et cas d'utilisation Mémo
Figure 1.1: Diagramme de Gantt: planification du travail temporaire
Page 23
1.5. Ressources logicielles et matérielles
1.5. Ressources logicielles et matérielles

On peut distinguer les ressources logicielles et matérielles.
1.5.1. Ressources logicielles

Les ressources logicielles suivantes seront utilisées, a priori :
1. Systèmes d'exploitation
• Microsoft Windows: 2012 R2, 2008 R2, 10 (Pro et Famille), 7 Pro
• GNU / Linux: Ubuntu Server LTS (18.x, 16.x, 14.x)
2. Virtualisation / Conteneurs: Hyper-V, VirtualBox, Docker
3. Édition et disposition de la mémoire: L A TEX, TeXstudio 2.12.22, MiKTeX 2.9
4. Gestionnaire des références bibliographiques: Zotero 5.0.82
5. Conception graphique et diagrammes de réseau: Microsoft Visio 2007, Inkscape 0.92.3
1.5.2. Ressources matérielles

Les ressources matérielles suivantes qui font partie de l'entreprise seront utilisées ou accessibles:
Serveurs: Lenovo CTOX3650M5, DELL PowerEdge T610, HP XW4600
Ordinateurs: HP ProDesk 400 Gx
Électronique réseau: commutateurs HP 2530 48G-POE et 3800 48G-POE.
Armoire de stockage: EMC VNX5200
Pare-feu: Fortigate 50E
1.6. État de l'art

Le besoin de systèmes SIEM dans les entreprises a augmenté récemment
années notamment en raison de l'évolution des cyberattaques contre les entreprises,
peut provoquer, entre autres: la discontinuité de ses services, des fuites de données et des dommages à votre
réputation.
Actuellement, les environnements TIC des entreprises deviennent de plus en plus complexes et
impliquer plus d'appareils pour lesquels une stratégie de sécurité doit être prise en compte
dans le processus métier. Par conséquent, les organisations ont commencé à investir dans les SIEM
pour améliorer votre sécurité ( ).
Le terme SIEM a été inventé en 2005 par Mark Nicolett et Amrit Williams, dans le rapport pour
Gartner a appelé , où ils ont proposé un
système d'information de sécurité combinant deux systèmes qui jusque-là avaient
statut séparé:
Gestion des informations de sécurité ( ): analyse et gestion des logs de sécurité
4 La liste sera élargie tout au long des travaux
sept
Page 24
Gestion des événements de sécurité ( ): gestion des événements de sécurité
Ils étaient limités dans la quantité de données qu'ils pouvaient traiter et la sophistication
les alertes et visualisations qu'ils ont générées. Ce serait la première génération de SIEM, de
les trois que les analystes identifient aujourd'hui ( ).
La deuxième génération de SIEM est mieux équipée pour gérer de grandes quantités de
données historiques et volumes de journaux. Ces SIEM peuvent corréler les données des journaux
événements historiques avec des événements en temps réel.
La troisième génération de SIEM, proposée par Gartner en 2017, combine les capacités
des SIEM traditionnels avec deux nouvelles technologies:
• : Analyse comportementale des utilisateurs et des entités, qui utilise pour établir
lignes de base du comportement des utilisateurs ou des systèmes technologiques
informations et identifier les anomalies pouvant indiquer des incidents de sécurité.
• : Security Orchestration and Automation Response, automatisation de la

sécurité, orchestration et réponse qui peuvent aider les analystes à enquêter rapidement
gérer les incidents et activer les outils de sécurité pour répondre automatiquement
à eux.
Normalement, les SIEM de troisième génération auront un coût associé et ne seront pas
possible de les mettre en œuvre dans notre organisation, avec laquelle nous nous limiterons au SIEM de
deuxième génération avec certaines caractéristiques de la troisième génération, qui couvrira entièrement
nos besoins.
1.7. Structure du document

Le document est structuré comme suit:
• Le chapitre aura lieu le plan de travail du maître, faisant la définition

et la planification pour cela.
• Dans le chapitre , une étude et une analyse générale des SIEM seront menées, pourquoi
en avez-vous besoin dans l'entreprise, quelles seront vos exigences et, enfin, par lesquelles nous avons
décanté. Une fois choisie, ses principales caractéristiques seront décrites.
• Dans le chapitre, vous choisirez où le SIEM sera monté (machine virtuelle, physique ou contenu
nedor) et avec quelle architecture réseau (centralisée ou distribuée).
• Dans le chapitre de la SIEM sera être installé dans notre réseau, d' abord dans un environnement de test
puis en production et le système sera sécurisé.
• Dans le chapitre des agents seront être déployés automatiquement.
• Dans le chapitre , SIEM sera utilisé pour détecter les vulnérabilités, le bon bastion
serveurs, intégrez-le à Nagios et à d'autres cas d'utilisation qui nous sont utiles.
De même, les notifications que le SIEM peut fournir seront étudiées.
• Le chapitre va présenter les conclusions obtenues lors de l' exécution des travaux et la
améliorations possibles qui pourraient être apportées.
• Dans les annexes ,,,,,, et sont les annexes au TFM, nécessaires pour votre
compression mais trop longue pour être incluse dans le corps du document.
Page 25
2
I NVESTIGATION ET
À LA NALYSE
2.1. Etude et analyse générale du SIEM
2.1.1. Définition d'un SIEM
Un SIEM est un outil qui nous permet de centraliser l'interprétation des enregistrements
questions de sécurité pertinentes.
Les menaces détectées par les SIEM appartiennent à certains des groupes suivants:
• Vulnérabilités
• Protocoles vulnérables
• Échecs de configuration par les administrateurs
• Introduction d'erreurs par l'utilisateur consciemment ou non
• Menaces internes
• Menaces externes
Ils nous permettent de collecter, normaliser et corréler les événements de sécurité, fournir des renseignements
gestion de la sécurité, écarter les faux positifs, évaluer l'impact d'une attaque,
unifier la gestion de la sécurité, centraliser les informations et intégrer les outils de sécurité
détection des menaces et des intrus.
Piste 26
CHAPITRE 2. ENQUÊTE ET ANALYSE
2.1.2. Définition d'un IDS

La détection d'intrusion consiste à détecter des événements jugés inappropriés
ou pas les bienvenus dans le système. Cette détection peut être effectuée manuellement,
inspecter le trafic réseau et les journaux pour chaque ressource ou automatiquement
en utilisant des outils. Un outil qui automatise le traitement des informations liées à
Rien avec des intrusions n'est identifié comme un système de détection d'intrusion (IDS). Les
Les IDS sont classés en:
1. (Host Intrusion Detection System): système de détection d'intrusion au niveau de

équipe.
2. (Network Intrusion Detection System): système de détection d'intrusion de niveau

réseau.
Tous les systèmes de détection d'intrusion réseau ne peuvent pas agir

suite à la génération d'une alerte. Ces fonctionnalités avancées sont parfois les
différence entre un NIDS et un (Système de prévention des intrusions sur le réseau).
Un HIDS détecte les événements sur un serveur ou un poste de travail et peut générer des alertes telles que
un NIDS mais est également capable d'inspecter complètement le flux de communication
et les techniques d'évasion NIDS telles que les attaques par fragmentation ne s'y appliquent pas.
De même, les communications cryptées peuvent être surveillées car HIDS inspecte
trafic avant qu'il ne soit chiffré.
Un HIDS doit pouvoir effectuer les vérifications suivantes:
• Vérification de l’intégrité des fichiers
• Surveillance du registre système
• Détection de rootkit
• Réponse active
2.1.3. Architecture générale d'un SIEM

Un SIEM doit fournir les services suivants:
• Gestion des logs: collecte, analyse, corrélation et analyse médico-légale.
• Conformité aux lois et réglementations
• Surveillance des journaux d’application
• Audit d’accès aux objets
• Alerte en temps réel
• Suivi des activités des utilisateurs
• Tableaux d'affichage (tableaux de bord)
• Rapports
• Surveillance de l’intégrité des fichiers
1 Technologies de l'information
dix
Page 27
2.2. Besoin d'un SIEM dans l'entreprise
• Surveillance des journaux et des enregistrements système
• Sécurité au niveau des terminaux (terminaux)
• etc. . .
Dans la figure nous pouvons voir graphiquement les éléments que doit avoir un SIEM.
Collecte de journaux Alerte en temps réel
Suivi de
Analyse du journal
activités des utilisateurs
Panneaux d'affichage
Corrélation de journaux
(Tableaux de bord)
Analyse médico-légale du journal

SIEM Rapports
Conformité aux lois et Surveillance de l'intégrité

normes en informatique de fichiers
Surveillance des logs Surveillance des logs

application appareils et système
Accéder à l'audit Sécurité des points

objets final (points de terminaison)
Figure 2.1: Architecture d'un SIEM
2.2. Besoin d'un SIEM dans l'entreprise

Il réglementant le système de sécurité nationale
dans le domaine de l'administration électronique indique dans son article 3, Champ d'application,
qui sera applicable aux dispositions de l'article 2 de la
. Plus précisément dans la section a):
a) Aux Administrations Publiques, entendues comme l'Administration Générale de l'Etat, le

Administrations des communautés autonomes et des entités qui composent l'administration
Locaux, ainsi que les entités de droit public liées ou dépendant d'elles.
Par conséquent, la Il est applicable dans notre organisation depuis 2010.
Dans le cadre du système de sécurité nationale, à l'annexe II, sont reflétées les mesures de
sécurité à appliquer pour assurer le respect des principes de base et des exigences minimales
établi par elle. Ces mesures sont divisées en trois groupes:
2 Système de sécurité nationale
Onze
Page 28
1. Cadre organisationnel
2. Cadre opérationnel
3. Mesures de protection.
Dans le cadre opérationnel, quelles sont les mesures à prendre pour protéger le fonctionnement du
système comme un ensemble complet de composants, est la surveillance de la
Système. Dans cette section, il est indiqué que pour les systèmes de moyenne et haute catégorie,
Ils disposeront d'outils de détection ou de prévention des intrusions. Par conséquent, la
la mise en œuvre de ce système nous aidera à respecter les .
D'autre part, et en se concentrant sur notre organisation, l'obligation de conformité
du implique la nécessité pour l'organisme d'avoir une politique de sécurité stable
acide; qui se reflétait dans le Pour qui
établit la politique de sécurité des technologies de l'information et de la communication en
l'Administration de la Junta de Andalucía. Ce décret indique que chaque entité
vous devrez établir votre propre politique de sécurité. C'est en octobre 2019 qu'il est approuvé
la politique de sécurité de l'information du ministère dans le
. Plus précisément et lié au thème de cette
les travaux sont indiqués au paragraphe 2 de l'article 25:
2. Étant donné que les services peuvent se dégrader rapidement en raison d'incidents, ils doivent
faire l'objet d'une surveillance continue pour détecter les anomalies dans leurs niveaux de
performance et ainsi pouvoir agir rapidement.
Par conséquent, il est évident que la surveillance des systèmes et la mise en œuvre d'un SIEM
(qui comprend un système de détection et de prévention des intrusions) est une nécessité dans notre
organisation.
2.3. Exigences SIEM à mettre en œuvre

Il y a deux exigences fondamentales que le SIEM choisi doit avoir et elles sont dues au
politiques de notre organisation. La Junta de Andalucía promeut la diffusion et
l'utilisation de logiciels libres, l'un des facteurs envisagés dans la
. De même, dans le
à l'article 1. Objet, il est indiqué qu'il:
• mettre le code source des programmes et applications informatiques à la disposition du public et

les documents qui leur sont associés et qui sont la propriété de l'Administration du Conseil
L'Andalousie et ses organes autonomes, qui auront le caractère de logiciel libre, ainsi que
établir les conditions de son utilisation et de sa distribution gratuites.
En d'autres termes, le logiciel développé par et pour la Junta de Andalucía aura le caractère de
logiciel libre, créant un référentiel public gratuit, il semble donc logique que le système
que nous implantons aussi.
L'autre exigence est que notre délégation provinciale recherche un système qui ne dispose pas
aucun coût associé, qui correspond à l'exigence précédente. Par conséquent, le système à mettre en œuvre
3 Journal officiel de la Junta de Andalucía
12
Page 29
2.4. Choix du SIEM
Il doit s'agir d'un logiciel libre SIEM sans coût associé.
De plus, selon les objectifs spécifiques vus dans la section , comme exigences supplémentaires
nous les aurions:
• Qu'il peut être implémenté dans nos systèmes, prenant en charge la technologie de virtualisation,
Conteneur Docker, etc. . .
• Prend en charge différentes architectures d'implémentation: centralisée, distribuée.
• Qui peut surveiller la plupart des périphériques réseau et des systèmes d’exploitation
Ce que nous avons.
• Cela permet d'être sécurisé, évitant les accès anonymes, les comptes génériques ou le trafic sans
code.
• Cela peut être automatisé dans le déploiement.
• Aidez-nous à nous conformer à l'ENS.
• Qu'il puisse détecter les vulnérabilités dans les différents systèmes dont nous disposons.
• Cela peut être intégré à l'outil de surveillance Nagios.
• Cela permet de détecter les logiciels malveillants, les attaques ou l'intégrité des fichiers.
• Cela permet les notifications.
Sur la base de toutes ces exigences, nous choisirons le SIEM qui répond à la plupart d'entre eux.
2.4. Choix du SIEM

Si nous regardons le Magic Quadrant de Gartner pour 2020 dans la figure , les leaders
sur les systèmes SIEM sont: Splunk, IBM, Exabeam, Securonix, Rapid7, LogRhythm et Dell
Technologies (RSA).
Figure 2.2: Magic Quadrant de Gartner pour SIEM 2020
Ces SIEM ne répondent pas aux deux exigences fondamentales de la section : qu'ils soient
logiciels libres (open source) et qui n'ont aucun coût associé, ils sont donc rejetés.
Nous avons considéré les SIEM open source suivants:
1. AlienVault OSSIM
2. Apache Metron (anciennement Cisco OpenSOC)
13
Page 30
3. MozDef
4. Prelude OSS
5. SIEMonster Community Edition
6. Pile Wazuh + ELK
Nous les analysons dans les tableaux ,,,, et .
AlientVault OSSIM
avantage Désavantages
Construit sur des projets open source éprouvés Manque de nombreuses fonctionnalités de la version payante
Grande communauté d'utilisateurs et de développeurs Ne prend pas en charge les plates-formes cloud comme AWS / Azure
Pas de gestion des logs, visualisations, automatisation

ou intégrations avec des tiers
Architecture serveur centralisée
Problèmes de mise à l'échelle
Tableau 2.1: Avantages et inconvénients d'AlientVault OSSIM
Apache Metron
Automatisation avec Ansible Il ne peut être installé que dans certains environnements et
systèmes d'exploitation
Installation via Docker (Windows / Mac) L'interface n'est pas très intuitive
Tableau 2.2: Avantages et inconvénients d'Apache Metron
SIEMonster (édition communautaire)
Construit sur des projets open source éprouvés Version limitée: 100 Endpoints et 2 rapports
La documentation en ligne est manquante
Interfaces non homogènes
Tableau 2.3: Avantages et inconvénients de SIEMonster (CE)
14
Piste 31
2.4. Choix du SIEM
Prélude OSS
Testé dans le temps: développé depuis 1998 Beaucoup plus limité que les autres solutions open source
ce en termes de performances, de caractéristiques et d'échelle
bilité
Prend en charge un large éventail de formats de journaux Destiné aux tests, évaluations et petits es-
cénarios
Normaliser les données au format 1 (utile pour inter-

changer avec d'autres IDS)
1 Format d'échange de messages de détection d'intrusion
Tableau 2.4: Avantages et inconvénients de Prelude OSS
MozDef
Sans agent: journaux JSON en entrée Nouveau et moins stable que les autres solutions
Mise à l'échelle facile en fonction du volume des événements Installable uniquement via docker ou sur CentOS 7
Prend en charge les sources de données basées sur le cloud Apprentissage amélioré de la configuration et de l'utilisation
(AWS CloudTrail et GuardDuty)
Propulsé par Mozilla, de confiance dans le monde

Open source
Tableau 2.5: Avantages et inconvénients de MozDef
Wazuh
Basé et compatible avec OSSEC Nécessite un déploiement ELK Stack en plus du

Serveur Wazuh
Prend en charge les déploiements Docker, Puppet, Chef et Ansible
Prend en charge la surveillance de l'infrastructure cloud

(payant) (AWS et Azure)
Ensemble de règles qui détecte de nombreux types de

attaques courantes
Conformité avec PCI DSS v3.1 et CIS
Détection des vulnérabilités
Architecture centralisée ou distribuée
Excellente documentation en ligne mise à jour
Tableau 2.6: Avantages et inconvénients de Wazuh
quinze
Piste 32
Dans notre cas, nous avons choisi Wazuh + ELK Stack pour plusieurs raisons:
• Il est open source et vous ne paieriez que pour le support ou la surveillance dans le cloud, mais pas le
nous avons besoin car nous cherchons une solution .
• Il ne s'agit pas d'une version limitée (comme avec OSSIM, Prelude OSS ou SIEMonster).
Il a toutes les fonctionnalités.
• Il est basé sur un HIDS de prestige reconnu, tel que l'OSSEC.
• Documentation en ligne mise à jour et très complète.
• Cluster facilement évolutif, à la fois Wazuh et ELK Stack.
• Surtout, il répond à toutes les exigences indiquées dans la section ,
.
2.5. Analyse du SIEM choisi: Wazuh + Elk Stack
2.5.1. Capacités Wazuh

Wazuh fournit les fonctionnalités suivantes:
Wazuh Security Analytics est utilisé pour collecter, agréger, indexer et analyser les données de
sécurité, aidant les organisations à détecter les intrusions, les menaces et les comportements
événements anormaux.
Détection d'intrusion Les agents Wazuh analysent les systèmes surveillés pour
malware cando, rootkits et anomalies suspectes. Ils peuvent détecter les fichiers et les processus
ports réseau d'écoute masqués et non enregistrés et incohérences dans les réponses aux
appels système. En plus de ces capacités d'agent, le serveur utilise
signatures pour détecter les intrusions, en utilisant son moteur regex pour analyser
les données des journaux stockés et recherchez des indicateurs d'anomalies.
Analyse des données du journal Les agents Wazuh lisent l'application et

système d'exploitation et envoyez-les en toute sécurité au serveur central pour stockage
et effectuer une analyse basée sur des règles. Ces règles aident à avoir des connaissances
erreurs système ou d'application, échecs de configuration, tentatives et / ou succès
activités malveillantes, violations de la politique de sécurité et autres problèmes
de fonctionnement ou de sécurité.
Surveillance de l'intégrité des fichiers Wazuh surveille le système de fichiers identifiable.

la modification du contenu, des autorisations, de la propriété et des attributs de
fichiers que nous indiquons. De plus, il identifie nativement les utilisateurs et les applications
nes utilisé pour créer ou modifier des fichiers.
Détection de vulnérabilité Les agents Wazuh envoient des données d'inventaire depuis
logiciel au serveur où il est mappé aux bases de données continuellement
mis à jour, pour identifier les logiciels vulnérables connus. L'évaluation de
les vulnérabilités nous aident automatiquement à trouver des vulnérabilités
sur les actifs critiques et prendre les mesures correctives nécessaires avant
exploité par des attaquants.
Évaluation de la configuration Wazuh surveille le système et la configuration de

applications pour s'assurer qu'elles sont conformes aux politiques, normes ou
4 Vulnérabilités et exposition courantes
16
Piste 33
guides de bastion. Les agents effectuent des analyses périodiques pour détecter
applications connues pour être vulnérables, non corrigées ou configurées à partir de
manière dangereuse. De plus, les chèques peuvent être personnalisés et adaptés
s'adapter à notre organisation.
Réponse aux incidents Wazuh fournit un ensemble de réponses prêtes à l'emploi,

qui exécutent des contre-mesures qui gèrent les menaces actives, telles que le blocage
accès à un système source de menaces lorsque certains critères sont remplis.
De plus, Wazuh peut être utilisé pour exécuter des commandes à distance ou interroger le
système, identification ( ) et en aidant d'autres activités
tâches médico-légales ou d'intervention en cas d'incident.
Conformité réglementaire Wazuh fournit certains des contrôles de sécurité nécessaires

nécessaires pour répondre aux normes et réglementations de l'industrie. Wazuh peut
utilisé pour répondre aux exigences , ou , en utilisant votre
interface utilisateur Web qui fournit des rapports et des tableaux de bord
cela peut nous aider à le faire.
Surveillance de la sécurité du cloud Wazuh aide à la surveillance de l'infrastructure

Structure dans le cloud de fournisseurs tels qu'Amazon AWS, Azure ou Google Cloud.
Wazuh Container Security offre également une visibilité sur la sécurité dans les conteneurs
Équipements et conteneurs Docker, surveillance de leur comportement et détection des menaces
nazas, vulnérabilités et anomalies.
Dans notre cas, être une installation , et n'ont ni équipement ni conteneurs

Docker, nous n'utiliserons pas les deux dernières fonctionnalités mentionnées.
2.5.2. Composants Wazuh
Wazuh est une solution complète composée de trois composants principaux: OSSEC HIDS,
OpenSCAP et Elastic Stack.
2.5.2.1. OSSEC HIDS
OSSEC HIDS est un système de détection d'intrusion utilisé pour la détection,

visibilité et surveillance du respect des événements de sécurité. Il est basé sur un
agent multiplateforme qui envoie des données système (messages de journal, hachages de fichiers,
anomalies détectées) à un gestionnaire central, où il est ensuite analysé et traité, donnant
en conséquence des alertes de sécurité. Les agents envoient leurs informations via des canaux
sécurisé et authentifié.
De plus, OSSEC HIDS fournit un serveur syslog centralisé et des systèmes de surveillance.
configuration sans agent qui nous permet de détecter les événements et les changements de sécurité
sur les appareils tels que les pare-feu, les routeurs, les commutateurs, etc. . .
5 Guide de bonnes pratiques 13

6 Règlement général sur la protection des données
17
Piste 34
2.5.2.2. OpenSCAP
OpenSCAP est un interprète de et qui sert à vérifier les paramètres

et pour détecter les applications vulnérables. C'est un outil conçu
pour vérifier la conformité de sécurité et la robustesse des systèmes en utilisant des directives
sécurité standard de l'industrie pour les environnements professionnels.
2.5.2.3. Pile élastique
Elastic Stack est une suite de logiciels (Filebeat, Elasticsearch, Kibana) permettant de
collecter, comparer, indexer, stocker, rechercher et présenter les données du journal. Fournit un
environnement Web qui fournit une vue de haut niveau via les panneaux de contrôle (tableaux de bord)
événements qui nous permettent d'effectuer des analyses avancées et de l'exploration de données.
2.5.3. Architecture de Wazuh
Wazuh a deux composants principaux à installer: le gestionnaire Wazuh et Elastic

Empiler. Le type d'installation fait que Wazuh autorise deux types d'architecture:
Architecture centralisée - Le serveur Wazuh et Elastic Stack fonctionnent sur le même
serveur.
Architecture distribuée: serveur Wazuh et cluster Elastic Stack (un
ou plusieurs serveurs) sur différents systèmes.
Dans la figure on peut voir l'architecture dans un seul hôte et dans la figure on peut voir
architecture distribuée.
Figure 2.3: Architecture Wazuh centralisée
La décision sur le type d'architecture qui convient à notre organisation sera prise dans le
chapitre de .
7 Open Vulnerability Assessment Language

8 Liste de contrôle de la configuration extensible Description Format
18
Piste 35
Figure 2.4: Architecture Wazuh distribuée
2.5.3.1. Évolutivité et disponibilité: cluster Wazuh
Wazuh vous permet également de configurer un cluster lorsque nous devons augmenter la capacité de
traitement parce que nous avons des milliers d'agents dans le système qui relèvent du gestionnaire de
Wazuh. Dans ce cas, il y aurait un nœud central (Master) et plusieurs nœuds worker (workers)
auquel la charge des agents serait répartie. L'architecture serait celle montrée
dans la figure , avec un équilibreur de charge devant le cluster Wazuh qui enverrait le
rapports des agents à l'un ou l'autre travailleur. Cela nous donne également de la disponibilité car
si un travailleur tombe en panne, un autre peut le remplacer. Ce que ce régime ne couvrirait pas est un
chute du nœud maître (maître), bien que ce soit une caractéristique (avoir plusieurs maîtres et
disponibilité ( )) que les développeurs de Wazuh n'ont pas encore implémenté,
comme vous pouvez le voir dans le fil de discussion github .
Quant à l'architecture à utiliser, vue dans la section , la décision de savoir si

implémenter un cluster Wazuh ou non dans notre organisation sera prise en phase de
, en fonction du schéma de réseau de notre organisation et du nombre de
agents à déployer.
9 Haute disponibilité
19
Piste 36
Figure 2.5: Cluster Wazuh
vingt
Piste 37
D ESIGNATION ET DÉCISION
3
LES DÉCISIONS
3.1. Architecture de réseau d'organisation

L'organisation de notre Délégation provinciale se compose de deux sièges, parmi lesquels il y a
visibilité au niveau du réseau:
1. Le bureau principal, avec l'adresse 10.xxx/23.

2. Le siège de la formation à distance, avec l'adresse 10.xxx/24.
De même, il existe deux types d'utilisateurs avec accès à distance via une connexion utili-
Facteur d'authentification double Zando: certificat numérique plus nom d'utilisateur et mot de passe d'entreprise.
Ils sont:
• Les utilisateurs qui ont uniquement accès à leur équipe de travail via Remote Desktop
en utilisant le protocole .
• Utilisateurs ayant accès à toutes les adresses du siège (déterminé

utilisateurs du Département d’informatique).
Le schéma de réseau du siège est illustré dans la figure et celle du siège de la formation
est dans la figure .
Pour des raisons de sécurité, toutes les adresses du TFM ont été anonymisées.
1 réseau privé virtuel

2 Protocole de bureau à distance
Piste 38
Accès à distance par RCJA

VPN Réseau d'entreprise Junta de Andalucía l'Internet
RCJA 0.0.0.0/0
Réseaux WAN IP2 VIRTUEL

IP1 VIRTUEL
10.66.160.112/28
BLÊME 10.66.160.115 10.66.160.131
10.66.160.114
10.66.160.128/28
Routeur principal Routeur de sauvegarde
LAN rouge Bord 10.66.160.113 10.66.160.129
10.66.160.130 Teldat M1 Teldat M1
10.66.128.0/23
4ème étage
Les serveurs Cluster Fortigate
WAN1 : 10.66.160.116
Physique ré WAN2 : 10.66.160.132 ré
V à LAN : 10.66.128.1 à V Accès 10.66.128.0/23
Windows 2008 R2 ou t t ou
Pare-feu Pare-feu
Dell PowerEdge T610 z ou ou z
FORTIGATE 50E FORTIGATE 50E
s s
Windows 2012 R2 J9775ASwitchHP
Mode
*13 2530-48G
5 sept
Spd:
lien
9Onze
13
Off
quinze
172530-48G
Mode
19
= vingt
10
Ports
2.lien
Mbps,
25
327
etMode
29
10/100
un
3133
flash
Tous
35de
Mode
37
/ 39
1000Base-T
liaison
=les
41
100
43
ports
lien
Quatre
47
Mbps,
Mode
49
RJ-45
51
Utilisez
cinq
(1on
lien
à(1
=48)
1000+
àuniqu
48) s
3ème étage
J9775ASwitchHP
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
je W W je
Mode
24 6 8lien
dix
12Mode
J9775ASwitchHP
1416
18vingt
lien
ConsoleLocatorFaultPower
J9775ASwitchHP
Mode
*13 2530-48G
5 sept
Spd:
lien
9Onze
13
Off
2224
quinze
Mode
262830
172530-48G
Mode
19
= vingt
10
Ports
2.lien
Mbps,
25
327
32
lien
3.36
etMode
29
10/100
un
3133
4Mode
flash
Tous
35
38
de
404244
Mode
37
/ 39
lien
464Mode
1000Base-T
liaison
=les
41
100
43
ports
lien
8cinquante
Quatre
47
Mbps,
Mode
49
RJ-45
51
lien 52
Utilisez
cinq
(1on
lien
à(1
=48)
1000+
àuniqu
48) s
Lenovo
battement de coeur Commutateurs de pile
Mode
*
24 6 8lien
dix
12Mode
13 2530-48G
Spd:
1416
18vingt
Off
lien
J9775ASwitchHP
Mode
2224Mode
= vingt
10
262830
Ports
Mbps,
32
lien
3.36
10/100
4Mode
flash
Tous
38404244
/ 39
lien
464Mode
1000Base-T
=les
100
ports
8cinquante
Mbps,
RJ-45
lien 52
(1onà(1
=48)
1000+
àuniqu
48) s
P À
J9775ASwitchHP
Mode5 sept
lien
9Onze
13quinze
172530-48G
Mode
19 2.lien
25
327
etMode
29
un
3133 35de
Mode
37liaison
41 43
lien
Quatre
47Mode
4951
Utilisez
cinq
lien
3250 M6
dix 32 54 76
À P LEDModeStatusReset Clear FanTest Console ActFDxSpd *
Mode
24 6 8lien
dix
12Mode
1416
18vingt
lien
ConsoleLocatorFaultPower2224Mode
262830
32
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
CTOX3650M5 3250 M6
dix 32 54 76
HP 2530-J9772A
N N
10.66.128.0/23
LAN LAN Accès
Serveurs Hyper-V W2012R2 WAN2
WAN2 WAN1
WAN1
Mode Spd: Off = 10 Mbps, flash = 100 Ports

Mbps, 10/100
on =/1000+
1000Base-T
Tous
Mbpsles
(1ports
à 48) RJ-45 (1 à 48) sont Auto-MDIX
hacosv01 hacosv02 hacosv03 hacosv04 J9775ASwitchHP 2530-48G *1 3 lien
Mode 5 sept9 Onze13 Mode
quinze
17 lien
19 vingt2. 3et 25
unMode
27 29 de31liaison
33 35 Mode
37 39lien
41 43 Quatre
47 Mode
cinq
49 51lien
J9775ASwitchHP 2530-48G Utilisez uniquement des émetteurs-récepteurs pris en charge
Console
LocatorFaultPower
LEDModeStatus
ActFDxSpd *
FanTest
Réinitialiser
Console Mode
2 4 lien6Effacer
8 dix 12 Mode
14 16lien
18 vingt22 24 Mode26 28lien
30 32 3. 436 Mode
38 40lien
42 44 46 48 Modecinquante
lien 52
Switch Core
Serveurs Hyper-V Ubuntu14.x / 16.x / 18.x
HP 2530-J9772A Coeur 2ème étage Mode
J9775ASwitchHP
Mode
* Spd:
13 2530-48G
5 sept
lien
9OnzeOff
13 = vingt
quinze10
Ports
Mbps,
172530-48G
Mode
19 2.lien
25
32710/100
etMode
29
un flash
Tous
3133 35 / 39
de 1000Base-T
=
Mode
37 les
100
ports
liaison
41 43 Mbps,
lien
Quatre
47 RJ-45
Mode
4951(1onà(1
=48)
Utilisez
cinq
lien 10
àu
J9775ASwitchHP
LEDModeStatusReset
Mode
24 6 8lien
dix
12Mode
1416
18vingt
lien
2224Clear
Mode
262830FanTest
32
lien
3.364Mode
38 Console
4042 44
lien
464ModeActFDxSp
8cinquante
lien 52
Commutateurs de pile J9775ASwitchHP
Mode
*13 2530-48G
Spd:
J9775ASwitchHP
Mode5 sept
lien
9OnzeOff
13 = vingt
quinze
Mode
24 6 8lien
dix
12Mode
1416
10
Ports
18vingt
lien
2224
Mbps,
172530-48G
Mode
19 2.lien
25
327
Mode
10/100
etMode
29
un flash
Tous
3133
262830
32
lien
35
3.36
/ 39
de 1000Base-T
=
Mode
37 les
100
ports
liaison
4Mode
38
41 43 Mbps,
lien
404244
Quatre
LEDModeStatusReset Clear FanTest Console ActFDxSp
47
lien
RJ-45
Mode
49
464Mode
51(1onà(1
=48)
Utilisez
cinq
lien
8cinquante
10
àu
lien 52
J9775ASwitchHP
Mode
*13 2530-48G
Spd:
J9775ASwitchHP
Mode5 sept
lien
9OnzeOff
13 = vingt
quinze10
Ports
Mbps,
172530-48G
Mode
19 2.lien
25
32710/100
etMode
29
un flash
Tous
3133 35 / 39
de 1000Base-T
=
Mode
37 les
100
ports
liaison
41 43 Mbps,
lien
Quatre
47 RJ-45
Mode
4951(1onà(1
=48)
Utilisez
cinq
lien 10
àu
HP 2530-J9772A LEDModeStatusReset Clear FanTest Console ActFDxSp
Mode
24 6 8lien
J9775ASwitchHP
Mode
*
dix
12Mode
13 2530-48G
5 sept
Spd:
lien
1416
9Onze
13
18vingt
Off
lien
2224
quinze
Mode
262830
172530-48G
Mode
19
= vingt
10
Ports
2.lien
Mbps,
25
327
32
lien
3.36
etMode
29
10/100
un
3133
4Mode
flash
Tous
35
38
de
404244
Mode
37
/ 39
lien
464Mode
1000Base-T
liaison
=les
41
100
43
ports
lien
8cinquante
Quatre
47
Mbps,
Mode
49
RJ-45
51
lien 52
Utilisez
cinq
(1on
lien
à(1
=48)
10
àu
J9775ASwitchHP
hacolx05 hacolx06 hacolx07 hacolx08 hacolx09 LEDModeStatusReset Clear FanTest Console ActFDxSp
Mode
24 6 8lien
dix
12Mode
1416
18vingt
lien
262830
32
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
Virtuel 10.66.128.0/23
Cabine
EMC VNX5200
J9775ASwitchHP
*Mode
Mode
1 32530-48G
J9775ASwitchHPSpd:
5sept
lien 13Off
9 Onze =vingt
quinze
Mode 10
Ports
Mbps,
172530-48G
19 2.lien
327
25 10/100
etMode
29
un flash
Tous
3133 / 1000Base-T
35de =
les
Mode
373941100
ports
liaison
43 Mbps,
lien
Mode
J9775ASwitchHP
2 4 68lien
*Mode
dix
12Mode
141618vingt
lien
2224Mode
26283032
lien
3.364Mode
38404244
49RJ-45
Quatre
47
lien
Mode
464Mode
(1onà (1
48)
= 1000+
51Utilisez
cinq
lien
8cinquante
àuniquement
lien 52
48) sont
MbpsAuto-MDIX
des émetteurs-récepteurs pris en charge Accès
1Mode
32530-48G
J9775ASwitchHPSpd:
5sept
lien 13Off
9 Onze =vingt
quinze
Mode 10
Ports
Mbps,
172530-48G
19 2.lien
327
25 10/100
etMode
29
un flash
Tous
3133 / 1000Base-T
35de =
les
Mode
373941100
ports
liaison
43 Mbps,
lien 49RJ-45
Quatre
47Mode (1onà (1
48)
= 1000+
51Utilisez
cinq
lien àuniquement
48) sont
MbpsAuto-MDIX
des émetteurs-récepteurs pris en charge
Commutateurs de pile LEDModeStatusReset Clear FanTest Console ActFDxSpd *
J9775ASwitchHP
Mode
2 4 68lien
*Mode
1Mode
J9775ASwitchHP
dix
5sept
12Mode
32530-48G
Spd:
lien
141618vingt
13Off
9 Onze
lien
2224Mode
=vingt
quinze
Mode 10
26283032
Ports
Mbps,
172530-48G
19 2.lien
327
25
lien
etMode
29
un
3.364Mode
10/100
3133
38404244
flash
Tous
35de
Mode
3739
lien
464Mode
/ 1000Base-T
=
les
41100
ports
liaison
43
lien
8cinquante
Mbps,
49RJ-45
Quatre
47Mode (1
lien 52
onà (1
48)
= 1000+
51Utilisez
cinq
lien àuniquement
48) sont
MbpsAuto-MDIX
des émetteurs-récepteurs pris en charge
HP 2530-J9772A ConsoleLocatorFaultPower
Mode
2 4 68lien
dix
12Mode
141618vingt
lien
2224Mode
26283032
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
10.66.128.0/23 J9775ASwitchHP 2530-48G 2530-48G

J9775ASwitchHP
1er étage
J9775ASwitchHPMode
*132530-48G
Spd:
J9775ASwitchHP
Mode 5 sept
lien Off
9 Onze
13 = vingt
quinze 10
Ports
Mbps,
172530-48G
Mode
19 2.lien
3 27
25 10/100
etMode
29un flash
Tous
3133 35 / 1000Base-T
de
Mode
37 =
les
39 100
ports
liaison
41
43 Mbps,
lien
Quatre
47 RJ-45
Mode
49 (1onà (1
48)
= 1000+
51Utilisez
cinq
lien àuniq
48)
Mode
24 6 8lien
dix
12Mode
14
1618vingt
lien
2224Mode
26283032
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
J9775ASwitchHPMode
*132530-48G
Spd:
J9775ASwitchHP
Mode 5 sept
lien Off
9 Onze
13 = vingt
quinze 10
Ports
Mbps,
172530-48G
Mode
19 2.lien
3 27
25 10/100
etMode
29un flash
Tous
3133 35 / 1000Base-T
de
Mode
37 =
les
39 100
ports
liaison
41
43 Mbps,
lien
Quatre
47 RJ-45
Mode
49 (1onà (1
48)
= 1000+
51Utilisez
cinq
lien àuniq
48)
Mode
24 6 8lien
dix
12Mode
14
1618vingt
lien
2224Mode
26283032
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
Mode
13J9775ASwitchHP
Spd: Off = vingt
10
Ports
Mbps,
2530-48G
10/100
flash
Tous / 1000Base-T
=
les100
ports
Mbps,
RJ-45
(1onà (1
48)
= 1000+
àuniq
48)
Commutateurs de pile
J9775ASwitchHP
Mode
* 2530-48G
5 sept
lien
9 Onze
J9775ASwitchHP 13
quinze
172530-48G
Mode
19 2.lien
3 27
25etMode
29un
3133 35de
Mode
3739
liaison
41
43
lien
Quatre
47Mode
49
51Utilisez
cinq
lien
Mode
24 6 8lien
dix
12Mode
14
1618vingt
lien
2224Mode
26283032
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
Vlan-id J9775ASwitchHPMode
13J9775ASwitchHP
Mode
* Spd:
2530-48G
5 sept
lien Off
9 Onze
J9775ASwitchHP 13 = vingt
quinze 10
Ports
Mbps,
2530-48G
172530-48G
Mode
19 2.lien
3 27
25 10/100
etMode
29un flash
Tous
3133 35 / 1000Base-T
de
Mode
37 =
les
39 100
ports
liaison
41
43 Mbps,
lien
Quatre
47
LEDModeStatusReset Clear FanTest Console J9775ASwitch
RJ-45
Mode
49 (1onà (1
48)
= 1000+
51Utilisez
cinq
lien àuniq
ActFDxSpd *
48)
HP 2530-J9772A
Mode
24 6 8lien
dix
12Mode
14
1618vingt
lien
26283032
lien
3.364Mode
38404244
lien
464Mode
8cinquante
lien 52
Données internes: 20
J9775ASwitchHP 2530-4
Voix: 21
Externe: 22 Accès 10.66.128.0/23
PC Windows 10 Téléphone VoIP Siemens
PC Windows 7
Figure 3.1: Schéma du réseau principal du siège
Piste 39
l'Internet
LAN rouge RCJA 0.0.0.0/0
10.66.250.0/24
Les serveurs
CPD
Physique
Routeur 10.66.250.1
Windows 2012 R2
HP XW4600
Serveur Hyper-V Ubuntu 16.x

Commutateur
hacolx10 Enterasys B5g214-24p2
Virtuel
10.66.250.0/24
CLASSE 3 - ORDINATEURS
Professeur
SECRÉTAIRE SALLE DE CLASSE
SALLE
1 DE CLASSE 2
Professeur Professeur
élèves
Figure 3.2: Schéma du réseau du siège de la formation
Piste 40
CHAPITRE 3. CONCEPTION ET PRISE DE DÉCISION
Sur la base de ces schémas de réseau, la décision sera prise sur la manière de mettre en œuvre Wazuh dans notre
organisation.
3.2. Choix du déploiement: virtuel, physique ou conteneur

Pour implanter Wazuh il y a 3 possibilités: l'implantation dans une machine physique, dans un
virtuel ou dans un conteneur. Nous les analysons dans les sections suivantes.
3.2.1. Implémentation dans une machine physique

Dans notre infrastructure, nous n'avons pas de serveurs physiques capables de gérer les exigences
Wazuh a recommandé la toux sur le fil . Plus précisément, les éléments suivants sont recommandés:
• Gestionnaire Wazuh: 4 cœurs, 16 Go de RAM et 1 To d'espace disque par nœud.

• Pile élastique: 8 cœurs, 32 Go de RAM minimum et 64 Go maximum, 1 To minimum de
espace disque par nœud (bien que ce dernier dépende des données stockées dans
Élastique).
Ces exigences recommandées nous empêchent de le déployer sur un serveur physique.
3.2.2. Déploiement dans un conteneur Docker

Il existe un conteneur Docker pour Wazuh qui utilise , qui a le tour 4
conteneurs:
1. Wazuh
2. Elasticsearch
3. Kibana
4. Nginx: c'est le serveur web proxy inverse qui sera utilisé pour accéder à kibana dans un
crypté avec nom d'utilisateur et mot de passe.
Au départ, une tentative a été faite pour utiliser Wazuh avec Docker sur Windows en utilisant la technologie
sur un PC (qui est celui utilisé sur les serveurs de notre organisation) pour
à travers . Cependant, cela nous a donné des erreurs lors du démarrage et nous avons créé un fil
dans le forum Wazuh pour en savoir plus. Là, ils nous ont dit qu'ils existent
Limitations de la virtualisation lors de l'utilisation de conteneurs Linux sous Windows. (Regarder
pour plus d'informations).
«Nos images Docker sont basées sur Ubuntu 16.04 LTS, donc leur exécution sous Windows est
impossible en raison des limitations de la virtualisation ".
En revanche, il serait possible d'utiliser Wazuh avec Docker sur Windows en utilisant la technologie
de à travers de , mais les anciennes versions de
VirtualBox (version 5.2.0) et, nous utiliserions vraiment une machine virtuelle à l'intérieur
de VirtualBox. Pour cela il est plus simple et plus efficace d'utiliser VirtualBox directement avec le
image .ova que Wazuh a préparée.
Tout ce qui précède nous amène à rejeter l'utilisation de conteneurs Docker depuis notre infrastructure
ture fonctionne avec les serveurs Windows 2012 R2 avec la technologie Hyper-V pour la virtualisation,
qui n'est actuellement pas pris en charge par les conteneurs Linux en général et Wazuh dans
particulier.
24
Piste 41
3.2. Choix du déploiement: virtuel, physique ou conteneur
3.2.3. Implémentation d'une image virtuelle

Dans cette option, nous installerions Wazuh dans une machine virtuelle. Dans ce cas, il y a deux
possibilités:
1. Utilisez une version précompilée, fournie par Wazuh. Ici nous avons, à notre tour,
trois options de virtualisation: , et :
à) : Utilisez la version précompilée de Wazuh pour VirtualBox (exten-

sión .ova) qu'au moment de la rédaction de cet article, cette section contient les éléments
défini dans la section .
3.2.3.1. Éléments de la version précompilée
• CentOS 7
• Wazuh 3.11.4
• API Wazuh 3.11.4
• Elasticsearch 7.6.1
• Filebeat 7.6.1
• Kibana 7.6.1
• Application Wazuh 3.11.4-7.6.1
Également avec les caractéristiques de la machine virtuelle indiquées dans la section suivante
( ).
3.2.3.2. Fonctionnalités de la machine virtuelle précompilée
• 4 Go de RAM
• RedHat 64 bits
• 4 processeurs
• 16 Mo de RAM écran
• Disque dur de 40 Go (dynamique)
b) : Utilisez la version précompilée de Wazuh pour (extension

.ovf + .vmdk) avec le même contenu que ci-dessus.
c) : Il n'y a pas d'image précompilée Wazuh pour Hyper-V (extension

.vhdx) mais il existe des tutoriels sur Internet pour convertir des images VMware en
Hyper-V. C'est un processus qui n'est pas anodin et nous dépendons d'outils tiers
comme , et scripts .
Nous avons dû corriger quelques erreurs mais il était possible d'importer le
vmdk sur un PC de test Hyper-V en suivant les liens ci-dessous:
• .
Nous rejetons les deux premières options car dans notre organisation nous n'utilisons pas ou
Technologie VirtualBox ou VMware, mais nous utilisons Hyper-V.
2. Installez Wazuh + ELK Stack à partir de zéro dans une ou plusieurs machines virtuelles de notre
environnement.
25
Piste 42
3.2.4. Méthode d'implantation sélectionnée

La décision prise a été d'installer Wazuh + ELK Stack à partir de zéro dans un ou plusieurs
machines virtuelles sur nos serveurs avec la technologie Hyper-V, pour les raisons suivantes:
1. Nous dépendons de l'infrastructure actuelle de notre organisation basée sur la technologie

Virtualisation Hyper-V.
2. Nous aurons une haute disponibilité, avec deux nœuds physiques et un cluster virtuel actif.
actif.
3. Le matériel utilisé (2 serveurs Lenovo CTOX3650M5, Intel Xeon CPU E5-2640 v4

(2 processeurs c / u ), avec 512 Go de RAM c / uy 15 To d'espace de stockage
Shared Cabin EMC VNX5200) est le meilleur que nous ayons.
4. Les images précompilées sont utiles pour avoir une idée générale du système et
démarrage rapide, mais pour le connaître à fond et le maîtriser, il vaut mieux effectuer
une propre installation à partir de zéro.
5. Nos serveurs Linux sont Ubuntu Server et nous avons une meilleure connaissance de
ces systèmes (.deb) que le système CentOS (.rpm) qui est monté dans les versions
précompilé.
6. Il n'y a pas d'image précompilée pour Wazuh Hyper-V comme nous l'avons vu dans le
séparé et, bien qu'il puisse être obtenu avec plusieurs , il ne serait pas
une image «propre» fournie par Wazuh, qui pourrait nous causer des problèmes.
En outre, nous aurions besoin de passer du temps à convertir à partir de l'image VMware
à Hyper-V qui est clairement compensé par le nécessaire pour installer à partir de zéro
Wazuh + pile ELK.
La ou les machines virtuelles créées (cela dépend de l'architecture utilisée, qui sera décidée
dans la section ), doit avoir comme exigences minimales celles indiquées comme caractéristiques
dans la section .
3.3. Architecture réseau: centralisée ou distribuée

Comme nous l'avons vu dans la section , Wazuh peut être installé avec une architecture centralisée
(partageant le même serveur Wazuh et Elastic Stack) ou distribué (séparant le serveur
Wazuh de la pile élastique). Dans notre cas, nous avons déjà une expérience avec l'un des
Composants de pile élastique, en particulier avec Elasticsearch, lors de son utilisation comme moteur de recherche dans
un Mediawiki de l'organisation. Ce composant consomme pas mal de ressources (en particulier
mémoire) et nous considérons qu'il est préférable qu'il soit séparé du serveur Wazuh pour
avoir une surveillance individuelle des deux machines et, si nécessaire, pouvoir modifier
ses ressources et / ou sa configuration sans affecter l'autre. Par conséquent, en principe, il sera choisi
pour installer le serveur Wazuh sur une machine virtuelle et Elastic Stack sur une autre.
D'autre part, un autre aspect à considérer en termes d'architecture est la question d'échelle.
labilité et disponibilité à l'aide d'un cluster Wazuh, comme nous l'avons vu dans la section .
Concernant l'évolutivité, dans notre cas et l'analyse des schémas de réseau de notre
organisation (chiffres et ), le numéro de à déployer ne dépassera pas 50. Ce
3 chacun
26
Piste 43
3.4. Conception finale de la mise en œuvre et de l'architecture
nombre de points de terminaison est facilement géré sans qu'il soit nécessaire d'utiliser le cluster Wazuh (avec
un enseignant et plusieurs ouvriers, plus un équilibreur). Son utilisation est recommandée
et nécessaire lorsque nous allons déployer des centaines ou des milliers de terminaux, ce qui n'est pas notre cas.
Concernant la disponibilité, il faut noter que le cluster Wazuh ne fournit pas

haute disponibilité, car si le Master tombe le système tombe, comme nous l'avons vu dans la section
. Par conséquent, ce n'est pas une raison de le déployer. Dans notre cas, haute disponibilité
sera couvert puisque nous installerons les machines virtuelles en production dans le cluster de
le basculement que nous avons déployé sur les serveurs Windows 2012 R2, pour
que, dans le cas où l'un des deux nœuds physiques (serveurs Lenovo) tombe, ils se dirigent vers le
autre les machines virtuelles et le système ne plante pas.
3.4. Conception finale de la mise en œuvre et de l'architecture

La mise en œuvre finale du serveur Wazuh sera le déploiement de deux machines virtuelles, une
pour Wazuh Server et un pour Elastic Stack dans le cluster de basculement Windows
2012 R2. Les deux auront Ubuntu Server dans sa dernière version stable ( ), installée
à partir de zéro et ayant comme exigences minimales celles utilisées par les images précompilées
que propose Wazuh et que nous avons vu dans la section .
L'architecture finale des serveurs physiques et virtuels des bureaux avec Wazuh implémentée
sera celui montré sur la figure indépendamment du fait que les agents soient finalement
déployé sur plus de terminaux (par exemple sur les PC des enseignants
ou ceux des étudiants) ou qui sont surveillés sans agent ( ) autres appareils (pour
exemples de commutateurs) en envoyant les journaux au serveur syslog Wazuh.
27
Piste 44
SIÈGE SOCIAL SIÈGE DE FORMATION

Physique Physique
Windows 2008 R2 Windows 2012 R2
Dell PowerEdge T610 HP XW4600
Windows 2012 R2
Lenovo dix 32 54 76
Virtuel
3250 M6
CTOX3650M5 3250 M6
dix 32 54 76
Serveurs Hyper-V Ubuntu16.x

Agents Wazuh
hacolx10
Virtuel
Serveurs Hyper-V W2012R2
Agents Wazuh
Serveurs Windows
hacosv01 hacosv02 hacosv03 hacosv04
Serveurs Hyper-V Ubuntu14.x / 16.x / 18.x
hacolx05 hacolx06 hacolx07 hacolx08 hacolx09
Serveurs Ubuntu
Agents Wazuh
Serveur ELK Serveur Wazuh
Pile élastique Serveur Wazuh
Elasticsearch Gestionnaire Wazuh
Kibana Filebeat
Application Wazuh API Wazuh
Pile Wazuh + ELK
Figure 3.3: Conception et architecture de la mise en œuvre finale Wazuh + ELK Stack
28
Piste 45
I NSTALLATION
4
4.1. Installation de test SIEM
L'installation du test Wazuh et ELK Stack sera effectuée sur mon équipe de travail, qui
présente les caractéristiques suivantes:
• Windows 10 Professionnel 64 bits (prend en charge Hyper-V, contrairement à la version familiale qui ne le fait pas)
• HP 400 g5, i5-8500 3 Ghz avec 8 Go de RAM
• Disque dur SSD de 256 Go
Deux machines virtuelles ont été créées avec Hyper-V, appelées wazuh-server-tests et wazuh-
essais d'élan comme indiqué dans l'annexe . Sur ces machines, Ubuntu a été installé
Serveur 18.04.4 LTS, en suivant les instructions de l'annexe .
Une fois que nous avons les deux machines virtuelles opérationnelles, mises à jour et avec une IP fixe visible
Pour le reste des équipes de l'organisation, nous pouvons commencer par l'installation. Être en
tests, nous réaliserons machines virtuelles au cas où nous devions revenir
un point précédent.
4.1.1. Installation du serveur Wazuh
Pour l'installation, nous suivrons la documentation en ligne ( ). Tout d'abord, pour

Ubuntu Server nous avons deux options:
1. Installer à partir des référentiels

2. Installer à partir du code source
1 instantané
Piste 46
CHAPITRE 4. INSTALLATION
En principe pour une installation en tests et voir que la version des référentiels est
mis à jour et c'est la même chose que si nous l'avons installé à partir du code source, nous avons opté pour le premier
option qui est plus simple et plus rapide. Cette installation est documentée en annexe .
La prochaine étape serait d'installer la pile Elastic.
4.1.2. Installation du serveur ELK Stack

En ce qui concerne la , nous avons la possibilité d'installer le serveur

Elastic Stack à partir de packages ou binaires précompilés au format tar.gz,
mais il est indiqué dans la documentation que cette deuxième option n'est pas prise en charge et n'est pas la
conseillé. En plus des composants de la pile Elastic, vous devez installer l'application
depuis Wazuh (via un plugin Kibana). Cette installation est documentée en annexe
.
4.1.3. Mise à jour des versions Wazuh et ELK
Au cours du développement du mémoire de maîtrise, la version Wazuh a été mise à jour, passant
de 3.11.4 à 3.12.0-2, ainsi que de la pile ELK, passant de 7.6.1 à 7.6.2. Cela a
documenté en annexe dans la section pour Wazuh Server et Wazuh API, en annexe
dans la section pour la mise à jour Kibana et Elasticsearch et dans la section
pour le plugin Wazuh pour Kibana.
4.1.4. Problèmes de sécurité dans une installation par défaut
On voit que l'installation initiale présente plusieurs problèmes de sécurité:
1. Il n'y a pas d'authentification ou de cryptage pour accéder au portail Kibana.
2. Il n'y a pas de communication chiffrée entre le serveur Wazuh (API Wazuh) et le

Plugin Wazuh pour Kibana.
3. Vous utilisez les utilisateurs par défaut (user: foo et password: bar) pour accéder au
API Wazuh.
4. Le serveur Elasticsearch n'est pas sécurisé.
Parce que pour sécuriser le système, nous devons générer des certificats via notre
, établir s pour les serveurs dans le serveur de noms, etc ..., cela déjà
nous ferons en production.
En revanche, nous avons vérifié que l'installation initiale du serveur Wazuh (Ubuntu +
Wazuh Server) est <3 Go et le serveur avec ELK Stack est <8 Go. Ledit espace
il augmentera progressivement en raison des journaux, des événements, etc. . . mais cela nous donne une idée de la taille
initiale appropriée pour les machines virtuelles. Nous avons également observé que le
Elastic consomme toute la mémoire fournie et peut-être en production nous devrions l'augmenter.
2 Autorité de certification
30
Piste 47
4.2. Installation en production du SIEM sécurisé

Pour l'installation de production, nous suivons les mêmes étapes que pour l'installation dans
tests que nous avons vus dans la section changer uniquement les adresses IP, les noms et les caractéristiques
des machines virtuelles (comme indiqué dans les annexes et ).
Une fois installés, les deux ont été ajoutés au cluster Windows 2012 R2 des deux serveurs
serveurs physiques, de sorte qu'il n'y ait pas de manque de disponibilité si l'un des deux serveurs physiques n'est pas
soulevé (arrêt pour maintenance, redémarrages programmés pour les mises à jour du système,
etc...). Ceci est documenté dans la section en annexe .
De plus, les enregistrements nécessaires ont été créés dans le DNS afin que le
certificats numériques nécessaires basés sur leur FQDN pour sécuriser l'application et les communications
cations. Cela a été documenté dans la section de l'annexe .
Pour résoudre les problèmes trouvés dans la section , nous devons effectuer 3 actions:
1. Sécurisez l'API Wazuh
2. Sécurisez la pile élastique
3. Fournissez l'authentification à Elastic Stack
Nous voyons cela dans les sections suivantes.
4.2.1. Sécurisez l'API Wazuh
4.2.1.1. Activer https dans l'API Wazuh
Tout d'abord, nous devons activer https. Pour ce faire, nous avons deux options: générer notre
propre certificat manuellement ou automatiquement avec un script fourni par Wazuh
dans votre documentation en ligne.
Dans notre cas, nous avons déjà créé un dans l'organisation, installée en tant qu'entité de
certification racine de confiance dans les clients et qui nous permet de générer des certificats pour
nos serveurs. Par conséquent, nous utiliserons cette autorité de certification pour générer le
certificat.
Le certificat du serveur wazuh (utilisé à la fois pour sécuriser l'API Wazuh

comme Filebeat), il a été généré en annexe dans la section . Il se compose de deux fichiers: un
clé privée (wazuh-server.key) et une clé publique (wazuh-server.crt).
Pour sécuriser l'API Wazuh, nous devons copier les fichiers où les fichiers de configuration nous indiquent.
ration /var/ossec/api/configuration/config.js , que nous laissons comme ceci:
// Utilisez le protocole HTTP sur TLS / SSL. Valeurs: oui, non.

config.https = "oui";
// Certificats HTTPS
config.https_key = "configuration / ssl / wazuh-server.key"
config.https_cert = "configuration / ssl / wazuh-server.crt"

config.https_use_ca = "oui"
config.https_ca = "configuration / ssl / rootCA.pem"
31
Piste 48
Maintenant, nous copions les fichiers des certificats Wazuh et le :
root @ serveur wazuh: ~ # cp wazuh-serveur.key / var / ossec / api / configuration / ssl /
root @ serveur-wazuh: ~ # cp serveur-wazuh.crt / var / ossec / api / configuration / ssl /

root @ serveur-wazuh: ~ # cp rootCA.pem / var / ossec / api / configuration / ssl /
Et nous redémarrons le service:
root @ wazuh-server: ~ # systemctl restart wazuh-api
Maintenant, nous devons aller sur le serveur ELK et dire au plugin Kibana Wazuh que nous allons
utilisez https au lieu de http. Nous éditons le fichier: / usr / share / kibana / Optimize / wazuh /
config / wazuh.yml et nous changeons en https ce qui était dans http:
hôtes:
- défaut:
URL: https: //10.xx57
port: 55000
utilisateur: foo
mot de passe: bar
4.2.1.2. Modifier les informations d'identification par défaut
Par défaut, les informations d'identification de connexion pour l'API Wazuh sont foo / bar. Nous allons
les modifier manuellement (ce serait également possible via un script automatiquement).
root @ serveur-wazuh: ~ # cd / var / ossec / api / configuration / auth
root @ wazuh-server: / var / ossec / api / configuration / auth # node htpasswd -Bc -C 10 utilisateur WazuhCor
Nouveau mot de passe:

Re-taper le nouveau mot de passe:
Ajout du mot de passe pour l'utilisateur WazuhCor.
Nous avons déjà créé le nouvel utilisateur appelé WazuhCor avec le mot de passe correspondant.
Ensuite, nous redémarrons le service API Wazuh.
Ensuite, nous irions sur le serveur ELK et éditerions le fichier de configuration du plugin
Wazuh pour Kibana, /usr/share/kibana/optimize/wazuh/config/wazuh.yml et pon-
Nous donnerions l'utilisateur WazuhCor et le nouveau mot de passe:
hôtes:
- défaut:
port: 55000
utilisateur: WazuhCor
mot de passe: <mot de passe>
32
Piste 49
4.2.1.3. Changer le port par défaut
Par défaut, le port utilisé par l'API Wazuh est 55000. Il est recommandé de le changer. Pour
Par conséquent, nous éditons le fichier /var/ossec/api/configuration/config.js et le changeons en
55999 par exemple.
// Port TCP utilisé par l'API.
config.port = "55999";
Ensuite, nous le modifions également dans le plugin Wazuh pour Kibana, dans le fichier / usr /
partager / kibana / optimiser / wazuh / config / wazuh.yml
hôtes:
- défaut:

port: 55999
utilisateur: WazuhCor
mot de passe: <mot de passe>
Et nous redémarrons l'API Wazuh:
Et nous devrions déjà avoir l'API Wazuh sécurisée à l'aide du trafic https, sur un port
différent de la valeur par défaut et avec un nom d'utilisateur / mot de passe qui n'est pas la valeur par défaut, comme
on voit dans la figure
Figure 4.1: Sécurisation de l'API Wazuh
4.2.2. Sécuriser la pile élastique
4.2.2.1. Pourquoi sécuriser Elastic Stack
Il est fortement recommandé de sécuriser Elastic Stack afin que les données fuient comme celles-ci
s'est produit dans les nouvelles
.
Ils étaient dus à un serveur Elastic Search non sécurisé, comme détaillé dans
Pour sécuriser Elastic Stack, il existe trois options:
33
Piste 50
1.
2.
3. comme proxy inverse pour Kibana (authentification simple et SSL)
4.2.2.2. X-Pack
Nous avons choisi car il ajoute nativement l'authentification et le cryptage. Précédent-

l'esprit était une fonctionnalité qui devait être payée (dans ce cas, Search Guard
qui n'avait aucun coût associé) mais à partir de la version 7.1.0 la sécurité peut être configurée
sans aucun frais. ( ).
Pour ajouter l'authentification et le chiffrement, nous avons besoin d'un et des certificats numériques pour
Serveur Wazuh (pour Filebeat), Elasticsearch et Kibana. Dans notre cas, comme Elasticsearch
et Kibana sont sur le même serveur, seuls deux certificats seraient nécessaires, un par machine
virtuel.
Dans la documentation Wazuh ( ), un outil est utilisé qui génère tous

les certificats nécessaires, y compris une autorité de certification, appelée elasticsearch-certutil. Comme
Nous avons déjà un CA dans notre organisation qui est également ajouté par les directives de
groupe aux navigateurs d'équipement et nous avons déjà généré le certificat du serveur Wazuh
dans la section , nous n'aurions qu'à générer un certificat pour le serveur Elk
(wazuh-élan). Nous l'avons fait dans l'annexe dans la section .
Une fois que nous avons les certificats, nous les copions sur le site approprié.
Dans notre cas, nous aurons les certificats suivants:
• rootCA.key: clé privée du certificat CA de l'organisation

• rootCA.pem: clé publique du certificat CA de l'organisation
• wazuh-server.key: clé privée du certificat pour le serveur Wazuh (utilisée dans
wazuh-api et filebeat)
• wazuh-server.crt: clé publique du certificat pour le serveur Wazuh
• wazuh-elk.key: clé privée du certificat pour le serveur ELK (utilisée dans
Elasticsearch et kibana)
• wazh-elk.crt: clé publique du certificat pour le serveur ELK
Par conséquent, tout d'abord, nous copions la clé publique du certificat CA et la clé privée et publique
du serveur ELK vers le répertoire Elasticsearch et configurez les permissions:
root @ wazuh-elk: ~ # mkdir / etc / elasticsearch / certs / ca -p
root @ wazuh-elk: ~ # cp rootCA.pem / etc / elasticsearch / certs / ca
root @ wazuh-elk: ~ # cp wazuh-elk.crt / etc / elasticsearch / certs

root @ wazuh-elk: ~ # cp wazuh-elk.key / etc / elasticsearch / certs
root @ wazuh-elk: ~ # chown -R elasticsearch: / etc / elasticsearch / certs
root @ wazuh-elk: ~ # chmod -R 770 / etc / elasticsearch / certs
Nous ajoutons les paramètres pour les couches transport et http dans le fichier / etc /
elasticsearch / elasticsearch.yml:
3. 4
Piste 51
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificat
xpack.security.transport.ssl.key: /etc/elasticsearch/certs/wazuh-elk.key
xpack.security.transport.ssl.certificate: /etc/elasticsearch/certs/wazuh-elk.crt
xpack.security.transport.ssl.certificate_authorities: ["/etc/elasticsearch/certs/ca/rootCA.pem"]
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.verification_mode: certificat
xpack.security.http.ssl.key: /etc/elasticsearch/certs/wazuh-elk.key
xpack.security.http.ssl.certificate: /etc/elasticsearch/certs/wazuh-elk.crt
xpack.security.http.ssl.certificate_authorities: ["/etc/elasticsearch/certs/ca/rootCA.pem"]
Nous redémarrons Elasticsearch
root @ wazuh-elk: ~ # systemctl redémarrer elasticsearch
4.2.2.3. Configurer l'instance Filebeat (gestionnaire Wazuh)
Dans la machine serveur Wazuh (serveur wazuh), nous copions les certificats nécessaires
et nous établissons les autorisations appropriées:
root @ wazuh-elk: ~ # mkdir / etc / filebeat / certs / ca -p
root @ wazuh-elk: ~ # cp wazuh-server.crt / etc / filebeat / certs
root @ wazuh-elk: ~ # cp wazuh-server.key / etc / filebeat / certs

root @ wazuh-elk: ~ # cp rootCA.pem / etc / filebeat / certs / ca
root @ wazuh-elk: ~ # chmod 770 -R / etc / filebeat / certs
Nous ajoutons la configuration nécessaire dans le fichier /etc/filebeat/filebeat.yml:
output.elasticsearch.hosts: ['10 .xx40: 9200 ']
output.elasticsearch.protocol: https
output.elasticsearch.ssl.certificate: "/etc/filebeat/certs/wazuh-server.crt"
output.elasticsearch.ssl.key: "/etc/filebeat/certs/wazuh-server.key"
output.elasticsearch.ssl.certificate_authorities: ["/etc/filebeat/certs/ca/rootCA.pem"]
Nous pouvons tester Filebeat avec la commande "filebeat test output" pour voir que nous nous connectons.
Nous avons chiffré et sécurisé le serveur Elasticsearch:
root @ wazuh-server: ~ # sortie du test filebeat
elasticsearch: https: //10.xx40: 9200 ...
analyser l'url ... OK
connexion ...
analyser l'hôte ... OK

recherche DNS ... OK
adresses: 10.xx40
appeler ... OK
TLS ...
sécurité: la vérification de la chaîne de certificats du serveur est activée
poignée de main ... OK

Version TLS: TLSv1.3
appeler ... OK
35
Piste 52
parler au serveur ... OK
version: 7.6.2
Et enfin nous redémarrons Filebeat:
root @ wazuh-server: ~ # systemctl redémarrer filebeat
4.2.2.4. Configurer l'instance Kibana
Sur la machine avec ELK Stack, nous créons le répertoire / etc / kibana / certs et copions le
autorité de certification et certificats wazuh-elk là-bas.
root @ wazuh-elk: ~ # mkdir / etc / kibana / certs / ca -p
root @ wazuh-elk: ~ # cp rootCA.pem / etc / kibana / certs / ca

root @ wazuh-elk: ~ # cp wazuh-elk.crt / etc / kibana / certs
root @ wazuh-elk: ~ # cp wazuh-elk.key / etc / kibana / certs

root @ wazuh-elk: ~ # chown -R kibana: / etc / kibana / certs
root @ wazuh-elk: ~ # chmod -R 770 / etc / kibana / certs
Nous ajoutons la configuration nécessaire dans /etc/kibana/kibana.yml
elasticsearch.hosts: ["https: //10.xx40: 9200"]
elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/certs/ca/rootCA.pem"]
elasticsearch.ssl.certificate: "/etc/kibana/certs/wazuh-elk.crt"
elasticsearch.ssl.key: "/etc/kibana/certs/wazuh-elk.key"
server.ssl.enabled: true
server.ssl.certificate: "/etc/kibana/certs/wazuh-elk.crt"
server.ssl.key: "/etc/kibana/certs/wazuh-elk.key"
Nous redémarrons Kibana
root @ wazuh-elk: ~ # systemctl redémarre kibana
Une fois cela fait, nous aurions déjà une communication https entre toutes les parties impliquées. À
alors nous ajouterions l'authentification.
4.2.3. Authentification pour Elastic Stack
Pour ajouter l'authentification à Elastic Stack, nous procédons comme suit:
• Nous ajoutons la ligne suivante au fichier /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: true
• Nous redémarrons Elasticsearch et attendons que le service soit prêt:
36
Piste 53
root @ wazuh-elk: ~ # systemctl redémarrer elasticsearch
• Nous générons des informations d'identification aléatoires pour tous les utilisateurs et rôles préchargés dans le
Pile élastique avec l'utilitaire elasticsearch-setup-passwords:
root @ wazuh-elk: ~ # / usr / share / elasticsearch / bin / elasticsearch-setup-passwords auto
Lancement de la configuration des mots de passe pour les utilisateurs réservés
↪→ élastique, apm_system, kibana, logstash_system, beats_system, remote_monitoring_user.

Les mots de passe seront générés aléatoirement et imprimés sur la console.
Veuillez confirmer que vous souhaitez continuer [o / N]
• Nous notons le mot de passe de l'utilisateur élastique et gardons tous les autres au même endroit
assurance.
• Nous établissons les informations d'identification de l'utilisateur Elastic dans Filebeat. Pour ce faire, nous éditons le
fichier /etc/filebeat/filebeat.yml (sur la machine serveur wazuh) et:
output.elasticsearch.username: "élastique"
output.elasticsearch.password: "password_generated_for_elastic"
• Nous redémarrons Filebeat:
root @ wazuh-elk: ~ # systemctl redémarre filebeat
• Nous établissons également les informations d'identification pour Kibana. Nous ajoutons au fichier / etc / kibana /
kibana.yml:
xpack.security.enabled: true
elasticsearch.username: "élastique"
elasticsearch.password: "password_generated_for_elastic"
• Nous redémarrons Kibana:
Nous aurions déjà sécurisé toutes les communications et l'authentification établie, avec laquelle
nous pourrions accéder à l'interface Web pour nous connecter à l'URL
et l'image de la figure nous serait présentée .
Comme nous pouvons le voir, nous utilisons une connexion https avec un certificat valide signé par notre
Autorité de certification (Figure ).
37
Piste 54
Figure 4.2: Connexion sécurisée au portail Kibana
Figure 4.3: Portail d'authentification Kibana avec X-Pack
38
Piste 55
4.3. Surveillance des serveurs Wazuh dans Nagios
4.3. Surveillance des serveurs Wazuh dans Nagios

Il est recommandé de surveiller les deux serveurs pour plusieurs raisons:
• Premièrement, nous devons savoir si des services de serveur Wazuh

(wazuh-manager, wazuh-api) ou le serveur ELK (Elasticsearch, Kibana) est en panne et
doit être levé.
• Deuxièmement, il est conseillé de surveiller les ressources du

système tel que la charge du processeur, la mémoire et l'espace utilisé, etc. pour voir si
il y a un goulot d'étranglement et nous devons faire évoluer le système, soit en augmentant
mémoire, processeurs, espace disque, etc ...
Pour surveiller les serveurs avec Nagios, nous utiliserons . Le processus d'installation et
la configuration, n'étant pas directement liée à Wazuh, est décrite dans l'annexe .
Une fois la configuration décrite dans ladite annexe réalisée, on obtient un suivi
Serveurs Wazuh comme indiqué dans les figures et .
Figure 4.4: Serveur Wazuh surveillé dans Nagios
Figure 4.5: Serveur ELK surveillé dans Nagios
3 Exécuteur de plugins à distance Nagios
39
Psaumes
Piste 56 57
D SPLIT
5
5.1. Déploiement automatique de l'agent
Une fois que les serveurs Wazuh et Elastic sont en cours d'exécution, l'étape suivante consiste à déployer
les agents des équipes ( ) pour la collecte d'informations et, comme indiqué dans
les objectifs de la section , en essayant d'utiliser des outils d'automatisation.
Dans notre cas, les systèmes d'exploitation sur lesquels les agents seront déployés sont au nombre de deux: Windows
et Linux. Nous allons maintenant étudier le déploiement dans chacun de ces systèmes.
5.2. Déploiement automatique sur les systèmes Linux

Wazuh permet le déploiement automatique d'agents Linux avec deux options: Puppet et Ansible.
Dans notre cas, nous avons choisi Ansible pour sa simplicité basée sur ssh. Installation et
La configuration initiale d'Ansible est détaillée dans l'annexe . Une fois cette installation terminée et
configuration, nous pouvons passer à l'installation du playbook et du rôle de l'agent Wazuh.
5.2.0.1. Obtenez les livres de jeu et les rôles de Wazuh
Wazuh a créé des playbooks et des rôles pour Ansible avec lesquels il est possible d'installer le
composants du serveur Wazuh, Elastic Stack ou agents, clonant le
référentiel dans / etc / ansible / roles. Comme condition préalable, nous avons besoin de l'outil git
qui est déjà installé par défaut sur notre serveur Wazuh. Tout d'abord, nous configurons
notre proxy pour git:
jpcozar @ wazuh-server: ~ $ sudo git config --global http.proxy http://10.xxx:3128
Ensuite, nous créons le répertoire pour les rôles Ansible et clonons le référentiel.
Psaumes 58
CHAPITRE 5. DÉPLOIEMENT
jpcozar @ wazuh-server: ~ $ sudo mkdir / etc / ansible / roles; cd / etc / ansible / roles
jpcozar @ wazuh-server: / etc / ansible / roles $ sudo git clone
↪→ https://github.com/wazuh/wazuh-ansible.git
Nous pouvons maintenant installer n'importe lequel des rôles que nous avons téléchargés.
5.2.0.2. Installez l'agent
Nous pouvons maintenant voir les rôles et playbooks préconfigurés dans le répertoire / etc /
ansible / roles / wazuh-ansible:
jpcozar @ wazuh-server: ~ $ cd / etc / ansible / roles / wazuh-ansible
jpcozar @ wazuh-server: / etc / ansible / roles / wazuh-asinble $ ls -l playbooks

total 24
-rw-r - r-- 1 racine racine 430 6 avril 12:16 wazuh-agent.yml
-rw-r - r-- 1 racine racine 2750 6 avril 12:16 wazuh-élastique_stack-distribué.yml
-rw-r - r-- 1 racine racine 446 6 avril 12:16 wazuh-élastique_stack-single.yml
-rw-r - r-- 1 racine racine 163 6 avril 12:16 wazuh-élastique.yml
-rw-r - r-- 1 racine racine 145 6 avril 12:16 wazuh-kibana.yml
-rw-r - r-- 1 racine racine 210 6 avril 12:16 wazuh-manager.yml
Nous utiliserons le playbook wazuh-agent.yml et le rôle wazuh-agent.
Le fichier de configuration par défaut est / etc / ansible / roles / wazuh-ansible / roles /
wazuh / ansible-wazuh-agent / defaults / main.yml
Le fichier pour configurer les clients sera / etc / ansible / roles / wazuh-ansible / playbooks /
wazuh-agent.yml.
5.2.0.3. Préparez le playbook
Il faut créer un fichier YAML similaire ou modifier l'existant pour l'adapter à la configuration.
tion. Dans ce cas, nous renommons l'original:
jpcozar @ wazuh-server: ~ $ cd / etc / ansible / roles / wazuh-ansible / playbooks; sudo cp wazuh-agent.yml
↪→ wazuh-agent.yml.original
Maintenant nous modifions le fichier / etc / ansible / roles / wazuh-ansible / playbooks / wazuh-
agent.yml paramètre Hôtes clients Ansible (dans notre cas, tous les serveurs
Linux), gestionnaire et proxy Wazuh:
---
- hôtes: hacolx05, hacolx06, hacolx07, hacolx08, hacolx09, hacolx10

les rôles:
- ../roles/wazuh/ansible-wazuh-agent
vars:
wazuh_managers:
- adresse: 10.xx57
port: 1514
protocole: udp
api_port: 55999
42
Piste 59
5.2. Déploiement automatique sur les systèmes Linux
api_proto: 'https'
api_user: WazuhCor
wazuh_agent_authd:
adresse_enregistrement: 10.xx57
activer: vrai
port: 1515
ssl_agent_ca: null
ssl_auto_negotiate: 'non'
environnement:
http_proxy: http://10.xxx:3128
https_proxy: http://10.xxx:3128
Et maintenant, nous pouvons exécuter la commande Ansible pour installer le rôle dans chacun des
les serveurs:
jpcozar @ wazuh-server: / etc / ansible / roles / wazuh-ansible / playbooks $ ansible-playbook
↪→ wazuh-agent.yml -b -K
Mot de passe SUDO:
Une fois exécuté avec succès, nous obtiendrons une image comme celle de la figure .
Figure 5.1: Exécution réussie d'Ansible
Sur le serveur Wazuh, nous exécutons la commande suivante pour voir que le
agents:
root @ serveur-wazuh: ~ # / var / ossec / bin / manage_agents -l
Agents disponibles:
ID: 001, nom: hacolx05, IP: 10.xxx
43
Piste 60
CHAPITRE 5. DÉPLOIEMENT
Et dans chacun des serveurs qui ont l'agent, nous avons pu voir qu'il est installé et
en cours d'exécution avec la commande:
root @ wazuh-server: ~ # systemctl status wazuh-agent
Et on nous montrerait ce que nous voyons dans la figure
Figure 5.2: Agent Wazuh en cours d'exécution
Et nous pouvions déjà voir les serveurs Linux enregistrés dans Kibana (figure ).
Figure 5.3: Agents Wazuh des serveurs Linux à Kibana
44
Piste 61
5.3. Déploiement automatique sur les systèmes Windows
5.3. Déploiement automatique sur les systèmes Windows
5.3.1. Déploiement de l'agent Wazuh par GPO

Pour déployer l'agent sur les serveurs Windows, nous utiliserons la mise en œuvre de
logiciel par stratégie de groupe ( ) pour tous les serveurs du siège
font partie de notre domaine. Cela a été documenté dans l'annexe .
5.3.1.1. Installation manuelle sur un serveur autonome
Dans le cas du lieu de formation, une installation manuelle sera effectuée car il s'agit d'un
serveur autonome, pas de domaine. Dans ce dernier cas, nous exécuterons la commande suivante
dans en tant qu'administrateur:
PS D: \ Wazuh - agent . \ Wazuh - agent -3.12.0-1. msi / q WAZUH_MANAGER = "10.xx57"
↪→ WAZUH_REGISTRATION_SERVER = "10.xx57"
Une fois la directive et la commande précédente exécutées, nous aurions tous les serveurs Windows
enregistré, comme on le voit sur la figure .
Figure 5.4: Agents Wazuh des serveurs Windows dans Kibana
5.4. Créer des groupes à Wazuh

Une fois que nous avons tous les serveurs à surveiller enregistrés, il est pratique de créer des groupes
pour que tout soit mieux organisé et pour pouvoir appliquer les politiques de groupe à l'avenir. Dans notre
Dans ce cas, nous allons créer un groupe appelé LinuxServers et un autre WindowsServers. Les deux création
car l'affectation de groupe peut être effectuée depuis le terminal ou depuis l'environnement Kibana.
Nous le ferons à partir de Kibana car c'est plus facile et plus rapide. Pour cela, nous allons
Gestion et sélectionnez Groupes, créant deux groupes:
1. Serveurs Linux
2. WindowsServers
Et puis nous affectons les agents déjà enregistrés à chacun de leurs groupes.
Avec cela, nous terminons la phase de déploiement et nous pouvons commencer à voir les cas d'utilisation.
1 objet de stratégie de groupe
Quatre cinq
Piste 63
62
C ASOS D'UTILISATION
6
6.1. Surveillance de l'intégrité des fichiers: FIM
En surveillant l'intégrité des fichiers ( ), nous détectons et alertons
lorsque des modifications se produisent dans les fichiers système et d'application. Par défaut
est activé pour certains répertoires à la fois pour Linux et Windows, et nous
indique si les fichiers surveillés ont été ajoutés, supprimés ou modifiés.
Nous pouvons ajouter les fichiers que nous voulons surveiller. Dans notre cas, par exemple, nous avons
un fichier de mots de passe départemental généré avec l'application ce qui nous intéresse
ont contrôlé. Le fichier, appelé passwords.kdbx, se trouve sur un partage Samba, qui
nous montons via le fichier / etc / fstab du serveur Linux hacolx05 dans le répertoire
/ mnt / KEEPASS.
Maintenant, nous éditons le fichier ossec.conf sur le serveur Linux (hacolx05) et ajoutons le
suivant pour pouvoir surveiller le répertoire avec le fichier de mot de passe:
<syscheck>
....
<directories> / mnt / KEEPASS </directories>
<skip_nfs> non </skip_nfs>

...
</syscheck>
Afin de vérifier les ressources NFS ou CIFS, nous devons utiliser l'option <skip_nfs>. Il y a
Notez que nous ne pouvons pas utiliser l'option pour vérifier les fichiers en temps réel (comme
nous le ferons lors de l'utilisation de VirusTotal) car inotify est utilisé sous Linux pour détecter les changements.
Si nous modifions le fichier de ressources CIFS de Linux où il est monté, si nous voyions le
modification en temps réel. Mais la chose normale sera de faire la modification de Windows qui
Piste 64
CHAPITRE 6. CAS D'UTILISATION
est l'endroit où nous avons installé le programme Keepass. Par conséquent, inotify ne détectera pas le changement
et la notification en temps réel ne fonctionnera pas. Ce que nous allons faire, c'est réduire l'intervalle de
syscheck à 15 minutes.
Une fois cela fait, nous redémarrons l'agent et essayons de modifier le fichier:
root @ wazuh-server: # systemctl restart wazuh-agent
Et il devrait déjà apparaître dans les alertes et dans Kibana lorsque nous modifions le fichier, comme
on voit dans la figure
Figure 6.1: Intégrité du fichier de mot de passe Keepass
Nous pouvons également générer une alerte qui nous avertit avec un certain niveau de gravité. Pour
nous créons une règle dans le fichier /var/ossec/etc/local_rules.xml avec ce qui suit
contenu:
<group name = "local, syscheck, ossec" >
<rule id = "100004" level = "12" >
<if_group> syscheck </if_group>
<match> /mnt/KEEPASS/passwords.kdbx </match>

<description> Modifications apportées à passwords.kdbx - Fichier critique! </description>
</rule>
</group>
Et lorsque l'événement ci-dessus se produit, il nous enverra une alerte de niveau 12, avec un ID de règle
que 100004, comme on le voit sur la figure
Nous verrons un autre exemple de surveillance de l'intégrité du système de fichiers dans le

intégration avec VirusTotal dans la section .
Ensuite, nous voyons une extension du FIM, qui nous permet, en plus de surveiller le fichier,
faire une vérification de qui et comment l'a fait. Cette fonctionnalité s'appelle who-data et est
disponible pour Windows et Linux.
48
Piste 65
6.1. Surveillance de l'intégrité des fichiers: FIM
Figure 6.2: Alerte sur le fichier de mot de passe Keepass
49
Piste 66
6.2. Audit Who-Data

Grâce à cette option Wazuh, nous pouvons voir quel utilisateur a apporté les modifications aux fichiers
surveillé, le nom du programme ou du processus utilisé pour le réaliser
et quand cela a été fait.
6.2.1. Audit Who-Data sur Linux

Afin d'effectuer l'audit sous Linux, nous devons avoir le service d'audit installé dans
Serveurs Linux. Dans notre cas, nous utilisons à nouveau Ansible pour l'afficher, comme
voir en annexe , section .
Une fois installé, si par exemple nous voulons surveiller qui apporte des modifications au répertoire
/ etc jusqu'au niveau 1 en profondeur (par exemple, nous voulons savoir qui a modifié
les fichiers / etc / passwd, / etc / shadow, /etc/hosts.allow, etc. . . ), nous devons effectuer
changements dans les agents dans le fichier de configuration /var/ossec/etc/ossec.conf. Comme
nous voulons le faire pour tout Linux, nous utiliserons la configuration centralisée (qui sera vue
encore dans la section ). Nous éditons sur le serveur Wazuh, le fichier commun à tous
les agents des serveurs Linux qui se trouvent dans / var / ossec / etc / shared / LinuxServers /
agent.conf et ajoutez le bloc suivant:
<config_agent>
...
<syscheck>
<répertoires check_all = "yes" whodata = "yes"
↪→ recursion_level = "0" > / etc </directories>
</syscheck>
...
</agent_config>
Nous indiquons que nous voulons surveiller qui accède à quoi dans le répertoire / etc mais seulement
du premier niveau (récursion 0). Une fois cela fait, nous vérifions la configuration de l'agent et
Nous redémarrons le service wazuh-manager sur le serveur et les agents à distance:
root @ serveur-wazuh: # / var / ossec / bin / verifiy-agent-conf
root @ wazuh-server: # systemctl restart wazuh-manager
root @ serveur-wazuh: # / var / ossec / bin / agent_control -R -a
Maintenant, dans l'un des agents Linux, nous pouvons vérifier si la règle est appliquée:
root @ serveur-wazuh: # auditctl -l | grep wazuh_fim
-w / etc / -p wa -k wazuh_fim
Plus tard, nous modifions, par exemple, le fichier /etc/hosts.allow du serveur hacolx05
et, en plus de voir que le fichier a été modifié dans la section Surveillance de l'intégrité
de Kibana, si nous recherchons l'alerte générée, nous pouvons voir qui l'a fait (jpcozar) de quoi
formulaire (en utilisant sudo), avec quel programme (en utilisant l'éditeur vim) et à quelle heure,
comme on le voit sur la figure
cinquante
Piste 67
6.2. Audit Who-Data
Figure 6.3: Audit de fichier Linux
51
Piste 68
6.2.2. Audit Who-Data sous Windows
De la même manière, nous pourrions suivre en temps réel qui a modifié certains
répertoires et fichiers sous Windows. Par exemple, si nous voulons surveiller le fichier d'hôtes de
Windows (C: \ Windows \ system32 \ drivers \ etc \ hosts), nous ajouterions le bloc suivant
dans le fichier de configuration commun / var / ossec / etc / shared / WindowsServers / agent.
conf à partir des serveurs Windows:
<config_agent>
...
<syscheck>
...
<répertoires check_all = "yes" whodata = "yes" > % WINDIR% \ SysNative \ drivers \ etc </directories>
</syscheck>
...
</agent_config>
Une fois cela fait, nous vérifions la configuration de l'agent et redémarrons le service
wazuh-manager sur le serveur et les agents à distance:
root @ serveur-wazuh: # / var / ossec / bin / verifiy-agent-conf
Maintenant, si nous modifions le fichier d'hôtes Windows C: \ Windows \ system32 \ drivers \

etc \ hosts, nous verrions l'alerte dans l'onglet Surveillance de l'intégrité comme nous le voyons dans le
figure
Figure 6.4: Audit de fichiers sous Windows - Surveillance de l'intégrité
Et l'alerte avec l'audit indiquant qui (l'administrateur), comment (en utilisant le bloc-notes) et
lorsque le fichier a été modifié, comme on le voit sur la figure
52
Piste 69
6.2. Audit Who-Data
Figure 6.5: Audit de fichiers sous Windows
53
Piste 70
6.3. Détection des vulnérabilités

C'est une fonctionnalité très intéressante de Wazuh qui nous permet de détecter des vulnérabilités
connu à la fois sur les systèmes Linux (Debian, Ubuntu, Red Hat) et Windows.
Pour le premier, il existe ses propres fichiers de base de données fournis par Debian,
Canonical et Red Hat respectivement et pour Windows, la vulnérabilité nationale est utilisée
Base de données ( ).
Il existe deux façons pour Wazuh d'obtenir ces fichiers de vulnérabilité:

en ligne ou hors ligne si nous sommes derrière un pare-feu ou un proxy (tout comme notre
Cas).
6.3.1. Détection de vulnérabilité dans les serveurs Ubuntu
6.3.1.1. Paramètres du gestionnaire Wazuh
Il faut tout d'abord activer la détection des vulnérabilités en général sur le serveur
Wazuh, dans le fichier /var/ossec/etc/ossec.conf.
...
<détecteur de vulnérabilité>
<enabled> oui </enabled>
<interval> 5m </interval>
<ignore_time> 6h </ignore_time>
<run_on_start> oui </run_on_start>
...
Et dans le même bloc xml, nous devrions activer les systèmes (appelés fournisseurs) pour le
nous voulons que les vulnérabilités soient détectées. On peut l'indiquer par le nom de la version
ou par le nombre. Comment nous allons surveiller les serveurs Ubuntu 14.x (Trusty Tahr), 16.x
(Xenial) et 18.x (Bionic) ce sont ceux que nous n'activerons que:
...
< nom du fournisseur = "canonical" >

<os> fidèle </os>
<os> xenial </os>
<os> bionique </os>
<update_interval> 1h </update_interval>
</provider>
...
Ce que font ces options est de télécharger les fichiers pour Bionic, Xenial et Trusty, respectivement.
vamente:
1 Base de données nationale sur la vulnérabilité
54
Piste 71
Mais le bug que nous avons signalé dans , c'est que

les fichiers fournis par Canonical à ces adresses et censés être xml
ils sont compressés et sont en fait .xml.bz2. Par conséquent, nous avons dû choisir un
propre configuration hors ligne. Dans ce cas, les étapes sont:
1. Nous créons un répertoire de téléchargement de vulnérabilités pour Ubuntu:

root @ serveur-wazuh: # mkdir -p / var / ossec / hors-ligne-vulnérabilités / ubuntu
2. Nous créons un script qui effectue les téléchargements et la décompression des fichiers pour
Ubuntu que nous appelons ubuntu-generator.sh:
#! / bin / bash
################################################ ############
# Utilisation: Script pour télécharger les flux canoniques dans xml.bz2
# Date: avril 2020
# Auteur: Javier Polo Cózar
################################################ ############
WGET = ` qui wget `
Bunzip2 = ` qui bunzip2 `
DIR = "/ var / ossec / offline-vulnérabilités / ubuntu"
URL = "https://people.canonical.com/~ubuntu-security/oval/"
pre = "com.ubuntu."
pos = ".cve.oval.xml"
pour moi dans bionic xenial trusty
faire
$ WGET $ URL / $ pre $ i $ pos -O $ DIR / $ pre $ i $ pos .bz2
$ BUNZIP2 -df $ DIR / $ pré $ i $ pos .bz2
terminé
3. Maintenant, nous mettons une tâche dans la crontab, qui les télécharge toutes les heures par exemple:
@hourly /var/ossec/offline-vulnerabilities/ubuntu-generator.sh> / dev / null
4. Nous pouvons maintenant modifier le fichier /var/ossec/etc/ossec.conf sur le serveur

Wazuh et changez de fournisseur, indiquant qu'il prendra les flux localement. le
on part comme ça:
< nom du fournisseur = "canonical" >

<os path = "/var/ossec/offline-vulnerabilities/ubuntu/com.ubuntud.trusty.cve.oval.xml" > l
↪→ fidèle </os>
<os path = "/var/ossec/offline-vulnerabilities/ubuntu/com.ubuntu.xenial.cve.oval.xml" > l
↪→ xenial </os>
<os path = "/var/ossec/offline-vulnerabilities/ubuntu/com.ubuntu.bionic.cve.oval.xml" > l
↪→ bionique </os>
</provider>
5. Lorsque nous avons terminé, nous redémarrons le gestionnaire Wazuh.
2 Le problème a été résolu par l'équipe Wazuh dans la version 3.12.1
55
Psaumes 72
root @ serveur wazuh: / var / ossec / etc # systemctl redémarrer wazuh-manager
6.3.1.2. Configuration des agents pour les serveurs Linux
Dans chacun des agents dans lesquels nous voulons exécuter l'analyse de vulnérabilité
nous devons vérifier que le module utilisé pour collecter les packages est installé dans le
système. Pour ce faire, nous éditons le fichier /var/ossec/etc/ossec.conf et vérifions que le
le bloc ressemble à ceci:
<wodle name = "syscollector" >

<disabled> non </disabled>
<interval> 1h </interval>
<scan_on_start> oui </scan_on_start>
<hardware> oui </hardware>
<os> oui </os>
<network> oui </network>
<packages> oui </packages>
<ports all = "no" > oui </ports>
<processes> oui </processes>
</wodle>
Et ils devraient commencer à rechercher les vulnérabilités. Si nous avons un problème, veuillez
Activons le débogage des modules dans le fichier / var / ossec / etc / sur le serveur Wazuh
internal_options.conf définissant l'option:
wazuh_modules.debug = 2
puis redémarrer le service wazuh-manager. Une fois cela fait, nous effectuerions
une recherche dans le journal du module de détection de vulnérabilité, avec la chaîne:
root @ wazuh-server: # grep Vulnérabilité-Detecteur /var/ossec/logs/ossec.log
2020/04/06 15:48:17 wazuh-modulesd: vulnérabilité-détecteur: INFO: (5452): vulnérabilité de départ
↪→ balayage.
2020/04/06 15:51:03 wazuh-modulesd: Vulnérabilité-Detecteur: INFO: (5461): Démarrage d'Ubuntu Bionic
↪→ mise à jour de la base de données.
2020/04/06 15:51:17 wazuh-modulesd: Vulnérabilité-Detecteur: INFO: (5494): La mise à jour du
↪→ Le flux Ubuntu Bionic s'est terminé avec succès.
2020/04/06 15:51:17 wazuh-modulesd: Vulnérabilité-Detecteur: INFO: (5461): Démarrage d'Ubuntu Xenial
↪→ mise à jour de la base de données.
Comme on le voit sur la figure les vulnérabilités trouvées dans le

Serveurs Ubuntu de notre organisation, pouvant filtrer par serveur, vulnérabilité CVE,
paquet concerné, etc ...
6.3.2. Détection des vulnérabilités dans les serveurs Windows

Pour détecter les vulnérabilités dans les systèmes Windows, on utilise la base de données de
la . Nous avons également l'option en ligne ou hors ligne.
56
Piste 73
Figure 6.6: Vulnérabilités dans les serveurs Linux / Ubuntu
Encore une fois, nous avons détecté un bogue dans la configuration hors ligne que nous avons signalé dans
.
La configuration en ligne fonctionnait à la maison (sans proxy et pare-feu) mais pas

Dans l'organisation. Nous avons donc dû appliquer le expliqué dans
pour pouvoir détecter les vulnérabilités dans Windows.
Il consiste à définir le proxy dans le fichier de configuration /etc/ossec-init.conf sur
Les flux Internet peuvent être obtenus via le proxy.
6.3.2.1. Configuration du serveur Wazuh
Nous configurons le serveur pour qu'il obtienne les mises à jour de l'année 2010 et que
mise à jour toutes les heures:
< nom du fournisseur = "nvd" >
<update_from_year> 2010 </update_from_year>
</provider>
6.3.2.2. Configuration de l'agent pour les serveurs Windows
Dans ce cas, chaque agent doit avoir une configuration similaire à celle-ci.
3 Un bug a finalement été pris en compte dans la documentation de Wazuh

4 rodéo
57
Piste 74
<os> oui </os>
<hotfixes> oui </hotfixes>

</wodle>
C'est celui qui vient par défaut, à l'exception de la balise <hotfixes> yes </hotfixes> qui nous permet
détecter les correctifs appliqués. Comment devrions-nous faire ce changement dans chacun des
surveillé les serveurs Windows, au lieu de le faire à la main, nous allons utiliser le
configuration centralisée.
6.4. Configuration centralisée

En faisant créer les groupes, les agents peuvent être configurés à distance à l'aide du fichier
agent.conf. Dans notre cas, nous voulons modifier les agents du groupe Windows, donc
Nous éditons le fichier agent.conf qui réside dans / var / ossec / etc / shared / WindowsServers.
Nous laissons ce fichier comme ceci:
<agent_config os = "Windows" >
<! - Inventaire système ->

<os> oui </os>
<hotfixes> oui </hotfixes>
</wodle>
</agent_config>
Et dans quelques minutes, nous aurions sur chacun des serveurs Windows, dit fichier dans le
chemin C: \ Program Files (x86) \ ossec-agent \ shared. Pour vérifier que l'agent avec
ID 007 - Windows Server, il est synchronisé nous exécutons:
root @ serveur-wazuh: # / var / ossec / bin / agents_groups -S -i 007

L'agent '007' est synchronisé.
Une fois déployé, il commencerait à détecter les vulnérabilités des systèmes Windows
comme on le voit sur la figure .
A titre d'exemple, nous avons installé les logiciels Adobe Reader XI et Google Chrome, pour
vérifier qu'il détecte non seulement les correctifs pour le système d'exploitation, mais également les vulnérabilités
58
Piste 75
6.5. Intégration avec VirusTotal
des dans le logiciel. C'est ce qu'il fait à travers le (Common Platform Enumeration), création
Wazuh un dictionnaire auxiliaire qui traduit l'inventaire réalisé par Syscollector du
Agents Windows dans un format valide pour les flux obtenus à partir de la vulnérabilité nationale
Base de données.
Figure 6.7: Vulnérabilités dans les serveurs Windows

Wazuh peut être intégré au service en ligne analyse de fichier pour
détection de virus, vers, chevaux de Troie et autres logiciels malveillants. Il existe une API publique avec
les restrictions suivantes:
1. Il y a une limite de 4 demandes par minute, 1 000 par jour et 30 000 par mois.
2. Un accès de faible priorité est accordé aux demandes effectuées par cette API.
3. L'API ne peut pas être utilisée dans des produits ou services commerciaux.
Et puis il y a une API privée sans limitation.
Dans notre cas, puisque nous avons un antivirus d'entreprise et que nous voulons seulement
essayez-le dans certains répertoires (par exemple dans l'un des wikis d'entreprise où le
les utilisateurs peuvent télécharger des fichiers), nous utiliserons l'API publique. Pour obtenir la clé API dont nous avons besoin
inscrivez-vous dans la communauté VirusTotal. Une fois cela fait, nous éditons le fichier / var /
ossec / etc / ossec.conf et ajoutez à la fin, avant la balise </ossec_config>, ce qui suit
bloquer:
59
Psaumes 76
<ossec_config>
...
<intégration>
<name> virustotal </name>
<api_key> "API_GENERADA" </api_key>
<group> syscheck </group>
<alert_format> json </alert_format>
</integration>
...
</ossec_config>
6.5.1. Utiliser FIM pour surveiller un annuaire

Dans les wikis, les utilisateurs peuvent télécharger des fichiers avec ces extensions: pdf, png, gif, jpg,
jpeg, doc, xls, mpp, ppt, tiff, bmp, docx, xlsx, pptx, ps, odt, ods, odp, odg, svg.
Ces fichiers sont enregistrés dans le chemin / var / www / html / wiki-sief / images / dans divers sous-
répertoires en cours de création. Nous irions donc sur le serveur Linux qui héberge le wiki
(dans ce cas hacolx08) et nous éditerions le fichier de l'agent /var/ossec/etc/ossec.conf
en ajoutant les éléments suivants pour surveiller le répertoire de téléchargement en temps réel:
<syscheck>
...
<répertoires check_all = "oui"
↪→ realtime = "oui" > / var / www / html / wiki-sief / images </directories>

...
</syscheck>
Il existe des fichiers de test avec des logiciels malveillants qui nous permettent de tester les systèmes antivirus. Une
d'entre eux est disponible en téléchargement sur le web . Le problème est que
les fichiers fournis ont une extension .com, .txt ou .zip, qui ne serait pas valide
pour le télécharger sur le wiki car l'extension n'est pas autorisée et la modifier indiquera une erreur
de type MIME puisque Mediawiki effectue une vérification de l'extension de fichier avec le
Tête de lit.
Mais un utilisateur malveillant pourrait intégrer un tel malware dans un fichier doc et
le vider en pdf, qui a été la solution que nous avons trouvée . Ce fichier pdf est celui qui
nous avons utilisé comme tests. Une fois téléchargé sur Mediawiki, on voit qu'il est détecté, à la fois dans
les alertes (figure ) comme dans l'interface de l'agent en particulier (figure ).
60
Piste 77
Figure 6.8: Alerte virale avec VirusTotal
Figure 6.9: Principales alertes hacolx08: virus détecté
61
Piste 78
6.6. Surveillance sans agent

Dans notre organisation, il existe des appareils sur lesquels l'agent ne peut pas être installé mais
nous voulons surveiller. Par exemple des commutateurs. Plus précisément, nous voulons surveiller
échec des tentatives d'authentification sur ces commutateurs, modèle HP 2530. Ce que nous allons faire
enverra vos journaux (restriction par gravité = avertissement et facilité = auth) au serveur
Wazuh syslog, où nous les analyserons et lancerons les alertes nécessaires.
Pour mener à bien cette tâche, nous nous sommes documentés avec le livre OSSEC Host-Based Intrusion
Guide de détection ( ), en particulier dans le chapitre 4 Travailler avec des règles, où
nous travaillons avec les événements et dans la définition de nouveaux décodeurs (décodeurs) et règles
(règles).
Le processus suivi a été, tout d'abord, de se connecter au commutateur et de le configurer pour que
envoyer les événements appropriés au serveur Wazuh:
CHAP-COR-001-SWLAN12 # config
CHAP-COR-001-SWLAN12 (config) # logging 10.xx57 control-descr serveur wazuh
CHAP-COR-001-SWLAN12 (config) # installation de journalisation auth
CHAP-COR-001-SWLAN12 (config) # avertissement de gravité de la journalisation

CHAP-COR-001-SWLAN12 (config) # write mem
Dans ce serveur, nous activons la capture des logs par syslog dans le fichier / var / ossec / etc /
ossec.conf à partir de l'adresse IP du commutateur:
<remote>
<connection> syslog </connection>

<allowed-ips> 10.xx246 </allowed-ips>
</remote>
Et pour vérifier que les événements nous parviennent, sur le serveur Wazuh, nous devons
activez temporairement l'option logall dans le fichier /var/ossec/ossec.conf:
<ossec_config>
<global>
...
<logall> oui </logall>

...
</global>
</ossec_config>
Une fois que cela est fait, nous devrions déjà voir les tentatives d'authentification échouées sur le commutateur dans
le fichier /var/ossec/logs/archives/archives.log
jpcozar @ wazuh-server: / var / ossec / logs / archives $ tail -f archives.log | grep "10.xx246"
2020 avril 07 15:49:00 wazuh-server-> 10.xx246 7 avril 17:49:00 10.xx246 00419 auth: invalide
↪→ nom d'utilisateur / mot de passe sur la session SSH L'utilisateur 'admin' tente de se connecter à partir de 10.xxx
Mais il n'a généré aucune alerte dans les fichiers d'alerte. (Json | log) ou dans Kibana.
C'est parce qu'il n'y a pas de décodeur ou de règle qui gère cet événement donc
nous devons construire le nôtre.
62
Piste 79
6.6.1. Création de décodeur
Considération importante: lors de la construction du décodeur, tenez compte du fait que

Le fichier logs vu ci-dessus insère un en-tête (en-tête) qui ne fait pas partie
du journal à analyser. Dans ce cas, bien que l'entrée dans le fichier journal soit:
2020 avr 07 15 : 49: 00 wazuh-server-> 10.xx246 avr 7 17 : 49: 00 10 .xx246 00 419 auth: non valide
↪→ nom d'utilisateur / mot de passe sur la session SSH L'utilisateur 'admin' tente de se connecter à partir de 10 .xxx
Il y a une partie d'en-tête insérée par Wazuh qui doit être supprimée pour construire
correctement le décodeur:
2020 avr 07 15 : 49: 00 wazuh-server-> 10.xx246
Et nous resterions avec:
7 avril 17 : 49: 00 10 .xx246 00419 auth: nom d'utilisateur / mot de passe non valide sur la session SSH Utilisateur 'admin'
↪→ essaie de se connecter à partir de 10 .xxx
Tenez également compte lors de la construction du décodeur de l'espace vide au début.
Pour créer le décodeur, nous ouvrons le fichier /var/ossec/etc/decoders/local_decoder.xml

et nous créons le décodeur suivant:
<decoder name = "hp" >
<prematch> \ w + \ s + \ d + \ d + \ d +: \ d + \ d +: \ d + \ d + </prematch>
<regex offset = "after_prematch" > (\ d +. \ d +. \ d +. \ d +) \ d + auth: nom d'utilisateur / mot de passe invalide sur SSH
↪→ L'utilisateur de session '(\ S +)' tente de se connecter depuis (\ d +. \ d +. \ d +. \ d +) </regex>
<order> dstip, utilisateur, srcip </order>
</decoder>
Expressions régulières ( ) utilisé on les voit dans le tableau
Expressions utilisées
\w AZ, az, 0-9, '-' '@'
\ ré 0-9
\s Espace vide
\S Tout caractère sauf \ s
Modificateurs
+ une ou plusieurs occurrences (\ w + ou \ d +)
Tableau 6.1: Expressions régulières dans le décodeur HP
5 Pour une liste complète des expressions régulières, voir
63
Piste 80
Dans la balise <prematch>, nous prenons jusqu'à l'adresse IP de destination, l'horodatage: 7 avril 17:49:00. le
les expressions qui vont entre parenthèses correspondent aux champs que nous voulons extraire.
Dans notre cas, il s'agira de l'adresse IP de destination (dstip), de l'utilisateur qui a tenté de se connecter (utilisateur) et
l'IP source (srcip). On voit la correspondance du décodeur dans le tableau .
Correspondance de journal (prématch)
\w+\s+\d+ 7 avr
\ d + \ d +: \ d + \ d +: \ d + \ d + 17:49:00
Correspondance de journal (regex)
(\ d +. \ d +. \ d +. \ d +) 10.xx246 dstip
\d+ 00419
'(\ S +)' «admin» utilisateur
(\ d +. \ d +. \ d +. \ d +) 10.xxx srcip
Tableau 6.2: Correspondance du décodeur
Une fois que nous avons le décodeur, nous le vérifions avec l'outil / var / ossec / bin / ossec.
logtest, en lui passant l'entrée de journal sans l'en-tête:
** Phase 1 : pré-décodage terminé.

événement complet: '7 avril 17:49:00 10.xx246 00419 auth: nom d'utilisateur / mot de passe invalide
↪→ sur session SSH L'utilisateur ' admin ' tente de se connecter à partir de 10.xxx '
horodatage: '(null)'
nom d'hôte: 'wazuh-server'
nom_programme: '(null)'
log: '7 avril 17:49:00 10.xx246 00419 auth: nom d'utilisateur / mot de passe invalide sur SSH
↪→ session L'utilisateur ' admin ' tente de se connecter à partir de 10.xxx '
** Phase 2 : décodage terminé.
décodeur: 'hp'
dstip: '10 .xx246 '

dstuser: 'admin'
srcip: '10 .xxx '
Comme nous pouvons le voir, il utilise le décodeur que nous avons créé et obtient les champs que nous voulions.
6.6.2. Création de règles: règles atomiques et composites
6.6.2.1. Règle atomique: échecs d'authentification

Une règle atomique est une règle qui ne dépend d'aucune autre. Dans notre cas, nous créerions
une règle pour détecter chaque échec d'authentification sur le commutateur comme des événements
indépendant.
Pour créer cette règle, nous éditons le fichier /var/ossec/etc/rules/local_rules.xml et

Nous avons créé une règle selon laquelle lorsque vous utilisez le décodeur hp, il déclenche une alerte de niveau 5 (selon
64
Piste 81
Le paramètre par défaut de Wazuh, doit être supérieur à 3 pour être enregistré) et avec un identifiant
supérieur à 10 0002 (les règles utilisateur doivent être créées à partir de 100 000).
< nom du groupe = "hp, sshd, syslog" >
<rule id = "100002" level = "5" >
<decoded_as> hp </decoded_as>
<description> sshd: échec de l'authentification HP Switch </description>
<group> authentication_failed </group>
</rule>
</group>
Et maintenant, si nous lançions à nouveau l'outil de test de journaux, un nouveau aurait été ajouté
phase qui est celle qui nous dit qu'elle lancerait une alerte de niveau 5:
** Phase 3 : filtrage terminé ( règles ) .
ID de règle: '100002'
Niveau: '5'
Description: 'sshd: échec de l'authentification HP Switch'
** Alerte à générer.
Une fois que cela est fait, si nous essayons de nous authentifier à tort auprès du commutateur, nous devrions
voir l'alerte à la fois dans les fichiers d'alertes. (json | log)
root @ serveur-wazuh: / var / ossec / logs / alertes # cat alerts.log | grep "Règle: 100002"
Règle: 100002 (niveau 5) -> 'sshd: échec de l'authentification HP Switch'
comme à Kibana, comme on le voit sur la figure .
65
Psaumes 82
Figure 6.10: Échec de la tentative d'authentification sur le commutateur HP
6.6.2.2. Règle composée: 5 échecs d'authentification en 10 minutes
Maintenant, nous voulons cela en plus de générer une alerte pour chaque échec d'authentification, s'ils se produisent
5 tentatives (par exemple du même utilisateur ou de la même IP) en moins de 10 minutes,
Considérons cela comme une attaque par force brute et une alerte est lancée avec une plus grande gravité.
Ce sera un type de règle composée, puisque nous dépendons d'autres règles.
Pour ce faire, nous éditons le fichier /var/ossec/etc/rules/local_rules.xml et créons un

nouvelle règle, au sein du groupe précédent, avec le contenu suivant:
<rule id = "100003" level = "10" frequency = "5" timeframe = "600" >
<if_matched_sid> 100002 </if_matched_sid>
<même_ip_source />
<description> 5 mots de passe échoués dans les 10 minutes HP Switch </description>
<description> de la même adresse IP </description>
<group> authentication_failures </group>
</rule>
66
Piste 83
Comme nous pouvons le voir, pour que cette règle soit exécutée, la règle atomique avec SID doit être remplie
100002 défini ci-dessus, avec une fréquence de 5 fois dans un temps de 600 secondes,
c'est-à-dire à 10 minutes de la même adresse IP (<same_source_ip />).
Nous testons cette règle d'abord avec le testeur, / var / ossec / bin / ossec-logtest, et copions
le journal précédent 5 fois pour voir si la règle composée saute:
** Phase 3 : filtrage terminé ( règles ) .
ID de règle: '100003'
Niveau: '10'
Description: «5 mots de passe ayant échoué dans les 10 minutes HP Switch à partir de la même adresse IP»
** Alerte à générer.
Comme nous pouvons le voir, cela fonctionne correctement et une alerte de niveau 10 est générée. Maintenant, nous la mettons
en pratique, en essayant de vous connecter au commutateur 5 fois à partir de la même adresse IP de manière erronée et
on voit que l'alerte est générée à la fois dans les logs:
root @ serveur-wazuh: / var / ossec / logs # cat alerts / alerts.log | grep "Règle: 100003"
Règle: 100003 (niveau 10) -> '5 mots de passe échoués dans les 10 minutes HP Switch à partir de la même IP'
comme à Kibana (voir figure ).
Figure 6.11: Alerte de règle composite: 5 tentatives d'accès ssh en 10 minutes Commutateur HP
67
Psaumes 84
6.7. Réponse active

La réponse active est que, lorsqu'un événement est détecté, nous agissons en conséquence,
ne soyons pas de simples spectateurs.
Pour cela, nous allons supposer que, dans l'un des serveurs Linux, nous voulons bloquer une IP qui
essaie à plusieurs reprises de se connecter à notre serveur par SSH pendant un temps que nous
établissons. Nous effectuerions les étapes suivantes.
6.7.1. Détection d'attaque
Dans ce cas, nous n'avons pas besoin de définir de nouvelles règles (comme nous l'avons fait pour le commutateur dans le
séparé ) puisque Wazuh est livré avec des règles par défaut pour détecter les attaques ssh. Spécifique
dans le chemin / var / ossec / ruleset / rules, nous avons le fichier 095-sshd_rules.xml. Dans le,
nous avons deux règles qui nous intéressent. La règle avec l'ID 5710, qui détecte la tentative de connexion
échoué par ssh car l'utilisateur n'existe pas:
<rule id = "5710" level = "5" >
<if_sid> 5700 </if_sid>

<match> utilisateur illégal | utilisateur non valide </match>
<description> sshd: tentative de connexion avec un utilisateur inexistant </description>

<group> invalid_login, authentication_failed, pci_dss_10.2.4, pci_dss_10.2.5, pci_dss_10.6.1,
gpg13_7.1, gdpr_IV_35.7.d, gdpr_IV_32.2, hipaa_164.312.b, nist_800_53_AU.14, nist_800_53_AC.7,
nist_800_53_AU.6, </group>
</rule>
Et la règle composée avec l'ID 5712, qui est lancée si vous avez ignoré la règle 5710 8 fois, dans un
durée de 2 minutes et sera ignorée pendant 1 minute.
<rule id = "5712" level = "10" frequency = "8" timeframe = "120" ignore = "60" >
<if_matched_sid> 5710 </if_matched_sid>

<description> sshd: force brute essayant d'accéder à </description>
<description> le système. </description>

<même_ip_source />
<group> échecs_authentification, pci_dss_11.4, pci_dss_10.2.4, pci_dss_10.2.5, gdpr_IV_35.7.d,

gdpr_IV_32.2, hipaa_164.312.b, nist_800_53_SI.4, nist_800_53_AU.14, nist_800_53_AC.7, </group>
</rule>
Une fois l'attaque détectée, la commande à exécuter doit être définie.
6.7.2. Définition de la commande
Wazuh est livré avec un certain nombre de scripts prédéfinis à utiliser dans les réponses actives du
répertoire / var / ossec / active-response / bin.
Nous utiliserons le script firewall-drop.sh qui permet de bloquer une adresse IP malveillante par
iptables. Une fois que nous avons le script, nous vérifions que la commande est définie dans le fichier
/var/ossec/etc/ossec.conf:
68
Piste 85
6.7. Réponse active
<commande>
<name> pare-feu </name>
<executable> firewall-drop.sh </executable>

<expect> srcip </expect>
<timeout_allowed> oui </timeout_allowed>
</command>
6.7.3. Définir la réponse active

Nous définissons maintenant la réponse active dans le même fichier ossec.conf sur le serveur Wazuh.
Les principaux éléments à inclure sont:
command: la commande firewall-drop précédemment définie
location: où la commande sera exécutée. Comme ce sera le cas dans l'agent signalant l'événement, il sera
local.
rules_id: la commande sera exécutée lorsque la règle avec l'ID 5712 sera exécutée.
timeout: nous bloquerons l'IP pendant 300 secondes (5 minutes).
Par conséquent, la réponse active sera comme ceci:
<réponse-active>
<command> firewall-drop </command>
<location> local </location>
<rules_id> 5712 </rules_id>
<timeout> 300 </timeout>
</active-response>
Maintenant, si nous essayons de nous connecter à partir de la même IP et échouons 8 fois en moins de 2
minutes, cela nous bloquera 5.
Dans le serveur Wazuh, nous pouvons voir l'alerte générée:
root @ serveur-wazuh: / var / ossec / logs # cat alerts / alerts.log | grep "Règle: 5712"
Règle: 5712 (niveau 10) -> 'sshd: force brute essayant d'accéder au système.'
6.7.4. Générer une alerte lorsqu'une réponse active est déclenchée

Dans l'agent qui a exécuté la réponse active, nous pouvons le voir enregistré dans le fichier / var / log
ossec / logs / active-answers.log.
Ven 10 avril 12:47:46 CEST 2020 /var/ossec/active-response/bin/firewall-drop.sh add - 10 .xxx
↪→ 1586515666 .494549866 5712
Ven 10 avril 12:52:47 CEST 2020 /var/ossec/active-response/bin/firewall-drop.sh delete - 10 .xxx
↪→ 1586515666 .494549866 5712
Comme on peut le voir, la règle de blocage a été créée et au bout de 5 minutes, la règle de déblocage.
69
Psaumes 86
Cependant, le gestionnaire Wazuh ne sait pas si une réponse a été déclenchée ou non.
actif sur les agents. Pour ce faire, nous devons configurer le serveur Wazuh pour lire le
fichier /var/ossec/logs/active-responses.log de chacun des agents. Pour ne pas
devoir passer agent par agent en modifiant la configuration, nous utiliserons à nouveau la configuration
vue centralisée en coupe .
Dans ce cas, comme nous voulons qu'il s'applique au groupe de serveurs Linux, nous éditerons le
file /var/ossec/etc/shared/LinuxServers/agent.conf et ajoutez ce qui suit:
<localfile>
<log_format> syslog </log_format>
<location> /var/ossec/logs/active-responses.log </location>
</localfile>
Nous redémarrons le gestionnaire et les agents Wazuh:
Maintenant, si on refait la même opération, en plus, on peut la voir à la fois dans le fichier
Alertes Wazuh (sachant que la règle qui sautera sera l'ossec de la réponse active, le
601) comme à Kibana (figure ).
root @ serveur-wazuh: / var / ossec / logs / alertes # cat alerts.log | grep "Règle: 601"
Règle: 601 (niveau 3) -> 'Hôte bloqué par la réponse active de firewall-drop.sh'
Figure 6.12: Blocage IP avec réponse active
70
Psaumes 87
6.8. Bastion de serveurs

L'un des meilleurs moyens de sécuriser les serveurs consiste à réduire la zone de vulnérabilité
bilité. Ceci est accompli en évaluant vos paramètres de sécurité. Ce
processus est appelé bastioning ou durcissement. Wazuh a 3 façons de le faire:
module développé par l'équipe Wazuh pour surmonter les limitations de l'autre
dos et a remplacé rootcheck, qui reposait sur le service syscheck dont
les flux sur les politiques de sécurité étaient très souvent obsolètes. Disponible
pour les ordinateurs Windows et Linux.
OpenSCAP n'est disponible que pour les machines Linux, pas Windows.
CIS-CAT est un outil propriétaire qui dépend d'une licence externe pour son utilisation.
Dans notre cas, nous utiliserons SCA, car il est inclus avec Wazuh, est open source et couvre les deux
Ordinateurs Windows tels que Linux.
6.8.1. Surveillance des politiques de sécurité avec SCA

Chaque agent a sa base de données locale dans laquelle il stocke l'état actuel de chaque contrôle:
réussi, échoué ou non applicable. De cette façon,
Les agents envoient uniquement les différences entre les analyses. Les politiques sont dans les agents
dans:
• Linux: / var / ossec / ruleset / sca

• Windows: C: \ Program Files (x86) \ ossec-agent \ ruleset \ sca
6.8.1.1. SCA sur les serveurs Windows
Par défaut, l'agent Windows installe uniquement la stratégie sca_win_audit qui audite les systèmes
Windows en général mais pas spécifiquement les serveurs Windows 2012 R2 comme le nôtre
Cas. Pour ce faire, nous téléchargeons les politiques pour les serveurs Windows 2012 R2, basé sur
le rôle qu'ils ont (contrôleurs de domaine ou serveurs membres) et selon un niveau
Profil L1 ou L2 (prolongeant le précédent). Nous pouvons trouver plus d'informations dans
.
• cis_win2012r2_domainL1: benchmark CIS pour le contrôleur de domaine Windows 2012 R2 L1
• cis_win2012r2_domainL2: benchmark CIS pour le contrôleur de domaine Windows 2012 R2 L2
• cis_win2012r2_memberL1: benchmark CIS pour Windows 2012 R2 Member Server L1
• cis_win2012r2_memberL2: benchmark CIS pour Windows 2012 R2 Member Server L2
root @ serveur wazuh: # cd / var / ossec / etc / shared /; mkdir sca-politiques
root @ serveur-wazuh: / var / ossec / etc / shared / sca-policies # wget https://raw.githubusercontent.com/ l
↪→ wazuh / wazuh / master / etc / sca / windows / cis_win2012r2_domainL1.yml
...
root @ serveur-wazuh: / var / ossec / etc / shared / sca-policies # chown -R ossec.ossec
↪→ / var / ossec / etc / shared / sca-policies
71
Psaumes 88
Une fois que l'utilisateur ossec a été téléchargé et établi en tant que propriétaire, nous pouvons le distribuer
aux serveurs avec la configuration centralisée, comme nous l'avons vu dans la section . Mais avant,
nous devons créer deux nouveaux groupes au sein des serveurs Windows, en distinguant si
ce sont des contrôleurs de domaine ou des serveurs membres. Nous n'appliquerons pas ces politiques ou
Serveur Windows 2008 ou serveur autonome.
Les nouveaux groupes seront:
2012DomainControllerServers contient HACOSV01 et HACOSV02
2012DomainMemberServers contient HACONF11, HACONF12, HACOSV03 et HACOSV04.
Nous pouvons maintenant ajouter au fichier de configuration agent.conf de chaque groupe, les politiques
correspondant. Par exemple, pour les serveurs membres du domaine, nous éditons le fichier
ro /var/ossec/etc/shared/2012DomainMemberServers/agent.conf et laissez-le être
trouver le chemin relatif où ils seront copiés dans les agents. Ce sera dans C: \ Program Files (x86)
\ ossec-agent \ shared comme il les recherche à l'origine dans C: \ Program Files (x86)
\ ossec-agent \ ensemble de règles \ sca.
<config_agent>
<sca>
<politiques>
<policy> /../../shared/sca-policies/cis_win2012r2_memberL1.yml </policy>

<policy> /../..//shared/sca-policies/cis_win2012r2_memberL2.yml </policy>
</policies>
</sca>
</agent_config>
Et pour les contrôleurs de domaine, le fichier à éditer est / var / ossec / etc / shared /
2012DomainMemberServers / agent.conf et le contenu:
<config_agent>
<sca>
<politiques>
<policy> /../../shared/sca-policies/cis_win2012r2_domainL1.yml </policy>
<policy> /../..//shared/sca-policies/cis_win2012r2_domainL2.yml </policy>
</policies>
</sca>
</agent_config>
Et nous copions les politiques dans les répertoires de chaque groupe:
root @ serveur-wazuh: / var / osssec / etc / shared # cp ./sca-policies/*member* ./2012DomainMemberServers
root @ serveur-wazuh: / var / osssec / etc / shared # cp ./sca-policies/*domain*
↪→ ./2012DomainControllerServers
Ces configurations seront mélangées avec celles existantes dans le bloc sca de chaque agent
et ils seront ajoutés à l'ancienne configuration. Après peu de temps, nous aurons évalué
ces politiques, qui apparaîtront dans Kibana dans un nouvel onglet appelé SCA dans
tro de chacun des agents dans la section: Audit et surveillance des politiques →
Évaluation de la configuration de la sécurité.
72
Psaumes 89
Comme on le voit sur la figure nous montre les trois politiques SCA auxquelles vous appliquez
serveur. Celui par défaut et les deux nouveaux que nous avons ajoutés.
Figure 6.13: Stratégies SCA du serveur membre de Windows 2012 R2
Si on clique sur chaque politique, on voit en détail le résultat de chaque test: échoué, réussi
ou sans objet. Nous voyons cela dans la figure .
6.8.1.2. SCA sur les serveurs Linux
Dans le cas des serveurs Linux, il n'est pas nécessaire de faire des étapes supplémentaires car les politiques
qui viennent par défaut pour Debian, sont compatibles avec Ubuntu. Dans le cas des serveurs
Les politiques Ubuntu 16.x ont été appliquées:
• Benchmark CIS pour Debian / Linux 9 L1
Et dans le cas du seul Ubuntu 14.x, les politiques:
Un exemple de chacun peut être vu dans les images et respectivement.
73
Piste 90
Figure 6.14: SCA - Test de référence CIS W2012R2 Member Server L1
Figure 6.15: SCA - Benchmark CIS Debian 9 L1
74
Piste 91
6.9. Notifications d'alerte et rapports
Figure 6.16: SCA - Benchmark CIS Debian 8 L1

Chaque système de surveillance doit être capable de faire un certain type de notification afin que
les administrateurs savent qu’une alerte a été déclenchée ou qu’une
rapport général d’eux. Dans le cas de Wazuh, nous pouvons configurer à la fois un rapport quotidien de
des alertes comme des e-mails spécifiques lorsqu'une alerte est déclenchée en fonction de votre niveau, de votre identifiant, de votre appartenance
à un groupe d'agents, etc. . .
Wazuh n'autorise pas l'utilisation de serveurs de messagerie avec authentification donc c'est nécessaire
utilisez un serveur relais. Puisque nous avions déjà résolu ce problème dans notre organisation,
Nous avons un serveur qui agit comme un relais de messagerie, hacolx05, ce qui
nous utiliserons pour l'envoi de notifications.
6.9.1. Notification d'alerte

Nous activons les alertes dans le fichier /var/ossec/etc/ossec.conf:
<ossec_config>
<globlal>
...
<email_notification> oui </email_notification>
<smtp_server> hacolx05 </smtp_server>
<email_from> user_envio@organizacion.es </email_from>
<email_to> user_reception@organizacion.es </email_to>
75
Psaumes 92
<email_maxperhour> 12 </email_maxperhour>
<email_log_source> alerts.log </email_log_source>
</global>
...
</ossec_config>
Et puis nous définissons le niveau d'alertes à partir duquel nous voulons que les messages nous soient envoyés
dans le même fichier. Par exemple, comment voulons-nous que des alertes pour les tentatives nous soient envoyées?
attaque par force brute par ssh que nous avons faite dans la section qui avait un niveau 10, quoi
on part comme ça:
<alertes>
<email_alert_level> 10 </email_alert_level>
</alerts>
Avec la configuration ci-dessus, tous les niveaux d'alertes ≥ 10 atteindraient l'utilisateur indiqué.
Wazuh permet une plus grande granularité et nous pourrions faire des alertes pour un certain
le serveur atteindra un e-mail spécifique. Par exemple, nous effectuons l'attaque ssh sur le serveur
hacolx07 et nous voulons qu'il atteigne l'utilisateur user_reception. Dans le même fichier
nous serions:
<email_alerts>
<event_location> hacosv07 </event_location>

<do_not_delay />
</email_alerts>
Nous essayons de faire l'attaque ssh et nous recevrions le courrier que nous voyons dans la figure
6.9.2. Envoi de rapports quotidiens

Nous pouvons envoyer un rapport quotidien avec un résumé des alertes qui ont été lancées chaque jour
et personnalisez-le selon nos besoins. Nous éditons le fichier / var / ossec / etc / ossec.
conf et configurez la section des rapports comme ceci:
<ossec_config>
<rapports>
<level> 10 </level>
<title> Rapport quotidien: alertes de niveau supérieur à 10 </title>
<email_to> report@correo-organizacion.es </email_to>
</reports>
</ossec_config>
Cette configuration enverrait un rapport quotidien des alertes générées avec un niveau ≥ 10,
comme on le voit sur la figure .
76
Piste 93
Figure 6.17: Alerte d'attaque par force brute par e-mail ssh
77
Épisode 94
Figure 6.18: Rapport quotidien d'alertes Wazuh de niveau 10 ou plus
78
Psaumes 95
6.10. Intégration avec des API externes: Slack
6.10. Intégration avec des API externes: Slack

Wazuh nous permet également de nous connecter à des API externes et à des outils d'alerte tels que ,
ou (vu dans la section ). Dans notre organisation, nous utilisons Slack
en tant qu'outil collaboratif de la DSI, nous allons donc intégrer
Wazuh avec elle, créant une nouvelle chaîne dans notre espace de travail Slack appelée
#wazuh et recevoir les alertes qu'il génère là-bas.
La connexion se fera grâce à la technologie . Nous devons en créer un,

qui nous donnera une URL unique (appelée hook_url) où nous enverrons un avec le message
texte et quelques options supplémentaires. Une fois que nous avons le hook_url, dans le fichier
/var/ossec/etc/ossec.conf nous configurons une nouvelle intégration, en ajoutant les filtres
correspondant: id_règle, niveau, groupe, emplacement_événement. Dans notre cas, nous filtrerons
pour les alertes de niveau ≥ 12:
<intégration>
<name> mou </name>
<hook_url> https://hooks.slack.com/services/"hook_url_individual " </hook_url> l
↪→
<level> 12 </level>
Une fois l'intégration configurée, nous redémarrons le gestionnaire Wazuh:
Et après peu de temps, la chaîne #wazuh de notre espace de travail nous parviendra
notifications avec le niveau d'alerte indiqué, comme on peut le voir sur la figure .
Figure 6.19: Notification d'alertes Wazuh dans Slack
6 Plus d'informations sur
79
Psaumes
Épisode 97
96
C ONCLUSIONS ET
sept
AMÉLIORATIONS
7.1. Conclusions
Les objectifs proposés suivants ont été atteints:
✓ Il a été possible de suivre le planning établi.
✓ La meilleure méthode d'implantation de Wazuh a été étudiée et déterminée dans notre

organisation.
✓ Les serveurs Wazuh et ELK Stack ont été installés avec une architecture distribuée.
✓ Les serveurs Wazuh et ELK Stack ont été sécurisés (y compris l'authentification dans le
accès au portail Web Kibana) et les communications entre eux à l'aide de la technologie
X-Pack pour la partie ELK.
✓ Les serveurs Wazuh et Elastic ont été intégrés dans l'outil de surveillance Nagios
tion de notre organisation.
✓ Les agents Wazuh ont été automatiquement déployés sur les deux serveurs Windows
(via des stratégies de groupe) comme Linux (via Ansible).
✓ La configuration centralisée proposée par Wazuh a été utilisée pour distribuer les options
Spécifiez les agents automatiquement au lieu de passer un par un manuellement.
✓ Les fichiers jugés critiques ont été surveillés, nous alertant de leur altération dans le temps
réel lorsque cela est possible. L'audit desdites modifications a également été réalisé,
Psaumes 98
CHAPITRE 7. CONCLUSIONS ET AMÉLIORATIONS
nous permettant de savoir qui, comment, quand et de quelle manière la modification a été effectuée
(who-data), à la fois sous Windows et Linux.
✓ Les appareils qui ne permettent pas l'installation d'agents spécifiques ont été surveillés
(sans agent) (commutateurs HP) en utilisant le serveur syslog Wazuh et en créant des décodeurs
et des règles spécifiques.
✓ L'outil VirusTotal a été intégré à Wazuh pour une analyse en temps réel des
certains répertoires.
✓ Il a été possible de détecter des vulnérabilités à la fois dans les systèmes Windows (en utilisant la base de données
Données NVD) comme sous Linux (en utilisant les OVALs fournis par Canonical).
✓ Des mécanismes de réponse active ont été définis pour répondre à certaines situations
(attaque ssh).
✓ La technologie SCA a été utilisée pour l'analyse des politiques de sécurité,

Serveurs Windows comme Linux.
✓ Les systèmes de notification ont été configurés à la fois par e-mail et avec
outils externes (Slack).
De plus, ce projet nous a aidés à:
• Implémenter dans notre organisation un logiciel libre SIEM qui lui manquait et voir
les énormes possibilités qu'il offre.
• Trouvez un système polyvalent, extensible et / ou adaptable à nos besoins grâce à

l'activation / la désactivation des différents modules dont il dispose, la création de
règles et décodeurs spécifiques, tableaux de bord personnalisés, etc ...
• Voir les possibilités d’intégration avec des outils et API externes (VirusTotal et
Slack, respectivement et dans notre cas) qui augmentent sa valeur en tant que SIEM.
• Apprécier les outils d'automatisation et de configuration à leur juste valeur

centralisé, ce qui nous aide à déployer rapidement et efficacement.
• Contribuez audit projet en rapportant les bugs trouvés.
• Installer un outil qui nous aide à nous conformer à l'ENS.
7.2. Surclassements
• L'installation par défaut de Wazuh génère de nombreuses alertes et informations de surveillance.
(par exemple, chaque connexion réussie sur un système Windows) qui est nécessaire
que nous déboguons pour séparer ce qui est vraiment important et ne pas surcharger le système comme ça
comment éliminer les faux positifs.
• Après une courte période de production du système (environ 1 mois),

l'espace occupé par les données Elasticsearch dans / var / data / elasticsearch, a
beaucoup grandi, nous avons donc dû migrer les données vers une nouvelle unité
virtual / mnt / es_data / lib / elasticsearch pour le garder indépendant du ser-
vidor et surveillé par Nagios. Nous avons également dû configurer la rotation et
suppression des index via Kibana. Plus de planification et d'étude sont nécessaires
exhaustif de ce sujet pour éviter les goulots d'étranglement.
82
Psaumes 99
7.2. Surclassements
• Il existe des fonctionnalités Wazuh supplémentaires (par exemple ) ça pourrait être nous
utile dans notre environnement et que nous mettrons en œuvre dans le futur.
• Il sera nécessaire de personnaliser Kibana en générant vos propres tableaux de bord pour notre organisation.
qui nous avertissent des alertes que nous avons définies (par exemple les attaques par ssh
aux serveurs Linux, ou tente de se connecter aux commutateurs, etc. . . ).
• Le cas d'utilisation du commutateur HP doit être appliqué (section ) au reste des commutateurs du
organisation et créer des règles supplémentaires ou des décodeurs si nécessaire.
• Etudier la possibilité d'utiliser Wazuh pour surveiller les appareils dans lesquels
nous partageons la gestion (pare-feu et cabine de stockage), accord préalable avec le
reste des administrateurs.
• Créer un manuel ou un guide d'utilisation de l'environnement Web installé (plugin Kibana + Wazuh)
pour les opérateurs et mettre en place des tableaux de bord préparés spécialement pour eux.
83
Piste 100101
Épisode
B IBLIOGRAPHIE
Livres
Bray, R., Cid, D. et Hay, A. (9 avril 2008). Guide de détection d'intrusion basée sur l'hôte OSSEC
(Édition: Pap / Cdr). Syngress. (Vid. P. ) .
Chhajed, S. (2015, 26 novembre). Apprentissage de la pile ELK: créez des visualisations fascinantes,
des analyses et des journaux de vos données à l'aide d'Elasticsearch, Logstash et Kibana. Packt
Édition.
Gormley, C. et Tong, Z. (7 février 2015). Elasticsearch: The Definitive Guide (Edition: 1).
O'Reilly Media.
Kruegel, C., Valeur, F. et Vigna, G. (2005). Détection et corrélation d'intrusions: défis
et des solutions. Springer US.
Lhotsky, B. (2013, 1er janvier). Système de détection d'intrusion basé sur l'hôte OSSEC instantané [Google-
Livres-ID: X80hLF8zL4EC]. Packt Publishing Ltd.
Miell, I. et Sayers, AH (28 février 2019). Docker in Practice, deuxième édition (édition:
2e). Manning.
Miller, DR, Harris, S., Harper, A., VanDyke, S. et Blask, C. (5 novembre 2010). Sécurité
Information et gestion des événements (Édition: 1). Éducation McGraw-Hill.
Northcutt, S. et Novak, J. (6 septembre 2002). Détection d'intrusion réseau (3 édition).
Publication de Sams.
Paro, A. (30 avril 2019). Elasticsearch 7.0 Cookbook: plus de 100 recettes pour une
et une recherche fiable pour votre entreprise, 4e édition. Publication de Packt.
Shukla, P. et N, SKM (31 mai 2019). Learning Elastic Stack 7.0: recherche distribuée,
analyse et visualisation à l'aide d'Elasticsearch, Logstash, Beats et Kibana, 2e
Édition (Édition: 2). Publication de Packt.
Épisode 102
BIBLIOGRAPHIE
Des articles
Mokalled, H., Catelli, R., Casola, V., Debertol, D., Meda, E. et Zunino, R. (2019). le
Applicabilité d'une solution SIEM: exigences et évaluation. 28e IEEE 2019
Conférence internationale sur les technologies habilitantes: infrastructure pour la collaboration
Entreprises (WETICE), Technologies habilitantes: infrastructure pour l’en-
terprises (WETICE), 28e Conférence internationale de l'IEEE 2019 sur, WETICE, 132-137.
(vidéo p. )
Podzins, O. et Romanovs, A. (2019). Pourquoi SIEM est irremplaçable dans un environnement informatique sécurisé?
Conférence ouverte 2019 des sciences électriques, électroniques et de l'information (eStream),
Sciences électriques, électroniques et de l'information (eStream), Conférence ouverte 2019 de,
1-5. (vidéo p. )
Ressources Web
A2Secure. (2019, 12 février). Systèmes IDS, IPS, HIDS, NIPS, SIEM De quoi s'agit-il? [A2Secure]
[Catalogue de la bibliothèque: www.a2secure.com Section: Blog]. Récupéré le 3 mars
2020, à partir de
Casetto, O. (7 février 2019). Une introduction à la sécurité SIEM: évolution et capacités de nouvelle génération
[Exabeam] [Catalogue de la bibliothèque: www.exabeam.com Section: SIEM]. Consulté le 28
Février 2020, à partir de
. (Vid. P.)
OSSEC. (2020). Documentation OSSEC HIDS. Récupéré le 25 février 2020 de
. (Vid. P.)
Chapeau rouge. (2020). Documentation Ansible. Récupéré le 25 février 2020 de
. (Vid. P. )
Verizon. (2019, mai). Rapport d'enquête sur les violations de données 2019 [Verizon Enterprise Solutions]
[Catalogue de la bibliothèque: enterprise.verizon.com]. Récupéré le 25 février 2020 de
. (Vid. P.)
Wazuh. (2020). Documentation Wazuh. Récupéré le 25 février 2020 de
. (Vid. Pp. ,, )
86
Épisode 103
Annexes
Épisode 105
104
H YPER -V
À
A.1. Création de commutateur virtuel dans Hyper-V
Dans par défaut lors de la création d'une nouvelle machine virtuelle, la connexion réseau est utilisée
Ethernet appelé commutateur par défaut qui est de type , ce qui rend le serveur Wazuh
non accessible par les agents. Par conséquent, avant de créer la machine virtuelle, nous devons
créez un nouveau commutateur virtuel s'il n'est pas déjà créé. Dans notre organisation sur serveurs
en production, il existe déjà, mais pas en tests dans notre équipe. Pour ce faire, nous réalisons le
Prochaines étapes:
1. Nous ouvrons le gestionnaire Hyper-V

2. Gestionnaire de commutateur virtuel
3. Type de connexion: externe
4. Nom: vSwitch externe
5. À quoi souhaitez-vous connecter ce commutateur virtuel?
• Réseau externe: contrôleur de la famille Realtek PCIe GBe
6. Vérifiez: Autoriser le système d'exploitation de gestion à partager
cette carte réseau
Il doit rester comme indiqué sur la figure
Une fois créé, nous changerons l'adaptateur réseau dans la machine virtuelle Default Switch
à External vSwitch et vous devriez déjà nous donner une adresse IP de la plage du siège, pas une adresse privée.
1 Traduction d'adresses réseau - Traduction d'adresses réseau
Épisode 106
ANNEXE A. HYPER-V
Figure A.1: Création d'un commutateur virtuel dans Hyper-V
A.2. Créer des machines virtuelles
A.2.1. Serveur Wazuh en test
1. Nous ouvrons le gestionnaire Hyper-V de notre équipe
2. Nous créons une machine virtuelle avec les caractéristiques suivantes:
• Nom: wazuh-server-tests
• Emplacement: D: \ Wazuh-tests
• Génération: 1
• Processeurs: 1 processeur virtuel
• Mémoire RAM: 2 Go
• Vérifier: utiliser la mémoire dynamique pour cette machine virtuelle
• Connexion: vSwitch externe (créé dans la section ).
• Créez un disque dur virtuel: Wazuh-server-tests.vhdx - 40 Go
• Installer un système d'exploitation à partir d'un CD / DVD ROM amorçable - Fichier
Image ISO: ubuntu-18.04.4-live-server-amd64.iso
• Nous démarrons la machine virtuelle et elle devrait commencer à installer l'ISO Ubuntu Server
• Suivez les étapes indiquées en annexe
A-2
Épisode 107
A.2. Créer des machines virtuelles
A.2.2. Serveur Wazuh en production
1. Nous ouvrons le gestionnaire Hyper-V du serveur
• Nom: Wazuh Server
• Emplacement: C: \ ClusterStorage \ Volume2
• Génération: 1
• Processeurs: 4 processeurs virtuels
• Connexion: vSwitch1
• Créez un disque dur virtuel: Wazuh-server.vhdx - 40 Go
• Installez un système d'exploitation à partir d'un CD / DVD ROM amorçable. Dossier de
A.2.3. Serveur ELK Stack en test

• Nom: ELk-stack-tests
• Emplacement: D: \ Wazuh-Elk-Tests
• Génération: 1
• Processeurs: 1 processeur virtuel
• Connexion: commutateur externe (créé dans la section ).
• Créez un disque virtuel: ELK-stack-tests.vhdx - 40 Go
A.2.4. Serveur ELK Stack en production

• Nom: ELk Server

• Emplacement: C: \ ClusterStorage \ Volume2
• Génération: 1
• Processeurs: 4 processeurs virtuels
• Connexion: vSwitch1
• Créez un disque virtuel: ELK-server.vhdx - 40 Go
A-3
Épisode 108
ANNEXE A. HYPER-V

A.3. Cluster de basculement - Haute disponibilité

Pour configurer la haute disponibilité et avoir des machines virtuelles en production (
Serveur Wazuh avec la pile ELK) se déplacer d'un nœud physique à un autre au cas où il y aurait
tout problème (plantage, arrêt, redémarrage programmé, etc.), nous devons les ajouter
à l'administrateur du cluster de basculement Windows 2012 R2.
Une fois les machines créées, nous allons à l'administrateur du cluster de basculement
erreur et nous indiquons que nous voulons créer un nouveau rôle. L'assistant de la figure apparaît
, où nous indiquons que nous voulons configurer la haute disponibilité pour une machine
virtuel.
Figure A.2: Sélectionnez le rôle pour configurer la haute disponibilité
Ensuite, nous sélectionnons les deux machines que nous voulons avoir une haute disponibilité,
comme on le voit sur la figure
Enfin, nous vérifions que deux nouveaux rôles ont été ajoutés dans l'administrateur du cluster
basculement, un pour chaque machine virtuelle comme nous le voyons dans la figure .
Maintenant, en cas de plantage du nœud propriétaire des machines virtuelles,

ces machines seront transférées vers l'autre nœud.
A-4
Épisode 109
A.3. Cluster de basculement - Haute disponibilité
Figure A.3: Machines à haute disponibilité
Figure A.4: Rôles créés pour la haute disponibilité
TO 5
Épisode 110
U BUNTU S ERVER
B
18.04.4 LTS
B.1. Installation d'Ubuntu Server 18.04.4 LTS sur Hyper-V

Les étapes pour installer Ubuntu Serve 18.04.4 LTS sont:
• Nous téléchargeons la dernière version stable d'Ubuntu Server: ubuntu-18.04.4-live-server-

amd64.iso
• Nous créons la machine virtuelle dans Hyper-V comme indiqué en annexe
• Nous démarrons la machine virtuelle et le programme d'installation d'Ubuntu Server nous ignore
• Langue espagnole
• Mise en page: espagnol
• Variante: espagnol
• Connexion réseau: eth0
◦ Sous-réseau: 10.xx0 / 23
◦ Adresse: en fonction de la machine virtuelle que nous installons, ce sera:
◦ Tests de pile d'élans: 10.xxx
◦ Tests du serveur Wazuh: 10.xxx
◦ Production ELK Stack: 10.xx40
◦ Production du serveur Wazuh: 10.xx57
◦ Passerelle: 10.xxx
◦ Serveurs de noms: 10.xxx, 10.xxx
◦ Domaines de recherche: <domaine>
• Adresse proxy: http://10.xxx:3128
Épisode 111
ANNEXE B. SERVEUR UBUNTU 18.04.4 LTS
• Adresse miroir: http://archive.ubuntu.com/ubuntu

• Mise à jour du programme d'installation disponible: continuez sans mettre à jour
• Configuration du système de fichiers: utilisez un disque entier
• Nous sélectionnons le disque local
• On laisse les partitions créées par défaut
• Votre nom: Javier Polo Cózar
• Le nom de votre serveur: en fonction de la machine virtuelle que nous installons, ce sera:
◦ tests-serveur-wazuh
◦ tests wazuh-elk
◦ serveur wazuh
◦ wazuh-élan
• choisissez un nom d’utilisateur: jpcozar
• Mot de passe et confirmation
• Vérifier: installer le serveur Open SSH
• Importer l'identité SSH: Non
• Ne marquez aucun snap
Une fois installés, nous mettons à jour les packages
jpcozar @ wazuh-elk-tests: ~ $ sudo apt-get mise à jour
jpcozar @ wazuh-elk-tests: ~ $ sudo apt-get upgrade
B.2. Configurer Ubuntu 18.04.4 LTS
B.2.1. Désactiver cloud-init

cloud-init est un service cloud dont nous n'avons pas besoin et qui ralentit également le démarrage du système
que nous le désactivons.
jpcozar @ wazuh-elk-tests: ~ $ sudo touch /etc/cloud/cloud-init.disabled
B.2.2. Paramètres réseau

Si nous devions changer la configuration du réseau (IP statique, DNS, passerelle) dans Ubuntu
18.x se trouve dans le fichier /etc/netplan/50-cloud-init.yaml.
Pour les tests wazuh-elk, ce serait:
réseau:
ethernets:
eth0:
adresses:
- 10.xxx/23
passerelle4: 10.xxx
serveurs de noms:
adresses:
- 10.xxx
- 10.xxx
B-2
Épisode 112
chercher:
- <domaine>
version 2
Pour appliquer la configuration réseau si nous modifions le fichier précédent, ce serait:
jpcozar @ wazuh-elk-tests: ~ $ sudo netplan apply
B.2.3. Configuration FQDN - DNS
Pour les machines en production, il faut qu'outre l'IP, elles aient configuré
correctement votre nom de domaine. Cela sera nécessaire pour la création de certificats,
résolution de noms directe et inversée, etc. . . . Pour ce faire, nous faisons le suivant:
• Nous ouvrons le gestionnaire DNS

• Nous ouvrons le serveur DNS
• Nous ouvrons les zones de recherche directe
• Nous ouvrons notre domaine <domaine>
• Nous créons un nouvel hôte en appuyant sur le bouton droit: Nouvel hôte (A ou AAAA)
• Nous saisissons les données pour le serveur Wazuh (comme nous le voyons dans la figure )
• Nous saisissons les données pour le serveur ELK (comme nous le voyons dans la figure )
• Nous vérifions à la fois dans la zone de recherche directe et dans la zone de recherche
inverse que les enregistrements ont été créés (par exemple, dans la figure on voit le disque
créé dans la zone de recherche inversée pour le serveur Wazuh).
• Nous vérifions que nous résolvons les équipes à la fois directement et à l'envers. Pour
exemple, pour le serveur wazuh-elk:
PS C: \ Users \ administrator. <NETBIOS>> nslookup wazuh-elk
Serveur: hacosv01. <domaine>

Adresse: 10.xxx
Nom: wazuh-elk. <domaine>

Adresse: 10.xx40
PS C: \ Users \ administrator. <NETBIOS>> nslookup 10.xx40
Serveur: hacosv01. <domaine>

Adresse: 10.xxx
Nom: wazuh-elk. <domaine>

Adresse: 10.xx40
Nous aurions déjà les machines virtuelles prêtes à commencer l'installation de SIEM.
B-3
Épisode 113
ANNEXE B. SERVEUR UBUNTU 18.04.4 LTS
Figure B.1: Ajouter une entrée dans le DNS du serveur Wazuh
Figure B.2: Ajouter une entrée dans le DNS du serveur ELK
Figure B.3: Enregistrement de la zone de recherche inversée Wazuh
B-4
Psaumes 114
B.2.4. Changer de fuseau horaire

Par défaut, le fuseau horaire est UTC (-2h) et le fait est qu'il est dans le nôtre (CEST). Pour
changez-le, nous faisons:
jpcozar @ wazuh-server: ~ $ sudo timedatectl set-timezone Europe / Madrid
jpcozar @ wazuh-server: ~ $ timedatectl
Heure locale: Ven 2020-04-03 18:44:08 CEST
Temps universel: Ven 2020-04-03 16:44:08 UTC

Heure RTC: Ven 2020-04-03 18:44:07
Fuseau horaire: Europe / Madrid (CEST, +0200)
Horloge système synchronisée: non

systemd-timesyncd.service actif: oui
RTC dans la TZ locale: non
B-5
Épisode 115
I NSTALLATION DE
C
W AZUH S ERVER
C.1. Installation à partir de référentiels

Tout d'abord, nous devons ajouter le référentiel Wazuh
C.1.1. Ajouter le référentiel Wazuh

Il y a une série d'exigences que nous devons avoir installé dans le système avant d'installer
Wazuh. Comme ces commandes doivent être exécutées en tant qu'utilisateur administrateur (root),
ou nous changeons pour ledit utilisateur ou nous exécutons sudo avant chacun. Dans notre cas, nous
nous devenons administrateur et installons les packages auxiliaires:
jpcozar @ wazuh-server-tests: ~ $ sudo su -
root @ wazuh-server-tests: ~ # apt-get update
root @ wazuh-server-tests: ~ # apt-get install curl apt-transport-https lsb-release gnupg2
Ensuite, nous installons la clé GPG pour nous permettre d'installer les packages. Pour cela, nous utiliserons
l'outil curl. Cet outil accédera à Internet et nous devons définir le proxy
pour que je puisse sortir. Pour le définir définitivement, nous créons le fichier ~ / .curlrc
avec le contenu suivant:
1 super utilisateur faire

2 Gnu Privacy Guard
Épisode 116
ANNEXE C.INSTALLATION DU SERVEUR WAZUH
proxy = 10.xxx: 3128
Une fois le proxy configuré, nous pouvons maintenant exécuter la commande:
root @ tests-serveur-wazuh: ~ # curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | ajout de clé apt
↪→ -
d'accord
Nous ajoutons le référentiel et mettons à jour les informations des packages:
root @ wazuh-server-tests: ~ # echo "deb https://packages.wazuh.com/3.x/apt/ stable main" | tee -a
↪→ /etc/apt/sources.list.d/wazuh.list
C.1.2. Installation de Wazuh Manager
Ensuite, nous installons le gestionnaire Wazuh:
root @ wazuh-server-tests: ~ # apt-get install wazuh-manager
Une fois installé, nous vérifions que le service a été lancé automatiquement:
root @ wazuh-server-tests: ~ # systemctl status wazuh-manager
Et il renverrait le résultat de la figure
Figure C.1: état systemctl wazuh-manager
C.1.3. Installation de l'API Wazuh
Pour exécuter l'API Wazuh, nous avons besoin dans une version égale ou supérieure à 4.6.1.
Dans notre cas, étant un Ubuntu récemment installé, il n'est pas présent, nous l'avons donc installé,
en ajoutant d'abord le référentiel officiel NodeJS:
C-2
Épisode 117
C.1. Installation à partir de référentiels
root @ tests-serveurs-wazuh: ~ # curl -sL https://deb.nodesource.com/setup_10.x | bash -

root @ wazuh-server-tests: ~ # apt-get install nodejs
Et enfin, nous installons l'API Wazuh et vérifions qu'elle a été lancée automatiquement
(figure ):
root @ wazuh-server-tests: ~ # apt-get install wazuh-api
root @ wazuh-server-tests: ~ # systemctl status wazuh-api
Figure C.2: état systemctl wazuh-api
C.1.4. Désactiver les mises à jour automatiques de Wazuh

Il est conseillé de désactiver le référentiel Wazuh ou de bloquer les paquets (les mettre
en attente) pour éviter les mises à jour accidentelles. Dans notre cas, nous avons opté pour
bloquer les paquets afin de pouvoir toujours effectuer une mise à jour manuelle à l'aide de la commande
apt-get install.
root @ wazuh-server-tests: ~ # echo "wazuh-manager hold" | dpkg --set-selections

root @ wazuh-server-tests: ~ # echo "wazuh-api hold" | dpkg --set-selections
C.1.5. Installez Filebeat

Filebeat est l'outil sur le serveur Wazuh qui envoie en toute sécurité des alertes et
les événements stockés dans Elasticsearch. Pour l'installer:
1. Nous ajoutons le référentiel Elastic, sa clé GPG et les packages de mise à jour:
root @ wazuh-server-tests: ~ # curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch |
↪→ ajout de clé apt -
d'accord
root @ wazuh-server-tests: ~ # echo "deb https://artifacts.elastic.co/packages/7.x/apt
↪→ main stable " | tee /etc/apt/sources.list.d/elastic-7.x.list

2. Nous installons Filebeat:
root @ wazuh-server-tests: ~ # apt-get install filebeat = 7 .6.1
C-3
Épisode 118
ANNEXE C.INSTALLATION DU SERVEUR WAZUH
3. Téléchargez le fichier de configuration Filebeat à partir du référentiel Wazuh. Ce

préconfiguré pour envoyer des alertes Wazuh à Elasticsearch:
root @ wazuh-server-tests: ~ # curl -so /etc/filebeat/filebeat.yml https: // l
↪→ raw.githubusercontent.com/wazuh/wazuh/v3.11.4/extensions/filebeat/7.x/filebeat.yml
4. Téléchargez le modèle d'alertes pour Elasticsearch:
root @ wazuh-server-tests: ~ # curl -so /etc/filebeat/wazuh-template.json
↪→ https://raw.githubusercontent.com/wazuh/wazuh/v3.11.4/extensions/elasticsearch/7.x/ l
↪→ wazuh-template.json
5. Téléchargez le module Wazuh pour Filebeat:
root @ wazuh-server-tests: ~ # curl -s
↪→ https://packages.wazuh.com/3.x/filebeat/wazuh-filebeat-0.1.tar.gz | sudo tar -xvz -C
↪→ / usr / share / filebeat / module
6. Nous éditons le fichier /etc/filebeat/filebeat.hml et remplaçons:

YOUR_ELASTIC_SERVER_IP avec l'adresse IP du serveur Elasticsearch.
output.elasticsearch.hosts: ['http://10.xxx:9200']
7. Activez, démarrez et vérifiez que le service Filebeat est lancé:
root @ wazuh-server-tests: ~ # systemctl daemon-reload
root @ wazuh-server-tests: ~ # systemctl enable filebeat.service

root @ wazuh-server-tests: ~ # systemctl start filebeat.service
root @ wazuh-server-tests: ~ # systemctl status filebeat
C.2. Mise à jour Wazuh Manager, API Wazuh et Filebeat

Comme nous avons conservé les packages, pour mettre à jour nous faisons:
jpcozar @ wazuh-server: ~ $ sudo apt-get install filebeat wazuh-manager wazuh-api
Nous aurions déjà la dernière version de Wazuh Manager et de l'API Wazuh en cours d'exécution, 3.12 et
7.6.2 à partir de Filebeat.
C-4
Épisode 119
ré
I NSTALLATION DE
SERVEUR ELK S TACK

D.1. Conditions préalables de la pile ELK
Comme nous sommes dans une autre machine virtuelle, nous devons définir le proxy d'entreprise (créer
le fichier ~ / .curlrc, installez les packages prérequis, ainsi que la clé GPG et
ajoutez le référentiel Elastic. Nous ferons tout cela avec l'utilisateur root.
jpcozar @ wazuh-elk-tests: ~ $ sudo su -
[sudo] mot de passe pour jpcozar:

root @ wazuh-elk-tests: ~ # apt-get install curl apt-transport-https
root @ wazuh-elk-tests: ~ # curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | clé apt
↪→ ajouter -
d'accord
root @ wazuh-elk-tests: ~ # echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" |
↪→ tee /etc/apt/sources.list.d/elastic-7.x.list
root @ wazuh-elk-tests: ~ # apt-get mise à jour
Nous pouvons maintenant installer les deux composants: Elasticsearch et Kibana.
Psaumes 120
ANNEXE D.INSTALLATION DU SERVEUR ELK
D.2. Elasticsearch
1. Installez le package Elasticsearch
root @ essais wazuh-ELK-: ~ # apt-get install ElasticSearch = 7 .6.1
2. Par défaut, Elasticsearch écoute uniquement sur l'hôte local. Pour le faire sur l'IP de
notre serveur ELK, nous éditons le fichier / etc / elasticsearch / elasticsearch.
yml, nous décommentons et définissons la ligne network.host avec l'adresse IP appropriée:
network.host: 10.xxx
3. Nous devons également indiquer les nœuds du cluster (dans ce cas, il n'y en aura qu'un). Pour
Par conséquent, nous modifions ou ajoutons les lignes suivantes dans le même fichier:
node.name: node1-tests
cluster.initial_master_nodes: ["node1-tests"]
4. Nous pouvons maintenant activer et démarrer le service Elasticsearch:
root @ wazuh-elk-tests: ~ # systemctl daemon-reload

root @ tests de wazuh-ELK-: ~ # systemctl permettent elasticsearch.service
root @ wazuh-elk-tests: ~ # systemctl démarre elasticsearch.service
5. Une fois Elasticsearch activé, il est recommandé de charger le modèle Filebeat

où il est installé. Dans notre cas, c'est sur le serveur Wazuh, sur l'autre machine
virtuel. Nous allons à ladite machine et exécutons:
root @ wazuh-server-tests: ~ # filebeat setup --index-management -E
↪→ setup.template.json.enabled = false
6. Nous vérifions maintenant, par exemple depuis le serveur Wazuh, qu'Elasticsearch est
écoute sur le port 9200:
root @ wazuh-server-tests: ~ # curl http://10.xxx:9200
7. Et il renverrait le résultat de la figure
J-2
Épisode 121
D.3. Kibana
Figure D.1: Elasticsearch
D.3. Kibana
Kibana est l'interface Web que nous utiliserons pour afficher les événements et les fichiers stockés
dans Elasticsearch.
1. Installez le package Kibana:
root @ wazuh-elk-tests: ~ # apt-get install kibana = 7 .6.1
2. Nous installons le plugin Wazuh pour Kibana:
root @ wazuh-elk-tests: ~ # cd / usr / share / kibana /

root @ wazuh-elk-tests: ~ # sudo -u kibana https_proxy = "http://10.xxx:3128"
↪→ installation de bin / kibana-plugin
↪→ https://packages.wazuh.com/wazuhapp/wazuhapp-3.11.4_7.6.1.zip
3. Kibana n'écoutera que sur l'hôte local par défaut. Pour pouvoir accéder à Kibana depuis
out, nous devons modifier le fichier /etc/kibana/kibana.yml et décommenter et
définissez la variable server.host et modifiez sa valeur:
serveur.hôte: "10.xxx"
4. Nous indiquons l'hôte Elasticsearch dans le même fichier:
elasticsearch.hosts: ["http://10.xxx:9200"]
De plus, comme le serveur Wazuh se trouve sur une autre machine, nous devons configurer le
Plugin Wazuh pour Kibana que nous venons d'installer. Pour ce faire, nous éditons le fichier
/usr/share/kibana/plugins/wazuh/wazuh.yml et remplacez localhost par
IP du serveur Wazuh:
J-3
Épisode 122
hôtes:
- défaut:
URL: http://10.xxx
port: 55000
utilisateur: foo
mot de passe: bar
5. Nous activons le service Kibana mais nous ne le démarrerons pas encore:
root @ wazuh-elk-tests: ~ # systemctl daemon-reload

root @ tests de wazuh-ELK-: ~ # systemctl permettent kibana.service
6. Enfin, comme pour le serveur Wazuh, nous allons bloquer (maintenir) les paquets
Elasticsearch et Kibana afin qu'ils ne soient pas automatiquement mis à jour, mais que nous
autoriser la mise à jour manuellement:
root @ wazuh-elk-tests: ~ # echo "elasticsearch hold" | dpkg --set-selections
root @ wazuh-elk-tests: ~ # echo "kibana hold" | dpkg --set-selections
D.4. Problèmes de Kibana

Le service Kibana écoute sur le port 5601 donc si nous allons sur notre navigateur
à nous devrions voir l'interface web de Kibana avec le plugin Wazuh. Sans pour autant
Cependant, nous avons reçu le message que le serveur Kibana n'est pas encore prêt.
D.4.1. Kibana ne démarre pas: le serveur Kibana n'est pas encore prêt
Le problème nous a été présenté, en suivant les instructions de la documentation Wazuh
( ) que Kibana n'avait pas fini d'être prêt et n'a pas montré l'interface Web. La
la solution à ce bogue est dans
où ils nous disent que nous devons éditer le fichier / etc / default / kibana et ajouter à la fin:
NODE_OPTIONS = "- max-old-space-size = 4096"
Si le démarrage Kibana est à moitié gauche, nous pouvons obtenir l'erreur suivante.
D.4.2. Une autre instance de Kibana semble migrer l'index

L'erreur Another Kibana instance semble être la migration de l'index. En attente de cette migration vers
Achevée. Si aucune autre instance Kibana ne tente de migrer, vous pouvez passer ce message en
suppression de l'index .kibana_1 et redémarrage de Kibana. Ce bogue a été corrigé comme suit
chemin (fil ):
jpcozar @ wazuh-elk-tests: ~ $ sudo curl -XDELETE 'http: //10.xx40: 9200 / .kibana_task_manager_1'
D-4
Épisode 123
D.5. Mise à jour de Kibana et Elasticsearch
Une fois que cela est fait, nous redémarrons le service avec sudo systemctl restart kibana et maintenant
on voit l'environnement Kibana, en particulier le plugin Wazuh, comme on peut le voir sur la figure
.
Figure D.2: Kibana déployé lors des tests
D.5. Mise à jour de Kibana et Elasticsearch

Pour mettre à jour Kibana et Elasticsearch sur le serveur Elk:
jpcozar @ wazuh-elk: ~ $ sudo systemctl stop kibana
jpcozar @ wazuh-elk: ~ $ sudo systemctl stop elasticsearch
jpcozar @ wazuh-elk: ~ $ sudo apt-get install kibana = 7 .6.2

jpcozar @ wazuh-élans: ~ $ sudo apt-get install ElasticSearch = 7 .6.2
Le plugin Wazuh Kibana devra également être mis à jour comme indiqué dans la section
suivant () .
D.6. Mise à jour du plugin Kibana

• Nous devenons administrateur et arrêtons kibana:
jpcozar @ wazuh-elk: ~ $ sudo su -
root @ wazuh-elk: ~ # systemctl arrête kibana
• Nous copions le fichier wazuh.yml dans son nouvel emplacement.
root @ wazuh-elk: ~ # mkdir -p / usr / share / kibana / Optimize / wazuh / config

root @ wazuh-elk: ~ # cp /usr/share/kibana/plugins/wazuh/wazuh.yml
↪→ /usr/share/kibana/optimize/wazuh/config/wazuh.yml
J-5
Épisode 124
• Nous supprimons le plugin Wazuh pour Kibana et les bundles générés
root @ wazuh-elk: ~ # cd / usr / share / kibana

root @ wazuh-elk: ~ # sudo -u kibana bin / kibana-plugin supprimer wazuh
root @ wazuh-elk: ~ # rm -rf / usr / share / kibana / Optimize / bundles
• Nous mettons à jour les autorisations de fichiers.
root @ wazuh-elk: ~ # chown -R kibana: kibana / usr / share / kibana / Optimize
root @ wazuh-elk: ~ # chown -R kibana: kibana / usr / share / kibana / plugins
• Nous installons le plugin Wazuh 3.12 pour 7.6.2:
root @ wazuh-elk: ~ # cd / usr / share / kibana
root @ wazuh-elk: ~ # sudo -u kibana https_proxy = "http://10.xxx:3128" bin / kibana-plugin
↪→ installez https://packages.wazuh.com/wazuhapp/wazuhapp-3.12.0_7.6.2.zip
• Nous mettons à jour les permissions des fichiers de configuration:
root @ wazuh-elk: ~ # chown kibana: kibana /usr/share/kibana/optimize/wazuh/config/wazuh.yml

root @ wazuh-elk: ~ # chmod 600 /usr/share/kibana/optimize/wazuh/config/wazuh.yml
• Nous avons déjà terminé la dernière étape en raison de l'erreur que Kibana nous a donnée, qui
consiste à augmenter la taille de la pile Kibana:
root @ wazuh-elk: ~ # cat >> / etc / default / kibana << EOF

NODE_OPTIONS = "- max_old_space_size = 4096"
EOF
• Nous redémarrons Kibana
root @ wazuh-elk: ~ # systemctl daemon-reload
• Nous devrions déjà avoir la dernière version stable d'Elasticsearch et de Kibana (et le plugin pour
Wazuh) en cours d'exécution, 7.6.2.
D-6
Épisode 125
C ERTIFICATS
ET
NUMÉRIQUE
E.1. Génération de certificat pour le serveur wazuh

Nous préparons un fichier wazuh-server_csr.txt avec les données que le certificat aura
en spécifiant comme noms alternatifs à la fois l'adresse IP du serveur et le (nom
DNS). Il aura le contenu suivant:
[req]
default_bits = 2048
prompt = non
req_extensions = san
distingué_name = dn
x509_extensions = san
extensions = san
[dn]
C = ES
ST = Cordoue
L = Cordoue
O = <O>
OU = <OU>
emailAddress = <adresse_email>
CN = serveur wazuh. <domaine>
[Saint]
Épisode 126
ANNEXE E. CERTIFICATS NUMÉRIQUES
subjectAltName = @alt_names
[alt_names]
DNS.1 = serveur wazuh. <domaine>
IP.1 = 10.xx57
Maintenant, nous générons la clé privée et la demande de certificat à la fois avec le fichier
précédent:
root @ wazuh-server: ~ # openssl req -new -sha256 -nodes -out wazuh-server.csr -newkey rsa: 2048
↪→ -keyout wazuh-server.key -config wazuh-server_csr.txt
Cela génère les fichiers wazuh-server.key et wazuh-server.csr. Nous vérifions que dans
La demande de certificat, nous avons les données correctes, y compris le nom IP et DNS:
root @ serveur-wazuh: ~ # openssl req -text -noout -in wazuh-server.csr
...
Extensions demandées:
Autre nom du sujet X509v3:

DNS: serveur wazuh. <domaine>, adresse IP: 10.xx57
...
Maintenant, nous signons la demande de certificat avec notre CA, en indiquant à la fois le fichier de
output (wazuh-server.crt) comme les extensions utilisées:
root @ serveur-wazuh: ~ # openssl x509 -req -in wazuh-server.csr -CA ./rootCA.pem -CAkey ./rootCA.key
↪→ -out wazuh-server.crt -days 730 -sha256 --extensions san --extfile wazuh-server_csr.txt
↪→
-CAcreateserial
Nous avons déjà le certificat généré, wazuh-server.crt. Nous le vérifions:
root @ serveur-wazuh: ~ # openssl x509 -text -noout -in wazuh-server.crt
Nous avons déjà le couple de fichiers dont nous aurons besoin pour sécuriser le serveur Wazuh:
wazuh-server.key et wazuh-server.crt.
E.2. Génération de certificats pour wazuh-elk

Nous préparons un fichier wazuh-elk_csr.txt avec les données que le certificat spécifié aura.
en spécifiant comme noms alternatifs à la fois l'adresse IP du serveur et le (Entrée DNS).
Il aura le contenu suivant:
[req]
default_bits = 2048
prompt = non
req_extensions = san
E-2
É
Épisode 127
E.2. Génération de certificats pour wazuh-elk
distingué_name = dn
x509_extensions = san
extensions = san
[dn]
C = ES
ST = Cordoue
L = Cordoue
O = <O>
OU = <OU>
emailAddress = <adresse_email>
CN = wazuh-elk. <domaine>
[Saint]
subjectAltName = @ alt_names
[alt_names]
DNS.1 = wazuh-elk. <domaine>

IP.1 = 10.xx40
Ensuite, nous créons la demande de certificat avec ces caractéristiques:
root @ wazuh-server: ~ # openssl req -new -sha256 -nodes -out wazuh-elk.csr -newkey rsa: 2048 -keyout
↪→ wazuh-elk.key -config wazuh-elk_csr.txt
Nous vérifions que nous avons à la fois le DNS et l'IP:
root @ serveur-wazuh: ~ # openssl req -text -noout -in wazuh-elk.csr
...
Autre nom du sujet X509v3:
DNS: wazuh-elk. <domaine>, adresse IP: 10.xx40
...
Maintenant, nous créons le certificat, en le signant avec le certificat racine.
root @ serveur-wazuh: ~ # openssl x509 -req -in wazuh-elk.csr -CA ./rootCA.pem -CAkey ./rootCA.key
↪→ -out wazuh-elk.crt -days 730 -sha256 --extensions san --extfile wazuh-elk_csr.txt
↪→ -CAcreateserial
Nous avons déjà la paire de clés pour le serveur de pile ELK, les fichiers wazuh-elk.crt et
wazuh-elk.key.
E-3
Épisode 128
M ONITORISATION AVEC F
N AGIOS
Afin de surveiller les serveurs avec Nagios, nous devons tout d'abord avoir installé
vos plugins.
F.1. Installation du plugin Nagios
root @ wazuh-server: ~ # apt-get install nagios-plugins
Une fois installés, pour pouvoir les vérifier à distance, nous avons besoin du plugin
(Nagios Remote Plugin Executor). Sur le serveur Nagios en production il est déjà installé,
nous n'avons donc qu'à installer le client sur chacun des serveurs à surveiller.
F.2. Installation du client NRPE v3.2.1

Le client NRPE v.3.2.1 (même s'il est paradoxalement appelé nagios-nrpe-server, il est
celui qui est installé sur l'ordinateur distant, étant nagios-nrpe-plugin celui qui est installé sur le
Serveur Nagios) est déjà dans les référentiels Ubuntu:
root @ wazuh-server: ~ # apt-get install nagios-nrpe-server
Épisode 129
ANNEXE F. SUIVI AVEC NAGIOS
Nous éditons le fichier /etc/nagios/nrpe.cfg et autorisons le serveur Nagios, avec IP

10.xx8, pour surveiller les serveurs Wazuh et définir les commandes auxquelles
appellera le serveur Nagios (vérifiez le nombre d'utilisateurs, la charge du système, le total
processus, etc ...):
...
allowed_hosts = 127.0.0.1,10.xx8
...
dont_blame_nrpe = 1
...
commande [check_users] = / usr / lib / nagios / plugins / check_users -w 5 -c 10

commande [check_load] = / usr / lib / nagios / plugins / check_load -r -w .15, .10, .05 -c .30, .25, .20
commande [check_zombie_procs] = / usr / lib / nagios / plugins / check_procs -w 5 -c 10 -s Z
commande [check_total_procs] = / usr / lib / nagios / plugins / check_procs -w 150 -c 200
commande [check_local_disk] = / usr / lib / nagios / plugins / check_disk -w 20% -c 10% /

commande [check_swap] = / usr / lib / nagios / plugins / check_swap -w 20% -c 10%
commande [check_mem] = / usr / lib / nagios / plugins / check_mem -w 90 -c 95
Nous copions le script check_mem du serveur Nagios qui ne vient pas dans l'installation par défaut
des plugins pour pouvoir vérifier la mémoire utilisée (un paramètre critique dans les serveurs
ELK Stack):
root @ serveur-wazuh: ~ # scp jpcozar @ hacolx05: / usr / lib / nagios / plugins / check_mem
↪→ / usr / lib / nagios / plugins
Nous installons le service au démarrage et vérifions qu'il est lancé:
root @ wazuh-serveur: ~ # systemctl permet nagios-nrpe-server

root @ wazuh-server: ~ # systemctl restart nagios-nrpe-server
root @ wazuh-server: ~ # systemctl status nagios-nrpe-server
Maintenant, depuis le serveur Nagios hacolx05, nous vérifions que nous pouvons vérifier à la fois le
Serveur Wazuh (10.xx57) comme Elk (10.xx40):
root @ hacolx05: ~ # / usr / local / nagios / libexec / check_nrpe -H 10 .xx57
NRPE v3.2.1
root @ hacolx05: ~ # / usr / local / nagios / libexec / check_nrpe -H 10 .xx40

NRPE v3.2.1
Une fois que tout est installé, il est temps d'ajouter les serveurs Wazuh à Nagios.
Pour ce faire, nous éditons le fichier /usr/local/nagios/etc/objects/linux.cfg et ajoutons
les entrées suivantes pour chacun des serveurs:
définir l'hôte {
utilisation serveur linux
nom_hôte wazuh-élan
alias wazuh-elk. <domaine>
adresse 10.xx40
F-2
Épisode 130
F.2. Installation du client NRPE v3.2.1
définir l'hôte {
utilisation serveur linux
nom_hôte serveur wazuh
alias serveur-wazuh. <domaine>

adresse 10.xx57
En l'ajoutant au groupe de serveurs linux, il effectuera automatiquement la vérification NRPE de

divers paramètres: charge du processeur, utilisateurs connectés, utilisation de la mémoire, espace occupé dans le
partition racine, etc. . . . En plus de ces paramètres généraux, nous sommes également intéressés par la surveillance
si les services sont lancés, à la fois pour le serveur Wazuh et pour le serveur ELK. Dans
concret nous devrons surveiller les ports indiqués dans le tableau .
Services Wazuh + ELK à surveiller dans Nagios
Serveur Un service Port
serveur wazuh gestionnaire wazuh 1515
serveur wazuh wazuh-api 5599
wazuh-élan kibana 5601
wazuh-élan elasticsearch REST 9200
wazuh-élan nœuds elasticsearch 9300
Tableau F.1: Services Wazuh + ELK à surveiller dans Nagios
Pour ce faire, nous ajoutons ce qui suit au fichier /usr/local/nagios/etc/objects/linux.cfg:
définir le service {
utilisation service local ; Nom du modèle de service à utiliser

Description du service gestionnaire wazuh
check_command check_tcp! 1515

}
utilisation service local ; Nom du modèle de service à utiliser

Description du service wazuh-api
}
utilisation service local
Description du service kibana

F-3
Épisode 131
ANNEXE F. SUIVI AVEC NAGIOS
Description du service elasticsearch-REST

}

Description du service elasticsearch-nœuds
Et puis on redémarre Nagios:
root @ hacolx05: ~ # service nagios recharger
On ferait déjà surveiller les serveurs, comme on le voit dans les figures et :
Figure F.1: Serveur Wazuh surveillé dans Nagios
Figure F.2: Serveur ELK surveillé dans Nagios
F-4
Épisode 132
UN NSIBLE
g
Pour réaliser cette annexe, nous avons utilisé la documentation en ligne Ansible ( ).
G.1. Installation d'Ansible sur le serveur Wazuh

Nous installerons Ansible sur le serveur Wazuh, à partir duquel nous distribuerons l'agent Wazuh à
Machines Linux à surveiller. Pour cela, nous faisons:
root @ wazuh-server: ~ # apt install ansible -y
root @ serveur-wazuh: ~ # ansible --version
ansible 2.5.1
G.2. Configuration du serveur Ansible et de ses clients
G.2.1. Échange de clés entre serveurs par ssh

Puisque toutes les communications dans Ansible sont effectuées par ssh, nous devons les échanger
clés entre le serveur Ansible et ses clients. Comme ce sont des serveurs Linux dans lesquels
ssh est désactivé pour l'utilisateur root pour des raisons de sécurité, nous utiliserons un
utilisateur du groupe sudo, utilisateur jpcozar.
Nous générons les clés ssh pour le serveur Wazuh avec l'utilisateur jpcozar:
jpcozar @ wazuh-server: ~ $ ssh-keygen
Nous avons déjà généré la clé privée dans /home/jpcozar/.ssh/id_rsa et la clé publique
que nous allons distribuer aux clients dans /home/jpcozar/.ssh/id_rsa.pub
Épisode 133
ANNEXE G. ANSIBLE
Ensuite, nous envoyons la clé publique à l'utilisateur jpcozar qui existe dans tous les services.
Serveurs Linux sur lesquels nous voulons installer les agents. Ce seront ceux indiqués sur la figure :
hacolx05, hacolx06, hacolx07, hacolx08, hacolx09 et hacolx10. Nous utiliserons la commande
ssh-copy-id:
jpcozar @ wazuh-server: ~ $ ssh-copy-id jpcozar @ hacolx05

...
Par exemple, pour le serveur hacolx09, nous aurions ce qui est montré dans la figure .
Figure G.1: ssh-copy-id vers le serveur hacolx09
Une fois que cela est fait, nous pourrions déjà nous connecter auxdits serveurs avec cet utilisateur sans nous
demandé le mot de passe du serveur Wazuh.
jpcozar @ hacolx09: ~ $
G.2.1.1. Création du fichier d'inventaire des hôtes Ansible
Ensuite, sur le serveur Wazuh, nous créons le fichier / etc / ansible / hosts avec le
Serveurs Linux sur lesquels nous installerons l'agent avec le contenu suivant:
[wazuh-agents]
hacolx05 ansible_ssh_user = jpcozar


Nous vérifions que tous les serveurs sont accessibles par Ansible avec la commande:
G-2
Épisode 134
G.3. Audit de l'installation
jpcozar @ wazuh-server: ~ $ ansible tout -m ping

hacolx08 | SUCCÈS => {
"changé": faux,
"ping pong"
}
"changé": faux,
"ping pong"
}

"changé": faux,
"ping pong"

"changé": faux,
"ping pong"
}
"changé": faux,
"ping pong"
"changé": faux,
"ping pong"
G.3. Audit de l'installation

Nous créons un répertoire pour les playbooks d'audit:
root @ serveur wazuh: # mkdir -p / etc / ansible / roles / audit-ansible / playbooks
Et nous créons le playbook avec un fichier appelé install-auditd.yml avec ce qui suit
contenu:
- hôtes: hacolx05, hacolx06, hacolx07, hacolx08, hacolx09, hacolx10
Tâches:
- nom: installez auditd
paquet:
nom: "{{item}}"
état: dernier
with_items:
- auditd
environnement:
http_proxy: http://10.xxx:3128
https_proxy: http://10.xxx:3128
Nous pourrions maintenant exécuter le playbook:
G-3
Épisode 135
ANNEXE G. ANSIBLE
root @ serveur-wazuh: # ansible-playbook install-auditd.yml -b -K
Et nous aurions le service d'audit installé sur tous les serveurs Linux, comme nous le voyons dans
la figure .
Figure G.2: Déploiement d'auditd sur les serveurs Ubuntu à l'aide d'Ansible
G-4
Épisode 136
D EXPLICATION DE
H
AGENT W AZUH BY
GPO
H.1. Problème de déploiement de logiciel GPO

Le problème avec le déploiement de logiciels GPO est que, par défaut, il ne permet pas
passer des paramètres à l'exécutable .msi. Dans notre cas, nous devons l'indiquer au moins
Serveur de gestionnaire Wazuh (variable WAZUH_MANAGER) et serveur de journaux Wazuh
(variable WAZUH_REGISTRATION_SERVER), pour pouvoir installer et enregistrer l'agent d'un
une fois silencieusement et automatiquement. Par conséquent, nous devons recourir à des outils
externe comme ou , qui vous permettent de créer des fichiers de transformation qui
ces paramètres seront transmis à l'exécutable lors de l'installation.
H.2. Fichier de transformation .mst avec InstEd

Dans notre cas, nous avons utilisé InstEd et le processus est le suivant:
1. Nous ouvrons le fichier wazuh-agent-3.12.0-1.msi avec InstEd
Épisode 137
ANNEXE H.DÉPLOIEMENT PAR GPO
2. Sélectionnez dans le menu Transform-> New Transform et enregistrez un fichier de

transformation nommée wazuh-agent-3.12.0-1.mst
3. Sur la gauche, nous sélectionnons la table des propriétés
4. À droite, nous créons une nouvelle ligne avec la propriété WAZUH_MANAGER et la valeur
10.xx57
5. Sur la droite, nous créons une nouvelle ligne avec la propriété WAZUH_REGISTRATION_SERVER
et la valeur 10.xx57.
6. Une fois que nous avons tout comme sur la figure nous pouvons maintenant enregistrer le fichier .mst
H.3. Création de la directive EQU_InstalarAgenteWazuh

Une fois que nous avons le fichier et sa transformation, nous les plaçons dans un endroit accessible aux utilisateurs.
ordinateurs auxquels il sera appliqué et nous créons la directive EQU_InstalarAgenteWazuh.
Dans la directive, nous établissons un filtre de sécurité, indiquant qu'il ne sera appliqué
aux contrôleurs de domaine et aux ordinateurs de domaine.
Pour le créer, nous allons:
• Configuration de l'équipement → Politiques → Configuration du logiciel → Installation de

Logiciel
• Nouveau package et sélectionnez le fichier d'origine wazuh-agent-3.12.0-1.msi dans
le site accessible.
• Dans l'onglet Modifications, nous sélectionnons le fichier de transformation créé
avec InstEd, appelé wazuh-agent-3.12.0-1.mst.
• Nous ouvrons le Gestionnaire de stratégie de groupe et lions la stratégie de groupe
aux unités organisationnelles où nous avons les serveurs Windows 2012 R2 qui
nous voulons surveiller avec Wazuh.
• Enfin, nous effectuons une mise à jour de la politique avec:
PS D: \ gpupdate / force
cela nous demandera un redémarrage et nous aurions déjà les agents Wazuh des serveurs Windows
installé et enregistré sur le serveur Wazuh et visible dans Kibana.
Figure H.1: Transformation de création dans InstEd
H-2

Langue

Déployer Wazuh Dans Une Organisation Publique

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Déployer Wazuh Dans Une Organisation Publique

Transféré par

Droits d'auteur :

Formats disponibles

26/01/2021 Déployer Wazuh dans une organisation publique

U NIVERSITÉ O BERTA DE C ATALUÑA

MISE EN ŒUVRE DE WAZUH

PROJET FINAL DU MASTER

DEGRÉ DE MASTER UNIVERSITAIRE EN SÉCURITÉ

Auteur : Javier Polo Cózar

Responsable régional : Víctor García Font

Ce travail est soumis à une licence de

À Violeta et Mireia, les deux petites stars de ma vie.

Merci beaucoup à tous.

FEUILLE DE TRAVAIL FINALE

Titre du poste: Mise en œuvre de Wazuh dans une organisation publique

Nom de l'auteur: Javier Polo Cózar

Nom du consultant: Pau del Canto Rodrigo

Nom de la PRA: Police Víctor García

Date de livraison (mm / aaaa): 06/2020

Diplôme: Master en sécurité des TIC

Zone de travail finale: sécurité de l'entreprise

Langue de travail: espagnol

Mots clés SIEM, Monitoring, Wazuh, HIDS, IDS, menaces,

Résumé du travail (maximum 250 mots): Avec le but, le contexte d'application,

L'information est devenue la ressource la plus précieuse au monde et nous devons

Résumé (en anglais, 250 mots ou moins):

Í INDEX DES CHIFFRES

INDEX DES CHIFFRES

Í INDEX DES TABLES

L IST D' UN CHRONYMES

Centre CIS pour la sécurité Internet

Énumération de plate-forme commune CPE

Vulnérabilités et exposition communes à la CVE

Surveillance de l'intégrité des fichiers FIM

Nom de domaine complet FQDN ,

Règlement général sur la protection des données GDPR

Guide de bonnes pratiques GPG13 13

Objet de stratégie de groupe GPO

Système de détection d'intrusion d'hôte HIDS ,

Format d'échange de messages de détection d'intrusion IDMEF

Système de détection d'intrusion IDS

Indicateurs de compromis des CIO

Technologie de l'information informatique

Notation d'objets JavaScript JSON

Support à long terme LTS

LISTE DES ACRONYMES

Traduction d'adresses réseau NAT

Système de détection d'intrusion réseau NIDS

Système de prévention des intrusions sur le réseau NIPS

NRPE Nagios Remote Plugin Executor ,

Base de données nationale de vulnérabilité NVD ,

OVAL Open Vulnerability Assessment Language

Protocole RDP Remote Desktop

Évaluation de la configuration de la sécurité SCA

Gestion des événements de sécurité SEM

Gestion des événements et des informations de sécurité SIEM

Gestion des informations de sécurité SIM

Réponse d'orchestration et d'automatisation de la sécurité SOAR

Thèse de maîtrise finale

Analyse comportementale des événements utilisateur UEBA

Réseau privé virtuel VPN

Liste de vérification de la configuration extensible XCCDF Description Format

ensemble solide d'activités menées pour renforcer autant que possible

Hyper-V est un programme de virtualisation Microsoft basé sur un hyperviseur pour

Indicateurs de compromis Indicateurs de compromis

machine learning machine learning.