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

  1. Accueil
  2. Outils et Systèmes
  3. Centralisateur de logs: Quartet Gagnant « Graylog – Nxlog – Elasticsearch – MongoDB »

matrix

logo-graylog

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)

Installation 0 Hard Disk VM et carte Bridged VMWARE

 

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.

Installation 3 vérif media CDROM d'install ISO CentOS7 sous VMWARE

 

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)

Installation 10 Démarrer VM CentOS7 sur le CDROM VMWARE dan le Bios Setup1

 

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

Installation 1 Centos7 et modif TPC-IP réseau Ethernet en0167777

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)

Installation 2 Centos7 et modif TPC-IP réseau Ethernet en0167777

 

 

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

Installation 4 vérif Install minimale et outils de débogage

 

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

Installation 5 confg motde passe et un user cetos7

 

Installation 6 Création utilisateur Admin et pwd Centos7

 

Installation 7 Terminiée CentOS finir la configuration

 

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

Installation 9 Déconnecter le media CDROM DVD ISO CentOS7 avant redémarrage de CentOS7

 

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

Installation 10 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 »

Installation 10 Démarrer VM CentOS7 sur le disque dur virtuel VMWARE dan le Bios Setup

 

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

Installation 11 Ouverture Login Admin et pwd

 

Installation 12 passer en root sur utilisateur admin

 

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)

Installation 13 connexion SSH via putty vers serveur CentOS7

Installation 26 lancement putty autorisation192.168.1.55

Installation 14 Ouverture Login user admin et pwd via Putty Installation 15 passer en root sur user admin

 

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:

Installation 16 service NTPD

Installation 17 suite service NTPD

 

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

Instllation 18 modif Selinu permissive

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

Installation 27 création du fichier de dépôt MongoDB au début avant installa JAva

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 28 statut service mongod ok

 

Installation des utilitaires Python

yum -y install policycoreutils-python

Installation 32 Installation des paquets utilitaires python après MongoDB

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 19 création fichier elasticsearch.repo

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:

Installation 30 Installation Elasticsearch ok

 

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:

Installation 20 vérif fichiers de dépôt yum repolist

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

Installation 33 reload enable start status Elasticsearch

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:

Installation 44 Fichier Elasticsearch.yml rectifié1

Installation 45 Fichier Elasticsearch.yml rectifié2

Installation 45 Fichier Elasticsearch.yml rectifié08.0.2016

Installation 46 Fichier Elasticsearch.yml rectifié4

 

Installation 46 Fichier Elasticsearch.yml rectifié5

 

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

Installation 34 Fichier config Elasticsearch.yml 5

 

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 »

}

Installation 34 vérif curl elasticsaech11

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

Installation 97 santé cluster green elasticsearch-1.7.5

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

Installation 35 Installation plugins marvel et Lastest Elasticsearch

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

Installation 98 1er ouverture du plugin HEAD via http

 Connexion via l’API REST HTTP ‘MARVEL’ Elasticsearch

Installation 95 commandes ok install plugin MARVEL à jour ok

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:

Installation 96 commandes install plugin HEAD directory elasticsearch-1.7.5

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

Installation 99 commande curl retour shards et index non assignés cluster jaune

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

 Installation 100 commande curl retour shards et index non assignés cluster jaune

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 39 Installation dépôt et server Graylog2 Graylog

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

Installation 36 Install générateur pwgen et creation mot de passe usser Graylog

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

Installation 38 création mot de passe root_password_sha2 Graylog

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

Installation 37 configuration des mots de passes user dans le fichier de config Graylog

Installation 50 Fichier config Graylog2

Installation 50 Fichier config Graylog3

Installation 50 Fichier config Graylog4

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

Installation 40 configuration fichier ocnfig Interface Web Graylog

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

Installation 38 création mot de passe root_password_sha2 Graylog

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

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

Installation 41 vérification démarrage server Graylog et node

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)

 Installation 43 Connexion Interface Web Graylog Admin pwd 123456

Installation 42 Visuel System via Interface Web Graylog

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

 Installation 47 Message maj version Graylog via 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

Installation 47 Message maj version Graylog via interface Web 2

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:

Installation 48 Mise en état false du Master node pour vérifier l'incidence sur Graylog

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

Installation 75 Input Graylog Syslog UDP TCP GELF

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

Installation 76 Input Graylog Syslog TCP

Installation 77 Input Graylog Syslog UDP

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

Installation 49 Premier retour de logs du Host 192.168.1.31 vers Graylog1 bis

Installation 49 Premier retour de logs du Host 192.168.1.31 vers Graylog

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:

Installation 51 commande ifconfig tcpdump

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

Installation 52 commande grep pour chercher le port 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

Installation 53 scan tous les ports UDP sur une IP

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:

Installation 54 connexion port 514 refusée utilisation iptables

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)

Installation 58 Activité tableau de bord Graylog et HOST

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

Installation 56 Tableau de bord renvoi logs rsyslog de Centos7 192.168.1.55 vers port 1514 Graylog

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

Installation 59 modulation bin adresse HOST et Server CentOS7 sur tableau de bord

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

Installation 57 Renvoi logs MSEventlogs mahcine Windows vers Graylog

Installation 80 Logs stratégie de groupe Windows7

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)

Installation 60 Evenement suppression de l'appli Skype sur HOST

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

Installation 81 réinstallation appli Skype

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

Installation 82 Observateur devenements windows1

Installation 83 Critères événements Windows appli securité systeme

Installation 84 copie script XML evenemtn windows pour Nxlog

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

Installation 92 arrêt du service nxlog cmd

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

Installation 85 localisation fichier nxlog.conf

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

Installation 62 fichier config Nxlog 11

Installation 62 fichier config Nxlog 22

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.

Installation 63 fichier de configuration Rsyslog1

Installation 63 fichier de configuration Rsyslog2

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 !

Installation 86 dashboard2

Installation 86 dashboard3

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:

Installation 87 création recherche modification applicaiton

 

Installation 87 création recherche modification applicaiton3

Installation 87 création recherche modification applicaiton2

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 »

Installation 88 Création d'un Dashboard Graphes des evenements1

 

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)

Installation 89 Visualisation d'un Dashboard Graphes des evenements1

 

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:

Installation 90 résultat Widget service AND installé

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

Installation 91 résultat Widget modification AND application

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

Installation 87 création recherche échec installation5

 

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

Installation 64 découverte Market place Graylog

Installation 65 contenu pack active directory nxlog market place graylog

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

Installation 66 copie du contenu pack active directory nxlog dans 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)

Installation 67 inportation contenu pack active directory nxlog dans Graylog Server

Installation 68 application du contenu pack active directory nxlog dans Graylog Server

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

https://creativecommons.org/licenses/by/2.0/fr/

20 Commentaires. En écrire un nouveau

  • Il est donc nécessaire que je booste un peu ma machine pour que je puisse installer Graylog. Je vous remercie pour ce guide très très détaillé. Ca permet de bien effectuer l’installation, parce que ça nous sera très utile.

    Répondre
  • Bonjour Gérald,

    Un grand merci pour votre compliment 🙂

    A propos de votre souhait de booster votre machine, effectivement la machine hôte (physique) aura plus de facilité à « travailler » avec des ressources matérielles supplémentaires notamment la mémoire vive.

    Pour cette installation (test) déployée à travers cet article, ma machine (mouton) est équipée de 16Go de DDRAM 4 Kingston (2133 MHtz). Pour information, 16Go de mémoire vive sera probablement suffisant pour votre machine. Etant donné que je réalise de nombreuses installations sur ma machine, je vais devoir moi aussi booster sa mémoire vive à 32Go.

    Ensuite tout dépend du type d’utilisation que vous souhaitez mettre en place à l’aide de ce tutoriel… Est-ce pour une utilisation dédiée à un contexte personnel ou bien à un environnement professionnel ?

    Rassurez-vous, je vous pose cette question car dans le cas d’une utilisation professionnelle la configuration d’une telle solution devra se faire autrement à travers un socle technique et matériel adapté notamment…

    Hormis toute cette technicité, il est préférable d’installer cette solution sur la partition du disque dur ‘C’ (système) de votre machine hôte (disque dur virtuel VMWARE de l’installation) ou bien sur un disque dur interne physique dédié à votre installation Graylog comme je l’ai fait ici. Pourquoi ? Simplement pour plus de sécurité et de « facilité », car j’ai l’habitude de réinstaller souvent l’OS de ma machine hôte. Je ne suis pas du genre à m’embêter à chercher l’origine d’un dysfonctionnement Windows par exemple 🙂 Je préfère reformater et réinstaller en réseau un nouvel OS. L’opération me prend 10mn tout au plus (via un serveur DRBL sous Fedora Linux que j’ai monté sur un autre disque dur physique interne dédié)

    Avez-vous d’autres questions au sujet de votre installation ? Peut-être quelques spécificités propres à votre besoin ?

    A bientôt,
    Bien à vous.

    Diki

    Répondre
  • Bonjour Diki,

    Merci pour ce tuto notamment pour le coup du XML dans le gestionnaire des tâches permet de gagner un temps certain j’imagine.

    De mon côté, j’ai installé Graylog/MongoDB/ElasticSearch sur une machine dédiée que j’ai installé avec la dernière Debian stable. Ca m’a posé un minuscule problème car Java 7 n’était pas disponible par défaut et j’ai du ajouter des backports pour pouvoir l’ajouter.

    J’aimerai centraliser les logs de clients de ma société qui sont donc des postes déportés…

    Avant d’en arriver là, il y a de le route et pas des moindre à ce que je constate tant je galère pour la mise en route.

    Tout d’abord, j’ai fait le choix (totalement arbitraire) d’utiliser Collector-Sidecar qui me semble, en fait, piloter NXLOG car j’auditerai uniquement des machines Windows ; à commencer par mon poste de travail en Windows 7 x64.

    Bon d’abord, j’ai créé un Input dans mon Graylog avec 192.168.1.223:12201 comme listner GELF UDP.
    Sur mon client, j’ai paramétré le fichier YML du Sidecar afin qu’il soit informer de l’adresse et du port du serveur.
    Le soft aurait du créé un nxlog.conf mais ne l’a pas fait. J’ai donc dupliqué celui du dossier d’nxlog et de même j’ai adapté la configuration afin d’utiliser le GELF, le module UDP et rappeler l’IP et le port de mon serveur.

    Tout me semblait bon … mais …
    Je me retrouvais avec des erreurs et surtout aucun message n’arrivait au serveur 🙁

    Donc en fouillant un peu j’ai trouvé la commande de test de Collector-Sidecar qui donne un truc dans le genre (je ne suis pas au bureau):
    graylog-collector-sidecar.exe -c collector.yml

    Ah des erreurs : parfait on va avancer !
    Les erreurs m’indiquent que la connexion est refusée, tu m’étonne je lis « …Dial TCP… » … Mec on avait dis UDP ?!

    Bon je ne me laisse pas avoir :
    – Je supprime mon Input UDP.
    – Je créé mon Input TCP.
    – Je modifie mes fichiers de config (YML et nxlog.conf).
    – Je redémarre le service Graylog Collector.
    – Je relance la commande de debug….

    Sauf que là la connexion reste bloquée sur « [Starting] » … quelle tristesse.

    Bon il semblerait que le Sidecar soit un ajout récent et il manque donc de documentation alors même que je suis ignare vis à vis de ce produit. Même si c’est beaucoup moins probable, il est possible que le Sidecar contienne des bugs…

    Bref, as-tu une idée de là où ça bloque (1) et penses-tu que je doive/puisse remplacer le Sidecar par Nxlog « brut » ?

    Merci par avance de ton intérêt et de ton temps 😉

    Répondre
  • Bonjour Antoine,

    Je vais être franc avec toi en te disant que je n’ai à ce jour pas testé « Graylog Sidecar ». Quoi qu’il en soit, il semblerait que ton souci provienne de la brique « Graylog Sidecar ». Adepte de « la loi du moindre effort » il serait judicieux de tester ton installation sans « Graylog Sidecar ». Si c’est positif alors nous aurons la confirmation que c’est bien « Graylog Sidecar » qui plante 🙂

    Tu as dit avoir dupliqué le fichier de config nxlog ? Je te pose cette question car « Graylog Sidecar » doit normalement être installé initialement avec le service Nxlog désactivé étant donné qu’il devient auto piloté par « Graylog Sidecar ». Logiquement « Graylog Sidecar » créé automatiquement nxlog.conf, s’il ne l’a pas fait c’est effectivement un petit bug.

    Faisons un petit test pour voir si le Démon nous joue des tours ! 🙂

    Pourrais-tu arrêter « GRAYLOG-SERVER » (shutdown), puis renommer ton nxlog.conf (pour le sauvegarder) et le remplacer par un nxlog.conf vide (vierge).

    Ensuite redémarre « GRAYLOG » et vérifie via le panneau « Collector Linux Configuration » (Graylog REST API) que Nxlog soit bien configuré (Define Nxlog Snippets => Backend => nxlog) ?

    Pour terminer, dis-moi si « Graylog » a injecté la bonne config dans le nxlog.conf ?

    Ça va être très dur, mais nous vaincrons ! 🙂

    A+!
    Diki

    Répondre
  • Bonjour,

    Merci pour ce tuto ;-).
    Mettons que je veuille centraliser les logs de 40 serveurs, combien d’espace disque, cpu, mémoire dois-je envisager pour mon serveur de log selon vous ?

    Et j’imagine que passé un certain temps de centralisation, on arrive vite à la taille maximale, que se passe t-il ensuite ? On peut programmer la suppression des logs ancien ou quelque chose du genre ?

    Merci à vous.

    Répondre
    • Bonjour alyshu,

      Pour être franc il me sera très difficile de répondre à ta première question. Généralement, lorsqu’un Administrateur Systèmes et Réseau doit par exemple centraliser 40 servers, il étudie, met en oeuvre et déploie au préalable un server pilote (Centralisateur Test) virtualisé. L’idée générale est de pouvoir notamment tester l’installation globale, la stabilité, la charge et le taux d’absorption des logs du Centralisateur (pilote) avec les 40 servers actifs et opérationnels. Il sera évidemment nécessaire de connaître avec précision le cahier des charges de chaque server (40 dans votre cas) en adéquation avec le besoin au niveau de la centralisation des logs. Etant donné qu’un centralisateur de logs est très gourmand en ressource « CPU/RAM », tout dépendra donc du budget alloué à cet effet 🙂

      Concernant la rétention, la rotation des logs et leur stockage ce n’est pas tellement un problème, car il est possible de moduler et d’ajuster ces éléments en fonction des résultats obtenus durant les phases de tests (centralisateur pilote). Cet aspect de la configuration se situe au chapitre ‘V’ de mon article. Quoi qu’il en soit il vous faudra réaliser des tests sur un centralisateur (pilote) pour obtenir des informations pertinentes. Sur le principe je dirai oui, il est possible de configurer la « suppression » des logs en fonction des critères évoqués plus haut (chapitre ‘V’: la rétention, la rotation des logs, nombre d’index maximum, taille des index etc.)

      Cordialement,
      Diki

      Répondre
      • Bonjour,

        Merci pour ta réponse Diki.

        Par contre, j’ai du mal à trouver la rétention dans le tuto. Le chapitre V s’intitule : « V. Installation du Serveur GRAYLOG2 (Centralisateur des journaux d’événements Windows) ».

        Quand je fais un ctrl+f, pas moyen de trouver non plus…

        Désolé si je fais le boulet :).

        Répondre
  • Bonjour,
    Effectivement c’est un peu plus subtile car il te faut naviguer dans le fichier de configuration du Server GRAYLOG qui est visible via les screenshots au chapitre V 🙂
    Au fait as tu déjà testé l’installation du Server Graylog ? Je suppose que oui… 🙂

    Répondre
    • En faite, actuellement je suis entrain de faire une petite étude comparative avec maquettes. J’ai donc simplement installé l’appliance de notre quartet gagnant ;).

      D’accord je lis plus attentivement cette partie. Merci à toi 😉

      Répondre
  • Rebonjour alyshu,

    Je vais un peu rentrer dans le vide du sujet de la « rétention des logs »… 🙂

    J’aurais pu te répondre de façon plus simpliste, du style:  » Regarde à la ligne n°135 du fichier de configuration ‘server.conf’ de Graylog (chapitre V) ». Sauf que ce n’est pas aussi simple puisqu’il y a beaucoup d’autres critères qui rentrent en ligne de compte, notamment celui du rapport entre le volume de stockage dédié aux logs et la quantité de messages générée sur un temps donné. Dans cet article j’ai volontairement appliqué une « rotation_strategy = count » pour des raisons évidentes de simplification.

    Si j’ai bien saisi ton besoin, tu opterais pour une « rotation_strategy = time », rien ne t’empêche donc d’appliquer un politique de « rétention des logs » en paramétrant « retention-strategy = close » dans la mesure où un volume suffisant de stockage dédié aux logs est prévu. Les logs seront ainsi stockés par cycle suivant une rotation prédéfinie dans le temps donnant lieu à la FERMETURE des indexes à la fin du cycle. Ces logs stockés pourront bien évidemment être ré-ouverts en vue d’une exploitation ultérieure.

    Quel est ton objectif de SUPERVISION et d’ANALYSE des logs que tu souhaites mettre en oeuvre par la suite ?

    A+!
    Diki

    Répondre
  • Bonjour ,

    Bravo pour ce tuto très complet, bien meilleur que certains en Anglais, sur un soft pas si simple que cela a mettre en oeuvre.
    Il me manque un petit quelque chose , l indexation des logs IIS et Apache. Je vois que ca n a pas l air complique ceci etant je vois qu il y a l ai d avoir deux ecoles , GELF et JSON pour le format. Peut etre que vous avez quelque chose a conseiller pour Graylog Nxlog IIS/Apache .

    Merci encore pour vos lumieres.

    Guillaume.

    Répondre
    • Bonjour Guillaume,

      Merci pour le compliment 🙂

      Effectivement, l’indexation des logs IIS/Apache n’est pas tellement compliquée à mettre en oeuvre. Par exemple la brique complémentaire d’ »Advanced Logging » d’IIS permettra de collecter les informations encapsulées dans le header HTTP pour connaître l’adresse IP du Client (infos navigateurs, OS utilisateurs, urls les plus demandées, géolocalisation des users etc.)

      Les formats GELF et Json sont complémentaires dans la mesure où les données échangées durant leur indexation sont au format Json nativement reconnu par Javascript . GELF est un format de communication plus riche qui ne souffre pas des limitations de Syslog. Ensuite tout dépendra de l’implémentation que vous souhaitez mettre en place durant les opérations de filtrage/découpage et d’extraction des logs en fonction du besoin ?

      De manière plus simplifiée Elasticsearch indexe automatiquement ce qui permet de trouver plus rapidement, via le champ de recherche fournit à travers l’API de l’interface Graylog-Web, des résultats probants et exploitables. La puissance de Json ici est indéniable puisqu’il offre notamment des « grok patterns » téléchargeable via la MarketPlace Graylog qu’il suffit tout simplement de copier/coller , ainsi que toute une multitude de combinaisons possibles permettant l’extraction et l’exploitation de données appropriées…

      Bonne fin de week-end ! 🙂
      A+!
      Diki

      Répondre
  • c’est un bon tuto que j’ai teste maintenant je veux ajouter deux noeuds encors

    Répondre
  • Très bon tuto, trop axé sur Windows pour moi ;'( J’aurais cru tu aurais parlé de centralisation de requête SNMP, log de firewall/équipement réseau

    Répondre
    • Bonjour,

      Merci pour le compliment.

      Le besoin que tu exprimes est relativement technique et s’applique aux environnements SNMP d’une Administrateur de Réseaux. Je ne crois pas que ce type de contenu aurait plu aux lectrices et aux lecteurs 🙂

      Au plaisir de te lire,
      Bien à toi,

      Diki

      Répondre
  • Bonjour,

    Trés bon tutoriel, agréable à lire et intéressant.
    Toutefois, dans un environnement Centos7.x, il est dommage de désactiver Selinux ou de le passer en mode permissif.
    Selinux bloque la transmission rsyslog des hôtes, ce qui implique de devoir le désactiver sur toutes les machines qui remontent leurs logs.

    Je suis preneur d’une solution.

    Répondre
  • Bonjour à tous,
    Excellent tutoriel, tout ce passait très bien jusqu’à l’envoie des logs Windows sur le serveur …

    J’ai enfin réussis à installer Graylog, cependant je rencontre une difficulté pour envoyé mes logs Windows vers ce serveur avec NxLog :

    Mon serveur est un centOS7 en 10.10.10.2.
    Mon Windows est un W7 en 10.5.10.8.

    J’ai configuré deux inputs sur Graylog avec comme paramètre :
    1)syslog TCP, bind-address : 0.0.0.0 et port : 9999
    2)syslog UDP, bind-address : 0.0.0.0 et port : 9514

    Pour ce qui est du fichier conf NxLog, j’ai configuré en Output : Module: om_tcp (ou om_udp), Host : 10.10.10.2, Port : 9999 .

    Mais voilà , aucun logs n’arrivent à destination, pourriez-vous m’aider svp ?

    Merci d’avance et bonne journée !

    Répondre
  • hey diki avez vous un rapport ou bien ebook plus détailler pour m’aider car j’ai un pfe sur ce sujet « graylog2 »

    Répondre
  • Bonjour et merci pour ce post qui m’a grandement aidé.
    Suite à la loi RGPD il me fallait centraliser les logs ce que j’ai réussi à faire avec votre tutoriel.

    Cependant je me permet de signaler qu’il y a beaucoup d’erreur de syntaxe.
    Quelqu’un comme moi qui débute sur linux, il m’a été assez difficile de le réaliser jusqu’au bout sans aller sur d’autres sites pour vérifier.

    Par exemple : systemctl deamon reload alors que c’est systemctl daemon-reload

    Quand vous connaissez pas grand chose c’est difficile de savoir d’ou vient le problème.

    Ensuite vous indiquer qu’il faut redémarrer Graylog (systemctl restart graylog-server) alors que dans votre procédure il s’installe après ! Donc forcément on se retrouve avec un message d’erreur.

    Mais il faut l’avouer que sans votre procédure, je n’aurai pas pu y arriver tout seul, donc malgré ses lacunes, un grand merci à toi !

    Répondre

Laisser un commentaire

Menu
More in Outils et Systèmes
honeypot
Les Honeypots : des pièges à pirates

On n'en entend pas souvent parler, mais les honeypots (pots de miel en français) sont des pièges à pirates qui remontent déjà d'il y a...

Close