gpg: failed to create temporary file '/var/lib/lurker/.#lk0x57ab2100.hantslug.org.uk.27060': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Thu Feb 7 13:37:13 2008 GMT
gpg: using DSA key 019AD0D8166C4BF0
gpg: Can't check signature: No public key
On Thu, 07 Feb 2008 at 12:09:52PM +0000, Jon Fautley wrote:
> > > 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.
I did said "before you deploy", before the box has even left the
build room. That's also the time to take your checksum data and
store on a read-only medium. Ultimatly you have to trust something
and you your install medium/image has to be something you trust -
the checksums and signatures must match the vendor's, but you have
to trust that they haven't done anything.
> Any half-competent malware/rootkit author should be checking for the
> existance of chkrootkit and friends, and "patching" them as required...
One you suspect an intrusion you are quite correct, nothing on the
box is trustable. However, what makes you suspect an intrusion?
While these tools are not perfect and can be bypassed, they don't
hurt to put them in as part of the build proccess, as long as you
don't get too many false positives.
> > 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.
Given that it needs to use a shell, a compiler and runs as root,
I'd say that any of those commands/processes could also contain a
trap. The only safe way is to boot from a known-clean disk and do
the same.
> > 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 :)
The biggest problem you have is the wasted time from a false
positive. If it's a real intrusion, then reinstalling is as you
say the quickest and only safe way of bringing the box back.
--
Adam Trickett
Overton, HANTS, UK
This would of course be likely to trigger a real constitutional crisis,
but as this Government has done so much to destroy the constitution
already, it seems only reasonable for other people to be allowed to join in.
-- John Lettice, The Register 2006-01-17
