Built.io joins Software AG! Read all about the news.

Built.io Blog

How To implement A Host-Based Intrusion Detection System (HIDS) In The Cloud


This article originally appeared on DZone.

Ensuring system security is as important as ensuring overall application security. A Host-based Intrusion Detection Systems (HIDS) provides the ability to identify, detect, and notify any unanticipated system changes that might impact the security of the system. HIDS is a powerful tool to maintain security standards implemented across IT systems. The Open Source HIDS SECurity (OSSEC) tool is one of the more popular HIDS options around.

OSSEC Architecture

The OSSEC tool can be implemented in multiple ways and largely depends on your infrastructure, that is, whether you have a fixed number of servers, or you have infrastructure that is frequently scaled – up and down.

Traditional Server-Agent Model

The traditional server-agent model can be followed to monitor the servers with a lightweight agent installed on them, where all agents report to the central OSSEC manager (Server) to analyze the events and to generate event notifications as appropriate.


This model works quite well for small and large, fixed setups. However, there are trade-offs:

  • Additional server management overhead: You need to manage the OSSEC server itself, along with its agents.
  • Adding or removing agents overhead: If you have a dynamic environment, which involves frequent scaling of servers, then a custom solution is needed to automatically register and de-register the agents in the OSSEC server, when scaling occurs.
  • Limited high availability of OSSEC server: There is an open feature request for making the OSSEC server highly available. Until this has been addressed, your best option is to keep a standby server with the configuration and data volumes replicated in realtime.

Local Model

The OSSEC can also be installed in a local model, where each server monitors itself. The local OSSEC installation eliminates maintenance overhead for the OSSEC server. In addition, each server reports incidents and unauthorized events.

Below you will find the steps required to install and incorporate the local model OSSEC into dynamic infrastructure.

OSSEC Installation

First, you need to install the required packages:

apt-get update
apt-get install build-essential inotify-tools

The build-essential package will install the required packages for the compilation steps involved in OSSEC installation. The inotify-tools package is used in real-time notifications.

Download and extract the OSSEC source code:

wget -O ossec-hids.tar.gz https://github.com/ossec/ossec-hids/archive/2.9rc4.tar.gz
tar -xf ossec-hids.tar.gz

While downloading, verify that it is a signed commit in the OSSEC repo. You might have noticed that we downloaded the RC build for OSSEC, instead of the stable version. The reason for this is that the recent “stable” OSSEC version (v2.8.3) was released in Oct. 2015 and is considered a bit outdated now. Especially for today’s agile environments, you want to start with the HIDS setup that includes all the latest features and fixes available.

Go to the OSSEC directory and copy the following variables into preloaded-vars.conf:

cd ossec-hids-2.9rc4/etc/

In preloaded-vars.conf:

USER_LANGUAGE="en"     # For english

For NS1, and NS2, specify the IP addresses for your nameservers. This preloaded variables help in carrying out silent OSSEC installation.

Now, install the OSSEC:

cd ossec-hids-2.9rc4/
make && make install

After the OSSEC installation completes successfully, start it with the following command:

/var/ossec/bin/ossec-control start

Syscheck Configuration

The OSSEC main configuration file is /var/ossec/etc/ossec.conf where you can update the section to monitor various files for unauthorized edits and get notified about them in realtime.

Make a backup of the main configuration file:

cp /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf-backup

Now you can go ahead with your configuration changes:

This section is used to add or remove directories from OSSEC monitoring. It also has options to enable alerting for realtime changes.

<directories report_changes=”yes” realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/bin,/sbin</directories>

The report_changes attribute reports changes (limited to text files for now) and realtime attribute generates notifications in realtime.

The default frequency for full scans is 6 hours, i.e. 21,600 seconds but you can change this to 1 hour or 24 hours – the scan itself is performed slowly to avoid any adverse impact on CPU/memory.

By default, this option is set to “no”. You can set this to “yes”, and get notified when new files are created. However, this option only works during full scans that are performed at the frequency specified by you.

Another attribute that is set to “no” by default. This option is kept disabled to avoid sending out unnecessary, large numbers of notifications in case of misconfiguration. You can enable this option to receive a notification for all file changes as they happen. If disabled, then the OSSEC automatically ignores file changes after a 3rd change.

Rule Configuration

The OSSEC does not send notifications for new files by default. In order to enable this, you need to overwrite the corresponding rule in local_rules.xml.

Make a backup of local_rules.xml and add the following configuration block at the end (it should be present within the ... section):

cp /var/ossec/rules/local_rules.xml /var/ossec/rules/local_rules.xml-backup
<rule id="554" level="8" overwrite="yes">
  <description>File added to the system.</description>

JSON Output Configuration

The biggest advantage of selecting RC build over a stable version is that it supports the JSON output format for alerts generated. You can enable JSON output as follows:


The alert file will be stored at the following location:


This file can be sent either to a custom Elasticsearch server, or any managed centralised logging solution, such as Loggly. If you are using a managed centralised logging solution, you will also have the ability to generate a custom email notification on specific changes, or a specific set of servers. This approach significantly reduces non-essential email traffic.

Slack Notification Configuration

Add the following configuration in ossec.conf to enable Slack notifications:

        <expect></expect> <!-- no expect args required -->

By setting the attribute to your desired value, you can filter out notifications and continue to receive only high priority incidents on Slack. Also, you need to update ossec-slack.sh located at /var/ossec/active-response/bin with the following parameters:


The SLACKUSER is a custom name you would like to give to OSSEC alert notifier.

The CHANNEL specifies the name of a channel (public) or a group (private). If it is a group, then directly mention its name, e.g. ossec-alerts. If it is a channel, then you will need to include a hashtag (#) in the name, e.g. #ossec-alerts.

The SITE will specify a URL to the incoming Slack webhook. You can configure an incoming Slack webhook here.

To have the configurations take effect, restart OSSEC with the following command:

/var/ossec/bin/ossec-control restart

Proposed Architecture

The proposed architecture for OSSEC with local model utilizes the tools that are generally available nowadays in agile environments. This approach also gives an ability for admins to receive selective notifications through Slack or email, and yet keep track of all events in a centralised place, which can be accessed with greater ease than perusing email. The configuration changes to OSSEC can be managed through deployment tools such as Chef or Puppet. The architecture then looks like this:


This proposed architecture for OSSEC leverages the utilities that many enterprises already have or can easily deploy today, including a centralised logging solution and a company-wide communications platform such as Slack or Cisco Spark. The implementation described focuses on the distributed architecture, often the norm as applications grow. By deploying this solution to a large number of servers, OSSEC admins can receive important event notifications in an efficient, targeted manner without being inundated with irrelevant messages.

Key takeaways:

  • The proposed architecture for OSSEC leverages the utilities that many enterprises either already have in use or can easily be deployed today. That includes a centralized logging solution and a company-wide communications platform such as Cisco Spark, Slack or HipChat. All the modifications and updates to the OSSEC software itself can be handled through existing widely used configuration management solutions, such as Chef, Puppet.
  • The proposed implementation described in the article focuses on distributed architecture, often the norm as applications grow. It is essential to consider this point when the component (here, OSSEC) will be an integral part of every application server.
  • By deploying this solution to a large number of servers, OSSEC admins can receive important event notifications in an efficient, targeted manner without being inundated with irrelevant messages. This way, the real incidents can be filtered out from pseudo ones. Also, as the incident information becomes available, the OSSEC admins can troubleshoot the relevant issues quickly.

Term Definitions for the Guide Glossary:

  • Host-based Intrusion Detection System (HIDS) - An Host-based Intrusion Detection System is a software application that monitors and analyzes a computer system for any unauthorised activity.
  • Open Source HIDS SECurity (OSSEC) - OSSEC is an Open Source Host-based Intrusion Detection System. It performs several functions including log analysis, integrity checking, rootkit detection, realtime alerting etc.
  • Dynamic or Agile Environment - The dynamic or agile environment is where servers are frequently scaled up or down.
  • Centralised Logging Solution - The centralised logging solution is either custom managed Elasticsearch-Logstash-Kibana (ELK) stack or a Software-as-a-Service (SaaS) solution. Having a centralised logging solution enables programmers or admins to easily view, compare and correlate logs from different servers at the same place.

Popular Posts

Subscribe to our blog