BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


FreeBSD Basics Checking System Integrity with tripwire

by Dru Lavigne
03/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:

Fun with Xorg

Sharing Internet Connections

Building a Desktop Firewall

Using DesktopBSD

Using PC-BSD

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 --check

This 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 2003

Finally, 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 2003

Nothing 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+KS

Notice 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.twr

After 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/vi

Remember, 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

Incident Response
By Kenneth R. van Wyk, Richard Forno

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.





Sponsored by: