Deployment variables wrongly use protocol for syslog if it is declared first

[jctello]

Manager	Indexer	Rev	Security
v4.3.5	Wazuh Indexer 4.3.5	4306	Basic

Description When the configuration stanza for a remote syslog collection is specified before than that for the agent's secure connection on the manager's ossec.conf the protocol shown in the Deploy agent screen will be that of the syslog configuration instead of the agents.

This is because here the plugin asks for the first remote connection instead of verifying the type of connection.

Preconditions The manager must be configured as follows:

<!--
  Wazuh - Manager - Default configuration for centos 7.9
  More info at: https://documentation.wazuh.com
  Mailing list: https://groups.google.com/forum/#!forum/wazuh
-->

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>yes</logall_json>
    <email_notification>no</email_notification>
    <smtp_server>smtp.example.wazuh.com</smtp_server>
    <email_from>wazuh@example.wazuh.com</email_from>
    <email_to>recipient@example.wazuh.com</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    <agents_disconnection_time>10m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
  </global>

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>12</email_alert_level>
  </alerts>

  <!-- Choose between "plain", "json", or "plain,json" for the format of internal logs -->
  <logging>
    <log_format>plain</log_format>
  </logging>

  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>0.0.0.0/0</allowed-ips>
  </remote>

  <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
    <queue_size>131072</queue_size>
  </remote>
...

Steps to reproduce

1. Place a remote syslog connection before the secure agent connection as shown above
2. Go to Agents > Deploy new agent
3. Select the options for any operating system
4. Observe how the protocol reflects the configuration for syslog instead of the agent

Expected Result

1. Protocol should not be shown in deployment variables, so the default (TCP) will be used

Actual Result

1. Protocol is specified as UDP in deployment variables

Screenshots

Additional context The API reply for this configuration is:

{
  "data": {
    "remote": [
      {
        "connection": "syslog",
        "ipv6": "no",
        "protocol": [
          "UDP"
        ],
        "port": "514",
        "allowed-ips": [
          "0.0.0.0/0"
        ]
      },
      {
        "connection": "secure",
        "ipv6": "no",
        "protocol": [
          "TCP"
        ],
        "port": "1514",
        "queue_size": "131072"
      }
    ]
  },
  "error": 0
}

[gdiazlo]

In the case described, the Wazuh API returns:

{
    "data": {
        "remote": [
            {
                "connection": "syslog",
                "ipv6": "no",
                "protocol": [
                    "UDP"
                ],
                "port": "514",
                "allowed-ips": [
                    "0.0.0.0/0"
                ]
            },
            {
                "connection": "secure",
                "ipv6": "no",
                "protocol": [
                    "TCP"
                ],
                "port": "1514",
                "queue_size": "131072"
            }
        ]
    },
    "error": 0
}

The API specification does detail what kind of object is returned by each request as per its documentation.

The remote object specification (ref) does not allow us to make decisions automatically about the protocol used by a new agent.

If we use the port to identify where an agent should connect, we assume there are no cases in which the user might change the port used for agent communication.

We can make the user select which remote an agent should connect to, but this might be a burden for the kind of user interested in the agent registration wizard.

Design proposal:

• if there is only one remote, we use it to select the protocol (same as today)
• If there are multiple remotes, select those of them who are configured as secure, and present the user a dropdown to select the name of the desired remote. We must validate the protocol is compatible with the agent's capabilities.
• Propose to add the name attribute to the remote, so a user can tell the difference between remotes by name.

[gdiazlo]

We have decided we will use the first entry of type secure:

• if a connection is secure, the protocol can be TCP, UDP or both.
• if the protocol is TCP or both, then we the protocol selected will be TCP, so no environment variable will be set.
• if the protocol is UDP and only UDP, then we will generate the variable WAZUH_PROTOCOL with value udp

[chantal-kelm]

This is how the "Deploy new agent" section looks like today after adding the development of this issue

https://user-images.githubusercontent.com/99441266/194386566-f9011991-bc33-4d6f-9512-ef29e669eefc.mp4

[jctello]

Hi @chantal-kelm thank you for the video, it shows as corrupt in several OS/Browser combinations, but I was able to download it.

I see that while it is taking the first secure remote setting as expected, when there is no secure remote setting it will incorrectly claim you do not have permissions to read groups and provide an installation command without the manager's address and the syslog's protocol.

It should instead provide a warning to the user that there's no secure protocol configured and agents will not be able to communicate with the manager.

It's important to note that this broken behavior is observed Wazuh v4.3.8, but it would make sense to include it in the scope of this issue.

[chantal-kelm]

We are getting a 500 error when we put in the ossec.conf the connection "syslog", if we try with "secure" it works fine and returns a 200. This issue is being consulted with Framework.

https://user-images.githubusercontent.com/99441266/196984070-35e5b1e6-2522-4510-90a0-34fb968f6b40.mp4

<!--
  Wazuh - Manager - Default configuration for ubuntu 18.04
  More info at: https://documentation.wazuh.com/
  Mailing list: https://groups.google.com/forum/#!forum/wazuh
-->

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>no</logall_json>
    <email_notification>no</email_notification>
    <smtp_server>smtp.example.wazuh.com</smtp_server>
    <email_from>wazuh@example.wazuh.com</email_from>
    <email_to>recipient@example.wazuh.com</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    <agents_disconnection_time>10m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
  </global>

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>12</email_alert_level>
  </alerts>

  <!-- Choose between "plain", "json", or "plain,json" for the format of internal logs -->
  <logging>
    <log_format>plain</log_format>
  </logging>

 <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>0.0.0.0/0</allowed-ips>
  </remote>

  <!-- Policy monitoring -->
  <rootcheck>
    <disabled>no</disabled>
    <check_files>yes</check_files>
    <check_trojans>yes</check_trojans>
    <check_dev>yes</check_dev>
    <check_sys>yes</check_sys>
    <check_pids>yes</check_pids>
    <check_ports>yes</check_ports>
    <check_if>yes</check_if>

    <!-- Frequency that rootcheck is executed - every 12 hours -->
    <frequency>43200</frequency>

    <rootkit_files>etc/rootcheck/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>etc/rootcheck/rootkit_trojans.txt</rootkit_trojans>

    <skip_nfs>yes</skip_nfs>
  </rootcheck>

  <wodle name="cis-cat">
    <disabled>yes</disabled>
    <timeout>1800</timeout>
    <interval>1d</interval>
    <scan-on-start>yes</scan-on-start>

    <java_path>wodles/java</java_path>
    <ciscat_path>wodles/ciscat</ciscat_path>
  </wodle>

  <!-- Osquery integration -->
  <wodle name="osquery">
    <disabled>yes</disabled>
    <run_daemon>yes</run_daemon>
    <log_path>/var/log/osquery/osqueryd.results.log</log_path>
    <config_path>/etc/osquery/osquery.conf</config_path>
    <add_labels>yes</add_labels>
  </wodle>

  <!-- System inventory -->
  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="no">yes</ports>
    <processes>yes</processes>

    <!-- Database synchronization settings -->
    <synchronization>
      <max_eps>10</max_eps>
    </synchronization>
  </wodle>

  <sca>
    <enabled>yes</enabled>
    <scan_on_start>yes</scan_on_start>
    <interval>12h</interval>
    <skip_nfs>yes</skip_nfs>
  </sca>

  <vulnerability-detector>
    <enabled>no</enabled>
    <interval>5m</interval>
    <min_full_scan_interval>6h</min_full_scan_interval>
    <run_on_start>yes</run_on_start>

    <!-- Ubuntu OS vulnerabilities -->
    <provider name="canonical">
      <enabled>no</enabled>
      <os>trusty</os>
      <os>xenial</os>
      <os>bionic</os>
      <os>focal</os>
      <os>jammy</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Debian OS vulnerabilities -->
    <provider name="debian">
      <enabled>no</enabled>
      <os>buster</os>
      <os>bullseye</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- RedHat OS vulnerabilities -->
    <provider name="redhat">
      <enabled>no</enabled>
      <os>5</os>
      <os>6</os>
      <os>7</os>
      <os>8</os>
      <os>9</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Amazon Linux OS vulnerabilities -->
    <provider name="alas">
      <enabled>no</enabled>
      <os>amazon-linux</os>
      <os>amazon-linux-2</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- SUSE OS vulnerabilities -->
    <provider name="suse">
      <enabled>no</enabled>
      <os>11-server</os>
      <os>11-desktop</os>
      <os>12-server</os>
      <os>12-desktop</os>
      <os>15-server</os>
      <os>15-desktop</os>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Arch OS vulnerabilities -->
    <provider name="arch">
      <enabled>no</enabled>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Windows OS vulnerabilities -->
    <provider name="msu">
      <enabled>yes</enabled>
      <update_interval>1h</update_interval>
    </provider>

    <!-- Aggregate vulnerabilities -->
    <provider name="nvd">
      <enabled>yes</enabled>
      <update_from_year>2010</update_from_year>
      <update_interval>1h</update_interval>
    </provider>

  </vulnerability-detector>

  <!-- File integrity monitoring -->
  <syscheck>
    <disabled>no</disabled>

    <!-- Frequency that syscheck is executed default every 12 hours -->
    <frequency>43200</frequency>

    <scan_on_start>yes</scan_on_start>

    <!-- Generate alert when new file detected -->
    <alert_new_files>yes</alert_new_files>

    <!-- Don't ignore files that change more than 'frequency' times -->
    <auto_ignore frequency="10" timeframe="3600">no</auto_ignore>

    <!-- Directories to check  (perform all possible verifications) -->
    <directories>/etc,/usr/bin,/usr/sbin</directories>
    <directories>/bin,/sbin,/boot</directories>

    <!-- Files/directories to ignore -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore>/etc/mail/statistics</ignore>
    <ignore>/etc/random-seed</ignore>
    <ignore>/etc/random.seed</ignore>
    <ignore>/etc/adjtime</ignore>
    <ignore>/etc/httpd/logs</ignore>
    <ignore>/etc/utmpx</ignore>
    <ignore>/etc/wtmpx</ignore>
    <ignore>/etc/cups/certs</ignore>
    <ignore>/etc/dumpdates</ignore>
    <ignore>/etc/svc/volatile</ignore>

    <!-- File types to ignore -->
    <ignore type="sregex">.log$|.swp$</ignore>

    <!-- Check the file, but never compute the diff -->
    <nodiff>/etc/ssl/private.key</nodiff>

    <skip_nfs>yes</skip_nfs>
    <skip_dev>yes</skip_dev>
    <skip_proc>yes</skip_proc>
    <skip_sys>yes</skip_sys>

    <!-- Nice value for Syscheck process -->
    <process_priority>10</process_priority>

    <!-- Maximum output throughput -->
    <max_eps>100</max_eps>

    <!-- Database synchronization settings -->
    <synchronization>
      <enabled>yes</enabled>
      <interval>5m</interval>
      <max_interval>1h</max_interval>
      <max_eps>10</max_eps>
    </synchronization>
  </syscheck>

  <!-- Active response -->
  <global>
    <white_list>127.0.0.1</white_list>
    <white_list>^localhost.localdomain$</white_list>
    <white_list>181.30.140.196</white_list>
    <white_list>181.30.140.136</white_list>
  </global>

  <command>
    <name>disable-account</name>
    <executable>disable-account</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <command>
    <name>restart-wazuh</name>
    <executable>restart-wazuh</executable>
  </command>

  <command>
    <name>firewall-drop</name>
    <executable>firewall-drop</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <command>
    <name>host-deny</name>
    <executable>host-deny</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <command>
    <name>route-null</name>
    <executable>route-null</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <command>
    <name>win_route-null</name>
    <executable>route-null.exe</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <command>
    <name>netsh</name>
    <executable>netsh.exe</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <!--
  <active-response>
    active-response options here
  </active-response>
  -->

  <!-- Log analysis -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/ossec/logs/active-responses.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/dpkg.log</location>
  </localfile>

  <localfile>
    <log_format>command</log_format>
    <command>df -P</command>
    <frequency>360</frequency>
  </localfile>

  <localfile>
    <log_format>full_command</log_format>
    <command>netstat -tulpn | sed 's/\([[:alnum:]]\+\)\ \+[[:digit:]]\+\ \+[[:digit:]]\+\ \+\(.*\):\([[:digit:]]*\)\ \+\([0-9\.\:\*]\+\).\+\ \([[:digit:]]*\/[[:alnum:]\-]*\).*/\1 \2 == \3 == \4 \5/' | sort -k 4 -g | sed 's/ == \(.*\) ==/:\1/' | sed 1,2d</command>
    <alias>netstat listening ports</alias>
    <frequency>360</frequency>
  </localfile>

  <localfile>
    <log_format>full_command</log_format>
    <command>last -n 20</command>
    <frequency>360</frequency>
  </localfile>

  <ruleset>
    <!-- Default ruleset -->
    <decoder_dir>ruleset/decoders</decoder_dir>
    <rule_dir>ruleset/rules</rule_dir>
    <rule_exclude>0215-policy_rules.xml</rule_exclude>
    <list>etc/lists/audit-keys</list>
    <list>etc/lists/amazon/aws-eventnames</list>
    <list>etc/lists/security-eventchannel</list>

    <!-- User-defined ruleset -->
    <decoder_dir>etc/decoders</decoder_dir>
    <rule_dir>etc/rules</rule_dir>
  </ruleset>

  <rule_test>
    <enabled>yes</enabled>
    <threads>1</threads>
    <max_sessions>64</max_sessions>
    <session_timeout>15m</session_timeout>
  </rule_test>

  <!-- Configuration for wazuh-authd -->
  <auth>
    <disabled>no</disabled>
    <port>1515</port>
    <use_source_ip>no</use_source_ip>
    <purge>yes</purge>
    <use_password>no</use_password>
    <ciphers>HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH</ciphers>
    <!-- <ssl_agent_ca></ssl_agent_ca> -->
    <ssl_verify_host>no</ssl_verify_host>
    <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
    <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
    <ssl_auto_negotiate>no</ssl_auto_negotiate>
  </auth>

  <cluster>
    <name>wazuh</name>
    <node_name>master-node</node_name>
    <node_type>master</node_type>
    <key>9d273b53510fef702b54a92e9cffc82e</key>
    <port>1516</port>
    <bind_addr>0.0.0.0</bind_addr>
    <nodes>
        <node>wazuh-manager-master</node>
    </nodes>
    <hidden>no</hidden>
    <disabled>no</disabled>
  </cluster>

</ossec_config>

[chantal-kelm]

This issue was developed with the imposter as we have not yet received a response from the Framework team to a possible bug in the api.

This PR fixes this issue and now only displays the WAZUH_PROTOCOL variable if a connection is type secure and its protocol is UDP.

In the video you can see that when a connection is secure and its protocol is UDP, the variable WAZUH_PROTOCOL appears in the installation command, otherwise it does not appear.

https://user-images.githubusercontent.com/99441266/197762041-43f6068f-2a5c-47c5-92f7-34771fb9b8cb.mp4

Added message and link to documentation when connection type is unsecure

Test

Go to the Agents tab Click on the 'Deploy new agent' button *Verify that when a connection is type secure and its protocol is UDP, the variable WAZUH_PROTOCOL appears in the installation command, otherwise it does not appear.

You can use this data to test with the imposter: CASE 1: Variable WAZUH_PROTOCOL should appear in the install command.

{
    "data": {
      "remote": [
        {
          "connection": "syslog",
          "ipv6": "no",
          "protocol": [
            "UDP"
          ],
          "port": "514",
          "allowed-ips": [
            "0.0.0.0/0"
          ]
        },
        {
          "connection": "secure",
          "ipv6": "no",
          "protocol": [
            "UDP"
          ],
          "port": "1514",
          "queue_size": "131072"
        }
      ]
    },
    }, "error": 0
  }

Case 2: WAZUH_PROTOCOL variable should not appear in the install command

{
    "data": {
      "remote": [
        {
          "connection": "syslog",
          "ipv6": "no",
          "protocol": [
            "UDP"
          ],
          "port": "514",
          "allowed-ips": [
            "0.0.0.0/0"
          ]
        },
        {
          "connection": "secure",
          "ipv6": "no",
          "protocol": [
            "TCP"
          ],
          "port": "1514",
          "queue_size": "131072"
        }
      ]
    },
    }, "error": 0
  }

[chantal-kelm]

Connection: Secure Protocol: UDP :

https://user-images.githubusercontent.com/99441266/198362522-3a11be0f-5339-4fe1-a80f-ab74ea004261.mp4

Connection: Secure Protocol: TCP :

https://user-images.githubusercontent.com/99441266/198362710-14078974-98da-4f83-bf17-723f40dee910.mp4

Connection: Syslog

https://user-images.githubusercontent.com/99441266/198362818-e2f8f5e2-e349-4427-825c-2256fee6f7f1.mp4

Error handling and warning in the UI to the client.

https://user-images.githubusercontent.com/99441266/198363223-246b9ddf-53b3-42cf-98f2-bd28a97cc32e.mp4

[Machi3mfl]

Researching with the team and with the collaboration of @Desvelao and @chantal-kelm. We found that the following issues are related and we need to treat and think of solutions for both new features at the same time

• 4318

• 4109

Related threads with this topic

• https://github.com/wazuh/wazuh-kibana-app/pull/4737#issuecomment-1291711949
• https://github.com/wazuh/wazuh-kibana-app/pull/4760#discussion_r1005401745

Exists different use cases to consider to prepare the new feature. We need to consider both params WAZUH_MANAGER, WAZUH_PROTOCOL to define the values of each other. We can't treat it separately because the protocol depends on the selected node in the Server Address input and we need to consider it to avoid showing a wrong deploy new agent command to the user.

The new Server Address Multi Selector behavior is documented in this comment issue

Uses cases to consider.

1.When the user adds in the selector 2 nodes/workers and both share the same protocol (UDP/TCP).

Solution to consider

• We should select the shared protocol that allows running the deploy new agent command without issues (register agents in both nodes)

2. When the user adds in the selector 2 nodes/workers that one of them has only UDP protocol.

Solution to consider If we add theWAZUH_PROTOCOL=UDP in the command the node with TCP will not work.

Solution to consider

• We should allow to the user selects the Server Address input nodes that not shares protocol?
• We should show an alert message saying that the command couldn't work because we are selecting nodes that don't share connection protocol?

3.When the user types the IP/DNS address manually

In this case, if the is not registered, we can't know what protocol is used.

Solution to consider

• We should allow to the user enter an address manually?
• We should try to suggest the WAZUH_PROTOCOL param?

Feel free to add more use cases that I didn't consider. And we add this thread to share opinions and find a better solution for bringing a better user experience and avoiding problems with the deploy new agent command

[chantal-kelm]

According to what we have discussed with the Framework team these are the cases we are going to take into account:

Uses cases.

• In all cases the client can only choose one IP.

• When the client has the IP address configured then in the server address field you will see that IP address and the protocol will be TCP.

• In case the user does not have the IP address configured then a selector will be shown in the server address where the manager and cluster will be shown, the user can choose one and based on the one he chooses, the protocol will be TCP or UDP as appropriate, the user can also write an IP and in that case the protocol will be TCP.

[Machi3mfl]

Issue solved in https://github.com/wazuh/wazuh-kibana-app/pull/4776

[Machi3mfl]

Bug found in manual testing fixed in PR https://github.com/wazuh/wazuh-kibana-app/pull/4849