[Image] TITAN's view of the world ------------------------------------------------------------------------ TITAN 3.0 FCS Abstract Titan is a collection of programs, each of which either fixes or tightens one or more potential security problems with a particular aspect in the setup or configuration of a Unix system. Conceived and created by Brad Powell, it was written in Bourne shell, and its simple modular design makes it trivial for anyone who can write a shell script or program to add to it, as well completely understand the internal workings of the system. Titan does not replace other security tools, but when used in combination with them it can help make the transformation of a new, out of the box system into a firewall or security concious system into a significantly easier task. In a nutshell, it attempts to help improve the security of the system it runs on. NOTE - due to time and resource limitations, the first release of Titan will only run on Solaris, versions 1.1.4 and 2.X. Other than taking the time to create Titan modules for other systems, there is nothing Sun-specific about Titan that would prevent it working on other Unix systems. Introduction Unix is often, and justifiably, criticized for being a difficult system that is cantankerous and hard to secure. Some of the main reasons that a Unix system is typically insecure include: o It is nearly infinitely configurable. o Unix is very complex. o Vendors don't ship secure systems. o It requires signicant amounts of time, resources, and expertise to secure. o Once secure (if ever) it will become less secure as time goes on through usage and the continaul flow of new security problems being discovered in the world. Titan can help with all of these problems; its main design goals are: o after being run, the system should be more secure than when we started. Things may be broken, but it should be more secure! The truth is that most things you do to secure a system is probably not going to cause a problem. A vendor can't take that chance - but we can. In any case, we haven't run into anything that Titan has broken, but it certainly could happen. o Security comes first, right along with functionality. If Titan has been run at its highest level of security, there will be no significant security problems that I know of. The system will not be 100% secure - none are - but it will be pretty darn secure. o Producing a consistent and understandably secure system. o It can help create a programatically defined technical aspect of a system or site's security policy. Allow the user to have complete control over what is run in Titan - with full source code and a fair bit of flexibility, it is easy to remove unwanted security fixes. After all, not everyone wants or needs all the actions that Titan does. o Titan is easily extended. Shell scripts or other programs can be placed into Titan's framework, and they will be run alongside all the other programs. o To be a useful security tool in the overall security framework. Titan does not try to do important things, like fix bugs, check for poor passwords, install patches, or check for COPS/Tiger/SATAN-like problems. But there is much more to security than that! And it is not meant to be run once and forgotten, nor is it meant to be run on all systems. But any system administrators that are concerned about security should have considered, if not resolved or fixed, a significant number (if not all) of the problems that Titan covers on their security critical systems. History Anyone working in security or systems administration who has been been around the Internet for any length of time has done it - making the same changes, over and over again, to secure a system. Worse yet, each new OS release would bring tiny, seemingly completely arbitrary changes that would invalidate prior work. And forget it when a new major release came out, or you had to work with another operating system altogether! And between the three of us we've ftp'd Crack, COPS, and other security programs from the net many thousands of times. Eventually it became clear. I was not only making the same changes to the underlying OS over and over again to secure my system from attack (the many security exploits and investigations that are saved on my system make it a target), but also when building various firewall configurations (which is what I do for a living.) I started writing Titan almost in self defence - initially as a simple set of tools for my personal systems, but it also quickly proved a valuable sanity check for confirming consistency when building firewalls. Its next natural task was to use it when examining or auditing a system. Laziness is the best motivator there is - if I had to type those things one more time... Analyzing the security of a system is depressing - the same sets of problems always come up. Worse yet, these problems almost always can be easily fixed - so why aren't they? Worst of all, these problems keep coming up; if you don't find them the first time, wait a few months or a year, and they'll be there then. And it's not Sun - it's DEC, it's HP, it's IBM, it's everyone that has even a mildly complex system. Yes, even Microsoft. So why do these same problems show up over and over and by different suppliers? Good question. I don't know exactly, but I do know that having a tool that can help ensure that your systems are consistent in your organization is a positive step in the right direction. Having a system consistently adhering to the security policy is perhaps the most valuable thing you can do to keeping it secure. I'm often asked how to tighten down the OS when a firewall product gets installed. There is a reasonable expectation from the customer that after the firewall is installed that the system will not be compromised by an attack that is outside the scope of the firewall product. After all, aren't firewalls supposed to protect you? You wouldn't say it was alright to run my business on the Internet unless you could protect me, would you? And it's true - it really is unreasonable to expect the user, a customer, to understand all, or even most (any? ;-)), of the security issues of running a system on the Internet. Why should they? However, this does place both the firewall vendor and security people in general in a rather awkward situation. Indeed, this probably scares firewall vendors more than anything else - the fact that their firewalls are falling because some user or administrator doesn't fix or upgrade an old version of a potentially vulnerable network service? What titan is not Titan isn't a replacement for anything (period; end of discussion) Titan doesn't mean you no longer need to install vendors security patches (although it might save you in some cases if you didn't install a patch) Titan doesn't mean that you shouldn't install SKIP, ssh, smap, smrsh, tripwire, Tcp_wrappers, rpcbind, noshell, COPS, SATAN, TIGER, crack, or any of the other security tools you are (or should be) currently using but it should make the results of running COPS look shorter. Titan works at the lower OS level to fix common configuration errors. Things like the user ``lp'' account having a valid shell and some administrator exporting /var/spool read-write via NFS so users can share an e-mail server. If you can't guess, "/var/spool" is a home directory, and if user ``lp'' has a valid shell, a remote user can add in a rhosts entry to /var/spool and login as user ``lp''; oh and guess what? In some OS's the user ``lp'' is in a privileged group (/etc is mode 775 in solaris for instance) or owns a directory where root runs commands out of. Why the name titan? I could go off and give the ``its an acronym'' speech about it standing for ``Toolkit for Interactively Toughening Advanced Networks and Systems'' but to tell the truth, I just kept getting requests from my fellow workers at the time (hi Pete, hi Alan) for ``those scripts to tighten down the OS''. The name just sort of stuck. Some philosophy behind titan Titan was designed using the KISS module. ``Keep It Simple Stupid'' At one time I built shell scripts that did all the fixes at one time. The trouble was that sometimes you wanted some things left alone so you ended up modifying the shell script (or C program) and commenting out some portions. Then when you went back to re-use the script the next time it was possible that the script would leave that commented item enabled when *this* time you wanted it disabled. Thus no consistency Or you have the script ask before doing every change. This can be a pain and time consuming if you need to do multiple systems and are on a time limit like most of us usually are. I abandoned these models in favor of short succinct set of scripts each of which did -one- and only one specific type of thing. Script names were picked that (mostly) made reference to what each module did. I have been hampered by porting to-from filesystems that restrict file name lengths at times (msdos for instance; ever try and copy files with names like disable_ip_forwarding.sh to a PC laptop and then back to a real system? arg!) Titan was designed so that anyone could build a titan module. See the FAQ Question number 4 on how to build a titan module and how a titan script is designed Descriptions as to what each script does: SunOS 4.1.X Solaris 2.X What You Still need to do: + Install VENDOR patches!!! Its actually better to install all known patches before running titan. See the fix-modes note above. + Use pkgrm to remove packages that can hinder security. This is pretty dependent on site policy. Some prime candidates might be any of the compiler stuff and the binary compatibility packages (assuming this is a firewall). This stops intruders who are lugging around old compiled binaries from running them on your firewall system. And since your not compiling software on your firewall itself (right?) you don't need to help the opposition compile newer breakin tools. + Run COPS and Tiger. We purposly didn't recreate many of the things that COPS or Tiger checks. Thats not Titans niche + Install any/all the SKIP, ssh, smap, smrsh, tripwire, tcp_wrappers, rpcbind, and noshell stuff as usual Planned Titan Version 4 build: + libc replacement for solaris 2.3, 2.4, 2.5 so rusersok is disabled (.rhosts) It is an Optional configuration in solaris 2.6! yay! Of course ssh or SKIP is still preferred since encryption blocks password snooping + Porting to other Unicies. + Porting to Non-Unix platforms. + Checks for unrestricted NFS and NT shares. Titan Frequently Asked Questions * Download Team Titan PGP key titan.pubkey.pgp[New!] * Download cleartext MD5 Checksum Now Titan,v3.0.FCS.tar.gz-checksum * Download PGP signed MD5 Checksum Now Titan,v3.0.FCS.tar.gz-checksum.asc * By clicking here, I agree to the licensing restrictions, I agree to use Titan at my own risk, and am ready to Download Titan Now ---------------------------------------------------------------------- Last Modified: 0:00 PDT, December 9, 1998