Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Dec 1998 07:58:22 -0500
From:      Charles Reese <reese@chem.duke.edu>
To:        freebsd-security@FreeBSD.ORG
Subject:   Re: tripwire was Re: append-only devices for logging
Message-ID:  <1.5.4.32.19981211125822.006d10e8@chem.duke.edu>

next in thread | raw e-mail | index | archive | help
At 09:42 PM 12/10/98 -0600, you wrote:
>James Wyatt rambled again:
>>reboot? If I wanted to erase my tracks (and thought you might not know I
>>was there or wanted to hide how long I'd been there), I could tamper with
>>scripts to kill logs next bringup. <PLUG>Tripwire(tm) is nearly perfect
>>for watching rc.* changes and such.</PLUG> Many of us just take the 
>>machine down, go '-s', blindly run our single-user-mode-admin-scripts, 
>>and go multiuser.
>
>On Thu, 10 Dec 1998, Charles Reese wrote:
>> Can tripwire be modified to compare two databases rather then one data base
>> and the current files?  I ask because I monitor some systems remotely and I
>> would like to be able to automatically generate a tripwire database on the
>> remote system, ftp it to my local site and compare it with a previously
>> created database that I have stored here on read-only media.  It is not
>> possible for me to use read-only media on the remote machine.
>
>This is a *great* idea! I had set the BIOS to boot w/o floppy and written 
>the DB to a floppy I changed to R/O by hand. This has a limit of 1.44MB 
>or 2.88 MB, depending on how much you spend for a floppy drive. I guess a 
>zip disk would work too, but I was given a parallel zip which seems to be 
>unsupported on FreeBSD. 8{(
>
>btw: You might implement this with something that, when called by the
>right host, performed a tripwire scan and dumped it back to the calling
>host. The calling host need not *receive* connects, just return the data. 
>Of fourse, a cracker might just replace the program with one that returned
>the 'right' result, rather than perform the scan... I guess you could also
>replace the tripwire executables, but how do you protect tripwire from
>modification? I knida miss the drives on my old Tandy 6000 that I could 
>write-protect by hand! - Jy@
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-security" in the body of the message
>
>
I like the 'call' idea; as far as the tripwire executable goes I could put
that on read-only (floppy) media on the remote machine.  The problem I have
isn't the lack of read-only media it is that I am in the US and the machines
are in England.  It's a long reach to change the floppy :-).  I guess my
broader question is how 'secure' can an internet server be?  I don't think I
can make mine 'full proof' but I would like a 'full proof' scheme that would
let me know when I've been compromised.  As the tripwire approach (MD5 etc.)
seems to be pretty solid it seems to boil down to how do you prevent
tampering with it and at the same time keep the machine maintainable without
having to go to single user mode?

Cheers
Charlie Reese
One Unix to Rule them all, One Resolver to Find them,
One IP to Name them all, In the Zone that Binds them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1.5.4.32.19981211125822.006d10e8>