Wazuh Architecture Overview : A Complete Guide to Security Monitoring

 


WAZUH ARCHITECTURE OVERVIEW


Hi everyone!

Whether you're new to Wazuh or looking to deepen your understanding of its architecture, this guide will walk you through its core components, data flow, and deployment best practices.

In this post, I break down how Wazuh’s agent-server-indexer model works, how data is securely moved between components, and why its architecture makes it a scalable solution for security teams of all sizes. Let’s dive in!

Wazuh Architecture Overview

 Wazuh is a powerful security monitoring solution that utilizes agents to collect and forward security data from monitored endpoints to a central server. The architecture supports both agent-based and agentless monitoring, ensuring flexibility in various network environments.

Wazuh Architecture Components

The Wazuh architecture is primarily composed of agents, a central server, and an indexer. The agents run on monitored endpoints and are responsible for forwarding security data to the Wazuh server. In addition to agents, Wazuh supports agentless devices such as firewalls, switches, routers, and access points, which can submit log data via Syslog, SSH, or their APIs.



 Central Server and Indexer

The central server plays a crucial role in decoding and analyzing the incoming data. It then passes the processed results to the Wazuh indexer for indexing and storage. The Wazuh indexer cluster consists of one or more nodes that communicate with each other to perform read and write operations on indices.

 • Single-node Clusters: Suitable for small deployments that do not require processing large volumes of data. 

 • Multi-node Clusters: Recommended for environments with numerous monitored endpoints, high data volume, or where high availability is essential.


 For optimal performance in production environments, it is advisable to deploy the Wazuh server and Wazuh indexer on separate hosts. In this configuration, Filebeat is utilized to securely forward Wazuh alerts and archived events to the Wazuh indexer cluster using TLS encryption.



 Wazuh Agent- Wazuh Server Communication

The Wazuh agent continuously sends events to the Wazuh server for analysis and threat detection. The agent establishes a connection with the server service, which listens on port 1514 by default (configurable). The server decodes and checks the received events against predefined rules. 

• Event Logging: 

Events are logged in two files:

 • /var/ossec/logs/archives/archives.json: Contains all events.

 • /var/ossec/logs/alerts/alerts.json: Contains only events that triggered a rule with a priority above a configurable threshold. 

The Wazuh messages protocol employs AES encryption by default, ensuring secure communication.

 Wazuh Server- Wazuh Indexer Communication

 The Wazuh server utilizes Filebeat to securely transmit alert and event data to the Wazuh indexer via TLS encryption. The indexer listens on port 9200/TCP by default. Once the data is indexed, it can be analyzed and visualized through the Wazuh dashboard. The Vulnerability Detection module within Wazuh updates the vulnerability inventory and generates alerts, providing insights into system vulnerabilities.


Wazuh Dashboard

The Wazuh dashboard interacts with the Wazuh RESTful API, which listens on port 55000/TCP by default on the Wazuh server. The dashboard displays configuration and status information of the Wazuh server and agents, and it can modify settings through API calls. All communications are encrypted with TLS and authenticated using a username and password.


Conclusion

The Wazuh architecture is designed to provide robust security monitoring through a combination of agents, a central server, and an indexer. By understanding the components and communication protocols, users can effectively deploy and manage Wazuh in various environments, ensuring comprehensive security oversight.

Comments

Post a Comment

Popular posts from this blog

Exploting Android using Metasploit on Kali linux

Image
  Hello everyone, this blog is related to exploiting Android system using Kali Linux. So, basically we need two operating systems, First one is kali(attacker) and second one is Android(victim). This Practical works when both of the machines are in same network. So. I have installed Kali-linux in Virtualbox and I am using Genymotion for Android. And I have managed to put the both machines on same network, you have to do same if you are also trying to do same as me. Otherwise Important is both the machines has to be on same network, This also works if you have host machine kali and on other side you have Android Device with you. You can also install kali on Virtualbox and set it to NAT network. For surety u can ping the Android Device machine from Kali to check that the machines are on same network or not. Practical Starts Here -  1. go to kali terminal and type the following command.  type your kali ip instead of  170.9.210.105        msfv...
Read more

Wifi phishing using Wifiphisher

Image
  Hello everyone , this blog is related to Wifi phishing . So , lets get started. What is Wifi phishing? Wifi phishing is when cyber criminals create a malicious Wifi  access point that appears similar or identical to a legitimate Wifi  access point. This malicious Wifi access point is sometimes known  as the "evil twin".   Unsuspecting users can be fooled into connecting to the malicious WiFI point in the belief it is the legitimate connection. Once connected to the cyber criminals' network, the user will still have an internet connection, but the criminal has access to that user’s system. Because of the open access that wireless networks offer, securing the platform from phishing and many other attacks becomes difficult. Individuals who are not aware of proper security protocols when accessing a WiFi connection, will easily be made a victim to phishing attacks. REQUIREMENTS : Internet Connection and a external adaptor STEPS: 1.  Get connected to an ...
Read more