Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Tracked by #4205
jctello opened this issue Jul 11, 2022 · 11 comments · Fixed by #4776
Closed
Tracked by #4205

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

jctello opened this issue Jul 11, 2022 · 11 comments · Fixed by #4776
Assignees
Labels
request/operational Operational requests type/bug Bug issue

Comments

@jctello
Copy link
Contributor

jctello commented Jul 11, 2022

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
image

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
}
@jctello jctello added type/bug Bug issue request/operational Operational requests labels Jul 11, 2022
@gdiazlo gdiazlo mentioned this issue Sep 7, 2022
29 tasks
@gdiazlo
Copy link
Member

gdiazlo commented Sep 9, 2022

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
Copy link
Member

gdiazlo commented Sep 28, 2022

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 chantal-kelm self-assigned this Oct 6, 2022
@chantal-kelm chantal-kelm linked a pull request Oct 6, 2022 that will close this issue
@chantal-kelm
Copy link
Member

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

videoProtocoludp.mp4

@jctello
Copy link
Contributor Author

jctello commented Oct 7, 2022

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.

@Machi3mfl Machi3mfl self-assigned this Oct 12, 2022
@chantal-kelm
Copy link
Member

chantal-kelm commented Oct 20, 2022

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.

syslog.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>

Screenshot from 2022-10-20 12-53-25
Screenshot from 2022-10-20 12-52-10
Screenshot from 2022-10-20 12-36-49

@chantal-kelm

This comment was marked as duplicate.

@chantal-kelm
Copy link
Member

Connection: Secure Protocol: UDP :

udpsecure.mp4

Connection: Secure Protocol: TCP :

TCPSECURE.mp4

Connection: Syslog

syslogtcpnosecure.mp4

Error handling and warning in the UI to the client.

error.mp4

@Machi3mfl
Copy link
Member

Machi3mfl commented Oct 28, 2022

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

Related threads with this topic

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

image

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 the WAZUH_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
Copy link
Member

chantal-kelm commented Nov 3, 2022

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.

Screenshot from 2022-11-03 09-56-51

  • 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
Copy link
Member

Issue solved in #4776

@Machi3mfl
Copy link
Member

Bug found in manual testing fixed in PR #4849

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request/operational Operational requests type/bug Bug issue
Projects
No open projects
Status: Done
5 participants