Tripwire Results

I.  Downloading and Compiling

In order to run our simulation with tripwire, we first had to download it.  Downloadable versions are available at http://www.tripwiresecurity.com/.   Once downloaded, we read the README file that accompanied the download.  The README file gave rather good instructions on how to compile the Tripwire program to run on our Linux machine, although we did run into problems when it required yacc and lex.  We solved the problem by downloading the aforementioned files from our real server for the Computer Science Department here at Baylor.  We ran into compilation errors with symbols redefined, but we used the precompiler command #ifdef to comment out the tripwire's redefinitions.

II. Tailoring, Initializing, and Testing

The README file explained how to tailor the program to keep a database on any file (i.e., make sure that these files have not been tampered with.)  We used a dummy file, trip_test, to test the tripwire system.  The file had the following set of simple lines:

We ran the tripwire diagnostics and received the status that nothing had changed.  Everything seemed set to go for our "hacking" test.

We decided now to proceed and "hack" into the system using a "stolen" password using telnet to gain access.  We changed the file by adding a single x to the beginning of the file, so that it now looked like:

III. Our Setup

We ran tripwire using only MD5 as a cryptographic signature for each file to be watched.  We also did not implement many of the safety features since we are the hackers and we decided not test those aspects of security (for example, the good people that brought us tripwire highly recommended that the tripwire files be placed in a read-only disk or other read-only NFS mounted server.  Since we did not want to test this (since it deals with another issue entirely), we did not implement this.)

IV. Results

Now that the tripwire system had been installed and initialized, then followed by the file tripwire is watching "hacked" into, we ran the tripwire diagnostics.

The following message appeared:

This automatically lets me know that the "system" file has been changed, by whom, when, the change in size, and the cryptographic signatures of the two versions of the file.  Notice that a single character changed the signature completely.  This makes it incredibly hard for a hacker to hack the system without tripwire catching it.

IV.  Other Words

Several questions might be raised in the back of your mind.  This section will attempt to answer the most common.

1) How does one prevent a hacker from messing with the tripwire system?

The tripwire system should be moved to a read-only disk and only updated (the disk must be switched to Read/Write) when the system is in single-user mode.

2) Using MD5 as the only cryptographic signature is rather safe, but I need to be more safe.  Can I do that?

The tripwire system can be configured to use a number of different cryptographic methods, and in fact multiple methods can be used in order to have a higher amount of confidence that your file(s) have not been hacked.  There is a cost, though, since each method requires a lot of time to derive the signature.

3) How do I prevent hackers from changing files?

Tripwire does not prevent hackers from changing files, but instead alerts the system administrator to files that have been hacked. 

V. Conclusions

Tripwire does an excellent job of keeping track of the natural state of the system's files.  Tripwire seems to be very portable, very useful, and incredibly helpful in registering attacks. It should be