" talk to server ERROR 401 Unauthorized: Unauthorized" after command "filebeat test output elasticsearch"

[Adam Nowak]

After succesfully instalation "https://documentation.wazuh.com/current/deployment-options/offline-installation.html" I try to "Securing your Wazuh installation" with negative information"

root@wazuh-1:~# filebeat test output
elasticsearch: https://192.168.131.200:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.131.200
    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

All steps I described on site:

https://github.com/wazuh/wazuh/discussions/25120

[Adam Nowak]

I have a question if using an example password with a "+" sign can generate errors with password authorization on wazuh-indexer ?

 For example password  "SuperS3cretPassword+"

curl -k -X PUT "https://192.168.131.201:55000/security/users/1" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d'b.  {c.    "password": "SuperS3cretPassword+"d.  }'

Output

{"data": {"affected_items": [{"id": 1, "username": "wazuh", "allow_run_as": true, "roles": [1]}], "total_affected_items": 1, "total_failed_items": 0, "failed_items": []}, "message": "User was successfully updated", "error": 0}

_________________________________________

f.  curl -k -X PUT "https://192.168.131.201:55000/security/users/2" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d'g.  {h.    "password": "SuperS3cretPassword+"i.  }'

Output

{"data": {"affected_items": [{"id": 2, "username": "wazuh-wui", "allow_run_as": true, "roles": [1]}], "total_affected_items": 1, "total_failed_items": 0, "failed_items": []}, "message": "User was successfully updated", "error": 0}

[Rajesh Kumar]

The error you're encountering, 401 Unauthorized, indicates that Filebeat is unable to authenticate with your Elasticsearch server. 

This error typically occurs when the credentials used by Filebeat to connect to Elasticsearch are either incorrect or insufficient in terms of permissions. 

This can be a security concern, as it suggests that the Filebeat instance cannot properly communicate with Elasticsearch, which may lead to missed logs or incomplete monitoring data.

Troubleshooting Steps:

1. Check Filebeat Configuration:

Ensure that the filebeat.yml configuration file contains the correct username and password for the Elasticsearch output. These credentials must correspond to a user that has sufficient permissions to write to Elasticsearch.

1. Verify User Permissions:

Log into Kibana or use the Elasticsearch API to verify that the user configured in Filebeat has the correct roles and permissions. The user should have the ingest_admin role or a custom role that allows for index creation and data writing.

Example API call to check roles:

curl -u your_elasticsearch_username:your_elasticsearch_password -X GET "https://192.168.131.200:9200/_security/user/your_elasticsearch_username"

1. Review Elasticsearch Logs:

Check the Elasticsearch logs for any additional error messages related to authentication or authorization. This can provide more context on why the authentication is failing.

Log location (assuming default installation paths):

1. Secure Communications:
• Ensure that the communications between Filebeat and Elasticsearch are encrypted using TLS. You mentioned that TLS is already enabled, which is good. Make sure that the certificate being used is valid and correctly configured on both Filebeat and Elasticsearch.
3. Check Security Settings:
• If Elasticsearch is set up with security features such as IP whitelisting, ensure that the IP address of the machine running Filebeat is allowed to connect to Elasticsearch.
4. Check for Typos and Misconfigurations:
• Simple issues like incorrect indentation or typos in the filebeat.yml configuration file can also cause issues. Double-check the file for any errors.

Security Implications:

• Unauthorized Access: The 401 Unauthorized error prevents unauthorized data from being sent to Elasticsearch, which is a positive security measure. However, it also means that legitimate data is not being sent, which could leave gaps in your monitoring and potentially make it difficult to detect intrusions or other security issues.
• Misconfiguration Risk: If the error is due to a misconfiguration, it highlights a potential oversight in securing your Wazuh and Elasticsearch setup. Properly securing your setup involves ensuring that all services are correctly configured to communicate securely and that only authorized users and services can interact with Elasticsearch.
• Data Loss: If Filebeat is unable to send logs to Elasticsearch, you may lose critical data that could be essential for security monitoring and compliance.

Next Steps:

• Correct the credentials in the Filebeat configuration.
• Ensure the user has the necessary permissions in Elasticsearch.
• Verify all security settings and configurations.
• Once resolved, monitor the Filebeat logs to confirm successful communication with Elasticsearch.

By addressing this 401 Unauthorized error, you can ensure that your Wazuh installation remains secure and that all logs are properly ingested into Elasticsearch for analysis.

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/49b1b02c-5369-43ce-baa2-245cdffcfb2en%40googlegroups.com.

[Adam Nowak]

 My filebeat.yml:

[Adam Nowak]

My:  curl -u kibanaserver:your_elasticsearch_password -X GET "https://192.168.131.200:9200/_security/user/kibanaserver"

[Olusegun Adenrele Oyebo]

Hello Adam,

The  ERROR 401 Unauthorized: Unauthorized seems to be because the user or password of Wazuh indexer does not match with the username or password in the file /etc/filebeat/filebeat.yml. Filebeat uses those credentials to connect to the Wazuh indexer. 

Kindly confirm you added the Wazuh indexer username and password admin:admin to the filebeat secrets keystore as stated here.

If you did and issue still persists, you can try to use the password management tool to change the Wazuh indexer admin user password. You need to run the command on your Wazuh indexer node. You can find it in the path /usr/share/wazuh-indexer/plugins/opensearch-security/tools/  or download it by running command curl -so wazuh-passwords-tool.sh https://packages.wazuh.com/4.8/wazuh-passwords-tool.sh. Run bash wazuh-passwords-tool.sh -u admin -p Secr3tP4ssw*rd replace  Secr3tP4ssw*rd with the password of your choice. If you're using an all-in-one deployment, it should automatically update the password where necessary. If you use it in a distributed environment, run the below command to update the admin user password in the filebeat keystore and in the ossec.conf file for the Wazuh server:

• echo <ADMIN_PASSWORD> | filebeat keystore add password --stdin --force
  
• sed -i 's/<password>.*<\/password>/<password><ADMIN_PASSWORD><\/password>/g' /var/ossec/etc/ossec.conf
  

Restart the filebeat and Wazuh manager service to apply changes:

• systemctl restart filebeat
  
• systemctl restart wazuh-manager
  

Run the filebeat test again filebeat test output and see if you'll still encounter the error.

Let me know if this resolves your issue or it still persists.

Best regards.

[Adam Nowak]

After succesfully change password with your instructions, I have new ERRORS during execute commands:

"# TOKEN=$(curl -u wazuh-wui:wazuh-wui -k -X GET "https://192.168.131.201:55000/security/user/authenticate?raw=true")

curl -k -X PUT "https://192.168.131.201:55000/security/users/1" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d'

{
  "password": "*********************”

}'

Output
{"data": {"affected_items": [{"id": 1, "username": "wazuh", "allow_run_as": true, "roles": [1]}], "total_affected_items": 1, "total_failed_items": 0, "failed_items": []}, "message": "User was successfully updated", "error": 0}

curl -k -X PUT "https://192.168.131.201:55000/security/users/2" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d'

{
 "password":   "*********************”

}'

Output
{"data": {"affected_items": [{"id": 2, "username": "wazuh-wui", "allow_run_as": true, "roles": [1]}], "total_affected_items": 1, "total_failed_items": 0, "failed_items": []}, "message": "User was successfully updated", "error": 0}

[Olusegun Adenrele Oyebo]

Hello Adam,

The error you attached is a new issue, which is different from the one you initially posted. Kindly confirm the previous issue when doing filebeat test got resolved. If the issue got resolved, will recommend you open a new thread based on this new error as we respond on a case-by-case basis.

Will be expecting your feedback.

Best regards.