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."

6 of 142 comments (clear)

  1. ifl by stoolpigeon · · Score: 3, Informative

    I think that there is room to mention the well known tools such as AIDA and TripWire and LogCheck.

    --
    It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
    1. Re:ifl by Moby+Cock · · Score: 4, Informative

      Most modern rootkits are kernel level and Trip Wire can not readily detect them. Nevertheless it is still useful to have at hand.

    2. Re:ifl by Anonymous Coward · · Score: 3, Informative

      Something like this?

  2. Re:This is... by Rosco+P.+Coltrane · · Score: 5, Informative

    It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.

    I'll tell you a little secret: if you know the kernel version number and target architecture, you can build a module on another, totally different machine. Wow! 2007 technology man!

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  3. Compiler is Irrelevant by brunes69 · · Score: 3, Informative

    It's pretty trivial to just deduce what kernel the machine is running and build working binaries wherever you want. In fact it would be preferred, since a sysadmin is far more likely to notice a rogue gcc process sucking up CPU than a file transfer while the rootkit is being loaded.

    Anyway - if the person has root on the box (which they need to install the rootkit anyway), then they can just ship up THEIR OWN COMPILER if they want to regardless.

  4. Re:Read Only Drives by chill · · Score: 4, Informative

    Impractical, because it requires you to dedicate a drive to the stuff that can be mounted RO. Just mount the PARTITION read-only, instead.

    If you have more than one machine, get a dedicated syslog server and send the logs from the other machines over to it. This way logs aren't on the main machines and it is much harder to compromise the audit trail.

    For businesses, get something like a Trigeo appliance and keep an eye on the behavior of everything.

    Make sure all your permissions/rules are based off the concept of "default deny, explicit allow".

    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!

      Charles

    --
    Learning HOW to think is more important than learning WHAT to think.