Tripwire is an open-source host-based intrusion detection system (HIDS) that monitors file and directory integrity on Linux systems. It creates a baseline snapshot of your filesystem and alerts you when files are added, modified, or deleted – making it a critical tool for detecting unauthorized changes, rootkits, and configuration tampering on production servers.
This guide walks through installing and configuring Tripwire on Ubuntu 24.04 LTS. We cover key generation, policy tuning, baseline creation, integrity checks, report analysis, database updates, and automated monitoring with cron and email alerts. Note that Tripwire’s open-source edition has not seen a release since 2018 (version 2.4.3.7), but it remains functional and available in the Ubuntu repositories.
Prerequisites
- A server or VM running Ubuntu 24.04 LTS
- Root or sudo access
- A working mail transfer agent (MTA) like Postfix for email notifications (optional but recommended)
- Basic familiarity with Linux file permissions and system administration
Step 1: Install Tripwire on Ubuntu 24.04
Tripwire is available in the Ubuntu universe repository. Install it with apt:
sudo apt update
sudo apt install -y tripwireDuring installation, the package prompts you to create a site key and a local key. Select Yes for both prompts. You will be asked to set passphrases for each key – choose strong passphrases and store them securely. The site key protects the policy and configuration files, while the local key protects the baseline database.
After installation completes, confirm the Tripwire binary is in place:
tripwire --versionYou should see version information confirming Tripwire is installed:
The current version of Tripwire is: 2.4.3.7Step 2: Initialize Tripwire Site and Local Keys
If you skipped key creation during installation, or need to regenerate them, create the site key and local key manually. The site key is shared across all Tripwire installations in your environment, while the local key is unique to each host.
Generate the site key:
sudo twadmin --generate-keys --site-keyfile /etc/tripwire/site.keyGenerate the local key (replace hostname with your server’s actual hostname):
sudo twadmin --generate-keys --local-keyfile /etc/tripwire/$(hostname)-local.keyVerify that both key files exist in the Tripwire configuration directory:
ls -l /etc/tripwire/*.keyYou should see both the site key and the local key listed:
-rw------- 1 root root 931 Mar 22 10:15 /etc/tripwire/site.key
-rw------- 1 root root 931 Mar 22 10:15 /etc/tripwire/server01-local.keyNext, update the Tripwire configuration file to set the report level to 4 (maximum detail). Open the config file:
sudo vi /etc/tripwire/twcfg.txtFind the REPORTLEVEL line and set it to 4:
REPORTLEVEL =4Rebuild the encrypted configuration file after the change:
sudo twadmin --create-cfgfile --cfgfile /etc/tripwire/tw.cfg --site-keyfile /etc/tripwire/site.key /etc/tripwire/twcfg.txtEnter your site passphrase when prompted. This encrypts the configuration so it cannot be tampered with.
Step 3: Configure the Tripwire Policy File
The policy file (/etc/tripwire/twpol.txt) defines which files and directories Tripwire monitors and what attributes to check (permissions, hashes, timestamps). The default policy monitors many system paths, but some may not exist on your system and will cause errors during initialization.
The best approach is to customize the policy by commenting out paths that do not exist on your server. Open the policy file:
sudo vi /etc/tripwire/twpol.txtReview each path listed in the policy. Comment out any file or directory that does not exist on your system by adding a # at the beginning of the line. Common paths to check include /etc/rc.boot, /root/mail, /root/Mail, /root/.xsession-errors, /root/.xauth, /root/.tcshrc, /root/.sawfish, /root/.pinerc, /root/.mc, /root/.gnome, /root/.gnome_private, /root/.gnome2, /root/.gnome2_private, /root/.ligatures, /root/.cshrc, /proc/devices, /proc/net, /proc/tty, /proc/cpuinfo, /proc/modules, /proc/mounts, /proc/dma, /proc/filesystems, /proc/interrupts, /proc/ioports, /proc/scsi, /proc/kcore, /proc/self, /proc/kmsg, /proc/stat, /proc/loadavg, /proc/uptime, /proc/locks, /proc/meminfo, /proc/misc, /proc/version.
You can quickly identify which paths in the policy do not exist on your system:
sudo grep -E "^\s+/" /etc/tripwire/twpol.txt | awk '{print $1}' | while read f; do [ ! -e "$f" ] && echo "MISSING: $f"; doneComment out each missing path in the policy file. This eliminates false warnings during database initialization and integrity checks.
After editing, rebuild the encrypted policy file:
sudo twadmin --create-polfile --cfgfile /etc/tripwire/tw.cfg --site-keyfile /etc/tripwire/site.key /etc/tripwire/twpol.txtEnter your site passphrase when prompted. The encrypted policy is written to /etc/tripwire/tw.pol.
Step 4: Create the Baseline Database
The baseline database is a snapshot of the current filesystem state. All future integrity checks compare against this baseline, so run this step on a known-clean system before putting it into production. If your server is already compromised, the baseline would include the tampered files – defeating the purpose of file integrity monitoring.
Initialize the database:
sudo tripwire --initEnter your local passphrase when prompted. The initialization scans every file and directory defined in the policy, computing checksums and recording attributes. This takes a few minutes depending on how many objects the policy covers:
Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/server01.twd
The database was successfully generated.If you see “file not found” warnings during initialization, go back to Step 3 and comment out the missing paths in the policy file, then regenerate the policy and re-initialize.
Verify the database file was created:
ls -lh /var/lib/tripwire/*.twdYou should see the database file named after your hostname:
-rw------- 1 root root 3.2M Mar 22 10:30 /var/lib/tripwire/server01.twdStep 5: Run the First Integrity Check
With the baseline in place, run your first integrity check to compare the current filesystem against the database. This is the core function of Tripwire – detecting any files that have been added, modified, or removed since the baseline was created.
sudo tripwire --checkOn a freshly initialized system, the check should report zero or minimal violations. The output shows a summary of scanned objects and any changes detected:
Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Total objects scanned: 14520
Total violations found: 0
===============================================================================
No violations found.
===============================================================================If violations appear on a system you just initialized, investigate each one. Common causes are log files that rotated between initialization and the first check, or temporary files in /tmp.
Step 6: Review Tripwire Reports with twprint
Every integrity check generates a report file stored in /var/lib/tripwire/report/. These reports are in a binary format and need the twprint utility to read them. This is similar to how tools like AIDE handle their database and report files.
List available reports:
ls -lt /var/lib/tripwire/report/Report filenames include the hostname and timestamp, making it easy to identify when each check ran:
-rw------- 1 root root 8234 Mar 22 10:35 server01-20260322-103500.twrPrint a report at the maximum verbosity level (level 4 shows all changed attributes):
sudo twprint --print-report --report-level 4 --twrfile /var/lib/tripwire/report/server01-20260322-103500.twrThe report levels control how much detail you see:
| Level | Description |
|---|---|
| 0 | Single-line summary only |
| 1 | Added and removed files listed |
| 2 | Changed files included |
| 3 | Changed attributes shown (default) |
| 4 | All attributes on all changed objects |
You can also print the database contents to see exactly what Tripwire is tracking:
sudo twprint --print-dbfile --dbfile /var/lib/tripwire/server01.twd | head -50Step 7: Update the Policy After Changes
When you install new software or change what Tripwire monitors, update the policy file rather than re-initializing the entire database. Policy updates preserve the existing baseline while applying the new monitoring rules.
Edit the plaintext policy file:
sudo vi /etc/tripwire/twpol.txtFor example, to add monitoring for a custom application directory, add a rule inside the Unix File System section:
(
rulename = "Custom Application",
severity = $(SIG_HI)
)
{
/opt/myapp -> $(SEC_BIN) ;
/opt/myapp/config -> $(SEC_CONFIG) ;
/opt/myapp/logs -> $(SEC_LOG) ;
}The severity macros control how changes are flagged. SEC_BIN checks for any modification to binaries, SEC_CONFIG tracks configuration file changes, and SEC_LOG is more permissive for log files that change frequently.
Apply the updated policy with the --update-policy flag. Use -Z low to accept any current filesystem changes and update the database simultaneously:
sudo tripwire --update-policy -Z low /etc/tripwire/twpol.txtEnter both your site passphrase and local passphrase when prompted. Tripwire runs a check with the new policy, accepts any detected changes, and updates the database.
Step 8: Update the Database After Approved Changes
After performing legitimate system changes – package updates, configuration edits, or deploying new applications – update the Tripwire database so these changes become the new baseline. Without this step, every future check will flag these approved changes as violations.
First, run a check to generate a report that captures the current changes:
sudo tripwire --checkThen update the database using the latest report file. The -a flag accepts all changes in the report:
sudo tripwire --update --accept-all --twrfile /var/lib/tripwire/report/$(ls -t /var/lib/tripwire/report/ | head -1)Enter your local passphrase when prompted. The database is updated to reflect the current filesystem state.
If you prefer to review each change individually instead of accepting all at once, omit the -a flag:
sudo tripwire --update --twrfile /var/lib/tripwire/report/$(ls -t /var/lib/tripwire/report/ | head -1)This opens the report in your default editor. Set entries to x (accept) or leave them unmarked (reject) before saving and closing. Only accepted changes update the database.
Step 9: Automate Tripwire Checks with Cron
Running integrity checks manually is not practical for production systems. Set up a cron job to run Tripwire checks automatically and write reports for later review.
Create a dedicated script for the cron job:
sudo vi /usr/local/sbin/tripwire-check.shAdd the following content:
#!/bin/bash
# Automated Tripwire integrity check
LOG="/var/log/tripwire-check.log"
echo "=== Tripwire Check: $(date) ===" >> "$LOG"
/usr/sbin/tripwire --check >> "$LOG" 2>&1
echo "=== Check Complete ===" >> "$LOG"Make the script executable:
sudo chmod 700 /usr/local/sbin/tripwire-check.shAdd a cron job to run the check daily at 3:00 AM:
sudo crontab -eAdd this line at the end of the crontab:
0 3 * * * /usr/local/sbin/tripwire-check.shVerify the cron job is registered:
sudo crontab -lYou should see the Tripwire check entry in the output.
Step 10: Configure Email Notifications for Tripwire Alerts
Tripwire has built-in email notification support. To use it, you need a working MTA on the server. Tripwire sends email through the SMTP settings defined in the configuration file.
First, verify your email configuration works by sending a test message:
sudo tripwire --test --email [email protected]If the test email arrives, the SMTP configuration is working. If not, check that your MTA is running and the SMTP settings in /etc/tripwire/twcfg.txt are correct:
sudo vi /etc/tripwire/twcfg.txtVerify these SMTP settings are configured for your environment:
MAILMETHOD =SMTP
SMTPHOST =localhost
SMTPPORT =25After modifying the configuration, rebuild the encrypted config file:
sudo twadmin --create-cfgfile --cfgfile /etc/tripwire/tw.cfg --site-keyfile /etc/tripwire/site.key /etc/tripwire/twcfg.txtTo receive email alerts when violations are detected, add an emailto attribute to rules in the policy file. Open the policy:
sudo vi /etc/tripwire/twpol.txtAdd the emailto directive to any rule that should trigger email alerts:
(
rulename = "Critical System Binaries",
severity = $(SIG_HI),
emailto = [email protected]
)
{
/usr/sbin -> $(SEC_BIN) ;
/usr/bin -> $(SEC_BIN) ;
}Apply the updated policy:
sudo tripwire --update-policy -Z low /etc/tripwire/twpol.txtYou can also update the cron script to email the full report. Similar to how OSSEC HIDS sends alerts on detected changes, Tripwire can pipe check results directly to mail:
sudo vi /usr/local/sbin/tripwire-check.shUpdate the script to include email delivery:
#!/bin/bash
# Automated Tripwire integrity check with email alerts
ADMIN_EMAIL="[email protected]"
HOSTNAME=$(hostname)
LOG="/var/log/tripwire-check.log"
echo "=== Tripwire Check: $(date) ===" >> "$LOG"
RESULT=$(/usr/sbin/tripwire --check 2>&1)
echo "$RESULT" >> "$LOG"
# Send email if violations found
if echo "$RESULT" | grep -q "Total violations found: [1-9]"; then
echo "$RESULT" | mail -s "Tripwire Alert: Violations on $HOSTNAME" "$ADMIN_EMAIL"
fi
echo "=== Check Complete ===" >> "$LOG"Conclusion
Tripwire is now configured to monitor file integrity on your Ubuntu 24.04 server. The automated cron job runs daily checks and emails you when unauthorized changes are detected. For a more actively maintained alternative, consider Wazuh which provides file integrity monitoring alongside real-time threat detection, log analysis, and compliance auditing in a single platform.
For production hardening, store a copy of the Tripwire database and policy files on read-only media or a remote server – if an attacker gains root access, they could modify the local database to hide their tracks. Regularly review and prune your policy to minimize false positives, and always update the baseline database promptly after approved system changes.
Nice, saving for posterity.