Exercise 3: Tripwire
Description
The first objective of an attacker is to obtain access to your system. The second objective is to retain that access, even if you close the hole she entered. To accomplish this, an attacker will often install a rootkit.
A rootkit is a collection of modified system binaries that are designed to hide the attacker's activities on your system. Often, a modified login program is installed with a backdoor account for gaining access. A hacked version of ls is installed to hide the attacker's files from view. The ps routine can also be altered to prevent you from seeing the attacker's processes running on your system.
In this scenario, the question becomes, "How do you know if you can trust the information your system is giving you?" You need to be able to prove that critical programs are unaltered. It is the objective of host-based intrusion detection systems, such as Tripwire, to provide that proof.
Tripwire creates a database of advanced mathematical checksums to take a snapshot of a system's file properties and contents. A checksum is nothing more than the result of a complex mathematical calculation that uses the file's properties and contents as input. The calculations are designed so that even the smallest change of a single bit results in a vastly different result. Tripwire uses MD5, which is currently considered one of the strongest algorithms, to calculate checksums.
The key to using Tripwire successfully is to install it and calculate the checksums on the system before it is put into production or connected to the network. Otherwise, you could be calculating checksums for previously hacked files, which would render Tripwire useless. It is also imperative to regularly update the checksum database. Changes will be legitimately made to critical files, such as the password file. In order for Tripwire to maintain its value, it must reflect these changes. It is also vital that the database be secured in such a way that an attacker cannot alter it. CD-R drives or removable, write-disabled discs are often used for this task.
Starting with Red Hat 7.0, Tripwire has been included as part of the Linux license.
Objective
The objective of this exercise is to introduce you to the installation, configuration, and use of Tripwire as a host-based intrusion detection system.
Requirements
-
Hardware
Intel-based PC running Red Hat Linux 7.2 -
Software
Tripwire v2.3.1-5, available on CD 1 of the Red Hat Linux 7.2 distribution
Challenge Procedure
For this exercise you are going to perform the following steps:
Install Tripwire.
Complete the Tripwire installation and create Tripwire passwords.
Configure Tripwire.
Test Tripwire.
Schedule a nightly Tripwire check.
Challenge Procedure Step-by-Step
The following are the detailed steps you are going to perform for this exercise:
-
The first step is to install Tripwire. Log in to a Gnome session as root. Insert CD 1 of the Red Hat Linux 7.2 installation discs. Open a command prompt by clicking the Terminal Emulation icon, which is located on the Start bar. If you have not already done so, create a directory to hold the files that will be used by the exercises in this book:
-
Change the directory to the one you created in the previous step:
-
Copy the Tripwire distribution to the exercises directory:
-
Install Tripwire with the following command:
-
Next, complete the Tripwire installation and create Tripwire passwords. Use the following command:
-
Create the site keyfile password.
-
Create the local keyfile password.
-
Sign the Tripware configuration file.
-
Sign the Tripware policy file.
-
Next, you'll configure Tripwire.
-
Install the default policy:
-
When prompted, enter your site password. Then, generate the initial checksum database:
-
Create a list of files to remove from the policy file by running the following command:
-
Open a second terminal emulation session. In it, list the files that need to be deleted from the policy file:
-
In the original terminal emulation session, edit the default site policy file:
-
Set the HOSTNAME variable to the system name. Find the HOSTNAME entry by pressing the forward slash (/) key and searching for localhost.
-
Enter cw to change localhost to Linux-Lab or the name of your system.
-
Press Esc to exit change mode. Lock files can change with every reboot, thus, comment out their entries with the following command:
-
Search for the remaining file entries to delete by pressing the forward slash key. Your cursor moves to the bottom-left corner of the screen. Type in the filename. Put a backslash (\) in front of the forward slashes in the filename. You can save keystrokes by just entering the filename. If you are not taken to the correct entry, just press n until you are.
-
Position the cursor on the first character and press i to enter insert mode. Comment out the entry by inserting the # symbol. Press Esc to exit insert mode.
-
Repeat steps 1920 for each entry in the delete files.
-
Now, you'll test Tripwire. Create a new root user with the following command:
-
Run a Tripwire check:
-
Knowing a root account has been added, edit the passwd file:
-
Press G to go to the end of the file. The last entry should begin with badguy.
-
Press dd to delete the badguy account. Then, press ZZ to save the changes and exit vi.
-
Next, you need to schedule a nightly Tripwire check. Start the crontab editor:
-
Press the a key to add an entry to root's crontab file. Add the following entry:
-
Press ZZ to save the entry and quit the crontab editor. Verify that the job is scheduled with the following entry:
-
If you set cron to test the check, after sufficient time check your mail:
mkdir /usr/local/exercises
cd /usr/local/exercises
cp /mnt/cdrom/RedHat/RPMS/tripwire-2.1.3-5.i386.rpm .
rpm i tripwire-2.1.3-5.i386.rpm
/etc/tripwire/twinstall.sh
Identify unnecessary system files that should not be validated with the following steps. This process is done to eliminate the false alarms that result from unnecessary file entries that are included with the default policy file.
/usr/sbin/twadmin -m P /etc/tripwire/twpol.txt
/usr/sbin/tripwire m I
/usr/sbin/tripwire m c | grep Filename > deletefiles
vi deletefiles
vi /etc/tripwire/twpol.txt
:g/\/var\/lock/s//\#\/var\/lock
After the unnecessary files have been commented out, press ZZ to save the changes and exit vi. Repeat these steps until the unnecessary files have been eliminated from the policy.
echo "badguy:x:0:0:Bad Guy:/bin/bash" >> /etc/passwd
WARNING
Make sure that you enter both > symbols, or you will eliminate every other entry in the password file.
/usr/sbin/tripwire m c
Tripwire should detect that the /etc/passwd file has been changed.
vi /etc/passwd
crontab e
0 1 * * * /usr/sbin/tripwire m c | mail root
NOTE
This entry tells the scheduling function, cron, to run the Tripwire check every day at 1 a.m. By default, the output will be mailed to root. You can test the scheduling by changing the time it should run to a couple of minutes in the future. In the previous entry, the 0 corresponds to the minute, and the 1 is the hour the command should run. Change these values to change the time when cron should execute the check.
crontab l
Finally, check the report that is generated.
Additional Reading
Stancin, Aleksander. "Installing and Running Tripwire," Help Net Security, http://www.netsecurity.org/text/articles/tripwire.shtml.
Wreski, Dave. "Tripwire in the Enterprise: Integrating Tripwire into Big Brother," SysAdminThe Journal for UNIX Administrators, Volume 10, Number 8. August, 2001, http://www.samag.com/documents/s=1147/sam0108a/0108a.htm.
Summary
Tripwire is an example of host-based intrusion detection software that should be installed on every system.
Using a database of calculated checksums, Tripwire is capable of detecting when a critical system file is changed. It is also one of the only tools that will provide notification that a rootkit has been installed on your system.
In order to be assured that your system has not been attacked, Tripwire should be run on a regular basis. This can be done easily by using the cron function.
Changes detected by Tripwire should be investigated carefully. Generally, the alerts that are generated are the result of normal system operations. When the cause of an alert is identified and found to be legitimate, the Tripware database should be updated to reflect the system's new state.