Tripwire

Making tripwire more useful -
Centrized tripwire analysis

Tripwire is an essential component for any security design - it provides a quick and simple meathod to determine the integrity of the physical system. There are a number of 'classic' problems with using tripwire:

Typically the tripwire binary, config file and database are located on the same machine that is being tested. The documentation suggests that this is not a good idea, but most implementations seem to resemble this way anyway.
Scalability. If there are more than a few machines on the network, the ammount of data (normally in the form of emails)can take too much time every day to dig through.
The database is maintained on the centeral host rather than the client end.

I would like to point out that most of this work is just a slightly simplified version of the work done by Yunliang Yu ([email protected]), published on the web site http://www.math.duke.edu/~yu/tw. I made a limited number of changes based on the notion that this system would have to scale arbitrarily large, and bandwidth issues for moving tripwire binarys would become an issue.

The general problem that we set out to solve was to address a large number of appliences scattered across the internet. These machines would be connected via a series of ssh connections back to the centeral administrative area. We modified the standard tripwire source with the Yu patch (thanks!) in order to be able to operate with the following options:

-tsig: Expected MD5 hash of the tripwire executable. If it does not match, flag error and exit.
-csig: Expected MD5 hash of tripwire config file. This file contains the listing of all the files and directories that will be watched by the application. Like tsig, the app will error out if tis fails.
-d -: The database of expected values id passed in from the central administrative host via standard in. This way there is no way for a compromised host to pass trojened libs/binarys by modifying or replacing the local database.

Keeping individual databases for the possibly thousands of hosts would be quite complex. Instead, we leverage the appliance nature of the client hosts and just need to keep one database for each release number. This will grow at a much slower value than the number of clients. Since we control the upgrade process from the centeral area, we will always know at exactly what relaese level the client is at.

From the centeral area, we issue a command similar to:

cat tripwire.db | ssh -i id_file -l logger_id client.host.name "/usr/secure/tripwire -tsig -csig -d - > ../logs/output"

and then catch the rturn stream for processing into a stream of HTML via a (far too) simple script. Look here for the script.

The final output can be fit together into a web page that can be looked at every morning, allowing for hundreds of hosts to be scanned in little or no time.

Again, all the real work has been done by Yunliang Yu so look at his page for more details.

Back

Hosted by www.Geocities.ws