Getting Started with Tripwire (Open Source Linux Edition)
A crude yet effective intrusion detection system such as Tripwire can alert systems administrators to possible intrusion attempts by periodically verifying the integrity of a server’s file systems. Systems intruders will often use trojan binaries for login, su, ps, and ls, etc. to cover their tracks and keep a low profile on the system. Under normal circumstances even astute systems administrators may not observe the intrusion because the trojan binaries mimic the system binaries so well.
One tried and true method to alert systems administrators of unexpected file system alterations is to use a software package such as Tripwire to keep a database of checksums on the file sizes of critical system files. Depending on the configuration, Tripwire can notify appropriate personnel if a critical file or directory is modified or deleted.
By using a strong checksum method similar to MD5, Tripwire can identify with absolute certainty whether or not a file has been modified, unlike similar programs that use weaker algorithms such as CRC to calculate checksums.
Also, for maximum effectiveness Tripwire should be installed at the time the operating system is installed to ensure that the system does not already have any trojan binaries. Tripwire is only as reliable as the initial file system its database is based upon. If the file system has already been attacked, then Tripwire can only identify further damage to the filesystem, if that.
The Linux Open Source Edition
Recently, Tripwire, Inc. has decided to open the source for a more recent version of the Tripwire package specifically for the Linux OS. Previously, a binary only version of the software had been made available to the Linux community and another version of the software with and an older, less featured academic source license had been available to the public. The Linux open source edition includes most of the newer features of the software, such as the ability to alert specific administrators for different areas of alterations, while remaining compatible with the commercial version of the software.
Getting the software
Download the source here: http://erikimh.com/files/tripwire-2.4.2-src.tar.gz
tar xvzf tripwire-2.4.2-src.tar.gz
Note that all Tripwire associated files will be kept in the /usr/local/etc/ directory by default. Binaries will be installed in /usr/local/sbin. If you prefer your files in /sbin and /etc, append –prefix=/ to the configure command below.
./configure
make
make install
Note: If you receive an error during configure such as:
configure:9002: error: C++ preprocessor “/lib/cpp” fails sanity check
This means your system is missing g++ and it’s failing the sanity check. If you’re seeing this error, you’re likely running a debian/ubuntu box. In which case, simply run:
sudo apt-get install g++
Initial Tripwire Configuration
Because very few Linux installations are identical, Tripwire will need a fair amount of configuration to adequately protect the system. Configuration begins during the installation script launched above with the selection of site and local passphrases. These passphrases are the key to preventing intruders from modifying your Tripwire installation and circumventing its protection so strong passphrases are essential!
The site key is used to sign Tripwire’s policy and configuration files while the local key is used for signing the database files. For enterprise wide installations, the use of multiple levels of passwords makes Tripwire more manageable by allowing a site to split administration functions across by a number of system administrators.
During the installation process, be sure you choose secure passphrases for your keyfiles and write them down and store them in a secure location.
The installation script creates default policy and configuration in plain text files stored in /usr/local/etc/ as twpol.txt and twcfg.txt. These files are in cleartext and need to be removed from the system as soon as the encrypted versions are in place for obvious security reasons. The encrypted versions of these are created in the steps below, and stored in /usr/local/etc/ as tw.pol and tw.cfg respectively.
Creating a Custom Policy (advanced)
You’ll want to custom tailor the twpol.txt file to your specific system environment. This allows you to monitor nearly any aspect of a file or directory, depending on the type of file. The types of files and monitoring strictness is defined using pre-defined variables as well as custom flags that you can add or remove per file or directory.
Here’s a list of pre-defined variables followed by their flag definitions:
Device = +pugsdr-intlbamcCMSH ;
Dynamic = +pinugtd-srlbamcCMSH ;
Growing = +pinugtdl-srbamcCMSH ;
IgnoreAll = -pinugtsdrlbamcCMSH ;
IgnoreNone = +pinugtsdrbamcCMSH-l ;
ReadOnly = +pinugtsdbmCM-rlacSH ;
Temporary = +pugt ;
So, for example, If you have a line in your policy file that says:
/etc/rc.d -> $(IgnoreNone) -SHa ;
You are actually telling tripwire to check the files in /etc/rc.d against the $(IgnoreNone) rule set, but exclude the SHa checks:
+pinugtsdrbamcCM-SHa ;
So, what do these actually mean? I thought you’d never ask:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
############################################################################## # # Property Masks # # - ignore the following properties # + check the following properties # # a access timestamp (mutually exclusive with +CMSH) # b number of blocks allocated # c inode creation/modification timestamp # d ID of device on which inode resides # g group id of owner # i inode number # l growing files (logfiles for example) # m modification timestamp # n number of links # p permission and file mode bits # r ID of device pointed to by inode (valid only for device objects) # s file size # t file type # u user id of owner # # C CRC-32 hash # H HAVAL hash # M MD5 hash # S SHA hash # ############################################################################## . |
Policy Examples and Demonstration
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181 # Demonstration policy file for Linux and Unix/etc/hosts -> +pinugs; # This is a very basic rule.# Tripwire will alert you if any of# the specified properties for# the file /etc/hosts are modified.!/etc/init.d ; # The "!" indicates a stop point.# The directory /etc/init.d will# not be scanned.!/etc/netmasks ; # Stop point on a file. Tripwire# will not scan /etc/netmasks"/home/fred/big file" -> +pingus; # Double quotes can be used to# protect special cases such as# filenames with spaces and escaped# characters."/home/emu/o\163trich" -> +s; # Escaped octal character"/home/emu/\x64odo" -> +m; # Escaped hex character"/home/emu/blue\'jay" -> +c; # Escaped character# The following rules demonstrate a scan using each of the individual# property selection masks./etc/passwd -> +a; # Access timestamp/etc/passwd -> +b; # Number of blocks/etc/passwd -> +c; # Inode timestamp (create/modify)/etc/passwd -> +d; # Inode storage disk device number/etc/passwd -> +g; # File owner's group ID/etc/passwd -> +i; # Inode number/etc/passwd -> +m; # Modification timestamp/etc/passwd -> +n; # inode reference count/etc/passwd -> +p; # Permissions and file mode bits/etc/passwd -> +r; # Device Number/etc/passwd -> +s; # File size/etc/passwd -> +t; # File Type/etc/passwd -> +u; # File owner's user ID/etc/passwd -> +l; # File is increasing in size/etc/passwd -> +C; # CRC-32 hash value/etc/passwd -> +M; # MD5 hash value/etc/passwd -> +S; # SHA hash value/etc/passwd -> +H; # Haval signature value# Rules can be given specific attributes which influence how tripwire# behaves either while scanning or when it detects an infraction./etc -> +ug (recurse=false); # The recurse attribute controls# recursive scanning of the# contents of a directory. In this# case, recurse is set to false, so# tripwire will scan the /etc# directory but not its contents./etc -> +ug (rulename=software); # Setting a rulename allows you to# associate a rule or set of rules# with a specific name. This can# help you to sort data in your# Tripwire reports. For this rule,# any infraction in the /etc# directory will appear as part of# the "software" section of the# report./etc -> +ug (emailto=admin@domain.com); # The emailto attribute will cause# Tripwire to send email to a# specified user if the indicated# rule is broken. In this case,# admin@domain.com will receive a# tripwire report if someone# changes the user or group id on# any file in the /etc directory./etc -> +ug (emailto="admin@domain.com webmaster@domain.com")# you can use quotes to email to# more than one person./etc -> +ug (severity=50); # You can set the severity of a# rule so that you can quickly scan# through a report to find the# most critical changes.# Setting variables is a good way to easily change the parameters for# several rules at once.param1 = +SMCH; # Set variable param1.dir1 = /etc/inet; # Set variable dir1DIR1 = /etc/init.d; # Variables are case sensitive$(dir1) -> +tbamc; # Rule using directory substitution# or "left Hand substitution"/etc/inet -> $(param1); # Rule using selection mask# substitution or "Right Hand# substitution".$(DIR1) -> $(param1); # It is also possible to do a# double substitution.# Tripwire also provides several predefined variables./etc/httpd/weblog -> $(Growing); # The Growing variable is intended# for files that should only grow,# such as the web log in this# example. Growing uses the# following masks: +pinugtdl/etc/passwd -> $(IgnoreNone); # IgnoreNone should be used on# critical files such as passwd.# It checks all file attributes:# +pinusgamctdbCMSH/home/fred/mytextfile -> $(IgnoreAll); # If you want to track a file's# presence or absence but do# not care about its properties,# use IgnoreAll. IgnoreAll ignores# all attributes: pinusglamctdbCMSH/usr/httpd/index.html -> $(ReadOnly); # ReadOnly is good for files that# are widely available but are# intended to be read-only.# Attributes: +pinugsmtdbCM/home/fred -> $(Dynamic); # Dynamic is good for monitoring# user directories and files that# tend to be dynamic in behavior.# Attributes: +pinugtd/dev/null -> $(Device); # Device is appropriate for checking# system devices and any other# files that may be important, but# should be relatively static and# accessed often: +pugs# Directives are useful if you want to use one policy across your network# servers, but also require special rules for each machine.@@ifhost salmon # The following rule will only run/etc -> +abcdgimnpstul; # will only run if the server name# is salmon.@@else/bin -> +abcdgimnpstul; # All other servers will run this@@endif # rule.# Directives can also be nested:@@ifhost crayfish/etc/passwd -> $(Growing); # Will only check /etc/passwd if# your hostname is crayfish.@@else # Otherwise it will check if your@@ifhost salmon # hostname is salmon. If so it/etc/passwd -> $(IgnoreAll); # will ignore passwd.@@endif # If your server has any other name/etc/passwd -> $(IgnoreNone); # then passwd is fully examined.@@endif# The following examples demonstrate more complicated uses of Tripwire that# are more likely to be seen in a real environment.# Trailing rules: These are typical of the rule format used in most of# this file. This is by far the most common usage./home/fred/specialfile -> asd (emailto=fred@domain.com, Rulename=special, severity=50);/home/fred/generalworkfile -> bm (Rulename=work, severity=60);/home/fred/myreport -> CSH (Rulename=report, severity=75);/home/fred/mypresentation.data -> Mpi (Rulename=urgent, severity=90);# Preceding rules: These are extremely helpful if you wish to apply a rule# to a large group of files or directories.(Rulename=standard, severity=30){/home/fred -> lgu;/home/jane -> CHM;/home/project/report.file -> $(Growing);}.
Installing your custom policy
After making your modifications to the .txt files, the default policy should be installed using the command as root:
/usr/local/sbin/twadmin -m P /usr/local/etc/twpol.txt
Now, lets generate the initial database using the following command as root:
/usr/local/sbin/tripwire -m i
Note that the -m switch identifies the mode in which Tripwire is being executed, which is “i” for “initialization” in this case. Later, the “c” mode for “check” will be used. Expect the initialization to take quite a long time, even on a fast machine.
Customizing Tripwire’s Configuration
Once and initial database is created, some customization is necessary to prevent the issuance of a large number of false alarms. These false alarms occur any time there is a discrepancy in the default policy and the local system’s current configuration. The default policy probably includes monitoring for a number of files not present on the local system, so it’s important to trim these files out of policy. To generate a listing of the discrepancies between the local system and the default policy, issue the following command as root:
/sbin/tripwire -m c | grep Filename >> twtest.txt
Note that this command will also take several minutes to complete. Once this listing has been generated, edit the policy file, /usr/local/etc/twpol.txt, and comment out or delete each of the filenames listed in twtest.txt.
Additionally, there are other files in the default policy that may not make sense to monitor on the local system. These include lock files (which identify that some process is in use) and pid files (which identify the process ID of some daemons). Since the files are likely to change often, if not at every system boot, they can cause Tripwire to generate false positives. To avoid such problems, comment out all of the /var/lock/subsys entries as well as the entry for /var/run.
Finalizing the Tripwire Configuration
Any time the tripwire policy file is edited, the policy needs to be reinstalled and the database will need to be recreated. As before, these tasks are accomplished by issuing the following commands as root:
/usr/local/sbin/twadmin -m P /usr/local/etc/twpol.txt
/usr/local/sbin/tripwire -m i
At this point it wouldn’t be a bad idea to repeat the customization procedures just to ensure that none of the unnecessary files listed in twtest.txt were omitted.
It’s now safe to delete the clear text versions of the Tripwire policy and configuration files, which can be performed by issuing the following command as root:
rm -f /usr/local/etc/twcfg.txt /usr/local/etc/twpol.txt
If they need to be restored cleartext versions of these files can be created from the encrypted versions by issuing the command (and providing the appropriate passphrases):
/usr/local/sbin/twadmin -m p > /usr/local/etc/twpol.txt
Note that unlike before, the “p” in this command is lowercase.
Finally, it is desirable to save a copy of the database at least initially and periodically if possible to read-only media such as CD-R. Having read-only copies of the database file is the only way to guarantee 100% that Tripwire’s database is authentic.
Scheduling a Nightly Tripwire Analysis
Without regular checks of the filesystem, Tripwire is effectively useless, so this section will identify how to schedule Nightly Tripwire Analyses that are e-mail to the system administrator.
First, one needs to create a shell script for generating the Tripwire reports. Creating the shell script can be more useful than just placing the command in the crontab because it allows the administrator to perform a filesystem check without needing to remember the exact syntax necessary for doing so.
Create the file “runtw.sh” in the directory /usr/local/bin that has the following contents:
#!/bin/sh
/usr/local/sbin/tripwire -m c | mail -s “Tripwire Report from $HOSTNAME” root@localhost
Feel free to change root@localhost to any e-mail address. Don’t forget to make the shell script executable by root:
chmod +x /usr/local/bin/runtw.sh
Now, schedule the script to execute nightly at 1:01am by adding the line:
1 1 * * * /usr/local/bin/runtw.sh
to root’s crontab using the command:
crontab -e
Tripwire will now submit nightly reports to the system administrator on the status of the file system’s integrity.
Resource Usage Optimization
The operations performed by Tripwire by nature are very resource intensive, both for CPU and I/O. The recommendation for nightly tripwire checking/reporting in this article runs at off peak hours (after 01:00). On highly populated machines or when manually regenerating the database this may cause resource issues. To help alleviate this, I recommend prefixing all /usr/local/sbin/tripwire commands with “nice” and “ionice“. This is outlined briefly below:
nice -n 19 ionice -c2 -n7 /usr/local/sbin/tripwire …
For details and more information on using nice and ionice, please see my article at http://erikimh.com/nice.
Conclusion
With the help of this walkthrough, one should be able to prepare a fully functional Tripwire installation. However, this article has barely scratched the surface of Tripwire’s feature set, which also includes determining the level of seriousness of an affected file or directory, reporting to syslog, and many other advanced features. Some other sources of information include the fine man pages (tripwire, twadmin, twintro, twfiles, twpolicy and twconfig), Red Hat Documentation, and Tripwire, Inc.
Thanks to Linux Security, The central voice for Linux and Open Source security news for this very helpful information. Additionally, Yunliang Yu from Duke University has written a HOWTO on implementing this across an entire network. You can read his article here.
Source: http://www.linuxsecurity.com/content/view/117563/171/
Tweet
Thank you very much. Helped me a lot. Best tutorial found on creating a Custom Policy using Tripwire.