Université Sidi Mohammed Ben Abdellah

Ecole Nationale des Sciences Appliquées - Fès

Filière : Génie Télécommunication et Réseaux

Stage d’Application
Elève Ingénieur En 2ème Année Génie Télécommunication et Réseaux

SUJET
Mise en place d’une solution SIEM pour la gestion des logs

Réalisé par :
Encadré par :
EL AMRANI Samira
Mme CHETIOUI Kaouthar

Année Universitaire : 2019/ 2020

 Remerciements

Avant tout développement de ce rapport, il apparaît opportun de commencer par des

remerciements, à ceux dont l’intervention au cours de ce projet a favorisé son aboutissement.

Je tiens à remercier mon encadrante, Mme CHETIOUI Kaouthar, qui m’a soutenu et

accompagné durant ma période de stage avec beaucoup de patience et de pédagogie, dont

j’en profite de ses directives et ses conseils pertinents.

Sans oublier dans mes remerciements tout le corps professoral de l’ENSA de Fès, pour la

formation polyvalente qu’ils m’ont prodiguée.

Que tous ceux qui m’ont aidé trouvent ici l’expression de mes meilleurs sentiments.

Rapport de stage d’application | 2

 Table des matières
Remerciements ................................................................................................................................................................. 3
Table des matières ............................................................................................................................................................ 4
Introduction générale ....................................................................................................................................................... 6
Chapitre 1 : Présentation du projet .................................................................................................................................. 7
I. Introduction ............................................................................................................................................................... 8
II. Cadre général du projet ............................................................................................................................................ 8
III. Problématique.......................................................................................................................................................... 8
IV. Objectifs ................................................................................................................................................................... 9
V. Conclusion................................................................................................................................................................. 9
Chapitre 2 : Etude des solutions de gestion des journaux .............................................................................................. 10
I. Introduction ............................................................................................................................................................. 11
II. Généralités sur les logs .......................................................................................................................................... 11
1. Définition des termes utilisés.............................................................................................................................. 11
2. Les classes de messages journaux....................................................................................................................... 12
3. Contenu de base d’un message journal .............................................................................................................. 12
4. La collecte et la transmission des fichiers journaux............................................................................................ 13
III. Les attaques contre les systèmes de journalisation .............................................................................................. 15
1. Attaques contre la confidentialité ...................................................................................................................... 16
2. Attaques contre l’intégrité du système de journalisation .................................................................................. 17
3. Attaques sur la disponibilité du système de journalisation ................................................................................ 19
IV. Centralisation des journaux ................................................................................................................................... 21
V. Système de gestion des évènements ..................................................................................................................... 21
1. Présentation d’un SIEM....................................................................................................................................... 21
2. Pourquoi ai-je besoin de SIEM? .......................................................................................................................... 23
3. Difficultés liées au SIEM ...................................................................................................................................... 23
VI. Produits SIEM ........................................................................................................................................................ 24
1. Graylog ................................................................................................................................................................ 24
2. Fluentd ................................................................................................................................................................ 25
3. ELK stack .............................................................................................................................................................. 26
VII. Analyse comparative............................................................................................................................................ 27
1. Caractéristiques .................................................................................................................................................. 27
Rapport de stage d’application | 3
 2. Fonctionnement .................................................................................................................................................. 27
VII. Choix de plateforme ............................................................................................................................................ 29
1. Présentation générale de la solution Graylog ..................................................................................................... 29
2. Composants de Graylog ...................................................................................................................................... 30
IX. Conclusion ............................................................................................................................................................. 33
Chapitre 3 : La mise en place de la solution Graylog ...................................................................................................... 34
I. Mise en place de serveur de la gestion des logs ...................................................................................................... 35
1. Présentation de l’environnement ....................................................................................................................... 35
2. Installation du serveur graylog............................................................................................................................ 35
3. Vérification des éléments installés ..................................................................................................................... 43
Conclusion générale ............................................................................................................................................................
Webographie ......................................................................................................................................................................

Rapport de stage d’application | 4

 Introduction générale

Dans le cadre de la formation universitaire à l’ENSA de Fès, on a l’opportunité de

passer un stage d’application afin de mettre en place les connaissances théoriques
acquises, et approfondir nos connaissances dans le domaine informatique.

Durant ce stage, mon encadrante m’a chargé de réaliser un projet sous le thème de «
Mise en place d’une solution SIEM pour la gestion des logs ».

Dans notre démarche, il sera donc question pour nous de présenter dans le premier
chapitre la problématique et l’objectif de la réalisation de notre projet, ensuite une
étude sur les journaux et comment peut-on les collecter et gérer. De plus, on va choisi
un logiciel qui permet de gérer les logs. Enfin, nous allons procéder à la mise en œuvre
du logiciel choisi.

Rapport de stage d’application | 5

 Chapitre 1
Présentation du projet

Ce chapitre va exposer la problématique et l’objectif de la réalisation du

projet

Rapport de stage d’application | 6

I. Introduction
Dans ce chapitre, nous présentons le contexte général du projet en étudiant la
problématique ainsi que les objectifs du projet.

II. Cadre général du projet

Aujourd’hui quasiment toutes les entreprises possèdent des logs venant des
systèmes, des applications ou des équipements réseau. Les informations contenues
dans les logs peuvent être utile à la prévention de problèmes (ex : problèmes liés à
la mal gestion des équipements réseaux à cause d’une mauvaise vérification des
configurations), la détection de problèmes (ex : détection d'une attaque) ou le suivi
du bon fonctionnement du système d’information.

Mais ces informations sont souvent noyées au milieu d'une multitude d'autres
informations et ne sont pas accessibles facilement par une simple lecture des logs.

Par conséquent, il devient important de centraliser, superviser et exploiter ces

données de façon intelligente.

III. Problématique
Notre problématique s’articulera autour de la conception et la réalisation d’un
système permettant une analyse des logs générés par des machines distantes. Cette
analyse doit pouvoir se faire en temps réel afin de permettre d'alerter
immédiatement s'il y a une détection de problème à partir des logs enregistrés dans
des fichiers de sauvegarde, afin de permettre une identification des alertes sur un
problème survenu.

Par conséquent, En cas d’une panne par exemple, on aura une intervention rapide
afin de limiter l’impact du problème survenu sur la productivité.

Alors, jusqu’à quelle point ce projet est réalisable ? Est-ce que la conception et la
réalisation de ce système sera-t-il une solution efficace pour les contraintes de la
distance et du temps ? Et que sera son avantage sur le plan économique ?

Rapport de stage d’application | 7

IV. Objectifs
L’enjeu principal dans ce projet est l’étude et l’implémentation d’un logiciel qui
permet de faire la gestion des logs.

En effet, Mise en œuvre d’un outil de gestion des journaux des équipements réseaux,
qui a pour fonction, la collecte et l’analyse des journaux envoyés par les machines du
réseau afin d’avoir une vue générale de système et d’avertir si cet outil a détecté des
anomalies pouvant causer un arrêt des services réseau.

V. Conclusion
Ce chapitre a été conçu pour présenter le cadre général du projet, ainsi que la
problématique et la solution pour remédier à ce problème.

Rapport de stage d’application | 8

 Chapitre 2
Etude des solutions de gestion des
journaux

Ce chapitre mettra le point sur les éléments qui définissent le concept de

la gestion des logs tout en spécifiant les différentes plates-fromes
disponibles de plus une étude comparative des solutions de gestion des
logs est primordiale.

Rapport de stage d’application | 9

I. Introduction
Le but de ce chapitre est de définir la notion de « centralisation des journaux », ainsi
que présenter les techniques et les recherches actuelles qui sont utilisées et
développées dans le domaine de la gestion des journaux, comment ces outils sont
utilisés pour analyser ces fichiers journaux.

IL développera également la comparaison des outils de centralisation des journaux

actuellement disponibles par rapport à la fonctionnalité désirée pour arriver à la
solution la plus appropriée.
II. Généralités sur les logs
1) Définition des termes utilisés
Évènement : est une occurrence unique dans un environnement, impliquant
généralement une tentative de changement d'état. Un événement inclut
généralement une notion de temps, d’occurrence et tout détail explicitement lié à
l’événement ou à l’environnement pouvant aider à expliquer ou à comprendre les
causes ou les effets de l’événement.

Champ d'événement : décrit une caractéristique d'un événement. Les exemples de

champ d'événement incluent la date, l'heure, l'adresse IP source, l'identification de
L’utilisateur et l'identification de l'hôte.

Entrée de journal ou bien enregistrement de journal (event record) : est une

collection de champs d’événement qui ensemble décrivent un seul événement.

Log : Un log, aussi appelé journal d’événement, est la notification d’un événement
envoyé par une application, un système, un service ou une machine sur le réseau. La
résolution des pannes nécessite en général d’étudier les logs des applications,
équipements réseaux ou autres, ils permettent donc de comprendre ce qu’il s’est
passé et de pouvoir retracer les actions d’un système. Ils sont donc très importants
en informatique, car ils peuvent donner des explications sur une ou plusieurs erreurs,
sur un crash ou une anomalie. Ils nous permettent de comprendre certains
fonctionnements d’un système par exemple, ils retracent la vie d’un utilisateur, d’un
Rapport de stage d’application | 10
paquet ou d’une application sur le réseau et peuvent aussi notifier une action
quelconque. Les logs sont donc indispensables pour bien comprendre d’où
proviennent certains dysfonctionnements.

Fichiers log : ce sont des ensembles séquentiels de messages émis par un programme
informatique ou un périphérique qui rendent compte de leur exécution.

Un audit : est le processus d'évaluation des journaux dans un environnement (par

exemple, dans un système électronique). L’objectif principal d’un audit est d’évaluer
l’état général ou de déterminer toute activité notable ou problématique.

Journalisation : c’est le fait de stocker les fichiers logs dans une base de données ou
autres supports.

Alerte ou Alarme : est une action effectuée en réponse à un événement,

généralement destiné à attirer l'attention de quelqu'un (ou de quelque chose).

2) Les classes de messages journaux

Ils peuvent être classés dans les catégories générales suivantes :

Informatif : Les messages de ce type sont conçus pour que les utilisateurs et les
administrateurs sachent qu'un événement bénin s'est produit.

Débogage : les messages de débogage sont généralement générés à partir de

systèmes logiciels afin d'aider les développeurs à résoudre et à identifier les
problèmes liés à l'exécution du code de l'application.

Avertissement : les messages d'avertissement concernent des situations dans

lesquelles des éléments peuvent manquer ou être nécessaires pour un système, mais
leur absence n'aura pas d'incidence sur le fonctionnement du système.

Erreur : ces messages sont utilisés pour relayer les erreurs qui se produisent à
différents niveaux dans un système informatique ; de nombreux messages d'erreur
ne donnent qu'un point de départ pour expliquer pourquoi ils se sont produits. Une
enquête plus approfondie est souvent nécessaire afin de rechercher la cause
fondamentale de l'erreur.
Rapport de stage d’application | 11
Alerte : une alerte indique qu'un événement intéressant s'est produit.

3) Contenu de base d’un message journal

Un message journal contient généralement les informations suivantes :

Timestamp : indique l'heure à laquelle le message de journal a été généré.

Source : est le système qui a généré le message de journal.

Données : il n’existe pas de format standard pour la représentation des données dans
un message de journal. Parmi les éléments de données les plus courants que l’on peut
trouver dans un message de journal figurent les adresses IP source et destination, les
ports source et destination, les noms d’utilisateurs, les noms de programmes etc.

4) La collecte et la transmission des fichiers journaux

Après la génération des logs par les divers périphériques et ordinateurs, les fichiers
journaux doivent être transmis et collectés dans un endroit que l’on l’appelle un
collecteur (loghost).

Un collecteur est un système informatique, généralement un système Unix ou

Windows server, où les messages de journalisation sont collectés.

Les protocoles utilisés pour la transmission des fichiers logs sont :

4.1) Syslog
C’est un protocole qui se compose d'une partie cliente et d'une partie serveur. La
partie cliente émet les informations sur le réseau, via le port UDP 514. Les serveurs
collectent l'information et se chargent de créer les journaux.

L'intérêt de syslog est donc de centraliser les journaux d'événements, permettant de

repérer plus rapidement et efficacement les défaillances d'ordinateurs présents sur
un réseau.

Rapport de stage d’application | 12

Cependant il n'y a pas de distribution fiable des messages de journal. Le principal
inconvénient de syslog est qu’il ne protège pas les enregistrements de journal
pendant la transmission ou le transfert point à point.

Il existe différentes implémentations du protocole syslog :

Syslog-ng : est une amélioration de syslog. Certaines des fonctionnalités incluent la

prise en charge du protocole IPv6, la possibilité de transférer des messages de journal
avec fiabilité à l'aide de TCP et le filtrage du contenu des journaux à l'aide
d'expressions régulières. Il utilise SSL pour une transmission sécurisée des fichiers
journaux. syslog-ng ne protège pas contre les modifications de données de journal
lorsqu'il est placé sur un noeud final
Syslog-sign : est une forme améliorée de syslog qui ajoute l'origine de
l'authentification, l'intégrité des messages, la résistance à la lecture, le séquencement
des messages et la détection des messages manquants à l'aide de deux messages
supplémentaires : "blocs de signature" et "blocs de certificats". Malheureusement, ils
sont supprimés après l'authentification, par conséquent l'intégrité du transfert n'est
que partiellement remplie. De plus, syslog-sign ne fournit aucune confidentialité lors
de la transmission.
syslog-pseudo : est également une amélioration de syslog qui propose une
architecture de journalisation pour pseudonymiser les fichiers journaux. L'idée
principale est que les enregistrements du journal sont d'abord traités par le
pseudonymiseur avant d'être archivés. Le pseudonymiseur consiste à remplacer des
champs spécifiques par des pseudonymes soigneusement conçus. Par conséquent les
messages log générés ne sont pas identiques à ceux qui sont stockés et l’origine des
messages logs ne peut être restaurée pour les besoins d’investigation. Syslog-pseudo
ne protège pas les enregistrements de journal des attaques contre la sécurité c’est-à-
dire des violations de la confidentialité et de l’intégrité.
Reliable-syslog : a pour objectif la mise en œuvre d'une livraison fiable des messages
syslog, qui repose sur les blocs du protocole BEEP (Extensible Exchange Protocol) qui
s'exécute sur TCP pour fournir le service de livraison fiable requis. Il permet
l’authentification des périphériques et incorpore des mécanismes pour

Rapport de stage d’application | 13

protéger l'intégrité des messages de journal contre les attaque de rejeu et autres
attaques. Cependant il n’assure pas la confidentialité lors de la transmission des
messages logs.

4.2) SNMP (Simple Network Management Protocol)

SNMP a été créé à l'origine pour être utilisé dans la gestion des périphériques réseau.
Cependant, au fil des années, de nombreux systèmes qui ne sont pas mis en réseau
ont adopté SNMP comme moyen d’émettre des messages de journalisation. Le noyau
de SNMP est constitué d’un ensemble simple d’opérations (et des informations
qu’elles recueillent) qui permet aux administrateurs de modifier l’état de certains
périphériques SNMP. Nous pouvons, par exemple, utiliser SNMP pour fermer une
interface de notre routeur ou vérifier la vitesse à laquelle notre interface Ethernet
fonctionne. Celui-ci peut même surveiller la température sur notre commutateur et
nous avertir quand elle est trop élevée.

De nombreux périphériques réseau sont capables d’envoyer des informations sur les
événements via syslog, mais pas tous, en particulier lorsqu’on utilise les anciens
périphériques. Par conséquent, les interruptions et les notifications SNMP permettent
d’obtenir des informations sur les événements des périphériques que nous n’aurions
pas pu collecter.

4.3) Windows Event Log

Format de journalisation propriétaire de Microsoft. Microsoft a décidé il y a longtemps
d'inventer son propre système de collecte et d'enregistrement de journaux. Ce
système s'appelle le journal des événements. Il a évolué au fil des ans et existe depuis
presque aussi longtemps que Windows. Le journal des événements d’aujourd’hui
dispose de fonctionnalités avancées. Le journal des événements est utilisé pour
collecter et examiner principalement deux Types de journaux : les Journaux Windows
et Les Journaux d'application.

III. Les attaques contre les systèmes de journalisation

Il existe diverses raisons pour lesquelles des attaquants pourraient cibler les journaux.
Tout d’abord, l’attaquant intelligent veut généralement éviter de se faire

Rapport de stage d’application | 14

prendre. Comme les données du journal fourniront la preuve de son activité, il
voudrait empêcher que les informations ne soient retrouvées en modifiant ou en
supprimant ces journaux. Un attaquant encore plus intelligent peut vouloir cacher ses
traces en induisent l’observateur à penser qu’il se passe autre chose.

En plus de masquer les pistes, les attaquants peuvent trouver des informations dans
les journaux qui sont utiles en elles-mêmes, ou des informations pouvant aider à
attaquer d'autres systèmes, tels que des mots de passe ou des numéros de compte.
Les attaques contre l'infrastructure de journalisation peuvent être effectuées à tout
moment et peuvent cibler n’importe quelle entité de l’infrastructure :

La source : le ou les hôtes sur lesquels les messages de journal sont générés.

Lors du transfert du fichier journal : au niveau du réseau entre les sources et l'hôte-
journal, ou entre le traitement et le stockage.

Le collecteur ou l'agent qui collecte les journaux : là où sont collectés les journaux de
différentes sources.

Le stockage des données de journalisation : le système de base de données sur lequel

sont stockés les informations de journalisation (si l’on utilise une base de données à
cette fin). Cela peut également s’appliquer à n’importe quel mécanisme utilisé pour
l’archivage des données de journal.

Au moment de l’analyse : le système où l'analyse est effectuée et le processus

d'analyse lui-même.

Enfin, on peut s'attaquer à la partie inévitable de toute gestion de journaux : un

analyste humain examinant des données et prenant des décisions.

Dans ce qui va suivre nous allons explorer les attaques qui peuvent être menées sur
les systèmes de journalisation ainsi que les mesures de protection qui peuvent être
prises pour les en empêcher.

Rapport de stage d’application | 15

1) Attaques contre la confidentialité
L’attaque contre la confidentialité peut être basée sur la collecte des renseignements
confidentiels par l’attaquant.

Confidentialité à la source : le moyen le plus simple est d’obtenir des données de

journaux et d’avoir accès à ces données là où elles sont générées. Des autorisations
excessives ou un accès indirect peuvent permettre à un attaquant de lire les données
du journal. L’exemple le plus simple est que le fichier journal soit lisible par tout le
monde.
Confidentialité lors du transfert des fichiers journaux : Si l’on transfère des données
de journal vers un hôte de journal central, un attaquant disposant d'un accès au
chemin réseau entre la source et l'hôte de connexion pourrait intercepter les données
lors du transfert. Ce type d'attaque peut être effectué sur l'un des points d'extrémité,
avec un accès au périphérique réseau sur l'un des hôtes ou par « détection » (trafic
d'interception) sur l'un des segments du réseau entre les deux hôtes.

Confidentialité chez le collecteur (loghost) : tous les problèmes liés à la protection de

la confidentialité des données à la source s'appliquent au loghost. De plus, comme le
loghost ne doit normalement être utilisé que pour collecter et éventuellement
analyser les données de journal, on peut restreindre les comptes de l'hôte de
journalisation aux seuls utilisateurs ayant besoin d'accéder aux données du journal,
ou d'administrer l'hôte de journalisation.

Pour certains environnements, un loghost furtif peut être souhaitable. Un hôte de

journalisation furtif n'est pas visible sur le réseau, mais les hôtes de ce réseau peuvent
toujours lui transférer leurs journaux.

2) Attaques contre l’intégrité du système de journalisation

Une attaque contre l'intégrité du journal est la possibilité de corrompre des données
réelles en écrasant ou en insérant de fausses données, ou en supprimant des données.
Un attaquant corrompt souvent des données afin de dissimuler des preuves de son
activité. L’approche la plus courante consiste simplement à

Rapport de stage d’application | 16

supprimer les données en question. Un attaquant plus malin pourrait supprimer
uniquement le message du journal indiquant son activité sur le système ou tout
simplement modifier les messages pour qu'ils semblent anodins et n'attirent pas
l'attention. Un autre type d’attaque consiste à créer une distraction en insérant des
messages factices indiquant qu’une autre activité est en cours, ce qui peut amener à
négliger son activité. Les fichiers journaux ne constituent pas de preuve si l’attaquant
arrive à démontrer que l’intégrité des journaux n’était pas sécurisée.

Intégrité à la source : Comme pour les problèmes de confidentialité que nous avons
déjà explorés, des autorisations inappropriées peuvent permettre à un attaquant de
modifier directement les données du journal à mesure qu'elles sont stockées. Par
exemple, disons qu'un utilisateur «anton» sur un système fait quelque chose de
néfaste et ne veut pas que l'activité lui soit associée. Si anton peut modifier les fichiers
journaux où ils sont stockés, il pourrait remplacer toutes les occurrences de «anton»
dans les journaux par «marcus», en transférant la responsabilité de l'activité sur
quelqu'un d'autre.
Intégrité lors du transfert : les messages Syslog Unix standard sont transportés via
UDP. Il n'y a pas d'authentification des adresses IP dans les en-têtes de paquets UDP,
et le serveur n'envoie aucun accusé de réception au client. Un attaquant ayant accès
au réseau peut injecter des messages Syslog falsifiés semblant provenir d'hôtes
légitimes sur le réseau. A titre d’exemple l’utilisation de l’outil Packit qui permet de
créer des paquets réseau arbitraire. Il est aussi possible d’intercepter et de modifier
le trafic IP («pirater la session») en utilisant une attaque par l'homme-au-milieu
Spoofing ARP. La meilleure défense contre toutes ces attaques basées sur le réseau
consiste à utiliser un mécanisme qui vérifie l'intégrité des messages.

L'intégrité chez le collecteur : les attaques d'intégrité sur le collecteur sont

fondamentalement les mêmes que les attaques à la source et les mêmes techniques
de protection s'y appliquent. L'impact de telles attaques, cependant, est supérieur à
l'impact sur une source unique, car l'intégrité de toutes les données collectées par le
serveur est en jeu.

Rapport de stage d’application | 17

Intégrité à l'analyse : les atteintes à l'intégrité de l'analyse cherchent à miner la
confiance dans la précision du système d'analyse. Il existe trois situations possibles
pour l’attaque de l'intégrité du système d'analyse :
Les données en cours de traitement (l'entrée)
Les outils utilisés pour l'analyse (le
système) La présentation des résultats
(la sortie)

3) Attaques sur la disponibilité du système de journalisation

Les attaques sur la disponibilité visent à empêcher les utilisateurs légitimes d'accéder
aux données ou au système. Les attaques contre la disponibilité peuvent être
considérées comme un type d'attaque par déni de service. Dans ce cas, « service »
peut signifier ressources humaines ainsi que ressources informatiques.

Disponibilité à la source : le déni de disponibilité le plus simple est la suppression des

données de journal à la source.
Disponibilité lors du transfert : comme mentionné précédemment, le mécanisme de
transport standard syslog utilise le protocole UDP, appelé couramment transport «
non fiable ». Un trafic réseau important peut entraîner le rejet de paquets UDP entre
la source et le serveur. Un attaquant pourrait essayer de masquer ses traces en
inondant le réseau de trafic, ce qui provoquerait l’abandon de paquets qu’il ne
souhaite pas être découverts.

Un des moyens les plus simples d’inonder un réseau qui peut facilement passer
inaperçu est le « ping flooding », exemple :

« -f » indique au programme de sortir des paquets en nombre (pas moins de 100

paquets par seconde). L'inondation du réseau est difficile à atténuer, car il est difficile
de différencier entre le trafic légitime et le trafic factice.

Disponibilité chez le collecteur (loghost) : en plus d'inonder le réseau, l'hôte de

journal peut être inondé, soit avec de fausses données de journal, soit simplement
avec un trafic factice. Les mêmes recommandations que pour les attaques d'intégrité
s'appliquent ici.

Rapport de stage d’application | 18

Disponibilité à l'analyse : une attaque contre la disponibilité, remarquable mais
souvent négligée, concerne la disponibilité de l'analyste. Un attaquant peut échapper
à la notification en exécutant suffisamment d'attaques différentes ou en injectant des
données pour donner l'impression que des attaques sont en cours. Il submerge ainsi
l'analyste de la sécurité ou lui faire perdre du temps à examiner une autre activité qui
semble plus sérieuse. La collecte et l'analyse des événements de journalisation
doivent être organisées de manière à minimiser la capacité des personnes extérieures
à injecter des données falsifiées. Généralement, la cryptographie aide à résoudre le
problème. Cela résoudra, au moins, le problème de la falsification des données lors
de la transmission de la source au point de collecte. Par exemple, remplacer syslog
basé sur UDP par un syslog fiable mis en tunnel via SSL, SSH ou IPSec.

IV. Centralisation des journaux

Le fait de centraliser les logs permet de sécuriser le réseau, d’avoir la meilleure gestion
du système d’information possible et d’avoir une vue d’ensemble de tous les éléments
importants sur le réseau. Certains messages sont anodins, tandis que d’autres
peuvent être très importants, c’est pour cela que la centralisation va faciliter la
recherche et l’analyse, qui pourront ainsi être à la fois très précises et concises sur les
activités de plusieurs systèmes, car tout se trouvera au même endroit. De plus, la
centralisation sera utile pour détecter les événements anormaux sur le réseau ou sur
les systèmes de tout type en utilisant les logs.

Ils pourront retracer le parcours d’une attaque plus facilement car ils seront d’une
part tous regroupés et d’autre part exportés de la zone d’effet de l’attaquant, il sera
donc difficile pour le pirate de supprimer les logs pour effacer ses traces. La
centralisation permet également de garantir la pérennité des logs, il est nécessaire de
ne pas les stocker sur un système en production qui peut tomber à tout instant car s’il
devient injoignable, la récupération des logs devient plus compliquée alors que, s’ils
sont exportés sur une machine disponible, la vitesse de récupération de ces derniers
sera beaucoup plus rapide et le problème sera traité plus facilement.

Rapport de stage d’application | 19

 Donc, il est d'une importance cruciale pour un service
informatique d'une organisation pour être en mesure de suivre efficacement tout état
de cause dans le réseau dans un délai nécessaire par la mise en œuvre d’un système
de gestion des évènements « SIEM » qui permet d'envoyer tous les journaux dans un
serveur central.

V. Système de gestion des évènements

1) Présentation d’un SIEM
Actuellement, il existe trois types d'environnements définis sur les systèmes de
gestion des événements :

 SEM (Security Event Management)

 SIM (Security Information Management)
 SIEM (Security Information and Event Management)
SEM (Gestion des événements de sécurité)
Ce type offre une gestion des événements, une analyse des menaces en temps réel,
une visualisation, une billetterie, une réponse aux incidents et des opérations de
sécurité. Ils sont généralement basés sur des bases de données SQL d'entreprise telles
qu'Oracle.

SIM (Gestion de l'information de sécurité)

Security Information Management, un type de logiciel qui automatise la collecte des
données du journal des événements à partir des dispositifs de sécurité, tels que les
pare-feu, les serveurs proxy, les systèmes de détection d'intrusion (IPS, IDS) et les
logiciels antivirus.

Rapport de stage d’application | 20

 SIEM (Informations sur la sécurité et gestion des
événements)
Ces produits combinent des capacités SIM et SEM, les produits SIM sont simples à
déployer et à utiliser, tandis que les produits SEM sont plus complexes.

La technologie SIEM fournit une analyse en temps réel des alertes de sécurité
générées par le matériel et les applications réseau. Les solutions SIEM sont fournies
sous forme de logiciels d’Appliance ou de services gérés. Elles sont également utilisées
pour consigner les données de sécurité et générer des rapports à des fins de
conformité.

Un outil SIEM va généralement examiner et collecter des informations provenant des

systèmes de base suivants :

 Journaux Active Directory (connexions réussies et infructueuses)

 Antivirus (périphériques et serveurs de l'utilisateur final)
 Dispositifs de protection de point final
 Les pare-feu
 Plateformes Malware et Spam
 Périphériques réseau (commutateurs, points d'accès, routeurs, etc.)

Rapport de stage d’application | 21

Cette information sera recueillie et corrélée à partir de tous ces dispositifs, qui seront
ensuite analysés pour les tendances et les modèles émergents.

2) Pourquoi ai-je besoin de SIEM?

SIEM est considérée comme la prochaine génération en matière de sécurité de
l'information car elle peut détecter les problèmes potentiels que les systèmes de
sécurité actuels ne peuvent tout simplement pas détecter. Les atteintes à la sécurité
s'accompagnent de pertes financières importantes et la réputation peut être encore
pire. Investir dans des systèmes de sécurité avancés réduit considérablement vos
risques de problèmes de sécurité, tout en vous assurant que tous vos systèmes de
sécurité sont synchronisés, surveillés et fonctionnent correctement.

3) Difficultés liées au SIEM

Utiliser un SIEM présente également des difficultés comme suivant :

 Projets SIEM non prioritaires

 Dimensionnement imprécis
 Sans configuration et sans optimisation, le SIEM ne sert à rien
 En cas "d’inondation" d’alertes, cela génère de la frustration
 Possibilité d’avoir des faux positifs

VI. Produit SIEM

Il existe un certain nombre d'outils SIEM sur le marché, à la fois open source et
commercial. Avec la montée en puissance de DevOps, de conteneurs et d'autres
méthodes de développement d'applications modernes, les solutions Open Source
connaissent un regain d'intérêt. Jetons un coup d'œil sur certains des meilleurs outils
SIEM open source.

1) Graylog
Graylog est un logiciel libre développé et écrit en langage Ruby et Java par Lennart
Koopmann en mai 2010, qui permet de centraliser tous les logs d’un parc

Rapport de stage d’application | 22

informatique sur une seule plateforme, avec des modules de traitements et de mise
en page.

Une importante communauté s'est fondée autour de cette solution, grâce au suivie
régulière des développeurs. Actuellement la version 2.0 est sortie en Avril 2016. Son
but est de pouvoir répondre rapidement en cas de problème sur le parc informatique.
Il a une plage d’action large. Il peut prévenir l’apparition d’un problème, nous prévenir
lorsqu’un problème survient, et il permet d'analyser les derniers logs de la machine si
elle s‘est éteinte subitement. La suite Graylog est alors composée de quatre parties :

 Elasticsearch permettant le stockage des logs et la recherche textuelle.

 MongoDB qui assure la gestion des métadonnées.
 Le serveur Graylog qui va recueillir les logs sur différents protocoles : UDP,
TCP…
 Et l’interface web de Graylog, qui permettre de consulter les logs

2) Fluentd
Fluentd est un outil open source permettant de collecter
des événements et des journaux. Son architecture
permet de collecter facilement les journaux provenant
de différentes sources d'entrée et de les rediriger vers
différents récepteurs de sortie. Certains exemples
d'entrée sont des journaux HTTP, syslog ou apache, et
certains puits de sortie sont des fichiers, du courrier et
des bases de données (aussi bien SGBDR que NoSQL). Aussi, il permet d'analyser les
logs et d'extraire seulement les parties significatives de chacun d’eux ; La sauvegarde
de ces informations structurées sur une base de données permet une recherche et
une analyse beaucoup plus simples.

Rapport de stage d’application | 23

 Fluentd se compose de trois éléments

de base :

Figure 13 : Architecture Fluentd

 Input : recevoir et extraire les journaux de la source de données.

 Buffer : assure la fiabilité. Lorsque la sortie échoue, les événements sont
conservés par la mémoire Buffer et automatiquement rejugé.
 Output : transmettre les journaux d’évènement vers le service de stockage.

3) ELK stack
ELK stack est une solution de centralisation et d’analyse de journaux, proposée par
l’entreprise Elastic. ELK stack se compose des trois logiciels suivants : Elasticsearch,
Logstash et Kibana.

Logstash
Est un outil de gestion des logs. Il prend en charge pratiquement tous les types de
journaux y compris les journaux système, les journaux d'erreurs et les journaux
d'applications personnalisées. Il peut recevoir des journaux provenant de nombreuses
sources, y compris syslog, messagerie (par exemple, rabbitmq) et jmx, et il peut
produire des données de différentes manières, y compris par courrier électronique,
websockets et Elasticsearch.

Rapport de stage d’application | 24

Elasticsearch
Est un moteur de recherche et d'analyse en texte intégral et en temps réel qui stocke
les données de journal indexées par Logstash. Il est construit sur la bibliothèque du
moteur de recherche Apache Lucene et expose les données via les API REST et Java.
Elasticsearch est évolutif et est conçu pour être utilisé par les systèmes distribués.

Kiabana
Est une interface graphique basée sur le Web permettant de rechercher, d'analyser
et de visualiser les données du journal stockées dans les index Elasticsearch. Il utilise
l'interface REST d'Elasticsearch pour extraire les données, aussi il permet aux
utilisateurs de créer des vues de tableau de bord personnalisées de leurs données,
mais leur permet également d'interroger et de filtrer les données.

VII. Analyse comparative

La comparaison des plateformes de centralisation et d’analyse des journaux a base
open source précédemment cités a était étudiés par deux tableaux comparatif dont
le but est de mieux choisir la plateforme la plus adopté pour notre solution

1) Caractéristiques
Le premier tableau comparatif ci-dessous a été effectué en fonction de
caractéristiques.

Rapport de stage d’application | 25

 Plateforme ELK-Stack Graylog Fluentd
Langage JavaScript Java / Ruby Rubis
Licence Apache 2.0 GPLv3 Apache 2.0
Protocole UDP BSD Syslog, BSD et syslog HTTP, AMQP,
UDP syslog IETF, IETF, FAES, GELF OMQ
IETF TCP, GELF via Http Kafka
AMQP
Stockage Elastic-Search Elastic-Search , Elastic-Search
MongoDB
Indexation Elastic-Search Elastic-Search Elastic-Search
Transport TCP, UDP TCP, UDP TCP, UDP

2) Fonctionnement
On vous présente simultanément, un deuxième tableau, qui réalise une comparaison
en terme de :

 Installation
 Configuration
 Fonctionnalités

Rapport de stage d’application | 26

 Plateforme ELK-Stack Fluentd Graylog

Installation L’installation est Installation simple, Installation

un peu complexe en créant un similaire à ELK
mais reste compte sur le site (Graylog utilise
relativement officiel et en également
simple grâce à la récupérant le ElasticSearch),
documentation en fichier avec une bonne
Ligne. d’installation. documentation.

Configuration Configuration un Configuration Configuration

peu complexe car simple qui se fait simple et similaire
il faut configurer depuis l’interface à Fluentd car elle
Logstash (il faut Web. se fait là aussi
donc maîtriser un depuis l’interface
web.
minimum les
langages de
script).
Recherche Syntaxe de Simple pour Utilisation basique
recherche avancée utilisation basique, simple, similaire à
basée sur la il suffit de taper le Fluentd et ELK.
syntaxe Lucene. mot clé recherché Syntaxe proche de
pour qu’il s’affiche Lucene.
en
surbrillance.

Dashboard Dashboard Dashboard non Dashboard

interactif par interactif. Barre de interactif facile à
défaut. Barre de recherche et créer et à modifier
recherche et barre temps non et la barre de
de temps toujours disponible par recherche / temps
disponible.
défaut. Il faut est disponible.
Dashboard facile à
configurer les
créer et à
modifier. Point Dashboard pour
fort d’ELK. les rendre
Rapport de stage d’application | 27
 compatible avec
les affichages.

VIII. Choix de plateforme

En partant de l’étude comparative énoncée au paragraphe précédent, nous avons
décidé de choisir la solution Graylog. Dans la section suivante nous réaliserons une
étude détaillée sur cette dernière.

1) Présentation générale de la solution Graylog

Graylog est une solution open-source de gestion de messages/texte/logs. Chaque
message reçu par un nœud serveur est enregistré dans une base de données Mongo-
DB indexée via Elasticsearch. Une interface web permet de gérer et d’analyser les
données.

Graylog est découpé en 2 parties principales : Graylog-server et Graylog-web. La

première est une application Java qui accepte les messages sur différents protocoles
: UDP, TCP, GELF, AMQP, …. Une API Rest est également intégrée à l’outil et est
notamment utilisée par la partie web-interface. Celle-ci (la deuxième partie), nous
permet de gérer des utilisateurs, des flux et des tableaux de bord.

Rapport de stage d’application | 28

2) Composants de Graylog
 MongoDB

MongoDB est une base de données orientée documents (mongodb). Graylog l’utilise
pour stocker nos données de configuration, pas nos données de journal. Seules les
métadonnées sont stockées, telles que les informations utilisateur ou les
configurations de flux. Aucun de nos messages de journal n'est stocké dans MongoDB.
MongoDB s’exécutera simplement en parallèle des processus de notre serveur
Graylog et n’utilisera pratiquement aucune ressource.

Graylog utilise MongoDB pour stocker nos données de configuration. Telles que les
informations utilisateur ou les configurations de flux.
 Elasticsearch
Elasticsearch est un moteur de recherche et d'indexation Open Source nouvelle
génération. Basé sur la librairie Apache Lucene, ce moteur de recherche offre des
fonctionnalités avancées telles que les recherches par coordonnées géographiques,
l'analyse et la catégorisation par agrégations, le filtrage de résultats ou encore la
recherche sur plusieurs index et types de documents différents. Taillé pour le Cloud,
ElasticSearch a été spécialement conçu pour indexer de très gros volumes de données
tout en assurant une montée en charge performante et une forte tolérance aux
pannes.

 Moteur de recherche et moteur d'indexation

Si nous parlons de moteurs de recherche, nous citons certainement Google, Bing...qui
sont des applications web permettant de retrouver des liens, des images...

Cependant, pour pouvoir donner des résultats pertinents, un moteur de recherche

doit savoir à l’avance où sont les ressources que nous pourrions lui demander. Pour
le savoir, de nombreux moteurs de recherche ont des robots qui parcourent Internet
à la recherche de nouvelles ressources. Ils se basent donc sur des moteurs
d’indexation, dont le rôle est de collecter des ressources, et d’extraire les mots-clés

Rapport de stage d’application | 29

 les plus significatifs. Un moteur d’indexation n’est donc
qu’un sous ensemble du moteur de recherche.

Tandis que les géants du Web utilisent des moteurs d’indexation propriétaires, dans
le monde de l’open source, Apache Lucene, une bibliothèque d’indexation
développée en Java s’est fait une grosse réputation, et est devenue aujourd’hui le
standard sur lequel se basent les meilleurs moteurs d’indexation. C’est le cas
d’Elasticsearch, lui aussi basé sur Apache Lucene, qui est aujourd’hui un des meilleurs
moteurs d’indexation du marché.

 Serveur Graylog
Graylog est une solution de gestion de journaux centralisée de premier plan construite
selon des normes ouvertes pour la capture, le stockage et l’analyse en temps réel de
téraoctets de données machine.

IX. Conclusion
Ce chapitre, a été consacré pour la définition des systèmes SIEM et de la notion de la
gestion des journaux, ainsi que la réalisation d’une étude comparative entre les
produits SIEM les plus utilisés, finissant par le choix de la solution Appropriée à
l’accomplissement du notre projet.

Rapport de stage d’application | 30

 Tout le long de ce deuxième chapitre, on a mis le point sur
les éléments les plus importants de notre projet, nous passerons dans le prochain
chapitre à la réalisation de la solution envisagée.

Chapitre 3
La mise en place de la solution
Graylog

Ce chapitre présentera les démarches à suivre pour installer le serveur Graylog sous
l’environnement Linux pour qu’on puisse par la suite gérer les logs.

Rapport de stage d’application | 31

I. Mise en place de serveur de la gestion des logs
1) Présentation de l’environnement
La solution de centralisation Graylog peut être installée en utilisant une variété de
méthodes et sur un large éventail de systèmes d'exploitation et d'environnements
différents.

Dans ce projet on a choisi comme système d’exploitation pour notre serveur «

Ubuntu-server 18.04 .5»

2) Installation du serveur graylog

Graylog a quatre composants principaux qui doivent être installés :

 Noeuds Graylog Server : Sert de travailleur qui reçoit et traite les messages et
communique avec tous les autres composants.
 Noeuds Elasticsearch : stocke tous les journaux / messages.
 MongoDB : stocke les métadonnées et ne supporte pas beaucoup de charge.
 Interface Web : l’interface utilisateur.
2.1) Installation de Java 8 et autres paquets prérequis
Il faut tout d’abord mettre à jour la liste des paquets disponibles depuis les dépôts
pour prendre en compte la branche nouvellement ajoutée.

Rapport de stage d’application | 32

Puis on passe à l’installation de Java 8 et de certains paquets qui nous seront utiles
par la suite :

Rapport de stage d’application | 33

 2.2) Installation de MongoDB
MongoDB est utilisé ici pour le stockage des métadonnées et données de
configuration du serveur Graylog. Il s’agit d’un SGBD non relationnel et NoSQL sans
schéma prédéfini des données où les documents (équivalents des enregistrements

des SGBDR) sont enregistrés aux formats BSON et JSON dans des collections
(équivalentes des tables des SGBDR).
Pour l’installation du MongoDB on procède de la manière suivante :
En premier lieu, il faut configurer le référentiel officiel MongoDB qui permet de fournir
la version la plus récente et il est recommandé pour installer MongoDB :

Ensuite, on fait l’installation du MongoDB :

Rapport de stage d’application | 34

La dernière étape consiste à activer MongoDB au démarrage du système
d’exploitation et à vérifier qu’il est en cours d’exécution :

A ce point, on peut passer pour l’installation de l’Elasticsearch

2.3) Installation d’Elasticsearch
Elasticsearch peut être installé avec un gestionnaire de paquets en ajoutant la liste
des sources de paquets d’Elastic.

On exécute les commandes suivantes pour importer la clé GPG publique Elasticsearch
dans apt et pour créer la liste des sources d’Elasticsearch :

Rapport de stage d’application | 35

Ensuite on installe Elasticsearch avec cette commande :

Rapport de stage d’application | 36

 Elasticsearch est maintenant installé, modifions alors
configuration de son fichier yml :

Rapport de stage d’application | 37

 Après avoir modifié la configuration, il nous reste la
dernière étape de démarrage d’Elasticsearch et de vérifier qu’elle est en cours
d’exécution :

Maintenant qu’Elasticsearch est opérationnelle, passons maintenant à l’installation

du serveur Graylog.

Rapport de stage d’application | 38

 2.4) Installation de Graylog
L’installation du serveur Graylog consiste, dans un premier temps, à installer un
nouveau dépôt puis, dans un second temps, à installer le serveur à partir de ce dépôt
nouvellement ajouté.

Et on fait l’installation et la mise à jour de notre serveur Graylog :

Rapport de stage d’application | 39

 A ce stade, il faut ajouter deux mots de passe qui sont
obligatoires et Graylog ne démarrera pas sans eux :

Remarque : « samiraGTR » est le mot de passe de l’utilisateur

« admin ».

Il faut ensuite éditer le fichier /etc/graylog/server/server.conf afind’ajouter les mots

de passe générés ainsi que l’adresse URL de notre serveur Graylog.

Rapport de stage d’application | 40

 Et pour la dernière étape dans l’installation, on active le Graylog à l’aide des
commandes ci-dessous :

Alors on a bien installé notre serveur Graylog, ainsi que ses composants.

3) Vérification des éléments installés

3.1) Interface Web de Graylog
Pour cela, il suffit de se connecter via un navigateur à l’URL suivante :
http://192.168.1.146:9000, avec 192.168.1.146 l’adresse IP de notre serveur
Graylog, on peut aussi utiliser le DNS pour donner un nom de domaine à cette adresse
afin de se connecter via un nom de domaine au lieu d’une adresse IP.

Comme montre la figure suivante l’interface web de notre serveur Graylog se lance
automatiquement :
Rapport de stage d’application | 41
Lorsqu’on remplit les champs de nom d’utilisateur et de mot de passe, on accède à
notre serveur Graylog :

Rapport de stage d’application | 42

Est comme ça l’ l’identification est abouti :
Mais on remarque une notification Qui nous informe qu’aucun format de message
(input) n’a été défini pour la réception des messages :

Figure 41 : Les notifications de graylog

Alors, on définit une entrée sur l’onglet « System/overview »

Rapport de stage d’application | 43

Les clients monitorés utilisent rsyslog ou syslog-ng, nous allons donc définir un input
de type « Syslog UDP » que nous choisissons parmi la liste déroulante :

Après avoir cliqué sur « Launch new input », la fenêtre suivante apparait, que nous
remplissons en spécifiant un port supérieur à 1024 car les ports situés en-dessous de
cette valeur sont réservés :

Rapport de stage d’application | 44

La valeur 0.0.0.0 signifie une écoute sur toutes les interfaces du serveur Graylog. Une
fois cliqué sur le bouton « Save », l’input Syslog UDP se lance automatiquement :

Rapport de stage d’application | 45

Le serveur est maintenant fonctionnel, mais en allant sur l’onglet « Search » on
remarque qu’aucun message n’est encore reçu, et c’est normal.

3.2) Connexion à MongoDB

Comme vu avec l’interface Web de Graylog, tout semble fonctionnel, mais il est
toujours mieux de s’en assurer.
La configuration de Graylog ne spécifie pas d’identifiant de connexion et utilise le port
par défaut, à savoir 27017. La base de données générée par le serveur Graylog se
nomme graylog.

Rapport de stage d’application | 46

Connexion apparemment réussie. Vérifions simplement si nous sommes bien
connectés à la base de données graylog :

Rapport de stage d’application | 47

 Conclusion générale
Ce stage d’application a été une expérience supplémentaire et d’une précieuse
utilité. Il m’a permis d’acquérir autant de connaissances et expériences en gestion
des logs qui est une notion très importante est primordiale . Il est donc une très
bonne occasion de confirmer son projet professionnel et de cerner toutes les facettes
du métier d'ingénieur.

Rapport de stage d’application | 48

 Webographie
[1] https://fr.slideshare.net/SaadaouiMarwen/rapport-pfe-ingnieur-rseaux-marwen-
saadaoui-juin-2018

[2] https://fr.wikipedia.org/wiki/Security_information_management_system

[3] https://www.harmonie-technologie.com/siem-security-information-and-event-management

[4] https://www.centreon.com/blog/graylog-et-centreon-votre-supervision-it-a-un-
incroyable-talent/

[5] https://www.cesar-conference.org/wp-
content/uploads/2019/11/20191120_J2_270_L-D-
ORAZIO_Evaluation_systèmes_de_masses_de_données_dans_le_cadre_d_analys
e_de_logs.pdf

Rapport de stage d’application | 49