Cluster configuration in ossec.conf is not being parsed correctly in some cases

[jmv74211]

Wazuh version	Component	Install type	Install method	Platform
4.2.0-40202	Server	Manager	Packages	Amazon linux 2

While testing for the development of the cluster performance test, I noticed the following case:

When an agent was connected and reporting a cluster worker node, I saw how indeed the worker was receiving those EPS, but when checking the agent status in the master node, that agent appeared as never connected and its status never changed.

Then I checked that the configuration was correct, that the worker node was in this mode...

The result appeared apparently normal:

NAME                                            TYPE    VERSION  ADDRESS       
master                                          master  4.2.0    172.31.10.32  
Test_cluster_performance_sprint2_B75_manager_1  worker  4.2.0    172.31.0.232  

The next step was to check if the agent was correctly sending the keep-alive to the worker node and why this worker node was not sending the synchronization information to the master node.

After making the corresponding query to wazuh-db, we observed that its last_keepalive was changing but that its sync_status always had the same value: synced

I was discussing this with several people in the team and we all discovered that the reason was that the whole configuration was not being parsed properly, and that the worker node was in master mode instead, even though in the master it appeared as a worker node (see the previous output of cluster_control -l).

First of all, we saw that the "worker" node was not, because when we put remoted in debug mode, it showed the following log:

2021/04/16 06:51:17 wazuh-remoted[9005] main.c:148 at main(): DEBUG: This is not a worker

The reason for this was that the following configuration was not being parsed correctly:

<ossec_config>

.....

  <cluster>
    <name>wazuh</name>
    <node_name>node01</node_name>
    <node_type>master</node_type>
    <key></key>
    <port>1516</port>
    <bind_addr>0.0.0.0</bind_addr>
    <nodes>
        <node>NODE_IP</node>
    </nodes>
    <hidden>no</hidden>
    <disabled>yes</disabled>
  </cluster>

</ossec_config>

...

<ossec_config>
  <cluster>
    <name>wazuh</name>
      <node_name>Test_cluster_performance_sprint2_B75_manager_1</node_name>
      <node_type>worker</node_type>
      <key>c98b62a9b6169ac5f67dae55ae4a9088</key>
      <port>1516</port>
      <bind_addr>0.0.0.0</bind_addr>
      <nodes>
        <node>172.31.10.32</node>
      </nodes>
      <hidden>no</hidden>
      <disabled>no</disabled>
  </cluster>
</ossec_config>

That is, it seems that when there is a second block, this second one prevails, (in fact in this case it can be observed that in the first one it is deactivated and in the second one it is activated, and the final result is that it was activated), but at the time of obtaining the type of the node, the last value block is not taken.

As a curious fact, if I set worker as node type in the first and second configuration block, it does not work correctly either, since the node still behaves as a master.

If I comment this first block or delete it, the configuration is already being read correctly and the node is considered as a worker.

2021/04/16 07:18:25 wazuh-remoted[11810] main.c:152 at main(): DEBUG: Cluster worker node: Disabling the merged.mg creation

It is requested to fix this case, because although it may not be very frequent that there are two configuration blocks for the cluster, this may cause some type of failure in the future in this case or for any other in which the same is used parser.

Regards.