Leverage OSSEC as a Syslog Client or Server

Open Source Security (OSSEC) is a Host-Based Intrusion Detection System (HIDS) that allows you to quickly collect, analyze and correlate events across your entire infrastructure. It can be deployed on any endpoint, from network based tools (e.g., routers, switches, etc..) to end points (e.g., servers, desktop, laptops, etc..).

System Logging protocol, (Syslogs), is a mechanism used to collect, package and send data from a client machine to a server machine. This server machine is typically a Syslog Server.

While helping a customer think through their logging solutions and requirements, we realized that many OSSEC users fail to realize that OSSEC has the ability to function as both a Syslog client and Syslog server.

This is a technical guide that explains when a deployment might require this type of configuration, and how to extend your OSSEC deployment to fully capitalize on the platforms capabilities.

Accounting for Busy Nodes / Networks

Leveraging OSSEC as a syslog client allows you to divide activity across different networks, while still leveraging the power of OSSEC.

Imagine a world where you have a different networks (Zone 1 and Zone 2). Zone 1 is extremely busy, generates in excess of 10 million requests a day. Zone 2 is quieter, generating a few hundred requests a day. Maybe Zone 1 is your web environment, leveraging complex configurations that account for load balancers, databases, web servers, etc.. Zone 2, however, is a cluster of desktop / notebook machines.

The task is to collect and aggregate all the data into a centralized manager so that you can perform your duties.

One option might be to deploy a normal Agent / Server deployment that would have all events consumed into one manager. Another, less used option, would be to deploy two Agent / Server configurations, where one Manager is subservient to the Master.

There are a couple different benefits of this deployment:

• Easier management of agents (allows you to group devices and data);
• A network / device that is yielding excessive logs, this configuration would pre-parse locally to parse data that matters to the master;
• Centralized control of all networks (assume you have multiple networks you’re managing).

This configuration allows you to isolate, process, and parse the information that makes sense.

In the example above, Zone 1 could have its own Manager that collects, analyzes and correlates activity across the network, and it can be done independent to what is happening on Zone 2. The manager in Zone 1 can then send the processed data to the Master manager. This ensure that you’re accurately collecting, and storing the event data that matters, while be responsible and cognizant of the potential load on your network.

This configuration is extremely powerful, and helps you be more efficient in the management of your event data. Below I’ll share some tips on how to make this work.

OSSEC: Syslog Client and Manager

Any OSSEC deployment (e.g., Agent, Manager, Hybrid) can function as a Syslog client, but only the manager can function as a Syslog manager. This is an important distinction.

Convert OSSEC Install Into a Syslog Client

First, you want to enable syslog client on your OSSEC install:

/var/ossec/bin/ossec-control enable client-syslog

This will enable the syslog client in OSSEC. In the example above, we did this on the OSSEC manager.

Once enabled, update the OSSEC configuration file to make sure it knows where to send the data:

vim /var/ossec/etc/ossec.conf 

Add a new section in the configuration file for syslog.

<syslog_output>
  <level>6</level>
  <server>[public IP of manager]</server>
  <port>1515</port>
</syslog_output>

This is going to allow you to take control of what gets sent to the Master server. Above I use three key options: level, server, and port.

• level -> defines what alert level should be sent to the manager, extremely powerful as it allows you to reduce the noise being sent to your master. In the example above, I select to only send alerts that are level 6 or higher.
• server -> is the public IP of your Master.
• port -> The port you want to send the information too. The default port for syslog with OSSEC is 1515.

What’s really unique about this is that it is going to allow you to leverage your OSSEC alerts, which have already processed and built intelligence from the events, and send that to your master in tact.

Last step is to reboot OSSEC on this end poing:

/var/ossec/bin/ossec-control restart

To verify the data is being sent, do a simple TCPDUMP and track the outbound requests:

tcpdump -i eth0  -nnn -s 0 -A udp port 1515

OSSEC Manager as a Syslog Manager

On the Master manager, configure it to accept the new syslog files.

To configure the Manager as the Syslog manager simply enable syslog connections on the manager. You do this by editing the OSSEC configuration file:

vim /var/ossec/etc/ossec.conf 

Create a new remote entry using the following options:

<remote>
  <connection>syslog</connection>
  <port>1515</port>
  <allowed-ips>[public IP of syslog agent]</allowed-ips>
</remote>

This is going to allow the manager to consume the events from your syslog client appropriately. In this instance, another OSSEC manager. Above, I used three options:

• connection -> Tells OSSEC to expect syslog data.
• port -> The port to expect the events. The default port for syslog with OSSEC is 1515.
• allowed-ips -> Identifies where the events are coming from, needs to be the public IP.

You can confirm things are functioning by running a similar TCPDUMP on the manager, or you can parse the the ossec.log file for details. Here is one way:

cat /var/ossec/logs/ossec.log | grep syslog

You should see something similar to the following:

When it’s all done, you will see an entry in your agent control for the new syslog connection.

/var/ossec/bin/agent_control -lc

It will be displayed like this:

List of syslog-based sources: ID: na, Name: [hostname]->[public IP], IP: [public IP], Syslog-based Active

OSSEC is one of the most powerful open-source solutions available to any organization to help them with their collection, aggregation and analysis of event data. What it lacks in aesthetics, it easily makes up for in its economics, functionality and relatively low footprint. .

If you’re managing your own OSSEC deployment, need help thinking through its deployment, or need help sustaining your existing deployment ColdPath is here to help you. Contact us via our Contact Page, or send us an email at info@coldpath.net.