Configuring a cluster

Reasons for using a cluster

High availability

Servers eventually fail: hardware can be broken, a human can turn them off, the system can go down... And while the server is restored, you won't be able to see what is happening in your agents. Using a cluster you make sure your agents will always have a manager to report to.

Types of nodes

Deploying a Wazuh cluster

1. Set the cluster configuration

   Using the <cluster> section in the Local configuration, set the cluster configuration as below:

   • <node_type>: Set the node type.

   • <key>: The key must be 32 characters long and should be the same for all of the nodes of the cluster. You may use the following command to generate a random one:

     # openssl rand -hex 16
     

   • <disabled>: Set this field to no in order to enable the cluster.

   • <nodes>: The address of the master must be specified in all nodes (including the master itself). The address can be either an IP or a DNS.

     The following is an example of the configuration of a worker node:

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

     And the following is an example of the configuration of a master node:

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

2. Restart the node

   # systemctl restart wazuh-manager
   

Agent registration in the cluster

All agents must be registered in the master node. The master is responsible for replicating the new agent's information across all worker nodes. If an agent is registered in a worker node, it will be deleted by the master node.

Configuring the Wazuh app for Kibana/Splunk

The following must be considered when configuring a Wazuh app:

• The apps must be configured to point to the master's API.

• All worker nodes need an event forwarder in order to send data to Elasticsearch or Splunk. Install Filebeat if you're using the Elastic stack or Splunk forwarder if you're using Splunk. This is only necessary if the node is in a separated instance from Elasticsearch or Splunk.

Installing Filebeat:

Type	Description
DEB packages	Install Filebeat on Amazon Linux 1 or greater.
RPM packages	Install Filebeat on CentOS 6 or greater.
DEB packages	Install Filebeat on Debian 7 or greater.
RPM packages	Install Filebeat on Fedora 22 or greater.
DEB packages	Install Filebeat on OpenSUSE OpenSUSE 42, OpenSUSE Leap and OpenSUSE Tumbleweed.
RPM packages	Install Filebeat on Oracle Linux 6 or greater.
RPM packages	Install Filebeat on Red Hat Enterprise Linux 6 or greater.
RPM packages	Install Filebeat on SUSE 12.
DEB packages	Install Filebeat on Ubuntu 12.04 or greater.

Installing Splunk forwarder:

Type	Description
RPM/DEB packages	Install Splunk forwarder for RPM or DEB based OS.

Pointing agents to the cluster with a load balancer

A load balancer is a service that distributes the workloads across multiple resources. In Wazuh's case, users want to use a load balancer to catch all the agent events and distribute them between the different workers in the cluster.

The correct way to use it is to point every agent to send the events to the load balancer:

1. Edit the Wazuh agent configuration in /var/ossec/etc/ossec.conf to add the Load Balancer IP address. In the <client><server> section, change the LOAD_BALANCER_IP value to the load balancer address and port:

   <client>
     <server>
       <address>LOAD_BALANCER_IP</address>
       ...
     </server>
   </client>
   

2. Restart the agents:

   1. For Systemd:

   # systemctl restart wazuh-agent
   

   2. For SysV Init:

   # service wazuh-agent restart
   

3. Include in the Load Balancer the IP of every instance of the cluster we want to deliver events.

   This configuration will depend of the load balancer service choosen.

Here is a short configuration guide of a load balancer using Nginx:

1. Install Nginx in the load balancer instance:

   • Download the packages from the Official Page.

   • Follow the steps related on that guide to install the packages.

2. Configure the instance as a load balancer:

   • The way nginx and its modules work is determined in the configuration file. By default, the configuration file is named nginx.conf and placed in the directory /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx.

   • Now, open the configuration file and add the following structure:

     stream {
         upstream cluster {
             hash $remote_addr consistent;
             server <WAZUH-MASTER-IP>:1514;
             server <WAZUH-WORKER1-IP>:1514;
             server <WAZUH-WORKER2-IP>:1514;
         }
         upstream master {
             server <WAZUH-MASTER-IP>:1515;
         }
         server {
             listen 1514;
             proxy_pass cluster;
         }
         server {
             listen 1515;
             proxy_pass master;
         }
     }
     

   • You can find more details in nginx guide for configuring TCP and UDP load balancer.

3. Restart nginx configuration files:

   # nginx -s reload
   

Keep in mind the following considerations:

• It is recommended to use TCP protocol instead of UDP. Permanent connections and stickiness are needed in order to make sure agent data is consistent. In order to use the TCP protocol, you should configure both your agents and your nodes.

• Disable the option use_source_ip in your authd configuration. When using a LB, the cluster nodes will only see the LB's IP and no the agents'. This will make the agents unable to connect to the cluster.

Keep alive thread

The keep alive thread sends a keep-alive to the master every so often. It is necessary to keep the connection opened between master and worker, since the cluster uses permanent connections.

Agent info thread

The agent info thread sends the statuses of the agents that are reporting to the worker node. The master checks the modification date of each received agent status file and keeps the most recent one.

The master also checks whether the agent exists or not before saving its status update. This is done to prevent the master to store unnecessary information. For example, this situation is very common when an agent is removed but the master hasn't notified worker nodes yet.

Integrity thread

The integrity thread is in charge of synchrozing the files sent by the master node to the workers. Those files are:

• Agent keys file.

• User defined rules, decoders and CDB lists.

• Agent groups files and assignments.

Usually, the master is responsible for sending group assignments, but just in case a new agent starts reporting in a worker node, the worker will send the new agent's group assignment to the master.

File Integrity Thread

The integrity of each file is calculated using its MD5 checksum and its modification time. To avoid calculating the integrity with each worker connection, the integrity is calculated in a different thread, called File integrity thread, in the master node every so often.