LINUX:Wazuh-WUI

(30 versions intermédiaires par le même utilisateur non affichées)

Ligne 38 :

dnf install wazuh-indexer

dnf install filebeat

dnf install wazuh-~~dashboad~~

dnf install wazuh-dashboard

Ligne 51 :

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:

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.

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/filebeat.yml

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

----

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:

Ligne 193 :

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

Ligne 242 :

Ligne 245 :

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>

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

----

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

----

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.

Ligne 311 :

Ligne 350 :

Nous avons les lignes qui nous concernent, suivantes:

----

tcp 0 0 ~~127~~.0.0.1:1514 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1514 0.0.0.0:* LISTEN

tcp 0 0 ~~127~~.0.0.1:1515 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

----

Ligne 385 :

Ligne 424 :

----

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

<nowiki>https://192.168.1.~~100~~: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".

=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

SSLEngine on

SSLCertificateKeyFile /etc/pki/home/private/localhost.key

SSLCertificateFile /etc/pki/home/certs/serverdb.home.pem

'''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=

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 <nowiki>https://localhost:9200/_opendistro/_security/api/internalusers</nowiki> | 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 <nowiki>https://packages.wazuh.com/4.3/wazuh-passwords-tool.sh</nowiki>

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.

=[[LINUX:Wazuh-WUI-Maintenance|Maintenance]]=

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

@@ Ligne 38 : / Ligne 38 : @@
   dnf install wazuh-indexer
   dnf install filebeat
-  dnf install wazuh-dashboad
+  dnf install wazuh-dashboard
@@ Ligne 51 : / Ligne 51 : @@
 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:
@@ 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.
-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/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":
 ----
-  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:
@@ Ligne 193 : / Ligne 193 : @@
 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 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.
@@ Ligne 242 : / Ligne 245 : @@
 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>
+      <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>
+----
+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.
@@ Ligne 311 : / Ligne 350 : @@
 Nous avons les lignes qui nous concernent, suivantes:
 ----
-  tcp        0      0 127.0.0.1:1514          0.0.0.0:*               LISTEN
+  tcp        0      0 0.0.0.0:1514            0.0.0.0:*               LISTEN
-  tcp        0      0 127.0.0.1:1515          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
 ----
@@ Ligne 385 : / Ligne 424 : @@
 ----
 Enfin on peut accéder à l'interface à partir d'un browser sur votre PC:
-  <nowiki>https://192.168.1.100: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".
+=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=
+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 <nowiki>https://localhost:9200/_opendistro/_security/api/internalusers</nowiki> | 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 <nowiki>https://packages.wazuh.com/4.3/wazuh-passwords-tool.sh</nowiki>
+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.
+=[[LINUX:Wazuh-WUI-Maintenance|Maintenance]]=
+Cette partie regroupe quelques problèmes rencontrés sur cet WUI.

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

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