Forgot your password?
typodupeerror
Security Software Linux

Detecting Rootkits In GNU/Linux 142

Posted by kdawson
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."
This discussion has been archived. No new comments can be posted.

Detecting Rootkits In GNU/Linux

Comments Filter:
  • ifl (Score:3, Informative)

    by stoolpigeon (454276) * <bittercode@gmail> on Monday December 18, 2006 @04:21PM (#17291050) Homepage Journal
    I think that there is room to mention the well known tools such as AIDA and TripWire and LogCheck.
    • Re:ifl (Score:5, Informative)

      by Moby Cock (771358) on Monday December 18, 2006 @04:39PM (#17291312) Homepage
      Most modern rootkits are kernel level and Trip Wire can not readily detect them. Nevertheless it is still useful to have at hand.
      • Re:ifl (Score:5, Funny)

        by stoolpigeon (454276) * <bittercode@gmail> on Monday December 18, 2006 @04:44PM (#17291392) Homepage Journal
        i have no idea. i've never used any of them. this is a joke gone completely wrong. i just copied and pasted the comment from over at tfa. hence my subject: ifl (it's funny laugh). i figured it'd end up troll, over-rated, but i got such a laugh out of doing it (sorry i'm easily amused) that i figured it was worth it. in what is a horrid twist of fate, i now feel bad for getting modded up.
      • Re:ifl (Score:4, Insightful)

        by computational super (740265) on Monday December 18, 2006 @05:05PM (#17291710)

        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.

        • Re: (Score:3, Informative)

          by Anonymous Coward
          Something like this [s-t-d.org]?
        • by jamesh (87723)
          Never underestimate the ingenuity of a hacker... consider the following (theoretical) possibilities:

          . The system could be almost completely restored on an orderly shutdown, leaving nothing detectable but a single hook (hide everything else in swap or unused sectors in filesystem)

          . Even without an orderly shutdown, a rootkit could keep stuff in the unused parts of the harddisk all the time, the rootkit would take care of not overwriting it.

          . MD5 hashes can be subverted, which means the above mentioned initia
          • Besides the point! (Score:2, Informative)

            by TrueKonrads (580974)

            Kind of bypasses the point of detection, in a way.

            One cane safely ass-u-me that if the storage is disconnected, then , if You look very very close, then You could detect a rootkit. Though IF,

            1. If the kit is in-mem only and subverts no system binaries and stores its support files somewhere under /home/maryjanesmith/ or somewhere on /var/www, in other words - locations with thouesand of changing files (TripWire won't work even with SHA1 or other non md5 sums)
            2. Uses an unpatched hole or security lapse to act
          • Re: (Score:2, Informative)

            by Jackmn (895532)

            . The system could be almost completely restored on an orderly shutdown, leaving nothing detectable but a single hook (hide everything else in swap or unused sectors in filesystem)

            The only way to leave a 'hook' on any common setup is to modify the storage medium of the OS or modify the firmware of a piece of hardware. Both can be detected, and there's no way to prevent that.

            MD5 hashes can be subverted, which means the above mentioned initial hook could hide (I believe this is only really useful if the hoo

            • by jamesh (87723)

              The only way to leave a 'hook' on any common setup is to modify the storage medium of the OS or modify the firmware of a piece of hardware. Both can be detected, and there's no way to prevent that.

              But you can prevent it from being easily detected. Especially the theoretical BIOS VM kit I mentioned. If you can place the whole operating system inside a virtual machine, then it is virtually impossible to detect without taking the BIOS chip out and reading it offline. Any attempt to detect the compromise would

        • by bl8n8r (649187)
          Knoppix doesn't use the hard drive to boot. At all. You can take the hard drive out of your comp, put it in the microwave, and knoppix will still boot. It's that amazing.
  • This is... (Score:2, Informative)

    For starters, why you do NOT keep any sort of compiler on your machine.

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

    It'd be even better if you could make every program execute only (no reading) and hide /proc through something like NSASecurity setup. What they dont know, they cant do much with. Obfuscation, THEN security. Keep em guessing.
    • Re:This is... (Score:5, Informative)

      by Rosco P. Coltrane (209368) on Monday December 18, 2006 @04:27PM (#17291152)
      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!
      • Re: (Score:1, Interesting)

        by Anonymous Coward
        "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!"

        Not on my internet-facing servers. No compilers and hand-compiled monolithic kernel.
    • Re:This is... (Score:5, Interesting)

      by psycho8me (711330) on Monday December 18, 2006 @04:27PM (#17291160) Journal
      That may have been true 30 years ago when a compiler license cost thousands. If a person has write access to your system, they can just copy a compiler binary over.
      • Re: (Score:1, Funny)

        by Anonymous Coward
        Cuz people who are looking to install rootkits on your computer are very respectful of copywrite law.
      • by gwait (179005)
        How would an unauthorized person get write access to my kernel or operating system files? I keep them all password protected, and I only allow root login on the console.
        • by gmack (197796)

          How would an unauthorized person get write access to my kernel or operating system files? I keep them all password protected, and I only allow root login on the console.

          I do hope your joking but in case you aren't: Attackers gain access by exploiting bugs in either network daemons or web scripts to gain access to the machine. then if they aren't root already they try and find a local utility that can be used to elevate their privileges.

          Just because it's Linux does not mean it's secure. If you have any

    • by brunes69 (86786) <slashdot AT keirstead DOT org> on Monday December 18, 2006 @04:28PM (#17291178) Homepage
      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.

      • Then I fail to understand: If you run a static kernel with NSA in, no compiler, no discernable way to tell the arch/version, and root removed (via NSA sec), how can you rootkit a machine? Hell, even BSD has apphend-only files for purposes of logfiles.
        • This [acm.org] is a good place to start. There are more ways to break into a house than there are doors.
        • by profplump (309017) <zach-slashjunk@kotlarek.com> on Monday December 18, 2006 @05:26PM (#17292046)

          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.


          • Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel?

            This reminds me of a certain rootkit that would copy its own kernel into your swap partition. On reboot the new kernel knows not to use that portion of the swap partition that is now currently occupied by the kernel.

            How the hell are you supposed to detect this afterwords?! Oh yea, it would have to modify your boot configuration.. which is detectable.
            Still neat though.

            -metric
    • by diegocgteleline.es (653730) on Monday December 18, 2006 @04:54PM (#17291544)
      Real men and real hackers write their programs in binary code, not in stupid and bloated assembler.
      • Bruce Schneier once wrote a kernel module just by cut'n'pasting 0s and 1s in an xterm.

        More on http://geekz.co.uk/schneierfacts/ [geekz.co.uk]

      • by Anonymous Coward
        52 65 61 6C 20 6D 65 6E 20 61 6E 64 20 72 65 61 6C 20 68 61 63 6B 65 72 73 20 77 72 69 74 65 20 74 68 65 69 72 20 70 72 6F 67 72 61 6D 73 20 69 6E 20 62 69 6E 61 72 79 20 63 6F 64 65 2C 20 6E 6F 74 20 69 6E 20 73 74 75 70 69 64 20 61 6E 64 20 62 6C 6F 61 74 65 64 20 61 73 73 65 6D 62 6C 65 72 2E
        • Re: (Score:3, Funny)

          by Linker3000 (626634)
          Hey, AC, There's a guy on the phone for you - says he's from SCO and he'd like a quick word.
    • Oh what's a Gentoo user to do?
    • No no, the real fruitbats disable the kernel module facility entirely. It could be used as a rootkit vector!
    • by gmack (197796)
      That's crap. The only way to keep people from installing back doors on your system is to keep up with your security updates and only run daemons with good reputations for security. I've seen backdoored glibc so the kernel isn't the only backdoor possibility.

      If any of my clients comes to me telling me someone made root on their system my advice is always to backup the data and reformat. I had a guy once refuse my advice and ran several security scanners only to miss one and have his server shut down again
  • by Rosco P. Coltrane (209368) on Monday December 18, 2006 @04:24PM (#17291108)
    ... with the Internet Freedom Disk [slashdot.org]!
    • Re: (Score:2, Funny)

      by Anonymous Coward
      ... with the Internet Freedom Disk!
      First it was "freedom fries," and now they've gone and corrupted what was once a perfectly fine Internet French Disk with their misplaced patriotism.
  • OSSEC HIDS (Score:2, Informative)

    by magmf (748370)
    I PREFFER OSSEC HIDS to do this. look www.ossec.net i think this is the most powerfull agent ever :)
  • Pish Posh (Score:5, Funny)

    by eno2001 (527078) on Monday December 18, 2006 @04:26PM (#17291136) Homepage Journal
    It's GNU/Linux. Any hacker worth his salt doesn't want to bother with archaic OSes based on Unix. He wants the 1337 stylings of Windows Vista. No sense in rootkitting a *nix box. You can't do anything with a *nix box. But an army of zombie Vista PCs, now THAT is ULTIMATE POWER!
    • Yes, but... (Score:5, Funny)

      by Darlantan (130471) on Monday December 18, 2006 @04:36PM (#17291268)
      You have your l33t ninja with his army of zombie Windows boxes... ...but how do they stack up to the *nix pirates, and their FTPs on the seven seas of the intarwebs? It's the classic clashes, modernized. Who has the REAL Ultimate Power?
      • by oldhack (1037484)
        It all comes down to the tube qualities. Can't bypass the laws of tubic physics.
      • Mr. Rogers. [newgrounds.com]
      • by trigggl (758335)
        That was a couple of days after openning a port in my router for ftp. I thought it was cool to be able to transfer files to and from work. I set it up so that only users could sign in and the user would be locked into their home folder. I saw a couple of attempts to get in in the log. I was watching the monitor of my internet traffic when someone got in and instantly data was going both ways. That's when I turned the DSL router off, closed all ports on the router behind it and disabled ftp on the box.
      • What about the fact that around half the internet runs on *NIX boxes of one stripe or another? Root one of those, and capture ALL the user data (IDs, passwords, credit card numbers, whatever) that passes through it. Much more efficient than relying on a random army of Windows Zombies.

  • Read Only Drives (Score:5, Interesting)

    by DigitalRaptor (815681) on Monday December 18, 2006 @04:38PM (#17291292) Homepage
    I run Gentoo Linux servers for hosting email and websites, and have wanted a way to really secure the boxes.

    Many hard drives have jumpers that make them read only.

    I thought it would be great to have all of the rarely changed portions of the operating system on a separate drive set to read only.

    The only time you would move the jumper to read-write would be when you were installing updates.

    Things like: /tmp /var/log
    etc

    Would have to always be on a read-write drive.

    But having things like /usr/bin on a read-only drive seems like an effective way to protect against many, many different root-kits, worms, etc.

    What do you think? Feasible or impractical?

    • can you flip them on the fly? if not, is the down time worth it?
      • by WaXHeLL (452463)
        Why would you want to flip it on the fly? I thought the parent thread's point was to get the OS setup and secured, and then hardware jumper it to read only.

        All the relevant data and /var/tmp are placed on another *physical* drive.
        • Re: (Score:3, Informative)

          by Darlantan (130471)
          You'd want to be able to flip it on the fly for OS updates. Otherwise, you're looking at pretty routine downtime -- which may or may not be an issue for you.
          • by WaXHeLL (452463)
            Well, with a secure operating sytem like OpenBSD, patches aren't released [openbsd.org] very often.

            But then, the parent was talking about Gentoo.

          • Re: (Score:2, Interesting)

            by FlyingGuy (989135)

            This is where about $5.00 worth of parts and a soldering iron will help you out.

            Most all chassis have at least ONE empty slot. Buy a simple miniature SPST toggle switch and some thin wire. Take a jumper and split it electricaly, then solder a wire to each jumper socket. Solder each end of the two wires to the pins on the toggle switch. Drill an approprate hole in the slot dust cover and mount the switch, or just feed the wires out and mount the switch on something close to the box. You now have on the

        • "Why would you want to flip it on the fly? I thought the parent thread's point was to get the OS setup and secured, and then hardware jumper it to read only"

          Yeah, that's quite easy on a publicly exposed machine where almost weekly some security-concerning bug is found... specially talking about Gentoo as the OS of choice!
      • Good question. I was always under the impression you could, though it would probably vary by vendor.

        I was going to build a device that allowed me to switch between read-only and read-write remotely over TCP/IP or dial in (for servers in a data center).

        This was 4 or 5 years ago and I was using Red Hat and security wasn't nearly as good (in any distribution).

        I sleep better at night using hardened Gentoo, but if the read-only method were feasible I'd build it into my next server for sure and sleep even better
        • by dfn_deux (535506)
          It would be insanely trivial for someone with an EE background to make a jumper emulator which is operated via parallel port that could switch the drive (or any other jumper for that matter), the issue is whether or not the drive's firmware honers the jumper setting at anytime or if it is a "check once" type of setting. I suspect that the firmware only cares about the jumper setting when the disk is first spun up, but I could be wrong.
      • Re: (Score:3, Funny)

        Yeah, there's a program you can run to flip them whenever you need to. I had to install it SUID root though.

        • is that like that software for making sandwiches?
           
          i kid, i kid. i'm just an xkcd fanboy with too much time on his hands.
    • by Ashtead (654610)

      I've seen CD-based distros that have / as read-only. That certainly is possible, and the Picotux 100 computers are also set up like that on delivery: a read-only / and a read-write /usr filesystem.

      You probably want to make at least /tmp, /var, /home, /mnt, the swap space, and parts of /usr read-write. I am quite certain that this is possible.

    • Re:Read Only Drives (Score:5, Informative)

      by chill (34294) on Monday December 18, 2006 @04:56PM (#17291572) Journal
      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 [trigeo.com] 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
      • Mounting the partition read only is easily overcome as soon as they have root. Change /etc/fstab, unmount, and remount and the partition is now read-write.

        A dedicated syslog server is always a good idea if it fits the budget.

        • by sylvandb (308927)
          Mounting the partition read only is easily overcome as soon as they have root. Change /etc/fstab, unmount, and remount and the partition is now read-write.

          Or maybe by "mount -o remount,rw {partition}" ?

          A dedicated syslog server is always a good idea if it fits the budget.

          Sure, anything to get the logs off the compromised system is a good idea. Even piping them out to an attached printer, or an RS232 data logger, or WORM drive, or another server, or a workstation, or...

          sdb
      • by noahm (4459) on Monday December 18, 2006 @05:51PM (#17292476) Homepage Journal
        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 [bughunter.net] Most modern kernel-level rootkits do not depend on the ability to dynamically load modules.

        noah

        • by chill (34294)
          All of it helps, because it leaves nice big footprints in your logs. Monitor them in real time.

          To help prevent them from getting root, use patches like grsecurity which add address randomization and specifically deals with /dev/kmem direct patching.

          If someone has root on your server, you've already lost. You need to go into "containment" and "cleanup" mode.
      • by jamesh (87723)

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

        Any rootkit that can get root could easily remount it rw.

        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!

        This sounds like a good idea, but is it possible to build everything in these days? Last time I checked I think there were some things that could only be built as modules...

    • by throx (42621)

      But having things like /usr/bin on a read-only drive seems like an effective way to protect against many, many different root-kits, worms, etc. Ineffective and simply feel-good security.

      If someone has root on your box (which is needed to install a rootkit) then they can just copy the read-only system to the writeable disk and mount it r/w. Now, given that they *already* know how to get root on the box then rebooting will clear whatever changes they made, but also put your system back into the configuration

      • You're assuming that /etc/fstab is on the read-write disk. If it's on the read-only disk, they've accomplished nothing and your system is clean after a reboot.

        Other things may be compromised, but your core OS would not be. And if other things are compromised, those things are more likely to be backed up and resurface after you restore the server.

        • Re: (Score:3, Insightful)

          by throx (42621)
          I'm not assuming anything is on a read-write disk. If the attacker is able to load arbitrary code into the kernel then it doesn't matter where /etc/fstab is - they can just rewrite the kernel at runtime to mount a disk without worrying about /etc/fstab.

          Yes - your machine will be "clean" after a reboot, but because you've made it read only it will be vulnerable to whatever attack gave them root in the first place.

          Any system - read/write or read only root drive can be reset to a known configuration with litt
          • Regardless of the exploit used to gain root, how many of todays rootkits do you think don't require being able to write to some of the files that would be on the read-only drive.

            Nothing will prevent all rootkits.

            But having files (like /bin/login, a common one changed by rootkits) on a read-only drive may prevent many of the existing rootkits from doing damage or working at all.

            If everyone were doing this and it were built into the distributions, then yes, rootkits would be written around this strategy. But
            • by throx (42621)

              Nothing will prevent all rootkits.

              Well - one thing will. Not allowing the attacker to get root in the first place.

              This is what I'm trying to reinforce. There is no point in considering defenses against an attacker who has root. At that point, you are being grossly negligent if you do anything but forensic analysis and removing the machine from a public network until such time as you can do something to prevent future incursions of the type that went through. Inventing clever tricks to stop root from hac

    • Try Knoppix or any of it's derivatives.
    • by mlock (648386)
      How often do you reboot? Once a year? Than a rootkit will be active for half a year on average - because even if it doesn't get to disk, you'll have it in RAM.

      You'd need read-only RAM - and this is what the OS is supposed to provide (process separation).
      If it fails, you've lost.

      And furthermore there are some things on startup that write temporary data to /tmp - possibly in a fixed path.
      So you create this file, make it unchangeable (eg. ext2/3 attribute, or simply 0555), and write malicious data there - mayb
  • by Timesprout (579035) on Monday December 18, 2006 @04:39PM (#17291324)
    When the dark suits turn up on my doorstep with an arrest warrant on charges of attempting to crack confidential government sites I can be pretty sure my machine has been rooted.
  • ... just .. un-cool?

  • A well done rootkit is hard to detect... if you can't find a rootkit on your system then it's probably too late.

    Go here now. [openbsd.org]
  • That's easy. Are you running VMWare with a Windows virtual install on this Linux box? Delete that virtual machine. Rootkit eliminated.
  • trojan the detector (Score:2, Interesting)

    by tkw954 (709413)
    Wouldn't the first step for a rootkit developer be to add rkhunter and chkrootkit to their list of trojaned programs so that they give a "no rootkit" output? Maybe there's some protection from this, but I don't see it in the article.
  • by sootman (158191) on Monday December 18, 2006 @05:03PM (#17291684) Homepage Journal
    How hard is it to build a basic but worthwhile rootkit detection tool with common tools? Like run `md5 /bin/*` and then ship the output of that to another machine every day for comparison to yesterday's output of that command? (Looking at other directories as well, of course.) My understanding is that many rootkits come with hacked versions of tools like 'ps' to hide themselves.

    On the one hand, yeah, let's not reinvent the wheel, but on the other hand, there are advantages to building your own tools:
    - you know exactly what they're doing--more complicated pre-existing tools might do more, but if you don't understand their output, they're no good.
    - you don't have to trust*/audit someone else's code
    - they don't do more than you need
    - they don't have features that you don't know about or might misuse
    - at the very least, it's a great way to learn

    * yes, I know about this. [acm.org] but there are reasonable limits--I do trust that my distro came with a clean copy of gcc. OTOH, I'd rather write my own 20-line script that download someone else's that says it does the same thing as what I would write myself but that I'd have to audit for even the smallest things, like sneaking in an
    if ($rooted="no")
    instead of
    if ($rooted=="no")
    • Re: (Score:1, Interesting)

      by Anonymous Coward
      Like run `md5 /bin/*` and then ship the output of that to another machine

      Nothing wrong with that, but how do you know md5 hasn't been compromised? The only way to be sure is to boot into something else like a livecd and run md5 from there.
      • by sootman (158191)
        Wouldn't it be pretty trivial to
        cp /mnt/cdrom/md5 /sbin/
        each night before running the tool? Or, as someone else suggested, leave md5 on with another name? I'm sure most rootkits wouldn't notice if 'zsh' was actually a copy of 'md5.'

        I'm not talking about a bulletproof tool for the NSA. I'm just interested in something basic that would do the trick for most people.
        • by noahm (4459)
          Wouldn't it be pretty trivial to
          cp /mnt/cdrom/md5 /sbin/
          each night before running the tool? Or, as someone else suggested, leave md5 on with another name? I'm sure most rootkits wouldn't notice if 'zsh' was actually a copy of 'md5.'

          Yes, it would be trivial. Unfortunately, it wouldn't do you much good these days. Modern rootkits (on Windows, Linux, what have you), are kernel based. It doesn't matter how trusted your md5, ls, ps, and other binaries are if your kernel is not reporting accurate inform

          • by Sancho (17056) *
            Exactly. Good rootkits patch syscalls, not binary programs. This way, no matter what program does your directory listing, you'll never see the rootkit's hidden files. Only the rootkit's programs will have the key to making the syscalls work as normal.
    • by rjstanford (69735)
      If (and I've never been paranoid enough to worry about it, so it is an "if") you care this much, you have to worry that they'd give you a new version of md5 as well. Sticking a known good version somewhere else under a different name is probably more than enough security there, though.

      Better yet, add a random amount of crap onto your key binaries so that they're non-standard, then get checksums with some theoretically known-good checksummer. Keep an eye on them automatically, and every now and then get th
  • by straponego (521991) on Monday December 18, 2006 @05:07PM (#17291730)
    I just eyeball /proc/kcore for anything suspicious every day or so.
  • "His passwd program has the same name as the real passwd program and works flawlessly in all respects except for the fact that it will also gather data residing on your machine such as the user details each time it is run and transmit it to a remote location or it will open a back door for outsiders by providing easy root access and all the time, you will be impervious about its actions."

    ...I don't think it means what you think it means.

    http://www.answers.com/impervious&r=67 [answers.com]

  • chkrootkit (Score:3, Informative)

    by joe 155 (937621) on Monday December 18, 2006 @05:22PM (#17291964) Journal
    chkrootkit is good, I like it anyway, you can get it in Fedora Core 6 through yum (although you don't seem to be able to get rkhunter through yum any more). you have to run it as root, maybe its something about what it needs to access... anywho, you can get issues with false possitives, I just ran it and got;

    Searching for OBSD rk v1... /usr/lib/security
    /usr/lib/security/classpath.security
    ....
    Searching for suspicious files and dirs, it may take a while...
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi/.pack list

    so I wouldn't worry too much if you see something that looks iffy before you check it out (I'd have been annoyed if I just reinstalled my OS just to find the same thing happening again). It will also show your ethnet port as being in "sniffer". Anywho, best practices can minimize the risk to pretty much 0... oh, but for God's sake PLEASE switch off remote root access on ssh over default ports, ideally switch it off altogether (If you need it please learn how to use it). Ssh coupled with an easily broken root password is the single biggest cause of rootkits... and a huge /var/log/secure!
    • by nuzak (959558)
      > Ssh coupled with an easily broken root password is the single biggest cause of rootkits

      Which begs^H^H^H^Hdemands the question: why doesn't any distro install one of the many ssh brute-force prevention utilities out of the box? Some of them don't even need to look at logfiles, they're simply common-sense firewall rules.
    • I use "AllowGroups blah" in sshd_config. This prevents any account which is not in the blah group from logging in via ssh. This keeps root out (although I turn root logon off anyway, or set it to use SSH keys only), as well as any system accounts. The disadvantage is that it's slightly more trouble to maintain.
  • If you want a bigger list of such tools, type ls /usr/portage/app-forensics/ on any gentoo machine.
  • I can't help but point out on FreeBSD you can use CVSup to force your sources to match the master site, and then "cd /usr/src ; make world". Around an hour later (depending on your machine) you will have completely new binaries for the kernel, kernel modules, binaries, docs, etc.

    Bye bye rootkits, viruses, back doors and the like.
    • If someone has compromised root, all of your utilities are not what they seem. The install, cp, etc. are not the same. Make is not the same. A 'make world' will not fix this. The utilities will not replace themselves. A rootkit could even run at kernel level and simply update what fake file it has to show to monitoring software. Please read other comments before repeating what has been said (erroneously) several times already.
      • You missed the part about syncing your source tree to the master, before rebuilding the world. Please read an entire posting before replying to it.
        • If your system is compromised, nothing is trustable. Not the kernel, not the sync utilities (which on a FreeBSD system would be the first thing to alter), not anything. I did not miss the part about syncing to master. If there's a rootkit it will either make sure your sync still has its changes, or it will simply not install files silently. It could also modify your compiler to produce backdoors in your executables (For more on this one in particular, look at this http://www.acm.org/classics/sep95/ [acm.org]Turing Aw

  • Joke's on you, Linux boys (and girls?)!

    I don't have to worry about this. I use Windows!

    Oh wait...

    - RG>
  • The best way to detect a rootkit: post-install, hash the installed file-system files and kernel and save the results on a CD-R. Periodically, check to see if the hashes have changed. If so, you know where the problem lies.

The only thing cheaper than hardware is talk.

Working...