Integrating with Wazuh OSSEC for HIDS – Part 1

integrate logzio wazuh ossec hids

This series of articles will explore the benefits and the technical instructions for integrating OSSEC with the ELK Stack for implementing advanced security and compliance protocols.

  • Part 1 of the series describes below how to setup the integration — installing the Wazuh OSSEC manager and agents along with shipping the triggered alerts into the ELK Stack or your own ELK deployment
  • Part 2 will focus on the visualization and analysis part and will explain how to build a comprehensive dashboard
  • Part 3 will be a bit more and will describe how to use our built-in alerting mechanism to get notified on alerts triggered by OSSEC

About OSSEC and Wazuh

OSSEC is a comprehensive platform used for monitoring and controlling systems. It contains a mixture of HIDS (host intrusion detection), logging and SIEM (security incident and event management) in one easy-to-deploy package.

OSSEC is used for implementing a variety of security and compliance protocols including SIEM and PCI-DSS and is a fully open source and supported by both leading security vendors and a growing community of contributors. Wazuh is a fork of OSSEC that adds additional management features and extended logging capabilities as well as built-in integration with the ELK Stack and RESTful API.

OSSEC is based on both log message decoders and sets of rules that trigger alerts. This signature-based approach is used to detect attacks, intrusions, configuration or application errors, system anomalies, and so forth.

Integration with ELK makes OSSEC a complete solution — it enables centralized analysis and visualization of the data shipped by the various agents in your system reporting to your main OSSEC manager and also allows you to retain the data for a longer period of time.

Alerting is another element ELK can add to OSSEC. If you are using the ELK Stack, alerting is included out-of-the-box so as soon as an OSSEC alert is fired, and you can get alerted via your preferred channel. If you are using your own ELK deployment, you will need to add and pay for X-Pack to use Watcher.

Installing ELK

Installing ELK is out of the scope for this series of articles. (You can see our complete guide here.) This means that to follow through on the steps outlined here, you either need to have your own running ELK deployment or a account.

If you are a Docker user and do not have ELK set up, check out this OSSEC-ELK container. It will help you set up the entire solution, albeit with an older version of ELK.

Installing Wazuh

Wazuh’s architecture consists of two main components — a manager and agents.

The manager (also knows as “server”) is the main focal point of a Wazuh deployment — it stores the main configuration files, rules, logs, and events. The agent is a smaller program that you install on the system you want to monitor. The agent collects the information and forwards it to the manager.

You can read up on Wazuh architecture here.

Installing the manager

To start with, you first need to set up the correct compilation environment by installing some development tools and compilers.

Since I’m using Ubuntu 16.04, the command for this is:

sudo apt-get update
sudo apt-get install curl apt-transport-https lsb-release

Next, we are going to install the GPG key and add the repository:

sudo su
curl -s | apt-key add -
echo "deb main" | tee -a /etc/apt/sources.list.d/wazuh.list

Update the repository and install the Wazuh server with:

apt-get update
apt-get install wazuh-manager

Your Wazuh manager is installed and ready. You can verify all is working as expected with the following command:

systemctl status wazuh-manager

You should see a similar output to this:

● wazuh-manager.service - Wazuh manager
   Loaded: loaded (/etc/systemd/system/wazuh-manager.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-04-08 07:55:40 UTC; 1min 5s ago
   CGroup: /system.slice/wazuh-manager.service
           ├─22264 /var/ossec/bin/ossec-authd
           ├─22268 /var/ossec/bin/wazuh-db
           ├─22285 /var/ossec/bin/ossec-execd
           ├─22292 /var/ossec/bin/ossec-analysisd
           ├─22297 /var/ossec/bin/ossec-syscheckd
           ├─22303 /var/ossec/bin/ossec-remoted
           ├─22326 /var/ossec/bin/ossec-monitord
           ├─22328 /var/ossec/bin/ossec-logcollector
           └─22331 /var/ossec/bin/wazuh-modulesd

Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started wazuh-db...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started ossec-execd...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started ossec-analysisd...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started ossec-syscheckd...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started ossec-remoted...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started ossec-logcollector...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started ossec-monitord...
Apr 08 07:55:38 ip-172-31-56-107 env[22235]: Started wazuh-modulesd...
Apr 08 07:55:40 ip-172-31-56-107 env[22235]: Completed.
Apr 08 07:55:40 ip-172-31-56-107 systemd[1]: Started Wazuh manager.

Installing an agent

Before you set up Wazuh on the system you wish to monitor, you need to retrieve an agent key from the manager.

Retrieving the agent key

So, on the Wazuh manager, run:

sudo /var/ossec/bin/manage_agents

When asked, enter “A” to add an agent, and then enter a name, IP address, and ID for the agent. Try and keep in mind that you will most likely add additional agents, so make the naming logical and clear as possible.


ID: 001
Name: php-server
IP address: xx.x.x.x

Once added, you will be taken to the manage_agents main menu again, where this time you will enter “E”.

From the list of displayed agents (you should have only one), enter the ID for the agent, and an agent key is displayed. Copy it for the next step.

Configuring a new agent

Install Wazuh on the system you wish to monitor using the steps outlined above, only this time use this install command to install the agent:

apt-get install wazuh-agent

In the agent configuration file (/var/ossec/etc/ossec.conf) make sure you define the server IP of the OSSEC manager:


Then, run:

sudo /var/ossec/bin/manage_agents

Enter “I”, and add the agent key you retrieved earlier.

Confirm the addition of the agent key and then restart the agent with:

sudo /var/ossec/bin/ossec-control restart

Shipping Into ELK

Alerts triggered by the OSSEC agents are recorded in JSON format in the manager (/var/ossec/logs/alerts/…).

To ship the alerts into ELK, you can use the Logstash file input. A detailed Logstash configuration for receiving an input of alerts from OSSEC is detailed here. (Note: Since version 5, Logstash configurations have changed somewhat, so the Logstash configuration used in that example might not work properly.)

A more lightweight option is to use Filebeat.

Installing Filebeat

Again, I’m using Ubuntu 16.04, so to install Filebeat on the master server, I used:

curl -L -O
sudo dpkg -i filebeat-6.3.0-amd64.deb

Configuring Filebeat

Below are two Filebeat configurations — one for shipping into, the other for shipping into your own ELK deployment.

First, download an SSL certificate and copy it to the correct location:


sudo mkdir -p /etc/pki/tls/certs
sudo cp COMODORSADomainValidationSecureServerCA.crt /etc/pki/tls/certs/

Then, use the Filebeat configuration wizard to configure the Filebeat YAML file.

Here is an example of what a configuration would look like:

            - /var/ossec/logs/alerts/alerts.json
            logzio_codec: json
            token: JiWdcPIpTRTJGdfdgMwQWGVsXtMApZofv
         fields_under_root: true
         ignore_older: 3h
         document_type: ossec
   registry_file: /var/lib/filebeat/registry

   hosts: [""]
      certificate_authorities: ['/etc/pki/tls/certs/COMODORSADomainValidationSecureServerCA.crt']

Copy this configuration to the Filebeat configuration file (/etc/filebeat/filebeat.yml) and start Filebeat with:

sudo /etc/init.d/filebeat start

Within seconds, you should be seeing OSSEC alerts in

ossec alerts

Open source ELK

If you have your own ELK deployment, the Filebeat configuration will look somewhat different. You do not need the token, for example, and you will not necessarily want to use SSL to encrypt the data.

So, define the prospector and the correct output — either a Logstash or Elasticsearch instance.

An Elasticsearch example:

            - /var/ossec/logs/alerts/alerts.json
         document_type: ossec
   registry_file: /var/lib/filebeat/registry

      hosts: [""]

Copy the configuration to the Filebeat configuration file (/etc/filebeat/filebeat.yml) and start Filebeat with:

sudo /etc/init.d/filebeat start

OSSEC’s architecture makes it extremely simple to get your HIDS environment set up in a matter of minutes. If you have ELK already installed, shipping the alerts is also pretty straightforward.


Extra work will most likely be needed if you want to massage the logs and enhance them with Logstash (if you are using, your OSSEC alerts will be parsed automatically). The next part of the series will describe what to do with the data once shipped.

Observability at scale, powered by open source


2022 Gartner® Magic Quadrant for Application Performance Monitoring and Observability
Forrester Observability Snapshot.

Centralize Server Monitoring With

See Plans