Running with Tripwire
Using Tripwire to monitor file changes
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:
- Go through the policy file and remove the file names that were printed for the non-existing files.
- 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.
No comments:
Post a Comment