MISE EN PLACE D’UNE SOLUTION DE CENTRALISATION ET D’ANALYSE DES LOGS (SERVEUR SYSLOG)

CAS DU PMUC
 PLAN:

I- Gestion centralisée des logs

II- Etude des différentes solutions SYSLOG

III- Mise en place de la solution choisie: Graylog

IV- Configuration des sources

V- Prise en main
 I- Gestion centralisée des logs

 Un log désigne une notification d’un événement d’une importance plus ou moins élevée envoyée
par un service, un système, un élément réseau ou une application.

 C’est une sorte de journal de bord horodaté de toutes les différentes actions qui ont été effectués
sur sa source.

 Les systèmes d’exploitation, les processus et les applications ont été écrits pour envoyer des
messages de leurs propres états ou pour indiquer que certains événements se sont produits.
Exemple: Logs d’un routeur Mikrotik
• Ces messages peuvent contenir un grand nombre d’informations
pouvant par exemple signaler un danger, ou une activité anormale
au sein du réseau. La complexité grandissante des systèmes
d’exploitation, processus et applications a emmené à la
conception de processus afin de catégoriser ces différents
messages pour permettre au personnel chargé des opérations de
rapidement différencier les notifications concernant les problèmes
à résoudre, des messages simples concernant l’état de la source.

• SYSLOG est l’un de ces processus. le protocole SYSLOG permet

à une machine d’envoyer des logs à travers les réseaux IP vers les
collecteurs de messages événementiels, également connus sous le
nom de serveur Syslog. C’est aussi le nom du format permettant
ces échanges.

• Un journal au format Syslog comporte dans l'ordre les

informations suivantes : la date à laquelle a été émis le log, le
nom de l'équipement ayant généré le log (hostname), une
information sur le processus qui a déclenché cette émission, le
niveau de priorité du log, un identifiant du processus ayant généré
le log et enfin un corps de message.
 Pourquoi Centraliser Les Logs?
Les logs ont un intérêt et une importance cruciale en informatique, car il s’agit là de
savoir ce qu’il s’est passé sur un ensemble d’applications ou systèmes pour pouvoir, par
exemple :
 Expliquer une erreur, un comportement anormal, un crash sur un service comme un
service web
 Retracer la vie d’un utilisateur, d’une application, d’un paquet sur un réseau sur les
logs d’un proxy et des éléments réseau par exemple
 Comprendre le fonctionnement d’une application, d’un protocole, d’un système
 Être notifié d’un comportement, d’une action, d’une modification tel qu’une extinction
ou un démarrage système

Il apparait donc qu’une analyse plus poussée des logs pourrait permettre la résolution
rapide de certains types de problèmes notamment ceux liés à la sécurité. Cependant, afin
d’exploiter les logs, il faudra se connecter unitairement à chacun des équipements ; ce qui
rend la tâche difficile et fastidieuse pour des systèmes d’informations complexes. La
construction d’un « puits de logs » semble donc être une première brique de réponse. Il
s’agira de collecter l’ensemble des journaux d’événements des équipements dans un espace
de stockage unique ; en d’autres termes, effectuer une gestion centralisée des logs.
 Les Atouts D’un Système
de Gestion Des Logs
Les principaux atouts d’un système de gestion des logs sont les suivants :

- La collecte des données de consignation : selon les cas, l’agent récupère les journaux d’événements et se charge de les
transmettre au serveur Syslog
- La conservation rationnelle : cette fonction est essentielle aux systèmes de gestion des logs étant donné le nombre de
réglementations incluant des conditions spécifiques exigeant la conservation des données de consignation, très souvent pendant
plusieurs années.
- La recherche : elle est indispensable pour utiliser les logs à des fins d’enquête, mener des analyses d’expertise et identifier les
défaillances tout en dépannant les applications à l’aide des logs.
- L’indexation et l’analyse des logs : l’indexation permet des recherches cent fois plus rapides. La technologie d’indexation crée
une structure de données appelée un index. Ce dernier permet d’effectuer des recherches très rapides à l’aide de mots-clés ou
d’opérateurs logiques sur l’ensemble du système de stockage des logs.
- Création des rapports standards et planifiés : ces fonctions concernent toutes les données recueillies par le produit de gestion
des logs ; les rapports doivent être créés rapidement, personnalisables et faciles à utiliser à diverses fins.
- Les alertes : Il est important d’avoir la capacité d’émettre des alertes selon des conditions émises sur les données enregistrées.
II- Etude des différentes solutions SYSLOG
III- Implémentation de la
solution choisie
L’objectif de notre travail était de pouvoir centraliser et analyser les
logs provenant de quatre différentes sources notamment :
- Les logs provenant du routeur
- Les logs applicatifs
- Les logs provenant des serveurs (journal d’événements)
- Les logs provenant des bases de données
Pour ce faire, nous avons opté pour le triplet: Graylog – Rsyslog –
NXLog.
Graylog et Rsyslog seront installés sur notre serveur Syslog tandis
que NXLog sera installé au niveau des serveurs dont on veut récupérer
les logs (serveur de bases de données, serveur hébergeant les
applications, …)
Elasticsearch sera chargé de stocker les logs récupérés tandis que
MongoDB va stocker les informations de configuration de Graylog.
Etapes
d’installation de
Graylog
Fonctionnant uniquement sur les systèmes GNU/Linux, Graylog possède deux dépendances
que sont Elasticsearch et MongoDB. Les étapes de sa mise en place sont les suivantes :
- Installation d’une distribution Linux: nous avons choisie Ubuntu 16.04
- Installation de Java 8
- Installation et configuration d’Elasticsearch 5.4
- Installation de MongoDB 3.4
- Installation et configuration de Graylog 2.3.1

Une fois que ces étapes ont été suivies, il est possible d’accéder à l’interface Web de
Graylog à partir de n’importe quel navigateur en saisissant dans la barre de recherche

https://172.18.100.15:9000
Présentation de l’interface web de Graylog :

 Les inputs

Les inputs Graylog sont les parties chargées d’accepter les messages de logs provenant des différentes sources. Ils sont lancés à
partir de l'interface Web ​dans la section System -> Inputs; ils sont lancés et configurés sans avoir besoin de redémarrer une partie du
système.

 Les Streams

Les streams Graylog sont un mécanisme permettant de router les messages en catégories en temps réel pendant leur traitement. O
définit des règles qui indiquent à Graylog quel message router dans quels stream. Un message sera acheminé dans chaque stream dont
toutes les règles (ou certaines de ses règles) correspondent. Cela signifie qu'un message peut faire partie de plusieurs stream et pas
seulement un.

 Les Alertes

Les alertes sont basées sur les streams. On peut définir les conditions qui déclenchent des alertes. Graylog est livré avec des
conditions d’alerte et des notifications d’alerte par défaut pouvant être étendus avec des plugins.
Présentation de l’interface web de Graylog :

 Les Dashboards

L'utilisation de tableaux de bord permet de créer des vues prédéfinies sur les données afin de toujours avoir tout à portée de clic.

 Utilisateurs et rôles

Graylog a un système d'autorisation granulaire qui sécurise l'accès à ses fonctionnalités. Chaque interaction qui peut examiner les données ou
modifier la configuration dans Graylog doit être effectuée en tant qu'utilisateur authentifié. Chaque utilisateur peut avoir différents niveaux d'accès
aux fonctionnalités de Graylog, qui peuvent être contrôlés en attribuant des rôles aux utilisateurs.
 Graylog Collector Sidecar

Il s’agit d’un système de gestion de configuration léger pour différents collecteurs de journaux, également appelé Backends. Le ou les nœuds
Graylog agissent comme un concentrateur centralisé contenant les configurations des collecteurs de journaux. Sur les périphériques / hôtes produisant
des messages, Sidecar peut s'exécuter en tant que service (hôte Windows) ou démon (hôte Linux). Ces configurations sont gérées de manière
centralisée et graphique via l'interface web de Graylog. Lors de sa première exécution, ou lorsqu'un changement de configuration a été détecté,
Sidecar va générer des fichiers de configuration Backend pertinents. Ensuite, il démarrera ou redémarrera ces collecteurs de journaux reconfigurés.
Configuration de base de
Graylog
Les premières configurations à effectuer une fois notre plateforme
Graylog mise en place concernent la création des « inputs » qui vont recevoir
les logs des différentes sources. Pour ce faire on ouvre l’onglet « Inputs »
du menu « System ».

 Input Rsyslog (qui recevra les logs provenant de Rsyslog)

 Sélectionner « Syslog UDP » puis cliquer sur « Launch new

input »
 Renseigner les différents champs et cliquer sur « save »:
 Input NXLog (qui recevra les logs provenant de NXLog)

 Sélectionner « GELF UDP » puis cliquer sur « Launch new

input »
 Renseigner les différents champs et cliquer sur « save »

Une fois que nos Inputs ont été créées, la suite de la procédure
consiste à configurer nos différentes sources afin qu’elles renvoient leurs
logs vers ces inputs.
IV- Configurations des sources
1- Cas du routeur Mikrotik

Le transfert des logs du routeur Mikrotik vers la

plateforme Graylog se fera par l’intermédiaire de l’outil
Rsyslog; c’est un logiciel libre installé par défaut sur des
systèmes d'exploitation de type Unix tels qu’Ubuntu que nous
avons utilisé pour notre projet. Il s’agira premièrement de
configurer Rsyslog afin de permettre deux actions :

- La réception des logs via UDP sur le port 514 : ceci se fait
en effaçant le signe dièse (#) devant les lignes concernées
après l’ouverture du fichier rsyslog.conf

$ sudo nano /etc/rsyslog.conf

- Le transfert des logs via UDP vers la plateforme Graylog en précisant le
port :

Ceci se fait par rajout de la ligne suivante au fichier de configuration de

Rsyslog

*.* @127.0.0.1:5140

Une fois que Rsyslog a été configuré pour permettre ces deux actions,
on redémarre le service Rsyslog et on suit les étapes suivantes:
 Se connecter au routeur à travers l’application Winbox

 Ouvrir la fenêtre « Logging » de l’onglet « System »

 Ajouter une nouvelle action pour désigner notre serveur Syslog

Ici Remote Address = 172.18.100.15

 Ajouter de nouvelles règles avec pour action celle que nous

avons créé pour le serveur Syslog

Les logs du routeur Mikrotik concernant les « accounts » sont

dès lors accessibles via la plateforme Graylog.
2- Cas des serveurs
Le transfert des logs des serveurs fonctionnant sous Windows vers la
plateforme Graylog se fait par l’intermédiaire des outils NXLog et Graylog-
collector-sidecar. Les étapes sont les suivantes :

 Installer Graylog-collector-sidecar sur le serveur dont on veut récupérer

les logs
 Installer NXLog sur le serveur dont on veut récupérer les logs
 Désinstaller le service NXLog et installer le service Graylog-collector-
sidecar à l’aide des commandes suivantes :

C:\Program Files\nxlog\nxlog –u

C:\Program Files\Graylog\collector-sidecar\Graylog-
collector-sidecar.exe –service install

NB: sur certains serveurs Program Files devra être

remplacé par Program Files (x86)

 Ouvrir le dossier d’installation de Graylog-collector-sidecar et modifier le

fichier YML collector_sidecar
 Ouvrir l’interface web de Graylog et aller dans l’onglet « Collector » du menu « System » ; cliquer sur « manage
configurations » puis sur « create new configuration »
 Sélectionner NXLog et configurer une Output et une Input sans oublier les tags comme l’indique les figures suivantes :
 Ouvrir l’invite de commandes en mode administrateur sur le serveur dont on veut
récupérer les logs et entrer la commande

C:\Program Files\Graylog\collector-sidecar\Graylog-
collector-sidecar

 Ouvrir la fenêtre “services” et démarrer les services « Graylog collector

sidecar » et « Graylog collector sidecar – nxlog backend »

On constate que les messages du journal d’événements Windows du serveur

concerné sont bien reçus par Graylog.

3- Cas des SGBD
Pour notre cas d’étude, nous avons travaillé avec SQL Server 2008 qui stocke ses logs d’erreurs dans des fichiers texte ; afin de
les transférer vers Graylog et pouvoir les analyser convenablement, on passe par les mêmes étapes que pour le cas des serveurs
présenté plus haut. La différence intervient au niveau de la configuration des Input et Output.

 Installer Graylog-collector-sidecar sur la machine hébergeant SQL Server

 Installer NXLog sur la machine hébergeant SQL Server
 Désinstaller le service NXLog et installer le service Graylog-collector-sidecar à l’aide des commandes suivantes :

C:\Program Files\nxlog\nxlog –u

C:\Program Files\Graylog\collector-sidecar\Graylog-collector-sidecar.exe –service install

NB: sur certains serveurs Program Files devra être remplacé par Program Files (x86)

 Ouvrir le dossier d’installation de Graylog-collector-sidecar et modifier le fichier YML collector_sidecar comme présenté
précedemment
 Ouvrir l’interface web de Graylog et aller dans l’onglet « Collector » du menu « System » ; cliquer sur « manage
configurations » puis sur « create new configuration »
 Sélectionner NXLog et configurer une Output et une Input sans oublier les tags comme l’indique les figures suivantes
4- Cas des Applications
Les applications stockent leurs logs dans des fichiers textes ; pour la gestion des logs applicatifs, se référer au cas précédent du
SGBD SQL Server et suivre les mêmes étapes.

Après avoir suivi toutes ces étapes on observe que tous les logs provenant de nos diverses sources sont bel et bien transférés vers
Graylog et stockés dans la base de données Elasticsearch. Afin d’optimiser le rendement et l’utilisation de notre serveur Syslog, des
points importants tels que la gestion des alertes, les sauvegardes et les restaurations, ainsi que la gestion de l’espace disque ont été
abordés,
V- Prise En Main
1- Envoi des alertes
L’un des atouts de Graylog réside en sa capacité d’envoyer des alertes par mail lorsque des conditions prédéfinies sont atteintes.
Pour ce faire, la première étape consiste à mettre en place un MTA (Mail Transfert Agent) qui permettra l’envoi d’email ; nous avons
opté pour Postfix car plus rapide, plus facile à administrer et plus sécurisée. Pour notre démo, Postfix a été configuré pour envoyer des
mails avec Gmail. Les étapes suivantes ont donc été suivies :

 Installation des paquets

$ sudo apt-get update

$ sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

Mailutils permet la gestion des courriels par la console, libsasl2-2 est l’implémentation de l’interface de programmation de
Cyrus SASL, ca-certificates contient des fichiers PEM de certificats CA et libsasl2-modules contient des modules
pour le paquet libsasl2-2.

Lors de l’installation, choisir « Site Internet » et mettre ensuite « syslog.server.local »

 Configuration de Postfix

On ouvre le fichier de configuration de Postfix et on le modifie

comme suit :

$ sudo nano /etc/postfix/main.cf

On modifie la ligne relayhost comme suit pour indiquer que nous

utiliserons le SMTP de Gmail :

relayhost = [smtp.gmail.com] :587

Ensuite on rajoute les lignes comme l’indique la figure suivante:

Cela sert à activer l’authentification, à indiquer où se trouve le

fichier sasl_passwd que nous créerons plus tard, à interdire le
mode anonyme, à indiquer où se trouve le certificat, et pour finir à
utiliser le TLS. On enregistre et on quitte.
 Préciser l’adresse Gmail d’où nous voulons que les mails partent

Pour cela il faut créer le fichier sasl_passwd :

$ sudo nano /etc/postfix/sasl_passwd

Dans ce fichier ajouter la ligne suivante :

[smtp.gmail.com]:587 [email protected]:password

Username désigne le nom d’utilisateur gmail.com et password le mot de passe de la boite Gmail. On enregistre et on quitte ; puis
on attribue les droits pour pouvoir utiliser ce fichier :

$ sudo chmod 400 /etc/postfix/sasl_passwd

 Exécuter un Postmap

$ sudo postmap /etc/postfix/sasl_passwd

 Rediriger le certificat vers /etc/postfix/cacert.pem

$ sudo cat /etc/ssl/certs/Equifax_Secure_CA.pem | sudo tee –a /etc/postfix/cacert.pem

 Relancer Postfix pour que tous nos changements soient pris en compte

$ sudo /etc/init.d/postfix reload

 Effectuer un test d’envoi des mails

$ echo “Mail de test de postfix” | mail –s “Test Postfix” [email protected]

Une fois que notre MTA a bien été mis en place, la deuxième étape consiste à modifier la section « Email Transport » du fichier de
configuration de Graylog comme suit:

$ sudo nano /etc/graylog/server/server.conf

Pour notre démo, nous avons utilisé notre compte Gmail.

A ce stade, Graylog est maintenant capable d’envoyer des alertes par mails sur les conditions qu’on aura définies.
 2- Backup/Restauration des logs
Les logs étant stockés dans la base de données Elasticsearch, les processus de backup et de restauration des logs vont être
effectués par les fonctionnalités Snapshot et Restore d’Elasticsearch. Les étapes pour effectuer un backup des logs sont les
suivantes :

 Préciser le répertoire de backup dans le fichier de configuration d’Elasticsearch

$ sudo nano /etc/elasticsearch/elasticsearch.yml

Puis rajouter la ligne:

Path.repo : [“/chemin/vers/répertoire/backup”]

 Redémarrer Elasticsearch et modifier les permissions sur le répertoire de backup de sorte qu’Elasticsearch puisse écrire ses
informations

$ sudo systemctl restart elasticsearch

$ sudo chown –R elasticsearch. /chemin/vers/répertoire/backup

 Elasticsearch doit connaître le chemin de sauvegarde en enregistrant un référentiel de sauvegarde

$ sudo –XPUT ‘localhost :9200/_snapshot/sauvegarde’ –d ‘{“type” : “fs”, “settings” :

{ “location” : “/chemin/vers/répertoire/backup”, “compress” : true } }’

Ici, notre référentiel de sauvegarde est « sauvegarde »

 Effectuer un snapshot de tous les indices présents dans Elasticsearch

$ sudo curl –XPUT “localhost:9200/_snapshot/sauvegarde/snapshot1?wait_for_completion=true”

 Supprimer les indices concernés de la base de données Elasticsearch à partir de l’interface web de Graylog

Pour effectuer une restauration du snapshot:

$ sudo curl –XPOST “localhost:9200/_snapshot/sauvegarde/snapshot1/_restore?

wait_for_completion=true”

Pour avoir une liste des snapshots:

$ sudo curl –XGET ‘localhost:9200/_snapshot/sauvegarde/_all?pretty’

Pour supprimer un snapshot:

$ sudo curl –XDELETE ‘localhost:9200/_snapshot/sauvegarde/NomDuSnapshot’

FIN