Open Source Tripwire

For other uses, see Tripwire (disambiguation).

Open Source Tripwire

Developer(s)	Tripwire, Inc.
Stable release	2.4.3.7 / 31 March 2018 (2018-03-31)
Repository	github.com/Tripwire/tripwire-open-source
Written in	C++, Perl
Operating system	Linux, all POSIX/UNIX Systems
Type	Security, Monitoring, HIDS
License	GPLv2
Website	https://github.com/Tripwire/tripwire-open-source

Open Source Tripwire is a free software security and data integrity tool for monitoring and alerting on specific file change(s) on a range of systems originally developed by Eugene H. Spafford and Gene Kim. The project is based on code originally contributed by Tripwire, Inc. in 2000. It is released under the terms of GNU General Public License.

It works by creating a baseline database, and then regularly comparing the state of the file system with the database. If it detects changes (e.g. addition or modification of some files), it includes these changes in its report, so that the security administrators could check these changes.

History

The Tripwire was created by Dr. Eugene Spafford and Gene Kim in 1992 in response to a series of stealthy intrusions that occurred in early 1991. These attacks circumvented the existing security systems by infecting the shared libraries in a way that their CRC checksums were unchanged. Tripwire was designed to use message digest functions from different hash families (e.g. MD5 and Snefru) in order to stay reliable even when a vulnerability is uncovered in some of the hashing algorithms. The name "Tripwire" comes from the trap or tripwire files which alert administrators upon being accessed by intruders. Spafford recalls:

We heard several stories where tripwire files were established, as per our original intent, which were used to detect insiders snooping into files and directories where they had no reason to explore. At least one such use was related to us as a trigger that uncovered insider-perpetrated fraud.

Tripwire was written in C and its design emphasized the program and database portability. On November 2, 1992, it was released for a beta testing. In December 1993, the formal release was made after identifying and fixing several bugs. Early releases were developed in a cleanroom style, where Gene Kim did the development and Eugene Spafford ran the acceptance testing.

The Tripwire was initially free and open-source, but it went commercial in 1997. Open Source Tripwire was released in October, 2000, under the GNU General Public License.

On May 4, 2015, the source code was moved from SourceForge to GitHub.

Overview

Diagram of high level operation model of Tripwire

During the installation, Open Source Tripwire asks the user to set the site-key and local key passphrases. The site-key passphrase is used to protect files across several systems (policy and configuration files) and the local passphrase is used to protect files on a specific machine. The policy file contains the list of files and directories to scan and the rules (e.g. which attributes of the directory tree to look at).

Open Source Tripwire later asks for the local passphrase when creating an initial database containing file signatures. It runs the first scan of the system and saves the result to the database. Afterwards, it runs integrity checks and compares the result with the database. For example, if a new file is created then it will be listed in the subsequent integrity check report. Open Source Tripwire can be configured to regularly run integrity checks (e.g. every night) and send report e-mails to the system administrator. The database file is designed to be human-readable, so that the user is able to verify properties of individual files or even check the database for potential tampering. It is important that the database is initialized before the system is at risk of being compromised.

A more sophisticated usage would include creating the tripwire files and configuring Open Source Tripwire to track these files in order to catch snooping intruders. When the intruder reads these files, their timestamps get updated and the security administrators get notified about this incident.

Unlike Tripwire Enterprise, Open Source Tripwire is not available for Windows and has only basic policies.

Details

Policy file

The policy file is called twpol.txt (or tw.config in the previous versions), and it tells which files and directories need to be monitored for creations, deletions or modifications. It supports preprocessing which allows administrators to write only one policy file for many different machines. In the policy file, along with each file or directory there is a selection-mask that tells which attributes to ignore and which to report. For example, the selection-mask could be written to report changes in modification timestamp, number of links, size of the file, permission and modes, but ignore changes to the access timestamp. Also, there is an option to specify whether or not Tripwire should be recursing into a directory, i.e. checking the subdirectories, subdirectories of those subdirectories, etc.

Example of the policy 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;

The following example of the policy file from "The Design and Implementation of Tripwire: A File System Integrity Checker" by Spafford and Kim makes use of the preprocessing language. Here it allows to ignore some directory with logs only on a specific host. Thus, the preprocessing allows to use the same policy file on this specific host and on other hosts, otherwise the user would need to write separate policy files.

# file/dir selection-mask
/etc R # all files under /etc
@@ifhost solaria.cs.purdue.edu
!/etc/lp # except for SVR4 printer logs
@@endif
/etc/passwd R+12 # you can't be too careful
/etc/mtab L # dynamic files
/etc/motd L
/etc/utmp L
=/var/tmp R # only the directory, not its contents

Configuration file

The configuration file is called twcfg.txt, and it contains information about paths to the policy file, database file, report file, etc. It also has entries for mail settings (for instance, which program to use to send an e-mail with the report). Example of the configuration file:

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

Database file

The database file is unique for each machine, as opposed to the policy file which could be shared across multiple machines. It stores signatures of the files, and not the content itself, because storing the content of the files would use too much disk space. For each file, the database can store up to ten signatures. There are six types of changes to the database: adding, deleting or updating a file, and adding, deleting or updating an entry. Most of them are straightforward except for adding a file when it does not have an entry in the policy file. In this case Tripwire chooses the "closest" ancestor entry in the policy file and copies its selection-mask, or uses the default selection-mask if the entry could not be found at all. Tripwire also has an interactive update mode which simplifies the process of reviewing every updated file. For each created, deleted or modified file it asks whether or not the corresponding database entry should be changed.

Signatures

In order to minimize the impact of hash collisions (i.e. the signature would not change even when the file was changed) on the security, Tripwire uses multiple different hashing algorithms to compute multiple signatures for each file. Because different hashing algorithms have different performances, Tripwire allows to configure which signatures to use and how frequently. For example, the system could be configured to compare CRC32 signatures every hour and compare MD5 signatures every day. This way the hourly integrity checks would run faster, and even if some file gets modified without changing its CRC32 checksum, it will get reported during the daily integrity check. Tripwire provides a generic interface to signature routines, so the user can include their own checksum methods.

See also

• AIDE
• Host-based intrusion detection system comparison
• OSSEC
• Samhain

External links

• Tripwire, Inc.