« LINUX:Wazuh-WUI-Maintenance » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (9 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 3 : | Ligne 3 : | ||
---- | ---- | ||
=But= | =But= | ||
Cette partie regroupe quelques problèmes rencontrés sur cet WUI. | |||
| Ligne 36 : | Ligne 36 : | ||
=Shards= | =Shards= | ||
Dans la base de données de Wazuh-Indexer, les différentes alertes sont rassemblées par paquets nommés "shards". Le premier découpage est fait par jour-mois-année; nommé "wazuh-alerts-4.x-<année>.<mois>.<jour>". Par défaut, il y a 3 paquets par jour et pas de répliqua. Donc pour une année de 365 jours, nous avons 365*3=1095 paquets. En plus, il y a 2 autres paquets par semaine, nommés "wazuh-monitoring-<année>.<n° de semaine>w" et "wazuh-statistics-<année>.<n° de semaine>w". Ce qui nous fait 52*2=104 paquets. Enfin il y a 4 paquets commençants par un point. | Dans la base de données de Wazuh-Indexer, les différentes alertes sont rassemblées par paquets nommés "shards". Le premier découpage est fait par jour-mois-année; nommé "wazuh-alerts-4.x-<année>.<mois>.<jour>". Par défaut, il y a 3 paquets par jour et pas de répliqua. Le nombre de paquets par jour et de répliquas sont paramétrables. Donc pour une année de 365 jours, nous avons 365*3=1095 paquets. En plus, il y a 2 autres paquets par semaine, nommés "wazuh-monitoring-<année>.<n° de semaine>w" et "wazuh-statistics-<année>.<n° de semaine>w". Ce qui nous fait 52*2=104 paquets. Enfin il y a 4 paquets commençants par un point. | ||
(.kibana_1, .opendistro-reports-definitions, .opendistro-reports-instances, .opendistro_security) | (.kibana_1, .opendistro-reports-definitions, .opendistro-reports-instances, .opendistro_security) | ||
'''Ces 4 là ne doivent en aucun cas être effacés !!!''' Au total pour une année, nous avons 1203 paquets. | '''Ces 4 là ne doivent en aucun cas être effacés !!!''' Au total pour une année, nous avons 1203 paquets. | ||
| Ligne 81 : | Ligne 81 : | ||
"number_of_data_nodes" : 1, | "number_of_data_nodes" : 1, | ||
"discovered_master" : true, | "discovered_master" : true, | ||
"active_primary_shards" : | "active_primary_shards" : 371, | ||
"active_shards" : ''' | "active_shards" : '''371''', | ||
"relocating_shards" : 0, | "relocating_shards" : 0, | ||
"initializing_shards" : 0, | "initializing_shards" : 0, | ||
| Ligne 95 : | Ligne 95 : | ||
Dans l'exemple, le chargement est arrivé à son terme ("active_shards_percent_as_number" : 100.0); il est à 100%. | Dans l'exemple, le chargement est arrivé à son terme ("active_shards_percent_as_number" : 100.0); il est à 100%. | ||
Le nombre de parquets est de | Le nombre de parquets est de 371 ("active_primary_shards" : 371). | ||
S'il y a des paquets qui ne sont pas assignés ("unassigned_shards") en fin de phase (son nombre restant stable), il y a un problème. | S'il y a des paquets qui ne sont pas assignés ("unassigned_shards") en fin de phase (son nombre restant stable), il y a un problème. | ||
| Ligne 103 : | Ligne 103 : | ||
=Elimination de Shards= | |||
En conséquence des différents points évoqués ci-dessus, il faut limiter le nombre de paquets présents. La première question a se poser est: Combien de temps en arrière désirons-nous revenir en arrière? J'ai choisi 3 mois plus le mois en cours. Périodiquement, il faut éliminer les plus anciens. | |||
Voici une procédure en exemple: | |||
---- | |||
#!/bin/bash | |||
ANNEE=2022 | |||
MOIS=09 | |||
curl --silent -X GET -k -u admin:admin <nowiki>https://localhost:9200/_cat/shards</nowiki> | grep "\-$ANNEE.$MOIS." | awk {'print $1'} | sort -u > delete.shards.txt | |||
cat delete.shards.txt | xargs -i curl -k -XDELETE -u admin:admin <nowiki>"https://localhost:9200/{}"</nowiki> | |||
---- | |||
Avant de lancer ce script, on adapte les variables "ANNEE" et "MOIS" en fonction de l'année et du mois dont on veut éliminer les paquets. La procédure consiste à créer une liste des paquets suivant la commande vue plus haut. On sélectionne les paquets à éliminer que l'on trie en effaçant les doublons. Le résultat est placé dans un fichier. Le contenu de ce fichier est dirigé vers une commande qui permet de détruire ces paquets. | |||
Voici le contenu du fichier "delete.shards.txt": | |||
---- | |||
wazuh-alerts-4.x-2022.09.01 | |||
wazuh-alerts-4.x-2022.09.02 | |||
wazuh-alerts-4.x-2022.09.03 | |||
wazuh-alerts-4.x-2022.09.04 | |||
wazuh-alerts-4.x-2022.09.05 | |||
wazuh-alerts-4.x-2022.09.06 | |||
wazuh-alerts-4.x-2022.09.07 | |||
wazuh-alerts-4.x-2022.09.08 | |||
wazuh-alerts-4.x-2022.09.09 | |||
wazuh-alerts-4.x-2022.09.10 | |||
wazuh-alerts-4.x-2022.09.11 | |||
wazuh-alerts-4.x-2022.09.12 | |||
wazuh-alerts-4.x-2022.09.13 | |||
wazuh-alerts-4.x-2022.09.14 | |||
wazuh-alerts-4.x-2022.09.15 | |||
wazuh-alerts-4.x-2022.09.16 | |||
wazuh-alerts-4.x-2022.09.17 | |||
wazuh-alerts-4.x-2022.09.18 | |||
wazuh-alerts-4.x-2022.09.19 | |||
wazuh-alerts-4.x-2022.09.20 | |||
wazuh-alerts-4.x-2022.09.21 | |||
wazuh-alerts-4.x-2022.09.22 | |||
wazuh-alerts-4.x-2022.09.23 | |||
wazuh-alerts-4.x-2022.09.24 | |||
wazuh-alerts-4.x-2022.09.25 | |||
wazuh-alerts-4.x-2022.09.26 | |||
wazuh-alerts-4.x-2022.09.27 | |||
wazuh-alerts-4.x-2022.09.28 | |||
wazuh-alerts-4.x-2022.09.29 | |||
wazuh-alerts-4.x-2022.09.30 | |||
---- | |||
Cette procédure peut être adaptée en fonction des besoins. Par exemple pour détruire les paquets d'une année entière. | |||
Pour effacer les paquets hebdomadaires, le n° de semaine peut être obtenu via Excel suivant cette formule: | |||
=NO.SEMAINE(DATE(2022;09;1)) | |||
Ici pour le 1 septembre 2022 qui donne 36. Toutes les semaines en dessous de ce n° peuvent être éliminées. | |||
Voici une procédure en exemple: | |||
---- | |||
#!/bin/bash | |||
ANNEE=2022 | |||
NOSEMAINE="32 33 34 35" | |||
curl --silent -X GET -k -u admin:admin <nowiki>https://localhost:9200/_cat/shards</nowiki> | awk {'print $1'} | sort -u > delete.shards.txt | |||
grep wazuh-monitoring-$ANNEE. delete.shards.txt > temp.txt | |||
grep wazuh-statistics-$ANNEE. delete.shards.txt >> temp.txt | |||
for i in $NOSEMAINE | |||
do | |||
echo $i | |||
grep .${i}w temp.txt | | xargs -i curl -k -XDELETE -u admin:admin <nowiki>"https://localhost:9200/{}"</nowiki> | |||
done | |||
rm -f temp.txt | |||
---- | |||
Voici les paquets éliminés: | |||
---- | |||
wazuh-monitoring-2022.32w | |||
wazuh-monitoring-2022.33w | |||
wazuh-monitoring-2022.34w | |||
wazuh-monitoring-2022.35w | |||
wazuh-statistics-2022.32w | |||
wazuh-statistics-2022.33w | |||
wazuh-statistics-2022.34w | |||
wazuh-statistics-2022.35w | |||
---- | |||
=Les cas des statuts UNASSIGNED= | |||
Normalement tous les paquets ont un statut "STARTED". | |||
Avant juin 2022, il y avait des paquets au statut "UNASSIGNED". | |||
La commande d'extraction du nom des paquets: | |||
curl --silent -X GET -k -u admin:admin <nowiki>https://localhost:9200/_cat/shards</nowiki> | |||
affichaient des entrées du style: | |||
---- | |||
security-auditlog-2022.05.28 0 p STARTED 228 458kb 127.0.0.1 node-1 | |||
security-auditlog-2022.05.28 0 r UNASSIGNED | |||
---- | |||
Ceci était dû à une entrée inappropriée dans le fichier de configuration de Wazuh-Indexer: "/etc/wazuh-indexer/opensearch.yml": | |||
---- | |||
plugins.security.audit.type: internal_opensearch | |||
---- | |||
Le fait d'éliminer cette ligne et de redémarrer le service "wazuh-indexer.service" a éliminé toute nouvelle apparition de ces lignes. | |||
Il a fallu éliminer les paquets qui ne pouvaient pas s'activer, en filtrant la liste des paquets sur le mot "UNASSIGNED". | |||
En fait lors de mises à jour des logiciels, toute nouvelle version d'un fichier de configuration est renommé avec l'ajout de l'extension ".rpmnew". Il faut alors repérer ce qui a changé. Ce plugin n'était plus renseigné dans le fichier de configuration mis à jour. | |||