Salamatandiayemoussakane 180825230438 PDF

RÉPUBLIQUE DU SENEGAL
Un Peuple- Un But- Une Foi
MINISTERE de l’ENSEIGNEMENT SUPERIEUR, de la RECHERCHE et de l’INNOVATION
Institut Supérieur d’Enseignement Professionnel de Thiès (ISEP)

Filière : Systèmes – Réseaux Informatiques et Création Multimédia
Métier : Administration Systèmes et Réseaux Informatiques
Projet Opérationnel (P.O)

Administration Systèmes et
Site Web : http://www.isep.sn Réseaux Informatiques
Tél. (+221) 33 951 38 88
Fax : (+221) 33 951 3889
(2016 - 2018)
Promotion 5
Adresse ISEP-THIES : n° 121 rue Dx44 – Dixième RIAOM
B.P. : 1509
Titre du Projet Opérationnel :

Le titre de votre Projet Opérationnel :
La Centralisation des logs dans un serveur
Présentés par :
Monsieur Moussa KANE
Mademoiselle Salamata NDIAYE
Le 12Encadreurs
Mai 2018 à Thies
Monsieur Lamine DIENG
Monsieur Pape Manoumbé DIENG
Monsieur Moustapha SARR NDIAYE
ISEP-THIES : Gestion des Logs
Page vierge
Salamata NDIAYE & Moussa KANE II

SOMMAIRE
I. CONTEXTE ET PROBLEMATIQUE
II. Présentation des outils de solution
III. Installation d'ELK
IV. ELK dans la production
V. Volet Sécurité : Qu’apporte l’analyse des logs sur le plan sécurité
VI. RESULTATS
Salamata NDIAYE & Moussa KANE III

DEDICACES
 C’est avec gratitude que nous dédions ce

modeste travail d’équipe à nos chers
parents ; qui ont sacrifié leur vie pour
notre réussite et nous ont éclairé le
chemin par leurs conseils judicieux.
Nous espérons qu’un jour, nous pourrons leurs
rendre un peu de ce qu’ils ont fait pour nous,
que Dieu leur prête bonheur et longue vie .
 Nous dédions aussi ce travail à nos

familles, nos professeurs, nos amis qui
nous ont accompagné, encouragé et tous
ceux qui de près ou de loin ont participé
à la réussite de cette mémoire.
Salamata NDIAYE & Moussa KANE IV

REMERCIEMENTS
 Tout d’abord nous remercions le tout puissant et son

prophète MOUHAMED (PSL) de nous avoir permis
d’être présent tout au long de notre formation.
 Nous exprimons nos remerciements à Monsieur
Lamine DIENG pour l’assistance qu’il nous a
témoigné, pour sa disponibilité, pour ses orientatio ns
et conseils qu’il trouve ici l’expression de notre
gratitude.
 Nous remercions aussi Monsieur Pape Manoumbé
DIENG pour ses conseils.
 Nous adressons nos vifs remerciements à Monsieur
ANNE pour ses précieux conseils.
 Nous souhaitons également remercier Monsieur
NDIAYE notre responsable de filière pour ces
orientations.
 Nous remercions tout particulièrement les membres de
jury qui ont accepté de juger notre travail ainsi que
tous les enseignants qui ont contribué à notre
formation.
 Enfin, LISTE
nous DES FIGURES aussi tous nos amis et
remercions
collègues qui nous ont soutenu et tous ceux qui ont
contribué de près ou de loin à la réalisation de ce
travail.
Salamata NDIAYE & Moussa KANE V

LISTE DES FIGURES
Figure 1 : organigramme de l’isep................................................................................................... X

Figure 2 : la pile elk ....................................................................................................................... 9
Figure 3 : Schéma de principe du fonctionnement Logstash ............................................................10
Figure 4 : architecture de la pile elk ...............................................................................................13
Figure 5 : version de java ..............................................................................................................14
Figure 6 : clé d’importation...........................................................................................................14
Figure 7 : paquets de transport .......................................................................................................14
Figure 8 : installation elasticsearch ................................................................................................15
Figure 9 : installation elasticsearch ................................................................................................15
Figure 10 : installation elasticsearch...............................................................................................15
Figure 11 : configuration input de logstash .....................................................................................16
Figure 12 : configuration logstash output........................................................................................16
Figure 13 : configuration filter .......................................................................................................17
Figure 14 : tableau de bord kibana .................................................................................................18
Figure 15 : démarrage du moteur elasticsearch................................................................................20
Figure 16 : script de syslog............................................................................................................21
Figure 17 : les logs linux ...............................................................................................................22
Figure 18 : chemin par défaut ........................................................................................................23
Figure 19 : chemin du fichier d’accès .............................................................................................23
Figure 20 : interface glpi ...............................................................................................................24
Figure 21 : les logs de glpi ............................................................................................................24
Figure 22 : input de nxlog .............................................................................................................25
Figure 23 : filter nxlog ..................................................................................................................25
Figure 24 : output nxlog ................................................................................................................26
Figure 25 : fichier de configuration de nxlog ..................................................................................26
Figure 26 : logs Windows .............................................................................................................27
Figure 27 : une simple architecture ................................................................................................28
Figure 28 : ping du router vers le serveur .......................................................................................28
Figure 29 : ping du serveur vers le router .......................................................................................29
Figure 30 : l’horodatage du router ..................................................................................................29
Figure 31 : mode configuration......................................................................................................30
Figure 32 : activation de l’horodatage ............................................................................................30
Salamata NDIAYE & Moussa KANE VI

Figure 33 : IP du serveur ...............................................................................................................30

Figure 34 : log facility...................................................................................................................30
Figure 35 : loglevel informational ..................................................................................................31
Figure 36 : envoi des logs cisco .....................................................................................................31
Figure 37 : chemin des logs cisco ..................................................................................................32
Figure 38 : redémarrage de syslog..................................................................................................32
Figure 39 : visualisation des logs cisco...........................................................................................32
Figure 40 : ajouter index et rows....................................................................................................33
Figure 41 : histogramme de logs ....................................................................................................33
Figure 42 : géolocaliser les users ...................................................................................................34
Figure 43 : histogramme du top des urls .........................................................................................34
Figure 44 : cercle de log des users..................................................................................................35
Figure 45 : chemin des différents logs d’erreurs ..............................................................................35
Figure 46 : affichage des logs d’erreurs ..........................................................................................35
Figure 47 : chemin pour voir les détailler du log .............................................................................36
Figure 48 : l’explication des logs d’erreur ......................................................................................36
Figure 49 : message d’erreur .........................................................................................................38
Figure 50 : message d’erreur .........................................................................................................39
Salamata NDIAYE & Moussa KANE VII

LISTE DES SIGLES ET ABREVIATIONS
ISEP : institut supérieur d’enseignement professionnel
ELK : elasticsearch logstash kibana
APC : approche par compétence
Disep : diplôme d’institut supérieur d’enseignement professionnel
P.O : projet opérationnel
SSI : sécurité des systèmes d’information
SI : système d’information
IDS : Intrusion Detection System ou système de détection d’intrusion
IPS : Intrusion protection System ou système de protection d’intrusion
IP : internet Protocol
OS : operating system
API : Application Programming Interface
RAM : random access memory
GO : gigats octet
SIEM :
Salamata NDIAYE & Moussa KANE VIII

Avant-propos
L’institut supérieur d’enseignement professionnel (ISEP) est un centre d’excellence créé en 2012 à
vocation régionale qui est sous la tutelle du Ministère de l’Education Nationale et est rattachée à
l’université de Thiès. L’ISEP a pour mission de dispenser un enseignement supérieur et des activités de
recherche en vue de préparer directement les étudiants aux fonctions d’encadrement dans la production,
la recherche appliquée et les services ; organiser des enseignements et des activités de recherche visant
au perfectionnement permanent, à l’adaptation et à la participation, à l’évolution scientifique et même
littéraire pour certaines filières , mais aussi procéder à des expertises dans le cadre de la formation à
l’intention des entreprises publiques et privées. Elle est constituée de cinq départements à savoir :
Systèmes et Réseaux Informatiques
Création Multimédia
Exploitation Agricole
Métiers Du Rail
Tourisme et Loisirs
Ce dernier délivre, à l’issue de deux ans de formation, un Diplôme de technicien supérieur Disep option
Administration en systèmes et réseau informatique. Avec l'adoption du système d’approche par
compétence (ACP) l’Institut Supérieur d’Enseignement Professionnel autorise à ce que les étudiants
ayant terminé les deux années de formation obtiennent leurs diplômes intitulé le « Disep » après une
soutenance de leur projet opérationnel (P.O) devant un jury, dont les thèmes sont soit proposés par
l’administration ou par les étudiants ; ces thèmes en fin de compte doivent être validé sous l’accord de
l’administration, à la suite duquel se tient un stage de fin d’étude, d’une durée de deux mois au sein
d’une entreprise.
Sa vocation première est de former, tant sur le plan théorique que pratique, de futurs cadres : Techniciens
Supérieurs dans tous les domaines cités précédemment.
L’objectif visé est de faciliter l’intégration de ses étudiants dans le milieu environnemental de
l’entreprise et de les mettre face aux fréquentes épreuves de la vie professionnelle. Il permettra donc à
l’apprenant de mettre en pratique les nombreuses connaissances théoriques acquises au cours de deux
années de formation.
Salamata NDIAYE & Moussa KANE IX

ORGANIGRAMME DE L’ISEP-THIES
Conseil d’administration
Conseil académique
Direction Conseil de gestion
Contrôle de gestion
Cellule interne d’Assurance Qualité
Audit interne
Suivi-évaluation Relations extérieures et

communication
Médiation Assistanat
Services
Fonctions de Services médico Direction des
Agence comptable Administratifs et
financiers services sociaux et sportifs études
Comités et
Conseillers Secrétariat
commissions
Service des Service des Service des Service Service

Comptabilité Ressources Ressources d’appui aux d’appui aux Bibliothèque
Ressources Départements
Humaines Financières Matérielles apprenants person nels Centrale
Dépense -
Service des Service de
Visa Service des ressources Centre Laboratoire
Ressources la Scolarité
Informatiques médical Central
Documentaires centrale
Recouvremen
t Centres
Accueil d’Innovation,
Rapportage Information Filières et d’Application
Comptabilité Imprimerie Programme
Orientation et de
Acquisitions Reprographie s de
Inscription Transfert
Personnel enseignant Recouvrement Numérisation formation
Personnel gestionnaire Suivi
Archivage
Personnel technique
Personnel de service
Voyages, Missions Service
d’Appui au
Placement
des
Logistique Apprenants
Réseaux Social, Médical
Patrimoine Visites
Multimédia Habitat,
Maintenance Immersions
Applications Restauration
Entretien Séjours, Stages
Maintenance Sport, Loisirs
Sécurité Culture
Insertion
Figure 1 : organigramme de l’isep
Source : notre responsable de filière
Salamata NDIAYE & Moussa KANE X

INTRODUCTION
Il n’existe pas de système parfaitement sécurisé. Même si vous débranchez votre ordinateur et
l’entreposez dans un hangar, il y aura toujours une personne capable de le rebrancher. Les
vulnérabilités sont donc inhérentes aux systèmes informatiques. Mais, s’il n’est pas possible de toutes
les supprimer, on peut néanmoins les surveiller. En parlant de surveillance ici, nous faisons référence à
deux réalités. La première est l’analyse en temps réel de l’utilisation qui est faite du système : cette
opération permet de détecter une attaque, voire de l’empêcher, et d’alerter les administrateurs en cas
de problème. La seconde est l’étude des traces laissées par l’exploitation d’une vulnérabilité : cela peut
permettre de comprendre la méthode employée par l’attaquant, de mettre en place des contre-mesures
ou même de mieux sécuriser l’application.
La sécurité des systèmes d’information (SSI) ou plus simplement sécurité informatique, est
l’ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires à la mise en
place de moyens visant à empêcher l'utilisation non-autorisée, le mauvais usage, la modification ou le
détournement du système d'information.
Pour mieux assurer la sécurité du système d'information, il nous faut un moyen technique qui nous
permet d’interagir avec le système pour pouvoir rassembler toutes les informations en temps réel. Pour
ce faire l’étude des journaux d’événement autrement dit les logs est un moyen efficace. Il existe
diffèrent type de journaux (journaux applicatives et journaux systèmes).
Le concept de la centralisation des logs consiste simplement à mettre sur un même serveur, une même
plateforme, l’ensemble des logs des systèmes, des applications, des routeurs, et des services des machines
environnantes.
Pour le bon déroulement de ce travail nous allons en première partie expliquer ce que c’est la
centralisation des logs, en deuxième partie présenter la solution ELK et son installation et enfin
expliquer comment centraliser les logs des différentes provenances et le fonctionnement de la stack
elk.
Salamata NDIAYE & Moussa KANE

1
PREMIERE PARTIE

2
I. CONTEXTE ET PROBLEMATIQUE
A. Contexte
Les entreprises déploient de plus en plus de solutions informatiques qu’il faut savoir
administrer, pour cela les logs en sont le principal outil. En effet, les logs sont très
importants pour les entreprises car ils permettent l'analyse en profondeur des services mis
en place. Le problème est qu’ils génèrent des logs que nous devons utiliser afin
d’administrer le système. Trouver le bon log devient évidemment un réel problème
lorsque l’on ne sait même pas où chercher.
B. Problématique
Les logs, sont donc indispensables dans toutes applications afin d’analyser, savoir ce qu’il
se passe et intervenir lors des différents problèmes (configurations, réseaux,
permissions…). Lorsque dans une infrastructure, plusieurs applications sont en marche, la
recherche de logs adéquats au problème devient très longue.
Plusieurs problèmes se posent :
Où peut-on trouver les logs ? Bien entendu les logs de chaque application ne se trouvent
pas au même endroit.
Ai-je la permission d’accès ? Les différentes applications ne sont pas créées par une seule
et même personne, les permissions sont différentes, un administrateur peut ne pas avoir
accès à chaque fichier.
Comment rechercher les bonnes informations ?
Il faut obligatoirement utiliser sous linux les commandes grep, cut, sort, tail afin de
rechercher la bonne information qui pourra aider à trouver le problème, ces commandes
sont très efficaces mais aussi très lassantes si on passe la journée à vouloir dépanner
différentes applications.
On perd donc un temps précieux à rechercher le bon log au bon endroit.
Pour répondre à ce besoin, nous souhaitons regrouper tous les journaux pour pouvoir les
exploiter plus simplement. Nous allons donc travailler sur une solution permettant une
gestion centralisée des journaux de plusieurs services, ainsi qu’un moteur de recherche
pour identifier les entrées des journaux en cas de problèmes.

3
C. Centralisation des journaux

1. LES LOGS
Un log, aussi appelé journal d’événement, est la notification d’un événement qui est plus ou
moins important, 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 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. Il existe diffèrent type de journaux (journaux
applicatives et journaux systèmes).
La journalisation applicative désigne l'enregistrement chronologique des opérations du logique métier

pendant le fonctionnement de l'application. Un journal applicatif est lui-même une exigence du métier.
Il est donc défini comme une fonctionnalité faisant partie de la logique applicative. Par conséquent, il
ne devrait pas être arrêté pendant le fonctionnement de l'application.
La journalisation système désigne l'enregistrement chronologique des événements survenant au niveau

des composants du système. Le niveau de cette journalisation peut être paramétré, afin de filtrer les
différents événements selon leur catégorie de gravité. Les catégories généralement utilisées sont, par
ordre croissant de gravité : information, débogage, avertissement, erreur.
2. La centralisation
Les logs sont produits par tous types de systèmes, d’applications et d’équipements sur le réseau. En
général, les logs sont stockés par défaut dans le dossier « /var/log » sous Linux.
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.

4
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.
3. Pourquoi l’analyse des journaux devient-elle plus importante

Communément, deux raisons répondent à cette interrogation :
 Avoir une vue d’ensemble d’éléments cruciaux à la bonne gestion d’un SI pour y mener des
traitements tels que :
 IDS : Certains types d’IDS (Intrusion Detection System ou systèmes de détection d’intrusion)
se servent des journaux d’événement pour détecter des comportements anormaux sur le réseau
ou sur les systèmes surveillés. Ceux-ci n’utilisent donc pas l’écoute du réseau pour effectuer
leur surveillance mais bien les logs, on appelle alors ces IDS des log-based IDS (IDS basé sur
les logs). Des exemples connus de tels systèmes sont Fail2ban et DenyHosts par exemple.
 Forensic, plus largement l’analyse d’attaque ou d’intrusion : on peut décrire le forensic de la
façon suivante : “c’est une méthode d’investigation matérielle ou virtuelle basée sur
l’extraction de données brutes ou altérées de manière à construire une chronologie
événementielle, à établir une logique séquentielle ou à reconstituer un ensemble cohérent de
données pour en tirer une explication contextuelle. ” (source : post d’un membre
d’Hackademics). C’est une définition exacte dans le cadre qui nous intéresse même si les
notions d’enquête et de moyen légal de récupération de données sont ici oubliées. Quoi qu’il
en soit, les logs vont être d’une grande aide lorsque ceux-ci nous permettent de retracer le
parcours, les actions et les dégâts d’un attaquant sur un ensemble de systèmes. Ceux-ci étant
facilité d’abord parce que les logs sont centralisés, mais également, car ils sont exportés de la
zone d’effet de l’attaquant qui a alors plus de difficulté à les supprimer pour effacer ses traces.
 Recherche / statistique : La centralisation des logs va permettre d’effectuer des recherches très
précises sur l’activité de plusieurs systèmes tout en étant sur une machine. Les opérations de
recherche et de statistique s’en trouvent donc facilitées, car tout est sur la même plate-forme.
 En cas de crash ou de suppression des logs
 Diagnostiquer un crash : Il peut être très utile de savoir précisément ce qu’il s’est passé
lorsqu’un système devient complètement injoignable (après un crash sévère par exemple). Si

5
les logs qui permettent de diagnostiquer la panne se trouvent sur ladite machine, ils sont
difficilement atteignables (on peut toujours extraire les disques, les lires sur un autre
périphérique, etc.). Dans le cas où les logs sont exportés sur une machine dont la disponibilité
est assurée, il est alors possible de rapidement récupérer les derniers événements systèmes de
la machine endommagée pour diagnostiquer plus facilement.
 Garantir la survie des logs à une suppression : une des étapes post-intrusion lors d’une attaque
informatique est l’effacement des traces que le pirate a pu laisser. On passe alors, en partie,
par la suppression des logs et historiques qui peuvent donner des indications sur les actions
menées pendant l’intrusion et possiblement sur une identité réseau (IP, adresse MAC, OS,
etc.). Lorsque les logs sont stockés en local, les logs qui sont supprimés sont alors
difficilement récupérables, lorsqu’ils sont également envoyés sur une autre machine, il est
possible de récupérer des informations. Notons que la suppression, ou perte, des logs peut
également arriver dans d’autres contextes plus proches de la vie quotidienne d’un SI telle que
la perte d’un disque, d’une partition dédiée aux logs, la mauvaise manipulation d’un
administrateur systèmes pressé…

6
DEUXIEME PARTIE

7
II. Présentation des outils de solution

A. Les applications existantes (étude comparative)
 Fail2ban : Fail2ban est un outil apprécié particulièrement, il s’agit d’un IDS/IPS basé sur les logs.
Ils sont donc d’une importance capitale ici, car les logs produits vont permettre à Fail2ban de
détecter certaines intrusions et ainsi déclencher des actions d’avertissement ou de protection
(envoyer un mail, bannir une ip, etc.).
 DenyHost : DenyHost reprend le même principe que Fail2ban, il se base sur les logs dans le
fichier /var/log/auth.log des machines Linux pour détecter des tentatives de brute force sur le port
SSH. Il n’est malheureusement retreint qu’au service SSH.
 Rsyslog : Rsyslog est ce qui permet de gérer les logs sur la plupart des machines Linux, il
implémente le protocole syslog pour l’envoi de logs entre machines. C’est un outil à connaître
lorsque l’on entreprend de centraliser des logs avec des machines sous Linux.
 Splunk : Il s’agit d’un outil d’indexation des journaux d’événements. Autrement dit, une fois les
logs centralisés, Splunk va permettre d’effectuer des recherches facilement dans ses logs pour en
extraire des données facilement exploitables.
 Snare : Snare est un outil pour Windows, il s’agit d’un service qu’interagit avec le système
Windows Event Log pour faciliter la gestion à distance et le transfert en temps réel
des informations des journaux d’événements Windows.
 ELK : Il s’agit de la combinaison de trois logiciels : Elasticsearch en tant que moteur d’indexation,
Logstash pour la collecte, l’analyse et le stockage de logs, et Kibana pour construire des graphiques
et requêter et visualiser n’importe quelles données.
Loin d’avoir fait le tour des outils qui vous permettront de mettre en place la centralisation des logs dans
vos parcs informatiques, mais il y en a un très grand nombre, que ce soit pour la centralisation en elle-
même, pour l’indexation, le stockage ou le traitement (sécurité, graphique…). Il s’agit là d’un élément
central de la sécurité d’un système d’information qui doit être pensé dès qu’il se met à grandir. Pour
notre cas on va travailler avec ELK.
B. Présentation général d’ELK
Le moins que l’on puisse dire sur ELK c’est qu’il a fait un sacré bonhomme de chemin. Il faut dire que
hormis SEC (un outil de corrélation d'événements pour le traitement avancé des événements qui peut
être utilisé pour la surveillance des journaux d'événements, pour la gestion de réseau et de sécurité,
pour la détection de fraude et pour toute autre tâche impliquant une corrélation d'événements.), il n’y
avait pas grand-chose de disponible dans le monde Open Source pour ce genre de travail.

8
Et puis le rapprochement naturel qui s’est opéré avec Elasticsearch et Kibana amène aujourd’hui le
projet vers de nouvelles ambitions. Devenir une des pierres angulaires de la Business
Intelligence… Rien moins que ça !
Il faut dire que Logstash est désormais bien entouré.
Figure 2 : la pile elk
Source : www.googleimage.com
 Elasticsearch
S’il y a un élément qui prend une importance primordiale dès lors que l’on souhaite analyser, stocker
des messages, évènements systèmes ou applicatifs, c’est la base de données utilisée. Les bases de
données traditionnelles (SGBD) ont montré, comme dans le cadre du stockage des métriques, leurs «
limites » pour travailler sur les volumes imposés par ce genre de pratique.
Elasticsearch n’est pas à proprement parlé une base de données mais un moteur d’indexation, de
recherche et d’analyse de données. Et c’est certainement là que Jordan Sissel, auteur de Logstash a fait
une bonne pioche. Car du coup, son projet bénéficie des fonctionnalités intrinsèques à Elasticsearch
comme :
 Le mode cluster actif/actif natif d’Elasticsearch.

 Les volumes qu’est capable de traiter Elasticsearch en matière de recherche tout en restant
temps réel ; ou quasi.
 Le système de « facets » qui permet, sans coût supplémentaire, de récupérer tout un ensemble
de statistiques sur les éléments trouvés, comme le nombre, la répartition de ces éléments par
rapport à une clé…
 La possibilité de commencer à envoyer des résultats à l’utilisateur alors que la recherche n’est
pas terminée sur l’ensemble des données. Logstash créé par exemple un index par jour, ce qui
fait que vos recherches les plus courantes restent rapides, quelques soit le volume total

9
d’événements stockés en base. La possibilité d’effectuer toutes les recherches via une API
REST donc pas de client dédié nécessaire.
Ceci n’est pas une liste exhaustive des qualités de Elasticsearch mais simplement celles qui ont le plus
marquées dans son utilisation. Notre « rivière » dans le contexte gestion de logs, c’est Logstash !
 Logstash
Ce qui est particulièrement frappant aujourd’hui est de constater la diversité des usages que font les
gens de Logstash, ce qui atteste de la polyvalence du projet en matière de traitement sur les
messages et autres événements.
C’était jusqu’à peu la seule solution à ma connaissance qui permettait de construire des systèmes de
gestion de logs structurés et normalisés pour Unix et Windows.
Ce genre de chose est désormais également possible avec Rsyslog qui lui aussi sait désormais envoyer
ces messages vers Elasticsearch. Bel exemple de convergence technologique !
Logstash fonctionne sur un principe simple, un peu comme un routeur de messages. Il est possible de
parler de chaînes de liaisons entre ces différents composants.
Figure 3 : Schéma de principe du fonctionnement Logstash
Source : googleimage.com
Tous les différents éléments que nous allons détailler sont implémentés sous forme de plugins, ce qui
rend très « facile » d’ajouter des possibilités à Logstash. La liste de ces plugins ne cesse d’ailleurs de
croître.

10
 Les entrées
Logstash accepte à peu près tout ce qui peut être représenté sous forme de chaîne de caractères en
entrée. Texte, nombre, date…. La liste des entrées disponibles est impressionnante et couvre des
plugins particuliers pour Collecte, Graphite, websocket, les interruptions SNMP et même l’IRC.
Il est tout à fait possible d’envisager un jour un plugin permettant de récupérer les données
depuis Check my Website pour les envoyer vers une instance Logstash.
Des plugins plus génériques sont bien sûr disponibles comme Syslog, AMQP pour recevoir des
messages depuis ce genre de bus messages…
 Les encodeurs/décodeurs
Les « codecs » sont arrivés pour pouvoir normaliser et packager un ensemble de filtres (à découvrir ci-
dessous).
Il existe de nombreux codecs dont Graphite pour encoder, décoder le format natif des
métriques Graphite ou encore NetFlow, qui permet lui l’encodage, décodage des flux NetFlow, très
utilisé (mais pas assez) pour la supervision réseau.
 Les filtres
Les filtres permettent de triturer tout message arrivant dans Logstash. Par triturer, on entend découper
un message en plusieurs parties et inversement, formater les dates, normaliser le nom des champs mais
pas seulement. Au programme, des filtres pour créer des sommes de contrôles, extraire des
nombres, supprimer des messages avant stockage et bien sûr Grok.
Grok est sûrement l’un des plus puissants et permet de structurer n’importe quel message, comme des
logs Apache 2 par exemple. Sa force réside dans sa capacité à construire des expressions complexes à
partir d’expressions régulières plus simples.
 Les sorties
Une fois que Logstash a opéré sur les messages, ceux-ci peuvent désormais être « routés » vers les
plugins de sortie qui permettent d’envoyer les messages vers un bon paquet d’outils tierces, en plus de
la sortie « naturelle » de Logstash; à savoir Elasticsearch.

11
 Kibana
Kibana a démarré comme un projet d’interface à Logstash. C’est aujourd’hui l’interface officielle
d’Elasticsearch.
Vous pouvez donc l’utiliser pour visualiser, rechercher parmi les messages de logs et autres
événements système mais n’est pas du tout limité à ça. Kibana vous permet de requêter et visualiser
n’importe quelles données contenues dans Elasticsearch.
C. Pourquoi le choix de ELK

Les avantages d’une centralisation des logs d’un système informatique complexe sont reconnus depuis
longtemps par les hébergeurs. La mise en œuvre d’une collecte centralisée basée sur syslog (via
rsyslog ou syslog-ng) est donc maintenant un classique dans le cadre de l’exploitation de ces systèmes
complexes.
Néanmoins l’exploitation des masses d’informations contenues dans ces fichiers reste très limitée et
fastidieuse tant qu’on a à faire à des fichiers texte sous forme brute. C’est là que des outils tels que
Kibana (couplé à ElasticSearch) permettent d’aller vraiment plus loin en offrant des interfaces de
recherche efficaces ainsi que la possibilité de produire des tableaux de bord permettant de suivre
l’activité d’un système. Ce type d’outils destinés aussi bien aux administrateurs systèmes qu’aux
développeurs ou aux experts métiers a pris un essor important ces dernières années.

12
D. Architecture de la pile ELK
Figure 4 : architecture de la pile elk
Source : ttps://www.google.sn/search?q=Architecture+de+la+pile+ELK&tbm
III. Installation d'ELK

A. Spécifications de l’environnement utilisé et nécessaire au déploiement
1. Ressources Matérielles
Sur l’ensemble de nos environnements, nous collectons des milliers de journaux d’événements par jour
ce qui correspond à des gigats d’octets de Logs par jour qu’il faut être en mesure d’analyser. Donc il est
nécessaire d’avoir de bonne ressources matérielles comme une machine serveur de système
d’exploitation linux comme ubuntu physique ou virtuel avec au moins 4G de RAM et 100Go de
stockage de disque dur dans laquelle on va installer notre outils ELK (Elasticsearch, Logstash et
Kibana) pour ne pas confronter à des erreurs de mémoire. Comme prérequis on doit Installer Java avant
d’installer elasticsearch. Il existe différents types de version de java pour chaque distribution sous
linux.
NB : Nous avons utilisé pour notre cas un système ubuntu14.04 pour faire tous nos installations

13
B. Installation d'Elasticsearch
1. Installation de Java
La commande suivante permet de connaitre la version de java du système installé :
java –version
Figure 5 : version de java
Source : auteur du projet
Dans notre cas on a comme version du java7 donc pour l’installer il faut :
apt-get install openjdk-7-jdk
2. Concepts de base Elasticsearch

Voici les concepts de base qu’il faut pour installer ElasticSearch.
 Télécharger la clé d’importation d’ElasticSearch avec la commande suivante :
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add –
Figure 6 : clé d’importation
Ensuite, nous avons besoin d’installer les paquets de transports avant de procéder à
l’installation d’ElasticSearch.
sudo apt-get install apt-transport-https
Figure 7 : paquets de transport

14
Enregistrer la définition du référentiel dans /etc/apt/sources.list.d/elastic-6.x.list qui est la

suivante :
echo "deb https://artifacts.elastic.co/packages/6.x/apt stable main" | sudo tee -a

/etc/apt/sources.list.d/elastic-6.x.list
Figure 8 : installation elasticsearch
Apres l’insertion de la clef d’importation il nous faut faire une mise à jour des paquets avant
d’installer elasticsearch. Pour ce faire on fait :
apt-get update && apt-get install elasticsearch
C. Installation de Logstash
1. Installation
Pour installer les paquets logstash il suffit simplement de taper la commande suivante :
apt-get install logstash
2. Configuration de Logstash
Pour configurer le logstash on crée un fichier dans le répertoire /etc/logstash/conf.d. Ce fichier
comporte 3 parties : input, filter et output
 Input : Ingestion de données de toutes formes, tailles et sources

15
 Filter : Qui sert à analyser les données et les transformer indépendamment du format ou
de la complexité
 Transformer les données non-structurées en données structurées en grok
 Déchiffrer des coordonnées géographiques à partir des adresses ip
 Faciliter le traitement indépendamment de la source, du format ou du schéma de données
 Output permet de faire redirectionner les logs d’entrées vers logstash ou dans la console
Exemple de configuration : Traitement en input
Figure 11 : configuration input de logstash
Traitement en output
Figure 12 : configuration logstash output
Traitement en filter
Il existe plusieurs manières de filtrer :
 Filtrer les évènements de manière centralisée (au niveau de l’indexer)
 Avantages : Moins de filtres à mettre en place, administration plus facile et mieux organisée.
 Inconvénients : Filtrage sur un grand nombre de logs en même temps, ce qui demande plus de
mémoire.

16
 Emettre les évènements directement au bon format
 Avantages : Pas de données à surveiller, pas de filtres redondants ni consommateurs en

mémoire.
 Inconvénients : Pratique pour de très faibles quantités de données. Impossible ici de mettre en
place de manière globale du fait des multitudes de pilotes ayant chacun un ou plusieurs formats
de logs différents
Exemple de filtre :
Figure 13 : configuration filter
D. Installation de Kibana
1. Installation
Une fois stockés plusieurs logs il nous faut un outil avec une interface graphique p our mieux avoir
une vue globale de l’ensemble des événements. Pour ce faire on installe kibana avec la commande
suivante :
apt-get install kibana

17
2. Tableaux de bord Kibana
Figure 14 : tableau de bord kibana

18
TROISIEME PARTIE

19
IV. ELK dans la production

A. Mise en place d’une Centralisation
1. Comment utiliser la pile ELK pour la récupération et l'analyse du journal
Le volume de données générées par les systèmes d’informations augmente de façon quotidienne, et
l’exploitation de ces données est un enjeu pour beaucoup d’entreprises. Donc il doit être
nécessairement faire appel à une procédure qui permet d’avoir une vue beaucoup plus explicite et plus
simple que l’on appelle kibana. Peu importe le format sous lequel est stockée l’information: fichier de
logs, base de données, autre média… la finalité est toujours d’extraire certaines données et de les
synthétiser dans un graphique ou un dashboard Kibana s’appuie sur toute la puissance d’ElasticSearch
pour manipuler simplement et efficacement l’ensemble de ses données. Ce dernier s’appuie
directement sur un système d’indexation c’est-à-dire analyser des données soumises, pour produire
un format qui facilite une recherche rapide, comme l’index d’un livre permet de retrouver du contenu
sur base d’un mot clé de même un moteur de recherche pour faire rechercher des données dans l’index
sur base de requêtes plus ou moins structurées une interface de visualisation pour donner du sens à des
données, une utilisation brute des résultats est fastidieuse, surtout si le volume est important. L’outil de
visualisation permet de produire des graphiques dynamiques, des visualisations ou des rapports sur
base des données retournées par le moteur de recherche.
 Procédures et étapes d’utilisation pour visualiser les logs vers kibana
ETAPE1 : Démarrer le moteur d’elasticsearch avec la commande suivante :
./bin/elasticsearch
Figure 15 : démarrage du moteur elasticsearch

20
ETAPE 2 : Démarrage de logstash avec un fichier log à utiliser :
NB : Pour rediriger les logs d’un logiciel, d’un OS ou d’une application dans le pipeline logstash on
doit créer, pour chaque service, un script dans logstash.
Exemple de cas pratique de récupération de logs :
a. Récupération des logs de type syslog machine local et distante (ssh, kernel, auth,
syslog)
Figure 16 : script de syslog
./bin/logstash –f syslog. Conf
Une fois démarré le service logstash avec la commande en dessus il laisse automatiquement les logs
défilés vers le console grâce à la sortie (output codec=>rubydebug)

21
La figure ci-dessous montre les différents types de log qui sont générés par notre système.
Figure 17 : les logs linux
b. Récupération des logs d’apache (utilisation de glpi)
GLPI (Gestion Libre de Parc Informatique) est une application open-source full-web pour gérer
l’ensemble des problématique d’un parc informatique de la gestion de l’inventaire, des composantes
matérielles ou logicielles du parc à la gestion de l’assistance aux utilisateurs. Dans notre cas on ne
s’intéresse pas à glpi pour son utilité de gérer la gestion d’inventaire d’un parc informatique mais en
guise d’exemple pour contrôler les logs des applications, comment trouvés leur erreurs et les résoudre.
Et pour ce faire il nous faut installer l’application glpi. Avant d’installer GLPI , il faut installer
l’environnement LAMP (Linux , Apache, Mysql, Php)
Apache2 est un serveur http qui gère des applications web (glpi, ldap, webmin…..) mais aussi de les
mettre en interaction direct vers l'internet (site web html, php, etc...). Dans notre cas pratique, on va
utiliser le glpi et l’interagir directement avec notre serveur apache2.
On sait qu’à chaque exécution d’une application ça laisse générer automatiquement des traces derrière.
La meilleur solution est de récupérer tous ces journaux et les mettre quelques part pour que quand

22
notre application bug ou voir même présente certaines anomalie c’est à parti du fichier log qu’il faut
aller voir pour identifier les erreurs.
Pour faire un lien entre apache2 et glpi il faut déplacer tout simplement les paquets de glpi vers
(/var/www/html/) de telle sorte qu’à chaque démarrage de notre application web, ça laisse passer
automatiquement des traces vers notre serveur apache2
Exemple de cas pratique
 Installation d’apache2:
Téléchargez apache2, php5, MySQL et phpMyAdmin
apt-get Install apache2 php5 mysql-server phpmyadmin
 Configuration du serveur apache
Allez dans /etc/apache2/sites-available et modifions le fichier 000-default.conf :
Figure 18 : chemin par défaut
Ici toutes les erreurs auquel rencontre notre application seront redirigé vers /home/salla-
kane/logs/error.log et les access vers /home/salla-kane/logs/access.log
Figure 19 : chemin du fichier d’accès
Téléchargement de l’archive GLPI :
Placez-vous dans /var/www/ et téléchargez l’archive de GLPI avec cette commande :
Wget https://github.com/glpiproject/glpi/releases/download/0.90.1/glpi-0.90.1.tar.gz
Il faut ensuite extraire l’archive avec la commande suivante :
Tar –zxf glpi-0.90.1.tar.gz

23
Créez l’arborescence voulue :
Le dossier glpi sera créé directement au bon endroit dans /var/www/
Démarrage de l’application glpi avec l’adresse suivante : Localhost/glpi
Figure 20 : interface glpi
Visualisation des logs vers le chemin du répertoire spécifié /home/salla-kane/logs/access.log
Figure 21 : les logs de glpi

24
c. Récupération des logs depuis une machine Windows
Lorsqu'on gère un parc de serveur qui comprend malheureusement des serveurs Windows, on souhaite
centraliser leurs logs, voir même recevoir des alertes en fonction du contenu. C'est simple à faire sous
Linux avec rsyslog, avec lequel on transmet les syslogs vers la destination voulu. Par contre dans le
monde Windows il n'y a pas de serveur syslog natif.
Le logiciel libre nxlog permet de faire exactement la même chose que rsyslog, sans interface
graphique. NXLog Community Edition est un outil de gestion de journaux open source disponible
gratuitement. Il est disponible pour différentes plateformes, y compris Windows et GNU / Linux.
L'édition communautaire de NXLog est utilisée par des milliers de personnes à travers le monde, des
petites entreprises en démarrage aux grandes entreprises de sécurité. Sa flexibilité lui permet d'être
utilisé dans diverses configurations et peut être utilisé à la fois comme un agent de collecteur de
journaux et comme un serveur de journal.
On commence par ajouter un nouvel input à logstash toutes les confs de logstash se gèrent
dans /etc/logstash/conf.d/ :
Figure 22 : input de nxlog
On créé maintenant un nouveau filtre pour mettre en forme les logs
Figure 23 : filter nxlog

25
Enfin on spécifie le chemin de sortie
Figure 24 : output nxlog
On redémarre logstash puis on vérifie que l’input nxlog est bien actif avec un petit netstat :
Service logstash restart
Pour la configuration de nxlog c’est simple, après avoir installé sur la machine cliente Windows le
logiciel nxlog on passe dans le fichier de configuration qui se trouve dans : C:\Program Files
(x86)\nxlog\conf et on renseigne l’adresse ip du machine serveur et le port 514 qui est le pour accéder
à rsyslog et le format json.
Figure 25 : fichier de configuration de nxlog

26
Teste : après les configurations on redémarre les services logstash voici les logs Windows qui passe
sur le serveur logstash.
Figure 26 : logs Windows
d. Récupération des logs d’un routeur Cisco
Nous allons étudier l'intérêt de la centralisation des logs et surtout la manière de faire pour
les systèmes Cisco (Routeurs, Switch, ...). Vous trouverez ainsi la procédure à suivre en ligne de
commande sous Cisco pour envoyer tout ou partie de vos logs sur un serveur distant
Configuration Cisco pour exporter les logs
On a utilisé gns3 pour réussir l’exportation de log des routeurs avec une simple architecture en guise
d’exemple.

27
Figure 27 : une simple architecture

NB : Avant tout on commence d’abords à tester si les périphériques se communiquent avec la
commande ping des adresses du routeur et du serveur
@routeur : 192.168.231.136
@serveur : 192.168.231.130
Test de la machine serveur sur la console du routeur :
Figure 28 : ping du router vers le serveur

28
Test de la machine routeur sur la console du serveur :
Figure 29 : ping du serveur vers le router
Comme on a une interconnexion entre notre routeur et notre serveur sur lequel les logs seront bientôt
stockés, étant donné que la configuration que nous présentons se fait en ligne de commande, on va
commencer par ouvrir un terminal. Une fois sur celui-ci, on va passer en mode enable.
Il est important de noter que l'horodatage, c'est à dire l'heure que vont avoir les journaux exportés, a
une importance particulière dans le système de centralisation des logs. Il permet en effet de retracer
précisément les logs entre plusieurs machines, c'est pour cela que la première chose à faire est de
mettre notre machine à la bonne date et la bonne heure :
Résultat
Figure 30 : l’horodatage du router

29
On va ensuite passer en mode configuration afin de paramétrer l'envoi des logs.
Figure 31 : mode configuration
On commence par activer l'horodatage des logs :
Figure 32 : activation de l’horodatage
Puis on configure les différents paramètres propres à l'envoi des logs, on commence par l'IP du serveur
distant :
Figure 33 : IP du serveur
Puis on peut préciser le log facility qui va nous permettre, sur le serveur distant, de trier les logs, par
exemple :
Figure 34 : log facility
Une chose importante à faire également est de configurer le log-level à partir duquel on prendra le soin
d'envoyer les logs. Pour différentes raisons comme la performance, on peut ne pas vouloir envoyer la

30
totalité des logs au serveur distant, on va alors choisir d'envoyer les logs à partir d'un certain niveau de
criticité. On retrouve généralement ces niveaux de logs :
 7 - debbuging
 6- informational
 5 - notifications
 4 - warnings
 3 - errors
 2 - critical
 1 - alerts
 0 - emergencies
Vous l'aurez compris, le loglevel "0" est le cas le plus critique et "7" est le cas le plus bavard où
beaucoup de logs sont produits, nous allons alors envoyer les logs de 6 à 0, on fixe donc la valeur
à "informational».
Figure 35 : loglevel informational
Notre système Cisco va maintenant commencer à envoyer ses logs au serveur distant. On va pouvoir
récapituler la configuration présente en retournant en mode enable puis en saisissant "show logging" :
Figure 36 : envoi des logs cisco

31
Paramétrage serveur et visualisation des logs Cisco

Maintenant que nous avons configuré notre routeur Cisco pour qu'il envoie les logs au serveur de log
distant, il faut que l'on sache mettre à part ces logs. Dans Rsyslog, système utilisé dans le tutoriel sur la
centralisation des logs dont j'ai parlé plus haut, il faut aller dans le fichier "/etc/rsyslog.conf" et ajouter
la ligne suivante pour que tous les logs arrivant en log-facility 5 soient mis dans un fichier spécifique.
On mettra par exemple tous les logs des machines Cisco sur ces logs level :
Figure 37 : chemin des logs cisco
On va ensuite redémarrer ce service
Figure 38 : redémarrage de syslog
Il nous faut maintenant, pour tester notre export de log Cisco, provoquer la journalisation d'évènement.
On verra alors dans le fichier configuré dans Rsyslog pour recevoir les fichiers à log-facility 4 les logs
de notre routeur Cisco
Figure 39 : visualisation des logs cisco

32
ETAPE3 : Visualisation des logs vers kibana
Maintenant que les logs sont collectés, puis transformées et enfin stockées dans Elasticsearch, il ne
reste plus qu’à les exploiter pour construire des tableaux de bord. Le tableau de bord que nous allons
construire affichera les informations de géolocalisation sur une carte, le top des urls, et l’activité sur le
site. Kibana a été installé à la racine du site web par défaut. Il est donc accessible à l’url suivante :
http://localhost/nomduserveur
Dans un premier temps, nous allons configurer dans quel index Elasticsearch nous allons récupérer
nos logs. Rappelez-vous, nous avons stocké nos logs dans un index dont le pattern était : « logstash-
local-salla-moussa- {+YYYY.MM.dd} »ce qui veut dire que Logstash créera un nouvel index chaque
mois. Nous allons reporter ce pattern dans Kibana en ouvrant les options du tableau de bord. Une fois
l’index enregistré, nous pouvons commencer à créer des panels de restitution. Pour cela, nous avons
besoin de créer des lignes rows qui vont contenir nos panels. Une fois la ligne créée, nous allons lui
ajouter des panels.
Figure 40 : ajouter index et rows

Cliquer sur le « + » à gauche de la ligne. La fenêtre de création de panel s’affiche en haut de l’écran.
Cliquer sur « + » de la ligne, puis sélectionner « histogram », puis enregistrer, et voici le résultat :
Figure 41 : histogramme de logs

33
Maintenant, nous allons ajouter un panel permettant de connaitre la position de nos utilisateurs. Pour
cela, nous allons utiliser le panel better-map qui s’appuie sur les coordonnées produites par le plugin
geoip. Ajoutez le champ geoip. Location dans le champ field et enregistrer le panel. La carte s’affiche
avec les points de connexion indiquant le nombre de requêtes reçues.
Figure 42 : géolocaliser les users

Nous allons utiliser le panel « terms » pour afficher le top des urls.
 Sélectionner le champ cs-uri-stem.

 Limitez le nombre d’url à 5,
 Appliquer un Order « count » et cliquez sur « Créer ».
Kibana nous affiche un histogramme contenant les 5 urls les plus accédés sur la période sélectionnée.
Figure 43 : histogramme du top des urls

34
Nous allons utiliser notre panel goal qui permet d’afficher les logs des utilisateurs (salitandiaye,
madamefaye, mbayang, ndeyefatou) sous forme de diagramme circulaire
Figure 44 : cercle de log des users

On peut aussi afficher les différents types d’erreurs auxquels nos utilisateurs se sont confrontés
Dans la fenêtre principale, survolez la colonne eventType, puis choisissez la flèche pour trier les types
d'événements par nom.
Figure 45 : chemin des différents logs d’erreurs

L’affichage des différents logs d’erreurs, d’avertissements, warning etc.
Figure 46 : affichage des logs d’erreurs

35
Pour mieux interpréter ces différents types de graphiques il faut aller juste sur le paramètre message
puis enchainer par l’élément bar
Figure 47 : chemin pour voir les détailler du log

L’explication des logs d’erreurs de façon détaillés
Figure 48 : l’explication des logs d’erreur

36
2. Besoins exprimés pour la future application

Le cahier des charges représente la synthèse des besoins exprimés par ELK et permet de définir les
fonctionnalités demandées à l’application ainsi que les ressources disponibles. L’outil doit permettre
de :
 Présenter schématiquement mais globalement l’ensemble des logs centralisés
 Mettre en évidence l’état des logs par un code de couleur
 Visualiser toutes les logs recensés
 Mettre en évidence l’état de chaque provenance
 Générer l’état des logs par rapport aux alertes
 Afficher le descriptif détaillé de chaque log
 Recenser toutes les alertes du serveur de log (date, heure, numéro d’alerte,
machine concernée, priorité de l'alerte)
3. Teste de visualisation des logs d’erreurs via le tableau de bord

Une fois récupérer tous les journaux de machine distante, on a reçu pas mal d’information par rapport
au différents service exécuté par l’administrateur du système. Des messages de genres avertissement
(warning) mais qui ne veut pas dire que le système ne marche pas ce n’est qu’une simple
avertissement , emerg (c’est-à-dire que le système est inutilisable ou risque de le devenir à très court
termes), alert (message alertant l’administrateur système qu’une action de sa part a été requise ),
critique (qui veut dire que Ya certains défaillance critique qui peut à tout moment empêcher a votre
système de pouvoir bien marcher), err (Message d’erreur), notice (message de fonctionnement normal,
sans gravité particulière, info (message à titre info), debug (débogage).
Pour notre cas pratique parmi les logs centralisés on a pris comme exemple un message d’erreurs
(WARNING). C’est à dire que l’utilisateur (NDEYE FATOU) est averti pour ne pas confronter à
certains problèmes. Le message s’affichant dans kibana nous dit qu’il est impossible d’enregistrer le
fichier car sa taille dépasse la limite autorisée. La solution ici est que l’espace source doit être
inférieure à celle de la destination.

37
Figure 49 : message d’erreur

38
Pour notre deuxième exemple la même machine est confrontée à un problème d’espace insuffisant
Figure 50 : message d’erreur

39
Windows a diagnostiqué avec succès une insuffisance en mémoire virtuelle(Espace du disque

dur interne d'un ordinateur qui vient seconder la mémoire vive, Elle se concrétise par un fichier
d'échanges (fichier swap), lequel contient les données non sollicités constamment. La mémoire
virtuelle, comme son nom l'indique, sert à augmenter artificiellement la mémoire vive. Elle est aussi
moins performante) .Ce qui veut dire que si la mémoire second est inferieur a la mémoire vive, elle
peut entrainer de la réduction de la performance et les applications mettent vraiment du temps à se
lancer. Pour résoudre ce problème on doit :
Démarrer , Panneau de configuration , Afficher par petites icônes , Système , Paramètres Système
Avancés , Clic sur le bouton "Paramètres" dans Performances , Onglet "Avancé" , Clic sur le bouton
"Modifier" dans Mémoire virtuelle , Décocher la case "Gestion automatique du fichier d'échange pour
les lecteurs" , Clic sur le volume qui doit contenir votre fichier "Page File" (généralement C:)
,Sélectionnez "Taille gérée par le système" (ou "Taille personnalisée" et saisir vos nombres) , Clic sur
le bouton "Définir" , Ok , Ok , Ok , Fermer et redémarrer.
V. Volet Sécurité : Qu’apporte l’analyse des logs sur le plan sécurité

1. L’importance de la sécurité de l’accès aux SI de l’entreprise
En informatique, le concept d'historique des événements ou de journalisation désigne l'enregistrement
séquentiel dans un fichier ou une base de données de tous les événements affectant un processus
particulier (application, activité d'un réseau informatique…). Le journal (en anglais log file ou plus
simplement log), désigne alors le fichier contenant ces enregistrements. Généralement datés et classés
par ordre chronologique, ces derniers permettent d'analyser pas à pas l'activité interne du processus et
ses interactions avec son environnement.
Il est essentiel pour toute entreprise ou organisation de concevoir et de mettre en œuvre des dispositifs
de sécurisation fiables pour mettre leurs SI et leur contenu à l’abri de personnes malveillantes ou
d’intrusions inopportunes. Les risques d’espionnage industriels et de piratage informatique sont en
effet réels.
2. Les enjeux d’une analyse des logs de sécurité bien menée

L’analyse des logs de sécurité permet d’avoir une vision fiable du niveau de sécurité de votre système
d’information. L’analyse consistera à décortiquer les évènements de sécurité, à étudier leur évolution
et notamment les incidents. De plus, elle vise à détecter les menaces informatiques potentielles et
permet d’adopter en conséquence les mesures de correction ou de renforcement les plus adéquates. En
fonction de vos infrastructures, vos besoins et vos possibilités techniques, l’analyse peut se faire en
temps réel pour un maximum de réactivité dès qu’une alerte est lancée ou à échéances régulières.

40
3. Analyser les traces des logiciels malveillants grâce aux fichiers de

journalisation
Les responsables informatiques réclament souvent la nécessité d’avoir une vision globale et détaillée
de l’activité de leurs équipements (firewalls, serveurs VPN, proxy, IDS, serveurs web, ressources de
calcul dédiées, anti-virus …) afin de contrôler toute tentative d’intrusion ou de malveillance. Face à la
quantité d’informations générées au sein d’un parc informatique, il est difficile de les traiter à la volée.
Une solution possible pour s’atteler à cette problématique fait appel aux SIEM (Security Information
and Event Management), des outils en mesure de gérer et de corréler des logs (fichiers de
journalisation). En effet, ces solutions sont munies de moteurs de corrélation qui permettent de relier
plusieurs évènements à une même cause. Cependant ce type d’approche ne permet pas d’identifier les
APT (Advanced Persistent Threat), c’est-à-dire des menaces latentes et le plus souvent entièrement
inconnues… Hélas, ces menaces sont très répandues de nos jours.
VI. RESULTATS
A. Objectifs réalisés
Nous avons pu centraliser plusieurs logs de sources différents dans un seul serveur. Il s’agit des
logs de machine:
 Linux
 Windows
 Les logs de services
 Les logs des routeurs Cisco
 Des applications comme glpi
Pour avoir une vue globale sur tous les informations de notre système et mieux pouvoir les analysés
B. Evolutions possibles
 Du stockage et du traitement de gros volumes de données (Big Data) dans la pile élastique qui
est la prochaine évolution d’ELK
 Amélioration du monitoring pour une facilité de pouvoir des erreurs comme des anomalies
 Détection de bug dans les applications Big Data…)

41
CONCLUSION
Pour valider notre fin de formation, il est obligatoire pour nous de présenter des P.O (projet
opérationnel) dont l’étude ici porte sur la sécurité informatique particulièrement des SI (système
d’informations) et notre choix se concentre sur l’étude des logs, centralisation des logs dans un serveur :
titre de notre sujet.
On a eu à voir ensemble ce qu’est la centralisation des logs et la solution ELK pour le mettre en place.
Aussi on a pu comparer notre solution avec d’autres solutions existantes et comment l’utilisé de manière
général.
La centralisation de logs consiste simplement à regrouper plusieurs logs de machines distantes, de

routeurs, d’applications ou des services dans un seul serveur pour y avoir une vue globale l’histoire de
mieux les surveiller.
En somme compte tenus des multiples avantages qu’offre la solution « open source » ELK, notre
problématiques d’avoir une vue d’ensemble des logs de tout machines et serveurs de l’ISEP-THIES des
bureaux et des applications virtuelle afin de faciliter le monitoring des différents services s’est enfin
réalisé.

42
WEBOGRAPHIE
 https://www.elastic.co/fr/
 https://www.supinfo.com/articles/single/2498-elk-installation-configuration
 https://image.slidesharecdn.com/dploiementelkenconditionsrelles
 https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_pr%C3%A9vention_d%27
intrusion
 https://www.ladissertation.com/Sciences-et-Technologies/Sciences-de-la-Vie-
de-la-Terre/Serveur-De-Centralisation-Des-Logs-36913.html
 https://desaille.fr/monitoring-avec-elk/
 http://blog.d2-si.fr/2016/08/23/bonnes-pratiques-elastic-stack/
 http://lesaventuresdeyannigdanslemondeit.blogspot.sn/2014/02/couplage-
nxlog-et-stack-elasticsearch.html
 https://openclassrooms.com/courses/proteger-son-serveur-avec-fail2ban
 https://blog.zenika.com/2016/02/15/consolider-les-logs-docker-dans-un-elk/
 https://www.information-security.fr/fr/centralisation-des-logs-un-outil-pour-
la-securite/
 http://www.ragingcomputer.com/2014/02/sending-windows-event-logs-to-
logstash-elasticsearch-kibana-with-nxlog
 https://fr.wikipedia.org/wiki/Historique_(informatique)
 http://www.wancore.fr/ref/analyse-des-logs-de-securite.html

XI
TABLE DES MATIERE

Page vierge .................................................................................................... II
SOMMAIRE.................................................................................................III
DEDICACES ............................................................................................... IV
REMERCIEMENTS ......................................................................................V
LISTE DES FIGURES ................................................................................. VI
LISTE DES SIGLES ET ABREVIATIONS ................................................ VIII
Avant-propos ............................................................................................... IX
ORGANIGRAMME DE L’ISEP-THIES........................................................X
INTRODUCTION.......................................................................................... 1
PREMIERE PARTIE ..................................................................................... 2
I. CONTEXTE ET PROBLEMATIQUE ...................................................... 3
A. Contexte ............................................................................................................................ 3
B. Problématique .................................................................................................................... 3
C. Centralisation des journaux ................................................................................................. 4
1. LES LOGS .................................................................................................................... 4
2. La centralisation ............................................................................................................. 4
3. Pourquoi l’analyse des journaux devient-elle plus importante ............................................ 5
DEUXIEME PARTIE .................................................................................... 7
II. Présentation des outils de solution .......................................................... 8
A. Les applications existantes (étude comparative) ................................................................... 8
B. Présentation général d’ELK ................................................................................................ 8
 Elasticsearch...................................................................................................................... 9
 Logstash ...........................................................................................................................10
 Les entrées....................................................................................................................11
 Les encodeurs/décodeurs ...............................................................................................11
 Les filtres......................................................................................................................11
 Les sorties.....................................................................................................................11
 Kibana..............................................................................................................................12
C. Pourquoi le choix de ELK..................................................................................................12
D. Architecture de la pile ELK ...............................................................................................13
III. Installation d'ELK ................................................................................13
A. Spécifications de l’environnement utilisé et nécessaire au déploiement .................................13

XII
1. Ressources Matérielles ..................................................................................................13

B. Installation d'Elasticsearch.................................................................................................14
1. Installation de Java ........................................................................................................14
2. Concepts de base Elasticsearch.......................................................................................14
C. Installation de Logstash .....................................................................................................15
1. Installation ....................................................................................................................15
2. Configuration de Logstash .............................................................................................15
D. Installation de Kibana ........................................................................................................17
1. Installation ....................................................................................................................17
2. Tableaux de bord Kibana ...............................................................................................18
TROISIEME PARTIE ...................................................................................19
IV. ELK dans la production ........................................................................20
A. Mise en place d’une Centralisation .....................................................................................20
1. Comment utiliser la pile ELK pour la récupération et l'analyse du journal .........................20
2. Besoins exprimés pour la future application ....................................................................37
3. Teste de visualisation des logs d’erreurs via le tableau de bord .........................................37
V. Volet Sécurité : Qu’apporte l’analyse des logs sur le plan sécurité ..........40
1. L’importance de la sécurité de l’accès aux SI de l’entreprise ............................................40
2. Les enjeux d’une analyse des logs de sécurité bien menée ................................................40
3. Analyser les traces des logiciels malveillants grâce aux fichiers de journalisation ..............41
VI. RESULTATS .......................................................................................41
A. Objectifs réalisés...............................................................................................................41
B. Evolutions possibles ..........................................................................................................41
CONCLUSION.............................................................................................42
WEBOGRAPHIE......................................................................................... XI
TABLE DES MATIERE ............................................................................. XII

XIII
PRESENTATION ET UTILISATION DE FAIL2BAN :

Fail2ban est un service simple d'utilisation, configurable et très puissant qui permet de sécuriser votre
serveur. Il permet par exemple de contrer les attaques brute de connexion SSH en bannissant
temporairement une IP ayant effectué un trop grand nombre de tentative de connexion infructueuses.
Lançons l'installation :
Figure : installation fail2ban

Commençons par créer une copie du fichier de configuration en local. Cela a pour but de pouvoir
personnaliser plus facilement la configuration de fail2ban sans toucher au cœur du service :
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Figure : copie du fichier jail

ETAPE N°2 - Configurer Fail2ban
Rentrons maintenant dans le vif du sujet. Ici on va vous montrer comment surveiller les erreurs pour
SSH et Apache, mais sachez que Fail2ban est très complet et permet de surveiller énormément de
services du système.
Allons voir maintenant à quoi ressemble notre fichier de configuration.
Figure : fichier de configuration

Il se peut qu’un jour d’avoir tromper en tapant votre mot de passe lorsque vous vous connectez en
SSH par exemple.
Le paramètre ignoreip permet donc d'ajouter une voir plusieurs IP à la liste blanche de Fail2ban et
ainsi d'éviter aux plus étourdis de se bannir soi-même.

XIV
Maintenant que c'est fait, descendez jusqu'à la partie concernant les jails (prisons). Comme vous
pouvez le constater, une prison est un bloc de 5 lignes concernant un service en particulier
Figure : les jails

Ici donc nous allons gérer la prison SSH, c'est à dire l'authentification à votre serveur. Pour activer
celle-ci, il suffit de passer le paramètre enabled à true. Vous pouvez aussi réduire le nombre de
tentatives avant le blocage de l'IP de l'intrus avec le paramètre maxretry.
Passons maintenant à Apache.
Figure : configuration apache

Là aussi il suffit de changer le paramètre enabled à true pour activer la prison. Pour le port, sauf si
vous avez effectué une configuration particulière d'Apache, vous pouvez laisser tel quel.
ETAPE N°3 - Tester la configuration
Commençons par redémarrer le service pour que notre configuration soit prise en compte
Figure : redémarrage du service

Maintenant nous allons consulter le fichier log de fail2ban pour vérifier que tout est OK :

XV
Figure : fichier log de fail2ban

La commande "tail" que j'ai donné au-dessus reste valable lorsque vous voulez voir si quelqu'un a
tenté récemment de faire n'importe quoi, on obtient alors un résultat comme ceci :
Figure : teste

XVI

Salamatandiayemoussakane 180825230438 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Salamatandiayemoussakane 180825230438 PDF

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE DU SENEGAL

Un Peuple- Un But- Une Foi

MINISTERE de l’ENSEIGNEMENT SUPERIEUR, de la RECHERCHE et de l’INNOVATION

Institut Supérieur d’Enseignement Professionnel de Thiès (ISEP)

Projet Opérationnel (P.O)

Titre du Projet Opérationnel :

La Centralisation des logs dans un serveur

Salamata NDIAYE & Moussa KANE II

Salamata NDIAYE & Moussa KANE III

 C’est avec gratitude que nous dédions ce

 Nous dédions aussi ce travail à nos

Salamata NDIAYE & Moussa KANE IV

 Tout d’abord nous remercions le tout puissant et son

Salamata NDIAYE & Moussa KANE V

LISTE DES FIGURES

Figure 1 : organigramme de l’isep................................................................................................... X

Salamata NDIAYE & Moussa KANE VI

Figure 33 : IP du serveur ...............................................................................................................30

Salamata NDIAYE & Moussa KANE VII

LISTE DES SIGLES ET ABREVIATIONS

ISEP : institut supérieur d’enseignement professionnel

ELK : elasticsearch logstash kibana

APC : approche par compétence

Disep : diplôme d’institut supérieur d’enseignement professionnel

P.O : projet opérationnel

SSI : sécurité des systèmes d’information

IDS : Intrusion Detection System ou système de détection d’intrusion

IPS : Intrusion protection System ou système de protection d’intrusion

API : Application Programming Interface

RAM : random access memory

Salamata NDIAYE & Moussa KANE VIII

Salamata NDIAYE & Moussa KANE IX

Suivi-évaluation Relations extérieures et

Service des Service des Service des Service Service

Figure 1 : organigramme de l’isep

Source : notre responsable de filière

Salamata NDIAYE & Moussa KANE X

Salamata NDIAYE & Moussa KANE

Salamata NDIAYE & Moussa KANE

Plusieurs problèmes se posent :

Comment rechercher les bonnes informations ?

On perd donc un temps précieux à rechercher le bon log au bon endroit.

Salamata NDIAYE & Moussa KANE

C. Centralisation des journaux

La journalisation applicative désigne l'enregistrement chronologique des opérations du logique métier

La journalisation système désigne l'enregistrement chronologique des événements survenant au niveau

Salamata NDIAYE & Moussa KANE

3. Pourquoi l’analyse des journaux devient-elle plus importante

Salamata NDIAYE & Moussa KANE

Salamata NDIAYE & Moussa KANE

Salamata NDIAYE & Moussa KANE

II. Présentation des outils de solution

Salamata NDIAYE & Moussa KANE

Il faut dire que Logstash est désormais bien entouré.

Figure 2 : la pile elk

 Le mode cluster actif/actif natif d’Elasticsearch.

Salamata NDIAYE & Moussa KANE

Figure 3 : Schéma de principe du fonctionnement Logstash

Salamata NDIAYE & Moussa KANE

Salamata NDIAYE & Moussa KANE

C. Pourquoi le choix de ELK

Salamata NDIAYE & Moussa KANE

D. Architecture de la pile ELK