LINUX:Wazuh-WUI-Maintenance
But
Cet 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. 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. Ces 4 là ne doivent en aucune cas être effacés !!! Au total pour une année, nous avons 1203 paquets.
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" : 278,
"active_shards" : 278,
"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 278 (active_primary_shards" : 278).
S'il y a des paquets qui ne sont pas assignés ("unassigned_shards") en fin de phase (son nombre restant stables), il y a un problème.
Pour une question de performance, il est conseillé de ce 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 ne ai testé cette possibilité.