RootUsers

Lately I’ve been working a lot with OSSEC, which is an open source host-based intrusion detection system (HIDS). This has primarily involved installing Linux or Windows based agents onto servers and configuring them to point to the OSSEC server, a process which is straight forward and fairly well documented. Unfortunately you aren’t going to be able to run an agent on some devices, such as those provided by Cisco or Juniper, so we instead have to look towards agentless or syslog monitoring.

Configuring the device

I wanted to log events such as successful or failed logins to various Cisco and Juniper firewalls with OSSEC, this was done by setting the OSSEC server as a Syslog server on the device, how this is done will depend on your particular device and OS version, you can check if your device is supported here.

For example on my Juniper device I have set the below configuration, keep in mind this is specific to my device and is just for illustrative purposes, check your vendors documentation for correct syntax for your device.

set syslog enable
set syslog config "192.168.0.10"
set syslog config "192.168.0.10" facilities local0 local0
set syslog config "192.168.0.10" log traffic
set syslog config "192.168.0.20"
set syslog config "192.168.0.20" facilities local0 local0

The first IP address 192.168.0.10 is just a normal Linux server running rsyslog to collect logs, the second IP address 192.168.0.20 is the OSSEC server. You should be able to specify multiple syslog destinations on your device however it will depend on the particular device, this only needs to be done if you want to use both syslog and OSSEC otherwise just specify one or the other.

As seen above, there is less configuration for the OSSEC server because we are sending less information over from the device when compared to the syslog server. This is because traffic is logged to the syslog server whereas this additional ‘log traffic’ line of configuration is not present for the OSSEC server as here we only care about other logs such as user login success/fail.

That’s basically all that needs to be done on the device, it should now be sending a subset of syslog messages over to the OSSEC server, as long as the connectivity between the two are fine – don’t forget to write the configuration when you’re done editing it so that it’s persistent.

Configuring the OSSEC server

Now we need to configure the OSSEC server so that it knows how to deal with the syslog messages that it’s receiving. By default the main OSSEC configuration file is /var/ossec/etc/ossec.conf, this is what we are going to edit. Below is the section that I’ve added to my configuration to accept syslog messages from my network devices.

<ossec_config>
  <remote>
    <connection>syslog</connection>
      <allowed-ips>192.168.0.20</allowed-ips>
  </remote>
  <remote>
    <connection>secure</connection>
  </remote>
</ossec_config>

These elements within remote are documented here.

Basically the remote section is used to configure remote connections that come in to OSSEC, whether these be from either the traditional agent or syslog. A connection type of syslog will configure OSSEC to listen on the standard syslog port of udp 514. I have the second connection element set to ‘secure’ which is needed for the OSSEC agents on my Linux and Windows servers to be able to connect in on port 1514 as that’s what they use by default. You can always set the <port></port> tag and use any custom port that you wish, the same goes for <protocol></protocol> where you can specify either TCP or UDP.

To accept syslog messages you must set at least one tag that defines either a specific IP address or range that OSSEC will allow in. If you have multiple IP addresses or ranges to specify enter them one per tag per line.

Once the configuration is in place and saved you need to restart ossec-control to apply the changes.

/var/ossec/bin/ossec-control restart

Testing

Once the changes are in place and ossec-control has been restarted successfully there are a couple of logs you can monitor to confirm things are working as intended.

/var/ossec/log/ossec.log – this log will typically show you if there are any problems, for instance if your allowed-ips is set wrong and a device which is not allowed is sending syslog messages to the OSSEC server they will be logged here as failing.

/var/ossec/log/alerts/alerts.log – tail this file while logging in to the device, you should see the success and failure messages logging here as they are sent via syslog.

Summary

In this post we have covered how to configure OSSEC to accept syslog messages from various devices that are not able to have the agent installed. This is a good way to not only be able to centrally log with syslog, but to process the logs and alert through OSSEC and notify as required based on different log levels. You could also configure agentless monitoring, whereby OSSEC will SSH to the device and run a command on the device, for instance an md5sum on a file to check if it’s changed – this is documented here.