Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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)
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.
Posted Apr 23, 2010 10:47 UTC (Fri) by Cato (subscriber, #7643)
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)
Posted Apr 23, 2010 11:10 UTC (Fri) by rwmj (subscriber, #5474)
Posted May 6, 2010 20:07 UTC (Thu) by spender (subscriber, #23067)
'Tamper-proof' is highly dependent upon implementation.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds