Updating Indexer Policy and Passwords
Krishna Prasad Bhandary
We are currently running a distributed environment, with 1 wazuh-server node, 2 indexer nodes with the primary indexer also running the dashboard.
We had changed the indexer passwords sometime in June but that had not fully completed due to the tool not being able to create a backup, however after looking into it in the last few weeks we found that the intern_users.yml had changed due to partial execution and we did have the changed passwords noted down.
We ran the securityadmin.sh script on November 24th and this resulted in the passwords being applied and communications with the Dashboard and Server stopping. We have about 3 weeks of logs now and are unsure that when we add the updated passwords or fully reset it again if the old logs will get indexed.
If they DO get indexed, we do not have enough space and thus wanted to change our retention policy from 60 days to 45 days to allow for the new logs to be added. How would I apply this policy for existing indices? Do I have to manually delete the older indices? I tried to modify the policy for the indices currently and set it to 45 days. Since nothing happened I selected the indices that the policy should apply to and on clicking apply, my indexer crashed and it took a lot of work to recover it. Would like some guidance on this.
Nikhil Gurjar
Apologies for the delayed response. Please allow me to address your queries sequentially.
If you encounter a “username or password is incorrect” error while accessing the Wazuh Dashboard, this does not impact index creation or log ingestion. Logs are ingested and indexed through certificate-based communication between Wazuh components and are not dependent on Dashboard user credentials. (reference document: https://documentation.wazuh.com/current/getting-started/architecture.html#component-communication ).
Additionally, could you please clarify why the securityadmin.sh script was executing. Is this for the LDAP configuration? Also, does the incorrect credentials issue occur for a specific user only, or does it affect all users, including the admin user, when accessing the Dashboard via a browser?
If you would like to reduce the retention period to 45 days, this can be configured via CLI, which is useful if Dashboard access is currently unavailable.
The following command creates an Index State Management (ISM) policy to automatically delete Wazuh indices older than 45 days. This policy can be applied to both existing and future indices, and it does not require Dashboard credentials.
curl -k -X PUT "https://192.168.54.61:9200/_plugins/_ism/policies/wazuh-retention-45d" \
-u admin: \
--cert /etc/wazuh-indexer/certs/admin.pem \
--key /etc/wazuh-indexer/certs/admin-key.pem \
-H "Content-Type: application/json" \
-d '{
"policy": {
"description": "Delete Wazuh indices older than 45 days",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "45d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
]
}
}'
2. Verify the policy creation:
curl -k -X GET "https://192.168.54.61:9200/_plugins/_ism/policies/wazuh-retention-45d" --cert /etc/wazuh-indexer/certs/admin.pem --key
/etc/wazuh-indexer/certs/admin-key.pem
3. Remove any old policy, which is already applied on the `wazuh-alerts-*`
curl -k -X POST "https://192.168.54.61:9200/_plugins/_ism/remove/wazuh-alerts*" --cert /etc/wazuh-indexer/certs/admin.pem --key /etc/
wazuh-indexer/certs/admin-key.pem -H "Content-Type: application/json"
4. Apply the newly created policy:
curl -k -X POST "https://192.168.54.61:9200/_plugins/_ism/add/wazuh-alerts-
*" -u admin: --cert /etc/wazuh-indexer/certs/admin.pem --key /etc/wazuh-indexer/certs/admin-key.pem -H "Content-Type: application/json" -d '{
"policy_id": "wazuh-retention-45d"
}'
Additionally, to help us assess the current status of your environment, could you please share the following details:
systemctl status wazuh-indexer
systemctl status wazuh-manager
systemctl status wazuh-dashboard
filebeat test output
I'm looking forward to your update.
Best regards,
Nikhil
Krishna Prasad Bhandary
Thank you for your response! I modified our existing policy and when the logs began showing up I looked at the newly created index for today wazuh-alerts-4.x-2025.12.16. This index has the "indices_policy" associated with it which is the policy I edited.
The policy is given below. I think this should suffice right?
{
"id": "indices_policy",
"seqNo": 35609091,
"primaryTerm": 51,
"policy": {
"policy_id": "indices_policy",
"description": "Wazuh index state management for OpenDistro to move indices into a cold state after 30 days and delete them after 45 days.",
"last_updated_time": 1765888772209,
"schema_version": 21,
"error_notification": null,
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"replica_count": {
"number_of_replicas": 1
}
}
],
"transitions": [
{
"state_name": "cold",
"conditions": {
"min_index_age": "30d"
}
}
]
},
{
"name": "cold",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"read_only": {}
}
],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "45d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"wazuh*",
"owlh*",
"security-auditlog-*",
"filebeat-*"
],
"priority": 100,
"last_updated_time": 1691476175689
}
]
Krishna Prasad Bhandary
I read that reindexing could solve this but on average our indices would be about 15gb per day therefor for about 23 days we would have 345 GB of logs. This can slow down or even crash the system right? What can be done to avoid this?
Nikhil Gurjar
Glad to hear that you’re now able to access the dashboard.
Regarding the retention policy, your newly created policy is correctly configured and will automatically delete indices 45 days after their creation.
For data recovery, you can follow the steps outlined in the documentation below: https://documentation.wazuh.com/current/migration-guide/restoring/wazuh-central-components.html#restoring-old-logs. This process restores data from the /var/ossec/logs/alerts directory on the Wazuh manager. Based on the data size, the restored logs will be forwarded to the indexer node, and the historical data will then be visible in the Wazuh dashboard.
Additionally, to identify the root cause of the Wazuh indexer or manager services going down, you can review the logs from the affected period using the following commands or you can share them here for analysis.
I hope this information is helpful. Please let us know if you have any further questions.
Best regards,
Nikhil