Detecting attacks with the Tripwire IDS
Silent Guardian
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.
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.
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
Level | Description |
---|---|
0 |
Summary in one line; lists the number of changes, additions, and deletions |
1 |
Parsable list of all violations |
2 |
Summary; list of violations by section in the Polfile and rule name |
3 |
Default level shows expected and recognized properties for monitored objects that have changed |
4 |
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
Directives
Directive | Description |
---|---|
@@section |
Starts section in Polfile; OS-dependent |
@@ifhost |
Conditional differentiation if a Polfile is deployed on multiple hosts |
@@else |
See @@ifhost |
@@endif |
See @@ifhost |
|
Outputs the string that follows on standard output |
|
Outputs the string that follows on error output |
@@end |
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
Property | Description |
---|---|
a |
Atime |
b |
The blocks occupied by the object |
c |
Timestamp when the inode was created or modified |
d |
Device ID |
f |
Flags (operating system-dependent) |
g |
Owner group ID |
i |
Inode number |
l |
Growing file |
m |
Mtime |
n |
Number of links |
p |
Permissions |
s |
File size |
u |
Owner User ID |
A |
ACL settings |
C |
CRC 32 |
G |
Inode generation number |
H |
HAVAL hash |
M |
MD5 hash |
S |
SHA hash |
Predefined Variables |
|
ReadOnly |
+pinugsmdbfCMAG |
Dynamic |
+pinugdfAG |
Growing |
+pinugdlfAG |
IgnoreAll |
Checks only whether an object exists |
IgnoreNone |
Checks all properties |
Device |
+pugsdrfA |
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
Attribute | Description |
---|---|
rulename |
Assigns a name for the rule. The default is the last element of the object name. |
severity |
Value from |
emailto |
Email address of the administrator that Tripwire informs in case of issues. |
recurse |
Recursion depth for directories. Possible values: true, false, and numbers from |
onviolation |
Runs the specified command in case of a violation. |
match |
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
(incl. VAT)
Buy Linux Magazine
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.
News
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.