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 conscious 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 access to hardware/software resource, Titan 3.8 will only run on Solaris, versions 1.1.4 , 2.X, Solaris 8,.
Titan version 4.0 Alpha works with Solaris, Linux, and Free BSD. These are minimalistic modules for Linus and Free BSD.
Other than taking the time to create Titan modules for other systems, there is nothing Sun specific (except for some few modules that are Solaris feature specific )about Titan that would prevent it working on other Unix systems.
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:
that Titan covers on their security critical systems. Titan helps by being systematic about things. No longer do you need to wonder if you finished applying all your changes. Just run Titan -v and it will spit out all the things Titan thinks need hardening.
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 was making the same changes over and over again. I started writing Titan almost in self defense - 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 motivation there is - if I had to type those same commands manually 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 NEC, it's HP, it's IBM, yes, Linux too! 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 okay 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? Security isn't the goal of a business, making money is. 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 failing because some user or administrator doesn't fix or upgrade an old version of a potentially vulnerable network service! I can no longer count the number of times I've heard "I didn't know leaving sendmail running on my firewall might make it vulnerable."
Titan tries to along with using some common sense on your part, and doing a minimum OS install, to build you a consistent, reproducible base install. Making the system suitable to then install a firewall or other product and knowing that the underlying foundation isn't all sand.
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.
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 I forgot 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. Or want to run things from a crontab.
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!) Thus the names are kept reasonably short at the expence of loosing a decriptive name.
See the FAQ Question number 4 on how to build a titan module and how a titan script is designed
