Migrate from Wazuh and Elastic Stack basic license to Wazuh central components

[Maria Juárez]

Is there any way to migrate from "Wazuh and Elastic Stack basic license" to "Wazuh central components"? I installed Wazuh Elastic Stack basic license but now I would like to migrate the environment to use all Wazuh components, but I don't want to lose the Indexes. Is there any way? (I tried to migrate first to Opendistro and then to Wazuh Central Components, but there was a problem with the versions of the Indexes)

[Dhananjay Nagwan]

Hello Majualoki,

Thank you for using wazuh!

With the Elastic Stack basic license Migrating to wazuh components can't be done directly.

You can do a fresh installation of the wazuh-indexer and wazuh-dashboard instead of migrating, after that you can do reindexing with alerts backups in the wazuh manager. Now you need to recover the logs in the environment with help of a recovery script.
We need to make sure that the wazuh manager should be unchanged and if the alerts backup is present or not.

You can only reindex if you have old logs. As it is a fresh installation for wazuh-indexer, your indices will be lost.

But with the help of alerts backup and recovery script, you can reindex the old alerts in the new indexer.
You can reinstall Filebeat with the new configuration and certs:https://documentation.wazuh.com/current/installation-guide/wazuh-server/step-by-step.html#configuring-filebeat

After that, you can follow the below guide to create recovery.py.https://wazuh.com/blog/recover-your-data-using-wazuh-alert-backups/

Here: The Wazuh manager stores alert from previous days in a compressed manner.

A script will be used to uncompress non-indexed alerts into a new file.

From there, the component forwarding the alerts will simultaneously index non-indexed alerts and alerts that are concurrently generated. Setting up the recovery script- The script will perform the creation of the recovery.json file, which will store the data that we will be indexing later.

We need to Determine the recovery parameters:-
The operability of the script is determined by the following characteristics:

• Events per second (EPS). The limit of EPS in the recovery process will depend on the cluster workload. Normally, the process can run at the same time as the current indexation flow, but configuring an excessive number of EPS may affect the cluster performance.
• Disk space. The recovery process will uncompress the alerts into a file periodically rotated depending on its size. The output size limit can be configured to prevent taking up too much disk space during the recovery, but setting up a small rotation limit will slow down the process.

Script usage:

usage: recovery.py [-h] [-eps eps] -min min_timestamp -max max_timestamp -o output_file [-log log_file] [-w wazuh_path] [-sz max_size] -eps eps, --eps eps Events per second. Default: 400 -min min_timestamp, --min_timestamp min_timestamp Min timestamp. Example: 2019-11-13T08:42:17 -max max_timestamp, --max_timestamp max_timestamp Max timestamp. Example: 2019-11-13T23:59:06 -o output_file, --output_file output_file Alerts output file. -log log_file, --log_file log_file Logs output. -w wazuh_path, --wazuh_path wazuh_path Path to Wazuh. By default:/var/ossec/ -sz max_size, --max_size max_size Max output file size in Gb. Default: 1Gb. Example: 2.5

We recommend using the command nohup to execute the script in the background and keep it running after the session is closed.

nohup ./recovery.py -eps 500 -min 2019-07-21T13:59:30 -max 2019-07-24T22:00:00 -o /tmp/recovery.json -log ./recovery.log -sz 2.5 &

In Kibana, you can extract the exact timestamp by opening the alert in JSON format in the Discover tab and looking at the" fields.timestamp" field. (fields. @timestamp for 6.x)
use the  "-min and -max"  options to set the range of alerts you want to index based on their timestamp.





I hope it helps. Please let us know your queries.