## $Id$ ## ## README for Tripwire ## ## Gene Kim & Gene Spafford ## The COAST Project ## Department of Computer Sciences ## Purdue University ## ## All files in the distribution of Tripwire are Copyright 1992, 1993, 1994 ## by the Purdue Research Foundation of Purdue University. All rights ## reserved. Some individual files in this distribution may be covered ## by other copyrights, as noted in their embedded comments. ## ## Redistribution and use in source and binary forms are permitted ## provided that this entire copyright notice is duplicated in all such ## copies, and that any documentation, announcements, and other ## materials related to such distribution and use acknowledge that the ## software was developed at Purdue University, W. Lafayette, IN by ## Gene Kim and Eugene Spafford. No charge, other than an "at-cost" ## distribution fee, may be charged for copies, derivations, or ## distributions of this material without the express written consent ## of the copyright holder. Neither the name of the University nor the ## names of the authors may be used to endorse or promote products ## derived from this material without specific prior written ## permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY ## EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE ## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR ANY PARTICULAR ## PURPOSE. This README file serves as a quick-and-dirty primer on Tripwire. A PostScript formatted paper that fully describes the design and rationale is also included in the ./docs directory. The design document is also available as a technical report (TR-CSD-93/71). This document will be referenced throughout the Tripwire distribution as the Tripwire design document or the comprehensive Tripwire paper. This README file contains information needed to build, test, and run Tripwire. A table of contents follow: 0.0. If you were running an earlier version 1.0. Background 1.1. Goals of Tripwire 2.0. How to build Tripwire 2.1. Common Tripwire compilation problems 2.2. The siggen utility 3.0. Getting Tripwire up and running 3.1. Creating your tw.config file 3.2. A caveat about your Tripwire database 3.3. Testing Tripwire 3.4. Running Tripwire as an integrity checker 3.5. Keeping your database up-to-date 3.5.1. Running Tripwire in Interactive mode 3.5.2. Running Tripwire in Database Update mode 3.6. A quick-checking mode 4.0. Some Tripwire scaling hints for using Tripwire in large sites 4.1. The tw.config grammar 4.2. How you might use these directives 5.0. Notes on signature routines 5.1. Performance vs. security 6.0. Signature routines 6.1. MD5 6.2. Snefru 6.3. CRC-32 6.4. CRC-16 6.5. MD4 6.6. MD2 6.7. SHA/SHS 6.8. Haval 6.9. null signature 7.0. Feedback and bug-reports 8.0. User contributions 9.0. Acknowledgements 0.0. If you were running an earlier version ============================================ If you have been running an older version of Tripwire, please also read the WHATSNEW file for information on new functionalities. Version 1.2 of Tripwire uses an updated version of the database file (now version 4). Databases used with previous versions of Tripwire are not compatible with this release and need to be regenerated. We suggest that you do this as follows: * take your system to single-user mode * rerun your old version of Tripwire in verify mode using your current database * build and install v1.2 Tripwire * build your new database using your old config file * resume multi-user operation 1.0. Background ================ With the advent of increasingly sophisticated and subtle account break-ins on Unix systems, the need for tools to aid in the detection of unauthorized modification of files becomes clear. Tripwire is a tool that aids system administrators and users in monitoring a designated set of files for any changes. Used with system files on a regular (e.g., daily) basis, Tripwire can notify system administrators of corrupted or tampered files, so damage control measures can be taken in a timely manner. 1.1. Goals of Tripwire ======================= Tripwire is a file and directory integrity checker, a utility that compares a designated set of files and directories against information stored in a previously generated database. Any differences are flagged and logged, including added or deleted entries. When run against system files on a regular basis, any changes in critical system files will be spotted -- and appropriate damage control measures can be taken immediately. With Tripwire, system administrators can conclude with a high degree of certainty that a given set of files remain free of unauthorized modifications if Tripwire reports no changes. 2.0. How to build Tripwire =========================== As of this writing, Tripwire has run successfully on (at least) BSD, OSF/1, Mach, Xenix, and late System V variants of Unix. Tripwire was built and tested on a wide variety of Unix variants. First of all, you should read through this entire README file before you modify any files or try to build the program. This text describes various settings and strategies for configuration and operation. Then, after you've thought about the operation of the system, come back to this section and follow the instructions. The file 'Ported' contains a list of platforms and operating systems where Tripwire has already been successfully ported. If you find your system in the list, note the system settings that were used to build Tripwire. Second, look through the Makefile and make sure that the C compiler and all flag settings are reasonable for your configuration. Most of the potentially tricky system settings should be listed in the 'Ported' file. Next, look in the './configs' directory to find a predefined 'conf-.h' file that matches closest to your operating system. Note this file, because you will be inserting this filename in the './include/config.h' file. If no such file exists, pick one "near" your system type and modify appropriately (then mail it back to us for a future release). ** Don't do anything with this file yet! In particular, don't copy ** it over the config.h file! (Instead, keep reading...) Now that you have chosen your operating system header file, edit the './include/config.h' file to tailor Tripwire to your system. Include the name of the predefined header file closest to your system at the appropriate line in config.h Paths and names of Tripwire configuration files are also set in the config.h file. Make sure you note the locations that Tripwire looks for its configuration and database files; change them for your system, as appropriate. NOTE: We *strongly* urge you to locate the Tripwire configuration files on a disk that can be made read-only with a hardware setting. This will prevent the files from being altered by an attacker. The run-time version of Tripwire should be located in the same place. If you are unable to mark a disk (or diskette) as read-only, you might also consider putting it on a remote partition of a more secure machine, and import it read-only. See the design document for the rationale behind this note if the concept is not obvious. Last, look in the './configs' directory again to find a tw.config file that matches your operating system. These files were custom-tailored to match the file layouts of various vendor-supplied operating systems. If no file in this subdirectory matches your system, choose the one that is closest in nature (e.g., BSD4.3 or SysV.4). Edit this file to include additional files and directories you want to monitor (e.g., local bins and critical databases), to correct paths if you have moved things or if they are mounted from a remote location (check them only on the server!), and to exclude locally-active files from the check. You should probably add the Tripwire binary itself to this file. See the next section for further details. After you have customized your tw.config file, copy it to the location that you specified in your config.h file. Next, simply type 'make' at the top level. Note that all Makefiles in the subdirectories are driven by the top-level Makefile. (i.e., typing 'make' in the ./src directory will probably not work.) Some common problems with building and using Tripwire are addressed in the FAQ file: you may want to read that if you have difficulties. 2.1. Common Tripwire compilation problems ========================================== Tripwire was originally written using ANSI C. However, Tripwire now compiles with K&R, too. All of the prototypes remain embedded between "#ifdef __STDC__" directives. Sadly, compiling under ANSI is sometimes noisier than with K&R. Therefore, go ahead and compile with K&R unless religion dictates ANSI. (The code lints completely clean, excepting the malloc() and exit() return values.) Common compilation trouble-spots are the dirent(S5)/direct(BSD) funkiness and #defines that changed for POSIX compliance. If the Tripwire test suite fails, consider trying the following: - double check that you're including the correct conf-*.h file in your ./include/config.h file. - change the CFLAGS definition in the Makefile so no optimization is done (i.e., remove the "-O" option). - do a "make clean". - try again. If this fails, try a different C compiler (e.g., GCC). It has been noted that newer versions of flex and bison (the GNU replacements for lex and yacc) do not generate code that passes all the test suites using the default Tripwire sources. Calvin Page helped contribute replacement config.pre.l and config.pre.y files that correct this problem. You'll find that using lex usually solves the problems that make the Tripwire test suite fail. If you use flex and bison, make sure you use the gcc compiler to avoid compile-time errors. 2.2. The siggen utility ========================== The siggen utility is provided so users can get signatures of files without having to run Tripwire. The syntax of siggen is simple. siggen [-0123456789aqv] [ file ... ] By default, siggen prints out all ten signatures. However, the signatures can be printed selectively by specifying the signature number on the command line. See the manual page for details. 3.0. Getting Tripwire up and running ===================================== Tripwire runs in either of four modes: Database Generation, Integrity Checking, Database Update, and Interactive Update mode. In order to run Integrity Checking, Tripwire must have a database to compare against. To do that, you must first specify the set of files for Tripwire to monitor. This list is stored in 'tw.config'. 3.1. Creating your tw.config file ================================== Edit your 'tw.config' file, or whatever filename you defined for the Tripwire config file, and add all the directories that contain files that you want monitored. The format of the config file is described in its header and in the man page. Pay especially close attention to the select-flags and omit-lists, which can significantly reduce the amount of uninteresting output generated by Tripwire. For example, you will probably want to omit files like mount tables that are constantly changed by the operating system. Next, run Tripwire with 'tripwire -initialize'. This will create a file called 'tw.db_[hostname]' in the directory you specified to hold your databases (where [hostname] will be replaced with your machine hostname). 3.2. A caveat about your Tripwire database =========================================== NOTE: Tripwire will detect changes made to files from this point on. You *must* be certain that the system on which you generate the initial database is clean, however --- Tripwire cannot detect unauthorized modifications that have already been made. One way to do this would be to take the machine to single-user mode, reinstall all system binaries, and run Tripwire in initialization mode before returning to multi-user operation. This database must be moved someplace where it cannot be modified. Because data from Tripwire is only as trustworthy as its database, choose this with care. We recommend placing all the system databases on a read-only disk (you need to be able to change the disk to writable during initialization and updates, however), or exporting it via read-only NFS from a "secure-server." (This pathname is hardcoded into Tripwire. Any time you change the pathname to the database repository, you must recompile Tripwire. This prevents a malicious intruder from spoofing Tripwire into giving a false "okay" message.) We also recommend that you make a hardcopy printout of the database contents right away. In the event that you become suspicious of the integrity of the database, you will be able to manually compare information against this hardcopy. We have yet to hear of a way for "crackers" to alter an old piece of printout made before they penetrated the system! You may also wish to generate a full set of signatures of the database, the configuration file, and the Tripwire executable using the "siggen" utility. (Be certain to generate siggen's signature too!) Store these on hardcopy for comparison if you need quick confirmation that the files involved have not changed. However, we advise that you do any comparison via a version of siggen stored on read-only media, or encrypted when not in use. 3.3. Testing Tripwire ====================== Tripwire includes a script-driven test suite that checks the top-level build directory against the distribution package. In the ./tests directory, there is a Tripwire database of the entire Tripwire source distribution and a tw.config file. The test script automatically converts the pathnames in these Tripwire files to match those of your system. After converting the files, it then runs Tripwire in Integrity Checking mode. To run the test, simply type 'make test' at the top level. This will invoke the script, and if all goes well, the output of Tripwire matches the expected values that the script provides. In addition to checking all the files in the Tripwire distribution, a number of signature and functional tests are run to ensure the correct operation of the compiled program. 3.4. Running Tripwire as an integrity checker ============================================== Once you have your database set up, you can run Tripwire in Integrity Checking mode by 'tripwire'. 3.5. Keeping your database up-to-date ====================================== A common setup for running Tripwire would mail the system administrator any output that it generates. However, some files on your system may change during normal operation, and this necessitates update of the Tripwire database. There are now two ways to update your Tripwire database. The first method is interactive, where Tripwire prompts the user whether each changed entry should be updated to reflect the current state of the file, while the second method is a command-line driven mode where specific files/entries are specified at run-time. 3.5.1. Running Tripwire in Interactive mode ============================================ Running Tripwire in Interactive mode is similar to the Integrity Checking mode. However, when a file or directory is encountered that has been added, deleted, or changed from what was recorded in the database, Tripwire asks the user whether the database entry should be updated. For example, if Tripwire were run in Interactive mode and a file's timestamps changed, Tripwire would print out what it expected the file to look like, what it actually found, and then prompt the user whether the file should be updated: /homes/genek/research/tw/src/preen.c st_mtime: Wed May 5 15:30:37 1993 Wed May 5 15:24:09 1993 st_ctime: Wed May 5 15:30:37 1993 Wed May 5 15:24:09 1993 ---> File: '/homes/genek/research/tw/src/preen.c ---> Update entry? [YN(y)nh?] y You could answer yes or no, where a capital 'Y' or 'N' tells Tripwire use your answer for the rest of the files. (The 'h' and '?' choices give you help and descriptions of the various inode fields.) While this mode may be the most convenient way of keeping your database up-to-date, it requires that the user be "at the keyboard." A more conventional command-line driven interface exists, and is described next. 3.5.2. Running Tripwire in Database Update mode ================================================ Tripwire supports incremental updates of its database on a per-file/directory or tw.config entry basis. Tripwire stores information in the database so it can associate any file in the database with the tw.config entry that generated it when the database was created. Therefore, if a single file has changed, you can: tripwire -update /etc/newly.installed.file Or, if an entire set of files that made up an entry in the tw.config file changed, you can: tripwire -update /usr/local/bin/Local_Package_Dir In either case, Tripwire regenerates the database entries for every specified file. A backup of the old database is created in the ./databases directory. Note that Tripwire can now handle arbitrary numbers of arguments in Database Update mode. This was added in version 1.0.1. The script ``twdb_check.pl'' was added in version 1.2 as an interim mechanism to ensure database consistency. Namely, when new entries are added to the tw.config file, database entries may no longer be associated with the proper entry number. The twdb_check.pl script analyzes the database, and remaps each database entry with its proper tw.config entry. The twdb_check functionality will be put into the Tripwire program in a future release. 3.6. A quick-checking mode =========================== Tripwire allows you to selectively skip certain signatures at run-time through a command-line option. For example, if you wish to run Tripwire on an hourly basis, even performing only MD5 checks might be computationally prohibitive. For this application, checking only the CRC32 signature might be desirable. To do this, assuming that only MD5, Snefru, and CRC32 were used when the database was initialized, you would type: tripwire -i 1 -i 2 This tells tripwire to ignore signature 1 and signature 2. Furthermore, for daily Tripwire runs, you could specify using only MD5 and CRC32. Finally, for weekly runs, you could run Tripwire with all three signatures. To find added or deleted files, with no signature checking, use: tripwire -i all 4.0. Some Tripwire scaling hints for using Tripwire in large sites =================================================================== The tw.config.5 manual page describes in detail the syntax supported by the tw.config file. Tripwire includes features that offer similar functionality to the C-preprocessor, and offer other directives that assist in the use of Tripwire at sites consisting of hundreds of workstations with local disk. 4.1. The tw.config grammar =========================== These commands are briefly described below: @@define VAR VALUE @@undef VAR @@ifhost HOSTNAME @@ifnhost HOSTNAME @@ifdef VAR @@ifndef VAR @@else @@endif @@include FILENAME Furthermore, the tw.config grammar also supports logical expressions. For example, you could have something like this in your tw.config file: @@ifhost spam.cc.purdue.edu || weiner.cc.purdue.edu ...entries... @@endif Besides the obvious cpp-like functionality, you can use @@define to create strings that are interpreted at run-time. For example: @@ifhost mentor.cc.purdue.edu @@ define TEMPLATE_S +pinug-cas0123456789 @@else @@ define TEMPLATE_S +pinug012-cas3456789 @@endif /etc/tw.loginfo @@TEMPLATE_S 4.2. How you might use these directives ======================================== Because Tripwire allows run-time interpretation of the tw.config file, it becomes possible for many different hosts to share the same tw.config file. This allows the maintenance of Tripwire configuration files to still be manageable in a large, heterogeneous environment. Although each host must still have different database file, this has few consequences except for disk space. 5.0. Notes on signature routines ================================= The RSA Data Security, Inc. MD5, MD4, and MD2 Message Digesting Algorithm, Snefru (the Xerox Secure Hash Function), SHA (the Secure Hash Algorithm), and Haval code have been changed to eliminate big-endian and little-endian run-time specific routines. These changes have been sent back to the authors, but we are not aware of any buy-backs yet. Until then, there will remain some differences between the code in this package and their respective virgin distributions. 5.1. Performance vs. security ============================== Normally, only one checksum per file would be enough to detect changes. For purposes of speed, an easy to calculate checksum would be preferred. However, most easy-to-calculate signatures are also easy to defeat if a determined attacker wished to do so (see the chart in the design document to see how easy this is to do with random comparisons). Tripwire includes six very difficult-to-forge signature algorithms, as well as two more conventional CRC routines. Using the default setup of recording two signatures (MD5 and Snefru) for each database entry gives very, very strong assurance that a file has not been tampered with. For tampering to have succeeded, the attacker would have had to have changed the file and added appropriate padding characters to recreate *both* checksums without also altering the size of the file. To do this at random might not even be possible with the MD5 and Snefru checksums used. Those two algorithms have not been exhaustively analyzed, but both are known to be strong message authentication codes. This added assurance is at a heavy price, however. The two algorithms, and Snefru in particular, are expensive to calculate. To run the MD5 and Snefru algorithms against every file is likely to be overkill for almost all systems (unless you have cpu cycles to spare!). Both checksums should be run over only the most critical files...like the Tripwire database and program, and perhaps each setuid and setgid file on your system. All other files can be checked with MD5 (or Haval) alone for much faster operation and a high level of assurance. The task of altering a file and recreating the original MD5 checksum is also very difficult, and it is unlikely that any but the most determined, sophisticated, and well-equipped attacker would be able to do it in finite time. To decrease the execution run-times of Tripwire, consider modifying your tripwire.config entries to ignore the Snefru (signature 2) attribute on files that do not need such stringent monitoring. This will skip the computationally-expensive Snefru signature collection entirely. Balancing this equation of security vs. speed is a decision best made by the administrator, most closely tailored to his/her site needs. For the extremely paranoid, Tripwire includes the MD2, MD4, SHA, and Haval signature algorithms, as well as the 16 and 32-bit CRC algorithms in its arsenal. Be forewarned, however, that MD2 is an order of magnitude slower than even Snefru, and probably guarantees no greater integrity checking. We include all these routines, however, so you can pick what you feel to be most appropriate for your site. You may wish to add other routines as checksum/signature generators. For instance, if you have a fast DES implementation (including chip-based generation), you might wish to encrypt the file using CBC mode and some fixed key, saving the final 128 bits of output as the signature. The configuration file routines have several signature flags that are currently bound to a null function, so there is room for this expansion if you wish. Clearly, with eight different signature algorithms at your disposal, Tripwire offers considerable flexibility in ensuring data security. Tripwire makes maintaining a trivial CRC database equally easy to administer and check as a full (but perhaps less practical) eight-signature database. The following section describes each of the eight signature algorithms. 6.0. Signature routines ======================== Tripwire ships with eight signature routines. This section briefly describes each signature routine. This is by no means an authoratative list, but it does attempt to give some background on each of the signature routines provided: MD5, Snefru, MD4, MD2, SHA, and Haval are all examples of message-digest algorithms (also known as one-way hash functions, fingerprinting routines, message authentication codes, or manipulation detection codes). They employ cryptographic techniques to ensure that any small change in the input stream results in immediate and widely diverging output. This way, even a small change in the input results in large change in the output. Therefore, any unauthorized, malicious, or accidental change will be evident. Furthermore, because these algorithms use a 128-bit or larger signature, using a brute-force attack to introduce a deliberate change in the file while trying to keep the same signature becomes a computationally infeasible task. The CRC algorithms, on the other hand, use simple polynomial division to generate the checksums. While this technique is very fast, the mathematics of this technique is well-understood. Additionally, since the signature space is so small (usually 16 or 32 bits), a brute-force search for a CRC collision is well within the capabilities of most workstations. There are currently several programs in the public domain that can, for any given input file, provide a different output file with the same CRC signature in 30 seconds or less. All observed timing measures provided for the signature routines were performed on a Sequent Symmetry with ten 16 Mhz 80386 processors. The numbers provided are simply an informal gauge of throughput, rather than any authoritative metric. 6.1. MD5 ========= MD5 is the RSA Data Security Inc. Message-Digest Algorithm, a proposed data authentication standard. The Internet Draft submission can be found as Internet Working Draft RFC 1321, available via anonymous FTP from NIC.DDN.MIL or from RSA.COM as ~/pub/md5.doc. MD5 attempts to address potential security risks found in the speedier, but less secure MD4, also by RSA Data Security Inc. MD5 was designed as a more conservative algorithm that backs "away from the edge" in terms of risks from successful cryptanalytic attack. MD5 generates a 128-bit signature, and uses four rounds to ensure pseudo-random output. Observed throughput is about 70 Kbytes/second. Currently, MD5 is considered by many to be a state-of-the-art signature algorithm. 6.2. Snefru ============ Snefru, the Xerox Secure Hash Function, was developed by Ralph Merkle at Xerox PARC. As an incentive to find a Snefru crack, there is a $1000 cash prize promised to anyone who can find two sets of input that map to the same signature. This reward has remained unclaimed since April 1990, when the 2-pass version of Snefru was broken by Eli Biham, a Ph.D. student of Adi Shamir. Currently, Ralph Merkle recommends using only the 4-pass version of Snefru, if not the 8-pass version. The Snefru README states, "Further study of the security of Snefru is required before production use is advisable." As shipped with Tripwire, Snefru is configured to run in 4-passes. Version 2.5 is the latest version available, and is the version included with Tripwire. Snefru is slower than MD5, but is recommended as a backup for MD5 as a primary signature. As configured, Snefru runs at about 31 Kbytes/second. Snefru can be obtained via anonymous FTP from arisia.xerox.com in directory /pub/hash. 6.3. CRC-32 ============ Cyclic Redundancy Checks have been the long been the de facto error detection algorithm standard. These algorithms are fast, robust, and provides reliable detection of errors associated with data transmission. It has been shown that CRC-32 has a minimum distance of 5 for block lengths of less than 4K. However, this decreases as the size of the blocks increases. Therefore, using CRC-32 on long files is certainly a misapplication of this signature algorithm. However, CRC-32 is provided as a fast and speedy alternative to the slower message-digest algorithms. The version of CRC-32 included with Tripwire was written by Gary S. Brown. This CRC-32 implementation runs at about 111 Kbytes/second. 6.4. CRC-16 ============ CRC-16 is the predecessor to CRC-32, using only 16 bits to store to the remainder of the data and the generator polynomial. CRC-16 is typically at the link level, usually done in hardware to detect transmission errors. This CRC-16 implementation runs at abut 131 Kbytes/second. 6.5. MD4 ========= MD4, the RSA Data Security Inc. Message-Digest Algorithm, is the predecessor to MD5 described above. It was also submitted as a standard data authentication algorithm, and is described in the Internet Working Draft 1320. The MD4 algorithm was designed to exploit 32-bit RISC architectures to maximize throughput. On a Sun SparcStation, throughput rates of over 1.4 Mbytes/second are achieved. MD4 can be obtained via anonymous FTP from RSA.COM in ~/pub. On a Sequent, MD4 throughput is about 332 Kbytes/second. 6.6. MD2 ========== The RSA Data Security, Inc. MD2 Message-Digest Algorithm was created as part of the Privacy Enhanced Mail package -- a package designed to authenticate and increase the security of electronic mail. Like the other algorithms by RSA Data Security, Inc presented here, MD2 generates a 128-bit signature. The MD2 algorithm is quite slow. On a 16 Mhz 80386, expect only 3 Kbytes/second. It is not clear that using this slower algorithm instead of MD5 brings any comparative advantage. The license for MD2 specifically states its use is exclusive to the Privancy Enhanced Mail package. Provisions have been made with RSA Data Security, Inc. for its inclusion and use in Tripwire in its present form. Note that MD2 is not in the public domain. 6.7. SHA/SHS ============= SHS is the NIST Digital Signature Standard, called the Secure Hash Standard. It is described in NIST FIPS 180. We refer to it as the SHA, or Secure Hash Algorithm, because we are using a non-certified implementation and we cannot claim standards conformance. SHA is about one-half as fast as MD5. It has been noted that SHS appears to be largely based on MD4 with several key enhancements, not all implemented in MD5. The mid-1994 correction to the algorithm at the behest of NSA (reflected in the default version compiled into Tripwire; see sigs/sha/sha.h) raises some questions about the overall strength of both SHA and MD4 in the minds of some cryptographers. 6.8. Haval =========== Haval was written by Yuliang Zheng at the University of Wollongong, and is described in Y. Zheng, J. Pieprzyk and J. Seberry: ``HAVAL --- a one-way hashing algorithm with variable length of output'', Advances in Cryptology --- AUSCRYPT'92, Lecture Notes in Computer Science, Springer-Verlag, 1993. Haval is shipped with Tripwire configured similarly to the other signature algorithms: 128 bit signature using four passes. Configured this way, Haval throughput is approximately 100K/sec. (30% faster than MD5.) 6.9. (null) ============ Well, sig_null_get() is not really a signature algorithm. Instead, it is a place holder for unused slots in the signature array. It will always return a single character, ``0''. 7.0. Feedback and bug-reports ============================== Please send any bug-reports, questions, feedback, or any comments to (tripwire-request@cs.purdue.edu). One or both Genes will try to answer questions as expeditiously as possible. 8.0. User contributions and experiences ======================================== The ./contrib directory contains several programs contributed by users during the beta-test period. Each program is accompanied by a README file written by the program author. Both Genes are willing to serve as clearinghouses for utilities that augment the Tripwire package. If you have something that you would like included in the Tripwire package, please contact either Gene Kim or Gene Spafford at the email addresses listed in the previous section. 8.1. Reports on subverting Tripwire ==================================== In early 1994, an "underground" hacker newsletter described how Tripwire database updates can be done by an intruder to prevent subsequent integrity checking runs from detecting tampered files. This attack was already documented in this README file, as well as in our design document. However, we use the appearance of this report to underscore the necessity to secure your database using physical means. (Mounting a file system read-only on the client side is less secure than exporting the file system read-only on the server side, both of which is far less secure than placing the database on some physical read-only media.) The afforementioned report also documents that Tripwire databases are usually stored in "/usr/adm/tcheck." If you wish to conceal Tripwire operation on your machine, you may want to use less predictable locations for Tripwire files. To the best of our knowledge, no site has been compromised where Tripwire was installed according to our recommendations without Tripwire reporting the attack. 9.0 Acknowledgements ===================== Dan Farmer, formerly of Sun Microsystems, Inc., for providing answers to questions of taste, and providing some impetus to finish this project during the summer of 1992. Shabbir Safdar for actually running early versions of Tripwire that popped up on an hourly basis. We also thank him for trying this on a few of the more exotic architectures around Purdue. Steve Weeber of Lawrence Livermore National Laboratory for insight into what sort of tools the Dept. of Energy has developed for in-house use, and comparisons of their functionality with Tripwire. Ralph Merkle of Xerox PARC for information on the Snefru one-way hash function. One of the directory printing routine in utils.c comes from the COPS package. It was from crc_check.c by Jon Zeeff. Eugene Zaustinsky for helping GeneK finally get all the signature routines right. It took three iterations and two patches, but things are finally kosher. This provided motivation for a more rigorous signature test suite, beyond just checking the signatures against the distribution build. Sam Gassel, Edward DeHart, Drew Gonczi, Rik Farrow, Jim Napier, Drew Jolliffe, John Rouillard, Alain Brossard, Eric Bergren, Patrick Sullivan, Nora Hermida, Juergen Schmidt, Debbie Pomerance, Michael Hines, Tim Ramsey, Georges Tomazi, Mitchell Marks, Philip Cox, Kevin Dupre', Chris Kern, and Eugene Zaustinsky helped in getting the Tripwire v1.1 release in shape for our December 1993 release. The 125 helpful beta testers that stuck with us during the six-week testing period. They put up with bugs, ever-changing interfaces and database file formats, and in one case, a flurry of conflicting patches in a thirty-minute period while GeneK and Spaf took turns saying, "Uh, oh." Tripwire v1.2 benefitted from the advice from many people. Asokan, Casper H.S. Dik, Paul Hilchey, Tom Orban Cal Page, Paul Szabo, and Eugene Zaustinsky all contributed code that we added to the release. (We list their contributions in the WHATSNEW file.) In addition, we thank the following people. Eric Berg, Eric M. Boehm, Lothar Butsch, John Crosswhite, Jason Downs, Peter Evans, Jon Freivald, Kevin Johnson, Lothar Kaul, Terry Kennedy, Chris Kern, Paul Madden, Fred Marchand, Mitchell Marks, Jim Moreno, Tom Orban, Lorraine Padour, Calvin Page, Tom Painter, Roger Peyton, Peter Phillips, Keith W. Rickert, Jim Roche, D Seddon, Paul Szabo, Gene C Van Nostern, John Wiegley, Robert Wilhite, Alain Williams, Eugene Zaustinsky, We appreciate the heroic effort of the Tripwire beta testers who suggested functional additions to Tripwire, found and hunted down bugs, and refined Tripwire beyond the authors' expectations. Special thanks go to: Walker Aumann, Lance R. Bailey, Michael Barnett, David Barr, Greg Black, Adrian P. van Bloois, J. Dean Brock, Kurt Cockrum, John Cristy, Jim Duncan, David S. Goldberg, Johannes Gronvall, Tom Gutnick, Michaela Harlander, Andreas Haug, Bill Henderson, Jim Hendrick, Norman Hill, Paul Joslin, Poul-Henning Kamp, Leslie Kordas, Simon Leinen, Philip Yzarn de Louraille, Stephen Mahler, Fletcher Mattox, Ken McDonell, Wes Morgan, Phil Moyer, Dan O'Neill, Joe Polcari, Phillip Porch, Brad Powell, W. Purvis, Daniel Ray, Dean Rich, Bill Romine, John P. Rouillard, Rich Salz, Christopher Samuel, Pete Shipley., David W. Smith, Harlan Stenn, Margarita Suarez, John G. Sutton, Tim Tessin, John Wagner, David Wiseman, Irving Wolfe, Stephen M. Youndt Extra kudos go to Ken McDonnell and Rich Salz for "raising the bar" of code quality through their wonderfully meticulous and insightful code-reviews during the beta-test period. E. Clinton Arbaugh provided extremely helpful advice and bug reports for the third patch release. He contributed greatly towards refinement in v1.0.4. GeneK and Spaf want to apologize in advance to anyone who sent us patches, comments or configuration info and whose name doesn't appear (but should). Please write to us and so we can correct the situation! Gene & Gene Kim & Spafford November 2, 1992 (gkim@cs.purdue.edu) (spaf@cs.purdue.edu) Last updated July 17, 1994