APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Root Kit Hunter

© May 2006 Anthony Lawrence

I had a strange problem with one of my own RedHat machines the other day. Very simply, I couldn't su to root, and I couldn't even login at the console as root. I hadn't forgotten the password, but the system just wouldn't let me in.

As it happened, I didn't have time to deal with the problem right that moment (obviously I didn't urgently need root access right then) so I didn't get back to this till the next day. To my surprise, I was now able to login or su as I wished.

My immediate thought was "rooted!". But after a moments reflection I wondered "how?" I'm behind a firewall. I don't allow inbound traffic to ssh, telnet or anything else. I watch the blinking lights on the lan when machines are supposed to be quiet, and I disconnect the cable modem when I'm done for the day. I really doubted that this machine had been rooted.. but what the heck, might as well check.

RKHunter is a shell script hat runs on just about any Unixy OS from AIX to Solaris and even Mac OS X. That wide range of OS checking makes this a very useful tool to have on your machines.

But it turned up no problems. And indeed, I couldn't see any indication of even an attempted breech. I left the modem connected after hours and watched the lights on the lan for any activity; all was quiet. I downloaded other root kit checkers; they all said the system was clean. So what was going on?

Well, it was my own doing. I completely forgot that I had protected this system with pam_tally in addition to other things. I had mistyped my password twice and locked myself out. I reset that every hour during working hours, so it had cleared itself quickly, which is why I could log in the next day.

Still, it was a good thing. I had been lax and had not checked any of my systems for rootkits in quite a while. That's probably not a good idea. For example, RKHunter showed me that I had "PermitRootLogin yes" in one of my boxes sshd_config. That had been intended as a momentary convenience, but I had forgotten to take it out. SShd wasn't actually running on that box, so it really didn't matter, but I could have easily turned it on without checking the configuration. RkHunter looks for things like that and more.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Root Kit Hunter


Inexpensive and informative Apple related e-books:

Take Control of Parallels Desktop 12

Take Control of Upgrading to El Capitan

Are Your Bits Flipped?

iOS 10: A Take Control Crash Course

Take control of Apple TV, Second Edition

More Articles by © Anthony Lawrence

Thu May 18 03:07:42 2006: 2031   drag

Bah on rootkit hunter. :P

Well not realy. It's a convience more then a reliable thing.

Although a huge pain in the rear the only reliable way to detect root kits would require that you keep checksums of system utilities and then have the ability to check checksums independant from the OS.. like booted off of a cdrom or whatnot. The whole idea is to avoid using a kernel that may have a kernel module rootkit or use any system utilities or whatnot that may have been perverted by the root kit to hide the fact that you've been rooted.

That's were I think some virtualization stuff would be very cool. You can use Tripwire to do checksums on all files on your system, but using it in a secure way previously would be very difficult. You'd have to do things like be able to boot it off a cdrom after doing upgrades and save the checksums on a read-only volume or a very secure server or whatnot. Things like that. It's a pain, expensive, and requires extra downtime.

But if you have Xen (or equivilent) it should be easy because you should be able to easily access the storage of your 'real' server. You'd shutdown the virtualized server, run checksums check, then boot it back up from the Xen environment. All very quick and easy. Maybe even as LVM matures you'd be able to do snapshots or read-only mounts and such so that you can run checksums without having to take the server down.

Also you can do neat things like keep continious copies of log files. Also IDS systems like Snort would be easy to setup since the Xen host has access to the network before it reaches the hosted operating system running in the VM.

Since the virtualization is very complete then anybody taking over the client machine should have a fairly hard time noticing it and even if they did they wouldn't be able to break out of the vm environment, even with root access.

As long as you keep the DomO Xen host VERY VERY secure then it should work out great. The major downside is that the operating systems running inside the VM are always less secure then the operating system or hypervisor running the VM. This is because with XenLinux you have direct access to the file systems running in DomU. Same thing with Microsoft's Vserver stuff or the non-hypervisor versions of Vware server. If the Dom0 system gets rooted then everything running on that machine is trivially easy to hack into.

Thu May 18 16:50:11 2006: 2036   TonyLawrence

I can't disagree with anything you've said, Drag. It's been my intention to upgrade my main servers so that they can run Xen.. currently I can't, and the days seem to slip away. Probably the only thing that will get it done is if something crashes and burns.. in a way, it would have been good if I had been rooted - or thought I had been anyway.

Thu May 18 17:57:39 2006: 2037   anonymous

I can understand that. It seems like once you get something working it's much better to just leave alone (except for nessicairy security patches) otherwise it just ends up being very counter productive.

In the future though Xen should end up being pretty easy. Suse supports it by default, Fedora does (so thusly will Redhat). And my favorite, Debian, now has Xen packages aviable with it's Unstable version. The next stable version for that will hopefully be out by the end of the year (but considuring Debian's track record...).


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

The last bug isn't fixed until the last user is dead. (Sidney Markowitz)

Linux posts

Troubleshooting posts

This post tagged:




Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode