Vous êtes sur la page 1sur 105

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
26/01/2021 Déployer Wazuh dans une organisation publique

Ce travail est soumis à une licence de


par Creative Commons

Page 3

UN MERCI

https://translate.googleusercontent.com/translate_f 2/105
26/01/2021 Déployer Wazuh dans une organisation publique
"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

https://translate.googleusercontent.com/translate_f 3/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

https://translate.googleusercontent.com/translate_f 4/105
26/01/2021 Déployer Wazuh dans une organisation publique
. . . . . . . . . . . . . . . . . . . . . . . . 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

https://translate.googleusercontent.com/translate_f 5/105
26/01/2021 Déployer Wazuh dans une organisation publique

. . . . . . . . . . . . . . . . . . . . . 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

https://translate.googleusercontent.com/translate_f 6/105
26/01/2021 Déployer Wazuh dans une organisation publique
. . . . . . . . . . . . . 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
https://translate.googleusercontent.com/translate_f 7/105
26/01/2021 Déployer Wazuh dans une organisation publique
. . . . . . . . . . . . . . . . . . . . . . . . 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

https://translate.googleusercontent.com/translate_f 8/105
26/01/2021 Déployer Wazuh dans une organisation publique

Page 11

Í INDEX DES TABLES


............................ 5

. . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . . . quinze
. . . . . . . . . . . . . . . . . . . . . . quinze
. . . . . . . . . . . . . . . . . . . . . . . quinze

. . . . . . . . . . . . . . . . . . . . . 63
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

. . . . . . . . . . . . . . . F-3

Page 13
12

https://translate.googleusercontent.com/translate_f 9/105
26/01/2021 Déployer Wazuh dans une organisation publique

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
https://translate.googleusercontent.com/translate_f 10/105
26/01/2021 Déployer Wazuh dans une organisation publique

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.

https://translate.googleusercontent.com/translate_f 11/105
26/01/2021 Déployer Wazuh dans une organisation publique
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.

https://translate.googleusercontent.com/translate_f 12/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 13/105
26/01/2021 Déployer Wazuh dans une organisation publique
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:

https://translate.googleusercontent.com/translate_f 14/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

CHAPITRE 1 INTRODUCTION

Phases et tâches Durée Début La fin

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

https://translate.googleusercontent.com/translate_f 15/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

Phases et tâches Durée Début La fin

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.

https://translate.googleusercontent.com/translate_f 16/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 17/105
26/01/2021 Déployer Wazuh dans une organisation publique
• 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

CHAPITRE 1 INTRODUCTION

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.

https://translate.googleusercontent.com/translate_f 18/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 19/105
26/01/2021 Déployer Wazuh dans une organisation publique
• 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

https://translate.googleusercontent.com/translate_f 20/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

CHAPITRE 2. ENQUÊTE ET ANALYSE

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

https://translate.googleusercontent.com/translate_f 21/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

https://translate.googleusercontent.com/translate_f 22/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 2. ENQUÊTE ET ANALYSE

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

avantage Désavantages

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

https://translate.googleusercontent.com/translate_f 23/105
26/01/2021 Déployer Wazuh dans une organisation publique

SIEMonster (édition communautaire)

avantage Désavantages

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

avantage Désavantages

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

avantage Désavantages

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

avantage Désavantages

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

https://translate.googleusercontent.com/translate_f 24/105
26/01/2021 Déployer Wazuh dans une organisation publique

Piste 32

CHAPITRE 2. ENQUÊTE ET ANALYSE

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

2.5. Analyse du SIEM choisi: Wazuh + Elk Stack

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

https://translate.googleusercontent.com/translate_f 25/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 2. ENQUÊTE ET ANALYSE

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

https://translate.googleusercontent.com/translate_f 26/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

2.5. Analyse du SIEM choisi: Wazuh + Elk Stack

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.

https://translate.googleusercontent.com/translate_f 27/105
26/01/2021 Déployer Wazuh dans une organisation publique

9 Haute disponibilité

19

Piste 36

CHAPITRE 2. ENQUÊTE ET ANALYSE

Figure 2.5: Cluster Wazuh

https://translate.googleusercontent.com/translate_f 28/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

https://translate.googleusercontent.com/translate_f 29/105
26/01/2021 Déployer Wazuh dans une organisation publique
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
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
battement de coeur Commutateurs de pile
Mode
*
24 6 8lien
dix
12Mode
13 2530-48G
Spd:
1416
18vingt
Off
lien
ConsoleLocatorFaultPower
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
ConsoleLocatorFaultPower
Commutateurs de pile J9775ASwitchHP
Mode
*13 2530-48G
Spd:
J9775ASwitchHP
Mode5 sept
lien
9OnzeOff
13 = vingt
quinze
ConsoleLocatorFaultPower
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
ConsoleLocatorFaultPower
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
ConsoleLocatorFaultPower2224Mode
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
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
ConsoleLocatorFaultPower
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 *
ConsoleLocatorFaultPower
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
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
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)
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
ConsoleLocatorFaultPower
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)
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
ConsoleLocatorFaultPower
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
LEDModeStatusReset Clear FanTest Console ActFDxSpd *
ConsoleLocatorFaultPower
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
ConsoleLocatorFaultPower2224Mode
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

https://translate.googleusercontent.com/translate_f 30/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

https://translate.googleusercontent.com/translate_f 31/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 3. CONCEPTION ET PRISE DE DÉCISION

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.

https://translate.googleusercontent.com/translate_f 32/105
26/01/2021 Déployer Wazuh dans une organisation publique
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.

https://translate.googleusercontent.com/translate_f 33/105
26/01/2021 Déployer Wazuh dans une organisation publique

27

Piste 44

CHAPITRE 3. CONCEPTION ET PRISE DE DÉCISION

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

https://translate.googleusercontent.com/translate_f 34/105
26/01/2021 Déployer Wazuh dans une organisation publique

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


https://translate.googleusercontent.com/translate_f 35/105
26/01/2021 Déployer Wazuh dans une organisation publique

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é

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.

https://translate.googleusercontent.com/translate_f 36/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

CHAPITRE 4. INSTALLATION

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.

https://translate.googleusercontent.com/translate_f 37/105
26/01/2021 Déployer Wazuh dans une organisation publique
root @ wazuh-server: ~ # systemctl restart wazuh-api

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:
URL: https: //10.xx57

port: 55000

utilisateur: WazuhCor

mot de passe: <mot de passe>

32

Piste 49

4.2. Installation en production du SIEM sécurisé

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:

URL: https: //10.xx57


port: 55999

utilisateur: WazuhCor
mot de passe: <mot de passe>

Et nous redémarrons l'API Wazuh:

root @ wazuh-server: ~ # systemctl restart wazuh-api

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:

https://translate.googleusercontent.com/translate_f 38/105
26/01/2021 Déployer Wazuh dans une organisation publique
33

Piste 50

CHAPITRE 4. INSTALLATION

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

4.2. Installation en production du SIEM sécurisé

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

https://translate.googleusercontent.com/translate_f 39/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 4. INSTALLATION

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

https://translate.googleusercontent.com/translate_f 40/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

4.2. Installation en production du SIEM sécurisé

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:

https://translate.googleusercontent.com/translate_f 41/105
26/01/2021 Déployer Wazuh dans une organisation publique
root @ wazuh-elk: ~ # systemctl redémarre 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

CHAPITRE 4. INSTALLATION

Figure 4.2: Connexion sécurisée au portail Kibana

Figure 4.3: Portail d'authentification Kibana avec X-Pack

https://translate.googleusercontent.com/translate_f 42/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 43/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 44/105
26/01/2021 Déployer Wazuh dans une organisation publique
-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 .

https://translate.googleusercontent.com/translate_f 45/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

ID: 002, nom: hacolx06, IP: 10.xxx

ID: 003, nom: hacolx07, IP: 10.xxx

ID: 004, nom: hacolx09, IP: 10.xxx

43

Piste 60

CHAPITRE 5. DÉPLOIEMENT

ID: 005, nom: hacolx08, IP: 10.xxx

ID: 006, nom: hacolx10, IP: 10.xxx

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

https://translate.googleusercontent.com/translate_f 46/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 47/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 48/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 49/105
26/01/2021 Déployer Wazuh dans une organisation publique

Figure 6.2: Alerte sur le fichier de mot de passe Keepass

49

Piste 66

CHAPITRE 6. CAS D'UTILISATION

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

https://translate.googleusercontent.com/translate_f 50/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 6. CAS D'UTILISATION

https://translate.googleusercontent.com/translate_f 51/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

root @ wazuh-server: # systemctl restart wazuh-manager

root @ serveur-wazuh: # / var / ossec / bin / agent_control -R -a

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

https://translate.googleusercontent.com/translate_f 52/105
26/01/2021 Déployer Wazuh dans une organisation publique

Figure 6.5: Audit de fichiers sous Windows

53

Piste 70

CHAPITRE 6. CAS D'UTILISATION

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
https://translate.googleusercontent.com/translate_f 53/105
26/01/2021 Déployer Wazuh dans une organisation publique

(Xenial) et 18.x (Bionic) ce sont ceux que nous n'activerons que:

...

< nom du fournisseur = "canonical" >


<enabled> oui </enabled>

<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

6.3. Détection des vulnérabilités

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" >

<enabled> oui </enabled>


<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>

<update_interval> 1h </update_interval>

https://translate.googleusercontent.com/translate_f 54/105
26/01/2021 Déployer Wazuh dans une organisation publique
</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

CHAPITRE 6. CAS D'UTILISATION

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

6.3. Détection des vulnérabilités

https://translate.googleusercontent.com/translate_f 55/105
26/01/2021 Déployer Wazuh dans une organisation publique

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" >

<enabled> oui </enabled>

<update_from_year> 2010 </update_from_year>

<update_interval> 1h </update_interval>
</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.

<wodle name = "syscollector" >

<disabled> non </disabled>

<interval> 1h </interval>

<scan_on_start> oui </scan_on_start>

<hardware> oui </hardware>

3 Un bug a finalement été pris en compte dans la documentation de Wazuh


4 rodéo

57

Piste 74

CHAPITRE 6. CAS D'UTILISATION

<os> oui </os>

<network> oui </network>

<packages> oui </packages>

<ports all = "no" > oui </ports>

<processes> oui </processes>

<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.

https://translate.googleusercontent.com/translate_f 56/105
26/01/2021 Déployer Wazuh dans une organisation publique

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 ->


<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>

<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

https://translate.googleusercontent.com/translate_f 57/105
26/01/2021 Déployer Wazuh dans une organisation publique

6.5. Intégration avec VirusTotal


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

CHAPITRE 6. CAS D'UTILISATION

<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 ).

https://translate.googleusercontent.com/translate_f 58/105
26/01/2021 Déployer Wazuh dans une organisation publique

60

Piste 77

6.5. Intégration avec VirusTotal

Figure 6.8: Alerte virale avec VirusTotal

Figure 6.9: Principales alertes hacolx08: virus détecté

61

Piste 78

https://translate.googleusercontent.com/translate_f 59/105
26/01/2021 Déployer Wazuh dans une organisation publique

CHAPITRE 6. CAS D'UTILISATION

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. Surveillance sans agent

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

https://translate.googleusercontent.com/translate_f 60/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 6. CAS D'UTILISATION

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

https://translate.googleusercontent.com/translate_f 61/105
26/01/2021 Déployer Wazuh dans une organisation publique
↪→ 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

6.6. Surveillance sans agent

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)

https://translate.googleusercontent.com/translate_f 62/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 6. CAS D'UTILISATION

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

https://translate.googleusercontent.com/translate_f 63/105
26/01/2021 Déployer Wazuh dans une organisation publique
Piste 83

6.6. Surveillance sans agent

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

CHAPITRE 6. CAS D'UTILISATION

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.

https://translate.googleusercontent.com/translate_f 64/105
26/01/2021 Déployer Wazuh dans une organisation publique
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>

https://translate.googleusercontent.com/translate_f 65/105
26/01/2021 Déployer Wazuh dans une organisation publique
<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

CHAPITRE 6. CAS D'UTILISATION

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:

root @ wazuh-server: # systemctl restart wazuh-manager

root @ serveur-wazuh: # / var / ossec / bin / agent_control -R -a

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'

https://translate.googleusercontent.com/translate_f 66/105
26/01/2021 Déployer Wazuh dans une organisation publique

Figure 6.12: Blocage IP avec réponse active

70

Psaumes 87

6.8. Bastion de serveurs

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

https://translate.googleusercontent.com/translate_f 67/105
26/01/2021 Déployer Wazuh dans une organisation publique

Psaumes 88

CHAPITRE 6. CAS D'UTILISATION

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

6.8. Bastion de serveurs

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.

https://translate.googleusercontent.com/translate_f 68/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

• Benchmark CIS pour Debian / Linux 9 L2

Et dans le cas du seul Ubuntu 14.x, les politiques:

• Benchmark CIS pour Debian / Linux 8 L1

• Benchmark CIS pour Debian / Linux 8 L2

Un exemple de chacun peut être vu dans les images et respectivement.

73

Piste 90

CHAPITRE 6. CAS D'UTILISATION

https://translate.googleusercontent.com/translate_f 69/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

6.9. Notifications d'alerte et rapports


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

https://translate.googleusercontent.com/translate_f 70/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

CHAPITRE 6. CAS D'UTILISATION

<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 .

https://translate.googleusercontent.com/translate_f 71/105
26/01/2021 Déployer Wazuh dans une organisation publique
76

Piste 93

6.9. Notifications d'alerte et rapports

Figure 6.17: Alerte d'attaque par force brute par e-mail ssh

77

Épisode 94

CHAPITRE 6. CAS D'UTILISATION

https://translate.googleusercontent.com/translate_f 72/105
26/01/2021 Déployer Wazuh dans une organisation publique

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>

https://translate.googleusercontent.com/translate_f 73/105
26/01/2021 Déployer Wazuh dans une organisation publique

Une fois l'intégration configurée, nous redémarrons le gestionnaire Wazuh:

root @ wazuh-server: # systemctl restart wazuh-manager

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.

https://translate.googleusercontent.com/translate_f 74/105
26/01/2021 Déployer Wazuh dans une organisation publique
✓ 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.
https://translate.googleusercontent.com/translate_f 75/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 76/105
26/01/2021 Déployer Wazuh dans une organisation publique

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
https://translate.googleusercontent.com/translate_f 77/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 78/105
26/01/2021 Déployer Wazuh dans une organisation publique

É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.

https://translate.googleusercontent.com/translate_f 79/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 80/105
26/01/2021 Déployer Wazuh dans une organisation publique
1. Nous ouvrons le gestionnaire Hyper-V du serveur
2. Nous créons une machine virtuelle avec les caractéristiques suivantes:
• Nom: Wazuh Server
• Emplacement: C: \ ClusterStorage \ Volume2
• Génération: 1
• Processeurs: 4 processeurs virtuels
• Mémoire RAM: 4 Go
• Vérifier: utiliser la mémoire dynamique pour cette machine virtuelle
• 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
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.3. Serveur ELK Stack en test


1. Nous ouvrons le gestionnaire Hyper-V

2. Nous créons une machine virtuelle avec les caractéristiques suivantes:

• Nom: ELk-stack-tests
• Emplacement: D: \ Wazuh-Elk-Tests
• Génération: 1
• Processeurs: 1 processeur virtuel
• Mémoire RAM: 3 Go
• Vérifier: utiliser la mémoire dynamique pour cette machine virtuelle
• Connexion: commutateur externe (créé dans la section ).
• Créez un disque virtuel: ELK-stack-tests.vhdx - 40 Go
• Installez un système d'exploitation à partir d'un CD / DVD ROM amorçable. Dossier de
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.4. Serveur ELK Stack en production


1. Nous ouvrons le gestionnaire Hyper-V

2. Nous créons une machine virtuelle avec les caractéristiques suivantes:

• Nom: ELk Server


• Emplacement: C: \ ClusterStorage \ Volume2
• Génération: 1
• Processeurs: 4 processeurs virtuels
• Mémoire RAM: 8 Go
• Vérifier: utiliser la mémoire dynamique pour cette machine virtuelle
• Connexion: vSwitch1
• Créez un disque virtuel: ELK-server.vhdx - 40 Go

A-3

Épisode 108

ANNEXE A. HYPER-V

• Installez un système d'exploitation à partir d'un CD / DVD ROM amorçable. Dossier de


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.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.

https://translate.googleusercontent.com/translate_f 81/105
26/01/2021 Déployer Wazuh dans une organisation publique

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é

https://translate.googleusercontent.com/translate_f 82/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 83/105
26/01/2021 Déployer Wazuh dans une organisation publique
◦ 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

B.2. Configurer Ubuntu 18.04.4 LTS

chercher:

https://translate.googleusercontent.com/translate_f 84/105
26/01/2021 Déployer Wazuh dans une organisation publique
- <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

https://translate.googleusercontent.com/translate_f 85/105
26/01/2021 Déployer Wazuh dans une organisation publique

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. Configurer Ubuntu 18.04.4 LTS

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

https://translate.googleusercontent.com/translate_f 86/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 87/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

root @ wazuh-server-tests: ~ # apt-get update

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

https://translate.googleusercontent.com/translate_f 88/105
26/01/2021 Déployer Wazuh dans une organisation publique

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


root @ wazuh-server-tests: ~ # apt-get update

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

https://translate.googleusercontent.com/translate_f 89/105
26/01/2021 Déployer Wazuh dans une organisation publique
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


I NSTALLATION DE

SERVEUR ELK S TACK


https://translate.googleusercontent.com/translate_f 90/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 91/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 92/105
26/01/2021 Déployer Wazuh dans une organisation publique
ANNEXE D.INSTALLATION DU SERVEUR ELK

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
.

https://translate.googleusercontent.com/translate_f 93/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

ANNEXE D.INSTALLATION DU SERVEUR ELK

• 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:

https://translate.googleusercontent.com/translate_f 94/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

root @ wazuh-elk: ~ # systemctl redémarre kibana

• 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]

https://translate.googleusercontent.com/translate_f 95/105
26/01/2021 Déployer Wazuh dans une organisation publique
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

É
https://translate.googleusercontent.com/translate_f 96/105
26/01/2021 Déployer Wazuh dans une organisation publique
É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

https://translate.googleusercontent.com/translate_f 97/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 98/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

nom_hôte serveur wazuh


Description du service gestionnaire wazuh

check_command check_tcp! 1515


}

définir le service {

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

nom_hôte serveur wazuh


Description du service wazuh-api

check_command check_tcp! 55999

https://translate.googleusercontent.com/translate_f 99/105
26/01/2021 Déployer Wazuh dans une organisation publique
}

définir le service {
utilisation service local

nom_hôte wazuh-élan

Description du service kibana


check_command check_tcp! 5601

définir le service {
utilisation service local

F-3

Épisode 131

ANNEXE F. SUIVI AVEC NAGIOS

nom_hôte wazuh-élan

Description du service elasticsearch-REST


check_command check_tcp! 9200
}

définir le service {

utilisation service local


nom_hôte wazuh-élan

Description du service elasticsearch-nœuds

check_command check_tcp! 9300

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

https://translate.googleusercontent.com/translate_f 100/105
26/01/2021 Déployer Wazuh dans une organisation publique

É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


jpcozar @ wazuh-server: ~ $ ssh-copy-id jpcozar @ hacolx06

...

https://translate.googleusercontent.com/translate_f 101/105
26/01/2021 Déployer Wazuh dans une organisation publique

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 @ wazuh-server: ~ $ ssh-copy-id jpcozar @ hacolx09

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

hacolx06 ansible_ssh_user = jpcozar


hacolx07 ansible_ssh_user = jpcozar

hacolx08 ansible_ssh_user = jpcozar

hacolx09 ansible_ssh_user = jpcozar


hacolx10 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"

}
hacolx07 | SUCCÈS => {
"changé": faux,

"ping pong"
}

hacolx09 | SUCCÈS => {


"changé": faux,

"ping pong"

hacolx06 | SUCCÈS => {


"changé": faux,

"ping pong"

}
hacolx05 | SUCCÈS => {

"changé": faux,
"ping pong"

hacolx10 | SUCCÈS => {

"changé": faux,
"ping pong"

https://translate.googleusercontent.com/translate_f 102/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 103/105
26/01/2021 Déployer Wazuh dans une organisation publique

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

https://translate.googleusercontent.com/translate_f 104/105
26/01/2021 Déployer Wazuh dans une organisation publique

É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

https://translate.googleusercontent.com/translate_f 105/105

Vous aimerez peut-être aussi