Introduction

Security is an incredibly complex problem when administering online servers. While it is possible to configure firewalls, fail2ban policies, secure services, and lock down applications, it is difficult to know for sure if you have effectively blocked every attack.Here you will find the steps to Install Tripwire Intrusion Detection System on Linux system for content integrity.

A host-based intrusion detection system (HIDS), works by collecting details about your computer’s filesystem and configuration. It then stores this information to reference and validate the current state of the system. If changes are found between the known-good state and the current state, it could be a sign that your security has been compromised.

A popular host-based intrusion detection system on Linux is tripwire. This software can keep track of many different filesystem data points in order to detect whether unauthorized changes have occurred.

Here we will discuss installation and configuration of tripwire tool in RedHat/CentOS Server –

Install Tripwire Intrusion Detection System

On CentOS/RHEL, Tripwire will not be found on official repository. So add EPEL repository to install Tripwire:

Now install Tripwire:

Create keyfile pass phrases

Likewise in Ubuntu local and site keyfile passphrases will not be created when installing Tripwire. Enter the following commands to create site and local keyfile pass phrases for Tripwire:

Initialize the Database

Following the installation, you must initialize and configure your installation. Like most security programs, tripwire is shipped with generic, but strict defaults that may need to be fine-tuned for your specific installation.

In the both above outputs, you may notice that a error called “No such file or Directory” and “file system error”. This is because the tripwire scans every files/directories which are mentioned in the tripwire configuration file. The files/directories might not be existed in your system. Comment the lines which are showing this error in the tripwire config file or leave it as is.

To do that open the file /etc/tripwire/twpol.txt and comment the file/directory lines which are not present in your system.

Configure the Policy File to Match Your System

Now that we have a list of files that are setting off tripwire, we can go through our policy file and edit it to get rid of these false positives.

Open the plain text policy in your editor with root privileges:

Do a search for each of the files that were returned in the test_result file. Comment out all of the lines that you find that match.

In the system configuration we will comment out are the /var/run and /var/lock lines so that our system does not flag normal filesystem changes by services:

There were a lot of files in the /root home directory that needed to be commented out on my system. Anything that is not present on your system should be commented out:

Save and close the file when you are finished editing.

Now that our file is configured, we need to implement it by recreating the encrypted policy file that tripwire actually reads:

After this is created, we must reinitialize the database to implement our policy:

All of the warnings that you received earlier should be gone now. If there are still warnings, you should continue editing your /etc/tripwire/twpol.txt file until they are gone.

Verify the Configuration

If your database initialization didn’t complain about any files, then your configuration should match your system at this point. But we should run a check to see what the tripwire report looks like and if there are truly no warnings:

The basic syntax for a check is:

You should see a report output to your screen specifying that there were no errors or changes found on your system.

Once this is complete, you can be fairly confident that your configuration is correct.

To view the Tripwire configuration location:

Set Up Email Notifications

We will configure tripwire to run every day and also implement automatic notifications. During the process, we can test how to update the database when we make changes to our system.

Now that we have that command installed, let’s do a test of our system’s ability to mail out a tripwire report. This report will have warnings and changes too, since we just installed new software without telling tripwire:

You should receive a report shortly in your email with details about the new mail software you just installed to send the message! This is good. It means that tripwire is picking up changes in the filesystem and that our mail software is working as well.

We can do this by typing:

This will run the same tests as normal, but at the end, instead of outputting the report to the screen, it is copied into a text file and opened with the default editor.

This report goes into quite a lot of detail about each file that changed. In fact, on my machine, the report generated was 2,275 lines long. This amount of information is extremely helpful in the event of a real security problem, but in our case, it’s generally probably not too interesting for the most part.

The important part is near the top. After some introductory information, you should see some lines with check boxes for each of the added or modified files:

These check boxes indicate that you want to update the database to allow these changes. You should search for every box that has an “x” in it and verify that those are changes that you made or are okay with.

If you are not okay with a change, you can remove the “x” from the box and that file will not be updated in the database. This will cause this file to still flag tripwire on the next run.

Conclusion

You should now have an automated intrusion detection system that sends you reports regarding changes on your filesystem. You should review the emailed reports regularly and take action where there are changes detected, either in updating the tripwire database to okay the changes, or investigating suspicious activity.