LWN.net Logo

OSSEC for host-based intrusion detection

By Jake Edge
April 21, 2010

A free software entrant into the host-based intrusion detection system (HIDS) arena, OSSEC, released version 2.4 earlier this month, with a number of upgrades and bug fixes. OSSEC may not be as well-known as other free software HIDS, like Samhain, AIDE, Osiris, or Open Source Tripwire, but they are all trying to do a similar job: detect changes to a running system that may have been caused by malicious activity. The techniques used by HIDS varies considerably, from simply hashing file contents and comparing them periodically to more sophisticated log file and behavioral analysis.

Conceptually, a HIDS should monitor everything about the system's state, such that it can detect changes in behavior that stem from some kind of host intrusion. Unlike network intrusion detections systems, which look at the network traffic to try to detect intrusion attempts, HIDS will only see problems after the fact. It is, in some sense, a second line of defense that is generally deployed behind a NIDS, at least in those installations with high security needs.

Most HIDS implementations only bite off some portion of the job. The simplest look for changes to system files and binaries by using hashes of their contents. Taking that a step further, and storing the hashes of "important" files on a separate system or read-only media provides defense against an intrusion that targets the files which store the hashes. OSSEC takes that idea even further by moving most of the monitoring and analysis to separate, presumably strongly hardened systems.

The basic architecture is intended to be client-server, with a "manager" running on a central server and "agents" running on each of the systems to be monitored. The agent is a small program that runs with low privileges and forwards information to the manager. There is also a "logcollector" process that runs as root on a client, and does just what its name would imply. Configuration information is mostly stored by the manager with some being locally cached. For obvious reasons, that configuration cache is monitored and changes to it will cause an alert.

OSSEC can be run in standalone mode, where the analysis and gathering are on the same host. The manager can also gather information from various devices, such as routers, firewalls, and other IDS systems without using an agent. There are agentless solutions for some devices, while others can use remote syslog to send their log information to the manager system. OSSEC is cross-platform, running on most major Unix systems as well as various flavors of Windows.

There are four main features to OSSEC, starting with file integrity monitoring. For logs, the monitoring rules are fairly extensive, covering a wide range of free and proprietary applications like apache, asterisk, Cisco IOS, McAfee anti-virus, MySQL, PostgreSQL, and so on. Much of what OSSEC does with log files is similar to what logwatch or syslog-ng can do, but the analysis can be done site-wide, and actions can be performed based on what OSSEC finds. New rules can be added for additional services or site-specific logging using an XML rule syntax.

As would be expected, system administrators can be alerted by email if some class of problem is detected. In addition, OSSEC has the ability to perform "active responses" based on certain kinds of attacks. OSSEC comes with a handful of pre-defined responses for things like adding an IP address to /etc/hosts.deny or to various firewalls' deny lists. Adding additional active responses is done by creating an XML chunk that specifies what to run and another to describe when to run it.

The fourth main feature of OSSEC is rootkit detection that runs periodically on client systems. For Windows clients, there is an additional feature that checks the registry for changes, and alerts the administrator of any it finds.

OSSEC was originally written by Daniel Cid and released as free software in 2004. Since that time, the code has been acquired twice, most recently by Trend Micro, which offers commercial support for OSSEC. It is licensed under the GPLv3, and is available as a tarball (along with SHA1/MD5 hashes for verification) from the installation page.

As with any HIDS solution, it will require some tweaking for specific environments to reduce false-positives to a manageable level. OSSEC has a number of useful features and looks to be a solution that is growing in popularity. It would seem to be a good candidate for one or more distributions to pick up and configure for their specific needs, which would make it easier for their users to start monitoring with OSSEC. For anyone considering HIDS for security at their site, OSSEC is worth a look.


(Log in to post comments)

OSSEC for host-based intrusion detection

Posted Apr 22, 2010 7:55 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

the biggest problem I have with OSSEC is that it is resistant to getting packaged.

It _really_ wants to be compiled on the target system. This directly conflicts with the fact that compilers tend to be forbidden on the security sensitive systems where it is most needed.

OSSEC for host-based intrusion detection

Posted Apr 22, 2010 14:50 UTC (Thu) by drag (subscriber, #31333) [Link]

Plus anything running on your system can be subverted by anybody attacking your system.

That is the major limitation to 'file hashing' HDIS type things. The only very effective way to run them is by taking the system offline and hashing from a alternative OS like a Live CD or something. And whats more you'll have to do all your installs, upgrades, and patches while the system is off the network and perform hashing before and after every upgrade.

Huge pain and very expensive to do this sort of thing 'right'. There is very little business justification for that level of expense.

Although I expect one of the arguments from OSSEC using folks would be that hopefully OSSEC module running on the machine would be able to relay information back to the central server before it's subverted by the attacker.

------------------
(on a side note)
I expect that HDIS can be wielded effectively when combined with a strong MAC policy applied via SELinux. Since it's very difficult to contain exploited user processes on any sort of *nix (and expecially) Linux systems. The attack surface for local user accounts is just too massive for DAC + "depend on good programming" to be effective. That way you can use your HIDS to monitor your services and make sure that they are not subverted... Of course... one kernel-level exploit and everything is toast anyways.

Ideally MAC + HDIS could be effective against kernel-level exploits if you combine it together with TPM (which is hopefully tamper-proof from the software side of things). That way you can do something like establish a 'chain of trust' from trusted module to system firmware to bootloader to kernel to initrd to userland which each part of the system's job is to validate the next item in a boot up.

But that is STILL limited to protecting you against attackers retaining control of your system through a reboot. Your still screwed if you have a exploit that is exploitable on the fly and the attacker goes through pains to make sure that they always operate from system memory and does not modify the file system binaries or configuration files in any meaningful way. To protect against that you'll need some way to monitor and validate code operating from RAM!

All in all it's completely space-cadet thinking that people would ever get something like that running in a cost-effective way.

---------------------------------------------
(on a side side note)

NDIS, of course, is very useful and can be done in a cost-effective manner, but nowadays it's not as useful as it once was. Long gone are the days when somebody will crack your server and install a IRC bot or server on it or something like that to control your systems. Instead nowadays they will subvert a existing service and relay commands to the root kit mixed in and disguised as legitimate traffic.

I would think that it would be very difficult for any NDIS to be able to cope with that.

OSSEC for host-based intrusion detection

Posted Apr 23, 2010 10:47 UTC (Fri) by Cato (subscriber, #7643) [Link]

No security measure is perfect, but using HIDS should raise the bar a bit - less competent attackers may not notice the HIDS in time to prevent it alerting the central server, or they may not correctly manage to disable it. Even if only a percentage of attacks are stopped by the HIDS, that may still be of value compared to the effort of maintaining it.

In the web host case, it's very useful to have a quick alert that certain files have been changed, e.g. by a scripted attack on a PHP or web app vulnerability.

OSEC for host-based intrusion detection

Posted May 6, 2010 19:52 UTC (Thu) by gvy (guest, #11981) [Link]

And less known HIDS well might be better at (not) getting spotted and disarmed in time. Just in case, there's OSEC -- ALT Linux homegrown one (standalone, no attempt at r/o checksum media or distributed operation but written by thorough people).

OSSEC for host-based intrusion detection

Posted Apr 23, 2010 11:10 UTC (Fri) by rwmj (subscriber, #5474) [Link]

I'd like to be able to do this from libguestfs for virtual machines. At least if the VM is compromised but the host is still OK, it should work.

OSSEC for host-based intrusion detection

Posted May 6, 2010 20:07 UTC (Thu) by spender (subscriber, #23067) [Link]

Speaking of TPM and its 'tamper-proof'ness, the enlightenment framework I developed disables all versons of IMA, a TPM-enabled kernel level Tripwire of sorts, in such a way that any remote monitoring host will not notice anything suspicious.

'Tamper-proof' is highly dependent upon implementation.

-Brad

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds