JCSecurity

Tools Required: Linux, Tripwire
Tools Optional: Sendmail

This is a [longish] guide on how to correctly configure and use Tripwire on Linux to improve the OS security. Tripwire is both an Intrusion Detection System and a great admin tool, there is a commercial version of it here but I will be discussing the open source version hosted on Sourceforge.

So in short, you give Tripwire a list of files you want to ‘protect’ and at configured intervals Tripwire scans these files and will alert you of any changes to them. It essentially monitors the integrity of critical files. Consider the scenario where an attacker breaks into your system, one of his goals will be to enable a means for future access. Lets say he does this in a covert manner by writing a backdoor into your FTP server and recompiling it leaving no visible trace. Tripwire could be configured to watch the FTP daemon files and changing a single bit will course an alert to be raised. Sounds pretty useful right? It is. Im told however that Tripwire sees limited deployment in production servers (can’t comment if this is true or not though), some reasons for this may be a) It’s a very paranoid piece of software b) regular file changes can cause an obscene number of false positives.

Tripwire works by using a cryptographic hash function to generate a checksum of specified files, this checksum goes into a database and that database is encrypted. So even if you get rooted, an attacker shouldn’t be able to modify the checksum database (key management issues here!). A hash function will take an arbitrary sized input value (a file) and will output a fixed size hash value. A single bit change in the input should reflect a major change in the outputted hash value (Avalanche Effect), so they make a pretty good way of detecting a modified file

Ok, so this tutorial will configure Tripwire to monitor a system directory and alert if integrity changes. Also, for full effectiveness this should be applied at a fresh install, what’s the point if your files may already be compromised?

I will assume for this example you have some important FTP server files in /root/demoFTP.

Installation:

- Download the Tripwire source & extract

Next we need to edit the install script slightly, edit the file install/install.cfg we need to disable the use of sendmail and enable smtp instead, if you have sendmail running and configured on your server ignore this step. Changed section should look like this (don’t worry about a valid server, I wont be covering email alerts here):

Now we can configure the build process & compile (edit the install directory to your preference):

Next is the installation, run ‘make install’ as root, as part of this we will need to accept the license agreement and configure some passwords for the database.

Ok, so you’ve just entered 2 (strong) passwords:

• Site: Secures configuration and policy files
• Local: Secures database and report files

That’s the installation all done, it’s now installed to /opt/tripwire

Configuration:

The main file we are concerned with is the Tripwire policy file: /opt/tripwire/etc/twpol.txt

Below is my clean, cut down bare essential config for this example (alot of the default comments are left in to explain the syntax. The specific rule for this tutorial is at the bottom.

Our rule (there are also included rules for checking the Tripwire configs & binaries):

This defines a rule to monitor the directory /root/demoFTP, $(ReadOnly) is the property mask and is defined and explained higher in the config (ReadOnly = +pinugtsdbmCM-rlacSH), basically its a very strict rule and stores multiple hashes, file owner information, sizes e.t.c. (recurse=2) tells the rule to recurse to a depth of 2 inside the directory. So a single bit change inside this directory will raise an alert.

In a proper deployment, you would set up rules to monitor all your critical global configs and system binaries, for example: /etc /usr/bin /usr/sbin /home

Next we have to compile this policy file and initialize the database for the first time.

We now have a secured integrity database with full details of /root/demoFTP

Running A Scan & Report Generation::

First for testing purposes change something in a file inside /root/demoFTP, i had a config file inside it and just added some junk to it.

To check the integrity of the files, simply run ‘./tripwire –check’ this will generate a report file. The generated report should show that the integrity of config.txt has changed.

Here is my report:

Clearly the report shows the file “/root/demoFTP/config.txt” has been modified

Updating & Regular Scans:

If you change a file under a monitored directory, you will need to update the database. This is done using an interactive check, run “./tripwire –check –interactive” and the report will be loaded up in vi, here you can edit which files will be updated in the database. Quit vi with :wq and the database will be updated.

Checks should be performed at regular intervals, maybe every couple of hours or once a day depending on factors such as server performance and data sensitivity. Best way to do this is by adding “/opt/tripwire/sbin/tripwire –check” as a system cron job.

Reports will be saved to /opt/lib/tripwire/reports, and you can also get e-mail alerts if you configure smtp or sendmail during installation, I wont go into that though.

Conclusions:

So now Tripwire will monitor /root/demoFTP/* at regular intervals, by reading the reports/alerts we will know if an attacker breaks in and modifies any of these files, apply this idea system-wide to critical files and you have a strong level of integrity acting as an intrusion detection system

Limitations:

Tripwire is reliant on your OS, that is by trusting Tripwire you are trusting your operating system. What can cause mistrust in an OS? A Rootkit! Tripwire reads files when it needs to make an integrity check, if you wanted to you could make a stealth rootkit to hijack the Linux open() syscall, so when the software tries to verify the integrity of an attacker modified file, you redirect the open() call to a hidden old version. Tripwire will ok the hash and be non-the wiser. This attack is discussed in detail here, implemented in a kernel module.

Another limitation to be aware of is the choice of hash function. If you pick a weak hash like MD4 or MD5 with known collision attacks then you are asking for trouble Use something with decent strength > 256bits and you will be significantly better off (SHA-512, Whirlpool).