Slashdot Log In
Detecting Rootkits In GNU/Linux
Posted by
kdawson
on Mon Dec 18, 2006 04:19 PM
from the watching-your-back dept.
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
ifl (Score:3, Informative)
Re:ifl (Score:5, Informative)
Parent
Re:ifl (Score:5, Funny)
Parent
Re:ifl (Score:4, 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.
Parent
Ah! No need for rootkit detector... (Score:5, Funny)
Pish Posh (Score:5, Funny)
Yes, but... (Score:5, Funny)
Parent
Read Only Drives (Score:5, Interesting)
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:
etc
Would have to always be on a read-write drive.
But having things like
What do you think? Feasible or impractical?
Re:Read Only Drives (Score:5, Informative)
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
Parent
Re:Read Only Drives (Score:5, Insightful)
# 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
Parent
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.
Re: (Score:3, Informative)
Re:Read Only Drives (Score:5, Interesting)
Amazingly enough, I can draw on 25 year old experience on this one, sort of. Back in the early 1980s, I ran a BBS on a dialup TRS-80. The floppy drives, I put toggle switches on the front of so the read-only setting could be changed on the fly. So worst case, it'd be something you might be able to put an external switch for that jumper, outside the drive case. Maybe. Might blow up but at the time it worked great.
Parent
Re: (Score:3, Insightful)
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
I like to leave this up to the FBI (Score:5, Funny)
I've always wondered... (Score:4, Interesting)
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")
Meh, I don't trust those tools (Score:5, Funny)
chkrootkit (Score:3, Informative)
Searching for OBSD rk v1...
Searching for suspicious files and dirs, it may take a while...
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
Re:This is... (Score:5, Informative)
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!
Parent
Re:This is... (Score:5, Interesting)
Parent
Re:This is... (Score:5, Interesting)
Parent
Compiler is Irrelevant (Score:4, Informative)
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.
Parent
Re:Compiler is Irrelevant (Score:5, 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.
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.
Parent
Re:This is... (Score:4, Funny)
Parent
Re:trojan the detector (Score:4, 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.
Parent