Code Monkey home page Code Monkey logo

wazuh-multi-node's Introduction

Wazuh clustering, simplified.

A Wazuh cluster is a group of Wazuh managers that work together to enhance the availability and scalability of the service. With a Wazuh cluster setup, we have the potential to greatly increase the number of agents as long as we add worker nodes whenever necessary.

Reasons for using a cluster:
Horizontal scalability. It multiplies Wazuh's event processing capacity and allows it to have thousands of agents reporting. Adding a new node to the cluster is very simple (just add the master's address in the configuration) and it can be automated easily, giving the user the ability to implement auto-scaling.

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.

wazuh-clustering

Types of nodes:
Master. The master node centralizes and coordinates worker nodes, making sure the critical and required data is consistent across all nodes. It provides the centralization of the following:

  • Agent registration.
  • Agent deletion.
  • Configuration of agents grouping.
  • Rules, decoders, and CDB lists synchronization.

All communications among nodes in the cluster are encrypted using AES algorithm.

Worker. Worker nodes are responsible for three main tasks:

  • Redirecting agent registration requests to the master.
  • Synchronizing integrity files from the master node.
  • Sending agent status updates to the master.

How the cluster works:
The cluster is managed by a daemon, called wazuh-clusterd, which communicates with all the nodes following a master-worker architecture. Refer to the Daemons section for more information about its use.

The image below shows the communications between a worker and a master node. Each worker-master communication is independent of each other, since workers are the ones who start the communication with the master.

There are different independent threads running and each one is framed in the image:

  • Keep alive thread. Responsible of sending a keep alive to the master every so often.
  • Agent info thread. Responsible of sending the statuses of the agents that are reporting to that node.
  • Agent groups send thread. Responsible of sending information of agent groups assignment to workers.
  • Local agent-groups thread. Responsible of reading all new agent groups information in the master.
  • Integrity thread. Responsible of synchronizing files in the cluster.
  • Local integrity thread. Responsible of calculating files' checksums in the master.

wazuh-cluster-sync

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 OS information, labels configured, and statuses of the agents that are reporting to the worker node.

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

Agent groups send thread. The agent groups send thread sends information from the master to all the workers about the groups to which each agent belongs. The information is calculated in the master when an agent connects for the first time.

Local agent-groups thread. The master needs to get agent-groups information from the database before sending it to all the workers. To avoid requesting it once per each worker connection, the information is obtained and stored in a different thread called Local agent-groups thread, in the master node, every so often.

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

  • Groups files.
  • The Wazuh agent keys file.
  • User defined rules, decoders and CDB lists.

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

wazuh-multi-node's People

Contributors

ahmadmavali avatar theuker avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.