WAZUH

The Wazuh architecture is based on agents , running on the monitored endpoints, that forward security data to a

central server . Agentless devices such as firewalls, switches, routers, and access points are supported and can

actively submit log data via Syslog, SSH, or using their API . The central server decodes and analyzes the incoming

information and passes the results along to the Wazuh indexer for indexing and storage.The Wazuh indexer cluster is a

collection of one or more nodes that communicate with each other to perform read and write operations on indices.

Small Wazuh deployments, which do not require processing large amounts of data, can easily be handled by a single-

node cluster

The Wazuh agent continuously sends events to the Wazuh server for analysis and threat detection. To start
shipping this data, the agent establishes a connection with the server service for agent connection, which listens on port

1514 by default (this is configurable ). The Wazuh server then decodes and rule-checks the received events, utilizing

the analysis engine. Events that trip a rule are augmented with alert data such as rule ID and rule name. Events can be

spooled to one or both of the following files, depending on whether or not a rule is tripped :

 The file /var/ossec/logs/archives/archives.json contains all events whether they tripped a rule or not.

 The file /var/ossec/logs/alerts/alerts.json contains only events that tripped a rule with high enough

priority (the threshold is configurable).

The Wazuh messages protocol uses AES encryption by default, with 128 bits per block and 256-bit keys. Blowfish
encryption is optional.

Wazuh server - Wazuh indexer communication

The Wazuh server uses Filebeat to send alert and event data to the Wazuh indexer, using TLS encryption. Filebeat reads the
Wazuh server output data and sends it to the Wazuh indexer (by default listening on port 9200/TCP). Once the data is
indexed by the Wazuh indexer, the Wazuh dashboard is used to mine and visualize the information.

The Wazuh dashboard queries the Wazuh RESTful API (by default listening on port 55000/TCP on the Wazuh server ) to
display configuration and status-related information of the Wazuh server and agents . It can also modify agents or
server configuration settings through API calls. This communication is encrypted with TLS and authenticated with a

username and password.

 Component Port Protocol Purpose

1514 TCP (default) Agent connection service

1514 UDP (optional) Agent connection service (disabled by default)

1515 TCP Agent enrollment service

Wazuh server 1516 TCP Wazuh cluster daemon

514 UDP (default) Wazuh Syslog collector (disabled by default)

514 TCP (optional) Wazuh Syslog collector (disabled by default)

55000 TCP Wazuh server RESTful API

9200 TCP Wazuh indexer RESTful API

Wazuh indexer
9300-9400 TCP Wazuh indexer cluster communication

Wazuh dashboard 443 TCP Wazuh web user interface

Both alerts and non-alert events are stored in files on the Wazuh server, in addition to being sent to the Wazuh indexer.
These files can be written in JSON format ( .json ), or plain text format ( .log ). These files are daily compressed and

signed using MD5, SHA1, and SHA256 checksums. The directory and filename structure is as follows:

root@wazuh-manager:/var/ossec/logs/archives/2022/Jan# ls -l

Log data analysis

Wazuh collects, analyzes, and stores logs from endpoints, network devices, and applications. The Wazuh agent, running on
a monitored endpoint collects and forwards system and application logs to the Wazuh server for analysis. Additionally, you
can send log messages to the Wazuh server via syslog or third-party API integrations.

Wazuh can collect syslog, auditd, application logs, and others from Linux endpoints.

Wazuh collects logs on Windows endpoints using the Windows event channel and Windows event log format. By default,
the Wazuh agent monitors the System, Application, and Security Windows event channels on Windows endpoints. The
Wazuh agent offers the flexibility to configure and monitor other Windows event channels .
Syslog events: Wazuh gathers logs from syslog-enabled devices, encompassing a wide array of sources including
Linux/Unix systems and network devices that do not support agent installation. The image below shows an alert triggered
when a new user is created on the Linux endpoint and the log is forwarded to the Wazuh server via rsyslog.

Agentless monitoring: The Wazuh agentless monitoring module monitors endpoints that don't support agent installation. It
requires an SSH connection between the endpoint and the Wazuh server. The Wazuh agentless monitoring module
monitors files, directories, or configurations and runs commands on the endpoint. The image below is an alert from an
agentless device on the Wazuh dashboard.

Custom logs: You can configure Wazuh to collect and parse logs from several applications and third-party security tools
like VirusTotal , Windows Defender , and ClamAV. The image below shows an alert of a log from VirusTotal
processed by the Wazuh server.

How it works

Wazuh uses the Logcollector module to collect logs from monitored endpoints, applications, and network devices. The

Wazuh server then analyzes the collected logs in real-time using decoders and rules. Wazuh extracts relevant

information from the logs and maps them to appropriate fields using decoders. The Analysisd module in the Wazuh
server evaluates the decoded logs against rules and records all alerts
in /var/ossec/logs/alerts/alerts.log and /var/ossec/logs/alerts/alerts.json files.

In addition to alert logs, Wazuh stores all collected logs in dedicated archive log files,
specifically /var/ossec/logs/archives/archives.log and /var/ossec/logs/archives/archives.json . These archive

log files comprehensively capture all logs, including those that do not trigger any alerts.

Rules and decoders

Wazuh rules and decoders are core components in log data analysis and threat detection and response. Wazuh

provides a powerful platform for log data analysis, allowing organizations to enhance their security posture by promptly

detecting and responding to potential security threats.

Wazuh decoders are responsible for parsing and normalizing log data collected from various sources. Decoders are

essential for converting the raw log data in several formats into a unified and structured format that Wazuh can process

effectively. Wazuh has pre-built decoders for common log formats such as syslog, Windows event channel , macOS ULS,

and more. Additionally, Wazuh allows you to define custom decoders for parsing logs from specific applications or

devices with unique log formats. By using decoders, Wazuh can efficiently interpret log data and extract relevant

information, such as timestamps, log levels, source IP addresses, user names, and more.

Wazuh ruleset detects security events and anomalies in log data. These rules are written in a specific format
and they trigger alerts when certain conditions are met. The rules are defined based on certain criteria like log fields,

values, or patterns to match specific log entries that may indicate security threats. Wazuh provides a wide range of pre-built

rules covering common security use cases.

Log data indexing and storage

The Wazuh indexer is critical in log analysis as it stores and indexes alerts generated by the Wazuh server. These alerts
are stored as JSON documents.

The Wazuh indexer guarantees redundancy by storing the JSON documents across several containers called shards and
distributing the shards across multiple nodes. This implementation prevents downtime when hardware failures or cyber-
attacks occur and increases query capacity as nodes are added to a cluster.

Wazuh uses four indices to store several event types:

 wazuh-alerts stores alerts generated by the Wazuh server when an event triggers a rule with high enough

priority.
  wazuh-archives index stores all events received from the Wazuh server regardless of whether they trigger an
alert. The Wazuh archives use this index to enable log retention and querying capabilities that offer
deeper insight into events happening within monitored endpoints. Wazuh archives are disabled by default

because of the huge storage requirements needed to store all the logs

 wazuh-monitoring index stores data about the state of Wazuh agents over a period of time. The state of the

agent could be Active , Disconnected , or Never connected . This information is very useful in tracking Wazuh

agents that are not reporting to the dashboard for several reasons that need investigation.

 wazuh-statistics index stores performance data related to the Wazuh server. This information is critical to

ensuring the Wazuh server performs optimally with the available computing resources

Monitoring basic log files

You can configure the Wazuh agent ossec.conf file on Windows, Linux, and macOS endpoints to monitor basic log files.

For example, perform the following steps to monitor the file file.log .

1. Add the following settings in between the <ossec_config> tags of the Wazuh agent configuration file:

o Linux: /var/ossec/etc/ossec.conf

o Windows: C:\Program Files (x86)\ossec-agent\ossec.conf

2.
<localfile>
<location>/<FILE_PATH>/file.log</location>
<log_format>syslog</log_format>
</localfile>
Where:
location : is the full path of the monitored file.

log_format : represents the format of the log. Refer to the log format documentation to learn more about the
different types of log_format you can configure.

Restart the Wazuh agent with administrator privileges to apply the configuration change:

Configuring syslog on the Wazuh serverPermalink to

this headline

The Wazuh server can collect logs via syslog from endpoints such as firewalls, switches, routers, and other devices that

don’t support the installation of Wazuh agents. Perform the following steps on the Wazuh server to receive syslog

messages on a specific port.

1. Add the following configuration in between the <ossec_config> tags of the Wazuh

server /var/ossec/etc/ossec.conf file to listen for syslog messages on TCP port 514:

2. <remote>
3. <connection>syslog</connection>
4. <port>514</port>
5. <protocol>tcp</protocol>
6. <allowed-ips>192.168.2.15/24</allowed-ips>
7. <local_ip>192.168.2.10</local_ip>
 8. </remote>

Where:

o <connection> specifies the type of connection to accept. This value can either be secure or syslog.

o <port> is the port used to listen for incoming syslog messages from endpoints. We use port 514 in

the example above.

o <protocol> is the protocol used to listen for incoming syslog messages from endpoints. The allowed

values are either tcp or udp .

o <allowed-ips> is the IP address or network range of the endpoints forwarding events to the Wazuh

server. In the example above, we use 192.168.2.15/24.

o <local_ip> is the IP address of the Wazuh server listening for incoming log messages. In the

example above, we use 192.168.2.10.

Refer to remote - local configuration documentation for more information on remote syslog options.

9. Restart the Wazuh manager to apply the changes:

# systemctl restart wazuh-manager

Windows event channel

Event channel is a log format that supports Windows Vista and recent versions. It captures Applications and Services

logs, as well as basic Windows logs, including Application, Security, and System logs. This log format also supports the

use of queries to monitor specific Windows events. By default, the Wazuh agent monitors the System, Application, and

Security Windows event channels. You can configure the Wazuh agent to monitor other Windows event channels of

interest.

Monitoring the Windows event channel with Wazuh

To monitor specific Windows event channels using the Wazuh agent, simply include the channel name in
the location field and set the log format as eventchannel within the localfile block in the C:\Program Files (x86)\

ossec-agent\ossec.conf file. For example, perform the following steps to monitor the Microsoft-Windows-

PrintService/Operational channel:

1. Add the following configuration in between the <ossec_config> tags of the Wazuh agent C:\

Program Files (x86)\ossec-agent\ossec.conf file:

2. <localfile>
3. <location>Microsoft-Windows-PrintService/Operational</location>
4. <log_format>eventchannel</log_format>
5. </localfile>

6. Restart the Wazuh agent via PowerShell with administrator privileges to apply the configuration change:

> Restart-Service -Name wazuh

Monitoring specific events from Windows event channelPermalink to this headline

You can configure Wazuh agent to collect specific Windows events from the Windows event channel using queries. For
example, the following configuration collects Windows events from the System channel whose levels are equal to or less

than 3 (warning):

<localfile>
<location>System</location>
<log_format>eventchannel</log_format>
<query>
\<QueryList\>
\<Query Id="0" Path="System"\>
\<Select Path="System"\>*[System[(Level&lt;=3)]]\</Select\>
\</Query\>
\</QueryList\>
</query>
</localfile>

Wazuh uses the following configuration to collect Windows events whose event ID is 7040 :

<localfile>
<location>System</location>
<log_format>eventchannel</log_format>
<query>Event/System[EventID=7040]</query>
</localfile>

Windows event channel ruleset

Wazuh provides a comprehensive ruleset designed for different Windows event channels. The rules are categorized

based on the event channels to which they belong. This classification enables Wazuh to efficiently maintain the ruleset.

Additionally, users can add custom rules specific to their desired event channel. The Windows event channel ruleset has

the following characteristics:

 By default, the monitored event channels are System, Security, and Application.

 Each event channel has one or more rule files specific to it. For example, you can find the rules specific to

the System event channel in the /var/ossec/ruleset/rules/0590-win-system_rules.xml file.

 A base file /var/ossec/ruleset/rules/0575-win-base_rules.xml includes every parent rule for the specific

event channels the Wazuh agent monitors.

 Every rule file has a specific rule ID range. Wazuh has reserved 100 rule IDs for the base rules and 500 rule

IDs have been reserved for each of the other rule files.

 A generic rule file /var/ossec/ruleset/rules/0620-win-generic_rules.xml contains rules that cannot be

easily classified into specific event channels.

..

Windows event log

The Windows event log format is compatible with all Windows versions and monitors all logs except for particular

Applications and Services logs. This format allows monitoring of logs such as Application, System, and Security. By
default, the Wazuh agent is configured to monitor only event channels, but you can configure it to also utilize the

Windows event log format.

Monitoring the Windows event log with Wazuh

You can configure Wazuh agent to monitor Windows event logs by placing the name of the event log in
the location field and eventlog as the log format within the localfile block in the ossec.conf file.

For example, perform the following steps to monitor Application logs from Windows event log:

1. Add the following configuration in between the <ossec_config> tags of the Wazuh agent C:\

Program Files (x86)\ossec-agent\ossec.conf file:

2. <localfile>
3. <location>Application</location>
4. <log_format>eventlog</log_format>
</localfile>

Restart the Wazuh agent via PowerShell with administrator privileges to apply the configuration change:

> Restart-Service -Name wazuh

Linux

The Wazuh agent collects and forwards Linux events to the Wazuh server for analysis. You can also configure a Linux

endpoint to forward events via syslog directly to the Wazuh server for analysis. The Wazuh server has out-of-the-box

decoders and rules to extract and analyze relevant fields from Linux events. You can create custom decoders and rules

to parse and analyze unsupported Linux events.

Monitoring Linux endpoint using rsyslog

Perform the following steps to configure a Linux endpoint to forward events using rsyslog to the Wazuh server for

analysis:

1. Add the following configuration to the /etc/rsyslog.conf file on the Linux endpoint:
2. *.info@@<WAZUH_SERVER_IP_ADDRESS>:514

Note

@@ indicates a TCP connection, while @ indicates a UDP connection.

Where: <WAZUH_SERVER_IP_ADDRESS> represents the IP address of the Wazuh server.

systemctl restart rsyslog

1. Add the configuration below in between the <ossec_config> tags of the /var/ossec/etc/ossec.conf file on

the Wazuh server. This configuration allows the Wazuh server to listen for remote syslog messages from the

Linux endpoint:

2. <remote>
3. <connection>syslog</connection>
4. <port>514</port>
5. <protocol>tcp</protocol>
6. <allowed-ips>192.168.2.15</allowed-ips>
7. <local_ip>192.168.2.5</local_ip>
8. </remote>

Where:

o <connection> specifies the type of connection to accept. This value can either be secure or syslog .

o <port> is the port used to listen for incoming events from the Linux endpoint. The default port for

syslog is 514.

o <protocol> is the protocol used to listen for incoming events from the Linux endpoint. This value is

either tcp or udp .

o <allowed-ips> is the IP address of the Linux endpoint forwarding events to the Wazuh server.

o <local_ip> is the IP address of the Wazuh server listening for the incoming Linux events.

9. Restart the Wazuh manager to apply the changes: # systemctl restart wazuh-manager