« LINUX:Wazuh-WUI » : différence entre les versions

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
 
(16 versions intermédiaires par le même utilisateur non affichées)
Ligne 51 : Ligne 51 :


Anciennement on devait le télécharger sur le site de Wazuh via les commandes suivantes:
Anciennement on devait le télécharger sur le site de Wazuh via les commandes suivantes:
  curl -sO <nowiki>https://packages.wazuh.com/4.3/wazuh-certs-tool.sh</nowiki>
  curl -sO <nowiki>https://packages.wazuh.com/4.8/wazuh-certs-tool.sh</nowiki>
  curl -sO <nowiki>https://packages.wazuh.com/4.3/config.yml</nowiki>
  curl -sO <nowiki>https://packages.wazuh.com/4.8/config.yml</nowiki>
Actuellement on est à la version 4.3 de Wazuh.
Actuellement on est à la version 4.8 de Wazuh.


On le rend exécutable:
On le rend exécutable:
Ligne 156 : Ligne 156 :
Ce module ne vient pas préconfiguré pour Wazuh. Il faut télécharger plusieurs fichiers et vérifier leurs droits d'accès.
Ce module ne vient pas préconfiguré pour Wazuh. Il faut télécharger plusieurs fichiers et vérifier leurs droits d'accès.


Les commandes suivantes téléchargent deux fichiers de configuration dans le répertoire: "/etc/filebeat". Ces téléchargements sont pour la version 4.3 actuelle de Wazuh:
Les commandes suivantes téléchargent deux fichiers de configuration dans le répertoire: "/etc/filebeat". Ces téléchargements sont pour la version 4.8 actuelle de Wazuh:
  curl -so /etc/filebeat/wazuh-template.json <nowiki>https://raw.githubusercontent.com/wazuh/wazuh/4.3/extensions/elasticsearch/7.x/wazuh-template.json</nowiki>
  curl -so /etc/filebeat/wazuh-template.json <nowiki>https://raw.githubusercontent.com/wazuh/wazuh/v4.8.0/extensions/elasticsearch/7.x/wazuh-template.json</nowiki>
  curl -so /etc/filebeat/filebeat.yml <nowiki>https://packages.wazuh.com/4.3/tpl/wazuh/filebeat/filebeat.yml</nowiki>
  curl -so /etc/filebeat/filebeat.yml <nowiki>https://packages.wazuh.com/4.8/tpl/wazuh/filebeat/filebeat.yml</nowiki>
  chmod 644 /etc/filebeat/wazuh-template.json
  chmod 644 /etc/filebeat/wazuh-template.json
  chmod 644 /etc/filebeat/filebeat.yml
  chmod 644 /etc/filebeat/filebeat.yml
Ligne 169 : Ligne 169 :
La commande qui suit, télécharge toute une arborescence qui ajoute les informations nécessaires pour l'envoi des alertes au service "wazuh-indexer.service":
La commande qui suit, télécharge toute une arborescence qui ajoute les informations nécessaires pour l'envoi des alertes au service "wazuh-indexer.service":
----
----
  curl -s <nowiki>https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.2.tar.gz</nowiki> | tar -xvz -C /usr/share/filebeat/module
  curl -s <nowiki>https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.4.tar.gz</nowiki> | tar -xvz -C /usr/share/filebeat/module
----
----
Dans cette partie ajoutée, j'ai ajouté une ligne au fichier '''"/usr/share/filebeat/module/wazuh/alerts/ manifest.yml"'''. Il défini quel fichier, ce service doit traiter. Par défaut, c'est le fichier des alertes "/var/ossec/logs/alerts/alerts.json". J'ai ajouté le fichier '''"/var/ossec/logs/alerts/alertsold.json"'''.
Dans cette partie ajoutée, j'ai ajouté une ligne au fichier '''"/usr/share/filebeat/module/wazuh/alerts/manifest.yml"'''. Il défini quel fichier, ce service doit traiter. Par défaut, c'est le fichier des alertes "/var/ossec/logs/alerts/alerts.json". J'ai ajouté le fichier '''"/var/ossec/logs/alerts/alertsold.json"'''.


Voici le contenu de ce fichier de configuration:
Voici le contenu de ce fichier de configuration:
Ligne 200 : Ligne 200 :
'''Attention''', ne chargez pas trop de mois, 6 par exemple. Par défaut, Wazuh-Indexer ne peut prendre en compte que 1000 segments d'indexations ("shards"). Nous verrons ce problème lors de la maintenance.
'''Attention''', ne chargez pas trop de mois, 6 par exemple. Par défaut, Wazuh-Indexer ne peut prendre en compte que 1000 segments d'indexations ("shards"). Nous verrons ce problème lors de la maintenance.


Autre précaution importante: Si vous charger des anciennes données par ce moyen, ce fichier alternatif ne doit pas contenir de données déjà chargées; elles seront en double.
Autre précaution importante: Si vous chargez des anciennes données par ce moyen, ce fichier alternatif ne doit pas contenir de données déjà chargées; elles seront en double.




Ligne 231 : Ligne 231 :




Dans ce même fichier, les trois lignes suivantes définissent le nécessaire pour une connexion sécurisée via le port TCP 444 entre le serveur Wazuh-Dashboard et le browser de votre PC. Ce sont une clé privée et un certificat publique auto signé au nom de la société Wazuh:
L'application "Wazuh-Dashboard" doit pouvoir consulter les informations de Wazuh-Manager via son API. Il utilise l'utilisateur "wazuh-wui". Le mot de passe de cet utilisateur est écrit dans le fichier de configuration "/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml". Par défaut, ce mot de passe est "wazuh-wui". Si vous l'avez changé, il faut l'adapter en conséquence.
 
Au bas de ce fichier, dans la section "hosts", on adapte le mot de passe:
----
----
  server.ssl.enabled: true
  hosts:
server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
  - default:
server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"
    url: <nowiki>https://localhost</nowiki>
    port: 55000
    username: wazuh-wui
    '''password: wazuh-wui'''
    run_as: false
----
----
Il peut être intéressant que ce certificat soit au nom de votre serveur ou de votre société. Pour cela je vous renvoie aux articles traitant des [[LINUX:Certificats|Certificats]].
On y remarque les informations de la machine à contacter et le port de connexion pour accéder à l'API de Wazuh ainsi que le nom de l'utilisateur utilisé.




Le point [[LINUX:Certificat auto signé|Certificat auto signé]] est semblable à celui existant. Mais nous avons un certificat publique au nom du serveur, "serverdb.home.dom" selon l'exemple.
==Wazuh-Manager==
Selon l'exemple de ce chapitre, les trois lignes deviennent:
Une section a été récemment modifiée. Dans le fichier "/var/ossec/etc/ossec.conf", la balise "<vulnerability-detector>" a été modifiée et fortement réduite.
Elle se limite aux lignes suivante:
----
----
server.ssl.enabled: true
  <vulnerability-detection>
server.ssl.key: '''"/etc/pki/tls/private/localhost.key"'''
    <enabled>yes</enabled>
server.ssl.certificate: '''"/etc/pki/tls/certs/localhost.crt"'''
    <index-status>yes</index-status>
    <feed-update-interval>60m</feed-update-interval>
  </vulnerability-detection>
----
----
* Le fichier "localhost.key" est la clé privée du serveur.
* Le fichier "localhost.crt" est le certificat publique auto signé.




Si nous voulons un certificat publique non auto signé au nom du serveur, nous reportons au point [[LINUX:Création d'une CA privée (V1)|Création d'une CA privée (V1)]]. Dans ce cas, le certificat publique est validé par notre propre autorité de certification (CA) au nom de notre serveur.
Une autre section est venue récemment s'ajouter en relation avec Wazuh-Indexer et FileBeat:
Selon l'exemple de ce chapitre, les trois lignes deviennent:
----
----
server.ssl.enabled: true
  <indexer>
server.ssl.key: '''"/etc/pki/home/private/localhost.key"'''
    <enabled>yes</enabled>
server.ssl.certificate: '''"/etc/pki/home/certs/serverdb.home.pem"'''
    <hosts>
      <nowiki><host>https://</nowiki>'''127.0.0.1:9200'''<nowiki></host></nowiki>
    </hosts>
    <ssl>
      <certificate_authorities>
        <ca>/etc/filebeat/certs/root-ca.pem</ca>
      </certificate_authorities>
      <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
      <key>/etc/filebeat/certs/filebeat-key.pem</key>
    </ssl>
  </indexer>
----
----
* Le fichier "localhost.key" est la clé privée du serveur.
On y a modifié la référence d'accès au service Wazuh-Indexer vers l'adresse IP "127.0.0.1".
* Le fichier "serverdb.home.pem" est une chaine contenant deux certificats publiques: le certificat publique de notre autorité de certification (CA) et le certificat publique du serveur validé par notre autorité de certificat.
 
 
Ces fichiers sont les mêmes que l'on doit utiliser pour le serveur Web Apache: variables "SSLCertificateKeyFile" et "SSLCertificateFile".




Pour une question de sécurité, je ne recommande pas que ce serveur soit accessible à partir d'Internet. Mais le principe est le même.
On doit ensuite enregistrer le nom d'utilisateur et le mot de passe d'accès à Wazuh-Indexer dans des fichiers sécurisé de Wazuh-Manager. Par défaut ils sont respectivement "admin" et "admin". Il est préférable que le mot de passe "admin" soit changé. On le verra par la suite.
Si on utilise des certificats officiels Let's Encrypt, nous utilisons:
/var/ossec/bin/wazuh-keystore -f indexer -k username -v admin
* la clé privée du serveur "/etc/letsencrypt/live/<DNS publique de votre serveur>/privkey.pem"
/var/ossec/bin/wazuh-keystore -f indexer -k password -v admin
* la chaîne de certificats publiques "/etc/letsencrypt/live/<DNS publique de votre serveur>/fullchain.pem" contenant trois certificats publiques (celui du serveur, celui de la CA et l'intermédiaire).




Note: Soyez attentif aux privilèges. Le service "wazuh-dashboard.service" est lancé sous la responsabilité de l'utilisateur Unix "wazuh-dashboard". Il doit avoir accès en lecture à ces certificats.
L'application "Wazuh-Dashboard" doit pouvoir consulter les informations de Wazuh-Manager via son API. Il utilise l'utilisateur "wazuh-wui". Le mot de passe de cet utilisateur est écrit dans le fichier de configuration "/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml". Par défaut, ce mot de passe est "wazuh-wui". Si vous l'avez changé, il faut l'adapter en conséquence.
Au bas de ce fichier, dans la section "hosts", on adapte le mot de passe:
----
hosts:
  - default:
    url: <nowiki>https://localhost</nowiki>
    port: 55000
    username: wazuh-wui
    '''password: wazuh-wui'''
    run_as: false
----
On y remarque les informations de la machine à contacter et le port de connexion pour accéder à l'API de Wazuh ainsi que le nom de l'utilisateur utilisé.
=Configurer le mur de feu ou FireWall=
=Configurer le mur de feu ou FireWall=
La majorité du trafic réseau se fait en local et donc ne pose pas de problème avec le Firewall de la machine qui héberge tous ces services. Seul le port TCP 444 a besoin d'être ouvert pour que nous puissions l'utiliser.
La majorité du trafic réseau se fait en local et donc ne pose pas de problème avec le Firewall de la machine qui héberge tous ces services. Seul le port TCP 444 a besoin d'être ouvert pour que nous puissions l'utiliser.
Ligne 433 : Ligne 426 :
  <nowiki>https://192.168.1.110:444</nowiki>
  <nowiki>https://192.168.1.110:444</nowiki>
Dans l'écran de connexion, le nom d'utilisateur est "admin" et son mot de passe est "admin".
Dans l'écran de connexion, le nom d'utilisateur est "admin" et son mot de passe est "admin".
=Configurations avancées de Wazuh-Dashboard=
Nous présentons ici quelques configurations alternatives de Wazuh-Dashboard.
==Certificats personnalisés==
Dans le fichier '''"/etc/wazuh-dashboard/opensearch_dashboards.yml"''', les trois lignes suivantes définissent le nécessaire pour une connexion sécurisée via le port TCP 444 entre le serveur Wazuh-Dashboard et le browser de votre PC. Ce sont une clé privée et un certificat publique auto signé au nom de la société Wazuh:
----
server.ssl.enabled: true
server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"
----
Il peut être intéressant que ce certificat soit au nom de votre serveur ou de votre société. Pour cela je vous renvoie aux articles traitant des [[LINUX:Certificats|Certificats]].
Le point [[LINUX:Certificat auto signé|Certificat auto signé]] est semblable à celui existant. Mais nous avons un certificat publique au nom du serveur, "serverdb.home.dom" selon l'exemple.
Selon l'exemple de ce chapitre, les trois lignes deviennent:
----
server.ssl.enabled: true
server.ssl.key: '''"/etc/pki/tls/private/localhost.key"'''
server.ssl.certificate: '''"/etc/pki/tls/certs/localhost.crt"'''
----
* Le fichier "localhost.key" est la clé privée du serveur.
* Le fichier "localhost.crt" est le certificat publique auto signé.
Si nous voulons un certificat publique non auto signé au nom du serveur, nous nous reportons au point [[LINUX:Création d'une CA privée (V1)|Création d'une CA privée (V1)]]. Dans ce cas, le certificat publique est validé par notre propre autorité de certification (CA) au nom de notre serveur.
Selon l'exemple de ce chapitre, les trois lignes deviennent:
----
server.ssl.enabled: true
server.ssl.key: '''"/etc/pki/home/private/localhost.key"'''
server.ssl.certificate: '''"/etc/pki/home/certs/serverdb.home.pem"'''
----
* Le fichier "localhost.key" est la clé privée du serveur.
* Le fichier "serverdb.home.pem" est une chaine contenant deux certificats publiques: le certificat publique de notre autorité de certification (CA) et le certificat publique du serveur validé par notre autorité de certificat.
Ces fichiers sont les mêmes que l'on doit utiliser pour le serveur Web Apache: variables "SSLCertificateKeyFile" et "SSLCertificateFile".
Pour une question de sécurité, je ne recommande pas que ce serveur soit accessible à partir d'Internet. Mais le principe est le même.
Si on utilise des certificats officiels Let's Encrypt, nous utilisons:
* la clé privée du serveur "/etc/letsencrypt/live/<DNS publique de votre serveur>/privkey.pem"
* la chaîne de certificats publiques "/etc/letsencrypt/live/<DNS publique de votre serveur>/fullchain.pem" contenant trois certificats publiques (celui du serveur, celui de la CA et l'intermédiaire).
Note: Soyez attentif aux privilèges. Le service "wazuh-dashboard.service" est lancé sous la responsabilité de l'utilisateur Unix "wazuh-dashboard". Il doit avoir accès en lecture à ces clé et certificats.
==Wazuh-Dashboard derrière le proxy d'Apache==
Dans notre configuration de Wazuh-Dashboad, nous sommes obligés de spécifier le port TCP 444 dans l'URL d'accès car le port TCP 443 classique pour le protocole HTTPS est utilisé par le service Apache.
Nous allons intercepter le trafic du port TCP 444 pour le récupérer dans Apache et le transmettre au client via le port TCP 443 (HTTPS). Le changement de configuration se fait dans Wazuh-Dashboard et dans Apache.
Du côté de Wazuh-Dashboard, les changements se font dans le fichier de configuration '''"/etc/wazuh-dashboard/opensearch_dashboards.yml"''':
----
'''server.host: 127.0.0.1'''
'''server.port: 444'''
opensearch.hosts: <nowiki>https://localhost:9200</nowiki>
opensearch.ssl.verificationMode: certificate
#opensearch.username:
#opensearch.password:
opensearch.requestHeadersWhitelist: ["securitytenant","Authorization"]
opensearch_security.multitenancy.enabled: false
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
'''server.ssl.enabled: false'''
'''server.basePath: "/wazuh"'''
'''server.rewriteBasePath: true'''
opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/root-ca.pem"]
uiSettings.overrides.defaultRoute: /app/wazuh
----
On garde le port TCP 444 ("server.port: 444") mais comme le traffic se fait entre Wazuh-Dashboard et Apache sur la même machine, on limite l'interface au "localhost" ("server.host: 127.0.0.1"). Ce transit interne se fera non crypté ("server.ssl.enabled: false") et donc on n'a pas besoin des clé et certificats. Le cryptage se fera sous Apache avec les certificats du serveur.
Sous Apache, nous avons déjà une arborescence et une racine; il faut donc réécrire la sortie vers un dossier non existant autre que la racine ("server.rewriteBasePath: true"). Nous l'avons nommé "wazuh" ("server.basePath: "/wazuh" "). L'URL d'accès devient dès lors: <nowiki>http://localhost:444/wazuh</nowiki>
Après le lancement du service "wazuh-dashboard.service", le port d'écoute sera ouvert mais aura changé. Quand on lancera la commande:
netstat -ntl
Nous aurons la ligne qui nous concerne, suivante:
----
tcp        0    127 0.0.0.1:444            0.0.0.0:*              LISTEN
----
Evidemment il n'est plus nécessaire d'ouvrir ce port dans le FireWall.
Du côté d'Apache, il faut s'assurer que les modules "proxy" sont actifs; sous Fedora, c'est le cas par défaut. Il faut repérer le fichier lié au cryptage SSL. Ce fichier est par défaut '''"/etc/httpd/conf.d/ssl.conf"'''. Voici un extrait, le plus important pour notre cas:
----
Listen 443 https
<VirtualHost _default_:443>
  SSLEngine on
  SSLCertificateKeyFile /etc/pki/home/private/localhost.key
  SSLCertificateFile /etc/pki/home/certs/serverdb.home.pem
  &nbsp;
  '''ProxyPreserveHost on'''
  '''ProxyRequests on'''
  '''ProxyPass /wazuh <nowiki>http://localhost:444/wazuh</nowiki>'''
  '''ProxyPassReverse /wazuh <nowiki>http://localhost:444/wazuh</nowiki>'''
</VirtualHost>
----
On retrouve les clé et certificats utilisés dans le chapitre précédent. Le texte en gras concerne la configuration Proxy. On retrouve l'URL d'accès à Wazuh-Dashboard qui renvoie vers le dossier "/wazuh" d'Apache. L'URL d'Apache pour accéder au WUI de Wazuh devient: <nowiki>https://serverdb.home.dom/wazuh</nowiki> pour le serveur portant le nom de "serverdb.home.dom". Bien sûr l'URL <nowiki>https://serverdb.home.dom:444/</nowiki> n'est plus d'actualité.




=Utilisateurs=
=Utilisateurs=
Lors de l'installation, de nombreux utilisateurs sont créés pour Wazuh-Indexer. Nous en avons rencontré un, le plus connu et utilisé par le logiciel Filebeat: "admin.
Lors de l'installation, de nombreux utilisateurs sont créés pour Wazuh-Indexer. Nous en avons rencontré un, le plus connu et utilisé par le logiciel Filebeat: "admin".




Ligne 581 : Ligne 675 :


=[[LINUX:Wazuh-WUI-Maintenance|Maintenance]]=
=[[LINUX:Wazuh-WUI-Maintenance|Maintenance]]=
Cet partie regroupe quelques problèmes rencontrés sur cet WUI.
Cette partie regroupe quelques problèmes rencontrés sur cet WUI.




Dernière version du 13 juin 2024 à 17:28

→ retour à Wazuh: HIDS

But

Wazuh dispose d'un outil additionnel sous forme d'interface utilisateur Web. Il permet de consulter les résultats des diverses analyses effectuées accompagnées de nombreux graphiques, d'avoir accès à la configuration,... Les alertes sont regroupées par jour et les graphiques qui en découlent sont présentés sous forme chronologiques.


Architecture

L'ensemble des pièces interagissant pour cette partie, peuvent être organisées dans une architecture complexe. Dans notre cas, les besoins sont très limités; nous opterons pour l'organisation la plus simple; tous les éléments seront rassemblés sur la même machine, celle hébergeant le service "wazuh-manager.service".


Le schéma suivant nous présente l'organisation retenue.


LINUX:Wazuh.3.pdf


Par rapport aux schémas précédents, diverses pièces viennent s'ajouter:

  • Wazuh-Indexer (ElasticSearch): est la pièce centrale. Il est constitué du logiciel ElasticSearch qui a été personnalisé pour Wazuh. Il est chargé de classer, d'organiser, les alertes qu'il va recevoir du logiciel Filebeat. Le résultat de ce travail pourra à son tour être consulté par le logiciel Wazuh-Dashboard. Il reçoit ses données et distribue ses résultats via le port réseau TCP 9200.
  • Filebeat: est chargé d'intercepter les alertes émises par Wazuh-Manager en inspectant ses journaux. Il les transmet au logiciel Wazuh-Indexer via son port d'écoute réseau TCP 9200.
  • Wazuh-Dashboard (Kibana): est l'interface graphique Web qui sera utilisé par tout explorateur Web tel Firefox d'un PC du réseau. Il est constitué du logiciel Kibana qui a été personnalisé pour Wazuh. Il sera accessible sur le port réseau TCP 444. A la base, c'est le port réseau TCP 443 (HTTPS) qui est implémenté mais comme ce port est déjà utilisé par le serveur Apache, ce port a dû être changé. Il va récolter les alertes de Wazuh-Manager centralisées par le logiciel Wazuh-Indexer via son port d'écoute réseau TCP 9200. D'autre part, il récupère la configuration de Wazuh-Manager en utilisant son Wazuh-API qui écoute sur le port réseau TCP 55000.
  • Wazuh-API: est un interface de type HTTP qui permet de consulter le contenu des informations dont dispose Wazuh-Manager via son port réseau TCP 55000.


Installation

Anciennement, il fallait installer Elasticsearch et Kibana et ensuite procéder à l'exécution de divers scripts disponibles sur le site de Wazuh. Maintenant cette partie a été fortement simplifiée.


Notons qu'il est fortement conseillé de consulter la document en ligne sur le site de Wazuh pour effectuer cette installation aux adresses:

  • https://documentation.wazuh.com/current/installation-guide/wazuh-indexer/step-by-step.html pour Wazuh-Indexer.
  • https://documentation.wazuh.com/current/installation-guide/wazuh-dashboard/step-by-step.html pour Wazuh-Dashboard.
  • https://documentation.wazuh.com/current/installation-guide/wazuh-server/step-by-step.html (seconde partie) pour Filebeat.

Elle est bien faite.


Nous procédons à l'installation grâce aux commandes suivantes sur la machine (A) hébergeant Wazuh-Manager: 

dnf install wazuh-indexer
dnf install filebeat
dnf install wazuh-dashboard


La documentation demande d'installer d'autres paquets; dans mon cas ils étaient déjà installés: 

dnf install coreutils initscripts chkconfig libcap


Création des certificats

Comme vu dans le schéma, les différents échangent se font via le réseau. Pour les sécuriser, ces échanges se font de façon cryptée sur base de certificats. Normalement cette machine ne doit pas être accessible à partie d'Internet. Ces certificats sont faits au plus simple; ils sont auto-signés au nom de la société Wazuh.

Le nécessaire vient avec le logiciel Wazuh-Indexer. Cet outil se trouve dans le répertoire "/usr/share/wazuh-indexer/plugins/opensearch-security/tools".

Anciennement on devait le télécharger sur le site de Wazuh via les commandes suivantes: 

curl -sO https://packages.wazuh.com/4.8/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.8/config.yml

Actuellement on est à la version 4.8 de Wazuh.

On le rend exécutable: 

chmod 700 wazuh-passwords-tool.sh

Si vous de disposez pas de l'utilitaire "curl", installez-le: 

dnf install curl


Les deux fichiers qui nous intéressent sont:

  • config.yml : fichier de configuration
  • wazuh-certs-tool.sh : script de création des clés et des certificats

On peut éventuellement les recopier dans un répertoire de travail.


La première tâche consiste à adapter le fichier de configuration avec un éditeur de texte. Dans le fichier "config.yml", on remplace les 3 lignes contenant le texte hors commentaire "ip: <indexer-node-ip>" par "ip: 127.0.0.1" car nous restons sur la même machine, "localhost".


On exécute alors le script: 

./wazuh-certs-tool.sh -A

S'il n'est pas exécutable, exécutez: 

bash ./wazuh-certs-tool.sh -A

Le sous-répertoire "wazuh-certificates" est créé contenant les clés et les certificats.

Chacun des 3 logiciels installés ci-dessus vont recevoir leurs clés et certificats. Dans la documentation, cette installation est plus compliquée mais elle se place dans le contexte plus général d'une installation sur les machines séparées. J'ai fait un script que voici que l'on peut nommer "copy.certificat.bat", il est à mettre au même endroit où se trouve le sous-répertoire "wazuh-certificates": 

#!/bin/bash
# Wazuh-Indexer
mkdir /etc/wazuh-indexer/certs
cp ./wazuh-certificates/node-1.pem /etc/wazuh-indexer/certs/
cp ./wazuh-certificates/node-1-key.pem /etc/wazuh-indexer/certs/
cp ./wazuh-certificates/admin.pem /etc/wazuh-indexer/certs/
cp ./wazuh-certificates/admin-key.pem /etc/wazuh-indexer/certs/
cp ./wazuh-certificates/root-ca.pem /etc/wazuh-indexer/certs/
mv -f /etc/wazuh-indexer/certs/node-1.pem /etc/wazuh-indexer/certs/indexer.pem
mv -f /etc/wazuh-indexer/certs/node-1-key.pem /etc/wazuh-indexer/certs/indexer-key.pem
chmod 500 /etc/wazuh-indexer/certs
chmod 400 /etc/wazuh-indexer/certs/*
chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs
# Wazuh-Dashboard
mkdir /etc/wazuh-dashboard/certs
cp ./wazuh-certificates/dashboard.pem /etc/wazuh-dashboard/certs/
cp ./wazuh-certificates/dashboard-key.pem /etc/wazuh-dashboard/certs/
cp ./wazuh-certificates/root-ca.pem /etc/wazuh-dashboard/certs/
chmod 500 /etc/wazuh-dashboard/certs
chmod 400 /etc/wazuh-dashboard/certs/*
chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs
# Filebeat
mkdir /etc/filebeat/certs
cp ./wazuh-certificates/wazuh-1.pem /etc/filebeat/certs/
cp ./wazuh-certificates/wazuh-1-key.pem /etc/filebeat/certs/
cp ./wazuh-certificates/root-ca.pem /etc/filebeat/certs/
mv -f /etc/filebeat/certs/wazuh-1.pem /etc/filebeat/certs/filebeat.pem
mv -f /etc/filebeat/certs/wazuh-1-key.pem /etc/filebeat/certs/filebeat-key.pem
chmod 500 /etc/filebeat/certs
chmod 400 /etc/filebeat/certs/*
chown -R root:root /etc/filebeat/certs

Rendez ce script exécutable: 

chmod 700 copy.certificat.bat

et exécutez-le: 

./copy.certificat.bat

Chacun des 3 logiciels a un répertoire de fichiers de configuration dans le répertoire "/etc". Sous ceux-ci un sous-répertoire "certs" est créé où viennent se placer les clés et certificats.

Il est crucial de bien respecter les droits et propriétaires; dans la documentation de l'ancienne version utilisant Elasticsearch et Kibana, des imperfections conduisaient ces services à un état d'erreur.


Configuration

Avant de lancer les services, il est utile de vérifier et, dans certains cas, de modifier certains fichiers de configuration.


API de Wazuh

Nous renvoyons à cet article pour la configuration de l'API de Wazuh qui est primordial pour cet module Web.


Wazuh-Indexer

Sa configuration se retrouve dans le fichier "/etc/wazuh-indexer/opensearch.yml".

Comme ce service doit interagir avec les services "filebeat.service" et "wazuh-dashboart.service" localement, on modifie dans ce fichier, la ligne: 

network.host: "0.0.0.0"

par la ligne: 

network.host: "127.0.0.1"

Dès lors, après le lancement du service "wazuh-indexer.service", les ports d'écoute seront locaux. Quand on lancera la commande: 

netstat -ntl

Nous aurons les lignes qui nous concernent, suivantes: 

tcp        0      0 127.0.0.1:9300          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:9200          0.0.0.0:*               LISTEN


Vérifiez que le propriétaire est bien "wazuh-indexer" et qu'il y a le droit d'accès: 

chmod 660 /etc/wazuh-indexer/opensearch.yml
chown wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/opensearch.yml


FileBeat

Ce module ne vient pas préconfiguré pour Wazuh. Il faut télécharger plusieurs fichiers et vérifier leurs droits d'accès.

Les commandes suivantes téléchargent deux fichiers de configuration dans le répertoire: "/etc/filebeat". Ces téléchargements sont pour la version 4.8 actuelle de Wazuh: 

curl -so /etc/filebeat/wazuh-template.json https://raw.githubusercontent.com/wazuh/wazuh/v4.8.0/extensions/elasticsearch/7.x/wazuh-template.json
curl -so /etc/filebeat/filebeat.yml https://packages.wazuh.com/4.8/tpl/wazuh/filebeat/filebeat.yml
chmod 644 /etc/filebeat/wazuh-template.json
chmod 644 /etc/filebeat/filebeat.yml

Comme ce service doit interagir avec le services "wazuh-indexer.service" localement, on vérifie dans le fichier "/etc/filebeat/filebeat.yml", la ligne: 

hosts: ["127.0.0.1:9200"]

La commande qui suit, télécharge toute une arborescence qui ajoute les informations nécessaires pour l'envoi des alertes au service "wazuh-indexer.service": 

curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.4.tar.gz | tar -xvz -C /usr/share/filebeat/module

Dans cette partie ajoutée, j'ai ajouté une ligne au fichier "/usr/share/filebeat/module/wazuh/alerts/manifest.yml". Il défini quel fichier, ce service doit traiter. Par défaut, c'est le fichier des alertes "/var/ossec/logs/alerts/alerts.json". J'ai ajouté le fichier "/var/ossec/logs/alerts/alertsold.json".

Voici le contenu de ce fichier de configuration: 

module_version: 0.1
 
var:
 - name: paths
   default:
     - /var/ossec/logs/alerts/alerts.json
     - /var/ossec/logs/alerts/alertsold.json
 - name: index_prefix
   default: wazuh-alerts-4.x-
 
input: config/alerts.yml
 
ingest_pipeline: ingest/pipeline.json

On crée le fichier vide "/var/ossec/logs/alerts/alertsold.json". Le nom du fichier a peu d'importance.

Il m'a servi dans divers cas. A une période, le service Filebeat s'arrêtait dans raison. Dans l'intervalle, plusieurs alertes ne sont pas traitées et celles des jours précédents sont archivées et compressées dans un sous-répertoire en fonction de l'année, le mois et le jour. Or Filebeat ne traite que les alertes du jour.

Pour régler cette perte, on décompresse le ou les fichiers concernées et on place leur contenu dans le fichier "/var/ossec/logs/alerts/alertsold.json". On surveille la fin de l'exécution par l'activité du CPU et des disques ou via le WUI. Dès que c'est fait, on vide à nouveau ce fichier. Eventuellement par sécurité, on redémarre le service "filebeat.service" pour être sûr que l'offset soit bien remis à 0.

Par le même moyen, j'ai pu charger les alertes des mois précédents la mise en route du WUI.


Attention, ne chargez pas trop de mois, 6 par exemple. Par défaut, Wazuh-Indexer ne peut prendre en compte que 1000 segments d'indexations ("shards"). Nous verrons ce problème lors de la maintenance.

Autre précaution importante: Si vous chargez des anciennes données par ce moyen, ce fichier alternatif ne doit pas contenir de données déjà chargées; elles seront en double.


Filebeat doit s'authentifier auprès de Wazuh-Indexer pour pouvoir y injecter les alertes. Il utilise l'utilisateur "admin" ajouté lors de l'initialisation de Wazuh-Indexer. Le mot de passe par défaut est "admin". On le changera par la suite. Ce couple, utilisateur-mot de passe, doit être stocké de façon cryptée dans un "magasin".

On crée le fichier (et le répertoire) "/var/lib/filebeat/filebeat.keystore": 

filebeat keystore create

On y stocke le nom de l'utilisateur et son mot de passe: 

echo admin | filebeat keystore add username --stdin --force
echo admin | filebeat keystore add password --stdin --force


Wazuh-Dashboard

Sa configuration se retrouve dans le fichier "/etc/wazuh-dashboard/opensearch_dashboards.yml".

Comme cette machine héberge le service Apache et donc utilise le port d'écoute réseau TCP 443 et que Wazuh-Dashboard utilise ce même port par défaut, il faut le changer. Nous avons opté pour le port TCP 444.

Dans ce fichier, trois lignes sont à vérifier, une est à modifier, celle reprise en gras ci-dessous. L'interface d'utilisation comme WUI ouvert à tous, son port réseau d'écoute ("444") et l'interface d'interaction avec Wazuh-Indexer. 

server.host: 0.0.0.0
server.port: 444
opensearch.hosts: https://localhost:9200

Dès lors, après le lancement du service "wazuh-dashboard.service", le port d'écoute sera ouvert. Quand on lancera la commande: 

netstat -ntl

Nous aurons la ligne qui nous concerne, suivante: 

tcp        0      0 0.0.0.0:444             0.0.0.0:*               LISTEN


L'application "Wazuh-Dashboard" doit pouvoir consulter les informations de Wazuh-Manager via son API. Il utilise l'utilisateur "wazuh-wui". Le mot de passe de cet utilisateur est écrit dans le fichier de configuration "/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml". Par défaut, ce mot de passe est "wazuh-wui". Si vous l'avez changé, il faut l'adapter en conséquence.

Au bas de ce fichier, dans la section "hosts", on adapte le mot de passe: 

hosts:
 - default:
    url: https://localhost
    port: 55000
    username: wazuh-wui
    password: wazuh-wui
    run_as: false

On y remarque les informations de la machine à contacter et le port de connexion pour accéder à l'API de Wazuh ainsi que le nom de l'utilisateur utilisé.


Wazuh-Manager

Une section a été récemment modifiée. Dans le fichier "/var/ossec/etc/ossec.conf", la balise "<vulnerability-detector>" a été modifiée et fortement réduite. Elle se limite aux lignes suivante: 

 <vulnerability-detection>
   <enabled>yes</enabled>
   <index-status>yes</index-status>
   <feed-update-interval>60m</feed-update-interval>
 </vulnerability-detection>


Une autre section est venue récemment s'ajouter en relation avec Wazuh-Indexer et FileBeat: 

 <indexer>
   <enabled>yes</enabled>
   <hosts>
     <host>https://127.0.0.1:9200</host>
   </hosts>
   <ssl>
     <certificate_authorities>
       <ca>/etc/filebeat/certs/root-ca.pem</ca>
     </certificate_authorities>
     <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
     <key>/etc/filebeat/certs/filebeat-key.pem</key>
   </ssl>
 </indexer>

On y a modifié la référence d'accès au service Wazuh-Indexer vers l'adresse IP "127.0.0.1".


On doit ensuite enregistrer le nom d'utilisateur et le mot de passe d'accès à Wazuh-Indexer dans des fichiers sécurisé de Wazuh-Manager. Par défaut ils sont respectivement "admin" et "admin". Il est préférable que le mot de passe "admin" soit changé. On le verra par la suite. 

/var/ossec/bin/wazuh-keystore -f indexer -k username -v admin
/var/ossec/bin/wazuh-keystore -f indexer -k password -v admin


Configurer le mur de feu ou FireWall

La majorité du trafic réseau se fait en local et donc ne pose pas de problème avec le Firewall de la machine qui héberge tous ces services. Seul le port TCP 444 a besoin d'être ouvert pour que nous puissions l'utiliser.

Voici la règle pour IPTABLES à ajouter sur le serveur dans le fichier "/etc/sysconfig/iptables": 

-A INPUT -p tcp -m tcp --dport 444 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT

Ici on ouvre l'accès à tous le LAN local. On peut être plus restrictif.


Activer et lancer les services

Il est temps de lancer les différents services.


Iptables

On relance le Firewall: 

systemctl restart iptables.service

Vérifiez son bon fonctionnement: 

systemctl status iptables.service

et que les règles sont bien chargées: 

iptables -n -L

Wazuh-Manager

Suite à notre changement à l'API de Wazuh-Manager, il faut le recharger: 

systemctl restart wazuh-manager.service

Vérifiez son bon fonctionnement: 

systemctl status wazuh-manager.service


Wazuh-Indexer

On active et lançons Wazuh-Indexer: 

systemctl enable wazuh-indexer.service
systemctl start wazuh-indexer.service

Vérifiez son bon fonctionnement: 

systemctl status wazuh-indexer.service


Initialisation de la base de données de Wazuh-Indexer

A ce stade, suite au premier lancement, il faut initialiser toute la base de données de Wazuh-Indexer sur le localhost: 

/usr/share/wazuh-indexer/bin/indexer-security-init.sh -ho 127.0.0.1


Filebeat

On active et lançons Filebeat: 

systemctl enable filebeat.service
systemctl start filebeat.service

Vérifiez son bon fonctionnement: 

systemctl status filebeat.service


Wazuh-Dashboard

On active et lançons Wazuh-Dashboard: 

systemctl enable wazuh-dashboard.service
systemctl start wazuh-dashboard.service

Vérifiez son bon fonctionnement: 

systemctl status wazuh-dashboard.service


Vérifier et tester

A ce stade, on vérifie que tout fonctionne.


Wazuh-Manager

On vérifie que les ports TCP 1514, 1515 et 50000 sont à l'écoute: 

netstat -ntl

Nous avons les lignes qui nous concernent, suivantes: 

tcp        0      0 0.0.0.0:1514            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1515            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:55000         0.0.0.0:*               LISTEN


Wazuh-Indexer

Si tout se passe bien, vérifiez les ports TCP 9200 et 9300 à l'écoute: 

netstat -ntl

Nous avons les lignes qui nous concernent, suivantes: 

tcp        0      0 127.0.0.1:9300          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:9200          0.0.0.0:*               LISTEN

On teste la connexion: 

curl -k -u admin:admin https://127.0.0.1:9200

qui donne dans mon cas: 

{
 "name" : "node-1",
 "cluster_name" : "wazuh-cluster",
 "cluster_uuid" : "g6pOvhmY1x-3BNSXfXJzMw",
 "version" : {
   "number" : "7.10.2",
   "build_type" : "rpm",
   "build_hash" : "e505b103a7c03ae8f26d675172402f2f8144ef0f",
   "build_date" : "2021-01-14T03:38:06.881862Z",
   "build_snapshot" : false,
   "lucene_version" : "8.10.1",
   "minimum_wire_compatibility_version" : "6.8.0",
   "minimum_index_compatibility_version" : "6.0.0-beta1"
 },
 "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

Autre commande: 

curl -k -u admin:admin https://127.0.0.1:9200/_cat/nodes?v

qui donne: 

ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           28          34  -1    0.31    0.32     0.27 dimr      *      node-1


Filebeat

On le teste: 

filebeat test output

qui donne: 

elasticsearch: https://127.0.0.1:9200...
 parse url... OK
 connection...
   parse host... OK
   dns lookup... OK
   addresses: 127.0.0.1
   dial up... OK
 TLS...
   security: server's certificate chain verification is enabled
   handshake... OK
   TLS version: TLSv1.3
   dial up... OK
 talk to server... OK
 version: 7.10.2


Wazuh-Dashboard

Si tout se passe bien, vérifiez le port TCP 444 à l'écoute: 

netstat -ntl

Nous avons la ligne qui nous concerne, suivante: 

tcp        0      0 0.0.0.0:444             0.0.0.0:*               LISTEN

Enfin on peut accéder à l'interface à partir d'un browser sur votre PC: 

https://192.168.1.110:444

Dans l'écran de connexion, le nom d'utilisateur est "admin" et son mot de passe est "admin".


Configurations avancées de Wazuh-Dashboard

Nous présentons ici quelques configurations alternatives de Wazuh-Dashboard.


Certificats personnalisés

Dans le fichier "/etc/wazuh-dashboard/opensearch_dashboards.yml", les trois lignes suivantes définissent le nécessaire pour une connexion sécurisée via le port TCP 444 entre le serveur Wazuh-Dashboard et le browser de votre PC. Ce sont une clé privée et un certificat publique auto signé au nom de la société Wazuh: 

server.ssl.enabled: true
server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"

Il peut être intéressant que ce certificat soit au nom de votre serveur ou de votre société. Pour cela je vous renvoie aux articles traitant des Certificats.


Le point Certificat auto signé est semblable à celui existant. Mais nous avons un certificat publique au nom du serveur, "serverdb.home.dom" selon l'exemple. Selon l'exemple de ce chapitre, les trois lignes deviennent: 

server.ssl.enabled: true
server.ssl.key: "/etc/pki/tls/private/localhost.key"
server.ssl.certificate: "/etc/pki/tls/certs/localhost.crt"
  • Le fichier "localhost.key" est la clé privée du serveur.
  • Le fichier "localhost.crt" est le certificat publique auto signé.


Si nous voulons un certificat publique non auto signé au nom du serveur, nous nous reportons au point Création d'une CA privée (V1). Dans ce cas, le certificat publique est validé par notre propre autorité de certification (CA) au nom de notre serveur. Selon l'exemple de ce chapitre, les trois lignes deviennent: 

server.ssl.enabled: true
server.ssl.key: "/etc/pki/home/private/localhost.key"
server.ssl.certificate: "/etc/pki/home/certs/serverdb.home.pem"
  • Le fichier "localhost.key" est la clé privée du serveur.
  • Le fichier "serverdb.home.pem" est une chaine contenant deux certificats publiques: le certificat publique de notre autorité de certification (CA) et le certificat publique du serveur validé par notre autorité de certificat.


Ces fichiers sont les mêmes que l'on doit utiliser pour le serveur Web Apache: variables "SSLCertificateKeyFile" et "SSLCertificateFile".


Pour une question de sécurité, je ne recommande pas que ce serveur soit accessible à partir d'Internet. Mais le principe est le même. Si on utilise des certificats officiels Let's Encrypt, nous utilisons:

  • la clé privée du serveur "/etc/letsencrypt/live/<DNS publique de votre serveur>/privkey.pem"
  • la chaîne de certificats publiques "/etc/letsencrypt/live/<DNS publique de votre serveur>/fullchain.pem" contenant trois certificats publiques (celui du serveur, celui de la CA et l'intermédiaire).


Note: Soyez attentif aux privilèges. Le service "wazuh-dashboard.service" est lancé sous la responsabilité de l'utilisateur Unix "wazuh-dashboard". Il doit avoir accès en lecture à ces clé et certificats.


Wazuh-Dashboard derrière le proxy d'Apache

Dans notre configuration de Wazuh-Dashboad, nous sommes obligés de spécifier le port TCP 444 dans l'URL d'accès car le port TCP 443 classique pour le protocole HTTPS est utilisé par le service Apache.

Nous allons intercepter le trafic du port TCP 444 pour le récupérer dans Apache et le transmettre au client via le port TCP 443 (HTTPS). Le changement de configuration se fait dans Wazuh-Dashboard et dans Apache.


Du côté de Wazuh-Dashboard, les changements se font dans le fichier de configuration "/etc/wazuh-dashboard/opensearch_dashboards.yml": 

server.host: 127.0.0.1
server.port: 444
opensearch.hosts: https://localhost:9200
opensearch.ssl.verificationMode: certificate
#opensearch.username:
#opensearch.password:
opensearch.requestHeadersWhitelist: ["securitytenant","Authorization"]
opensearch_security.multitenancy.enabled: false
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
server.ssl.enabled: false
server.basePath: "/wazuh"
server.rewriteBasePath: true
opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/root-ca.pem"]
uiSettings.overrides.defaultRoute: /app/wazuh

On garde le port TCP 444 ("server.port: 444") mais comme le traffic se fait entre Wazuh-Dashboard et Apache sur la même machine, on limite l'interface au "localhost" ("server.host: 127.0.0.1"). Ce transit interne se fera non crypté ("server.ssl.enabled: false") et donc on n'a pas besoin des clé et certificats. Le cryptage se fera sous Apache avec les certificats du serveur.

Sous Apache, nous avons déjà une arborescence et une racine; il faut donc réécrire la sortie vers un dossier non existant autre que la racine ("server.rewriteBasePath: true"). Nous l'avons nommé "wazuh" ("server.basePath: "/wazuh" "). L'URL d'accès devient dès lors: http://localhost:444/wazuh

Après le lancement du service "wazuh-dashboard.service", le port d'écoute sera ouvert mais aura changé. Quand on lancera la commande: 

netstat -ntl

Nous aurons la ligne qui nous concerne, suivante: 

tcp        0    127 0.0.0.1:444             0.0.0.0:*               LISTEN

Evidemment il n'est plus nécessaire d'ouvrir ce port dans le FireWall.


Du côté d'Apache, il faut s'assurer que les modules "proxy" sont actifs; sous Fedora, c'est le cas par défaut. Il faut repérer le fichier lié au cryptage SSL. Ce fichier est par défaut "/etc/httpd/conf.d/ssl.conf". Voici un extrait, le plus important pour notre cas: 

Listen 443 https
<VirtualHost _default_:443>
 SSLEngine on
 SSLCertificateKeyFile /etc/pki/home/private/localhost.key
 SSLCertificateFile /etc/pki/home/certs/serverdb.home.pem
  
 ProxyPreserveHost on
 ProxyRequests on
 ProxyPass /wazuh http://localhost:444/wazuh
 ProxyPassReverse /wazuh http://localhost:444/wazuh
</VirtualHost>

On retrouve les clé et certificats utilisés dans le chapitre précédent. Le texte en gras concerne la configuration Proxy. On retrouve l'URL d'accès à Wazuh-Dashboard qui renvoie vers le dossier "/wazuh" d'Apache. L'URL d'Apache pour accéder au WUI de Wazuh devient: https://serverdb.home.dom/wazuh pour le serveur portant le nom de "serverdb.home.dom". Bien sûr l'URL https://serverdb.home.dom:444/ n'est plus d'actualité.


Utilisateurs

Lors de l'installation, de nombreux utilisateurs sont créés pour Wazuh-Indexer. Nous en avons rencontré un, le plus connu et utilisé par le logiciel Filebeat: "admin".


On peut en obtenir la liste des utilisateurs avec la commande suivante en utilisant l'API de Wazuh-Indexer: 

curl --silent -X GET -k -u admin:admin https://localhost:9200/_opendistro/_security/api/internalusers | python -m json.tool

Cet API nécessite une authentification (option "-u <utilisateur>:<mot de passe>"). Nous avonsd gardé l'utilisateur "admin" avec son mot de passe par défaut vu plus haut "admin". L'outil de "python", "json.tool" permet de rendre plus lisible le résultat au format JSON.

On obtient la sortie suivante: 

{
   "wazuh_admin": {
       "hash": "",
       "reserved": true,
       "hidden": false,
       "backend_roles": [],
       "attributes": {},
       "opendistro_security_roles": [],
       "static": false
   },
   "logstash": {
       "hash": "",
       "reserved": false,
       "hidden": false,
       "backend_roles": [
           "logstash"
       ],
       "attributes": {},
       "description": "Demo logstash user",
       "opendistro_security_roles": [],
       "static": false
   },
   "wazuh_user": {
       "hash": "",
       "reserved": true,
       "hidden": false,
       "backend_roles": [],
       "attributes": {},
       "opendistro_security_roles": [],
       "static": false
   },
   "snapshotrestore": {
       "hash": "",
       "reserved": false,
       "hidden": false,
       "backend_roles": [
           "snapshotrestore"
       ],
       "attributes": {},
       "description": "Demo snapshotrestore user",
       "opendistro_security_roles": [],
       "static": false
   },
   "admin": {
       "hash": "",
       "reserved": true,
       "hidden": false,
       "backend_roles": [
           "admin"
       ],
       "attributes": {},
       "description": "Demo admin user",
       "opendistro_security_roles": [],
       "static": false
   },
   "kibanaserver": {
       "hash": "",
       "reserved": true,
       "hidden": false,
       "backend_roles": [],
       "attributes": {},
       "description": "Demo kibanaserver user",
       "opendistro_security_roles": [],
       "static": false
   },
   "kibanaro": {
       "hash": "",
       "reserved": false,
       "hidden": false,
       "backend_roles": [
           "kibanauser",
           "readall"
       ],
       "attributes": {
           "attribute1": "value1",
           "attribute2": "value2",
           "attribute3": "value3"
       },
       "description": "Demo kibanaro user",
       "opendistro_security_roles": [],
       "static": false
   },
   "readall": {
       "hash": "",
       "reserved": false,
       "hidden": false,
       "backend_roles": [
           "readall"
       ],
       "attributes": {},
       "description": "Demo readall user",
       "opendistro_security_roles": [],
       "static": false
   }
}

On peut obtenir aussi cette liste via le WUI de Wazuh. On clique en haut à gauche, sur l'icône représentée par trois barres horizontales qui donne accès au menu. Sous le poste "OpenSearch Plugins", on choisit "Security"; on passe dans le menu de gauche, à la ligne "Internal Users".

A ce stade, tous ces utilisateurs ont un mot de passe égal au nom d'utilisateur: par exemple, l'utilisateur "admin" a comme mot de passe "admin". Ils sont non sécurisés. Il faut donc leur attribuer un mot de passe moins trivial.


Changement du mot de passe des utilisateurs

Wazuh dispose d'un utilitaire pour effectuer cette tâche.

On peut le télécharger sur le site du concepteur grâce à cette commande: 

curl -so wazuh-passwords-tool.sh https://packages.wazuh.com/4.3/wazuh-passwords-tool.sh

Actuellement on est à la version 4.3 de Wazuh.

On le rend exécutable: 

chmod 700 wazuh-passwords-tool.sh


Comme on a installé le paquet "wazuh-indexer", il se trouve aussi dans le répertoire "/usr/share/wazuh-indexer/plugins/opensearch-security/tools".

Cet utilitaire vérifie l'OS. Dans notre cas, pour les distributions sous l'égide de Red Had, c'est l'utilitaire d'installation "yum" dont la présence est testée. Or sous Fedora, depuis quelques versions, c'est l'utilitaire "dnf" qui est préféré; l'utilitaire "yum" n'est plus installé par défaut. Par conséquence, cet utilitaire est inutilisable.

Pour pouvoir l'utiliser soit vous installez l'utilitaire "yum": 

dnf install yum

soit vous changez toutes les occurrences du mot "yum" par le mot "dnf" à l'aide d'un éditeur de texte.


En correspondance avec le script utilisant l'API, la commande utilisant cet utilitaire devient: 

./wazuh-passwords-tool.sh -u admin -p "Pw-Bidon-pour-Admin"

Les options:

  • -u suivi du nom de l'utilisateur dont on veut changer le mot de passe
  • -p suivi du nouveau mot de passe désiré.


Notons que si nous changeons le mot de passe de l'utilisateur "admin", il faut redémarrer le service "filebeat.service" car l'utilitaire adapte ce changement dans son magazin (keystore) comme vu plus haut pour pouvoir s'authentifier lors de l'injection les alertes dans Wazuh-Indexer.

Il faut faire cette même tâche pour tous les autres utilisateurs.


Maintenance

Cette partie regroupe quelques problèmes rencontrés sur cet WUI.




→ retour à Wazuh: HIDS

Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Wazuh-WUI&oldid=8415 »