Checking System Integrity with tripwire
by Dru Lavigne03/20/2003
In the previous
article, I introduced file integrity utilities and demonstrated how to
install the tripwire utility. Let's carry on where that
article left off.
tripwire comes with several utilities which are used to
create and maintain the tripwire database, configuration file and policy
file. man twintro shows the following:
tripwire(8): used for the creation of the Tripwire
database, and checking the integrity of the filesystem against that
database.
twadmin(8): used to create, encode, and sign
Tripwire policy, configuration, and key files
twfiles(5): provides an overview of the various
files created and used by Tripwire, including default locations and
settings.
twconfig(4): explains the configuration file
twpolicy(4): explains the policy file, which
specifies the files and directories Tripwire should check, and how they should
be scanned.
The install process created a default database for you in the
/var/db/tripwire directory. Let's see what type of files it
contains:
$ file /var/db/tripwire/*
/var/db/tripwire/hostname.twd: data
/var/db/tripwire/report: directory|
Also in FreeBSD Basics: |
Your actual database name will reflect your system's hostname. Note
that the tripwire database (the .twd file) is NOT in ASCII
text. You won't be able to view it in an editor or a pager. Instead, use
the tripwire utilities to manipulate that database. You'll also find that
the report directory will be empty by default.
The premise behind tripwire is that a database is
"initialized" using the parameters contained in a policy file. This
initialization takes a snapshot or baseline of the files on the
system. You then periodically do an "integrity check" to see which files
have changed, investigating why any files have changed.
During the install, the database was initialized for you using the
default policy parameters. It's up to you to use the tripwire
command to check the integrity of the database:
$ tripwire --checkThis will check your current system against the snapshot contained in
the tripwire database. If it finds any inconsistencies, they will be
printed to your screen. In addition, a data file with the naming format
hostname-date-time.twr will be placed in
/var/db/tripwire/report. Again, this file isn't in ASCII
text. View this report file with the twprint utility:
$ cd /var/db/tripwire/report
$ twprint --print-report -r hostname-20030309-104231.twr | more Note that the name of your report file will depend upon your hostname and
the date and time you generated the report. Also, don't forget to include
-r to specify the name of the particular report file you would
like to view.
Let's take a look at a sample tripwire report:
*****
Note: Report is not encrypted.
Tripwire(R) 2.3.0 Integrity Check Report
Report generated by: root
Report created on: Sun Mar 9 10:42:31 2003
Database last updated on: Never
===============================================================================
Report Summary:
===============================================================================
Host name: hostname
Host IP address: 1.2.3.4
Host ID: None
Policy file used: /usr/local/etc/tripwire/tw.pol
Configuration file used: /usr/local/etc/tripwire/tw.cfg
Database file used: /var/db/tripwire/hostname.twd
Command line used: tripwire --check
===============================================================================
Rule Summary:
===============================================================================
-------------------------------------------------------------------------------
Section: Unix File System
-------------------------------------------------------------------------------
Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- --------
Invariant Directories 66 0 0 0
Sources 100 0 0 0
Temporary directories 33 0 0 0
* Tripwire Data Files 100 1 0 0
Local files 66 0 0 0
Tripwire Binaries 100 0 0 0
Libraries, include files, and other system files
100 0 0 0
System Administration Programs 100 0 0 0
User Utilities 100 0 0 0
X11R6 100 0 0 0
NIS 100 0 0 0
(/var/yp)
/etc 100 0 0 0
Security Control 100 0 0 0
* Root's home 100 0 0 1
FreeBSD Kernel 100 0 0 0
FreeBSD Modules 100 0 0 0
/dev 100 0 0 0
Linux Compatibility 100 0 0 0
(/compat)
Total objects scanned: 102111
Total violations found: 2
***** Note that the report gives a summary of how many files have been
added, removed, and modified since the last check of the database. In my
case, a tripwire file was added and a file in root's home
directory was modified. The summary is then followed by details regarding
the changed files:
===============================================================================
Object Detail:
===============================================================================
----------------------------------------
Added Objects: 1
----------------------------------------
Added object name: /var/db/tripwire/dhcp-17-14.kico2.on.cogeco.ca.twd.bak
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 1
----------------------------------------
Modified object name: /root
Property: Expected Observed
------------- ----------- -----------
* Modify Time Sun Mar 9 09:54:01 2003 Sun Mar 9 10:42:34 2003
* Change Time Sun Mar 9 09:54:01 2003 Sun Mar 9 10:42:34 2003Finally, the report will indicate any errors. In my case, it repeated the Kerberos errors I encountered when I initially installed tripwire.
The above report is an example of a report that doesn't show any anomalies. As another example, I'll repeat the check after
- creating a new user on the system
- deleting the binary file
tip
As you'd probably expect, this report will show the above changes; however, you may be surprised to see how the changes are reported. Here are the relevant bits of the report:
Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- --------
* Tripwire Data Files 100 1 0 0
* User Utilities 100 0 1 1
* /etc 100 0 0 6
* Root's home 100 0 0 1
===============================================================================
Object Detail:
===============================================================================
----------------------------------------
Removed Objects: 1
----------------------------------------
Removed object name: /usr/bin/tip
----------------------------------------
Modified Objects: 1
----------------------------------------
Modified object name: /usr/bin
Property: Expected Observed
------------- ----------- -----------
* Modify Time Tue Mar 4 19:36:47 2003 Sun Mar 9 16:11:57 2003
* Change Time Tue Mar 4 19:36:47 2003 Sun Mar 9 16:11:57 2003Nothing surprising here. It clearly indicates that
/usr/bin/tip was removed from the system at 16:11:57 on March
9th.
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 6
----------------------------------------
Modified object name: /etc
Property: Expected Observed
------------- ----------- -----------
* Modify Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* Change Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
Modified object name: /etc/group.bak
Property: Expected Observed
------------- ----------- -----------
* Inode Number 961 1297
* Size 404 461
* Modify Time Wed Sep 25 13:28:27 2002 Sun Feb 9 13:07:19 2003
* Change Time Sat Nov 9 14:35:21 2002 Sun Mar 9 16:02:39 2003
* CRC32 A676qQ CqOlUf
* MD5 DyxBdqQBLU5dTDXG4sGHwl BRoZrUEyVXd6aCYc0TsG/M
Modified object name: /etc/master.passwd
Property: Expected Observed
------------- ----------- -----------
* Size 2042 2150
* Modify Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* Change Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* Blocks 4 8
* CRC32 DDJ4Ig BF6+V2
* MD5 DuVzv0gdyUQffuRQnHbKrC CxQW2V/pqjJ1ep5vzunMG5
Modified object name: /etc/passwd
Property: Expected Observed
------------- ----------- -----------
* Inode Number 1956 1953
* Size 1499 1543
* Modify Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* Change Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* CRC32 AEOtzi CF+noG
* MD5 DTYQyRBwdY/bsHG3TzCDS0 A35b+lMv45SAzp25IoUmVW
Modified object name: /etc/pwd.db
Property: Expected Observed
------------- ----------- -----------
* Inode Number 1906 1012
* Modify Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* Change Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* CRC32 B4ufr3 Du5vQF
* MD5 A5cw0I8QyfWE76jhIupjbx Aw92gyYFa0DPEx+eGFG1MM
Modified object name: /etc/spwd.db
Property: Expected Observed
------------- ----------- -----------
* Inode Number 1955 1837
* Modify Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* Change Time Sat Feb 15 10:48:13 2003 Sun Mar 9 16:02:39 2003
* CRC32 B1+c6t BnB5nm
* MD5 BeDTKuET4SYQH9UgLdsv5i BCU119GuWEYDvMd00+8LnP
-------------------------------------------------------------------------------
Rule Name: Security Control (/etc/group)
Severity Level: 100
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 1
----------------------------------------
Modified object name: /etc/group
Property: Expected Observed
------------- ----------- -----------
* Inode Number 1297 961
* Size 461 475
* Modify Time Sun Feb 9 13:07:19 2003 Sun Mar 9 16:02:39 2003
* Change Time Sun Feb 9 13:07:19 2003 Sun Mar 9 16:02:39 2003
* CRC32 CqOlUf AdqVt7
* MD5 BRoZrUEyVXd6aCYc0TsG/M AFcDFbm7SEtHIYfQ7jy+KSNotice how much happens behind the scenes when you add a user account.
Both password files (passwd and master.passwd)
are updated, the group database and its backup are updated, and both
password databases (pwd.db and spwd.db) are
updated.
Since I added that user and deleted that file, I can easily interpret the report. However, alarm bells would go off in my head if I were reading this report on a system where I knew I hadn't made those changes. Since the report includes the time of the change, I have a reference point for any necessary investigation: I can start looking at the logs for that time period or question other users who may have been on the system during that time period.
Notice also that tripwire continues to include the changes from
previous reports. In my example, I still have the 1 added tripwire file
and the 1 modified file in root's home directory. Normally after you've
analyzed the report and have accounted for any changes, you merge those
changes back into the database so you don't have to review them again. To
accomplish this, use the update switch and specify the name
of the report file you wish to merge with the database:
$ tripwire --update -r hostname-date-time.twrAfter a moment, the report will open up in an editor (vi
by default). Toward the end of the report, you'll see some boxes like
this:
Remove the "x" from the adjacent box to prevent updating the database with
the new values for this object.
Removed:
[x] "/usr/bin/tip" By default, all your changes have the x, meaning if you
leave them as is, the changes won't be repeated the next time you generate
a new report.
So, I'll type :wq to write and quit the vi editor. I'll then
be prompted for the passphrase so the database can be updated.
Up to this point, we've used the default policy file. Next, I'll demonstrate a simple change to the policy file in order to resolve the error report section of the tripwire report.
When you installed tripwire, the default policy file was saved to
/usr/local/etc/tripwire/tw.pol. This file is used by
tripwire whenever you do a check on the database. However,
you can't edit this file directly as it has been encoded and signed.
Fortunately, there is an ASCII text version of the file called
/usr/local/etc/tripwire/twpol.txt. Edit that file then use
the tripwire utility to incorporate your changes into the
encoded policy file.
Let's start by examining the contents of
/usr/local/etc/tripwire:
$ cd /usr/local/etc/tripwire && file *
hostname-local.key: data
site.key: data
tw.cfg: data
tw.pol: data
twcfg.txt: ASCII text
twpol.txt: ASCII English text
twpol.txt.bak: ASCII English text Note that the actual policy file (tw.pol) and
configuration file (tw.cfg) are data files. However, each has
an ASCII text equivalent; in addition, the ASCII equivalent of the policy
file also has a backup (twpol.txt.bak).
The first time you look at a tripwire policy file, you'll probably
feel a bit intimidated by the ugly looking syntax. It's not that bad,
especially if you stick with the basics. The FreeBSD port makes a policy
file that should cover anything found in a FreeBSD install. Note that some
lines begin with a #. This means that line is commented out
(not used during the tripwire check). If you want tripwire to check for
that file or directory, simply remove the #. Alternately, if
you find something you don't want tripwire to check, place a
# in front of it.
In my case, I want to comment all of the lines that deal with Kerberos
in twpol.txt so I won't continue to receive Kerberos errors
in my tripwire reports. Once I've saved my changes, I'll run this command
to incorporate the changes into the encoded policy file:
$ tripwire --update-policy twpol.txt
Parsing policy file /usr/local/etc/tripwire/twpol.txt
Please enter your local passphrase:
Please enter your site passphrase:Note that you will be prompted for both passphrases. The best time to
merge in a new policy is just after you do a tripwire
--update. If you try to change a policy file and there are
inconsistencies in the tripwire database (i.e. some files have changed
since the last check), the policy merge will fail. While inconvenient,
this is a safety feature as it forces you to be aware of any changes to
the files on your system before you change the policy. So if your policy
fails to update, do a tripwire --check, resolve your changes
with tripwire --update, then try your tripwire
--update-policy command again.
Commenting and uncommenting lines in the tripwire policy file is the
easiest way to control which files tripwire monitors. If
you're an advanced user who wants more control over the policy file, read
through man twpolicy thoroughly before starting your own
experiments.
The configuration file has a much more user-friendly syntax which is
covered in man twconfig. For example, if you're allergic to
vi, change this line in twcfg.txt to reflect the
full path to your favorite editor:
EDITOR =/usr/bin/viRemember, if you make a change in the ASCII configuration file, use this command to merge your changes into the encoded configuration file:
$ twadmin --create-cfgfile -S site.key twcfg.txt
Please enter your site passphrase: Note that you'll receive a syntax error if you forget to include the
-S site.key switch.
Now that you have an idea of how to use the tripwire
utility, how often should you use it? This will depend upon the security
policy of your network; or, if you're a home user, how often you're
willing to read your tripwire reports and investigate the changed files on
your system. Ideally, your tripwire check should be a part of your daily
routine, something you do after reading the daily output and security
emails that are sent to the superuser. If you do the tripwire check less
often, you will have more changes to investigate and it will be harder to
remember if you did something on that day that changed a file on your
system.
|
Related Reading 
|
You should also consider what to do with the ASCII versions of your
configuration and policy files, as well as the tripwire reports
themselves. It is an added security measure to backup these files to a
removable media such as a floppy drive or backup tape, then remove them
from the hard drive. However, don't remove your keys or your data files as
they are needed for the proper operation of tripwire.
I'll leave you today with a URL which provides practical information regarding the points to be considered when creating a tripwire policy: http://www.cert.org/security-improvement/implementations/i002.02.html
Even though the article is specific to a Solaris installation, it still
contains much useful information regarding the actual usage of
tripwire.
If you're new to the CERT site, spend some time exploring its many resources. CERT is best known for its searchable vulnerabilities and incidents database. CERT issues advisories as vulnerabilities are discovered. Each advisory follows the same format: a description of the problem, where to find and how to apply the solution, and the systems which are affected. You can also join the CERT mailing list and receive advisories as they are released. In addition, CERT provides many practical how-to guides for securing operating systems.
In the next article, I will demonstrate aide and
yafic. These are two alternative file integrity utilities
which offer some advantages over tripwire. If there's room,
I'll also talk a bit about DDoS and some utilities that are available to
check for DDoS agents.
Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.
Read more FreeBSD Basics columns.
Return to the BSD DevCenter.
