LINUX:Wazuh-WUI
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.
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.