Centralisateur de logs: Quartet Gagnant « Graylog – Nxlog – Elasticsearch – MongoDB »

Bonjour,

Aujourd’hui nous allons attaquer un joli morceau à travers une très belle distribution de Linux nommée « CentOS 7 ». Pour les lectrices et les lecteurs qui ne connaissent pas, disons simplement que c’est le petit frère de la distribution Red Hat Enterprise Linux (RHEL). La seule chose qui les différencie c’est le volet « payant », étant donné que RHEL est dédié aux entreprises incluant un support payant. Quant à la distribution « CentOS 7 Linux« , elle profite de tout le développement et les mises à jour apportées par la Team RHEL (Red Hat Enterprise linux), sans le support, et totalement GRATUITE !

L’objectif de cet article sera d’installer un centralisateur de journaux d’événements Windows (logs) sur une machine virtuelle. Comme vous le savez certainement, l’Eventlog de Windows est indigeste et mal adapté pour un utilisateur lambda. Nous verrons progressivement, à travers cet article, comment déployer un serveur GRAYLOG (Centralisateur de journaux d’événements Windows) sous « CentOS 7 Linux » associé au Duo de choc Elasticsearch et MongoDB. Le Trio « Graylog / Elasticsearch / MongoDB » nous permettra de traiter en temps réel toute l’activité d’un ordinateur, notamment grâce à des graphiques en temps réel efficaces, un tableau de bord, des « Dashboards », des techniques de filtrage se nourrissant des logs récupérés de l’Eventlog Windows. Ce dernier est très souvent délaissé voir occulté par son côté anxiogène.

Je vous invite dès à présent à rentrer dans un nouvel univers à l’image de « MATRIX » ! Les logs ont la faculté de transiter par différents canaux et voies numériques, il va dont falloir pénétrer la « Matrice » des logs pour parvenir à nos fins ! Toute intrusion, anomalie ou dysfonctionnement de la « matrice » sera détectée, analysée et traitée grâce au Centralisateur Graylog ! (humour)

GRAYLOG est un outil très puissant de centralisation, d’analyse et d’extraction des logs, pour ne garder que l’essentiel de ses fonctionnalités et de son côté très évolutif. Graylog remplace idéalement le serveur syslog-ng qui collecte les logs de tous vos « serveurs/machines ». Vouloir collecter les logs (Eventlogs) c’est très bien, mais pouvoir les centraliser, les traiter et les analyser c’est encore mieux ! C’est pour cette raison que je vous propose de découvrir dans cet article le Quartet Gagnant « Graylog / Nxlog / Elasticsearch / MongoDB ». Bien que dans cet article j’aborderai succinctement le service dédié « Rsyslog » de la distribution « CentOS 7 », Nxlog permettra de collecter les journaux de systèmes Windows, Unix, Linux, BSD, Android et aussi les logs d’équipements réseau (Firewall physique, contrôleur Wi-Fi, Onduleurs, routeur, commutateur etc.). Dans le cadre de l’installation que j’évoquerai à travers cet article, le service « Rsyslog » aura pour rôle la collecte des logs du serveur « CentOS 7 Linux ». J’ai choisi ici de me concentrer sur l’installation et l’utilisation de ce « Quartet Gagnant » dans un environnement grand public (un ordinateur de bureau tournant sous OS Windows et une plateforme de virtualisation VMWARE WORKSTATION PRO pour les besoins de cette installation sur laquelle tourne un serveur « CentOS 7 Linux« )

Dans cet article, j’ai décidé d’utiliser « VMWARE WORKSTATION 12 PRO » pour virtualiser le Trio « GRAYLOG2/Elasticsearch/MongoDB ». Vous ne connaissez pas VMWARE ? Aucun souci ! Voici le lien d’un de mes articles où je vous invite à installer et à vous familiariser à la version d’essai « VMWARE WORKSTATION 12 PRO » ici

Nous aurons aussi l’occasion de découvrir partiellement la Market Place de Graylog qui offre une grande librairie d’utilitaires très pratique, fonction des besoins et environnements systèmes et réseau de l’utilisateur (Administrateur).

Objectifs de cet article

L’utilisateur lambda sera en mesure:

1. de virtualiser l’installation de la distribution « CentOS 7 Linux »
2. d’installer le Centralisateur de journaux d’événements Windows (logs)  « Graylog« 
3. d’installer un système de gestion de base de données « scalable » orienté documents de type NoSQL appelé « MongoDB« 
4. d’installer le puissant moteur de recherche et d’indexation « Elasticsearch« 
5.  d’installer l’interface (client) Nxlog pour collecter, convertir et renvoyer les Eventlogs de Windows vers le Centralisateur Graylog
6. de configurer le fichier de configuration Nxlog à partir d’un filtre généré via l’Observateur d’Evénements Windows 
7. de se connecter via l’interface Web Graylog  (navigateur internet) à partir de son réseau privé (Box Internet)
8. d’effectuer des recherches précises de logs (journaux d’événements) à partir du Tableau de Bord Graylog-Web
9. d’installer un utilitaire sur le Centralisateur Graylog à partir de la « MarketPlace Graylog » en ligne
10. de sauvegarder des profils adaptés de recherche de logs (journaux d’événements Windows)
11. de créer des Widgets et un « Dashboard » personnalisé pour superviser l’activité de son ordinateur physique (Windows) et son serveur CentOS 7

 

Quelques prérequis à propos de cette installation (à noter que j’ai utilisé un disque dur physique de 1To dédié à cette installation):

1. Mémoire vive de la VM: 4 Go (minimum)
2. Espace alloué au disque dur virtuel: 40 Go (minimum, si vous le souhaitez vous pouvez mettre plus comme moi, ici 600Go sur un disque dur physique dédié)
3. Une interface réseau VMWARE « Bridged » (pont) sur laquelle j’ai attribué une adresse IP statique via ma Box Internet (IP/MAC)
4. Installation du logiciel Putty.exe ici qui servira à nous connecter en SSH (port 22) sur le Centralisateur Graylog via l’adresse IP statique (ici: 192.168.1.55)
5. Interface client (conversion des logs) NxLog à télécharger ici puis l’installer sur la machine physique (Windows)

 

 

Sommaire

I. Virtualisation de l’installation « CentOS 7 Linux »
II.Installation du système de gestion de base données « MongoDB »
III. Installation du moteur de recherche et d’indexation « ELASTICSEARCH »
IV. Installation des Plugins Head et MARVEL (API RestFull)
V. Installation du Serveur GRAYLOG2 (Centralisateur des journaux d’événements Windows)
VI. Installation de l’interface Web Graylog
VII. Connexion via l’interface Web Graylog
VIII. Paramétrage d’un écouteur (Input) sur Graylog
IX. Analyse du trafic
X. Résultat renvoyé par le Tableau de Bord Graylog-Web
XI. Fichier de configuration Nxlog
XII. Fichier de configuration ‘ /etc/rsyslog/ ‘ de CentOS 7 Linux
XIII. Où en sommes-nous ?
XIV. Recherche adaptée à partir de l’interface Web Graylog
XV. Création d’un « Dashboard » Graylog intitulé ici « Graphes des Evénements Windows »
XVI. Découverte de la « Market Place » GRAYLOG

 

I. Virtualisation de l’installation « CentOS 7 Linux »

 

Maintenant que vous avez installé « VMWARE WORKSTATION »  et que vous vous êtes familiarisé avec , commençons par télécharger le DVD ISO de CentOS 7 ici

 

Avant de lancer l’installation du serveur « CentOS 7 », rendez-vous dans les paramètres (Settings) de VMWARE puis sur l’interface réseau « Bridged » et vérifiez qu’elle est bien connectée (connexion au démarrage de la VM)

 

Avant de lancer l’installation du serveur « CentOS 7 », dans les paramètres (Settings) de VMWARE, sélectionnez via l’explorateur de fichier Windows (Browser) le fichier DVD ISO « CentOS 7 » téléchargé précédemment.

 

Démarrez votre votre machine virtuelle (CentOS 7) via « Power On To Firmware » pour atteindre l’utilitaire de configuration du Boot (Bios VMWARE), puis sélectionner un démarrage de la VM sur le CDROM VMWARE (DVD ISO CentOS 7)

 

Votre machine virtuelle vient de démarrer sur le DVD ISO CentOS 7. Vérifiez que les propriétés TCP/IP de la carte réseau soient bien configurées

Sur mon installation j’ai modifié l’adresse IP, la passerelle et le DNS de la carte réseau (voir l’Administration de votre Box Internet pour choisir une adresse IP statique disponible)

 

 

Sélectionnez les outils de débogage durant l’installation minimale de « CentOS 7 »

 

Paramétrez le mot de passe pour l’Administrateur « ROOT », puis créez un nouvel Utilisateur et son mot de passe

 

 

 

!!! ATTENTION !!! NE REDÉMARREZ PAS le serveur « CentOS 7  » (VM), veuillez retourner dans les paramètres de VMWATE (Settings) ET désélectionner (décocher) « Connect at power on », ceci afin d’éviter un redémarrage sur le DVD ISO « CentOS 7 » ! 

 

!!! ATTENTION !!! NE REDÉMARREZ TOUJOURS PAS le serveur « CentOS 7  » (VM), faites un « SHUTDOWN GUEST »

 

Retournez dans la configuration du « Boot » (Bios VMWARE) pour modifier la séquence de démarrage sur le disque dur virtuel où a été faite l’installation de « CentOS 7 »

 

Au terme de la modification de la séquence de démarrage « Boot » (Bios VMWARE), votre machine virtuelle « CentOS 7 » démarre  normalement

 

 

Félicitations ! Vous avez réussi à installer et lancer une machine virtuelle tournant sous « CentOS 7 Linux » !

 

*** NOTE IMPORTANTE: Veuillez dès à présent lancer un « Snapshot » (sauvegarde de votre installation) intitulé: « Fin d’installation CentOS 7 ***

 

Pour des raisons de facilité et autres, nous n’allons pas travailler directement sur la machine virtuelle. Je vous propose de vous y connecter à partir de votre ordinateur (Bureau Windows) à l’aide du petit utilitaire très connu « Putty.exe » (téléchargé précédemment)

 

Débutons par la mise à jour du système « CentOS 7 »

yum update

 

Installation du service NTPD, ça sert à quoi ?

Il peut être utile, voire dans certains cas indispensable, que l’horloge d’un système informatique soit synchronisée avec un temps de référence, ce qui est le cas pour cette installation. Le protocole NTP (Network Time Protocol) permettra d’effectuer cette opération. Voici les lignes de commande à taper, dans Putty (connexion SSH vers le serveur CentOS7 sous VMWARE WORKSTATION PRO) afin d’installer et configurer NTP sur un système Linux :

yum install ntp –y

systemctl enable ntpd

systemctl start ntpd

 

Pour les lectrices et les lecteurs qui n’ont pas l’habitude de ce genre d’installation, voici un exemple d’installation du service NTP sous CentOS 7. La commande ‘yum install ntp -y‘ a permis de télécharger et d’installer les paquets nécessaires à l’installation du service NTP:

 

Pour ceux qui connaissent un peu l’éditeur ‘VI‘, vous pouvez éditer le fichier de configuration pour visualiser les serveurs de temps à utiliser avec la commande:

         vi /etc/ntp.conf

Nous pouvons par exemple utiliser les serveurs de temps du projet pool.ntp.org qui sont accessible à cette adresse http://www.pool.ntp.org/zone/europe :

            server  0.centos.pool.ntp.org

            server  1.centos.pool.ntp.org

            server  2.centos.pool.ntp.org

            server  3.centos.pool.ntp.org

 

Nous utiliserons celui-ci: 0.centos.pool.ntp.org . Pour ce faire arrêtons le service pour le mettre à jour:

 systemctl stop ntpd

ntpdate -u 0.centos.pool.ntp.org

systemctl start ntpd

 

Nous devrons ensuite configurer le service pour qu’il se lance automatiquement à chaque démarrage:

chkconfig ntpd on 

systemctl restart ntpd

Installation des utilitaires « mlocate », « updatedb »  et « net-tools »

Les utilitaires « mlocate », « updatedb » et « net-tools » font partis du hit parade d’outils utiles dans un environnement Linux pour rechercher notamment des fichiers, nous allons donc les installer:

yum install mlocate –y

updatedb

yum install net-tools -y

Configuration de « Selinux »:

SELinux (Security Enhanced Linux) est un système de contrôle d’accès obligatoire (Mandatory Access Control) qui s’appuie sur l’interface Linux Security Modules fournie par le noyau Linux. Concrètement, le noyau interroge SELinux avant chaque appel système pour savoir si le processus est autorisé à effectuer l’opération concernée. Pour cette installation nous avons décidé de modifier Selinux. Pour des raisons de simplification de cette installation, nous avons choisi de le rendre « permissive » au lieu de « enforcing » (par défaut). Dans certains cas il sera nécessaire de le désactiver (disabled). 

Nous allons éditer le fichier de configuration SeLinux, puis rendre « permissive » Selinux:

vi /etc/selinux/config

Installation de Java

L’installation du paquet Java fait partie des prérequis nécessaires à l’installation du serveur GRAYLOG. Il faudra s’assurer que nous avons installé la dernière version de Java. Il est à noter que Java est un paquet délicat à prendre en compte dès maintenant, car il conditionne le bon déroulement de la suite des opérations d’installation (serveur GRAYLOG et ses fonctionnalités ainsi que tout l’environnement MongoDB, Elasticsearch etc.). La version de Java devra être identique et la plus récente, dans le cas où plusieurs serveur GRAYLOG devaient coexister au sein d’une même infrastructure réseau, ceci afin d’éviter un dysfonctionnement des centralisateurs GRAYLOG, voir le « plantage total » ! Lançons au préalable une mise à jour de yum puis installons le paquet Java :

 

yum update

yum install java* –y

java -version

Installation de EPEL et de dépôts complémentaires pour CentOS

Le dépôt EPEL propose des pack d’extensions complémentaires utiles non disponibles depuis les dépôts officiels de CentOS ou Red Hat Enterprise Linux. Les instructions son également inclus pour installer d’autres dépôts secondaires, tels que le Projet Communautaire IUS ou le dépôt Remi RPM. Bien que EPEL propose uniquement des logiciels qui ne sont pas inclus dans les dépôts officiels des éditions Linux CentOS et Red Hat Enterprise, IUS et Remi proposent de nouvelles versions des logiciels (tels que MySQL et PHP) qui sont déjà présents dans les dépôts officiels.

Il est conseillé de réaliser une installation manuelle du dépôt comme suit :

yum install wget -y

wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

rpm -Uvh epel-release-7*.rpm

II.Installation du système de gestion de base données « MongoDB »

Création du fichier de dépôt:

vi /etc/yum.repos.d/mongodb-org-3.0.repo

yum install -y mongodb-org

chkconfig mongod on

systemctl start mongod

systemctl deamon reload

Voici le résultat de sortie du statut de « mongod.service« :

systemctl status mongod

 

Installation des utilitaires Python

yum -y install policycoreutils-python

Configuration de SeLinux pour autoriser MongoDB à démarrer:

semanage port -a -t mongod_port_t -p tcp 27017

service mongod start

chkconfig mongod on

Mise à jour du Système ‘yum update’:

yum update

*** NOTE IMPORTANTE: Veuillez dès à présent lancer un second « Snapshot » intitulé « Mises à jour système, installation Java, EPEL, Python, MongoDB ***

III. Installation du moteur de recherche et d’indexation « ELASTICSEARCH »

Importer la clé et créer le fichier de dépôt Elasticsearch:

rpm –import https://packages.elastic.co/GPG-KEY-elasticsearch

Ici nous allons créer le fichier de dépôt Elasticsearch:

vi /etc/yum.repos.d/elasticsearch.repo

et y insérer les lignes suivantes:

[elasticsearch-1.7]

name=Elasticsearch repository for 1.7.x packages

baseurl=http://packages.elastic.co/elasticsearch/1.7/centos

gpgcheck=1

gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch

enabled=1

Voici le résultat:

Installation de la dernière version d’Elasticsearch:

yum –y install elasticsearch*

Note importante:

Les fichiers de configuration d’Elasticsearch ont été installé ici: /etc/elasticsearch/ 

Les fichiers d’installation d’Elasticsearch  ont été installé ici: /usr/share/elasticsearch/

Voici le résultat au terme de l’installation d’Elasticsearch:

 

Vérification des dépôts disponibles:

Vous pouvez voir si les dépôts dont vous avez besoin sont installés et activés en exécutant la commande suivante :  # yum repolist

Le résultat de sortie devrait ressembler à ceci:

Maintenant rechargeons le « démon« , activons ‘elasticsearch.service‘, redémarrons Elasticsearch et vérifions son Statut:

systemctl daemon-reload

systemctl enable elasticsearch.service

systemctl start elasticsearch.service

systemctl status elasticsearch.service

Nous allons éditer le fichier de configuration Elasticsearch c’est à dire ici  ‘/etc/elasticsearch/elasticsearch.yml‘:

vi /etc/elasticsearch/elasticsearch.yml

Remarque: Dans le cadre de cette installation, nous utiliserons le fichier de configuration installé par Elasticsearch dans ‘ /etc/elasticsearch/elasticsearch.yml ‘ et non celui généré par l’environnement de travail dans ‘ /etc/elasticsearch/elasticsearch-1.7.5/config/elasticsearch.yml ‘

Voici un extrait du fichier de configuration Elasticsearch de cette installation:

 

 

Rechargement du « Démon », activation et redémarrage d’Elasticsearch et vérification de son statut:

Configurer Elasticsearch pour se lancer au démarrage du système :

Activer et charger le tout :

systemctl daemon-reload

systemctl enable elasticsearch

systemctl restart elasticsearch

 

Testons l’accès en localhost sur le port 9200 avec CURL :

Voici le résultat de sortie de la commande:

curl -X GET http://localhost:9200

{

 « status » : 200,

 « name » : « hacker Diki »,

 « cluster_name » : « leblogduhacker »,

 « version » : {

   « number » : « 1.7.5 »,

   « build_hash » : « xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx »,

   « build_timestamp » : « xxxxxxxxxxxxxxxxxx »,

   « build_snapshot » : false,

   « lucene_version » : « 4.10.4 »

 },

 « tagline » : « You Know, for Search »

}

Testons la santé du ‘cluster’ (instance) Elasticsearch:

curl -XGET ‘http://localhost:9200/_cluster/health?pretty=true’

Le résultat de santé du ‘cluster‘ Elasticsearch doit être normalement à l’état « green » (vert):

Nous constatons dans cette installation qu’il n’y a qu’un seul « node » (noeud) et un seul noeud de données, tout va bien !Enfin, pour les plus experts qui souhaiteraient installer plusieurs ‘noeuds’ sur leur instance, faites attention, car il faut être rigoureux et méthodique. Pour ceux et celles qui désireraient avoir un peu plus d’explication sur ces notions de ‘cluster/node/shards/duplicas’, j’y répondrai par commentaire si besoin est.

IV. Installation des Plugins Head et MARVEL (API RestFull)

Avant d’installer ces deux plugins, rendons-nous dans le bon répertoire des fichiers de configuration Elasticsearch:

cd /usr/share/elasticsearch/

Ces Plugins vont nous permettre d’accéder et de communiquer avec Elasticsearch via un navigateur internet à l’adresse : http://adresse_IP_Serveur:9200/_plugin/head  et http://adresse_IP_Serveur:9200/_plugin/marvel  à l’aide d’un navigateur internet:

./bin/plugin -install mobz/elasticsearch-head

./bin/plugin -i elasticsearch/marvel/latest

systemctl restart elasticsearch

./bin/elasticsearch -f

Deux autres plugins sont nécessaires. Installons-les toujours au même endroit : 

cd /usr/share/elasticsearch/

« Mapper Attachment Type » pour ElasticSearch =>  https://github.com/elasticsearch/elasticsearch-mapper-attachments

« ICU Analysis pour Elasticsearch » =>  https://github.com/elasticsearch/elasticsearch-analysis-icu

Vous pouvez les installer en utilisant ces deux commandes :

bin/plugin -install elasticsearch/elasticsearch-mapper-attachments/2.5.0
bin/plugin -install elasticsearch/elasticsearch-analysis-icu/2.5.0

Remarque: Ici j’ai souhaité vous faire découvrir ces deux plugins, mais un seul suffit. Généralement le plugin ‘HEAD’ est le plus adapté pour ce genre d’installation.

Avant d’ouvrir votre navigateur internet pour se connecter à l’API HTTP ‘HEAD‘ et « MARVEL » d’Elasticsearch, je vous propose maintenant de redémarrer le serveur CentOS 7 pour prendre en compte l’installation des plugins (Normalement nous aurions du arrêter le « noeud » pour installer les plugins. Je préfère simplifier):

reboot

Pour accéder à Elasticsearch via le navigateur internet, c’est très simple, saisissez l’URL suivante:

http://’adresse-Ip-server’:9200/_plugin/marvel  ( http://’adresse-Ip-server’:9200/_plugin/head)

Connexion via l’API REST HTTP ‘HEAD’ Elasticsearch

 Connexion via l’API REST HTTP ‘MARVEL’ Elasticsearch

Dans la mesure où l’objectif de cette installation est orienté exclusivement vers une utilisation du moteur de recherche Elasticsearch relativement simple, il est inutile ici de rentrer dans le détail des fonctionnalités du moteur Elasticsearch. L’utilisateur n’aura besoin que de l’interface Web Graylog pour administrer ses journaux d’événements Windows.

Note importante: refaite un petit ‘snapshot’ ça ne mange pas de pain et il peut être d’un grand secours pour la suite de cette installation.

PROBLÈME DE ‘CLUSTER’: état de santé au « jaune »:

En cas de problème dans votre ‘cluster’ il se pourrait, que pour différentes raisons « obscures » que seule la raison pourrait expliquer, l’état de santé de votre ‘cluster » soit « jaune » par exemple.  Sans rentrer dans les détails, si votre ‘cluster » a la « jaunisse » ce n’est pas normal. Voici la protocole médical à suivre, c’est très simple:

La première commande va demander via le port d’écoute 9200 d’Elasticsearch de rechercher dans le dossier ‘shards’ tous les ‘shards’ et ‘index’ non assignés, et de nous les retourner:

 curl -s http://’adresse_IP_serveur’:9200/_cat/shards | grep UNASS

La deuxième commande (pour faire simple) va supprimer les ‘shards non assignés (à effectuer un par un pour chaque ‘shards’). La suivante va modifier le nombre de ‘replicas’ à la valeur ‘0’ (zéro). Pourquoi ? C’est du au fait qu’un ‘shard’ a besoin d’un autre ‘node’ (noeud) disponible pour lui tout seul, afin qu’il puisse se positionner dans ce ‘node’, pour ensuite appliquer un ‘réplicas’ à ce ‘shard’. Un ‘shard’ et un ‘replicas’ ne peuvent pas cohabiter dans le même « node ». En d’autre terme, si l’état de santé de votre ‘cluster’ est « jaune », cela signifie que vous avez probablement mal configuré le fichier de configuration /etc/elasticsearch/elasticsearch.yml’ et accidentellement créé plusieurs « nodes ». Je vous rappelle au passage que cette installation évolue autour d’un seul « noeud maître » (master node), un seul « Shard » et aucun « replicat ». Pourquoi ? Simplement parce que notre unique « node » est conçu nativement pour effectuer à lui seul toutes les opérations nécessaires (du Node, du Shard et du replicat etc. à travers une Instance unique, le « Cluster ») Au pire, vous vous êtes trompé quelque part dans l’installation…, ‘snapshot back’ ! (sourire) :

(commande à faire pour chaque ‘shards’ non assigné, ici: ‘ .marvel-1016.04.04, 03, 02, 01 ‘ etc )

 curl -XDELETE http://’adresse_IP-server’:9200/’non_du_shard’   

(ici: 192.168.1.55)

curl -XPUT http://192.168.1.55:9200/_settings -d ‘{« number_of_replicas » :0}’

 

La troisième commande va vérifier qu’il n’y ait plus de « shards’ non assignés (la même que la première):

 curl -s http://’adresse_IP_serveur’:9200/_cat/shards | grep UNASS

Les deux dernières commandes vont tout simplement redémarrer le service ‘elasticsearch‘ et « graylog-server‘:

systemctl restart elasticsearch

systemctl restart graylog-server

Remarque: Cette opération est susceptible de demander un certain délai avant que « Elasticsearch » puisse recouvrer tous ses moyens. Soyez patient ! (humour) Au fait, pour ceux dont leur « cluster » à la « rougeole » (état de santé « rouge), ça risque d’être compliqué!  

V. Installation du Serveur GRAYLOG2 (Centralisateur des journaux d’événements Windows)

Création du dépôt:

rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-1.2-repository-el7_latest.rpm

Installation de la dernière version du serveur GRAYLOG:

yum -y install graylog-server*

Voici le résultat que vous devriez obtenir:

Installation du générateur de mot de passe utilisateurs Graylog et création du mot de passe utilisateur Graylog:  ‘/etc/graylog/server/server.conf’

yum install -y pwgen

Génération d’un mot de passe sécurisé pour Graylog à copier ensuite dans son fichier de configuration ‘

pwgen -N 1 -s 96

Pour que ce soit plus pratique, je vous propose de copier dans un bloc note le premier mot de passe sécurisé ci-dessus (le votre !).

Toujours dans le fichier de configuration  ‘vi /etc/graylog/server/server.conf ‘  créons notre mot de passe utilisateur (ici ‘123456‘) Graylog que nous allons copier à nouveau dans le bloc note avec le précédent:

root_password_sha2

Editer le fichier de configuration Graylog et copier les deux mots de passe:

vi /etc/graylog/server/server.conf

Voici le résultat que vous devrez obtenir (attention les mots de passe dans cet exemple ne sont pas à copier !) dans votre fichier de configuration ‘server.conf’:

Note importante: Le nom du noeud configuré dans le fichier de configuration Graylog ci-dessus (ici « Hacker-Diki ») doit-être IDENTIQUE à celui précédemment défini dans le fichier de configuration Elasticsearch !

VI. Installation de l’interface Web Graylog

yum -y install graylog-web

Edition du fichier de configuration ‘/etc/graylog/web/web.conf ‘:

vi /etc/graylog/web/web.conf

Relancer l’interface Web Graylog:

systemctl restart graylog-web

L’interface est configurée pour écouter le port 9000, il faut donc paramétrer le Firewall pour autoriser le trafic sur ce port (9000):

firewall-cmd –permanent –zone=public –add-port=9000/tcp

firewall-cmd –reload

Ouverture du navigateur pour se connecter à l’adresse IP sur server Graylog (ici 192.168.1.55:9000) en utilisant l’identifiant par défaut « admin » et notre mot de passe (ici 123456) configuré dans le fichier de configuration

Vérification du démarrage du serveur Graylog (Centralisateur de journaux d’événements Windows)

tail -f /var/log/graylog-server/server.log

VII. Connexion via l’interface Web Graylog

Saisissez l’identifiant par défaut ‘admin‘ et votre mot de passe que vous avez généré plus haut (ici 123456)

 

*** NOTE IMPORTANTE: Veuillez dès à présent lancer un troisième « Snapshot » intitulé « Installation Elasticsearch, Graylog Server/Web » ***

Message de mise à jour du Serveur Graylog et de l’Interface « Graylog-Web »

L’Administration Graylog-Web est particulièrement performante puisqu’elle alerte l’utilisateur (Administrateur) de tout événement important lié, notamment ici, à une mise à jour du serveur Graylog et de son interface Web:

 

Voici les commandes fournies par le message de mise à jour Graylog:

rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-1.3-repository-el7_latest.rpm

yum install graylog-server graylog-web

systemctl restart graylog-server

systemctl start graylog-web

Comportement de GRAYLOG lors d’une anomalie

Je vous propose de créer une anomalie volontaire pour tester le comportement du serveur GRAYLOG. Voyons comment Graylog va réagir si je lui retire le « Master Node ». Nous savons que le serveur Graylog a besoin d’un noeud maître (master node) pour fonctionner correctement. Je vais donc modifier la 3ème ligne de son fichier de configuration (/etc/graylog/server/server.conf ) par défaut comme suit «  is_master = true  » en  » is_master = false « , voici la conséquence:

L’interface Web Graylog communique efficacement lorsqu’il y a une anomalie ou un dysfonctionnement. Il est donc impératif de bien lire tous les messages (notifications) que Graylog nous renvoie !

VIII. Paramétrage d’un écouteur (Input) sur Graylog

Configuration d’un écouteur (Input Syslog UDP port 1514 et TCP port 1614) via Graylog-Web:

A ce stade de l’installation, nous allons réaliser un premier test en paramétrant un écouteur (Input) sur Graylog pour voir un peu ce qui se passe. Le résultat ne sera pas probant, mais il permettra de vous donner un aperçu rapide de cet outil phare GRAYLOG. Nous verrons plus tard comment configurer et optimiser les journaux d’événements Windows et les rendre explicites et plus parlant J’ai choisi ici d’écouter l’IP 192.168.1.31 de ma machine physique (HOST 127.0.0.1). Je vous propose de découvrir ci-dessous la première heure d’activité de l’adresse IP 192.168.1.31 qui correspond à ma machine physique (HOST). Vous remarquerez que ma machine physique est faignante ! C’est normal, puisque je travaille principalement avec des machines virtuelles « bridgées ».

A ce stade, évidemment, on ne comprend rien, c’est normal puisque ce résultat n’est pas très probant…, pour l’instant ! Il va nous falloir vérifier le trafic  transmis par notre machine.

IX. Analyse du trafic

De quoi avons-nous besoin pour comprendre ?

1. Analyser le trafic transmis par une machine: utilitaire ‘tcpdump‘ à installer sur le serveur CentOS 7 => yum install -y tcpdump
2. Scanner et identifier les adresses IP et les ports ouverts et fermés d’une machine: utilitaire ‘nmap‘ à installer sur le serveur CentOS 7 => yum install – nmap
3. un client de log à installer sur la machine serveur CentOS 7: démon ‘Rsyslog‘ => yum install -y rsyslog*
4. un client de log à installer sur la machine à superviser ici « Windows 8.1 Pro » (la mienne): ‘Nxlog‘ => Télécharger ici Nxlog

 

Commençons par vérifier le trafic de ma machine (CentOS 7 Graylog) à l’adresse IP  192.168.1.55 sur les ports UDP ou ICMP (icmp sert au retour code erreur si erreur il y a) de ma carte réseau (‘bridged’) intitulée ‘eno16777736′. Pour connaître le nom de la carte réseau de votre serveur « CentOS 7 / Graylog »,  tapez simplement la commande

ifconfig

puis:

 tcpdump -i eno16777736 udp or icmp

Voici un exemple de résultat de sortie:

Vous constaterez qu’il y a quelques ports ouverts (UDP) qui échangent du trafic via le DNS Google, normal. En revanche, sur « CentOS 7 » par défaut tous les ports d’entrée sont fermés et tous les ports de sortie sont ouverts. Le port qui nous intéresse en priorité est le port 514 UDP qui est fermé puisque vous ne devriez pas le voir dans votre résultat de sortie ‘tcpdump’ juste après. Vous verrez peut-être une ou plusieurs adresses IP (internes) qui vous sembleront étranges. Si comme moi vous avez par exemple un décodeur TV dans votre réseau privé, alors vous devriez voir son adresse IP (attribuée par votre Box Internet) échanger du trafic avec le serveur « CentOS 7 ».

 Vérifions par exemple si le port UDP 514 écoute avec la commande:

 netstat -antup | grep 514

Visiblement il n’y a sur mon serveur que le port 5144 UDP qui écoute ! Normal.

Scannons avec la commande ‘nmap‘ tous les ports UDP de mon serveur CentOS 7 ici 192.168.1.55 :

nmap -sU 192.168.1.55

De nouveau nous constatons qu’il n’y a que le port 123 UDP dédié au service d’horloge NTP d’ouvert ! 

Nous arrivons sur un sujet épineux, celui du pare feu ‘Firewalld’ de la distribution CentOS 7. Pour des raisons de simplicité, nous allons devoir utiliser une autre version de Firewall connue sous le nom de « iptables« . Pourquoi ? Réponse brève:

Comme vous le constatez, j’ai testé le port 514 UDP via telnet en ouvrant de façon permanente sur le Firewall CentOS 7 le port 514, la connexion m’a été refusé. 

Il est à noter que tous les ports inférieurs à 1024 sont réservés, nous devrons donc rediriger le trafic vers d’autres ports du style: ‘port 1514 UDP’ et ‘port 1614 TCP’ pour plus de précaution… par le biais des fichiers de configuration (Rsyslog et Nxlog)que nous verrons plus tard.

Pour ceux et celles qui ont l’habitude de travailler avec le service ‘ iptables’, vous pouvez bien évidemment l’utiliser à la place du service ‘firewalld’. Ce dernier est aujourd’hui son remplaçant. Dans le cadre de cette installation nosu utiliserons exclusivement ‘firewalld’ qui est par défaut installé sur « CentOS 7 »

FACULTATIF: Désactivation et arrêt du service ‘Firewalld‘, installation du service ‘iptables‘, chargement à chaque démarrage du service ‘iptables‘ et démarrage ‘iptables‘:

systemctl stop firewalld

yum – y install iptables-services

systemctl enable iptables

systemctl start iptables

Systemctl start firewalld

X. Résultat renvoyé par le Tableau de Bord Graylog-Web

Après avoir configurer les fichiers de configuration Rsyslog (‘ vi /etc/rsyslog.conf ‘ ) et Nxlog (sur la machine Windows HOST ‘ nxlog.conf ‘), je vous dévoile enfin quelques résultats renvoyés par le Tableau de Bord du Centralisateur Graylog. Rassurez-vous nous évoquerons Rsyslog et Nxlog après.

Tableau de Bord de l’activité du Serveur CentOS 7 (ici 192.168.1.55) et de la machine HOST (ici 192.168.1.31)

Tableau de Bord de l’activité du serveur « CentOS 7 » (extrait coloré en jaune: ouverture d’une connexion SSH via Putty vers CentOS 7)

Modulation de l’activité du serveur CentOS 7 (192.168.1.55) et de la machine HOST (192.168.1.31)

Tableau de bord des journaux d’événements Windows (HOST)

Ici je vais volontairement supprimer l’application « Skype » de mon ordinateur pour voir le retour de Graylog sur son Tableau de bord, puis je la réinstallerai.

Suppression de l’application « SKYPE » sur mon ordinateur (HOST Windows), centralisée par Graylog (coloré en jaune ci-dessous)

Réinstallation de l’application « Skype » sur mon ordinateur (HOST Windows), centralisé par Graylog (coloré en jaune ci-dessous)

XI. Fichier de configuration Nxlog

Maintenant nous allons aborder les interfaces Nxlog (Windows) et Rsyslog (CentOS 7 Linux). Effectivement, pour que le Centralisateur Graylog puisse centraliser les logs en provenance du Serveur « CentOS 7 » et des Eventlogs de Windows (machine physique), il nous faut configurer quelques éléments d’information sur leur fichier de configuration.

Débutons par Nxlog

Nous n’allons pas rentrer dans le détail du fichier de configuration Nxlog , mais sachez que c’est ici que nous définissons le comportement du Client Nxlog (Windows) pour collecter les Eventlogs Windows qui seront ensuite convertis au format de communication « Syslog » (Standard) et « GELF » (Graylog) et finalement renvoyés vers le Centralisateur Graylog. Nxlog va simplement utiliser des modules prédéfinis, en l’occurrence « xm_syslog« , « im_msvistalog » et « xm_gelf » qui vont permettre aux entrées « input » de traiter les logs (journaux d’événements Windows) en provenance de la machine physique HOST (ici: 192.168.1.31) au bon format de communication qui seront ensuite convertis (logs) via les sorties (« out« ) qui indiqueront quelle « route » (chemin) suivre pour être finalement centralisés par Graylog . Un processus en informatique suit toujours la même séquence de traitement suivante: « Entrée » => « Processus » => « Sortie ».

De quels événements Windows avons-nous besoin ?

L’idée ici est de générer le bon script d’événements Windows grâce à l’observateur d’événements Windows. Nous n’aurons ainsi plus qu’à copier/coller ce script dans le fichier de configuration Nxlog. Pour ce faire, rendez-vous dans « Panneau de Configuration / Outils d’administration / Observateur d’événements« , cliquez droit sur « Observateur d’événements / Créer une vue personnalisée« , dans l’onglet « Filtrer » section « Journal » sélectionnez les critères des journaux d’événements Windows que vous souhaitez générer (ici: Application, Sécurité, Installation, Système). Validez le nom de votre nouvelle vue puis rendez-vous dans l’onglet « XML » pour copier et coller le script (filtre) dont vous avez besoin dans le fichier de configuration ‘ Nxlog.conf ‘.

Note importante: avant d’apporter toute modification sur le fichier de configuration ‘ nxlog.conf ‘, il est nécessaire de stopper  préalablement le service ‘nxlog’. Pour ce faire ouvrir un invite de commande Windows (touches clavier: « WINDOWS » + « R », tapez ‘ cmd ‘ puis « OK ») et saisissez les commandes suivantes:

cd/

cd « Program Files (x86) »

cd nxlog

net stop nxlog

Il ne vous reste plus qu’à répercuter le script généré ci-dessus (le votre!) dans le fichier de configuration Nxlog (ci-dessous), plus exactement dans l’entrée intitulée ‘ in ‘ par défaut dédiée au format « Syslog » tout en préservant la syntaxe et la structure initiale du fichier ‘nxlog.conf ‘. L’entrée intitulée ici ‘ ingelf ‘ sera dédiée au format « GELF » de Graylog. Les sorties (‘ out ‘ par défaut) seront définies dans cet exemple avec ‘ out1 ‘, ‘ out2 ‘ ‘outgelf ‘ pour les besoins de cet article uniquement. La ‘ route ‘ sera donc pour cet extrait:

in  =>  out1,  out2,  outgelf‘

Localisation du fichier de configuration ‘ nxlog.conf ‘:  C:Program Files (x86)nxlogconfnxlog.conf

Nxlog traitera donc les « EventLogs Windows » au format « Syslog » (UDP et/ou TCP) et au format « GELF » de Graylog (UDP et/ou TCP).

XII. Fichier de configuration ‘ /etc/rsyslog/ ‘ de CentOS 7 Linux

vi /etc/rsyslog.conf 

Le principe de fonctionnement du fichier de configuration Rsyslog est le même que celui de Nxlog. Celui que je vous propose de découvrir ci-dessous est un générique qui pourra bien évidemment s’adapter en fonction de votre besoin, objectif et environnement. Les lignes 9,10, 11, 12, 15 et 19 chargent les modules nécessaires à Rsyslog pour traiter les logs (messages). Il existe d’autres modules que nous évoquerons pas dans cet article. L’idée ici est de demander à Rsyslog d’activer son serveur pour recevoir tout le trafic UDP sur le port 514 et tout le trafic TCP sur le même port 514. Généralement, l’Administrateur choisira un seul protocole de communication soit UDP ou soit TCP. Moi j’ai décidé de faire autrement pour les besoins de cet article. Pourquoi ? Je vais tout simplement demander à Rsyslog de SEGMENTER le trafic UDP et TCP et de le REDIRIGER vers deux autres ports d’écoute du serveur GRAYLOG (plus bas). Nous voyons ensuite un exemple de « template » intitulé ici « FILENAME ». Ensuite Rsyslog a besoin de connaître les chemins où devront être stockés les logs (messages) par catégorie. En fonction du besoin, l’Administrateur pourra poster des chemins spécifiques. Les lignes 95 et 96 sont IMPORTANTES puisqu’elles vont permettre de REDIRIGER tous logs du serveur ‘CentOS 7’ au format UDP et TCP à partir du serveur Rsyslog vers le serveur Graylog (Centralisateur de Logs) comme suit:

Trafic UDP:  @192.168.1.55:1514   (vers le port 1514 écouté par Graylog – un arobas ‘@’ indique que c’est UDP)

Trafic TCP:  @@192.168.1.55:1614 (vers le port 1614 écouté par Graylog – deux arobas ‘@@’ indique que c’est TCP)

Rsyslog traitera donc les logs en provenance du serveur CentOS 7 au format de communication « Syslog » avec soit le protocole TCP et/ou UDP. Dans l’exemple de mon installation, j’ai volontairement appliqué TCP et UDP pour vous montrer le principe de configuration. Généralement nous n’avons besoin que d’un seul protocole de communication soit TCP ou bien UDP. Sachez que les logs d’équipements réseau notamment sont transmis en UDP qui est un format approprié car leurs logs (routeur, commutateur, contrôleur Wi-Fi…) génèrent peu d’information au contraire du format de communication GELF de Graylog qui est beaucoup plus riche et mieux adapté au traitement des Eventlogs de Windows.

Vérification de la zone active, activation des services ‘HTTP’/’HTTPS’ et activation des ports nécessaires via le service ‘firewalld’:

Sans rentrer dans une explication détaillée du service ‘firewalld‘ de CentOS 7, nous allons ici simplement vérifier la zone active du réseau (carte réseau ici ‘eno16777736’), activer les services de base (HTTP, HTTPS) et ouvrir les ports nécessaires sur cette zone active qui sont pour cette installation: 9000, 9200, 9300, 9350, 514, 1514, 1614, 1714, 5414. Par défaut, le service  ‘firewalld’ de CentOS 7 FERME tous les ports entrants et OUVRE tous les ports de sortie. Voici les commandes à utiliser par ordre chronologique. Pour des raisons de simplification et de réduction du contenu de cet article, je poste ci-après les commandes génériques utilisées pour gérer le service « firewalld »:

firewall-cmd –state
firewall-cmd –get-default-zone
firewall-cmd –get-active-zones
firewall-cmd –list-all
firewall-cmd –zone=public –list-all
firewall-cmd –zone=public –change-interface=eno16777736
systemctl restart firewalld.service
firewall-cmd –get-active-zones

firewall-cmd –zone=public –permanent –add-service=http

firewall-cmd –zone=public –permanent –add-service=https

firewall-cmd –permanent –zone=public –add-port=514/udp

firewall-cmd –permanent –zone=public –add-port=1614/tcp

firewall-cmd –permanent –zone=public –add-port=1714/udp

firewall-cmd –permanent –zone=public –add-port=5414/udp

firewall-cmd –permanent –zone=public –add-port=9000/tcp

firewall-cmd –permanent –zone=public –add-port=9200/tcp

firewall-cmd –permanent –zone=public –add-port=9300/tcp

firewall-cmd –permanent –zone=public –add-port=9300/tcp

firewall-cmd –permanent –zone=public –add-port=9350/tcp

firewall-cmd –reload

firewall-cmd –list-ports

XIII. Où en sommes-nous ?

La question que tout le monde se pose à cet instant crucial est: « Oui mais bon ! Ca va donner quoi comme résultat !?! « . Voici un exemple de « Dashboard Graylog » que j’ai créé pour l’occasion et qui va nous donner un tout petit aperçu DE LA PUISSANCE DU QUARTET GAGNANT !

Comme nous l’avons vu précédemment, c’est bien beau d’avoir des journaux d’événements Windows (logs) centralisés, mais l’idéal évidemment serait de pouvoir les VISUALISER EN TEMPS RÉEL sur un tableau de bord personnalisé (Dashboard) adapté aux besoins de l’Administrateur de cette installation. Vous vous doutez bien que je ne pourrais pas évoquer les milliards de possibilités qu’offre ce Quartet Gagnant. C’est pour cette raison que je vais focaliser mon action sur les points suivants:

1. Recherche adaptée à partir de l’interface Web Graylog »
2. Sauvegarde des recherches « Graylog-Web »
3. Ajout des recherches sur un « Dashboard » Graylog intitulé ici « Graphes des Evénements Windows« 
4. Visualisation du « Dashboard » Graylog intitulé ici « Graphes des Evénements Windows »

 

XIV. Recherche adaptée à partir de l’interface Web Graylog

Ici nous allons créer un profil de recherche à l’aide des mots clés ‘ modification ‘ ET (AND) ‘ ‘ application ‘. ‘ AND ‘ sera l’opérateur logique utilisé par le moteur de recherche et d’indexation Elasticsearch pour trouver tous les événements Windows faisant référence aux mots clés ‘ modification ‘ ET ‘ application‘. Graylog va donc d’une certaine façon « FILTRER » le résultat des logs en fonction de ce nouveau critère de recherche créé. ATTENTION, je viens de parler de « filtres », sachez que les filtrage et le découpage (parsing) sont des fonctionnalités beaucoup plus sophistiquées et puissantes que nous n’aborderons pas dans cet article pour des raisons évidentes. 

Il existe plusieurs façon d’effectuer une recherche via Graylog. La plus pratiquée utilise les opérateurs logiques ‘AND‘ ou ‘OR‘ que l’on peut combiné. Dans l’exemple ci-dessous je recherche dans les événements les expressions « modification » ET « application » qui se traduit par ‘ modification AND application ‘ sur le champ de recherche Graylog:

 

A ce stade, nous avons sauvegardé un profil de recherche intitulé « Modification application Windows ».

 

XV. Création d’un « Dashboard » Graylog intitulé ici « Graphes des Evénements Windows »

A partir de l’onglet « Dashboards » visible sur l’interface Web Graylog, nous allons pouvoir créer un nouveau « Dashboard » personnalisé intitulé ici « Graphes des Evénements Windows » dans lequel nous pourrons ajouter nos profils de recherche créés précédemment, en cliquant sur l’onglet « Add count to dashboard »

 

Visualisation du « Dashboard » via Graylog intitulé ici « Graphes des Evénements Windows »

Comme vous pourrez le constater, le « Widget » que nous venons de créer « Modification application » apparaît bien sur notre « Dashboard« . Maintenant, vous l’aurez compris, il suffit d’appliquer cette méthode pour les autres « Widgets » dont vous aurez besoin. Pour les besoins de cette installation j’ai créé les « Widgets » en utilisant les mots clés de recherche suivants:

service AND application

modification AND antivirus

modification AND processus

modification AND système

service AND installé

source AND ‘adresse IP ou HOSTNAME’  

(ici j’ai mis ‘ source AND 192.168.1.31  » l’adresse IP de ma machine physique)

 

Il est clair que vous pouvez adapter vos mots clés de recherche à votre convenance pour créer vos propres Widgets sur votre Dashboard.

L’intérêt de ce « Dashboard » est qu’il nous donne en temps réel un état de l’activité de l’environnement matériel et logiciel. Si vous disposez de plusieurs ordinateurs en réseau local chez vous, vous aurez une vue rapide des points clés de l’activité de vos machines. Prenons l’exemple de mon Widget nommé  » Services installés Windows » (mots clés de recherche utilités: ‘ service AND installé ‘). Si je souhaite visualiser le détail de ces 3 services récemment installés, il me suffit simplement de cliquer sur l’icône de la petite flèche (violette) pour obtenir ceci:

Le Centralisateur Graylog m’informe que ceux sont les services « Skype« , « Skype Updater » et « Nxlog » qui ont été installé sur ma machine. Cool! Si je souhaite vérifier plus en profondeur quelles sont les interactions générées par l’installation de ces 3 services, il me suffit de visiter le Widget intitulé « Modification application Windows« :

Ci-dessus je vous montre seulement trois exemples de logs sur un total de 19, mais il y a notamment mon antivirus Avira qui a réagit à ces installations. 

 

Prenons un autre exemple de recherche avec les mots clés ‘ échec AND installation ‘, voici le résultat renvoyé par Graylog. Ce dernier m’informe que durant les 8 dernières heures mon système Windows a subi deux échecs d’installation liés à l’Agent de mise à jour automatique « Windows Update »:

 

*** NOTE IMPORTANTE: Veuillez dès à présent lancer un quatrième « Snapshot » intitulé « Configuration Nxlog, Rsyslog, Firewall, écouteurs, recherches et Dashboard » ***

 

XVI. Découverte de la « Market Place » GRAYLOG

Je vous invite à découvrir comment exploiter la « Market Place » de Graylog. Nous allons ici récupérer et installer le contenu du « Pack Graylog » intitulé: « 

Active Directory Auditing (NXLOG)

Copie du contenu « Pack Active Directory Auditing Nxlog » dans un fichier texte (via Notepad++)

Sélection et application du contenu (copie fichier via Notepad++) « Pack Active Directory Auditing Nxlog » » dans GRAYLOG:

Le but dans cet exemple sera uniquement de vous expliquer comment intégrer un Pack (contenu) via la Marketplace de Graylog à travers votre serveur Graylog (interface Wrylog-Web). Il existe certains Packs qui se téléchargent automatiquement via le tableau de bord Graylog-Web. La plupart du temps, lorsqu’il s’agit de « code » spécifique à un type d’application, vous adopterez donc cette méthode « manuelle » d’installation d’un Pack (Content Pack Marketplace Graylog)

C’est presque terminé ! Pour des raisons de stabilisation de cette installation, il est préférable de lancer une dernière mise à jour du système CentOS 7, comme suit:

yum update

Remarque: Cette dernière mise à jour risque d’être relativement longue. Il se peut que vous ayez un message d’erreur par exemple sur un paquet spécifique à Elasticseach, n’en tenez pas compte. Au terme de ces mises à jour, effectuez un dernière « snapshot » intitulé « Installation et configuration finalisées, mises à jour MongoDB et Système effectués« 

Félicitations ! L’installation est terminée ! 

Conclusion

Nous avons donc réussi à mettre au point un Centralisateur de journaux d’événements Windows très performant qui retrace toute l’activité d’une ou plusieurs machines installées sur un réseau privé (Box Internet), grâce à des outils efficaces et des fonctionnalités conviviales adaptées au besoin de l’Administrateur !

Conscient de ne pas pouvoir traiter la totalité des fonctionnalités et outils de cette solution, l’objectif de cet article a finalement été atteint. L’utilisateur (Administrateur) dispose donc d’une base de centralisation de ses journaux d’événements Windows, facilement exploitable par le biais de l’interface Web Graylog. L’administration Graylog-Web permet ainsi de nombreuses configurations adaptées aux besoins de l’utilisateur. La sécurisation des journaux d’événements grâce au Centralisateur Graylog assure à l’utilisateur une protection optimale de ses logs en cas de « piratage » de son ordinateur et d’effacement frauduleux de ses journaux d’événements en local. L’utilisateur aura toujours la possibilité de consulter, d’analyser et rechercher toute anomalie ou trace d’intrusion dans son système, grâce à cette solution de centralisation des logs.

Pour les plus experts d’entre vous qui sont équipés notamment d’un routeur/modem dédié ou un contrôleur Wi-Fi ou un serveur Web sur leur réseau privé, il est possible de centraliser les logs de tout vos équipements réseau.

J’invite tous les lecteurs et les lectrices à me solliciter pour de plus amples informations dans l’éventualité où vous seriez confrontés à un souci durant cette installation.

Prochainement, je publierai un e-book qui reprendra le contenu de cet article de façon plus détaillée, avec des compléments d’information plus poussés notamment sur le filtrage, découpage (parsing, Grok Pattern) des logs, l’administration et l’utilisation des plugins « HAED » et « MARVEL », la configuration et l’exploitation de l’utilitaire Graylog « Active Directory, Windows, Operatig Systems, Security » , l’installation et l’administration de Kibana…

Dans l’attente de vos réactions et commentaires, je vous dis à très bientôt !

Diki

Article sous licence Creative Commons Attribution 2.0 FR

Articles similaires