[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-security] chkrootkit keeps complaining about hidden processes
- Subject: Re: [cobalt-security] chkrootkit keeps complaining about hidden processes
- From: Michael Stauber <cobalt@xxxxxxxxxxxxxx>
- Date: Tue, 5 Mar 2002 09:54:48 +0100
- Organization: Stauber Multimedia Design
- List-id: Mailing list for users to address network security on Cobalt products. <cobalt-security.list.cobalt.com>
Hi Jelmer,
> I was thinking of some solution to these false alarms. This would require
> rewriting chkrootkit, so I can only suggest things. Maybe something like
> doing it process by process (recompare all the time).
Yes, it defenitely would need a rewrite of chkrootkit. Or at least of the
"chkproc" executable which does this comparance.
> Is this test really useful? False alarms are quite dangerous because people
> don't watch them anymore. So if there has never been any incident with
> hidden /proc entries, the test better be turned off????
It sure is a double edged sword - you're right about that. On a vanilla
system which hasn't been hardened before I'd certainly would like to run a
"quick and dirty" tool like chkproc to find out if there is anything hidden.
For me it'll remain a good tool for security audits, but just one tool out of
a few (never put all your eggs in one basket ;o).
More often than not chkrootkit has then uncovered a surprise or two. However,
the usuefulness of chkproc degrades once LCAP (and other security hardening
tools) have been installed, because by then almost all positive reports about
hidden processes you'll see will be false ones.
However, I run the full assorted toolbox comming with chkrootkit twice per
day on my machines and usually I get one false alarm per week. If I see it in
two successive runs I take a closer look under the hood and evaluate the
processes manually. But I should add that seeing it twice in a row is very
rare and it boils down to once in two months or around that figure.
--
With best regards,
Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer