> -----Original Message----- > From: Michael Fratoni [mailto:[EMAIL PROTECTED] > # tripwire -m p -Z low /etc/tripwire/twpol.txt > Parsing policy file: /etc/tripwire/twpol.txt > Please enter your local passphrase: > Please enter your site passphrase: > ======== Policy Update: Processing section Unix File System. > ======== Step 1: Gathering information for the new policy. > ======== Step 2: Updating the database with new objects. > ======== Step 3: Pruning unneeded objects from the database. > Wrote policy file: /etc/tripwire/tw.pol > Wrote database file: /var/lib/tripwire/tuxfan.twd > > # rm -f /etc/tripwire/*.txt > ##(No need to leave text versions of config and policy files around) > > > Also, what is the best way to protect the tripwire files > themselves in > > case the system were to ever be compromised? i.e. copy the important > > files to a secure server and replace them on the original > server when > > you want to run tripwire? or copy them to a floppy disk? or ? > > Removable media or write protected media would be safest I suppose. > I leave mine on the machine and just compare them to known > good backups. > > > And which files would need to have copies made of them? I > would guess > > the tw.pol file and the *.twd files; is there any others? > > Plus tw.cfg as well as your site and local keys.
A couple of extra comments: 1) Select DIFFERENT passphrases for the site and local, and don't select the same passphrase as (for example) the root account or any other account you know. Select different local passphrases for every machine, too, and choose good passwords. 2) Either remove references in tw.pol to /var/log, or be prepared to run an update on the tripwire database regularly; DON'T do this via an automated method! I suggest at a minimum updating the tripwire database manually once a week. 3) There is a tripwire mailout capability; use it! It gives you a backup against changes to the tripwire database that would then be undetected. 4) You might want to insert a "trojan marker" into the tripwire database, something that you change on an a regular basis; for example, if you have /sbin/fortune >> /etc/motd as a cron job, CHECK /etc/motd; have a few discrete "trojan markers" to give you a verification that you are seeing valid tripwire output; if you don't see your trojan marker in the email report, your tripwire database was changed between the time the time that your cron job went off and when tripwire "verified" the database. In my case, I have a dozen little trojan markers, and have the first set to go ten minutes after tripwire checks the database; the rest are scattered throughout the day, and can give me (within a few hours) a good idea of when the database changed. If the database changed, and you didn't do it, you know you were compromised by someone who was trying to fool tripwire... 5)In the end, never fully trust the tripwire database; there are folks who have been able to crack a box slightly, and then update the tripwire database to conceal their tracks who haven't been paranoid (like I'm suggesting, see comment #1 for an easy method of hacking it). Be suspicious! Non suspicion is the first crack in the defense of your box. Bill Ward -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
