A reasonable approach. Finding evidence of break-in is of course more likely to be meaningful than finding no (real) evidence. I was mostly addressing the latter case, which is what we have been presented, so far. ("The password I think I used to use doesn't work" doesn't qualify as real evidence.)

I would be at least a little wary of false positives from chkrootkit scripts: If the thing gives its opinion that there's a rootkit installed, then adopt a usefully skeptical attitude, and examine the alleged rootkit for yourself. And of course don't forget that there's no reason an intruder would have to install a rootkit in the first place: Those are merely mechanisms to conceal the intruder's on-system activity, which many intruders just don't bother with in the first place.

And there's good reason to beware of false negatives, as well: You're running a system-checking script on a suspect system, and you're willing to trust the results? Really? Does the script use only executables provided with it, and none of the system's own? Do any of the executables invoke (necessarily suspect) system libraries? Did you use any (necessarily suspect) system tools to gain access to the script? And you trust that none of those system facilities would be so evil as to interfere with the system-checking script?

As I said, checking the state of a running system that you suspect of root compromise is a non-trivial problem. Throwing chkrootkit scripts at it doesn't make the obstacles go away.

Real forensics get run from altnerate boot media, never trusting (and never running) any binary, library, or configuration file on the suspect system.

Rick Moen
rick@linuxmafia.com