CTS 2311 (Unix/Linux Security) Project #3
Setup Tripwire HIDS

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.

1. Install Tripwire.  If you like a challenge, install from the open source version.  (This tarball has makefile and other errors that must be fixed, before you can successfully build and install.)  Otherwise, install the binary RPM from the Fedora yum repository.
2. Once installed you will need to configure Tripwire.  You can make any changes you see fit to the twcfg.txt file.  I suggest two changes:  Set LOOSEDIRECTORYCHECKING to 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 tw.cfg (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 --cfgfile filename on every command you enter.

   What changes did you make to the default Tripwire configuration file?

3. You will eventually create (actually modify the default) policy file.  But initially you can use the policy file that ships with the Tripwire package, with a few additions.  For Fedora the default policy lists in detail every file that can be found if you did a full install (all packages).  But even this won't find files installed from non-standard sources, such as from tar-balls or yum packages 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.)

4. When done defining the initial policy and the tripwire configuration, generate the keys and digitally sign (and encrypt) your files.  This is done using commands similar to the following:

   # 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.

5. Generate the initial Tripwire database.  This is done by reading the (encrypted) configuration and policy files, and examining the system.  You will get lots of errors about missing files; these will be removed from the policy file later.  You create the database (in the location defined in your configuration file) with a command similar to this:

   # tripwire --init
   ... lots of messages ...
   The database was successfully generated.
   

   The tripwire database file has a name like servername.twd.  What is the absolute pathname of the Tripwire database file you just generated?  How big is this file?

6. Next run your first Tripwire check.  The command is something like this:

   # 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 hostname-date-time.twr.  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 tripwire --update-policy twpol.txt to update the encrypted version with your changes.

   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.

7. Now is the time to make any changes you want to the baseline policy.  This is the hard part, deciding on your policy and creating a policy file.  (See the Hints section below.)  What changes (if any) did you make to the baseline policy?  (If you made no changes, be sure to say so.)
8. After making changes to your configuration and policy, update those files and then run another check, to make sure no errors are found.  Then run the command touch /etc/tripwire/tw.pol.  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?
9. You can eliminate that error by performing a Tripwire database update.  This updates the errors found in a report by updating the Tripwire database.  Use a command similar to this:

   # tripwire --update --accept-all \
      -r /var/lib/tripwire/report/reportname
   

10. To be useful you should automate the Tripwire check to run via cron or anacron.  Exactly what would you need to do to have Tripwire run a check every night, and email a report to root?

The default configuration is probably fine, however you may wish to change pathnames of some of the files (I prefer putting databases and reports under /var), or the reporting options to use syslog rather than email.  (Or not!)  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.  (Using 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 twadmin and tripwire, especially the difference between updating a policy and creating one.

Making Changes to the Baseline Policy:

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 files.  For example binary directories and their contents should never be modified without detection: /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/[s]bin, /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 DLL files.

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 /usr, /opt, etc.  Additionally some programs put config files in strange locations, such as under /var/lib/someplace.

In /etc are a few special files that are expected to be present, but whose contents changes all the time.  Examples include mtab and ld.so.cache.  If you use a general policy rule for all of /etc and 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 under /usr someplace.  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 home directories).  Also it may pay to monitor /root, but to allow some files to change without reporting them (e.g., .bash_history, .viminfo).

As a final change, consider resetting LOOSEDIRECTORYCHECKING back to false.  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 asked above.  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 (preferred).  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.