On Thu, Mar 29, 2001 at 04:13:20PM -0500, Noah L. Meyerhans wrote: > > Yes, knark does this, and does it very well. It's available from > packetstorm, and I've seen it in action "in the wild". It's extremely > effective. Fortunately such rootkits are still very uncommon. I'm not > sure why that is, as they're no more difficult for the script kiddy > than any other rootkit. If used right, they're completely effective > against things like tripwire or AIDE. They can do more than just hide > files, too. indeed. > Note that LIDS is supposed to be able to detect Knark. It also helps to > portscan the machine from a known good system and look for ports that > should not be open (especially ports that don't look open on the > potentially cracked box). It's also worth it to reboot from a trusted > rescue disk, but don't use the standard rescue disks! They load modules > from the systems hard drive, one of which could insert knark. one can also use lcap to remove CAP_SYS_MODULE and CAP_SYS_RAWIO from the kernel capability bounding set. this makes it impossible to install modules and blocks access to /dev/mem, /dev/kmem and /proc/kcore even to root. this *should* make it pretty much impossible to install the kernel module without rebooting the machine (which should attract the attention and scruteny of a good admin). the problem with this approach is the intruder can remove the lcap call from the initscripts and reboot. before you say make the initscripts and kernel immutable and revoke CAP_LINUX_IMMUTABLE notice that revoking that capability does NOT disable root's access to the raw device files, so its still trivial for root to remove the immutible bit from any file using debugfs and mount -o remount /whatever. AFAICS there is no capability that blocks root's access to the raw disk device files, unlike the BSD securelevel. of course even if you could, its been said you cannot make / and /etc immutable without severly breaking the system which means the attacker need only do the following: cp -a /etc /etc.new mv /etc /etc.old mv /etc.new /etc <remove offending security calls from /etc> reboot rm -rf /etc.old of course this again requires a reboot which should be noticed. both this and lids make system administration a royal pain (every security update will require a reboot into single user mode). lids can perhaps do a better job, but its funky to configure, breaks things and still makes admining the box a royal pain. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpWhVdHh1cVa.pgp
Description: PGP signature