In the project, you will install and then configure the open source version of the Tripwire HIDS. Then you will run Tripwire to generate a report. If you have two or more hosts assigned to you, you only need to install Tripwire on one of them (the server host).
Tripwire can now be installed with
yum so you don't
have to download the source code tar-ball and build it anymore.
Once correctly installed, your textbook(s) have information to help
you configure Tripwire for your system.
You may work in groups of two or three on this project. Each member of the group still must turn in a separate copy of the assignment, listing all group members as authors.
twcfg.txtfile. I suggest two changes: Set
true. (This will help with the initial policy tuning. You can later turn this back to
false.) Secondly you may want to change some of the filenames used. By default some of these include the hostname. If that is set randomly by DHCP, or not set at all, it will be difficult to use Tripwire later.
Additionally, the Tripwire RPM for Fedora is
compiled to use the configuration filename of
(this is the name for the encrypted version of the file).
If you use that name then you won't need to use the option of
on every command you enter.
What changes did you make to the default Tripwire configuration file?
full install(all packages). But even this won't find files installed from non-standard sources, such as from tar-balls or
yumpackages from non-standard repositories. You must manually add in to the policy file all the non-standard files installed that you want to protect. Additionally note that you almost certainly did not install everything, so the first time you run Tripwire, if you use the default policy file it will report a lot of files are missing! This is not a problem for now.
You will fix the policy file up later. Initially just use this default policy file, with non-standard software additions. What changes (if any) did you make to this initial policy file? (If you made no changes, be sure to say so.)
# cd /etc/tripwire # twadmin --generate-keys --site-keyfile site.key # twadmin --generate-keys --local-keyfile localhost-local.key
(Be sure to record the passwords used, but not in your system journal!) Now that you've created the keys, the policy and configuration files can be digitally signed and encrypted. Use commands similar to these:
# twadmin --create-cfgfile --cfgfile tw.cfg \ --site-keyfile site.key twcfg.txt # twadmin --create-polfile twpol.txt
Note that the names of the files you use must match the names listed in the configuration file! If you use different names, you must supply the name(s) on the command lines.
# tripwire --init ... lots of messages ... The database was successfully generated.
The tripwire database file has a name like
What is the absolute pathname of the
Tripwire database file you just generated?
How big is this file?
# tripwire --check
(When I ran this on my office system using the default policy
file, 108 errors resulted.)
The generated report usually has a name such as
What is the absolute pathname of the
report file you just generated?
What is the tripwire command line used to view that report?
Use the results to make any needed tweaks to your policy, using
vi on the unencrypted version of the file.
Then using the command
to update the encrypted version with your changes.
tripwire --update-policy twpol.txt
Depending on the changes made to your system and to your policy, this command may not work. Read the man page to determine what additional command line argument(s) you may need.
Instead of updating the policy file (and database), you may find it easier to simply delete the compiled policy file (and database), and then use the commands shown earlier to just create them again.
If you now run another check, no problems should be found. If there are remaining problems, repeat the last steps (edit the policy, update the encrypted version, check again) until no errors remain.
Even with the policy correct, some errors may be reported. This happens when some file was changed from what the database says. In fact, on a production system errors may often result by having files updated.
This is the policy file to backup (an encrypted copy works best; you should delete the plain text version after making a backup). This file can be considered your baseline policy file.
. Now run another check and examine the resulting report. You should see the changed timestamp as an error in the new report. What was the error message(s) reported?
# tripwire --update --accept-all \ -r /var/lib/tripwire/report/reportname
The default configuration is probably fine, however you may wish
to change pathnames of some of the files (I prefer putting databases and
/var), or the reporting options to use syslog
rather than email.
Also consider whether or not to turn on
LOOSEDIRECTORYCHECKING, which defaults to off (false).
One potential problem with the default configuration
is that many of the files use the hostname as part of the filenames.
This allows easy identification when managing many hosts and keeping
the files in one place.
But if using DHCP (especially at HCC in the lab)
your hostname may change from day to day.
This may result in Tripwire not finding its files.
You can overcome this, by (a) not using the hostname as part of
the file names, (b) using command line options to tell tripwire the
names of the files to use, or (c) configure your system to have a
stable, static hostname.
localhost is a good choice, since you only are running
tripwire on a single host.)
Check the man pages for
twintro for an overview of
the various Tripwire commands.
Note in particular the tasks handled by
tripwire, especially the difference between updating
a policy and creating one.
You need to decide which parts of your system to monitor, and
to what degree (that is, what attributes to monitor).
A simple basic policy can be used to protect only your critical
For example binary directories and their contents should never be
modified without detection:
/opt/[s]bin, and so on.
(Basically the directories found by running
find / -type d -name \*bin".)
You must also protect any
lib directories, as these
contain kernel modules, PAM modules, and
Next you should ensure Tripwire monitors most configuration files.
On a learning host like ours, you should expect most of these
files to change regularly, but rarely in a production setting.
These directories include
/etc and other directories in
Additionally some programs put config files in strange locations,
such as under
/etc are a few special files that are expected to
be present, but whose contents changes all the time.
If you use a general policy rule for all of
its contents (a good idea), you must make exceptions of these
files or you will get many false positives.
Log files should exist and not change, except to grow or be rotated (which usually changes the inode number).
Finally you need to protect other important but not critical files,
such as timezone files or printer configuration files, often found
Also, on a production machine you are rarely adding users, so
the directories under
/home may be usefully monitored,
although a looser policy to allow legitimate users to add or change files
should be allowed (perhaps it is enough to monitor system account
Also it may pay to monitor
/root, but to allow
some files to change without reporting them (e.g.,
As a final change, consider resetting
LOOSEDIRECTORYCHECKING back to
If you do change your configuration file you must rebuild the
encrypted version (using the same command as before).
A copy of your journal pages, describing each task you performed to
install and configure Tripwire, and the answers to the questions
Include a copy of your Tripwire report (from the last
tripwire --check), as well as a copy
of your (final version of your) policy and configuration files.
You can send as email to
If email is a problem for some reason, you may turn in a hard-copy.
In this case
the pages should be readable, dated, and stapled together.
Your name should appear on the first page.
Don't turn in your whole journal, just a copy of the relevant sections. It is common in fact to keep the journal as a text file on the system (with a paper backup of course).
Please see your syllabus for more information about submitting projects.