Filesystem integrity auditing is an important part of any system administrator's security program.
When most system administrators think of system security, they think of firewalls, network configuration, services management, and user policy. Rarely, they might even think of reactive defenses like rootkit checking. However, a task of great importance to the really security conscious system administrator is filesystem integrity auditing. This integrity auditing involves keeping track of the state of your system's filesystem, and checking it periodically for unauthorized changes. When a suspicious change is detected, it's time to determine whether this was caused by an intruder and, if necessary, do damage control. While the damage control might be time-consuming, and even expensive, it's far better than letting the security compromise to go unaddressed.
By far the best-known filesystem integrity auditing tool in a Linux or UNIX environment is Tripwire. There is a commercial version of Tripwire available, but I will be addressing how you use the open source version (often referenced as "tripwire", without the capital "T"). The open source tripwire utility is a highly functional, very capable tool, and is a critical part of secure system administration. It is rare that a Linux system connected to the Internet should not have Tripwire installed: when in doubt, use it.
The tripwire tool is actually very simple in concept. It maintains a database that contains a "snapshot" of the filesystem, created by way of a policy defining what parts of your filesystem should be examined for unauthorized changes. The tripwire policy in general not only defines the snapshot, but also provides a set of rules for what constitutes an unauthorized or suspicious change in the state of the filesystem. When tripwire audits your filesystem, it uses the policy to examine the current state of the filesystem and compare it against the snapshot, and then it produces a report based on what it finds. Typical configurations have tripwire run once every day, usually late at night when nobody is likely to be using the system in question.
Your first tripwire snapshot should be created when you first install the operating system, before you ever connect it to the network or otherwise make it available to users and to other less trustworthy data sources. If you are retrofitting your system with tripwire, you might consider a plan to recreate your system configuration from scratch with tripwire in place from day one to ensure that there are not already some system compromises in place before tripwire is ever introduced to your system security practice.
Tripwire does have some problems that you should be aware of. These problems are divisible into two headings: convenience (also known as "administrative overhead") and weakness. The convenience issue centers on the fact that tripwire reports can be long and tedious to view and analyze, and the fact that you will have to update the tripwire database regularly if you make frequent changes to files audited by your tripwire policy. You will have to work out how best to mitigate these problems for yourself, based on the specific needs of your circumstances.
The weakness issue is mostly concerned with the fact that filesystem integrity auditing must necessarily be done on a periodic basis, rather than in real time. The reason for this is that real-time filesystem auditing would require prohibitive system resources, grinding your system's performance to a virtual halt so that it cannot do the job it's meant to do. The problem with periodic checks is that, for instance, if you make a change to a file after one audit, and a cracker modifies it again before the next audit, tripwire (or whatever auditing tool you use) will report a change that you will then attribute to your own activities and you may not be aware that anything untoward has happened. You should also be aware that, like any other security measure, Tripwire is not infallible. It is however a marked improvement, if used well, over its absence.
Despite these problems, tripwire is an excellent tool for increasing system security, and it is far better to use it than not. Other excellent filesystem integrity auditing tools exist such as Samhain and Aide. Because tripwire is the industry standard, and the most common such tool, it's the tool that I will be addressing here. I encourage you to investigate your options, however, and choose the tool that best suits your needs or the tools if you choose more than one. While it is unlikely that multiple filesystem integrity auditing tools will provide reasonable additional benefit, that too is a choice you should make yourself based on available information.
Setting up tripwire
How tripwire gets installed on your system in the first place is dependent on you. Major Linux distributions typically include tripwire in their software repositories so that you can use your distribution's package manager to download and install the software. For instance, on Debian, you might type apt-get install tripwire. You might also choose to get tripwire from its Open Source Tripwire project page on SourceForge.
Depending on how it's installed, some of the process of setting it up might be accomplished automatically as part of the installation procedure. Some Linux distributions provide a system configuration utility front end to tripwire's setup scripts that can make things easier. If that's not the case, or if you opt out of using the system-specific front end, you'll have to set up tripwire yourself.
First, you'll need to sign in as the root user and navigate to the /etc/tripwire directory. Once there, run the twinstall.sh script, followed by starting tripwire itself in database initialization mode using the —init switch. Finally, remove the twcfg.txt and twpol.txt located in the /etc/tripwire directory. The series of commands, with a # prompt indicating you are the root user, should look something like this:# cd /etc/tripwire
# tripwire —init
# rm twcfg.txt
# rm twpol.txt
It is possible you may not have the twinstall.sh script. If this is the case, the things twinstall.sh is designed to do must be done by you. This includes creating site and local keys for ensuring the integrity of the policy and configuration files for tripwire. Start out by generating site and local keys, still from within the /etc/tripwire directory. Then, sign the configuration and policy files with the site key, and finally change file permissions. In the following, "host" should be replaced with the hostname of the local system on which tripwire is being installed and configured:# twadmin —generate-keys —site-keyfilesite.key
# twadmin —generate-keys —local-keyfile host-local.key
# twadmin —create-cfgfile —cfgfiletw.cfg —site-keyfilesite.key twcfg.txt
# twadmin —create-polfile —cfgfiletw.cfg —site-keyfilesite.key twpol.txt
# chownroot:rootsite.key host-local.keytw.cfgtw.pol
# chmod 600 site.key host-local.keytw.cfgtw.pol
Once this is done, perform the next three steps as your would after using twinstall.sh:# tripwire â€"init
# rm twcfg.txt
# rm twpol.txt
The final removal of the twcfg.txt and twpol.txt files is a security measure. The tw.cfg and tw.pol files provide the actual functionality, and the two .txt files are simply plain-text versions of the same things from which the working copies are generated. Before going through the above steps, you should edit twcfg.txt and twpol.txt to suit your needs.
Once it is set up, of course, you need to be able to make use of tripwire. The best approach to that is the very simple command:# tripwire —check
Aside from manpages, you can get a brief help message about the uses of tripwire with —check by entering it with the —help switch:# tripwire —check —help
To automate the process of doing an integrity check with tripwire, you can create a cron job entry for a regularly scheduled system check. This involves editing your system's crontab file in the /etc directory, or add an appropriate execution script to the /etc/cron.daily directory, as appropriate for your distribution and system configuration policy. To edit the crontab file, open the /etc/crontab file in the text editor of your choice, and add a line for tripwire check execution. For example, to perform a check at 2:00 AM every day, you would enter the following line:
0 2 * * * /usr/sbin/tripwire —check
A better way to handle this would be to run it from another machine on the network, however, so that an intruder won't compromise the cron job that runs your tripwire integrity check on the local system. On that machine, then, you might add the following line to the crontab file, where "target-host" is the hostname of the target system:0 2 * * * ssh -n -l root target-host /usr/sbin/tripwire â€"check
In both cases, you run the risk of using a compromised tripwire program, however. It is best to burn copies of your tripwire binary and key files to a CD-R, and run the program from that. You will have to configure tripwire to work in this manner by editing the twcfg.txt file before signing it. Assuming that your CDROM mounts at /mnt/cdrom you should make the following changes to your /etc/twcfg.txt file:ROOT=/mnt/cdrom
You will have to sign the modified file, then generate your tripwire database, and unmount the CD-R when you're done. The only difference when doing it this way will be where you specify the site key to be stored (the following commands assume you're currently in /etc/tripwire):# twadmin —create-cfgfile —cfgfiletw.cfg —site-keyfile /mnt/cdrom/site.key twcfg.txt
When this has been done, you will run tripwire checks by mounting the CD-R that contains the tripwire binary, executing it from there, and unmounting the CD-R when you are done so that it can be removed and stored. You could leave the CD-R mounted and run checks from a cron job, as above, and specify in the crontab file /mnt/cdrom/tripwire as the program's location rather than /usr/sbin/tripwire.
Only the key files (the site key and local key) and the binary executable itself need to be stored on a non-writable media to protect them. This is because modifications to your configuration and policy files will be detected since they will not have been signed using your site and local keys, safely stored on the CD-R.
Updating the tripwire database
Files will change in your filesystem, and tripwire will detect these changes. Some changes are expected and desired. If you make a change to a file, tripwire will report that just as diligently as if some security cracker had changed it. The key is to know what changes should be there and what should not, and to keep the database updated so that it will not continuously report changes that are supposed to be there. After authorized changes have been made, and tripwire has been used to ensure those are the only changes that have been made, you can then update the database so that the next time it runs it will not continue to indicate the authorized changes. The following commands will provide a database update to tripwire:# LASTREPORT=`ls -1t /var/lib/tripwire/report/host-*.twr |head -1`
# tripwire —update —twrfile "LASTREPORT"
Scratching the surface
The tripwire configuration can be adjusted to target only specific parts of the filesystem, to assign differing scan priorities to various parts of the filesystem, and individually add files to the tripwire database or exclude them from it. Such configuration options are likely to prove valuable if you begin using tripwire in production deployments or otherwise find a need to leverage its functionality in a more than casual manner. They are, however, beyond the scope of this article.
All of this only scratches the surface of what tripwire can do. Increasing levels of strict security can be employed with the use of tripwire. It can be run as a centralized filesystem integrity auditing tool for an entire network, and it can even be used to audit filesystem integrity on Windows VFAT file systems (FAT16 and FAT32 file systems). At minimum, however, you should probably employ integrity auditing with a tool like tripwire on your local system, except in extreme cases of quickly changing file systems, to help ensure that you will not be caught unawares by malicious intruders.