The Internet is awash in intrusion opportunities. One unpatched exploit can let an intruder slip through the perimeter defenses. As a result, computers owned by unsuspecting citizens and businesses can mutate into spam slingers, distributing malicious programs or spying on users. How do you know if an intruder is on your computer? The host-based intrusion detection system Tripwire quietly monitors the filesystem and promptly notifies you in case of any changes.

Numerous IDS systems exist for the free Linux operating system, both for whole networks (Network-based Intrusion Detection System, NIDS) and for individual hosts (Host-based Intrusion Detection System, HIDS). The first category includes Snort, Suricata, and Prelude, which ideally detect attacks on entire networks. The second category includes applications such PortSentry, Logcheck, Samhain, OSSEC, and, last but not least, Tripwire.

Tripwire is a file integrity checker. The system was developed in 1992 by Gene Kim and Dr. Eugene Spafford at Purdue University. Since 1999, Tripwire Inc. has further developed the application as Tripwire Enterprise.

The Tripwire Open Source Project was launched in 2002 and uses Tripwire sources from 2000 as its basis. According to Tripwire Inc., the Tripwire program is suitable for small networks that do not require centralized management and reporting capabilities.

Operations

Attackers usually try to contaminate a hijacked system with trojans, backdoors, and manipulated files. Tripwire helps to prevent this problem by encrypting information (checksums, file sizes, Mtime, ctime, inode, etc.) and important directories and files and storing the information in a database. The program then compares these identifying parameters with the properties of the monitored files and notifies the admin of any deviations. Ideally, everything is fine and the report is concise. Slightly longer reports occur when files have been altered intentionally or unintentionally.

Operating on this principle offers the advantage that you can make the comparison discreetly on a regular basis or upon suspicion of a break-in. The IDS uses very few system resources and is thus not usually noticeable as a running process. False alarms occur relatively infrequently. Administrators usually know that Tripwire is monitoring their servers, and they can quickly update its databases or determine whether they are responsible for a reported change.

Or course, Tripwire cannot warn the admin while a potential attack is taking place; it can only log its consequences. Once Tripwire sends a message about an unauthorized change to the administrator, the assumption must be that the attack was successful.

Installation

The main repositories of the major distributions do not usually include Tripwire. Ubuntu only provides the latest version in the Universe branch of Saucy Salamander (13.10). OpenSUSE keeps Tripwire in the security repository, meaning you need to install retrospectively. The program performs its tasks very well; thus, developers do not need to produce new versions constantly. The current version is 2.4.2.2, which you can build and install from the source code with the typical three steps.

# ./configure && make && make install

During installation, Tripwire creates a site key and a local key. The former is used to sign the configuration and policy files, the latter to protect the Tripwire database. If you forgot to generate the key during installation, you can use the commands in Listing 1 to catch up.

Listing 1: Generate Keys

# twadmin --generate-keys --site-keyfile /etc/tripwire/site.key
# twadmin --generate-keys --local-keyfile /etc/tripwire/$HOSTNAME-local.key

The same rules apply to passphrases as to any good passwords: More than eight characters and a mix of uppercase and lowercase letters and special characters enhance security.

You may also need to modify the /etc/tripwire/twcfg.txt file. This is where you enter the path to the key files, the policies, the database, and the reports. You can use other variables to set the default editor (EDITOR) and specify whether Tripwire should wait as long as possible until requiring password input from the user LATEPROMPTING). Additionally, double messages (file, directory) in case of changes to a monitored file can be prevented here (LOOSEDIRECTORYCHECKING).

Because Tripwire is often launched on remote servers as a cronjob, it may be useful also to send email notifications if everything is okay (MAILNOVIOLATIONS=true). The absence of a message means that you can expect the worst.

The report levels define how extensive the reports should be (see Table 1). You can also define the type (SMTP or sendmail) and the server required for mail delivery.

Setting Up Your Tripwires

Once the keys are in place and you have modified the configuration file in plain text, it’s time to place your tripwires in the form of policies on the server. The Tripwire configuration directory, /etc/tripwire/, most likely already contains an annotated file (twpol.txt) with default policies: the policy file or “Polfile.” Because every system is different, this setup will not necessarily provide the protection that an individual server needs. Instead, the file is used as a good starting point for your own customizations.

The policy file uses some keywords starting with @@ (see Table 2). You can use these directives to divide the policies into sections with specific conditions and individual messages.

Polfile rules start with the object to be monitored (this can be a file or directory), followed by ->, the properties to monitor, and optional rule attributes in brackets. The developers have summarized frequently used properties in several variables.

You also can define your own variables, which call in the $(<variable>) file. A rule usually extends over a line and ends with a semicolon. Rules can also be combined into groups so that they are easier to manage later on.

Tripwire can manage several criteria for a file. These include Atime and Mtime, the blocks occupied by an object, the hard disk ID, the inode number, the file size, the user and group IDs, and the permissions. Furthermore, you can select the hash method through the properties. For an overview of the main properties and the above-mentioned predefined variables, see Table 3.

The rulename attribute lets you define report-friendly names for rules, set the focus of a rule, specify an email address and command to be executed in the event of an attack, or specify wildcard patterns for the file types to be monitored. Additionally, you can specify the recursion depth to which Tripwire investigates the contents of a directory (see Table 4).

With the use of email addresses, Tripwire can notify different stakeholders of an attack; for example, the webmaster for changed PHP files and the system administrator in case of anomalies in directories such as /etc or /sbin. You can enter multiple addresses separated by commas. The command to run (onviolation) can be used, for example, to stop services for security reasons.

In recurse, -1 and true have an identical effect. In both cases, Tripwire investigates the entire contents of a directory. The settings 0 or false mean that Tripwire only checks the inode for a directory, whereas 1 means that Tripwire would include the files in the directory in the integrity checks (but ignore the content in subdirectories).

Stop points define a special rule of the <object>; type. These are directories or files that are excluded from the check. Stop points also let you choose exceptions within a directory to be checked.

Each server is different and requires individual protection; thus, you need to customize the policy file for each machine. The default policy file at least offers a minimum of protection for the following directories: /boot, /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /usr/lib, /usr/local/lib, and /etc.

Listing 2 shows an extension with rules that extend this protection to 64-bit libraries and an Nginx installation in the /opt directory. The rule for the 64-bit libraries also shows how to group multiple objects. Additionally, email addresses are stored so that stakeholders receive email notifications in case of incidents.

Listing 2: Extend Protection

(
  rulename = "64 Bit Libs",
  severity = 100,
  emailto = "falko@mail.de;chef@mail.de"
)
{
  /lib64     -> $(ReadOnly) ;
  /usr/lib64 -> $(ReadOnly) ;
}
/opt/nginx   -> $(ReadOnly) (rulename = "Nginx", severity = 100, emailto = falko@mail.de) ;

After creating the configuration and policy files, you need to encrypt them before you initialize the Tripwire database. You can create the two plain-text files at the command line with the commands in Listing 3. After encryption, the configuration and policy files exist in a format that is not easily readable.

Listing 3: Create Text Files

# twadmin --create-cfgfile --cfgfile tw.cfg --site-keyfile site.key twcfg.txt
# twadmin --create-polfile --polfile tw.pol --cfgfile tw.cfg --site-keyfile site.key twpol.txt

After successfully creating the Tripwire database, remove the plain-text files. If you want to look at the files later, all you need is the twadmin --print-polfile or twadmin --print-cfg-file command.

You create the Tripwire database with the tripwire --init command. It is then located by default as a file with the .twd extension in /var/lib/tripwire/. Tripwire may report a few errors when creating the database because the policy file contains invalid entries, such as missing files. In this case, change the policy file and generate it again until Tripwire creates the database without complaining.

Check and Report

Before you bundle Tripwire off into a cron job, you should check whether the software really sends email without any glitches. The following command does the trick:

# tripwire --test --email <address>@<domain>.com

If everything works, you can type tripwire --check to run your first real integration check (Figure 1). Tripwire outputs the reports in short form at the console and stores them at the same time in more detail in /var/lib/tripwire/report/$HOSTNAME-timestamp.twr (Figure 2).

Figure 1: During the integrity check, Tripwire outputs a short summary on the standard output. The associated reports usually show much more detail.

Figure 2: One report for each cronjob and manual integrity check: If you do not delete the reports, they tell a long tale of intentional or unintentional file manipulation.

If you want to mail the reports, you also need to set the --email-report switch. The reports are then dispatched to the recipients defined in the policy file for the matching rules.

Occasionally, admins change things on running systems. Because Tripwire does not know that these modifications are allowed, the reports may be full of violations. To avoid this, you need to adjust the Tripwire database on the basis of the report. Use the command

# tripwire --update -twrfile  /var/lib/tripwire/report/$HOSTNAME-timestamp.twr

to open an editor that lists all rule violations (Figure 3). Alternatively, Tripwire can use tripwire --check --interactive to adopt the changes immediately.

Figure 3: Changes that are understandable and allowed can be added to the Tripwire database.

If you then consent by doing nothing, Tripwire modifies the database accordingly; these integrity violation messages do not occur in future tests. If a rule violation is not approved and if you want Tripwire to continue reporting it in future tests, simply uncheck the checkbox associated with the violation.

If you want to look at the Tripwire database, you can use the

twprint --print-dbfile

command and use a similar approach for binary report files (Figure 4):

# twprint --print-report --twrfile /var/lib/tripwire/report/$HOSTNAME-timestamp.twr

If all manual checks run satisfactorily, you can set up a cron job to delegate the integrity check by opening the cron table as root, typing crontab -e, and adding

00 5 * * * /usr/sbin/tripwire --check --email-report

to tell the system to run a daily check at 5:00am and report by email, for example.

Figure 4: The Tripwire report shows in some detail where discrepancies have occurred.

Security Tips

Ideally, you will want to set Tripwire up on a freshly installed system: Only then can you really be sure that all the files are still in their original state. The keys, policy file, and configuration file should be readable and writable only for root; the following command takes care of this:

# chmod 600 site.key $HOSTNAME-local.key tw.*

The /etc/tripwire and /var/lib/tripwire/ directories are also intended for root access only (chmod 700 ...).

If possible, you should also specially protect the Tripwire database so that the attacker has no chance to change it. For a desktop computer, an external storage medium is a good way of doing this. A server can download the database from another computer before each test using SSH and the public key method or load the database from a read-only medium.

Conclusions

Tripwire lives up to its name. The simple but effective Tripwire HIDS can be set up quickly and provides its service quietly and discreetly. Although the HIDS does not defend against attacks, it does help identify anomalies in good time. Admins often have little chance of detecting modified files left behind by attackers, but Tripwire serves up the evidence by email, reducing search and removal overhead.

The rules can also be adapted easily retroactively. The report files are usually fairly small, and the risk of slowly but surely using up all your disk space is virtually non-existent. By allowing intended changes that update or change configuration files, you can adapt the database in an uncomplicated way.

Info

Code for this article