Running with Tripwire

Using Tripwire to monitor file changes

Tripwire® is an intrusion detection system that monitors for file or directory changes based on the policy provided by the system administrator.

Share:

David Tansley (david.tansley@btinternet.com), System Administrator, Ace Europe

David TansleyDavid Tansley is a freelance writer. He has 15 years of experience as a UNIX administrator, using AIX the last eight years. He enjoys playing badminton, then relaxing watching Formula 1, but nothing beats riding and touring on his GSA motorbike with his wife.


developerWorks Contributing author
        level

13 December 2011

Also available in Chinese Russian

Introduction

The open source Tripwire® is a file integrity checker package that has been around for years and, though I have used it many times on Linux® distributions, I have only recently got around to using it on AIX®. This is mainly due to the following:

  • It is troublesome to compile using the gcc AIX version.
  • I prefer using the AIX built-in audit service.

However, as there is now a Tripwire rpm for AIX, I use it for some of our AIX boxes. Tripwire does not provide a complete solution to intruder detection based on file changes, but coupled with running an AIX audit, it provides a firm security policy. Tripwire monitors for changes to files and directories on your system via the objects that you provide in the main policy file. These changes may be but are not restricted to:

  • inode
  • timestamps
  • file size
  • file permissions and ownership attributes
  • hash values
  • file types

It reports on changes from the previous run of Tripwire, where you can compare previous ran reports. If files have been altered, removed, or added, then this requires further investigation by the system administrator to determine if it is a valid change or a forced change by some application or user.

Tripwire does have its short comings, when compared to other intruder detection systems (IDS). However, as it is open source, these shortcomings are soon forgotten. There is a commercial Tripwire product, but for this demonstration, I will only focus on the open source version. I am also using AIX 7.1 with Tripwire version 2.4.1. See the Resources section on where to download the Tripwire rpm. Once downloaded, be sure to have the following prerequisite rpms installed:

libgcc-4.6.1-1.aix7.1.ppc.rpm  
libstdc++-4.6.1-1.aix7.1.ppc.rpm
(openssl-1.0.0d-1.aix5.1.ppc.rpm)

Tripwire also requires openssl; most AIX boxes should already have this installed. If you are using SSH, be sure you have at least version 0.9.8. Check your version with:

# openssl
OpenSSL> version
OpenSSL 0.9.8m 25 Feb 2010
OpenSSL> quit

Next, install Tripwire:

#  rpm -ivh tripwire-2.4.2-1-1.aix5.1.ppc.rpm
tripwire                    ##################################################

Once installed, the Tripwire binary files are located in /opt/freeware/sbin.

tripwire-check           
atcadmin
tripwire                 
tripwire-setup-keyfiles  
reprint

The policy files are located at /etc/tripwire. The twcfg.txt file defines variables used by Tripwire (for example, location of tripwire report files, mailing, reporting level). The twpol.txt policy file tells Tripwire what files to monitor.

The first step is to tailor the policy file on what files gets monitored. The twpol.txt files that ships with Tripwire is geared for a Linux distribution, and you want to ensure that it covers the files you want to monitor. If you forget to tailor this policy file, an error for non-existent files are reported. It can be quicker to generate your own policy file, specific to your own security standard policy. This article demonstrates how an initial baseline policy is generated. I do not discuss all the features of Tripwire, such as severity levels and email conditions, but rather how to get up and running with Tripwire using a self-generated policy file to suit your needs and reports on file violations.


Configuring Tripwire

The contents of twcfg.txt are shown below. As Tripwire complains about directory permissions that may not be correct for your AIX box, the documentation suggests, and I agree, to change:

LOOSEDIRECTORYCHECKING = false

to

LOOSEDIRECTORYCHECKING = true

You may also want to change the locations of DBFILE and REPORTFILE to suite your location standards:

ROOT                   =/opt/freeware/sbin
POLFILE                =/etc/tripwire/tw.pol
DBFILE                 =/var/lib/tripwire/$(HOSTNAME).twd
REPORTFILE             =/var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr
SITEKEYFILE            =/etc/tripwire/site.key
LOCALKEYFILE           =/etc/tripwire/$(HOSTNAME)-local.key
EDITOR                 =/usr/bin/vi
LATEPROMPTING          =false
LOOSEDIRECTORYCHECKING =false
MAILNOVIOLATIONS       =true
EMAILREPORTLEVEL       =3
REPORTLEVEL            =3
MAILMETHOD             =SENDMAIL
SYSLOGREPORTING        =false
MAILPROGRAM            =/usr/sbin/sendmail -oi -t

If your hostname is not resolvable, you have to inform Tripwire of your local hostname. Edit the twpol.txt file; around line 64 there is an entry for:

HOSTNAME=;

Append your hostname after the '='. For example, the host name of my AIX box is rs6000, so the change would be:

HOSTNAME=rs6000;

Save and exit the file.

Generating the keys

The next task is to generate a site and local key for Tripwire using a passphrase. This helps safeguard Tripwire from unauthorized access. The local key is for the database file, and the site key is for the configuration and policy files. You need to remember the passphrases you give, as you will be prompted for these when you update the policy file or database. The following command generates both keys. For this demonstration, I will show the passphrases I used through out this article:

# /opt/freeware/sbin/tripwire-setup-keyfiles

----------------------------------------------

Creating key files...
Enter the site keyfile passphrase:rs6000
Verify the site keyfile passphrase:rs6000
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:master
Verify the local keyfile passphrase:master
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection.  It  is  recommended  that  you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.
Signing policy file...
Please enter your site passphrase:rs6000
Wrote policy file: /etc/tripwire/tw.pol.

When the key generation completes, the following files exist in /etc/tripwire:

rs6000-local.key  tw.cfg            twcfg.txt
site.key          tw.pol            twpol.txt

Looking at the above listing, we now have the additional files:

  • rs6000-local.key (your encrypted local key file);
  • site.key (your encrypted site key file);
  • tw.cfg (your encrypted configuration variables file); and
  • tw.pol (your encrypted policy file).

At this point, there is no need to keep the twcfg.txt and twpol.txt files in its current location. You can access the encrypted version of the files via a Tripwire utility by providing your passphrase to decrypt it. This is demonstrated in this article.

The initial scan

Now that we have generated the keys and supplied our passphrases, we can do an initial scan. Use the policy in the encrypted tw.pol policy file. As mentioned earlier, the policy file that ships with Tripwire is geared towards a Linux system in what files to check. The policy file needs to be tailored to your AIX system; you'll see how to do that shortly. However, for now, run the scan where Tripwire generates the checksums and records the file's scanned attributes. The database is also created and updated. Expect a lot of errors on this run, but this exercise gives you a feel on what to expect using Tripwire.

When running the initialization, you are prompted for your passphrase (I have also heavily truncated the output due to the amount of errors reported):

# /opt/freeware/sbin/tripwire --init
Please enter your local passphrase:master
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
### Warning: File system error.
### Filename: /proc/ksyms
### A file or directory in the path name does not exist.
### Continuing...
### Warning: File system error.
### Filename: /dev/initctl
### A file or directory in the path name does not exist.
### Continuing...
…
...
Wrote database file: /var/lib/tripwire/rs6000.twd
The database was successfully generated.
#

To function correctly, the Tripwire database must always be present; make sure it is backed up regularly. It is easy to re-initialize the database.

Once the initialization has completed, Tripwire reports that the database has been created (note that the current hostname is part of the database file-name located in /var/lib/tripwire/rs6000.twd).


The policy file

To customize the policy file to your needs, use the Tripwire check mode to check the integrity of the system. This also prints errors out where files are not present in the system but are present in the policy file. Expect the listing to be long; it maybe advantageous to redirect the output to a log file for further review:

 # /opt/freeware/sbin/tripwire --check | grep -w "Filename:"

A partial typical output from the above command could be:

     Filename: /bin/ypdomainname
     A file or directory in the path name does not exist.
     Filename: /bin/tcsh
     A file or directory in the path name does not exist.
     Filename: /usr/sbin/fixrmtab
     A file or directory in the path name does not exist.
     …
     …

To tailor the Tripwire policy on what files to monitor, you have two choices:

  1. Go through the policy file and remove the file names that were printed for the non-existing files.
  2. Start from scratch and add your own entries.

I prefer the last choice. That way, I only monitor what I want. Before we create those entries, the basic format of the policy file needs to be explained.

The policy file is very rich in command directives and objects, so be sure to read the man page on twpolicy. In this demonstration, I cover and implement only some of those command objects. Tripwire has the ability to monitor for the file attributes contained below in Listing 1.

Listing 1. File attributes
a     Access timestamp
b     Number of blocks allocated
c     Inode timestamp (create/modify)
d     ID of device on which inode resides
g     File owner's group ID
i     Inode number
l     File is increasing in size (a "growing file")
m     Modification timestamp
n     Number of links (inode reference count)
p     Permissions and file mode bits
r     ID of device pointed to by inode
      (valid only for device objects)
s     File size
t     File type
u     File owner's user ID
C     CRC-32 hash value
H     Haval hash value
M     MD5 hash value
S     SHA hash value

Additional masks can also be added to the attributes:

+	do compare attribute
-ignore  attribute

Built-in objects

If you have looked through the shipped twpol file, you would have noticed that the objects are already defined. These are shown below in Listing 2. Use the attributes as described in Listing 1 to create the property masks.

Listing 2. Masks
Variable       Mask
Device =      +pugsdr-intlbamcCMSH ; # devices file 
Dynamic =     +pinugtd-srlbamcCMSH ; # directories that change
Growing =     +pinugtdl-srbamcCMSH ; # file that grow in size
IgnoreAll =   -pinugtsdrlbamcCMSH ;  # check nothing
IgnoreNone =  +pinugtsdrbamcCMSH-l ; # check everything except growing attribute 
ReadOnly =    +pinugtsdbmCM-rlacSH ; # read only
Temporary =   +pugt                  # temp files that might be removed

Looking at the property mask Temporary, contained in Listing 2, we can see that temporary monitor:

  • permissions (and compare permissions)
  • file ownership
  • file group ownership
  • file type

Tripwire uses these property masks, that contain variables, to make it easier to specify what attributes to monitor on any given file. However, you can define your own objects, and in this demonstration, that is what I discuss. To aid in cross platform sharing, an object can be created to match certain criteria. In a nutshell, this means that you can specify what file attributes to monitor for different types of files.

The format of an object is:

object_name  = [ mask ];

Where object_name is a meaningful name of the type of files to monitor and mask represents the attributes shown in Listing 1.

Defining objects

If I wish to monitor system binary files, such as reducevg or chfs, I need to know about changes relating to these files on the following:

  • permissions
  • symbolic links
  • group owner
  • file owner
  • file size
  • modification stamp
  • MD5 hash signature

So using the above changes, I can generate a object called SYSBIN (for system binaries), using the attribute information contained in Listing 1.

SYSBIN =  +pngu+sm;

Note in this mask, I have stated with the plus (+) sign that the file permissions and file size should be compared from a previous Tripwire run or snapshot.

The format of each file or directory to monitor is:

<directory/file-name> - > $(object_name)

An entry in the policy file to monitor for the binary /usr/local/bin/pwgen, using the object SYSBIN, could be:

/usr/local/bin/pwgen  -> $(SYSBIN);

If I wanted to monitor the /usr/bin directory using the object SYSBIN, I could have:

/usr/bin -> $(SYSBIN);

Any modifications in the above directory, like additional new files, removed files created in that directory and are flagged as a violation.

For dynamic files, typically these are logs, we do not have to be so restrictive, as the files sizes are always changing. I could, for example, use the following object:

 SYSLOGS +p-lum

In this object, I specified to monitor only the following:

  • permissions
  • ignore file size growth ( -l)
  • file owner
  • MD5 hash signature

For an entry in the policy file for the /var/adm/messages log file, I could have:

/var/adm/messages - > $(SYSLOGS)

For certain application configuration scripts, I would want to monitor at least the following attributes:

  • access timestamp
  • permissions
  • modification timestamp
  • filesize
  • fileowner
  • MD5 hash signature

I could use the following object, calling it APPCONF:

APPCONF a+pm+suM;

The entry for an application config file /opt/dstage/Server/DSEngine/dsenv could be:

/opt/dstage/Server/DSEngine/dsenv - > $(APPCONF);

You cannot scan a file system, that already has another file system mounted from the base mount point, (non NFS cross mounts) unless it is specially put in the policy file.

For example, suppose you wanted to monitor /opt, but that file system also has another file system mounted called /opt/myapp and is mounted like:

/opt
/opt/myapp

Tripwire would complain and report:

The object: "/opt/myapp" is on a different file system...ignoring.

So make sure you have all the entries for file systems that you want to scan.

Using non-variable objects

You do not always have to use object variables, though it is easier when doing repetitive commands in the policy file. You can specify the attributes in place of the object, typically called property masks. For example, to monitor the /etc/security directory, plus scan recursively from within that directory, look for changes in:

  • permission
  • file owner
  • group owner

You could use:

/etc/security   -> +pug  (recurse=-1);

Where -1 means to do a recursive scan; 0 means to just scan the inode of the directories.

When specifying directories to scan and a new file is added, removed or, changed to that directory, Tripwire flags it as a violation.


Getting Tripwire to ignore files

To ignore directory or files (by that I mean for Tripwire not to scan them), the format is:

! <object_name>;

Where object_name could be a predefined variable, or a file-name, or a directory. For example, to inform Tripwire not to scan /opt/dump and the file /opt/freeware/goodies/myjob, you could have:

!/opt/dump;
!/opt/freeware/goodies/myjob;

Previously, there was an example of scanning /etc/security. However, in that directory the lastlog file holds the last login times. If you do not want that scanned, you could put the following entry in !/etc/security/lastlog; .

Now Tripwire scans /etc/security but will ignore the lastlog file.


Decrypting policy file

When you need to edit the policy file, do not get in the habit of copying back existing policy backup files to work with. Always use the current one. That means you need to decrypt it from Tripwire first.

To generate a text version of the current encrypted policy file, created previously, use:

 # /opt/freeware/sbin/twadmin --print-polfile > /etc/tripwire/twpol.txt

The de-decrypted policy file is now called twpol.txt.


Create new policy file

In this demonstration, I have decided to create a new twpol file, so just create a new file called /etc/tripwire/twpol.txt.

Put the following content in that file:

# this is a comment
# aix twpol.txt file

# system binaries
SYSBIN =  +pngu+sm;

/usr/local/bin/pwgen  -> $(SYSBIN);
/usr/bin -> $(SYSBIN);
/usr/sbin -> $(SYSBIN);

/etc/security   -> +pug  (recurse=-1);

# ignore last log
!/etc/security/lastlog;

# logs
SYSLOGS = +p-lum;

/var/adm/messages -> $(SYSLOGS);
/opt -> $(SYSBIN);
# ignore these do not scan
!/opt/dump;
!/opt/freeware;

Encrypt policy file

To get Tripwire to generate the new policy file (or update an exiting policy), use the twadmin command; you will be prompted for your site passphrase:

# /opt/freeware/sbin/twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt
Please enter your site passphrase:rs6000
Wrote policy file: /etc/tripwire/tw.pol

Display encrypted policy file

To confirm Tripwire has pulled in the newly updated policy file, use the following atcadmin command to display the contents of the policy:

# /opt/freeware/sbin/twadmin --print-polfile
# this is a comment
# aix twpol.txt file

# system binaries
SYSBIN =  +pngu+sm;

/usr/local/bin/pwgen  -> $(SYSBIN);
/usr/bin -> $(SYSBIN);
/usr/sbin -> $(SYSBIN);

/etc/security   -> +pug  (recurse=-1);

# ignore last log
!/etc/security/lastlog;

# logs
SYSLOGS = +p-lum;

/var/adm/messages -> $(SYSLOGS);
/opt -> $(SYSBIN);
# ignore these do not scan
!/opt/dump;
!/opt/freeware;

If the Tripwire database exits, prior to running a tripwire --init, it is good practice to delete the original database first. This ensures you get a clean database build. In this demonstration, my database is located in /var/lib/tripwire/rs6000.twd.

Scan it to build the database

Next, get Tripwire to do an initial integrity scan and generate the new database:

# /opt/freeware/sbin/tripwire --init
Please enter your local passphrase:master
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/rs6000.twd
The database was successfully generated.

Now run a Tripwire integrity check on the system (by that I mean a Tripwire scan). The output is contained below in Listing 3. Tripwire integrity check shows the output of the report with the new policy being used:

Listing 3. Tripwire integrity check
# /opt/freeware/sbin/tripwire –check

Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Wrote report file: /var/lib/tripwire/report/rs6000-20110817-173602.twr


Open Source Tripwire(R) 2.4.1 Integrity Check Report

Report generated by:          root
Report created on:            Wed Aug 17 17:36:02 BST 2011
Database last updated on:     Never

===============================================================================
Report Summary:
===============================================================================

Host name:                    rs6000
Host IP address:              192.168.4.8
Host ID:                      None
Policy file used:             /etc/tripwire/tw.pol
Configuration file used:      /etc/tripwire/tw.cfg
Database file used:           /var/lib/tripwire/rs6000.twd
Command line used:            /opt/freeware/sbin/tripwire –check
Rule Summary:
===============================================================================

-------------------------------------------------------------------------------
  Section: Unix File System
-------------------------------------------------------------------------------

  Rule Name                       Severity Level    Added    Removed  Modified
  ---------                       --------------    -----    -------  --------
  pwgen                           0                 0        0        0
  (/usr/local/bin/pwgen)
  bin                             0                 0        0        0
  (/usr/bin)
  sbin                            0                 0        0        0
  (/usr/sbin)
  security                        0                 0        0        0
  (/etc/security)
  messages                        0                 0        0        0
  (/var/adm/messages)
  opt                             0                 0        0        0
  (/opt)

Total objects scanned:  3739
Total violations found:  0
# Section: Unix File System
-------------------------------------------------------------------------------

No violations.

===============================================================================
Error Report:
===============================================================================

No Errors

-------------------------------------------------------------------------------
*** End of report ***

Checking and fixing violations

Using our rather sparse policy file, all looks OK on the system. Now I will change a file permission attribute of one of the files being scanned ( /usr/local/bin/pwgen).

# cd /usr/local/bin
# ls -l pwgen
-rwxrwxr-x    1 root     system       198697 Mar 26 15:15 pwgen
# chmod 755 pwgen
# ls -l pwgen
-rwxr-xr-x    1 root     system       198697 Mar 26 15:15 pwgen

Now run Tripwire to scan again; it picks up the change to the file pwgen. The truncated output of the scan is shown below in Listing 4.

Listing 4. Violation check
# /opt/freeware/sbin/tripwire --check
Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Wrote report file: /var/lib/tripwire/report/rs6000-20110817-173839.twr


Open Source Tripwire(R) 2.4.1 Integrity Check Report

Report generated by:          root
Report created on:            Wed Aug 17 17:38:39 BST 2011
Database last updated on:     Never

===============================================================================
Report Summary:
===============================================================================

Host name:                    rs6000
Host IP address:              192.168.4.8
Host ID:                      None
Policy file used:             /etc/tripwire/tw.pol
Configuration file used:      /etc/tripwire/tw.cfg
Database file used:           /var/lib/tripwire/rs6000.twd
===============================================================================
Rule Summary:
===============================================================================

-------------------------------------------------------------------------------
  Section: Unix File System
-------------------------------------------------------------------------------

  Rule Name                       Severity Level    Added    Removed  Modified
  ---------                       --------------    -----    -------  --------
* pwgen                           0                 0        0        1
  (/usr/local/bin/pwgen)
  bin                             0                 0        0        0
  (/usr/bin)
  sbin                            0                 0        0        0
# Section: Unix File System
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Rule Name: pwgen (/usr/local/bin/pwgen)
Severity Level: 0
-------------------------------------------------------------------------------

Modified:
"/usr/local/bin/pwgen"
…
…
*** End of report ***

To re-init or update the policy

From Listing 4, you can see that Tripwire has correctly detected the change. If this change of the file pwgen is a valid change, we really do not want Tripwire to keep reporting it. So here we have two choices on how to remove Tripwire from reporting this violation.

We can either run Tripwire with the init option again to get a base level scan on what to compare, on the next run, like so:

# /opt/freeware/sbin/tripwire --init

Or update the Tripwire database and inform it to disregard, or rather accept, this change.

In the /var/lib/tripwire/report directory, all report files that Tripwire generates resides here in the form hostname<date_stamp>.twr. Simply select the report that was generated with this Tripwire scan by listing the files in date order. Once you have the correct file, the following command allows you to update the database:

tripwire - - update - - twrfile </var/lib/tripwire/report/<hostname_date_stamp>.twr

After executing the command, you are placed into an editor. Search for the file-names that were reported. All violations or updates have a [x] preceding the file-name. The pattern to look for in this demonstration is:

[x] "/usr/local/bin/pwgen"

Like so:

Rule Name: pwgen (/usr/local/bin/pwgen)
Severity Level: 0
-------------------------------------------------------------------------------

Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.

Modified:
[x] "/usr/local/bin/pwgen"

If you wish to accept that these changes were valid, just save and exit the file. Tripwire no longer reports on that file. If you want this file to be excluded from being added to the database, remove the 'x'.

When you save and exit from the editor, and updates to the database are to take place, you will be prompted for your passphrase to complete the process. If no update is to take place, then Tripwire informs you of this and no passphrase is required. In this demonstration the following is prompted, as the database will be updated:

Please enter your local passphrase: master
Wrote database file: /var/lib/tripwire/rs6000.twd

Initial population of the policy file

To populate a new policy file with files you want monitored can be time consuming. One alternative in achieving a quick population of the policy file is to just specify the directories/file systems, as demonstrated earlier. However, another alternative is to run a find command on your system binary directories, like /usr/bin, then redirect the output to the policy file. Listing 5 below contains a simple script that finds files of normal type and prints the object name (like SYSBIN, as described earlier). This can then be redirected to the policy file.

Listing 5. pop_twpol
#!/bin/sh
# pop_twpol
dir_list="/usr/bin /usr/sbin /usr/local/bin"

for loop in $dir_list
do
list=$(find ${loop} -type f -exec ls {} \;)

 for loop2 in $list
  do
   echo "${loop2} -> \$(SYSBIN);"
  done

done

A sample output from the above script could be:

/usr/bin/xmtopasagg -> $(SYSBIN);
/usr/bin/xmtrend -> $(SYSBIN);
/usr/bin/xmwlm -> $(SYSBIN);
/usr/bin/xpstat -> $(SYSBIN);
/usr/bin/xsend -> $(SYSBIN);
/usr/bin/yes -> $(SYSBIN);
/usr/bin/ypcat -> $(SYSBIN);
/usr/bin/ypmatch -> $(SYSBIN);
/usr/bin/yppasswd -> $(SYSBIN);
/usr/bin/ypservers -> $(SYSBIN);
/usr/bin/ypwhich -> $(SYSBIN);

First though, get the plain text version of the policy file from Tripwire as we did earlier:

# /opt/freeware/sbin/twadmin --print-polfile > /etc/tripwire/twpol.txt

Next, run the script contained in Listing 5, amend the directory list to suit your needs, and redirect to the twpol.txt file, like so:

#./pop_twpoll >> /etc/tripwire/twpol.txt

Remember to remove any duplicate entries you may have previously inserted earlier in the policy file, or just start afresh with a new policy file.

Next, pull the new policy file into Tripwire:

# /opt/freeware/sbin/twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt

For other ad hoc files and log files, these could be added manually or similar processes to the above could be carried out.

Confirm the policy file now containing our individual files is encrypted and ready for use by printing the policy file contents:

# /opt/freeware/sbin/twadmin –print-polfile
# this is a comment
# aix twpol.txt file

# system binaries
SYSBIN =  +pngu+sm;


# logs
SYSLOGS = +p-lum;

/var/adm/messages -> $(SYSLOGS);

/etc/security   -> +pug  (recurse=-1);
# ignore last log
!/etc/security/lastlog;

/opt -> $(SYSBIN);
# ignore these do not scan
!/opt/dump;
!/opt/freeware/goodies/myjob;

/usr/bin/Mail -> $(SYSBIN);
/usr/bin/ManGetURL.class -> $(SYSBIN);
/usr/bin/Rsh -> $(SYSBIN);
/usr/bin/SpmiArmd -> $(SYSBIN);
…
…

Next, run a Tripwire initial scan to re-regenerate the database:

 # /opt/freeware/sbin/tripwire --init

Next, run a Tripwire check using your newly created policy file:

 # /opt/freeware/sbin/tripwire –-check

Monitoring and reporting on a large quantity of files can sometimes really be too much. So choose carefully what files you want monitored. This process is an iterative one and can take a few weeks till you are satisfied on what actually requires monitoring by Tripwire.

For system binaries, I prefer to just scan by directory name. For all other files, like configuration scripts and security files, I typically enter these in manually.


Reporting

As mentioned earlier, every time Tripwire runs a check, it generates a report. These reports go to standard output and are also saved as a report file. The reports are located in /var/lib/tripwire/report.

Like so:

# pwd
/var/lib/tripwire/report
bash-3.2# ls
rs6000-20110811-174421.twr  rs6000-20110812-092023.twr
rs6000-20110811-175332.twr  rs6000-20110812-093053.twr
rs6000-20110811-192716.twr  rs6000-20110812-093410.twr

To view the a report, use the reprint command. The format is:

pwprint -m r –twrfile <reportfile.twr>

To view the report file rs6000-20110812-093643.twr, you could use:

# /opt/freeware/sbin/twprint \
-m r --twrfile /var/lib/tripwire/report/rs6000-20110812-093643.twr

 Report is not encrypted.
Open Source Tripwire(R) 2.4.1 Integrity Check Report
Report generated by:          root
Report created on:            Fri Aug 12 09:36:43 BST 2011
Database last updated on:     Never
===============================================================================
Report Summary:
===============================================================================
Host name:                    rs6000
Host IP address:              192.168.4.8
Host ID:                      None
Policy file used:             /etc/tripwire/tw.pol
Configuration file used:      /etc/tripwire/tw.cfg
….
….

You can also print information about a particular file that is held in the database. To extract the file information on /usr/local/bin/pwgen, you could use:

# /opt/freeware/sbin/twprint -m d --print-dbfile /usr/local/bin/pwgen
Object name:  /usr/local/bin/pwgen

Property:               Value:
-------------           -----------
Object Type             Regular File
Mode                    -rwxr-xr-x
Num Links               1
UID                     root (0)
GID                     system (0)
Size                    198697
Modify Time             Sat Mar 26 15:15:25 GMT 2011

To extract all the information from the Tripwire database, use the following:

# /opt/freeware/sbin/twprint -m d –print-dbfile |more

Running Tripwire

For Tripwire to be effective, it should be run regularly. This is accomplished by running Tripwire through your favorite scheduler. The following cron entry runs Tripwire every day at 06:30 in the morning, redirecting the report to /opt/dump/logs/triplog<date_stamp>, like so:

30 06 * * *  /opt/freeware/sbin/tripwire \
- - check > /opt/dump/logs/triplog'date +"%d-%m-%y"'

Of course, do not forget you still have the report files in /var/lib/tripwire/report to review if necessary. Alternatively, you could have the report emailed to you. The following cron entry emails the syadmin email group the Tripwire report:

30 06 * * *  /opt/freeware/sbin/tripwire - - check | mail sysadmin -s "tripwire report for
'hostname'"

Conclusion

Be advised, if you are using a backup application to backup your AIX box, some of these applications may change the last accessed attribute of the file it has backed up as part of its backup process.

If you are monitoring this attribute via Tripwire, it flags the attribute as a violation. So you may need to either adjust your policy setting or run a Tripwire initialization after the backup to get a fresh snapshot. One way to check the last accessed time is to use the istat utility. For example:

istat <filename>

Tripwire is very feature rich; I have only covered some of the more common features in this article. Be sure to view the twpol manpage on the other feature not covered in the article. Do not hold back in tailoring the policy file to your particular requirements on your system. Tripwire is a good tool to have when used in conjunction with other auditing tools.

Resources

Get products and technologies

  • Download Tripwire and other rpm packages.
  • Download the AIX rpm packages.
  • Try out IBM software for free. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=780173
ArticleTitle=Running with Tripwire
publish-date=12132011