This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: Security

An open source security triple play

By Joe Barr on August 07, 2006 (8:00:00 AM)

Share    Print    Comments   

Want to protect your SOHO machine or LAN from rootkits and malware, but want something a little more real-time than simply running Chkrootkit or another rootkit detector after the fact? Consider OSSEC-HIDS, an open source host intrusion detection system.

According the OOSEC-HIDS Web site, it's more than a host intrusion detection system (IDS). It's also a security event manager and a security information manager, which makes it the security equivalent of a hat trick in hockey, a triple-play in baseball, or a rare triple-double in basketball.

OSSEC-HIDS runs on both Windows and Linux/Unix. You can download the latest version along with the project's PGP public key, so you can verify the download.

You'll need to have GCC installed on your system in order to install OSSEC-HIDS, as the install script compiles the various tools as it runs. Using the install script is the recommended approach, though you are free to hack your way through the install manually if you prefer.

You can install OSSEC-HIDS in a client-server fashion, or simply on your desktop machine. The script will ask which you're doing, since the chores to be done depend on that. I selected a local installation, meaning it's just set up to run on one machine. If you're going to be running it on several machines, you'll want to install the server first, then the clients. Ubuntu users can find detailed installation instructions by Stephen Bunn on UDSF.

Only advanced users will need or want to choose anything but the default choices during the installation, so just press Enter now and then and watch the lines scroll by in the terminal. At the end of the procedure, the install script tries to set up an init script to start OSSEC-HIDS at boot time. Unfortunately, the script didn't recognize either of the two platforms I've installed it on: Ubuntu or SUSE SLED 10. Bunn's install tips page noted above shows how to rectify that on Ubuntu.

I was more interested in seeing it run than in getting it set up as an init script, at least at first, so I cranked it up by entering this command as root:

/var/ossec/bin/ossec-control start

Assuming you stuck with the default choices, you'll see these messages when it starts up for the first time:

Suse10-1:/home/warthawg # /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v0.9 (by Daniel B. Cid)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...

OSSEC-HIDS keeps its configuration in /etc/ossec.conf in the directory it was installed in. If you kept the default directory, the full file spec for it would be /var/ossec/etc/ossec.conf.

Like Snort, the venerable open source network IDS, OSSEC-HIDS is rules-based. The default install puts 26 different rule sets in the rules directory. According to the manual, you can combine and extend the rules to achieve custom-tailored results, but I'm not ready to experiment with that yet.

Active response

In addition to checking your log files, searching for rootkits, and identifying changes to programs or other files in accordance with your configuration, OSSEC-HIDS can also perform active response measures in the event of an intrusion.

This is a somewhat controversial and possibly risky technique. Active response means that when certain thresholds or events occur, the software will execute predetermined commands or responses. A possible unintended side effect of active responses is to tip your hand to the attacker, who may then craft a denial of service attack based on your response. The benefits are that active response can stop certain illicit activities -- port scanning is an example -- and it also allows you to quickly close a possible window of vulnerability.

By default, OSSEC-HIDS blocks an attacking host IP address for 10 minutes using either /etc/host-deny or a firewall drop-IP command whenever a rules violation with a severity level of 6 or above is discovered. The installation process allows you to whitelist IP addresses that you never want to be blocked.

Tweaking the config

When you use all the defaults as recommended, you are going to receive alert messages from OSSEC-HIDS that you probably don't need or want to receive. You'll need to tweak the configuration in order to stop getting them.

One way to do that is by modifying the Syscheck section of the configuration file. By default, it looks like this, after the Windows directives are removed:

  <!-- Frequency that syscheck is executed - default every 2 hours -->

  <!-- Directories to check (perform all possible verifications) -->
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/bin,/sbin</directories>

  <!-- Files/directories to ignore -->


In addition to adding or ignoring directories, you can change the checks to be performed on those selected. To tweak the checks performed, set check_all to "no" and then set your choice of check_sum, check_size, check_owner, check_group, or check_perm to "yes".

You can also tweak the settings for rootkit checks and the level for mail alerts.

Is it real or is it Memorex?

If you're paranoid, false positives can scare you. I've installed OSSEC-HIDS on a couple of systems. On one box, I installed a preview release of SUSE SLED 10 three times, and as the first order of business each time, I followed the installation of the OS with an OSSEC-HIDS install. Each time I did so, I received the following alert:

** Alert 1154021500.0: mail
2006 Jul 27 12:31:40 Suse10-1->rootcheck
Rule: 14 (level 8) -> 'Rootkit detection engine message'
Src IP: (none)
User: (none)
Rootkit 'ZK' detected by the presence of file '/etc/sysconfig/console/load.zk'.

I've forwarded all the details to the OSSEC-HIDS community mailing list so that the developers can check it out. Hopefully it will turn out to be a false positive, and they will be able to avoid generating the alert next time. In the meantime, I am eyeing that box with suspicion.

OSSEC-HIDS can become a new standard for security, not just for system administrators but for SOHO users as well. It takes a bit of effort to configure it properly, but if you're concerned about security, as we all should be, it looks to me to be time well spent.

Share    Print    Comments   


on An open source security triple play

Note: Comments are owned by the poster. We are not responsible for their content.

Rootkit information

Posted by: Anonymous Coward on August 08, 2006 12:16 AM
I got here from a new resource on the internet, <a href="" title=""></a>. I recommend checking their site out to get more information on rootkits, spyware, trojans, viruses, and other malware.


too much effort?

Posted by: Anonymous Coward on August 08, 2006 05:40 AM
Perhaps it's just the nature of intrusion detection that administering it will always be complex, but that very complexity makes it useless for a lot of admins. Too much work to tweak and tune, too many false positives, and you're never really sure if it's going to catch the bad stuff.

I do what I can by putting system files non-writeable media, like bootable live CD-ROMS. I know those binaries are good.<nobr> <wbr></nobr>:) This isn't very practical for busy servers, but for firewalls and low-volume servers it works great. Maybe someday we'll have hard drives that include a physical write-protect key.


Very little effort to me...

Posted by: Anonymous Coward on August 08, 2006 09:32 AM
I found ossec to require much less effort to install and configure than most security tools out there. I have it running on my Fedora and RHEL systems and the installation did everything for me (including init scripts) and I didn't have a problem with false positives so far.



Posted by: Anonymous Coward on August 08, 2006 09:35 AM
I think that it seems cool.<nobr> <wbr></nobr>:)

Never heard of this one before, but it seems it have potential.



Posted by: Anonymous Coward on August 08, 2006 07:11 PM
its always a bit weird to compile stuff on machines you want to secure; hackers love being able to compile too.
A good idea would be to deinstall gcc et all after this install.



Posted by: Anonymous Coward on August 08, 2006 07:23 PM
De-installing gcc won't help much (especially on i386) since the hacker can just pre-compile stuff at home. It's far better to use mandatory access control things like SELinux. Removing gcc doesn't make your system any more secure.



Posted by: Anonymous Coward on August 08, 2006 08:04 PM
You are mostly right. But long story short, you will never keep out someone with sufficient dedication and technical skill short of unplugging the machine. All you can do is raise the bar of irritation and difficulty and hope most move on to softer targets.


Worthless review

Posted by: Anonymous Coward on August 08, 2006 09:29 PM
I can't believe what passes for technical journalism these days. All this artical shows is some amateur fiddling with a software installation. The entirety of this could have been summarized "well, I installed it and it works". There's not much mention of what the software actually does, how it works, what its core features are and how it compares to other similar packages. Thanks for nothing.


Re:Worthless review

Posted by: Joe Barr on August 09, 2006 02:12 AM

You're certainly welcome, and thanks for your input.


Re: Worthless review

Posted by: Anonymous [ip:] on February 11, 2008 03:24 AM
Thanks to this "worthless review" as you call it, I now have a good solution for securing my system.

BTW: Some of Joe Barrs articles helped me out considerably when I was getting a start with Linux almost four years ago.


active response is completely broken

Posted by: Anonymous Coward on August 09, 2006 05:06 AM
I've tried injecting attacks into my log file, and active response (specifically the firewall script that triggers a block on iptables) doesn't work.

It isn't even attempting to execute the "command", because when I run the script myself it works just fine.

I spent hours fiddling with the xml rule files, injecting various dangerous attacks using echo into my log file. Doesn't even attempt to execute the firewall scripts.


Re:active response is completely broken

Posted by: Joe Barr on August 09, 2006 05:52 AM

I doubt that's the case (that it's completely broken). Much more likely something in your configuration is not right. Check in on the mailing list, they can probably set you straight in a jiffy.



Posted by: Anonymous Coward on August 09, 2006 07:18 AM
Does this means that SLED10 comes contaminated with the ZK rootkit or you have been compromised, please report as this is severe for Novell users. That is not a false positive.



Posted by: Administrator on August 09, 2006 12:01 AM
cool software, ill try it out


An open source security triple play

Posted by: Anonymous [ip:] on January 16, 2008 03:35 AM
I love this open source Host IDS associated with Network IDS Snort, but i really didn't like the active-response module.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya