User: Password:
Subscribe / Log in / New account

OSSEC for host-based intrusion detection

OSSEC for host-based intrusion detection

Posted Apr 22, 2010 7:55 UTC (Thu) by dlang (subscriber, #313)
Parent article: OSSEC for host-based intrusion detection

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.

(Log in to post comments)

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.


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