Slashdot Mirror

← Back to Stories (view on slashdot.org)

Detecting Rootkits In GNU/Linux

Posted by kdawson on from the watching-your-back dept.

An anonymous reader sends note of a blog post on rootkit detection in GNU/Linux. The article mentions only two utilities for ferreting out rootkits — the first comment to the blog post lists three additional ones — but it could be useful for those who haven't thought about the problem much. From the article: "A rootkit... is a collection of tools that a cracker installs on a victim's computer after gaining initial access. It generally consists of log cleaning scripts and trojaned replacements of core system utilities such as ps, top, ifconfig and so on."

4 of 142 comments (clear)

  1. Re:ifl by computational+super · · Score: 3, Insightful

    You know, one of the things I'd like to do if I had more time and knew how to do it would be to create a bootable "system scan" disk. A rootkit could hide itself from tripwire et al, but it couldn't hide from a bootable CD. I guess you can sort of achieve the same effect with Knoppix with a bit of work, but it would be nice to have something that I could use to scan a machine for vulnerabilities without using the hard drive to boot at all.

    --
    Proud neuron in the Slashdot hivemind since 2002.
  2. Re:Compiler is Irrelevant by profplump · · Score: 4, Insightful

    First, let me introduce you to the file command, which can tell me all about your arch. Or failing that, less, or any other program than can read any binary on your system. Your binary executables necessarily include information about their format, including their architecture.

    spaceheater ~ 0$ file /bin/bash
    /bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped

    Second, why are you worried about compilers and version numbers if you're so sure people can't load modules anyway? What exactly are you trying to protect? There's something to be said for a minimalistic system, but you've yet to explain how having a compiler installed poses any sort of realistic security threat.

    Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel? Even if you disable all the ways to do this without rebooting -- kexec() and /proc/kcore, probably among others -- they could always reboot the machine. Sure, you'd notice the reboot, but would you be able to detect their change after the reboot?

    I'd also like to mention that OS-enforced append-only files are a poor substitute to logging to a hardware-enforced WORM drive, particularly if we're talking about rootkits. You're still fundamentally relaying on the OS to provide protection, which isn't reasonable when a rootkit has been installed.

  3. Re:trojan the detector by sfjoe · · Score: 3, Insightful


    They can do that but, if you're like me, chkrootkit runs from a mounted CD-ROM. It's a little harder for them to trojan it that way.

    --
    It's simple: I demand prosecution for torture.
  4. Re:Read Only Drives by noahm · · Score: 4, Insightful
    Impractical, because it requires you to dedicate a drive to the stuff that can be mounted RO. Just mount the PARTITION read-only, instead.

    # mount -o remount,rw /readonly/partition

    So that won't help you...

    You could also built a monolithic kernel and not allow modules at all. Kind of hard to insert a corrupt module if the kernel isn't modular!

    That won't help either: http://doc.bughunter.net/rootkit-backdoor/kmem-pat ching.html Most modern kernel-level rootkits do not depend on the ability to dynamically load modules.

    noah