Register agent to another manager - alerts gap

[Milica Mijatovic]

Hi,

I want to register Wazuh agents to another Wazuh manager. I am using 3.13.0 version. Due to the risk of alerts gap (there are around 50 agents, agents will not register in parallel), is there a possibility to re-import current alerts.json/alerts.log from old Wazuh manager to the new one and then concatenate these files so I can have all logs from the current date visible? 

I consider two options:

• stop filebeat, concatenate alerts.json files (as explained above), delete registry, start filebeat. Question: do I need to concatenate only .json files or .log files are also necessary?
• preferred option: under "/data/ossec/logs/alerts/year/month" path we have also  backup .json and .log alerts on a daily basis. I would import .json/.log file from old Wazuh manager here. Is there a way to force filebeat to harvest this file and to continue harvesting regular alerts.json?

Thanks upfront,

Milica

[Alberto Rodriguez]

Hello 

You can tackle the problem using different approaches. 

- Wazuh side: 

    * Move all the agents. You can re-register all the Wazuh agents in the new Wazuh server. Using the agent-auth binary, the Wazuh API, etc. Even you can copy the /var/ossec/etc/client.keys from the old Wazuh server to the new one and change the Wazuh server IP in the Wazuh agent configuration files and they will report directly to the new Wazuh server without re-register. 

    * Move the Wazuh server data. The Wazuh alerts are rotated, compressed, and stored in /var/ossec/logs/alerts/ folder. Those data have been ingested by Elasticsearch using filebeat, so it's duplicated in two places. If you want to have the "raw" Wazuh alerts then, you can move the mentioned folder to the new server. 

- Elasticsearch data:

    * If you want to have the same data in the new Elasticsearch node, I would recommend you to use the Elasticsearch migration data tool: https://www.elastic.co/guide/en/cloud/current/ec-migrate-data.html.

So, a good plan could be:

1.- Wazuh agent migration. 

2.- Once the migration is complete, and new data is received by the new Elasticsearch, start the Elasticsearch data migration using their API method. 

Take into account that, depending on the stress level of your Elasticsearch node, maybe could be better to migrate Elasticsearch data before migrating agents. This is 1: Migrate Elasticsearch data from the beginning to the migration day, 2: Migrate the Wazuh agents, 3: Migrate the Elasticsearch data of the migration day. The stress caused would be less because is fewer data to ingest meanwhile is ingesting Wazuh alerts in real-time. Only in cases when the Elasticsearch node/s is/are stressed. 

Regards, 

Alberto R

[Milica Mijatovic]

Hi Alberto,

Many thanks for the prompt response.

I would like to go with the Wazuh side way:

If I copy, for example, ossec-alerts-19.json raw file (file created for the migration day) from the old Wazuh manager to the /var/ossec/logs/alerts/2021/Jan folder in the new Wazuh manager, and rename it like alerts_old.json (in order not to break current ossec-alerts-19.json file in the new Wazuh manager) , how can I "force" filebeat to re-process this file? I tested it like this:

edit the manifest.yml file located in the /usr/share/filebeat/module/wazuh/alerts/manifest.yml with the following:

module_version: 0.1

var:

  - name: paths

    default:

      - /data/ossec/logs/alerts/alerts.json

      - /data/ossec/logs/alerts/2021/Jan/alerts_old.json

  - name: index_prefix

    default: wazuh-alerts-3.x-

input: config/alerts.yml

ingest_pipeline: ingest/pipeline.json

It seems to work, but can you let me know if this approach is good and will not break something else? I see that regular alerts are processed from the alerts.json file.

Regards,

Milica

[Alberto Rodriguez]

Hello Milica

  In that case, I would recommend you to use the tool described in this blog post: https://wazuh.com/blog/recover-your-data-using-wazuh-alert-backups/, I think that is exactly what you want. Instead of renaming files, you could just copy them and indicate the script the start and the end of the reinjection. 

Please let me know if you have any doubt using it. 

Regards, 
Alberto R