Detecting Rootkits In GNU/Linux

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

Comments

Re:This is...

[psycho8me]

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.

Read Only Drives

[DigitalRaptor]

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?

Re:Read Only Drives

[djh101010]

Right, but now if you want to install a program or security update you have to power off, change jumper, power on, install, power off, reset jumper, power back on. This may or may not be worth it, particularily in the case of a security update.

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.

Re:This is...

[seifried]

Does root have access to /proc/kcore? If yes then an attacker with root access can modify the kernel in memory as needed. Heck there's even projects to bring this into the mainstream for carrier grade Linux (no need for those pesky reboots after a kernel upgrade): http://pannus.sourceforge.net/

I've always wondered...

[sootman]

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