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 [1].

Tripwire is a file integrity checker. The system was developed in 1992 by Gene Kim and Dr. Eugene Spafford at Purdue University [2]. Since 1999, Tripwire Inc. [3] 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 [4], 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 [5], 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 [6] to catch up.

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.

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.

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.