Linux Intrusion Detection With Tripwire On Ubuntu and Debian: Part 2
Previously, we discussed installing Tripwire on a system running the Debian or Ubuntu Linux distributions as a means of detecting intrusions on your system. This time we’ll be looking at continuing to get it set up and running.
Initializing the Database
When we left off, we had Tripwire configured with a basic configuration that will need tweaking for our needs later. First though, we’ll initialize the database which will also flag issues that will also need to be adjusted in the configuration. This can be done with the following command:
sudo tripwire –init
You will be prompted for your local passphrase to continue. A number of messages will then scroll up the screen. To obtain the list of issues, we can run tripwire with the –check flag. This will create a lot of output, so it’s best to pipe it to the less command:
sudo sh -c ‘tripwire –check | less’
The problems are listed at the end of the output, after a lot of scrolling. This will mostly consist of files that Tripwire is attempting to monitor that don’t exist on your system. An easy way to get the list of files is to grep for “Filename”, and then write the output to a file:
sudo sh -c ‘tripwire –check | grep Filename > tripwire_file_errors’
This file will then become a list of the files that Tripwire is attempting to monitor that are causing errors. You can then view this file with less or using a text editor:
less tripwire_file_errors
You’ll need to take a note of all those files, as you need to edit the Tripwire policy configuration file to comment out matching lines. This will stop Tripwire trying to check those files:
sudo nano /etc/tripwire/twpol.txt
Files
This configuration file starts by defining the severity levels that can be applied to files on the system based on how the files are used. After that come sets of rules, and each rule set is split into two sections. The first section in regular brackets “()” provides the name for a rule and the severity assigned to a change detected by this rule. After that, in curly brackets “{}”, comes a list of the files and directories monitored as part of that rule, as well as the setting for what changes are allowed in that file.
As an example in my test, the file /etc/rc.boot was missing and causing an error. In the twpol.txt file I found it in the “Boot Scripts” section. The line itself is shown below:
/etc/rc.boot -> $(SEC_BIN) ;
To comment it out simply add a hash symbol “#” at the start of the line as follows:
# /etc/rc.boot -> $(SEC_BIN) ;
You’ll need to do this for all of the files in the error list where matches can be found.
Once you’ve gone through the list, you may find there are a number of files in /proc that caused errors such as an example from my test:
Filename: /proc/1414/task/1414/fd/3
This references a file descriptor for a running process. Processes change all the time as they access various files; every time you run a new application it starts a new process and as such monitoring these can flag lots of false positive responses. The solution here is to be far more precise when referencing where in /proc to be checked. In the configuration file it’s referenced under “Devices & Kernel Information”, which in my file is referenced simply /dev and /proc. Which brings us to another error: on Debian and Ubuntu systems /dev/pts is on a different filesystem to /dev, and as such Tripwire will only check it if asked to specifically. So the solution is to change this section to read as:
{
/dev -> $(Device) ;
/dev/pts -> $(Device) ;
#/proc -> $(Device) ;
/proc/cpuinfo -> $(Device) ;
/proc/devices -> $(Device) ;
/proc/dma -> $(Device) ;
/proc/filesystems -> $(Device) ;
/proc/interrupts -> $(Device) ;
/proc/ioports -> $(Device) ;
/proc/kcore -> $(Device) ;
/proc/kmsg -> $(Device) ;
/proc/loadavg -> $(Device) ;
/proc/locks -> $(Device) ;
/proc/meminfo -> $(Device) ;
/proc/misc -> $(Device) ;
/proc/modules -> $(Device) ;
/proc/mounts -> $(Device) ;
/proc/net -> $(Device) ;
/proc/scsi -> $(Device) ;
/proc/self -> $(Device) ;
/proc/stat -> $(Device) ;
/proc/sys -> $(Device) ;
/proc/tty -> $(Device) ;
/proc/uptime -> $(Device) ;
}
The last step is to comment out the lines for the directories “/var/lock” and “/var/run”, as these will be changed through the course of normal system operations, and unless you specifically want to be informed of when processes change IDs, etc, then you don’t necessarily need to monitor those.
Finally, with the changes made to the configuration file you can save the changes once more and then re-encrypt the configuration.
sudo twadmin -m P /etc/tripwire/twpol.txt
Again you will need that site passphrase.
With the policy encrypted for use, you can then re-initialize the database:
sudo tripwire –init
This time access with the local passphrase.
Finishing Up
Now if you run tripwire with a check, the output should be smaller and the errors should be gone. At this point we have Tripwire configured with the basics you need for your system. You should be able to see from the configuration file how you can go about creating new sections for monitoring other files on your system, such as checking your website’s files to ensure they aren’t being changed unexpectedly.
While Tripwire is configured, we still aren’t finished. Next time, we’ll be looking at how to get Tripwire automatically checking your system for intrusions and emailing you any reports.