search

wazuh / wazuh-puppet

Wazuh - Puppet module
https://wazuh.com
GNU General Public License v2.0
46 stars 135 forks source link

Wazuh resets user passwords #740

Closed temmishy closed 10 months ago

temmishy commented 1 year ago

Hello everyone! We use wazuh using this puppet module аnd we encountered an unexpected problem: about once a month, they change passwords to standard ones from users admin, kibanaserver etc. While the passwords in the keystore do not change and the problem is solved by changing the password to the one in the keystore. The documentation does not mention any schedule for changing passwords, puppet does not change them every time it is executed. Has anyone else had this problem and can help/suggest what could be causing this behavior. And how to fix it.

vaskosmihaylov commented 11 months ago

Thanks to @temmishy for highlighting this issue. I've encountered the same problem and upon investigation, discovered that the Wazuh Puppet module seems to prioritize keystore credentials over those in configuration files. Here's a detailed breakdown of the issue for the Wazuh team:

Expected Behavior

Changing passwords for Wazuh Dashboard, Filebeat, and Wazuh API via class parameters should result in these services using the updated passwords in the configuration files, rather than defaulting to keystore credentials.

Current Behavior

After a fresh installation of Wazuh central components via the Puppet module, setting custom values for wazuh::dashboard::dashboard_password, wazuh::dashboard::dashboard_wazuh_api_credentials, and wazuh::filebeat_oss::filebeat_oss_elastic_password does not reflect the changes. These services still retrieve passwords from the keystores, despite wazuh::dashboard::use_keystore being set to false.

Steps to Reproduce

  1. Install Wazuh using the Puppet module with all class definitions as per the documentation.
  2. Update the aforementioned parameters to custom values via Hiera or via the local profile. I am doing it with Hiera:
wazuh::filebeat_oss::filebeat_oss_elastic_password: newpass
wazuh::dashboard::dashboard_password: newpass
wazuh::dashboard::dashboard_wazuh_api_credentials:
  - id: default
    url: https://localhost
    port: 55000
    user: wazuh-wui
    password: newpass

  1. After running Puppet, check /var/log/wazuh-indexer/*-wazuh-cluster.log for authentication failures.

    [2023-12-01T12:17:41,680][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:17:47,444][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:18:00,999][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:18:21,654][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:19:13,973][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:20:07,417][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:21:01,896][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:21:32,944][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:21:43,907][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for kibanaserver from 127.0.0.1:33240

  2. Test output from Filebeat shows a 401 Unauthorized error, indicating a failure in the password update:

filebeat test output
elasticsearch: https://127.0.0.1:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 127.0.0.1
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... ERROR 401 Unauthorized: Unauthorized
  1. Try to login to the Wazuh API with the new password:
curl -u wazuh-wui:newpass -k -X POST "https://localhost:55000/security/user/authenticate?raw=true"
{"title": "Unauthorized", "detail": "Invalid credentials"}

I can confirm the passwords in changed in the config files:

grep 'password' wazuh.yml
#       # Host / API password
#       password: wazuh-wui
#       password: wazuh-wui
      password: newpass

Using the defaults works as expected:

curl -u wazuh-wui:wazuh-wui -k -X POST "https://localhost:55000/security/user/authenticate?raw=true"
eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9..(*runcated)Axf5m_qroot

Resetting passwords using Wazuh's wazuh-passwords-tool.sh script, which updates the keychains, temporarily resolves the issue. However, this suggests that the module might revert to default passwords upon updates or when pulling new data via R10K.

Conclusion

It seems that there's a disconnect between the module's handling of custom passwords and its reliance on keystores. This issue needs addressing to ensure consistent password management across Wazuh installations.

@vcerenu, can someone from the Wazuh team review the issue and advise us.

BR, Vasko

vcerenu commented 10 months ago

Thank you @temmishy and @vaskosmihaylov for the analysis regarding this issue of password control within the deployment of Wazuh with Puppet. Regarding the parameters for passwords within the wazuh_dashboard and filebeat_oss classes, they are parameters for the deployment, that is, you are indicating to Wazuh dashboard or Filebeat with which password you are going to connect, but it is not an indication of which password will have the user used within Wazuh indexer or Wazuh API respectively. To use another password you should change the password first at the origin: https://documentation.wazuh.com/current/user-manual/user-administration/password-management.html After changing the password, you should parameterize the corresponding password within each class. These parameters have the default values assigned and it is necessary to modify them if they do not have the default values. The problem of the parameters returning to default does not exist because we do not generate the internal_users.yml file of Wazuh indexer with templates. In addition, the securityadmin.sh script should also be executed so that it impacts the user base, the configuration files are not modified either. from Wazuh API, so you should not have problems with passwords returning to default. Currently we do not have in our roadmap to add the password change within our classes, but any contribution that you want to make and that we can add will be welcome.

vaskosmihaylov commented 10 months ago

Thank you for your input, @vcerenu. I appreciate your guidance and have indeed followed the steps you suggested. Initially, I reset the passwords using the Wazuh wazuh-passwords-tool.sh. Following that, I updated the password parameters accordingly. However, after a while, I encountered a reset of the passwords, which was evident from the errors in the Wazuh indexer log:

[2023-12-01T12:21:32,944][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for admin from 127.0.0.1:33200
[2023-12-01T12:21:43,907][WARN ][o.o.s.a.BackendRegistry  ] [node-1] Authentication finally failed for kibanaserver from 127.0.0.1:33240

To understand this unexpected behavior, I have included the Wazuh indexer and dashboard configuration files in the audit service for monitoring. As I haven't made any recent changes myself, I suspect the resets might be triggered either by an update in the Wazuh package or possibly through the Puppet module.

I'll be sure to keep this issue updated as I investigate further, especially since the problem now appears to be intermittent.