🚀 go-pugleaf

sims@drake.mitre.org (Jim Sims) writes:

> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>find the root's version of tripwire and change it to *always* spit out the
>"don' worry, be happy message"....

...but it may not be '/etc/tripwire' or something so obvious.  What if
the admin put it in '/var/spool/mail/some-user' and changed the perms
so that it's not executable (harder to find).  You gonna poke through 
EVERY file on the system lookin' for it?  What're the chances you'll be
detected before you do?  :-)

-- 
Rich Holland              | INTERNET: holland@matt.ksu.ksu.edu
100 Jardine Terr, Apt A7  | BITNET  : holland@ksuvm
Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

(Mostly in response to comments by Jim Sims):

Actually, the documentation for Tripwire will recommend that it be
installed on a read-only disk or across a network on read-only media.
The program has been designed to work with read-only input and with
the program on read-only storage.  If the read-only attribute is set
in hardware, it is very, very difficult to "hotwire" the code or
database.

As far as frequency of operation, that is up to the sysadmin.  Many
alterations cannot be detected without something like this.  In some
cases (e.g., mounting file systems across a network), files can be
altered without any unauthorized login from occuring.  Tripwire will
find those kinds of access.  This will also find Unix viruses, if any
ever appear.

Tripwire doesn't run "diff" against the file contents.  It uses message
digests/cryptographic signatures on those files that the sys admin
chooses to sign.  If the sysadmin wishes to only check i-node contents
for selected files, then the signature is not performed.

A fair amount of careful thought went into the design of this.  I'm
certainly interested in hearing comments and criticisms, but it sure
would be helpful if people would wait until they know what it is they
are commenting on.  (But then, this *is* Usenet. :-)
-- 
Gene Spafford
Software Engineering Research Center & Dept. of Computer Sciences
Purdue University, W. Lafayette IN 47907-1398
Internet:  spaf@cs.purdue.edu	phone:  (317) 494-7825

holland@matt.ksu.ksu.edu (Rich Holland) writes:

>sims@drake.mitre.org (Jim Sims) writes:

>> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>>find the root's version of tripwire and change it to *always* spit out the
>>"don' worry, be happy message"....

>...but it may not be '/etc/tripwire' or something so obvious.  What if
>the admin put it in '/var/spool/mail/some-user' and changed the perms
>so that it's not executable (harder to find).  You gonna poke through 
>EVERY file on the system lookin' for it?  What're the chances you'll be
>detected before you do?  :-)

    You are right in pointing out that Tripwire is only as reliable
and secure as the database and Tripwire executable files.  Therefore,
putting these files on the local system where they can be tampered with
would be a bad idea.

    In the documentation for Tripwire, we suggest putting both the 
database and the Tripwire executable on a ``secure-server''.  For
instance, putting them on read-only media on a remote file-system
with the files accessed via read-only NFS would be prudent.

Gene
    
(genek@mentor.cc.purdue.edu)

Gene> == Gene Kim <genek@mentor.cc.purdue.edu> 

 Gene>     You are right in pointing out that Tripwire is only as
 Gene> reliable and secure as the database and Tripwire executable
 Gene> files.  Therefore, putting these files on the local system where
 Gene> they can be tampered with would be a bad idea.

<unlock SysAdm Cabinet>
<remove "special" floppy>
<insert "special" floppy>
mount -r /dev/fd0c /floppy
/floppy/tripwire

This is one possible way to do it on floppy-equipped systems (say, an
SS2 or IPX or whatever).  Maybe this should go in the docs?
--
Christopher Davis   | ]CALL -151       
<ckd@eff.org>       | *300: 20 DD FB 60
System Administrator| *3D0G            
EFF +1 617 864 0665 | ]CALL 768        

In article <sims.715743134@starbase> sims@drake.mitre.org (Jim Sims) writes:
>(buncha stuff about a utility to diff files as a security measure deleted)
>
> It seems to me rather useless and extremely CPU and I/O expensive to diff
>files as a security measure. 

Well, every little bit helps.  If I can run this thing once or twice per
week without melting my CPU or I/O controller, it's worth it.

>How ooften you gonna run this thing? Every 10
>minutes? What's the expected delta between logins that someone could be
>snagging passwords on your system? Seems like better control over changing
>the files is the answer rather than finding out afterwards....

In theory, you're absolutely right.  In reality, there will always be a
hole of which you are unaware.  I'd like to have something like Tripwire
"looking over my shoulder".

> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>find the root's version of tripwire and change it to *always* spit out the
>"don' worry, be happy message"....

Of course, that'll be hard to do if I keep the binary(ies) encrypted (or
on a Sun floppy)......8)

--Wes

-- 
MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu

>(buncha stuff about a utility to diff files as a security measure deleted)
>
> It seems to me rather useless and extremely CPU and I/O expensive to diff
> files as a security measure. 

I have written a shell script performing checks on inodes of files and
computing checksums over them. After coding that inode comparison stuff
in C, the script runs only for about 80 seconds depending on the systems
load to check about 1.300 files. And I really can't think of more than 1.300
files to watch on a BSD system.
So I don't expect Tripwire to take much longer.

Malte.

P.S.: The Machine is a Sun 4/470, serving 15 diskless clients and 5 Xterminals.

In article <1992Sep8.144541.2091@ms.uky.edu> morgan@ms.uky.edu (Wes Morgan) writes:
>In article <sims.715743134@starbase> sims@drake.mitre.org (Jim Sims) writes:
>>(buncha stuff about a utility to diff files as a security measure deleted)
>>
>> It seems to me rather useless and extremely CPU and I/O expensive to diff
>>files as a security measure. 
>
>Well, every little bit helps.  If I can run this thing once or twice per
>week without melting my CPU or I/O controller, it's worth it.

I run something like this nightly.  It checks UID, GID, mode bits, sizes,
creation and update times, and the checksum.  It has yet to find an
intruder, but then the system hasn't been broken into in 3 or 4 years now.

You'd be surprised how much idle CPU time you have at 2am ;-)
-- 
John F. Haugh II                   | "The US Government has the Midas Muffler
Ma Bell: (512) 251-2151            |  touch: everything they touch turns to
UUCP: ...!cs.utexas.edu!rpp386!jfh |  shit."
Domain: jfh@rpp386.cactus.org      |                  -- Jay Maynard