Detecting attacks with the Tripwire IDS

Silent Guardian

© Lead Image © John McAllister,

© Lead Image © John McAllister,

Article from Issue 163/2014

Tripwire is a powerful tool that protects your systems against unwanted changes.

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.


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.


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

Listing 1

Generate Keys


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.

Table 1

Report Levels




Summary in one line; lists the number of changes, additions, and deletions


Parsable list of all violations


Summary; list of violations by section in the Polfile and rule name


Default level shows expected and recognized properties for monitored objects that have changed


Full report that goes into minute detail

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.

Table 2





Starts section in Polfile; OS-dependent


Conditional differentiation if a Polfile is deployed on multiple hosts


See @@ifhost


See @@ifhost


Outputs the string that follows on standard output


Outputs the string that follows on error output


End of Polfile; all following entries are ignored

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.

Table 3

Predefined Variables






The blocks occupied by the object


Timestamp when the inode was created or modified


Device ID


Flags (operating system-dependent)


Owner group ID


Inode number


Growing file




Number of links




File size


Owner User ID


ACL settings


CRC 32


Inode generation number


HAVAL hash


MD5 hash


SHA hash

Predefined Variables








Checks only whether an object exists


Checks all properties



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).

Table 4

Rule Attributes




Assigns a name for the rule. The default is the last element of the object name.


Value from 0 to 1000000. If the severity is specified during an integrity check, only rules from this level are tested.


Email address of the administrator that Tripwire informs in case of issues.


Recursion depth for directories. Possible values: true, false, and numbers from -1 to 1000000.


Runs the specified command in case of a violation.


Wildcard pattern for file types to take into account in the integrity check.

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


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


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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Tripwire

    The simple but effective Tripwire HIDS provides its service quietly and discreetly, preventing attackers from infecting computers with trojans, backdoors, or modified files by identifying anomalies unnoticed by the user.

  • Security Lessons: System Rescue

    Kurt provides some tips and recommends some tools to help you detect signs of network intrusion and data corruption.

  • Host-Based IDS

    A host-based intrusion detection system is a simple but powerful tool for finding traces of an attacker's footprint.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More