Re: Tripwire output on Solaris 2.7From: Neil Dickey (email@example.com)
- Previous message: Gary Mulder: "Re: Tripwire output on Solaris 2.7"
- Maybe in reply to: Simon Crowther: "Tripwire output on Solaris 2.7"
- Next in thread: McAllister, Andrew: "RE: Tripwire output on Solaris 2.7"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-Id: <200110121421.JAA29328@shiloh.geol.niu.edu> Date: Fri, 12 Oct 2001 09:21:53 -0500 (CDT) From: Neil Dickey <firstname.lastname@example.org> Subject: Re: Tripwire output on Solaris 2.7 To: email@example.com
Darren J Moffat <Darren.Moffat@eng.sun.com> wrote in part:
>> st_mtime: Thu Sep 20 15:12:35 2001 Tue Aug 28 17:48:56 2001
>> st_ctime: Thu Sep 20 15:12:35 2001 Tue Aug 28 17:48:56 2001
>> md5 (sig1): 0IwBXI:7wc0zkf6Fd.ZDz4 1WBpJzMF9qHs1S:hA7rVsd
>> snefru (sig2): 0tfIUuhOX:2WTXxljSXXO0 1aPZdiJ7sUTvwi1OWKYEwh
>Are you really sure you wnant tripwire checking itself because it will
>write to those files so they will always change.
But that is the database file, which shouldn't change unless the user,
or an intruder, runs Tripwire in 'initialize' mode. The md5 and snefru
signatures indicate that the *content* of tw.db_msxgbgw1 has changed,
and this shouldn't happen under normal operation. I have other ways of
verifying the integrity of my database and executable files, so cannot
say from experience whether mtime or ctime would be changed by running
tripwire against itself. I tend to think not, because it doesn't do that
to other files it checks. Otherwise, the database would have to be re-
initialized every time Tripwire was run.
If you look at the dates in the log extract, that modification happened
22 days ago, counting from today. That's a good long time, don't you
Neil Dickey, Ph.D.
Northern Illinois University