On Monday 24 November 2003 04:13, Ben Stringer wrote:
> On Sat, 2003-11-22 at 12:39, Sam Barnett-Cormack wrote:
> > > What you should do against it is remove the server from the net, backup
> > > any data (avoiding executables) and reinstall. Then have everyone who
> > > ever used a password on the server change their passwords. Rootkits
> > > tend to install a backdoor for access (Eg. second sshd) and to replace
> > > common binaries (ls, ps) to hide their presence. chkrootkit can only
> > > find rootkits that have been sloppily constructed.
> >
> > Actually, chkrootkit will probably be able to find all but the best, as
> > long as the author keeps it up to date. It detects the common
> > modifications to binaries as well.
>
> I think chkrootkit is a great tool, but my point is it is only as good
> as the executable it is calling. If a rootkit replaced the "test"
> functionality of bash to always return false for the existence of the
> files making up the rootkit, suddenly that rootkit is invisible. I would
> consider any rootkit that replaces binaries, but neglexts to replace
> those binaries that can be used to detect it, sloppily written.
>
> It would be straightforward for a rootkit writer to examine all the
> tests done by chkrootkit and to replace each binary involved to render a
> newly created rootkit "invisible".
>
> Cheers, Ben
The new viruses can stop the old antivirus software, the new antivirus
software can stop the old viruses :) - normal situation.
If you want paranoid protection you can make an iso9660 partition/file,
'burn' modifyed chkrootkit + staticaly linked test/bash/whatever chkrootkit
needs and make sure your new pet will use only these external executables.
If you do something like chkrootkit-iso that also uses a normal chkrootkit
as decoy I'll probably happily install this one too ;)
btw: rpm -V should give you warnings for modified/replaced binaries.
--
Regards,
Doncho N. Gunchev
