Merge pull request #9204 from wazuh/merge-4.14-into-4.14.2

Merge 4.14 into 4.14.2

Author: javimed

CHANGELOG.md

@@ -43,6 +43,9 @@ All notable changes to this project will be documented in this file.
 - **Post-release**: Updated the *Installation from sources* documentation. ([#9168](https://github.com/wazuh/wazuh-documentation/pull/9168))
 - **Post-release**: Updated diagram images in the documentation. ([#9097](https://github.com/wazuh/wazuh-documentation/pull/9097))
 - **Post-release**: Updated the Wazuh signed package (WPK) files section. ([#9175](https://github.com/wazuh/wazuh-documentation/pull/9175))
+- **Post-release**: Updated `offline-url` setting reference in the vulnerability detection capability section. ([#9197](https://github.com/wazuh/wazuh-documentation/pull/9197))
+- **Post-release**: Updated the Wazuh Indexer API documentation. ([#9200](https://github.com/wazuh/wazuh-documentation/pull/9200))
+- **Post-release**: Updated the *How to configure SCA* section. ([#9202](https://github.com/wazuh/wazuh-documentation/pull/9202))
 
 ### Fixed
 

source/user-manual/capabilities/sec-config-assessment/how-to-configure.rst

@@ -65,22 +65,39 @@ The second is to disable them from the Wazuh agent ``ossec.conf`` file by adding
 How to share policy files and configuration with the Wazuh agents
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-As described in the :doc:`centralized configuration </user-manual/reference/centralized-configuration>` section, the Wazuh manager can push files and configurations to connected Wazuh agents.
+As described in the :doc:`centralized configuration </user-manual/reference/centralized-configuration>` section, the Wazuh server can push files and configurations to connected Wazuh agents.
 
 You can enable this feature to push policy files to the Wazuh agents in defined groups. By default, every Wazuh agent belongs to the ``default`` group, which is used here as an example:
 
-#. On the Wazuh agent, edit the ``local_internal_options.conf`` file to allow the execution of commands in SCA policies that use the ``c`` (command) rule type sent from the Wazuh server:
+#. Edit the Wazuh agent ``local_internal_options.conf`` file to allow the execution of commands in SCA policies sent from the Wazuh server:
 
-   .. code-block:: console
+   .. tabs::
 
-      # echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf
+      .. group-tab:: Linux
 
+         .. code-block:: console
+
+            # echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf
+
+      .. group-tab:: Windows
+
+         .. code-block:: doscon
+
+            > notepad "C:\Program Files (x86)\ossec-agent\local_internal_options.conf"
+
+         Append the command ``sca.remote_commands=1``.
+
+      .. group-tab:: macOS
+
+         .. code-block:: console
+
+            # echo "sca.remote_commands=1" >> /Library/Ossec/etc/local_internal_options.conf
 
    .. note::
 
-      By enabling the ``sca.remote_commands`` flag, the Wazuh server can execute commands on the monitored endpoint for SC policies that include rules of type ``c`` (command). This setting is only required for SCA policies using the ``c`` rule type; policies with other rule types (e.g., ``f`` for file, ``p`` for process, or ``r`` for registry) are not affected by the ``sca.remote_commands`` flag and will function without enabling it.
+      By enabling remote command execution, the Wazuh server can execute commands on the monitored endpoint. Remote commands are disabled by default as a security measure, helping reduce the attack surface if the Wazuh server is compromised.
 
-      Remote command execution is disabled by default as a security measure to reduce the attack surface in case the Wazuh server is compromised. If you prefer not to enable remote commands, you can manually deploy policy files to each agent without using the Wazuh server to push them. For example, you can create the policy file directly on the monitored endpoint or use ``scp`` to copy the policy file to the endpoint.
+      You do not need to enable remote commands if you add the policy files to each agent without using Wazuh to push them. For example, you can manually create the policy file directly on the monitored endpoint, or use ``scp`` to copy the policy file to the monitored endpoint.
 
 #. On the Wazuh server, place a new policy file in the ``/var/ossec/etc/shared/default`` folder and change its ownership. Replace ``<NEW_POLICY_FILE>`` with your policy name. 
 

source/user-manual/capabilities/vulnerability-detection/configuring-scans.rst

@@ -221,12 +221,12 @@ Follow the steps below to configure the Vulnerability detection module for offli
          <enabled>yes</enabled>
          <index-status>yes</index-status>
          <feed-update-interval>60m</feed-update-interval>
-         <offline-url><FILE_PATH_TO_OFFLINE_REPOSITORY></offline-url>
+         <offline-url>file://<FILE_PATH_TO_OFFLINE_REPOSITORY></offline-url>
       </vulnerability-detection>
 
    Where:
 
-   -  ``<FILE_PATH_TO_OFFLINE_REPOSITORY>`` is the file path to the threat intelligence repository downloaded in the previous step.
+   -  ``<FILE_PATH_TO_OFFLINE_REPOSITORY>`` is the file and path to the threat intelligence repository downloaded in the previous step.
 
 #. Restart the Wazuh manager to apply the configuration.
 

source/user-manual/indexer-api/getting-started.rst

@@ -76,54 +76,68 @@ JSON Web Token (JWT)
 
 The JSON Web Token (JWT) is another method of authenticating to the Wazuh indexer API. JWT is an open standard (RFC 7519) that defines a compact and self-contained method for securely transmitting information between parties as a JSON object.
 
-A JWT can be self-generated, and the validation key can be stored in the ``/etc/wazuh-indexer/opensearch-security/config.yml`` file or generated and validated through a JSON Web Key Set (JWKS) endpoint to retrieve the key from its location on the issuer’s server.
+A JWT can be self-generated using validation keys stored in the ``/etc/wazuh-indexer/opensearch-security/config.yml`` file or generated and validated through a JSON Web Key Set (JWKS) endpoint to retrieve the key from its location on the issuer's server.
 
-JWT authentication is not enabled by default, and its settings are specified within the ``jwt_auth_domain`` section in the ``/etc/wazuh-indexer/opensearch-security/config.yml`` configuration file. Follow the steps below to enable and log into the Wazuh indexer using JWT authentication:
+JWT authentication is not enabled by default, and its settings are specified within the ``dynamic`` section in the ``/etc/wazuh-indexer/opensearch-security/config.yml`` configuration file. Follow the steps below to enable and log into the Wazuh indexer using JWT authentication:
 
-#. Open the ``/etc/wazuh-indexer/opensearch-security/config.yml`` configuration file and update the highlighted settings:
+#. Run the following command twice to generate 64 bytes of cryptographically secure random data and output it as a Base64-encoded string:
+
+   .. code-block:: console
+
+      # openssl rand -base64 64
+      # openssl rand -base64 64
+
+#. Open the ``/etc/wazuh-indexer/opensearch-security/config.yml`` configuration file and update the highlighted settings. Use the first output as a signing key, replacing the ``<SIGNING_KEY>`` variable. Use the second output as an encryption key, replacing the ``<ENCRYPTION_KEY>`` variable below:
 
    .. code-block:: yaml
-      :emphasize-lines: 3,10,14,15
-   
-      jwt_auth_domain:
-        description: "Authenticate via Json Web Token"
-        http_enabled: true
-        transport_enabled: false
-        order: 0
-        http_authenticator:
-          type: jwt
-          challenge: false
-          config:
-            signing_key: "<ENCODED_SIGNING_KEY>"
-            jwt_header: "Authorization"
-            jwt_url_parameter: null
-            jwt_clock_skew_tolerance_seconds: 30
-            roles_key: <ROLES_KEY>
-            subject_key: <SUBJECT_KEY>
-        authentication_backend:
-          type: noop
-   
-   .. note::
-   
-      Replace ``<ENCODED_SIGNING_KEY>`` with your base64 encoded HMAC key or public RSA/ECDSA pem key. Update the values of ``<ROLES_KEY>`` with the name of a backend user the JWT should attach to, and ``<SUBJECT_KEY>`` to a descriptive subject name that identifies the JWT. For example, setting the values to **admin** and **automationUser** respectively will attach the JWT to the internal admin user and name the JWT as automationUser.
+      :emphasize-lines: 3,4,5,6
+
+      config:
+        dynamic:
+          on_behalf_of:
+            enabled: 'true'
+            signing_key: <SIGNING_KEY>
+            encryption_key: <ENCRYPTION_KEY>
 
 #. Run the ``/usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh`` script to load the configuration changes made in the ``/etc/wazuh-indexer/opensearch-security/config.yml`` file:
 
    .. code-block:: console
-   
+
       # export JAVA_HOME=/usr/share/wazuh-indexer/jdk/ && bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh -f /etc/wazuh-indexer/opensearch-security/config.yml -icl -key /etc/wazuh-indexer/certs/admin-key.pem -cert /etc/wazuh-indexer/certs/admin.pem -cacert /etc/wazuh-indexer/certs/root-ca.pem -h 127.0.0.1 -nhnv
 
+#. Run the command below to fetch a JSON web token.
+
+   .. code-block:: console
+
+      # curl -k -u <WAZUH_INDEXER_USER>:<WAZUH_INDEXER_PASSWORD> -XPOST "https://localhost:9200/_plugins/_security/api/generateonbehalfoftoken" -H 'Content-Type: application/json' -d
+      '
+      {
+         "description":"Testing",
+         "service":"Testing Service",
+         "durationSeconds":"180"
+      }
+      '
+
+   Below is an example of an output.
+
+   .. code-block:: json
+      :class: output
+
+      {"user":"admin","authenticationToken":"eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6IlRlc3RpbmcgU2VydmljZSIsIm5iZiI6MTc2Nzc5Njc1NiwiaXNzIjoid2F6dWgtY2x1c3RlciIsImV4cCI6MTc2Nzc5NjkzNiwiaWF0IjoxNzY3Nzk2NzU2LCJlciI6Illid1JkVGxKVDZWRXdvR2lSZS8rblNNalVyNG9zZFM3SnlSZkg5S09LTlE9In0.oUOVhPB6WCidAIp3O9W6GQnngq0dednQQNtBIHExhMhtJcNw9h1aL6MwZ42kGr4JORbA-a-wc9IpKcrUV2omGg","durationSeconds":180}
+
+   Replace the variables ``<WAZUH_INDEXER_USER>:<WAZUH_INDEXER_PASSWORD>`` with your Wazuh indexer username and password.
+
 #. Authenticate to the Wazuh indexer API using your JWT, as seen below. In this example, we use cURL to connect and authenticate:
 
    .. code-block:: console
-   
+
       # curl -k -XGET "https://localhost:9200" -H "Authorization: Bearer <WAZUH_INDEXER_JWT>"
 
-   Replace ``<WAZUH_INDEXER_JWT>`` with your JWT. The expected output is as seen below:
-   
+   Replace ``<WAZUH_INDEXER_JWT>`` with your generated JWT. The expected output is as seen below:
+
    .. code-block:: none
       :class: output
-   
+
       {
         "name" : "node-1",
         "cluster_name" : "wazuh-cluster",
@@ -141,14 +155,16 @@ JWT authentication is not enabled by default, and its settings are specified wit
         "tagline" : "The OpenSearch Project: https://opensearch.org/"
       }
 
-Optionally, you can use your JWT as an environment variable.
+   Optionally, you can use your JWT as an environment variable.
 
-You can access any API endpoint using the below structure. Replace ``<METHOD>`` with the desired method, ``<ENDPOINT>`` with the string corresponding to the endpoint you wish to access, and ``<WAZUH_INDEXER_JWT>`` with your JWT. If you are using an environment variable, replace ``<WAZUH_INDEXER_JWT>`` with your environment variable, for example ``$TOKEN``.
+You can access any API endpoint using the below structure. Replace ``<METHOD>`` with the desired method, ``<ENDPOINT>`` with the string corresponding to the endpoint you wish to access, and ``<WAZUH_INDEXER_JWT>`` with your JWT.
 
 .. code-block:: console
 
    # curl -k -X <METHOD> "https://localhost:9200/<ENDPOINT>" -H "Authorization: Bearer <WAZUH_INDEXER_JWT>"
 
+If you are using an environment variable, replace ``<WAZUH_INDEXER_JWT>`` with your environment variable e.g. ``$TOKEN``.
+
 Configuration options
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -282,7 +298,7 @@ The Python ``requests`` library allows us to send HTTP requests to the Wazuh Ind
    from requests.auth import HTTPBasicAuth
 
    # Base URL and endpoint
-   Wazuh_indexer_url = "https://localhost:9200"
+   wazuh_indexer_url = "https://localhost:9200"
    endpoint = "/_cluster/health"
 
    # Full URL
@@ -349,63 +365,71 @@ Using Bash
 
 You can also interact with the Wazuh indexer API using a bash script. A bash script is preferable when you do not want to install additional programs like Python. In the following ``check_wazuh_indexer_health.sh`` bash script, we query the Wazuh indexer API to retrieve the cluster health status.
 
-.. code-block:: bash
-   :emphasize-lines: 7,8
-
-   #!/bin/bash
-
-   # Base URL and endpoint for Wazuh Indexer API
-   WAZUH_INDEXER_URL="https://localhost:9200"
-   ENDPOINT="/_cluster/health"
-   FULL_URL="${WAZUH_INDEXER_URL}${ENDPOINT}"
-   USERNAME="<WAZUH_INDEXER_USERNAME>"
-   PASSWORD="<WAZUH_INDEXER_PASSWORD>"
-
-   # Make the API request using basic authentication
-   response=$(curl -s -k -u "$USERNAME:$PASSWORD" "$FULL_URL")
-   # Check if the request was successful
-   if [ $? -eq 0 ]; then
-     echo "Cluster Health Status:"
-     # Check if jq is installed
-     if command -v jq > /dev/null; then
-       echo "$response" | jq .
-     else
-       echo "Warning: 'jq' is not installed. Displaying raw JSON response:"
-       echo "$response"
-     fi
-   else
-     echo "Error: Failed to retrieve cluster health."
-   fi
-
-Run the ``check_wazuh_indexer_health`` script:
+#. Create a bash script called ``check_wazuh_indexer_health.sh`` and paste the content below:
 
-.. code-block:: console
+   .. code-block:: bash
+      :emphasize-lines: 7,8
 
-   # ./check_wazuh_indexer_health
+      #!/bin/bash
 
-.. code-block:: none
-   :class: output
+      # Base URL and endpoint for Wazuh Indexer API
+      WAZUH_INDEXER_URL="https://localhost:9200"
+      ENDPOINT="/_cluster/health"
+      FULL_URL="${WAZUH_INDEXER_URL}${ENDPOINT}"
+      USERNAME="<WAZUH_INDEXER_USERNAME>"
+      PASSWORD="<WAZUH_INDEXER_PASSWORD>"
+
+      # Make the API request using basic authentication
+      response=$(curl -s -k -u "$USERNAME:$PASSWORD" "$FULL_URL")
+      # Check if the request was successful
+      if [ $? -eq 0 ]; then
+        echo "Cluster Health Status:"
+        # Check if jq is installed
+        if command -v jq > /dev/null; then
+          echo "$response" | jq .
+        else
+          echo "Warning: 'jq' is not installed. Displaying raw JSON response:"
+          echo "$response"
+        fi
+      else
+        echo "Error: Failed to retrieve cluster health."
+      fi
 
-   Cluster Health Status:
-   {
-     "cluster_name": "wazuh-cluster",
-     "status": "green",
-     "timed_out": false,
-     "number_of_nodes": 1,
-     "number_of_data_nodes": 1,
-     "discovered_master": true,
-     "discovered_cluster_manager": true,
-     "active_primary_shards": 30,
-     "active_shards": 30,
-     "relocating_shards": 0,
-     "initializing_shards": 0,
-     "unassigned_shards": 0,
-     "delayed_unassigned_shards": 0,
-     "number_of_pending_tasks": 0,
-     "number_of_in_flight_fetch": 0,
-     "task_max_waiting_in_queue_millis": 0,
-     "active_shards_percent_as_number": 100
-   }
+#. Run the following command to make the above script executable:
+
+   .. code-block:: console
+
+      # chmod +x check_wazuh_indexer_health.sh
+
+#. Run the ``check_wazuh_indexer_health`` script:
+
+   .. code-block:: console
+
+      # ./check_wazuh_indexer_health.sh
+
+   .. code-block:: none
+      :class: output
+
+      Cluster Health Status:
+      {
+        "cluster_name": "wazuh-cluster",
+        "status": "green",
+        "timed_out": false,
+        "number_of_nodes": 1,
+        "number_of_data_nodes": 1,
+        "discovered_master": true,
+        "discovered_cluster_manager": true,
+        "active_primary_shards": 30,
+        "active_shards": 30,
+        "relocating_shards": 0,
+        "initializing_shards": 0,
+        "unassigned_shards": 0,
+        "delayed_unassigned_shards": 0,
+        "number_of_pending_tasks": 0,
+        "number_of_in_flight_fetch": 0,
+        "task_max_waiting_in_queue_millis": 0,
+        "active_shards_percent_as_number": 100
+      }
 
 .. note::
 
@@ -514,7 +538,7 @@ Example response to report a resource not found exception (HTTPS status code 404
        "reason" : "no such index [testindex]",
        "index" : "testindex",
        "resource.id" : "testindex",
-       "resourcez.type" : "index_or_alias",
+       "resource.type" : "index_or_alias",
        "index_uuid" : "_na_"
      },      
      "status" : 404

source/user-manual/indexer-api/index.rst

@@ -22,7 +22,7 @@ Here is a list of some of the Wazuh indexer API capabilities:
 -  Configuration management
 -  Index lifecycle management
 
-Take a look at the :doc:`Wazuh indexer API use cases <use-case>` for practical examples of how the Wazuh indexer API can be utilized.
+Refer to the :doc:`Wazuh indexer API reference <reference>` for details about all the Wazuh indexer API endpoints. Take a look at the :doc:`Wazuh indexer API use cases <use-case>` for practical examples of how the Wazuh indexer API can be utilized.
 
 .. topic:: Contents