Guidance Required for Restoring Wazuh Alert Logs from S3 to Dashboard

[xeption]

Hello Team,

We have Wazuh alerts.json log files archived in an Amazon S3 bucket, organized by date. We would like to restore these historical logs and make them visible in the Wazuh Dashboard for analysis and reporting purposes.

Could you please guide us on the recommended approach to import the archived alerts.json files from the S3 bucket into Wazuh/OpenSearch so that the events become searchable and accessible through the Wazuh Dashboard?

Specifically, we would like to understand:

• The supported method for importing historical alerts.json files from S3.
• Whether the logs need to be re-indexed into the Wazuh/OpenSearch indices.
• Any prerequisites, tools, or scripts required for the restoration process.
• Best practices for preserving the original event timestamps during the import process.

Our objective is to restore historical Wazuh alerts stored in S3 and make them available in the Wazuh Dashboard for investigation and reporting.

We would appreciate your guidance on the process.

Regards,

xeption

[Olamilekan Abdullateef Ajani]

Hello Xeption,

Yes, restoring historical alerts from an S3 bucket and making them available in the Wazuh dashboard is possible. Since the dashboard displays data from the Wazuh Indexer, the archived alerts.json files need to be re-indexed through Filebeat.

You can refer to the approach below, which allows filebeat to read from the backed-up alers.json file and feed it to the Wazuh indexer naturally for guidance.

1. Download the required alerts.json files from S3 to a temporary location on the Wazuh manager. aws s3 sync s3://your-bucket/wazuh-alerts/ /tmp/wazuh-restore/ --include "*.json"
2. Configure Filebeat to read the historical file in addition to the live /var/ossec/logs/alerts/alerts.json file. For example, if the temporary file from above step is /tmp/wazuh-restore/alerts.json, then do the below:

Modify the file: nano /usr/share/filebeat/module/wazuh/alerts/manifest.yml and add the new path under where you have the alerts.json being read to look similar to

   var:
  - name: paths
    default:
      - /var/ossec/logs/alerts/alerts.json
      - /tmp/wazuh-restore/alerts.json

Then:
filebeat test config
systemctl restart filebeat
tail -f /var/log/filebeat/filebeat

Verify the modified path is loaded:
   cat /usr/share/filebeat/module/wazuh/alerts/manifest.yml
Check if Filebeat is monitoring the file:
   grep -i recovery /var/log/filebeat/filebeat

3. Filebeat will process the alerts through the normal Wazuh ingestion pipeline and index them into the corresponding wazuh-alerts-* indices.
4. Verify the data in the Wazuh indexer and adjust the Dashboard time range to view the restored events.

I will advise you:

- Test with a small set of historical data before importing large volumes.
- Preserve the original timestamp field in the alerts to ensure events are indexed with their original event time.
- Import data in batches if the archive is large to avoid excessive load on the indexer.
- Once the import is complete, remove the temporary recovery file path from the Filebeat configuration and restart Filebeat.

I have tested and validated this process by adding a historical JSON file as an additional Filebeat input, and I confirmed Filebeat harvested the file and verified that the events were successfully indexed into the wazuh-alerts-* indices with their original timestamps preserved.

Please let me know if you have further questions around this.