Tripping Up the Bad Guys

Sandor W. Sklar

$Id: tripwire-aix.html,v 1.20 2001/11/27 21:39:23 ssklar Exp ssklar $

Introduction

Should I take this tutorial?

This tutorial is designed for administrators of IBM RS/6000 systems who seek a reliable method of monitoring changes to, and ensuring the integrity of files on the AIX systems that they are responsible for.

Step-by-step instructions are provided for compiling, configuring and deploying the free Academic Source Release version of the Tripwire security tool on IBM RS/6000 systems running AIX.

About the examples

The system used for the examples in this tutorial is an IBM RS/6000 700-C10 Compact Server, with AIX 4.3.3 Maintenance Level 8 installed upon it. This example system has the hostname "earth", and is part of a network of RS/6000s; the other systems are named "mars", "mercury", and "venus".

About the author

Sandor W. Sklar is a UNIX Systems Administrator at Stanford University, in Northern California,

The design of Tripwire

The need for file integrity

It is probably obvious to most system administrators that the single most important part of a computing environment is data. Whether that data consists of databases, plain text files, images, or anything else, without that data, the value of the service provided by a computer drops to zero. Understanding that concept makes clear that accessing, modifying, and deleting that data is one of the more popular goals of system crackers and other network-dwelling ne'er-do-wells.

Knowing about any changes to the data and other critical files on a system is imperative to ensure the integrity of the information and services provided by any system. The large number of files involved in a system, though, increases the difficulty of monitoring for changes. Often, it is impossible to answer questions such as: "Where did that file go?", "When was this configuration changed?", and "How long has this program been here?" Being able to answer those questions is perhaps the most important task of a system administrator.

Enter Tripwire

Tripwire was developed in 1992 as a free application, by Gene H. Kim and Eugene Spafford, at Perdue University. It use quickly spread, making Tripwire one of the most widely deployed and used security tools for UNIX Systems ever developed. For the first time, a self-contained application, portable and usable on many different varieties of UNIX, made the task of protecting critical files easy and virtually uncrackable

Over time, Tripwire underwent numerous changes in its operation and reliability, and 1999, Perdue University transferred the exclusive rights to the distribution of the Tripwire application to a commercial entity, Tripwire Security Systems, Incorporated (TSS). In doing this, the growth, development, and support of Tripwire was greatly enhanced, and the number of platforms that Tripwire can be deployed upon has multiplied.

As a service to the community, TSS has made available the last free version of Tripwire, designated the "Academic Source Release", version 1.3.2 (ASR). Though development and support for this release is not available from Tripwire Security Systems, Tripwire ASR remains a valuable and useful tool for insuring the integrity of the files on UNIX systems.

What does Tripwire do?

As described in the User Manual, "Tripwire is a file integrity assessment tool, a utility that compares a designated set of files and directories against information stored in a previously generated database. The utility flags all differences, including added or deleted entries."

In short, Tripwire provides the system administrator assurance that there has been no unauthorized changes, deletions, or additions to the files on a system. By running Tripwire on a regular basis, any of the aforementioned violations will generate a report with the details of any changes made.

The following diagram, taken from the designdoc.ps file included in the Tripwire source distribution, illustrates the high-level operation model of the Tripwire application:

[Note to Editor: the above graphic was copied directly from a document included in the Tripwire distribution. For copyright reasons, it may be necessary to recreate the graphic, with the same content but in a different style.]

Compiling Tripwire

Prerequisites

The source for Tripwire can be built using the GNU gcc compiler or the IBM C for AIX compiler. There is, however, a dependency on the use of "flex", the "fast lexical analyzer generator", available for download in source form at <ftp://ftp.gnu.org/non-gnu/flex/flex-2.5.4a.tar.gz>. Compiling tripwire will fail if the standard AIX "lex" is used.

To build flex, download and decompress the source distribution into /usr/local/src, cd into the flex source directory, and issue the commands:

./configure && make test

When the above actions complete, the last lines written to the display will be similar to:

./flex -t -p  ./scan.l  | sed s,\"./scan.l\",\"scan.l\",  | diff scan.c -
Check successful, using COMPRESSION=""
Target "test" is up to date. 

Downloading the source

The latest "Academic Source Release" version of Tripwire can be downloaded from <http://www.tripwire.com/files/downloads/asr/Tripwire-1.3.1-1.tar.gz>. The manual, in Adobe PDF format, can be retrieved at the URL <http://www.tripwire.com/files/downloads/asr/Tripwire-1.30-docs.pdf>.

After downloading the source distribution and saving it into /usr/local/src, decompress the contents of the tarball. The following directory its contents should be similar to:

$ ls -l tw_ASR_1.3.1_src

-rw-r-----   1 ssklar  wheel   2201 May  4  1999 COAST.info
-rw-r-----   1 ssklar  wheel  23945 May  4  1999 Changelog
-rw-r-----   1 ssklar  wheel   5441 May  4  1999 FAQ
-rw-r-----   1 ssklar  wheel   4076 Nov 25 08:56 Makefile
-rw-r-----   1 ssklar  wheel   4441 May  4  1999 NEWS
-rw-r-----   1 ssklar  wheel  12167 May  4  1999 Ported
-rw-r-----   1 ssklar  wheel  40285 May  4  1999 README
-rw-r-----   1 ssklar  wheel  20370 May  4  1999 Whatsnew
drwxr-xr-x   2 ssklar  wheel   2048 Nov 25 08:51 configs
drwxr-xr-x   2 ssklar  wheel   1024 Nov 20 14:35 contrib
drwxr-xr-x   2 ssklar  wheel   1024 Nov 23 15:35 docs
drwxr-xr-x   2 ssklar  wheel   1024 Nov 25 08:50 include
drwxr-xr-x   2 ssklar  wheel   1024 Nov 20 14:35 lib
drwxr-xr-x   2 ssklar  wheel   1024 Nov 20 14:35 man
drwxr-xr-x  10 ssklar  wheel   1024 Nov 20 14:35 sigs
drwxr-xr-x   2 ssklar  wheel   1024 Nov 20 14:35 src
drwxr-xr-x   3 ssklar  wheel   1024 Nov 20 14:35 tests
drwxr-xr-x   2 ssklar  wheel   1024 Nov 20 14:35 util

Compile-time decisions and Makefile modifications

Before starting the compilation, several changes to files in the source distribution will need to be modified. Some of these changes are required for successful compilation, as the last modifications to the Academic Source Release were made in 1998, before AIX 4.3.3 was available. Other changes reflect the standards for locally-installed software implemented at your data center.

For this tutorial, it is assumed that all security-related local software will be installed into subdirectories of "/usr/sec", and that only root and members of the system group have access to the contents of that directory.

Open the top-level "Makefile" in an editor (after making a backup copy), and make the following changes and the line numbers indicated:

DESTDIR = /usr/local/bin/tw

DESTDIR = /usr/sec/tw/bin

DATADIR = /var/tripwire

DATADIR = /usr/sec/tw/db

MANDIR  = /usr/man

MANDIR  = /usr/local/man

LEX     = lex

#LEX     = lex

#LEX     = flex

LEX     = flex

#CC      = cc

CC      = cc

CC      = gcc

#CC      = gcc

CFLAGS  = -O

CFLAGS  = -O -qmaxmem=-1

Open the file "include/config.h" in an editor (after making a backup copy), and make the following changes at the line numbers indicated:

#include "../configs/conf-svr4.h"

#include "../configs/conf-aix.h"

#define CONFIG_PATH "/usr/local/bin/tw"

#define CONFIG_PATH "/usr/sec/tw/config"

#define DATABASE_PATH "/var/tripwire"

#define DATABASE_PATH "/usr/sec/tw/db"

#define DEFAULTIGNORE   "R-23456789"

#define DEFAULTIGNORE   "R-2345689"

Change into the "tests" directory, and issue the following commands:

mv test0.key test0.key.orig
grep -v sha test0.key.orig > test0.key

mv test0.sh test0.sh.orig
sed s/-h/-h012345689/ < test0.sh.orig > test0.sh

Compiling and installation

After saving the changes made to the above files, execute the make command from within the tw_ASR_1.3.1_src directory. When the compilation completes, the last lines displayed on the screen will be similar to:

cc -O -qmaxmem=-1 -ldl -o siggen siggen.c ../sigs/md5/md5wrapper.o ../sigs/md5/md5.o ../sigs/snefru/snefru.o ../sigs/crc32/crc32.o ../sigs/crc/crc.o ../sigs/md4/md4.o ../sigs/md4/md4wrapper.o ../sigs/md2/md2.o ../sigs/md2/md2wrapper.o ../sigs/sha/sha.o ../sigs/sha/shawrapper.o ../sigs/haval/haval.o ../sigs/haval/havalwrapper.o nullsig.o utils.o
Target "all" is up to date.

Now issue the command make test to run the test suite. When the testing finishes, execute the following commands to set up the proper directory structure and install the files into their places:

mkdir -p /usr/local/man/man5 /usr/local/man/man8
mkdir -p /usr/sec/tw/bin /usr/sec/tw/db /usr/sec/tw/config
cp src/tripwire src/siggen /usr/sec/tw/bin
cp man/tw.config.5 /usr/local/man/man5
cp man/*.8 /usr/local/man/man8
chown -R root:system /usr/sec/tw
chmod -R o-rwx /usr/sec/tw

Creating the configuration file

Understanding the tw.config file

Tripwire performs its monitoring of directories and files based on the contents of its configuration file, defined at compile-time as /usr/sec/tw/config/tw.config. Each entry in the tw.config (excluding comments, indicated by lines beginning with a pound sign, and blank lines) specifies the following items:

[! or =] [directory or file] [select-flags or template] [# optional comment]

Pruning filesystem objects

The first part of an entry is optional, An exclamation point ("!") at the beginning of an entry signifies an "inclusive prune"; Tripwire will remove the item from its list of files to be scanned. If the "!" is listed on a line that specifies a regular file, it will not be monitored for any changes. If the entry with the "!" is a directory, tripwire will not monitor the directory for any changes, nor will it descend into that directory and examine any of its contents.

If the first character of a tw.config entry is an equal sign ("="), Tripwire will do an "exclusive prune" on the specified object. If the object is a directory, Tripwire will report on changes to the directory itself, but will not descend into the directory. The equal sign has no effect if it is used with a regular file.

The object specification

The second part of a tw.config entry is required; it specifies the filesystem object (file or directory) to be monitored by Tripwire. If the entry specified is a directory, Tripwire will descend into that directory and monitor all of its contents, unless specific items have been pruned. Note, though, that Tripwire will not cross a filesystem boundary: If /usr/local is a separate filesystem, an entry for the /usr filesystem will not direct Tripwire to monitor the objects within /usr/local.

For that reason, it is a good idea to organize the tw.config file in "stanzas", each responsible for the monitoring of a filesystem.

Attributes and signatures

The third part of a tw.config entry specifies what attributes and signatures Tripwire will monitor for the specified filesystem object. The available attributes are:

p

i

n

u

g

s

a

m

c

In addition to the numerous attributes available for monitoring, Tripwire also records the "signature" of file objects and reports if that signature changes. This feature is one of the more valuable functions of Tripwire; it is often possible to replace filesystem objects without modifying the attributes mentioned earlier, but it is extremely difficult, if not impossible, to replace an object and not change its signature.

The following table lists the different methods of generating signatures. Some of the algorithms available have been "defeated",meaning that it is possible, though difficult, to change an object without changing its signature; others are considered "unbreakable", but may be computationally expensive to have performed on a large number of files regularly.

0

1

2

3

4

5

6

7

8

9

When determining which signatures to use on a given object, speed an security must be balanced. If tripwire will be run on a frequent basis, two or three of the "quicker" algorithms might be a better choice than one or two of the more secure, but slower methods. Conversely, if Tripwire will be run only once or twice a day, the benefit of the slower but better proven algorithms might outweigh the time consideration.

Defining templates

Instead of specifying the attributes and signatures to be monitored for each entry in the tw.config file, a template can be defined. Templates are like macros, and are expanded by Tripwire at run-time. The following predefined templates are available:

R

+pinugsm12-ac3456789

L

+pinug-samc123456789

N

+pinugsamc123456789

E

-pinugsamc123456789

>

+pinug-samc123456789

To define a template, use the following syntax:

@@define [template_name] [select_flags]

For example, to define the template named LOG, which will monitor the permissions, hard-link count, UID and GID, but perform no signature checking, add the following line to the tw.config file:

@@define LOG +pnug-isamc0123456789

To use the template for the file "/var/adm/sulog", the entry in the tw.config would be:

/var/adm/sulog @@LOG

A basic configuration file for AIX

The following example configuration file defines several templates, and configures Tripwire for the monitoring of the five standard AIX filesystems: "/", "/usr", "/var", "/tmp", and "/home". If this tw.config file is going to be used with your systems, any additional filesystems must be added to the configuration, or they will not be monitored.

[Note to Editor: I suggest that the contents of the tw.config file presented below be available as a separate file, with a "download to disk" link.]

########################################################################
## /usr/sec/tw/config/tw.config                                       ##
## ------------------------------------------------------------------ ##
## Tripwire 1.3.2-ASR configuration file for AIX 4.3.3 filesystem     ##
########################################################################


##====================================================================##
## Define templates for monitoring filesystem objects                 ##
##====================================================================##

# STD  
#
# The "default" monitoring level, for scripts, binaries, and other
# objects whose attributes and signatures should NEVER change. Any 
# system configuration files that are monitored at this level will be
# reported any time their contents change.
#     
# The attributes to be monitored are:
#
#   p : permissions and file mode
#   i : inode number
#   n : hard-link count
#   u : UID
#   g : GID
#   s : file size
#   m : modification timestamp
#   c : inode change timestamp
#
# The signatures that will be generated are:
#
#   1 : MD5
#   2 : Snefru
#   4 : CRC-16

@@define STD +pinugsmc124-a0356789

# LOG
#
# The monitoring level for log files; the size of the file is expected
# to change frequently, along with the modification time.  The inode
# number and inode change timestamp will also change with rotation.
#
# The attributes to be monitored are:
#
#   p : permissions and file mode
#   n : hard-link count
#   u : UID
#   g : GID
#
# No signatures will be generated for log files

@@define LOG +pnug-samc0123456789

##====================================================================##
## Filesystem object entries go here.                                 ##
##====================================================================##

#-----------------------------------------------------------------------
# "/", the root filesystem (/dev/hd4)
#-----------------------------------------------------------------------

# the filesystem mountpoint, its contents, and the contents of all of
# its subdirectories (but not the contents of other filesystems or of
# symbolic links to other directories) ...

/                           @@STD

# but handle these files and directories differently ...

/.sh_history                @@LOG
/.profile                   @@LOG
/smit.log                   @@LOG
/smit.script                @@LOG
/etc/utmp                   @@LOG
/etc/sendmail.st            @@LOG
/etc/sendmail.pid           @@LOG
/etc/syslog.pid             @@LOG
/etc/security/lastlog       @@LOG
/dev                        @@LOG

=/dev/.SRC-unix             @@LOG  # ignore contents of directory

#-----------------------------------------------------------------------
# the /usr filesystem (/dev/hd2)
#-----------------------------------------------------------------------

# the filesystem mountpoint, its contents, and the contents of all of
# its subdirectories (but not the contents of other filesystems or of
# symbolic links to other directories) ...

/usr                        @@STD

# but handle these files and directories differently ...

=/usr/idebug/temp           @@STD  # ignore contents of directory

=/usr/local/src             @@STD  # ditto

#-----------------------------------------------------------------------
# the /var filesystem (/dev/hd9var)
#-----------------------------------------------------------------------

# the filesystem mountpoint, its contents, and the contents of all of
# its subdirectories (but not the contents of other filesystems or of
# symbolic links to other directories) ...

/var                        @@STD

# but handle these files and directories differently ...

=/var/tmp                   @@STD  
/var/locks/LCK..cron        @@LOG

# treat the contents of /var/adm as log files ...

/var/adm                    @@LOG

# except for these items ...

/var/adm/ras/errtmplt       @@STD
/var/adm/ras/bosinst.data   @@STD
/var/adm/ras/image.data     @@STD
/var/adm/ras/codepoint.cat  @@STD

# treat all of the contents of the following directories
# as log files ...

/var/dt                     @@LOG
/var/ncps/log               @@LOG
/var/news                   @@LOG
/var/spool/lpd              @@LOG
/var/spool/uucp             @@LOG
/var/tmp                    @@LOG

# ignore the contents of these directories ...

=/var/perf/tmp              @@LOG
=/var/preserve              @@LOG
=/var/spool/calendar        @@LOG
=/var/spool/lpd/stat        @@LOG
=/var/spool/mail            @@LOG
=/var/spool/mqueue          @@LOG
=/var/spool/qdaemon         @@LOG

#-----------------------------------------------------------------------
# the /tmp filesystem (/dev/hd3)
#-----------------------------------------------------------------------

# The filesystem mountpoint will be monitored, but its contents will
# be ignored ...

=/tmp                       @@STD

#-----------------------------------------------------------------------
# the /home filesystem (/dev/hd1)
#-----------------------------------------------------------------------

# the filesystem mountpoint will be monitored, but its contents will
# be ignored ...

=/home                      @@STD

########################################################################

Be sure to add any additional filesystems that should be monitored, as well as adding and pruning entries specific to the system that Tripwire is being deployed upon, and then save the file into the /usr/sec/tw/config directory as tw.config.

Using Tripwire

Initializing the database

The first action for Tripwire to perform is to initialize its database. Enter the following commands as root to create the initial database:

cd /usr/sec/tw/
./bin/tripwire --initialize

The initialization of the database can take considerable time, depending on the number of files within each filesystem to be scanned and the signatures being generated for each file.. On an RS/6000 7009-C10, the initialization of the database took 43 minutes to scan 50,513 files and directories, using the configuration file above.

When the database initizilation is complete, the following output will have been printed to the display:

Tripwire(tm) ASR (Academic Source Release) 1.3.1 
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Warning:    creating ./databases directory!
###
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database
###
### Warning:   Database file placed in ./databases/tw.db_earth.
###
###            Make sure to move this file and the configuration
###            to secure media!
###
###            (Tripwire expects to find it in '/usr/sec/tw/db'.)

Tripwire will always create the database named tw.db_hostname, in a subdirectory of the current directory named "databases".

Running the scans

After creating the initial database, Tripwire can be used to scan the system for objects that have been added, deleted, or changed. Before starting this scan, though, the database file must be moved into the /usr/sec/tw/db directory. The path to the database file is hard-coded into the Tripwire binary; it is recommended, but not required, that this directory be made read-only, via a hardware setting or a mount option. For these examples, though, the database directory is a part of the normal filesystem.

To move the database, run the following command:

mv ./databases/tw.db_earth ./db/

/usr/sec/tw/bin/tripwire [ --ignore # or 'all' ] [ --quiet ] [ --verbose ] 

Those optional arguments specify:

• --ignore #

  When Tripwire is configured to generate and check a number of signatures for each file it encounters, the time necessary to complete the scan might be excessively long. Specifying the "--ignore" option with the numbers of one or more signatures as the arguments tells Tripwire to skip the calculation of that signature for this scan.

• --quiet

  Normally, Tripwire will print a block of several lines for each inconsistency it detects, detailing the object, the attributes that it expected to find, and the differences in attributes that were detected. Specifying the "--quiet" option reduces this information block to a single line.

• --verbose

  When the "--verbose" option is specified, Tripwire will list each file processed as the file is scanned. This may be useful for fine-tuning the configuration file, or debugging a problem, but the output generated can be voluminous.

For this example, Tripwire will be run in integrity-checking mode after the installation of several filesets comprising the Tivoli Storage Manager (TSM) backup-archive client. To reduce the amount of time the scan will take, all signatures will be skipped; only attributes will be compared to the previous state. To start the scan scan, enter the command:

bin/tripwire --ignore all

When the scan is complete, the following output will be printed to the display (note that portions of the output have been removed):

... output deleted ...

### Phase 4:   Searching for inconsistencies
###
###                     Total files scanned:            50652
###                           Files added:              141
###                           Files deleted:            0
###                           Files changed:            43
###
###                     Total file violations:          184

The above block of text indicates the number of "violations" detected by Tripwire: files that have been added, deleted, or changed since the generation of the database. After the above summary, Tripwire will display a single line for each added, deleted, or changed file:

... output deleted ...

added:   drwxr-xr-x root         1536 Nov 26 17:15:19 2001 /usr/lpp/tivoli.tsm.client.ba.aix43.32bit
added:   -rw-r--r-- root           39 Nov 26 17:14:08 2001 /usr/lpp/tivoli.tsm.client.ba.aix43.32bit/.cr.status
added:   drwxr-xr-x root          512 Nov 26 17:15:18 2001 /usr/lpp/tivoli.tsm.client.ba.aix43.32bit/deinstl

... output deleted ...

changed: -rw-r--r-- root        32768 Nov 26 16:53:35 2001 /etc/objrepos/CuDvDr
changed: -rw-rw-r-- root         8192 Nov 26 17:06:25 2001 /etc/objrepos/SWservAt
changed: -rw-rw-r-- root         8192 Nov 26 17:06:25 2001 /etc/objrepos/SWservAt.vc

... output deleted ...

Following the list of violations, a block of text for each changed item will be displayed, detailing the points of inconsistency. Each attribute that has changed will be reported, as described in the following table:

st_mode

p

st_ino

i

st_nlink

n

st_uid

u

st_gid

g

st_size

s

st_atime

a

st_mtime

m

st_ctime

c

sig[0-9]

0 - 9

Note that, because the checking of signatures was skipped, there will be nothing indicated for those signatures, even if they have changed. Tripwire will print the following header block, and then a block of text for each violation.

### Phase 5:   Generating observed/expected pairs for changed files
###
### Attr        Observed (what it is)         Expected (what it should be)
### =========== ============================= =============================

The following block is an example of a file that has changed:

/usr/lib/objrepos/product.vc
       st_size: 167936                        163840                        
      st_mtime: Mon Nov 26 17:15:39 2001      Mon Nov 26 06:27:19 2001   

For the file listed, /usr/lib/objrepos/product.vc, Tripwire indicated that the size and the time of the last modification of the file had changed since that file was added to the Tripwire database.

Handling changes and inconsistencies

When Tripwire executes an integrity-checking scan, objects that are found to be in violation are not recorded in the database; until the Tripwire database is updated, those items will continue to be reported as inconsistent. There are three ways to reconcile the current state of the filesystem objects with that state recorded in the database.

• Generate a new database.

  Though this method entails the greatest usage of system resources, generating a new Tripwire database is the easiest method of ensuring that the current state of the filesystems is reflected in the database. To generate a new database, first make a backup of the existing database, and then run the same commands executed earlier to generate the database. Since Tripwire will again examine each item within each filesystem (subject to "pruning" defined in the tw.config file), and will regenerate any signatures specified by the configuration, this process will most likely take as long to complete as the initial database generation.

• Update the database interactively

  If the administrator is available to monitor the integrity-checking scan, add the --interactive flag to the tripwire command. When run in this mode, Tripwire will report on all added, changed, and deleted files, as in the standard integrity check mode The user will then be prompted for each detected violation:

  added:   drwxr-xr-x root         1536 Nov 26 17:15:19 2001 /usr/lpp/tivoli.tsm.client.ba.aix43.32bit
  ---> File: '/usr/lpp/tivoli.tsm.client.ba.aix43.32bit'
  ---> Update entry?  [YN(y)nh?] 

  If the user presses 'enter', or types y, the database entry for the object will be updated. Entering a capital Y will update the database for that object and all others that are reported as inconsistent. Typing n will skip the update for that object, and typing N will skip all remaining objects (essentially canceling the database update at that point.)

• Automated update of database entries

  This method is most useful when Tripwire scans are being performed via an automated mechanism, without human intervention. Specifying the --update flag, with the path to the inconsistent. object as the argument, Tripwire will update the appropriate entry in the database.

bin/tripwire --update /usr/lpp/tivoli.tsm.client.ba.aix43.32bit

The easiest way to update the database entries for a number of objects is to process the output of the integrity scan, extracting lines that specify added, deleted, and changed files, and pulling the path and name of the object from that output. The following commands present one possible method of accomplishing the described process:

# run the integrity-check scan, directing the output to the file /tmp/twscan.out ...

bin/tripwire > /tmp/twscan.out

# run tripwire in update mode, parsing the contents of /tmp/twscan.out for
# file paths and names, and replacing new-lines with spaces ...


bin/tripwire --update `grep -E "^(added|deleted|changed):" /tmp/twscan.out | cut -c60- | tr "\n" " "`

When run in update mode, Tripwire will automatically generate a backup copy of the database, and save the new database in a directory named "databases", within the current directory. The user will have to manually move the new database to the proper location before doing any other scanning.

Automating the Tripwire process

How often should Tripwire be run?

In an ideal setting, Tripwire would be run in a never-ending loop, detecting and reporting policy violations almost immediately after they occur. Unfortunately, several factors prohibit such an "aggressive" schedule. On systems with little activity, a Tripwire scan may not impact system performance in a notable way, but on systems that have a significant amount of load or interactive use, the increased load added by a Tripwire scan may degrade the system's performance by an unacceptable amount.

On systems that have a large number of files to be scanned, the work performed by Tripwire in examining those files can cause a large spike in both processor and I/O activity. Depending on the signatures being generated for each file, the length of time required to complete the scan may exceed the planned "window."

For these reasons, a good "baseline" schedule might be to perform a "quick" scan (one that checks no signatures, or one or two of the "simpler" algorithms) every two to four hours, and to do a "full" scan (verifying all of the signatures declared in the Tripwire configuration) once per day, at a time that system activity is low.

Managing multiple systems

One of the problems with the Academic Source Release version of Tripwire is that is has no facility for executing and managing integrity scans on multiple systems. Each host whose filesystem are to be protected must have Tripwire installed, with all scanning, reporting, and updating functions handled by the administrator locally. For environments with multiple systems, this can become a tedious task, prone to errors that may disguise real problems.

Further, is is recommended that the Tripwire database be stored on read-only medium, or if not practical, that it be stored on a "secure" host and exported via NFS as a read-only filesystem. If those recommendations are not followed, an administrator can never be sure that the database itself has not been tampered with in order to hide other unauthorized changes.

The following Korn shell script, "rtrip" addresses the issues mentioned above: Instead of having a Tripwire installation on each system to be monitored, Tripwire and the databases for all monitored systems will be located on a single system, one whose security is presumed to be tighter than the other systems in the data center. Usage of this script is as simple as:

rtrip [ -q ] [ -h hostname | -l hostlist ]

The flags and arguments taken by the script are:

• -q

  Configures tripwire to do a "quick" scan. By default a quick scan excludes the checking of all signatures. This may be configured in the script to only perform specific signature checks.

• -h hostname

  The script will do an integrity scan and database update on the hostname specified.

• -l hostlist

  The script will do an integrity scan and database update on each hostname listed in the specified hostlist file.

For example, to have tripwire run on a system named "pluto" every hour, at fifteen minutes past the hour, place the following entry in the root crontab on the "control" system (in these examples, the control system will be named "earth"):

15   *    *    *    *  /usr/sec/bin/rtrip -h pluto

To have tripwire run a "quick" scan on the hosts "mercury", "venus", "mars" and on the local system, named "earth" every day at 1:30am, 5:30 am, 9:30 am, 1:30 pm, 5:30 pm, and 9:30 pm, create the file "/usr/sec/etc/myhosts":

# cat /usr/sec/etc/myhosts
earth
mars
mercury
venus

Then add the following entry to the root crontab on the control system ("earth" in these examples):

30   1,5,9,13,17,21  *  *  *  /usr/sec/bin/rtrip -q -l /usr/sec/etc/myhosts

Setting up rtrip

The following conditions must be in place for rtrip to function:

• Each system that will be protected via rtrip must have Secure Shell (SSH) installed and functioning. Additionally, the root account on the control system must be able to execute commands on each target system without having to enter a password.

• The directory on the control system containing the tripwire components (/usr/sec/tw, in this tutorial) must be exported via NFS to each target system, as a read-only filesystem, with root access permitted. This can be accomplished by executing the command mknfsexp on the control system:

/usr/sbin/mknfsexp -d /usr/sec/tw -t ro -r targethost1,[targethost2,...] -B

The rtrip script

[Note to Editor: I suggest that the contents of the rtrip script presented below be available as a separate file, with a "download to disk" link.]

[script goes here ... still being debugged, bulletproofed, and fine-tuned.]

Summary

Making life easier for systems administrators since 1992

The development of Tripwire was one of the defining moments in the history of UNIX security. By deploying and using Tripwire on a regular basis, the difficult task of protecting and monitoring the integrity of each system's valuable data will become easier to accomplish and much more difficult to subvert.

Though Tripwire does not address the numerous other issues in providing a secure computing environment, it is a valuable tool that should be in the arsenal of every security-conscious system administrator

References and resources

The best reference for information on the design and use of Tripwire is in the documents that are included with the Tripwire 1.3.1 Academic Source Release distribution. The source can be obtained from the Tripwire Security Systems, Inc. web site, at <http://www.tripwire.com/products/tripwire_asr/>.

Information about the commercial version of Tripwire, its advantages and enhancements over the ASR release, can also be found at the TSS website: <http://www.tripwire.com>.

[Note to Editor: I think that items mentioning, and links to, my previous two tutorials would be useful and relevant to placement in this tutorial]

$Id: tripwire-aix.html,v 1.20 2001/11/27 21:39:23 ssklar Exp ssklar $