Detecting attacks with the Tripwire IDS
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
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.
Infos
- Tripwire: http://www.tripwire.org
- Purdue University: http://www.purdue.edu
- Tripwire, Inc.: http://www.tripwire.com
- OpenSUSE security repos: http://download.opensuse.org/repositories/security/
- Tripwire download: http://sourceforge.net/projects/tripwire/files/latest/download
- Code for this article: ftp://ftp.linux-magazin.com/pub/listings/magazine/163
« Previous 1 2
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
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.