First of all, let me note that there exists two different versions of Tripwire. There is a commercial version available from http://www.tripwire.com. There is also a free version available for Linux fromhttp://tripwire.org and http://sourceforge.net/projects/tripwire/.
Many of the differences between the Open Source version of the software and the commercial version are outlined in the Tripwire FAQ, which can be found here: http://tripwire.org/qanda/faq.php According to the previously mentioned FAQ, there are no plans for Tripwire Inc. to release an Open Source version of their software for any platforms other than Linux. Tripwire for Linux is released under the GPL (General Public License- which can be found here).
My impression of the GPL leads me to believe that you can modify the source code in any manner that you see fit as long as you surrender the code that you have written to the project. This is an *extremely* simplified interpretation of the GPL, however it makes me wonder, could Tripwire be ported to other operating systems, legally? I don’t know, however I supect that porting this application is no trivial matter. Any of you who may have a better answer, please let me know so that I can let other readers know.
This article will focus on Tripwire for Linux, however most of what is discussed here should be applicable to the commercial version as well.
Tripwire is an intrusion detection system (IDS). Tripwire is designed to let you know that your machine has been compromised and what files on your machine have been modified. Tripwire is not a firewall and is not a replacement for existing security measures that you may have in place already. Tripwire is used to complement other systems in a total security solution.
One of the most important features of Tripwire is the email alert. Tripwire will email whomever you have configured it to as soon as it detects an intrusion. A quick response will allow the administrator to remove that machine from the network and, through the use of Tripwire, perform an integrity check (i.e. what files were compromised…).
Because of its file monitoring capabilities, many admins are using Tripwire for a variety applications other than intrusion detection.
Admins can monitor machines to verify that unauthorized software has not been installed on the machines that they are responsible for.
You can also use Tripwire to verify system compliance with your security policies. To do this, you would first set up an ideal system in a lab environment. Once you have done this, you would install Tripwire and create a baseline database. You could then compare this database with other systems to verify compliance.
You can use Tripwire for damage assessment and recovery. By having a list of files that have been compromised, you will know what files to restore from backup, or at least be able to make an educated decision as to whether or not you may be better off reinstalling the operating system. Having that choice is a really nice feature of Tripwire.
Lastly, Tripwire can be used for forensics of a compromised system. With Tripwire, the user can provide evidence that can be used for prosecution of attackers.
Tripwire is made up of several components. Basically, you have configuration files, policy files, report files, and the database that was made when Tripwire was first installed.
The configuration file contains information about the location of Tripwire data files, rules governing email notification and other system specific information. A good part of this information is generated during the initial installation, however much of it can be changed afterwards.
All of the rules that you define, will be defined in the policy file. This is where you tell Tripwire to monitor certain objects, and describes under which conditions Tripwire should notify you.
Report files are generated every time you run a system integrity check. This is where you will see changes that have taken place on the system that you are monitoring.
Lastly there is the database file. This is the actual database that you create immediately after installing Tripwire. This database can be modified, however it should only be created once. In other words, suppose that you have initialized the database only to realize that something was not configured correctly. You would not want to delete this file. Instead, you would want to make changes to your configuration and apply it to the database. More on that later.
It is important to note that although it would add one more step to the would-be cracker’s to-do list, unless you encrypt and/or hide these files, Tripwire could still be bypassed.
Tripwire thought of this. This is why Tripwire encodes all of its files with an El Gamal 1024 bit encrypted signature. This is done through the use of a paired set of keys, with one public key and one private key. If you do not know what this is, find out more here.
There are two sets of keys. One is the site key, which is used to protect policy and configuration files accross a site. You will also have a local key pair, which is used to protect the database file and any report files that you may have.
With the site key, a sytem administrator can develop a single policy file for an entire site. That policy file would be accessible with a passphrase that only that administrator would know.
In order to give you an idea of how secure 1024 bit encryption is, I was going to compare it to something that you could relate to. I can’t do that. The best I can do is the following comparison. If you were to have started a computer trying every possible combination, once per nano-second (one billionth of a second), since the theoretical beginning of the universe as we know it (4 billion years ago), it would have completed about one percent of all the possible combinations for 128 bit encryption. At that rate, we would have worked through every possible combination in about 2.7 trillion years. 1024 bit encryption is much, much more complex than that.
Jay Fougere is the IT manager for the Murdok network. He also writes occasional articles. If you have any IT questions, please direct them to Jay@https://murdok.org.
