Re: Tripwire output on Solaris 2.7

From: Gary Mulder (gary@cgen.com)
Date: 10/11/01 

Message-ID: <3BC602DD.BAF33523@cgen.com>
Date: Thu, 11 Oct 2001 16:36:45 -0400
From: Gary Mulder <gary@cgen.com>
To: Simon Crowther <SCrowthe@msxi-euro.com>
Subject: Re: Tripwire output on Solaris 2.7

Simon,

You need to examine the files that Tripwire has detected as changed. Most can
be attributed to normal file changes due to user activity and reboots. Unless
it's a permissions or ownership change, I usually ignore changes to special
files such as named pipes and devices.

For every non-special (ie. regular) file, you need to ask yourself: Did I or
someone on the system make a change to do something to cause a change in that
file on that date? If yes, then you're fine.

The one that I would really look at is /etc/oshadow, my (limited) understanding
is that when someone changes a shadow password field (eg. by using the passwd
command) /etc/oshadow is the backup made before the change is made. I don't see
/etc/shadow marked as changed, so this might be suspicious.

Note also that your Tripwire checking is only as secure as the Tripwire binary
and database. If they're editable by root then anybody who gets root on your
system can fake out Tripwire. At worst you need to manually checksum these two
files and store the checksum result off-computer (I think there's a util
provided with Tripwire called siggen that will do this for you). Somewhat
better is storing your binary and database on a read-only NFS share as well.
The ultimate best way to store them is to put them on a read-only mounted
write-protected floppy or CDROM.

I also keep multiple historic database copies so I can determine when
particular files changed on my system. This is very useful when you've got
multiple Admin's mucking with systems and changing things without documenting
their changes! 

-- 
Gary Mulder
System Administrator,
Compugen, Inc.
http://www.cgen.com