The Design and Implementation of Tripwire:A File System Integrity Checker Gene H. Kim and Eugene H. SpaffordCOAST LaboratoryDepartment of Computer SciencesPurdue UniversityWest Lafayette, IN 47907–1398February 23, 1995AbstractAt the heart of most computer systems is a file system. The file system contains user data, executableprograms, configuration and authorization information, and (usually) the base executable version of theoperating system itself. The ability to monitor file systems for unauthorized or unexpected changesgives system administrators valuable data for protecting and maintaining their systems. However, inenvironments of many networked heterogeneous platforms with different policies and software, the taskof monitoring changes becomes quite daunting.Tripwire is tool that aids UNIX system administrators and users in monitoring a designated set offiles and directories for any changes. Used with system files on a regular (e.g., daily) basis, Tripwire cannotify system administrators of corrupted or altered files, so corrective actions may be taken in a timelymanner. Tripwire may also be used on user or group files or databases to signal changes.This paper describes the design and implementation of the Tripwire tool. It uses interchangeable“signature” (usually, message digest) routines to identify changes in files, and is highly configurable.Tripwire is no-cost software, available on the Internet, and is currently in use on thousands of machinesaround the world.1 IntroductionMost modern computer systems incorporate some form of long-term storage, usually in the form of filesstored in a file system. These files typically contain all of the long-lived data in the system, including bothuser data and applications, and system executables and databases. As such, the file system is one of the usualtargets of an attack. Motives for altering system files are many. Intruders could modify system databasesand programs to allow future entry. System logs could be removed to cover their tracks or discouragefuture detection. Compromised security could lead to degradation or denial of services. Modification This paper is to appearin the Proceedingsof the 2nd ACM Conference on Computer and Communications Security, 1994. Anearlier version of this paper was released as Purdue Technical Report CSD-TR-93-071.1or destruction of user files might also compromise aspects of the security policy. As such, the securityadministrator needs to closely monitor the integrity of the file system contents.Thenear-ubiquitous UNIX system is an example of a file system where such monitoringis useful. Flawsand weaknesses in typical UNIX systems are well-documented (e.g., [8, 25, 19, 4, 9]). UNIX file systemsare susceptible to threats in the guise of unauthorized users, intruders, viruses, worms, and logic bombsas well as failures and bugs. As such, UNIX system administrators are faced with prospects of subtle,difficult-to-detect damage to files, malicious and accidental.Tripwireis an integritycheckingtool designed for the UNIXenvironmentto aid systemadministratorstomonitor their file systems for unauthorized modifications. First made available on November 2, 1992, it hasproven to be a popular tool, being portable, configurable, scalable, flexible, manageable, automatable, andsecure. It was written in responseto repeated break-in activityon the Internet, and the difficulty experiencedby affected administrators in finding all of the “backdoors” left by the intruders.The foundations of integrity checking programs are surveyed in [2]. In simplest terms, a database iscreated with some unique identifier for each file to be monitored. By recreating that identifier (which couldbe a copy of the entire file contents) and comparing it against the saved version, it is possible to determineif a file has been altered. Furthermore, by comparing entries in the database, it is possible to determine iffiles have been added or deleted from the system.As described in [9], achecklistis one form of this database for a UNIX system. The file contentsthemselves arenotusually saved asthiswouldrequire too muchdiskspace. Instead, a checklistwould containa set of values generated from the original file — usually including the length, time of last modification, andowner. The checklist is periodically regenerated and compared against the saved copies, with discrepanciesnoted. However, as noted in [9], changes may be made to the contents of UNIX files without any of thesevalues changing from the stored values; in particular, a user gaining access to the root account may modifythe raw disk to alter the saved data without it showing in the checklist.Efficientlydetecting changes to files under these circumstances can be done by storing a value calculatedfrom the contents of the files being monitored. If this value is dependent on the entire contents of the file andis difficult to match for an arbitrary change to the file, then storing this value is sufficient. This fingerprintor signature of the file can then be saved instead of the file contents.1The signature function(s) used shouldbe computationally simple to perform, but infeasible to reverse. It should signal if the file changes but besufficiently large as to make a chance collision unlikely. Signature functions and methods are discussed in[24, 18, 9, 17, 4, 7, 16, 23].Although various candidate signature functions have been studied over the past few years, we wereunaware of any tool in general use that used these methods under UNIX. This led to the design of Tripwire.2 Problem DefinitionUltimately, the goal of integrity checking tools is to detect and notify system administrators of changed,added, or deleted files in some meaningful and useful manner. The success of such a tool depends on howwell it works within the realities of the administration environment. This includes appropriate flexibility1Some contendthat the term signatureshouldbe usedonly when referring to functions thathave rootsin cryptographicmethods.In this paper, we use the term in a more generalconnotation: the fixed-size“fingerprint” generated by a function using the contentsof a file as its input data.2to fit a range of security policies, portability to different platforms in the same administrative realm, andease of use. We also believe that it is important that any such tool present minimal threat to the system onwhich it was used; if the tool were to be read or executed by an attacker, it should not