Detecting Attackers with Tripwire
Silent Guardian
ByTripwire 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.
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.
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 0 to 1000000. If the severity is specified during an integrity check, only rules from this level are tested. |
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 -1 to 1000000. |
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
( 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).
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.
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.
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
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
-
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.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.