Tiger
Kristy Westphal The typical systems administrator has more duties than it is humanly possible to accomplish in a regular work week. Security, unfortunately, always seems to be at the bottom of the list, although it should be one of the highest priorities on any network. There is also a distinction between having good security policies and enforcing them. Many companies claim they have good security policies on paper, but when you dig down into their systems, quite the opposite is true. This article covers the security tool Tiger that can help to enforce security policies without causing more work for the systems administrator. Tiger is a set of scripts that go through a UNIX system, checking for possible anomilies with the operating system. It then reports these anomilies for future attention by the security administrator. It was originally written for the purpose of monitoring the UNIX boxes at Texas A&M, but has since been made available for the UNIX community at large. With some initial setup time and ongoing monitoring, your network can be more secure and live up to the policies set in your corporate policies manual. Tiger is a freeware utility and was run here on HP-UX 10.20 boxes, but can easily be used and adapted for other flavors of UNIX. Configuration and Intrusion Detection Management There are several good tools available help the busy systems administrators keep an eye on their systems. These tools can be automated to run on a regular basis for continual monitoring. Tiger is a utility written by Douglas Lee Schales, Dave Hess, Khalid Warraich, and Dave Safford. It can be downloaded from:
http://www.net.tamu.edu/ftp/security/TAMUThere are three versions of tiger:
• tiger-2.2.3p1 is the latest TAMU distribution, with the check_devs and the check_rhosts fix applied. • tiger-2.2.3p1-ARSC is contributed by the Arctic Region Supercomputer Center. • tiger-2.2.4p1 is the TAMU distribution plus some changes to support Linux.
TAMU is specific to the Texas A&M University computers it was written for, but can be updated for usage on your systems (see the Updates section for further detail). I will refer to this version for the remainder of this discussion. Once Tiger is installed and configured on your systems, the scripts included will run various security checks. These checks include: irregularities in your group file, easily guessed passwords, files that create unwanted trust relationships between machines (rhosts and netrc), unrecommended PATH variables, as well as changed checksums on key operating system files. The scripts that do these checks can be run manually or automated (more on this later). The power in Tiger comes from it's configurable settings and logging. It provides easy to read reports of possible problems with your systems and it keeps historical information. Compromised systems can then be identified and isolated more quickly, hopefully preserving other nodes on your network. Once you have download the distribution, you will need to gunzip it and untar it in a secure, writable only to root, location. You can run tiger on your system as is or, if you would like to fully install tiger, you can do so through the Makefile, editing it to your choosing. Note that if you decide to run make install on tiger, you need to specify a separate directory to install to (as indicated by the TIGERHOME variable in the Makefile), or you will corrupt the version that has been untarred in the current directory. Using the Makefile install is useful if you want to install the files into directories other than the directory in which you untar the tiger distribution. If you want to keep the distribution as is, then it is not necessary to run make install. Updates -- The tigerrc File You will have some setup options to configure in several files. Three files you can configure (if you decide to run it out of the box) are the tigerrc, site-host, and config files. The tigerrc file is specific to Texas A&M, but the tigerrc-dist file is for the full distribution, so simply make a copy of it called tigerrc for your use. It may take a while to run from this configuration file, but it is a good way to baseline your system. Here are some various sections of the tigerrc file:
# # 'rc' file for tiger. This file is preprocessed, and thus # can *only* contain variable assignments and comments. # #---------------------------------------------------------- # # Select checks to perform. Specify 'N' (uppercase) for checks # you don't want performed. # Tiger_Check_PASSWD=Y # Fast Tiger_Check_GROUP=Y # Fast Tiger_Check_ACCOUNTS=Y # Time varies on # of users Tiger_Check_RHOSTS=Y # Time varies on # of users Tiger_Check_NETRC=Y # Time varies on # of users Tiger_Check_ALIASES=Y # Fast Tiger_Check_CRON=Y # Fast Tiger_Check_ANONFTP=Y # Fast Tiger_Check_EXPORTS=Y # Fast Tiger_Check_INETD=Y # Could be faster, not bad though Tiger_Check_KNOWN=Y # Fast Tiger_Check_PERMS=Y # Could be faster, not bad though Tiger_Check_SIGNATURES=Y # Several minutes Tiger_Check_FILESYSTEM=Y # Time varies on disk space... can be hours Tiger_Check_PATH=Y # Fast for just root... varies for all Tiger_Check_EMBEDDED=Y # Several minutesThis first section lists the various checks that tiger will run on your system, along with the estimated speed with which it runs. A guideline here is to weigh what is more important to you: how long it runs vs. what you really want to watch out for. All of the scripts run important checks, but if you aren't interested in waiting a few hours for the FILESYSTEM scan to run, or can't run it in off-hours, you may want to turn it off. It's a good idea to run it at some point, however, as it checks for suid files, device files, unowned files or files without groups, and other suspicious files. The PATH check looks at file permissions in root's path. The EMBEDDED check looks for embedded path names. The rest of the checks are fairly self-explanatory. The next variable to look at is:
Tiger_Run_CRACK=Y # First time, ages; subsequent fairly quickcrack is a great tool to run against your password file to see if passwords can be guessed. As the comment says, it will take a long time to run this at first, but it is very worthwhile. This tool alone can help to enforce a stronger password policy to show your users that changing their passwords to a good password is a smart idea. In order for the password checking script to work on your systems through tiger, you will need to have the software already installed. You can download it from:
ftp://ftp.cert.org/pub/tools/crack5.0.tar.gzOne of the simplest and most important network policies that any enterprise can encourage is the use of good password policies. Enforcement of this can be managed through user education and the use of a password cracker script. When the passwords are guessed, it is imperative that the user is notified right away to change it or that the account is locked in the case of persistent abusers. Making an effective password policy work for users is probably one of the hardest goals to achieve. It can be a lot of overhead (in support terms) to have passwords checked and followed up on regularly. However, if you as an administrator can guess these user's passwords, then a hacker can as well. In other words, leave the password checking utility as one of your options in the tigerrc file (even if it takes a long time)! The next variable to note is:
Tiger_CRON_Output_Width=0If you do decide to change this variable, change it one time and leave it like that. After running tiger through cron several times, you will want to run diff on them to check for differences. If you change the width of the log files, you will get more differences than you bargained for!
Tiger_Embed_Max_Depth=3This variable lists the limit of directories that tiger runs through recursively when searching for embedded paths in executables. Be wary of setting this much higher than the default, or it could take a very long time to run.
Tiger_ROOT_PATH_OK_Owners='root'When checking for executables in root's path, tiger will check for ownership of executables based on what you have set here. The recommendation would be to leave it at root, so if anyone has placed suspicious binaries in root's PATH that are not owned by root, you will be alerted. There is also a variable that looks for legitimate ownership of files in user's PATH statements. You may want to add any other possible owners here, so you don't get a lot of notices kicked back to you. Nearing the end of the tigerrc file, there are a few variables you should be aware of. If you want tiger to wait for CRACK to finish running, you can set the Tiger_Collect_CRACK variable to “yes” (default is no). You can also select whether you want CRACK to check only local password files with Tiger_Crack_Local. There is also a section regarding what types of files you would like to look for when doing the FILESYSTEM scan:
Tiger_FSScan_Setuid=Y # Setuid executables Tiger_FSScan_Devs=Y # device files Tiger_FSScan_SymLinks=Y # strange symbolic links Tiger_FSScan_ofNote=Y # weird filenames Tiger_FSScan_WDIR=N # world writable directories Tiger_FSScan_Unowned=N # files with undefined owners/groupsThese are fairly self-explanatory in what they do; however, if you are looking for things to cut out of your scan, don't cut out the Setuid, Device, and World Writable directories checks. The other areas are also important, but can be skipped to give you a little less to scan through in your logs. More Updates The other files you will need to change are: 1) The site-host file -- make a copy of the site-sample file naming it for the host you will be running from, or just call it “site” and edit it. 2) The config file -- to specify where you want keep logs and other files. See sidebars for examples of these files. Items in the site-host file that must be customized include the paths for FIND and AWK (if they are different from what is listed) and the correct path for the CRACK utility. There are several items in the config file to note. The first section lists numerous commands with their paths. Run through these quickly to see whether there are any discrepancies with paths on your system, and make changes accordingly. The second half of this file is specific to tiger and does not need to change. It refers to the various scripts that tiger runs as it checks your system. The Signature File An unfortunate hitch in tiger is that the signature files for operating systems other than SunOS and Solaris are not provided (the signature file contains an encrypted checksum for critical system files). This is an important part of why you should run tiger in the first place, so you will need to create your own signature file if you do not run either SunOS or Solaris. To do this, you can utilize the MD5 algorithm script located in the bin directory of your distribution to run against essential files that need to be monitored on your systems. You can use one of the available Solaris signature files (located on the ftp site where you downloaded tiger) as a guide for your list of files, and simply run the command:
md5 /usr/etc/in.telnetdwhich should produce a line similar to:
Y . /usr/etc/in.telnetd 657163eb 45e21f05 c7f08784 \
a8fc6ce7208ae4f9 2e766d11 6f30f8b6 ec461a4d SunOS 4.1.1
Repeat for each file in your list until you have a complete set for your system. I have created a base one for HP-UX 10.20, which can be found on Sys Admin's Web site. When you make your own, place it under the appropriate OS type in the system directory of your tigerrc distribution.Running Tiger Now that you have invested the time configuring tiger, it is time to run it! Before you begin running tiger, you should start with a clean OS install with the latest patch versions to be sure your systems have not already been compromised. Unfortunately, your busy schedule may not allow this luxury. Keep this in the back of your mind as you continue the enforcement of your security policies. Running tiger itself requires just a few more decisions. You can run tiger by using the tiger executable from the directory where you untarred it, or the base directory of where you ran your make install earlier. Or, if you want to test tiger to make sure the options are set correctly, you can run it with a -t. Indicating a -B option tells tiger where your base install directory is, instead of the directory where you currently are. Once you have set up the details in tiger, you can set it up to run regularly either as a cron job or through the included script called tigercron. Through cron, you can run the entire script at one time; whereas, through the tigercron script, you can run certain pieces of it at a time and not bog down your busier systems. You will need to decide which systems to install and run tiger on, depending on the size of your environment. Tiger runs specific to a certain host, as seen in the site-sample file. Therefore, the larger network you have, the more work will be involved in distributing and setting up tiger. Creative scripting will help in this area, especially if you include the cron job to run tiger at regular intervals. How you gather and read all of those reports that tiger generates depends on your environment. One way is to have the output of tiger mailed to the person responsible for maintaining security at your site. Another way is to set a cron job on a single machine that gathers the reports from the boxes and scans them for differences over prior runs. These differences could then be dumped to another file for the security person to review. There is also a mailing list that you can join so that you can keep updated on any changes in tiger. You can sign up through: majordomo@net.tamu.edu with “subscribe tiger” in the body of the message. Summary In conclusion, dedicating a little time by using some basic utilities to monitor important aspects of your network can help you enforce a network security policy. The real key, however, is accountability and vigilance in keeping up with the latest exploits, watching your logs for suspicious behavior, and making the necessary changes to keep your network secure on an ongoing basis.
About the Author
Kristy Westphal is a network administrator, skilled in troubleshooting and process analysis. Her 6+ years of experience in the IS field have allowed her to become knowledgeable in UNIX and NT, as well as project management and security/disaster recovery planning. Kristy is now a Senior Consultant for Integrated Information Systems. She can be reached at: cpwkaw@primenet.com.
|