LINUX:Wazuh-WUI-Maintenance
But
Cette partie regroupe quelques problèmes rencontrés sur cet WUI.
Chargements d'alertes complémentaires
Lors de la description de la configuration de Filebeat, dans l'article parent, nous avions ajouté une ligne faisant référence à un autre fichier à traiter.
Dans le fichier "/usr/share/filebeat/module/wazuh/alerts/ manifest.yml", nous avons ajouté la ligne:
- /var/ossec/logs/alerts/alertsold.json
En temps normal, ce fichier est vide.
Si par exemple, le service "filebeat.service" s'est arrêté quelles heures ou jours, les données des jours précédents ne sont pas chargés et ils ont été archivés. Pour les données du jour, il n'y a pas de problèmes; Filebeat dès son redémarrage, va continuer son travail là où il s'est arrêté. S'il n'a encore rien chargé, il commence au début. Par contre pour les jours précédents, il faut extraire après décompression, les alertes non chargées.
ATTENTION:
- Il ne faut pas inclure les alertes déjà chargées sinon elles seront en double.
- Il est à noter que la séparation journalière des archives ne se fait pas à minuit précise; il y a toujours quelques alertes du jour précédent qui sont passées comme étant du jour courant lors de cet archivage.
Chargement des alertes courantes à partir du début
Dans le cas où on efface les alertes du jour contenues dans le fichier "/var/ossec/logs/alerts/alerts.json", de la base de données de Wazuh-Indexer, on va vouloir les recharger. Mais Filebeat garde l'endroit où il est arrivé dans son traitement du fichier "/var/ossec/logs/alerts/alerts.json". Ce point est appelé "offset". On retrouve cette information dans le fichier "/var/lib/filebeat/registry/filebeat/log.json". Avant de tenter de relancer ce chargement, il faut s'assurer que cet "offset est remis à "0". Bien entendu, dans un contexte actif, ce fichier "/var/ossec/logs/alerts/alerts.json" continue à grossir.
Une solution simple consiste à arrêter le service "filebeat.service". Puis à effacer le répertoire "/var/lib/filebeat". A ce stade, il faut réinitialiser Filebeat en recréant le "keystore" comme vu précédemment :
filebeat keystore create echo admin | filebeat keystore add username --stdin --force echo <nouveau mot de passe>| filebeat keystore add password --stdin --force
Enfin on redémarre le service "filebeat.service". Le fichier "/var/ossec/logs/alerts/alertsold.json" doit être vide
Une méthode que je n'ai pas testée, serait de vider le contenu du fichier "/var/lib/filebeat/registry/filebeat/log.json" lorsque le service "filebeat.service" est arrêté.
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. 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) Ces 4 là ne doivent en aucun cas être effacés !!! Au total pour une année, nous avons 1203 paquets.
On peut obtenir cette liste avec la commande suivante:
curl --silent -X GET -k -u admin:admin https://localhost:9200/_cat/shards | sort
Limitation sur les Shards
Le nombre de paquets ("shards") est limité par défaut à 1000. Dès que l'on atteint cette limite, plus aucune donnée n'est chargée. Donc avant d'avoir atteint un an d'utilisation, nous serons bloqué.
Il est possible de modifier cette limite en interagissant avec l'API de Wazuh-Indexer. Voici la commande où nous avons porté cette limite à 3000.
curl -X PUT -k -u admin:admin https://localhost:9200/_cluster/settings -H "Content-Type: application/json" -d '{ "persistent": { "cluster.max_shards_per_node": "3000" } }'
Note: le mot de passe de l'utilisateur "admin" est l'original pour la commodité de l'exposé.
La commande suivante affiche la valeur implémentée:
curl --silent -X GET -k -u admin:admin https://localhost:9200/_cluster/settings | python -m json.tool
qui donne:
{
"persistent": {
"cluster": {
"max_shards_per_node": "3000"
}
},
"transient": {}
}
Performances
Tous ces paquets sont chargés en mémoire. Lors du démarrage du service "wazuh-indexer.service", ils sont chargés et plus il y en a plus cette étape prend de temps avant que le service soit utilisable.
On peut suivre cette phase avec la commande suivante:
curl -X GET -k -u admin:admin https://localhost:9200/_cluster/health?pretty
qui donne par exemple:
{
"cluster_name" : "wazuh-cluster",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"discovered_master" : true,
"active_primary_shards" : 371,
"active_shards" : 371,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
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 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.
Pour une question de performance, il est conseillé de se limiter à 1000 paquets. D'autre part, plus vous chargez de paquets en mémoire, à un certain moment, elle sera toute utilisée et c'est le swap qui rentre en action. Alors la réactivité de votre machine chute drastiquement. Il est possible de limiter ce nombre chargé; je n'ai pas testé cette possibilité.
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 https://localhost:9200/_cat/shards | grep "\-$ANNEE.$MOIS." | awk {'print $1'} | sort -u > delete.shards.txt
cat delete.shards.txt | xargs -i curl -k -XDELETE -u admin:admin "https://localhost:9200/{}"
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 https://localhost:9200/_cat/shards | 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 "https://localhost:9200/{}"
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 https://localhost:9200/_cat/shards
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.