Re: [cobalt-security] Forensics on a hacked server

[Eugene Crosser <crosser@xxxxxxxxxxx>]

Thanks for sharing the experience, Michael!

On Wed, 2003-05-21 at 20:14, Michael Stauber wrote:

> My bottom line: Do you still trust chkrootkit? Think again.
> 
> It still is a useful tool, but without watching the filesystem for actual 
> changes (with Tripwire, FCHeck or similar tools) you might be coaxed into 
> believing that everything is fine when it is not.

kernel modules are nasty stuff.  You can hide processes/sockets without
any need to modify any binaries (that's why reinstalling binaries from
RPMs did not change anything in your case).  Thus, Tripwire would have
nothing to notice!  If the intruder keeps files in often-changing
directories that are not usually checked by tripwire, it's no more
useful than chkrootkit.  Theoretically, the intruder might even tidy up
his traces on the filesystem, and just leave one or more hidden
processes listening on hidden sockets.

On a system like Cobalt, with very little variation in hardware
configuration, it would make perfect sense to have monolithic kernel
without module support at all.  It would be much more difficult to get
inside unnoticed.  As a workaround, one could use a "module locker
module" - that, once loaded, would shut the module loading interface
until next reboot.  This can be loaded from an rc script immediately
after all legitimate modules are in place.  I think I've heard about
such thing (can anyone provide a pointer?).

A firewall (better external) could be an answer, too, barring the path
to the backdoor.

Eugene