gpg: failed to create temporary file '/var/lib/lurker/.#lk0x583e4100.hantslug.org.uk.27404': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Thu Feb 7 12:09:52 2008 GMT
gpg: using DSA key 9111B5743CA26D44
gpg: Can't check signature: No public key
On Thu, 7 Feb 2008 11:36:48 +0000
Dr Adam J Trickett <adam.trickett@???> wrote:
> On Thu, 07 Feb 2008 at 11:01:06AM +0000, Jon Fautley wrote:
> > On Thu, 7 Feb 2008 08:55:43 +0000
> > Dr Adam J Trickett <adam.trickett@???> wrote:
> >
> > > Somepeople build an AIDE database then burn it to a read-only
> > > medium, and run off that. I use a combination of aide,
> > > check root kit, rootkit hunter, and tiger all available in Debian
> > > Etch.
> >
> > All excellent tools, but you should never install them from your
> > distributions repositories. If your system has been "rooted" then
> > just doing an "apt-get install chkrootkit" could mean your system is
> > grabbing a compromised package from another location. Additionally,
> > a "dpkg -i chkrootkit-blah.dpkg" could trigger the rootkit/malware
> > to replace critical parts of the package before they hit the
> > filesystem. Unlikely, but not impossible.
>
> Obviously you need to install them before you deploy your system,
> it is utterly pointless to install them after you think you system
> has been compromised!
Nope - that's not how it should be done. If you believe a box has been
compromised, you cannot trust any binaries or data on that system -
period.
Any half-competent malware/rootkit author should be checking for the
existance of chkrootkit and friends, and "patching" them as required...
> There is also some logic in having a dedicated live CD to inspect
> suspect systems, but as you need to do a reboot they are not
> practical for routine scanning.
Absoloutely. My normal "routine check" method is to pull down the
chkrootkit tarball from the website, check the sig, unpack, and run
from there - and delete it when I'm done. That way I can be "fairly
sure" that it's not been tampered with.
> > I know that chkrootkit is designed to be "standalone" - i.e.
> > download and run, no messing around with compilation/installation
> > for exactly this reason.
> >
> > For the same reasons, never use an "already installed/downloaded"
> > copy of these tools if you suspect you've been 0wn3d.
>
> Some people I know would quarantine a suspect box, deploy a
> replacement from a known good source. They would only be interested
> with the suspect system if there was data on it that wasn't backed
> up. If it held no data, then they'd just wipe the suspect box and
> re-deploy.
>
> The next question is, "You do have backups?" followed by, "Have
> your backups have been compromised...?"
Absoloutely - and if I even suspect that a system has been owned,
that's exactly what I'd do. There's little to no point attempting to
clean an infested box - the time and effort required is generally many
orders of magnitute more than just reinstalling from known good media
and restoring from backup. You can also never be 100% sure that you've
managed to scrape all the filth out :)
Cheers,
/j
--
Jon Fautley RHCE, RHCX email: jfautley@???
Senior Consultant cell : +44 7841 558683
Global Professional Services
Red Hat UK, 200 Fowler Avenue, Farnborough, Hampshire, GU14 7JP
