« LINUX:Wazuh-WUI » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 257 : | Ligne 257 : | ||
Vérifiez son bon fonctionnement: | Vérifiez son bon fonctionnement: | ||
systemctl status wazuh-manager.service | systemctl status wazuh-manager.service | ||
Ligne 267 : | Ligne 265 : | ||
Vérifiez son bon fonctionnement: | Vérifiez son bon fonctionnement: | ||
systemctl status wazuh-indexer.service | 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: | 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 | /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 | |||
==Wazuh-Indexer== | |||
Si tout se passe bien, vérifiez les ports TCP 9200 et 9300 à l'écoute: | Si tout se passe bien, vérifiez les ports TCP 9200 et 9300 à l'écoute: | ||
netstat -ntl | netstat -ntl | ||
On teste la connexion: | |||
curl -k -u admin:admin <nowiki>https://127.0.0.1:9200</nowiki> | |||
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: <nowiki>https://opensearch.org/</nowiki>" | |||
} | |||
---- | |||
Autre commande: | |||
curl -k -u admin:admin <nowiki>https://127.0.0.1:9200/_cat/nodes?v</nowiki> | |||
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== | ==Filebeat== | ||
On le teste: | |||
filebeat test output | |||
qui donne: | |||
---- | |||
elasticsearch: <nowiki>https://127.0.0.1:9200</nowiki>... | |||
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 | |||
Enfin on peut accéder à l'interface à partir d'un browser sur votre PC: | |||
https://192.168.1.100:444 | |||
Version du 26 novembre 2022 à 19:24
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 filebeat
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.3/wazuh-certs-tool.sh curl -sO https://packages.wazuh.com/4.3/config.yml
Actuellement on est à la version 4.3 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/ #mv -f /etc/wazuh-dashboard/certs/dashboard.pem /etc/wazuh-dashboard/certs/dashboard.pem #mv -f /etc/wazuh-dashboard/certs/dashboard-key.pem /etc/wazuh-dashboard/certs/dashboard-key.pem 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":
curl -so /etc/filebeat/wazuh-template.json https://raw.githubusercontent.com/wazuh/wazuh/4.3/extensions/elasticsearch/7.x/wazuh-template.json curl -so /etc/filebeat/filebeat.yml https://packages.wazuh.com/4.3/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.2.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".
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.
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 concernent, suivante:
tcp 0 0 0.0.0.0:444 0.0.0.0:* LISTEN
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
Wazuh-Indexer
Si tout se passe bien, vérifiez les ports TCP 9200 et 9300 à l'écoute:
netstat -ntl
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
Enfin on peut accéder à l'interface à partir d'un browser sur votre PC:
https://192.168.1.100:444