Tripwire - The Only Way to Really Know - Page 2

By Jay Beale | Posted Oct 17, 2000
Page 2 of 3   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn


Deploying Tripwire

Downloading and Compiling TW ASR 1.3.1

We'll now download and compile Tripwire 1.3.1 ASR. I've chosen the Academic Source Release for this article, for simplicity and because it's free for all platforms. I'll cover 2.x, later, as it does include a number of improvements. Everything we do here is extensible to version 2, though. So, first download the Academic Source Release from http://www.tripwiresecurity.com. You should end up with a file, named like: Tripwire-1.3.1-1.tar.gz. Next, untar it in a private directory, like /home/jay:

$ tar -xzf Tripwire-1.3.1-1.tar.gz
$ cd tw_ASR_1.3.1_src

Now, make sure to read the README file, which has lots of useful information. Once you're done, we can continue by editing include/config.h:. Change the following lines (lines 106 and 107 in my copy) to use directories within root:

#define CONFIG_PATH     "/usr/local/bin/tw"
#define DATABASE_PATH   "/var/tripwire"

to

#define CONFIG_PATH     "/root/tw"
#define DATABASE_PATH   "/root/tw/databases"

We'll change the Makefile too before compiling, changing lines 13 and 14:

DESTDIR = /usr/local/bin/tw
DATADIR = /var/tripwire

to

DESTDIR = /root/tw
DATADIR = /root/tw

Now, we'll compile and install. Make sure to do the last step as root.

# make
# make install
# cd /root/tw

We find the Tripwire files in /root/tw, including a great utility, siggen, which can generate signatures for any one file, like this:

# ./siggen -17 tripwire
sig1: md5      : 0PzZFU.NRuADv.IIWROXE8
sig7: sha      : 0kkeI7Cd9CkQ4vElcgLpcK7SDgA

Write these down! Someone could Trojan the tripwire binary! Let's now write a configuration file, so we can start using Tripwire.


Writing a "Quiet" Configuration File

First, we'll back up Tripwire's original tw.config.

# mv tw.config tw.config.orig

Now, we'll write our own configuration file. Be warned, though! Tripwire is a "noisy" Intrusion Detection System (IDS) when you try to watch the entire drive. "Noisy" IDSs tend to report too many false positives, though most can be tuned to be quieter. Tuning Tripwire mostly involves listing out exception files (or qualities) that tend to change often on your machine. Once you tune Tripwire to your machine, it will be quieter, but this does take work. Let's write the file - pay careful attention to the comments, as they explain rationale.

# "louder" tw.config for SecurityPortal.com article  jjb 
06/30/2000

# This file is a sample configuration file that you can use for a
# stock Red Hat 6.2 system, using Tripwire 1.3.1.

# REFERENCE CHART follows - each letter/number corresponds to a
# different quality of the file to watch.
#
#   p    - Permission and file type (mode)
#   i    - inode number (inode=entry in the filesystem)
#   n    - link count (number of hard links to the file)
#   u    - UID (owner of the file)
#   g    - GID (group owner of the file)
#   s    - size of file
#   a    - access timestamp (last time the file was accessed (RARELY 
USED!)
#   m    - modification timestamp (last time the file was modified)
#   c    - inode Change timestamp (last time the inode was modified)
#   0-9  - "signature" algorithm to use: 1=md5, 2=snefru, 
7=SHA-1
#   E    - Ignore everything 

#
# First, define a number of monitoring levels.
#

# Essential system binaries should be monitored on all attributes, 
with a
# high level of certainty.  We keep only md5 and SHA-1 for now.

@@define BIN E+pinugsmc17

# System logs should be allowed to change, and even to switch inode 
numbers.
# The inode modification is because of Red Hat's automatic log 
cycling.

@@define LOG E+pnug

# Device files should simply maintain ownership, permissions and such.
# It doesn't make sense to monitor contents.  We also ignore inode
# mod (c) because this changes every reboot.
@@define DEV E+pnug

# Essential system config files (/etc/fstab, /etc/hosts.allow) should
# be watched very closely.

@@define CONF E+pinugsmc17

# Most directories need to allow for new files to be added, so we
# won't watch size, mod time, changes to the inode, or compute sigs.

@@define DIR  E+pinug

#
# Main configuration starts here...
#

# Monitor the root directory itself, but don't recurse into it.
=/      @@DIR

# Monitor essential system binaries: libraries and programs.

/bin    @@BIN
/lib    @@BIN
/sbin   @@BIN
/usr    @@BIN

# Monitor the /boot directory, where the kernel et al. is stored.
# System.map changes inode and mod time on every reboot, so ignore
# these.

/boot                   @@BIN
/boot/System.map        @@BIN-mc

# Monitor /dev, the devices directory.

/dev    @@DEV

#
# Granularly, watch the system's config files...

/etc    @@CONF

# mtab holds current mounted volume information.  Usually, we should
# treat this as a log, since it must change.

/etc/mtab       @@LOG

# passwd and shadow will change on any system with many users, since
# you'll  be adding users regularly, changing your passwords...  If
# you're on a system with few users, watch /etc/passwd more closely.
# If you don't allow users to change passwords, watch /etc/shadow
# more closely.
#     ( Most people should leave this as is, unfortunately... )

/etc/passwd     @@LOG
/etc/shadow     @@LOG

# /home should change often.  We can simply watch the directory 
itself,
# but we have to allow for new directories to be created within.

=/home          @@DIR

# lost+found can be watched as a directory with no monitoring of 
contents

=/lost+found    @@DIR

# mnt contains the system mount points for CD-ROM, floppy,...  Barely
# watch this...

=/mnt           @@DIR

# The proc filesystem is special and changes a great deal.

=/proc          @@DIR

# /root is root's home directory.  We don't generally watch the 
contents,
# but you can choose to do this if you're careful enough when logging 
in
# as root.

=/root          @@DIR

# /tmp should change often and greatly.

=/tmp           @@DIR

# /var is difficult, as it contains logs, mail queues, and mailboxes, 
to
# name a few type of files.
#   1) The log directory is hard to watch, because of the log cycling.
#   2) The spool/cron should be watched.  We can watch very closely 
if we
#      are willing to disallow cron.
#   3) The spool/mail directory should only be watched for 
permissions, but
#      not for content, since mail files will be added with new users.

=/var                   @@DIR
/var/log                @@LOG
=/var/spool             @@LOG
/var/spool/cron         @@LOG
/var/spool/mqueue       @@LOG
/var/spool/mail         @@LOG
!/var/lock

OK, so we've created the config file. Let's use it!

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter