TITAN -- A Systems Administration Approach to Security
Dan Farmer, Brad Powell, and Matt Archibald Systems administrators usually spend the day getting bounced from one manager or end user issue to another, being cornered in the hallway for those can-you-do-me-a-favor friends, or just plain fixing or tweaking the same operating system settings and problems over and over again. A new server or desktop gets installed, and we have to run through the list of settings that need to be modified post-installation before the machine can run in our environment. Our partner systems administrator decides to do a favor and patch all of our servers over the weekend, and on Monday it's “Oh, I forgot to do that...”. Typically, as soon as we become able-bodied, shell-programming novices, we all end up spending time coding small tools to do this followup work for us. So, What is TITAN? TITAN is a collection of small tools, created or gathered by Brad Powell currently at Sun Microsystems, that is used to set a desired security posture in UNIX. Dan Farmer, currently at Earthlink, and Matt Archibald convinced Brad to let them add some additional functionality and bundle these tools into a single, relatively smart configuration and test utility. In December 1998, TITAN was released to the public at the Usenix-LISA conference held in Boston. To date, TITAN has been downloaded by over 1500 security and systems administration peers. A Brief Primer on Information Security Risks Information security exists to protect your company's assets, the integrity of the operating system, the accountability of user transactions, and the proprietary nature of the information contained and managed by and for all of the above. Keep in mind that, no matter who tries to sell you something, there are no technological silver bullets to guarantee the security of your operating systems or information. Strong deployment of information security relies on the marriage of technology and “operational readiness”. There are three primary operational-readiness layers that are most likely to be attacked to gain unauthorized access to proprietary information or networked systems from which to launch privileged user account attacks:
1. Information about your operating system a. Vendor name and version number b. Known bugs, patches, publicly available exploits 2. Information about the network services you are running a. Access to shared filesystems and account information (NFS, AFS, NetBIOS, etc.) b. Listing of current user accounts on the system and recent activity (finger/rwho, etc.) c. Known bugs, patches, publicly available exploits 3. Information about the user accounts available on the system, in your company phone book, on public Web sites, etc. a. Social engineering attacks (HelpDesk password changes, dial-up information, etc.) b. Password-guessing seed data, accounts to use as your attack base across all networked systems/shared filesystems, from the Internet, etc. c. Avenue through which to launch attacks against #1 and #2 above, that typically, if seen at all, are ignored by many systems administrators Why Would I Want to Use TITAN? The better question would be “Why wouldn't I want to use TITAN?”. First, you need to understand how TITAN deals with each of these three primary security risks. TITAN tries to provide at least a partial solution to all these problems by attempting to locate and fix many of the more common procedural problems, as well as put into one place all those OS tweaks that can assist in securing your system. TITAN improves the security of a system by:
• Cutting off entry points into the system • Mitigating or preventing the effects of various denial of service (DOS) attacks • Turning on or improving the level of logging and auditing features • Improving network and local (e.g., host level) defenses • Assisting in programmatically defining and enforcing a system security policy
Note that TITAN's focus is on the correction of procedural problems. While it can be used as an adjunct to other auditing tools, whether host or network based, it does not attempt to find problems that it cannot correct. An automated tool that changed weak passwords, unpatched or insecure system binaries, and unrestricted filesystem mounts, for instance, could break or disrupt operations to an unacceptable level. Like most other security tools, TITAN is not meant to be used only once. Achieving effective security requires continued concern and attention to good security practices. Competent systems administrators should have considered, if not resolved or repaired, nearly all of the problems that TITAN addresses on their own security-critical systems. TITAN's Main Design Goals Security comes first -- We mandated this concept for TITAN. After TITAN has been run on a system, that system should be more secure than before, and there will be no remaining significant host- level security problems, other than those involving vendor OS and independent daemon security issues and patches (e.g., if the system is a Web server, CGI or CGI-like interfaces could be problematic). The system will not be 100% secure -- none are -- but it will be pretty darn secure, especially after applying security patches. Due to customer pressure, vendors can't take the chance with their patches and system releases that things will break -- but we can. In our testing and use over the years, we haven't run into a single thing that TITAN has irreparably broken, but it certainly could happen. Easy to use -- TITAN should be simple to install and run. Although knowledge about the system always helps, you can trust TITAN to do the right thing in most cases. Policy based -- TITAN can assist in the creation of a programmatically defined technical system or site security policy. Classes or types of security (such as firewall, desktop, etc.) are simple to define and apply to the appropriate system, and help produce a consistently secure system in ways that are readily comprehensible. Freely available source code -- In security, it is imperative to have complete source code availability. Having full control over what is run, and possessing the potential for total understanding of exactly what actions it performs, is mandatory for a truly effective security tool. Modular -- TITAN is non-monolithic and easily extended. Shell scripts or other programs can either be removed or added into TITAN's framework. Doing so will not affect the other programs. Useful -- Quite simply, we've found TITAN to be enormously handy and something that can be used quite frequently if security is a significant concern for you or your systems. What TITAN Does Not Do It is important to note that there are several procedural security problems that TITAN does not attempt to fix or seal off. CGI programs, often deployed on Web servers, are becoming one of the more widespread security problems on the Internet, and are nearly impossible to programmatically detect or prevent. TITAN also does not render a system impervious to break-ins -- not only are inside attacks common, but new bugs and holes are constantly being found. Remember -- there is an arms race going on out there. Additionally, TITAN does not address the problems of secure software distribution or updates. This means that TITAN is probably not a viable tool to secure all systems on a large network due to the administrative costs involved in setting up and maintaining all the copies of TITAN. Of course NFS, rdist, or other methods of software replication and deployment could be used. Be warned that there are risks in such methods and that controlling an organization from a central location probably outweighs the benefits in most situations. Each TITAN module accepts one of three arguments -- Fix (-f or -F), Verify (-v or -V), or Inform (-i or -I). The Inform argument merely prints out what the script will do. Unless run under the policy mode, TITAN runs the modules in alphabetical order (sorted by the shell using the “*” wild card.) How to Install and Use TITAN Using TITAN is fairly simple, but we want to reiterate that it cannot secure a system, nor fix problems that will inevitably arise unless you continue to run it. You might consider choosing a non-production machine as a guinea pig, and only after sufficient testing, run TITAN on one of your production systems. Regardless of what system you choose, we suggest that you employ the following sequence when first utilizing TITAN:
1. Read the TITAN documentation and look at the programs. Does it do what you want? Does it fit into your security policy? 2. Examine or secure your system using your normal set of tools and procedures. Note any flaws. 3. Back up your system. 4. Run TITAN in Verify mode and examine all of the logs for FAIL messages. These indicate configuration areas that should be addressed to enhance your security posture. 5. Decide which configurations can be modified while still allowing you to conduct business as required. 6. Create your own local TITAN configuration file with Verify and/or Fix flags set for each appropriate TITAN module. (See the TITAN documentation for details.) 7. Examine your system again. Are the flaws gone? Are new ones present? Does everything still work? 8. Continually monitor your system, running TITAN in Verify mode at least once a week. 9. Report any problems found with TITAN to us at titan@fish.com, so we can fix them in subsequent releases! How TITAN Runs TITAN includes a master script (called Titan), which runs a collection of Bourne shell, Perl, or other shell scripts called TITAN modules. However, before getting any results or fixes from TITAN, you must first run the TITAN-Config script, which figures out which OS type and version you're running and creates links to the proper TITAN modules. Unless something goes awry, this takes no input from the user (other than -i, install or -d, deinstall). Once configured, TITAN has three primary modes of operation to choose from: Fix, Verify, and Inform. Fix, the most commonly used, simply tells TITAN to run out and fold, spindle, and mutilate your system in all the various ways it can to create a more secure system, while informing you of what it is doing. Verify mode uses the same set of tests, but instead of changing the system, it simply informs you that various changes would be made if run in the Fix mode. Inform mode takes no investigative or corrective action, but simply echos the function of each module. Unless you're using a predefined policy, the main TITAN script will run all the programs in the module directory with the same mode. You can either create a policy or simply move any modules that you don't want out of the module directory, and TITAN will not run them. The Anatomy of a TITAN Module Although TITAN can run any executable program, it is currently written almost entirely in Bourne shell. The TITAN scripts are heavily commented, and were intended to be easy to understand. Following the same general form, they start by setting a safe umask with the following copyright notice:
: # umask 022 # This tool suite was written by and is The scripts then set the path and perform a sanity check to verify root is running the program (since TITAN almost exclusively modifies root- or system-owned files, it makes little sense to run it as anything else):
# who am I?
MYNAME=`basename $0`
# UCB rules!
PATH=/usr/ucb:/bin:/usr/bin:/sbin
# did things work out or not?
action=`./sanity_check $MYNAME $1`
if test $? -ne 0 ; then
exit 1
fi
TITAN scripts then have three functions -- Intro(), Check(), and Fix() -- to do all the serious work. The Check() function is used when a TITAN script is run in the -v (“V” for Verify) mode. You might look through a few of the TITAN scripts to see some of the ways the Check() function examines the system. The only action that all TITAN scripts do in the Check() function is to output either PASSES CHECK or FAILS CHECK, so users can figure out if this TITAN fix is needed or already applied to the system. It can be as simple as (taken from dmi-2.6.sh):
Check() {
if [ -f /etc/init.d/init.dmi ]; then
echo " dmi daemon is enabled: FAILS CHECK"
exit 1
else
echo " dmi doesn't start at boot time: PASSES CHECK"
fi
}
The fix code is similar, but instead of simply stating that there is a problem, it actually takes action. This code snippet is from disable-L1-A.sh, which disables the L1-A or stop-A keyboard sequence by modifying /etc/default/kbd:
if [ -f /etc/default/kbd ] ; then
echo " Disabling the abort sequence "
ed - /etc/default/kbd <
Finally, a TITAN module processes the user arguments to see what action to take; it returns a 0 if the module is successful, and non-zero if something goes wrong. Building a TITAN Module To build your own TITAN module, you might want to start out with the ${TITAN-HOME}/arch/sol2sun4/src/stubs/skeleton script -- unless, of course, you want to write something other than in Bourne shell. The key points are that the module accepts the basic three arguments (-i, -v, and -f) as well as outputting an appropriate message based on the success, failure, or the detection of a problem. For example, simply create a Perl program called runme.pl, which accepts the standard TITAN arguments (-i, -v or -f) and put it into the TITAN module directory. Running titan -f would cause all the scripts in that directory -- including your new one -- to be executed with the -f flag. Note that if you write a TITAN module, it will be run as root and probably mangle the system in some fashion. Be careful with the code -- it's easy to disable or otherwise make a system useless with a single errant character or a subtle logical error. Availability Primary release copies of TITAN, including PGP-signed releases and MD5 checksums, are available from http://www.fish.com/titan. There may be other copies available on the Internet. Accept no substitutes! If TITAN does most of the things that you personally do to secure your systems but misses a few points, you might consider writing some additional TITAN modules to perform the tasks. We also ask you to send us email about this -- if security related, we would certainly consider including your module in the general TITAN release or rewriting it ourselves. If we include it, your name will be added to the credits. Cool, huh? Up to Date Notes on TITAN Releases Note that because of time, resource, and expertise limitations, the first release of TITAN is only known to run on Sun Microsystems Solaris Operating Systems -- versions Solaris 2.x and Solaris 1.x. However, many of the small sub-programs within TITAN work well with other UNIX flavors, and other than taking the time to create TITAN modules for them, there is nothing Sun-specific about TITAN to prevent it from working on other UNIX systems. Conclusions Host-based security is not dead, even in the largest installations. Indeed, as organizations grow larger and their resources drop correspondingly, they will be required to pick their security fights wisely -- and we feel that TITAN can be useful in protecting or evaluating the security of key systems, such as firewalls, production servers, and other critical hosts. TITAN has been invaluable to us in our work as security professionals -- running TITAN improves the security of a system in almost all cases. And although it is not impossible to create tight, well-maintained, secure systems, it is time consuming and very difficult! Also it's easy to miss one or more of the many (sometimes crucial) details. Most professionals end up cobbling together various tools using ad hoc checklists when installing or auditing a system. TITAN is well suited for auditing systems as well as creating automated, formal checklists. If a technical security policy does not exist, it can suggest the beginnings of one and either determine or force the adherence of a system to it. It should be said, as disappointing as this may be, that the creation of a secure system is (and will probably always be) far more involved than simply running a computer program. Without a good security policy that is adhered to, and a diligent and conscientious systems administrative staff that keeps abreast of the latest security news and issues, TITAN is relatively useless. TITAN's development future seems bright. Brad, both the originator and the main force behind the effort, has worked on and used TITAN for many years, and has no plans to abandon it now. The other co-authors will be contributing as well, and while we all hope that the Internet community will give ideas or TITAN modules, TITAN's future is not dependent on that. Methods for backing out of the changes TITAN makes, a simple GUI interface for policy management, and ports to other systems are all currently being investigated. Security tools, from COPS, the TCP wrappers, Crack, Tiger, SATAN, to the many commercial security tools currently available, are invaluable to keeping systems monitored and secure. This is why we respectfully put forth TITAN as another freely available tool in the public security defense arsenal, and hope that it proves as valuable to you as it has for us.
About the AuthorDan Farmer does security research at Earthlink Networks, Inc. In past lives, he has authored or co-authored various security programs and papers, most notably the COPS and SATAN packages. He also worked for several years at Sun Microsystems with Brad and Matt and can be reached via email at: zen@fish.com. Brad Powell has been in the Computer and Network Security field for more than 10 years. As Senior Security Architect for Sun Professional Services, he designs security solutions including Firewalls, Security Architectures, and specialized security products for banks, industry, and government agencies. Brad can be reached at: brad.powell@eng.sun.com. Matt Archibald left Sun Microsystems Inc. in 1992, after 5 years as a systems admin/security engineer. After some extended work outside of Sun Microsystems dealing in building and managing mixed-platform environments, he joined Securix/Dynasoft in 1994 as a Security Consultant. Today he works as the Director of Security for a large Silicon Valley corporation. Matt can be reached at: ir003355@mindspring.com. |