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 Logz.io 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 Logz.io-specific 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 Logz.io 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 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 Logz.io 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.
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 https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - echo "deb https://packages.wazuh.com/3.x/apt/stable 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: Started wazuh-db... Apr 08 07:55:38 ip-172-31-56-107 env: Started ossec-execd... Apr 08 07:55:38 ip-172-31-56-107 env: Started ossec-analysisd... Apr 08 07:55:38 ip-172-31-56-107 env: Started ossec-syscheckd... Apr 08 07:55:38 ip-172-31-56-107 env: Started ossec-remoted... Apr 08 07:55:38 ip-172-31-56-107 env: Started ossec-logcollector... Apr 08 07:55:38 ip-172-31-56-107 env: Started ossec-monitord... Apr 08 07:55:38 ip-172-31-56-107 env: Started wazuh-modulesd... Apr 08 07:55:40 ip-172-31-56-107 env: Completed. Apr 08 07:55:40 ip-172-31-56-107 systemd: 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:
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:
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.
Again, I’m using Ubuntu 16.04, so to install Filebeat on the master server, I used:
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.3.0-amd64.deb sudo dpkg -i filebeat-6.3.0-amd64.deb
Below are two Filebeat configurations — one for shipping into Logz.io, the other for shipping into your own ELK deployment.
First, download an SSL certificate and copy it to the correct location:
wget https://raw.githubusercontent.com/logzio/public-certificates/master/COMODORSADomainValidationSecureServerCA.crt 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:
filebeat: prospectors: - paths: - /var/ossec/logs/alerts/alerts.json fields: logzio_codec: json token: JiWdcPIpTRTJGdfdgMwQWGVsXtMApZofv fields_under_root: true ignore_older: 3h document_type: ossec registry_file: /var/lib/filebeat/registry output: logstash: hosts: ["listener.logz.io:5015"] ssl: 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 Logz.io.
Open source ELK
If you have your own ELK deployment, the Filebeat configuration will look somewhat different. You do not need the Logz.io 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:
filebeat: prospectors: - paths: - /var/ossec/logs/alerts/alerts.json document_type: ossec registry_file: /var/lib/filebeat/registry output: logstash: hosts: ["127.0.0.1:9200"]
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 Logz.io, your OSSEC alerts will be parsed automatically). The next part of the series will describe what to do with the data once shipped.