Re: preventing tampering with tripwire

From: Michael A. Williams (mike@netxsecure.net)
Date: 06/20/02


Date: Thu, 20 Jun 2002 18:31:07 +1200
From: "Michael A. Williams" <mike@netxsecure.net>
To: Maxlor <mail@maxlor.com>

Hi,

Maxlor wrote:
>
> After being rooted recently (no idea how it happened - I was following the
> SAs and whatnot... and yes, I already formatted and reinstalled), I decided
> to install tripwire, so I would be alerted to something like that sooner.

Good idea, check out Aide as well and then our signed_exec kernel
patches from http://www.trojanproof.org , as time allows and further
testing of the V2 code which is available as a beta only for OpenBSD 3.1
Release we will port the V2 code to FreeBSD 4.6 Release and stable
branch as well as current which extends cover from binaries and scripts
to KLD's and shared libraries. DO read our paper at
http://www.trojanproof.org/sigexec.pdf for an idea of what we are up to
and be sure to note that our original reference code checks binaries and
scripts only in a relatively simple and stable way that is very compute
expensive whereas the new V2 code does more and very efficiently.
 
> The thing installed fine and is running ok, there's just this one thing
> thats puzzling me:
>
> How do I prevent an intruder that somehow gains root on my machine from
> simply replacing the tripwire binary that always gives me an "everything
> ok" report?

Include the binary in your tripwire or aide checklist then do an md5 or
sha1 signature check of the database and have a human check this with a
copy kept off the system daily.
 
> I've been considering putting the binary on a floppy or CD, but then an
> intruder could simply unmount the disk and place the replacement binaries
> in the mountpoint dir.

Run the system in securelevel 2 to avoid raw access to the disk and
monitor the system log after each and every reboot.
 
> I'm currently running tripwire as a nightly cronjob, and I'd rather not
> resort to mounting a disk, running tripwire from it manually, then
> unmounting it. You know, my lazyness and the effort needed to do this would
> lead to me eventually no longer doing it...
>
> So, how did you solve this problem?

Combine security features relative to your risk and the cost in terms of
effort you are prepared to put in.

If I had more time I would be offering assistance with porting the cool
new systrace facility just integrated into the OpenBSD base system in
OpenBSD current see http://www.citi.umich.edu/u/provos/systrace -
someone please :)

Cheers,
Mike.
 

-- 
Michael A. Williams
Security Software Engineering and InfoSec Manager
NetXSecure NZ Limited, http://www.nxs.co.nz
Ph: +64.3.318.2973 Fax: +64.3.318.2975 Mob: +64.21.995.914
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message