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 manière être effacés !!! Au total pour une années 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.
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:Cddvdbnc71 https://localhost:9200/_cluster/settings | python -m json.tool
qui donne:
{
"persistent": {
"cluster": {
"max_shards_per_node": "3000"
}
},
"transient": {}
}