SIEM SERIES WAZUH

In the last edition of the SIEM series, we discussed EFK (Elasticsearch, Fluentd, and Kibana), which included a general overview of the technology stack before diving into a hands-on practice. As a reminder, this blog series is not meant to replace course training but rather to introduce the audience to what is involved with SIEM and explain how it works at a basic level. Additionally, I also wanted to help users create easy sandbox environments where they can practice while they learn.

What is Wazuh?

Wazuh is an opensource complete SIEM (Security Information and Event Management) and XDR (Extended Detection and Response) platform. It was created as a fork from Ossec in 2015 and was intended to modernize and extend the latter’s capabilities. Its goal is to become a unified security monitoring solution.

It has tried to address some of the complexities that we witnessed in ELK and make it easier to create your own monitoring system.

Core Components of Wazuh

Wazuh is a powerful open-source security platform that integrates threat detection, integrity monitoring, incident response, and compliance management. Its architecture is modular, comprising several key components:

• Wazuh Agent: Installed on endpoints (servers, VMs, containers), the agent collects security data such as logs, file integrity changes, and system inventory. Wazuh also supports agentless monitoring via Syslog, SSH, or APIs for devices like firewalls and routers.
• Wazuh Server: The central processing unit of the platform. It receives data from agents or external sources, decodes it, applies rules, and generates alerts. It also manages agent configurations and orchestrates communication across the platform.
• Analysis Engine: A subsystem within the Wazuh Server that applies detection rules, correlates events, and identifies threats. It enriches events with metadata like rule IDs and severity levels.
• Wazuh Indexer: Built on OpenSearch, this component stores and indexes alerts and events. It enables fast search, filtering, and analytics across large datasets. Filebeat is used to securely forward data from the server to the indexer.
• Wazuh Dashboard: A web-based interface for visualizing alerts, managing agents, and interacting with the platform. It communicates with the Wazuh Server via a RESTful API and supports real-time monitoring, threat hunting, and compliance reporting.

Wazuh can be deployed as a single-node or multi-node architecture depending on scalability and performance needs.

How Wazuh Works: A Step-by-Step Overview

The process can be summarized into the following steps:

1. Wazuh collects data from endpoints using agents. This includes logs, system activity, and file changes. For systems without agents, data can be collected via Syslog, SSH, or APIs.
2. The server receives and decodes the data, preparing it for analysis.
3. The analysis engine applies rules to detect threats or policy violations. Alerts are generated and enriched with relevant details.
4.  Alerts and events are sent to the indexer, where they’re stored and made searchable.
5. The dashboard lets users view alerts, monitor systems, and manage configurations through a web interface.

As we covered earlier in this series, raw syslog messages aren’t ideal for building dashboards or triggering alerts. To make them useful, we need to break them down into structured, readable data. In simple terms, creating clear key-value pairs is essential—especially when working with visualization tools like Kibana or the Wazuh Dashboard.

Parsing and More Parsing

Logstash and Fluentd are general purpose log processing engines and are designed for flexibility. However, often flexibility requires complexity. During our walk-through example of grok parsing it was evident that this is an acquired skill and requires time and effort to gain expertise in.

Wazuh chose a slightly different path and uses two stages to process the logs. The first stage leverages decoders while the second one uses the rules. Wazuh attempts to make it easier to parse logs for security purposes by leveraging decoders and regulations with built-in security parsers.

In a nutshell, this is how we can compare what we saw with Logstash/Fluentd to Wazuh Decoders and Rules:

Aspect	Logstash/Fluentd	Wazuh Decoders & Rules
Purpose	Generic log processing	Security event analysis
Out-of-box capability	Empty pipeline	3,000+ security rules ready
Security context	Manual implementation	Built-in threat intelligence
Field extraction	Generic grok patterns	Security-aware decoders
Correlation	Manual configuration	Automatic event correlation
Compliance mapping	Custom development	Pre-mapped to frameworks
Threat detection	Build from scratch	Immediate threat detection
Time to security value	Weeks/months	Hours/days

Sandbox Tutorial

Just like in our previous posts in this SIEM series, we’re all about hands-on learning. In this exercise, we’ll be working with an Ubuntu virtual machine to install Wazuh directly on the operating system—no Docker this time. For our test lab setup, Wazuh offers a convenient installation script that makes the process quick and straightforward.

Please use this link for the tutorial section:

https://documentation.wazuh.com/current/quickstart.html  

Wazuh Single Node Installation

1. Run the below script:

curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh && sudo bash ./wazuh-install.sh -acurl -sO https://packages.wazuh.com/4.12/wazuh-install.sh

2. When the script finishes, note down the admin password.

3. At this point, you should be able to open a browser and navigate to the IP address or DNS name of your Wazuh VM. If everything is set up correctly, the Wazuh dashboard will load, giving you access to your SIEM environment.

For reference, here's what I used: https://wazuh02

4.      Log in using the username admin and the password that appeared in your terminal after completing the installation script. Once logged in, Wazuh will present a rich dashboard full of options to explore.

Setting Up Decoders and Rules for Ootbi Syslog Integration

We’ve created a GitHub repository with simple decoders and rules tailored for Object First’s Ootbi (Out-of-the-Box Immutability) syslog forwarding. You can download them using:

 https://github.com/object1st/wazuh-examples.git

No Ootbi yet? No problem. We’ll simulate syslog messages to demonstrate how Wazuh processes them.

File Placement

Instead of modifying the default local_decoder.xml and local_rules.xml, we recommend creating separate files for better organization, especially if you plan to manage multiple event types.

Copy the following files:

1. From the decoders folder:

• honeypot_application_decoders.xml
• ootbi_working_decoders.xml files

Place them in: /var/ossec/etc/decoders/

2. From the rules folder:

• honeypot_application_rules.xml
• ootbi_final_rules.xml files

Place them in: /var/ossec/etc/rules/

Configuring Wazuh to Receive Syslog Messages

1. Ensure Wazuh is listening for incoming syslog connections by adding the following section to 

/var/ossec/etc/ossec.conf file under </ossec_config> 

<remote> 

    <connection>syslog</connection> 

    <port>514</port> 

    <protocol>udp</protocol> 

    <allowed-ips>192.168.0.0/24</allowed-ips> 

    <allowed-ips>127.0.0.1</allowed-ips> 

</remote> 

2. Update allowed-ips to match your subnet.

3. Restart the Wazuh manager service:

systemctl restart wazuh-manager

4. Verify that the port is listening:

Ss -tunlp 

Sending Test Syslog Messages

You can send test messages to Wazuh using netcat:

echo '<14>Aug 26 19:00:00 ootbisiem OOTBI [ootbi_event@61062 Node="ootbisiem" Source="Disks" EventId="1039"] The RAID array "md0" is missing.' | nc -q0 localhost 514 

echo ‘<12>1 0001-01-01T00:00:00.000000+00:00 ootbi-node1 OOTBI - - [ootbi_event@61062 Node="ootbi-node1" NodeId="A410B7E9-FF68-4ADF-B570-A964C6F45D98" DateTime="01/01/0001 00:00:00 UTC" Source="S3" EventId="6207" ProductVersion="1.7.67.10970" EDataVersion="1"] '{}' smart entity is in '{}' unconfirmed state’ | nc  -q0 localhost 514 

Viewing Events in the Wazuh Dashboard

In the Wazuh dashboard, open the top-left menu and click on “Explore” then “Discover.”

You should now see the syslog messages you sent.

Importing the Ootbi Dashboard

1. Go to Dashboard Management from the top-left menu.

2. Under “Saved Objects,” click “Import.”

3. Upload the export.ndjson file from your desktop.

4. Once imported, click on “Explore” then “Dashboards.”

5. Subsequently, click on the “Ootbi Dashboard.” You’ll see the events you sent earlier displayed.

Testing the Honeypot Feature

Since Wazuh is functioning as a SIEM, this is a great opportunity to test Ootbi's new Honeypot feature.

1. To start, point your Ootbi syslog forwarding to the Wazuh installation.

2. Then, send a test message to confirm reception.

3. If your Honeypot is running on a static IP (mine, for example, is 192.168.0.44), scan it using Zenmap.

5. You should see events lighting up in the Ootbi dashboard and corresponding entries in your Wazuh SIEM dashboard.

6. Now let’s check our SIEM:

Final Thoughts on Wazuh Setup and Integration

This blog served as a hands-on introduction to Wazuh, an open-source SIEM and XDR platform designed to simplify security monitoring and threat detection. We explored its modular architecture—covering agents, the server, analysis engine, indexer, and dashboard—and walked through a single-node installation on Ubuntu using Wazuh’s streamlined setup script. From there, we demonstrated how to configure decoders and rules for syslog integration, simulate events, and visualize them in the Wazuh dashboard.

We also showcased how to import a custom dashboard and test Ootbi's Honeypot feature, giving readers a practical look at how Wazuh can be used in real-world scenarios. Whether you're new to SIEM tools or looking for a more security-focused alternative to traditional log processors, Wazuh offers a powerful and approachable solution. For further exploration, I’d highly recommend checking Wazuh’s official documentation.