TITAN 3.0 FCS FAQ

        1) Question: Titan isn't as chatty as it used to be. How do I get the verbose output back?

Answer: Why would you want to? :-)

Actually, Titan and all of its modules were changed to allow you to pick how much chattiness is appropriate for your environment /mood. I say mood, because you may want Titan to be chatty when you first learn Titan conventions, or you may want as much verbosity as possible when running in verify (-v) audit mode, but there are other times when you will want Titan to  just shut up and do its thing. The verbosity of output has been made configurable for just these reasons. To change the level of how much verbosity output you want, modify:

$TITANDIR/lib/misc_functions.sh (TITANDIR/lib is a symlink). Change "print_level=1" and "echo_out=t_echo.res"

#
# File name that t_echo prints to if it doesn't go to the screen
#
#echo_out="/dev/null"
echo_out="t_echo.res"
#
# t_echo (output_level, output)
#
# Where output_level is one of these:
#
#       0 = Actions done or problems found, not even error messages
#       1 = Error messages
#       2 = Pass/fail informational, chatty stuff
#       3 = debug
#
 

    2) Question: Titan has a whole lot of modules that it disables that I need left alone. How do I get Titan to only fix specific things?

Answer: Be careful. We wrote each modules for a reason. If your either sure you need the service, or you are willing to risk leaving it enabled, then read on. We agree that different systems have different security needs. A user desktop sitting behind a firewall and assuming (ass-u-me) the other security layers are in place, and working, doesn't need all of the Titan modules run on it. We prefer (from the security standpoint) to break things, and then have you turn on only the services that you can't live without. Don't despair, we have made it easy for you to accomplish this, but we would be remiss if we didn't warn you first. If you know what your doing, and have a good understanding of why Titan disables the things it does, then (and only then) you are ready for building configuration files for the different system types under your control. We honestly believe that after a short time playing with Titan, you will be using the "-c" feature as your default, and get the most satisfaction out of running Titan this way. But let me stress again YOU ARE WATERING DOWN YOUR SECURITY. Okay now lets look at a sample configuration file, and how Titan runs it. This is a real simple sample. We call this file "simple-sample"


------------------cut---here----------------------------------------------------
# Short sample configuration file
# Titan is smart enough to not run lines starting with a "#" so put in comments
# to remind yourself why you changed things

# You can mix and match "-f", "-v", (or -i for that matter, not that -i makes sense
# here)

# Titan expects that each line has two arguments; the module to run AND the run
# flag

# run the following line in "-v" verify mode. Titan only verifies the fix is in
# place. no change is made to the system. See system audit Q&A below!

add-umask.sh -v

# go ahead and change the file ownership's using the "-f" (fix) flag
file-own.sh -f

# run these module as well in fix mode
utmp.sh -f
vold.sh -f
my-new-module.sh -f
------------------end sample configuration--------------------------------------
 

3) Question: Wait. Titan as a system audit tool? Tell me more!

Answer:  YOU BET! The third biggest uses for Titan (the first being to FIX security problems; the second is Titan's use as a security learning tool) and the use security consultants and auditors will like best about Titan is its ability to be run on a Unix system and report things that may be security issues. A checklist that runs all the checks and produces a simple report. There are three  ways of accomplishing this. The first way is to look at "TitanReport," and run it. TitanReport is designed to run (out of cron) all Titan modules "-verify" and send the results via e-mail. For all three of these; make sure you pre-set print_level=3. See Question 1 above. The second way is to run Titan -v, and gathering up the $TITANDIR/logs/* files and

the "t_echo.res" files. The third way is to build a configuration file (audit.config) that lists out all the Titan modules you want to run "-verify" and running "Titan -c audit.config". In this way you can use Titan to audit firewalls, servers, and desktops using a separate configuration that matches your security policy (you do have a security policy don't you?)

We encourage you to use the Titan framework, and write your own modules. If you do, please donate them to Titan. We will take all modules and incorporate them into the next release of Titan.



4) Question: Which Modules should I use for a Server, a Firewall, A desktop?

Answer: That depends. Take a look at Server.config, Firewall.config, and Desktop.config

Here are my recommendations broken down by OS.

SunOS 4.1.X

Firewall -
All titan modules should be run and then some! I'd walk through /etc/rc.local and /etc/rc and disable everything that you didn't want to run at start-up time. Also consider running ASET in the tune-high mode. Additionally look in the optional directory for the patch to turn off forwarding of source routed packets.
Server
Run all titan modules except possibly routed.sh if the system is a router.
Also run tftpServer.sh if the system is a diskless workstation server, or run tftp-disable.sh if the system does not boot diskless workstations. Check aliases.sh and decode.sh one may be more restrictive than your policy allows. Inetd.conf.sh might need to be modified. Also consider running ASET in the tune-med mode
Desktop
Run all titan scripts except tftpServer.sh. Inetd.conf.sh might need to be modified. Also consider running ASET in the tune-low mode

Solaris 2.X

Firewall -
All titan modules should be run and then some. You might want to turn off sendmail for instance completely, on the firewall and just pass mail to a protected mailserver. All other titan modules should be run with the following caveat. On a Proxy firewall such as TIS that doesn't have a Windowing System GUI (curses based GUI) All titan modules can be run and in fact I would also either do a fresh install of the OS and only install the "core" unix utilities or do a pkgrm of all the un-needed utilities. DO NOT RUN anon-ftp.sh unless the systems is supposed to be an anonymous ftp server.
So what are the "unneeded" utilities? I can't answer that without knowing what you are going to use the firewall for in more details. Here instead is a list of Solaris 2.X utilities that you should think about removing from a Proxy firewall.
Any of the Compiler utilities. You shouldn't be compiling on the firewall. You also don't want crackers (cracker = criminal hacker) being able to compile things on your firewall. (note you might make the compile utilities directory mode 700 owned by root; if you have to compile on the firewall)
All of the System administration applications as well as the System and network administration packages. These are made for remote administration. Why risk having someone else remotely administering your firewall?
All the Audio applications unless you have some sort of audio alert set up to detect intrusion attempts (doubtful)

All the SunOS Binary Compatibility packages. its amazing how many older breaking tools will no longer work if this package isn't available.

All the CC/GCC tools (used by the compiler) compile somewhere else or at least have a build directory that is mode 0700 owned by root. If intruder can compile on your system then, well, you have already lost.

Unless your using a GUI *on* the firewall system (such as running FW-1 GUI; fwui locally) then you can remove all of the GX cg6 device drivers.

Again if your not using any GUI, then remove all the CDE (common desktop environment)

windowing system stuff. Note; you can still re-display GUI application to a remote server without this being installed.

Remove all the DT (desktop login environment).

Remove all the HotJava browser portions

Remove all the UTF-8 unless your using a GUI *on* the Firewall system.

If you are not using the Federated naming System (man fns) then remove all the references to this such as SUNWfns

Remove all the SunOS header files support unless for some reason your using binaries compiled from a SunOS system. This also applies to the binary compatibility packages.

All the X11 fonts also go unless you run a windowing system locally

Any Java support unless you run java locally (a DMZ Web server might; but the Firewall shouldn't)

Remove all the KCMS support unless your using a GUI (even then consider it)

Any of the WorkShop support can be removed unless you run a Sun workshop application (such as the C compiler not recommended to be run on the firewall)

The FlexLM (License Manager) may need to be there so that licensed software packages can run (FW-1). However if you don't need it, this is one less daemon running and should be considered for removal. Proxy firewalls most often don't need the license manager daemon.

On a firewall system the LP services can often be removed unless you run a local printer to capture hard copy of log files. If you leave this installed, you should disable LP unless you actually run a (line) printer. Some sites leave this installed but disabled until it is needed e.g., until a break-in and a need for stringent logging.

All the Motif support can be removed unless the CDE window system is run.

The SNMP agents are most commonly removed or disabled on a firewall system. This is because they can give out information to intruders. Unless you are using SNMP to send alerts to an internal system, then remove the SNMP packages. If you do use SNMP alerts, make sure and block SNMP on the external router.

NIS can often (and should be) removed from the firewall system. Exceptions are older SunOS 4.1.X systems which needed NIS to run for DNS to work. If you don't need it; remove it.

The NTP support is the Network Time Protocol. If you use NTP to synchronize clocks, leave this in. Systems that might use this are Digital Token Databases that use time displays (Security Dynamics) or you may be using an atomic clock service to synchronize your Server or internal systems clocks. if you do use xntpd or NTP services you should most likely wrapper the service so that only specific trusted locations can modify your systems sense of reality. An interesting attack would be to reset the system clock back 20 minutes so that a time based token becomes valid again.

Open Windows and open look packages can be removed on Proxy Firewalls without a GUI, as well as Firewall Systems that don't manage the firewall via local GUI.

The Power management support can be removed on a firewall. I don't know of any firewalls that should shut themselves down after N minutes of idle time. However powerd can be used to shutdown systems on low power conditions. If you use UPS and don't use another software package supplied by the UPS vendor, powerd might be useful to have. If you do leave this running make sure and wrapper the service.

The Solstice Enterprise agent can probably be removed as well.

Sparc Compilers binary compatibility can be removed unless you are cross compiling SunOS binaries on your firewall (not recommended)

The Solaris Naming Enabler I can't find what it does.

Spell Checking Engine can probably be removed from most firewalls

SUNWsregu can be removed

SUNWsrh can be removed

All the ToolTalk utilities can be removed

All the vold utilities can be removed unless you are lazy about mounting floppies or CD's.

All the XGL, XIL, and X window system can be removed unless you run a local GUI.

Server
All titan modules should be run except the following.
anon-ftp.setup.sh should only be run on a system that you want people to anonymously ftp to (limited number of systems).
lpsched.sh should be left on if the system is a print server or if persons login and print from the system.
nsswitch.sh may need to be modified for Servers if NIS or DNS is being used.
disable_ip_holes may need to be modified if the Server is a router. You will probably want to allow the ip_forwarding in this case.

The snpmdx and dmi titan modules would not be run if the system was being remotely monitored/managed via SNMP.

inetd.sh may need to be modified if other services that run out of inetd.conf are required on the server.

routed.sh would not be run on a Server system that was acting as a router.

vold.sh would not be run on a system where users were allowed to mount software from floppy or CD media. Caution should be taken that they can't mount a suid root copy of ksh and thus bypass security. That is why you might want to disable vold.

ziplock.sh should probably NOT be run on any system that isn't a firewall system. And then only on a proxy or tightly controlled system.

Desktop
All titan modules can be run except the following.
anon-ftp.setup.sh should not be run.
automount.sh may be left on if the Automounter of file systems is permitted
inetd.sh may need to be modified if things like calendar manager is run on the desktop
lpsched.sh might be left on so users can print.
nsswitch.sh may need to be modified if DNS and NIS is used.

vold.sh should not be run if users are allowed to mount floppies or CD's locally

ziplock.sh should NOT be run on desktops.

Note- depending on the windowing system used you may need to leave on some RPC services
 
 
 

5) Question: Why the SCCS directories?

Answer: The intent is so that if changes are made to titan modules we have a record of who did what and when. SCCS was used instead of other source control modules because most all unicies have SCCS. e.g., its the lowest common denominator.

6 )Question: How do I build my own titan module?

Answer: Start out with the arch/sol2sun4/src/stubs/skeleton script. It was put there for just that reason. Lets examine it in detail.

The first line ":" this character is similar to using "#!/bin/sh" the difference is that it is possible that "sh" doesn't live in "/bin" thus if we use ":" we tell the system to use the kernel default shell which for unix is the bourn shell "sh"
The second line sets the umask value so that any files created by the script have a sane default file mask.
The next few lines are Copyright and License notices and required for legal purposes.
Next we have a setup section and the sanity check section. We use "MYNAME" so that error messages will echo the name of the script that the error occurred from. The sanity check calls the sub-script "sanity_check" which checks for execution by "root" as well as checks that the user passed the required number of arguments (-Verify, -Intro, -Fix)
The next part of a titan module is the Introduction section Intro(). We use a simple trick so that any text you place between the "EOF_INTRO" keywords gets echoed to the screen when the user starts a titan script with the "-i", "-I" or "-Introduction" flag. e.g., if a user runs "add_umask.sh -i" all the lines in the add_umask.sh script between the "EOF_INTRO" words are displayed to his/her terminal using the cat command.

 
The next section of a titan script is the Check() function. This is the pert of the script that is used when a titan script is run in the "-v" verify mode. Look through a few of the titan scripts to see some of the ways the Check() function checks out the system. The only standard thing that titan does in a Check() function is to produce a "PASSES CHECK" or a "FAILS CHECK" so users can figure out if this titan fix is needed or already applied to the system. Notice that all three sections Intro(), Check(), and Fix() are bound by brackets "{and}" at the beginning and end of the function. Example Check function using a simple if, then, else, fi sequence.
The next portion of a titan script is the Fix() function. This is where we actually change or modify system files. This function is only invoked when the user specifically runs a titan script with the "-f", "-F", "-fix" flag. The structure is similar to the Intro() and Check() structure but commonly has more lines since files are modified. Example Fix() function which moves and renames start-up files so that on system boot these scripts are no longer run by the system; thus disabling that function. Again we use a simple if, then, else, fi sequence.
The last section of a titan script is the action section. This is pretty generic for all scripts. We basically check to see which flag the user specified and then run that function. e.g. if the user typed "foo.sh -f" then we run the Fix() function. If the users types anything that isn't a n "-i, -v, -f" (capital or lower case) then we simply print out an error message with the usage lines and exit.
That is basically it.
There are a few other functions you should be aware of.

The "Titan-Config" (Titan-Config -i" (install) script figures out your OS type and makes links to the proper Titan modules. Titan-Config also asks if you want to create a backup of all the files Titan modifies. This is needed in the event you want to recover from titan being too aggressive about security and breaking some of your functionality. The untit.sh utility is called when "Titan-Config -d" (de-install) is used. Untit.sh removes all changes Titan performed (assuming you made a backup when you ran "Titan-Config -i"
 

The Titan script runs *all* commands in the $TITANDIR/bin/modules directory that are
a) a file, and b) are executable. Thus you can move all the scripts that you don't want run to another location or simply change the mode of the file, and Titan will not run them.
Example: By just creating a new script called "runme.sh" which accepts the standard titan arguments (-i, -v or -f) and putting it into the $TITANDIR/bin/modules directory, and calling "Titan -F" would cause all the scripts that are in the $TITANDIR/bin/modules  directory to be run  with the "-f" flag including your new module.
Example2: Removing all the scripts except script a.sh, b.sh, c.sh and running "Titan -v" would cause titan to only run a.sh, b.sh, and c.sh with the "-v "flag. No other script would be run. An easier way would be to build a configuration file and list the modules you want run including the run flag, and running "Titan -c config.file"

misc_functions.sh is there so that you can use the t_echo (t_echo [0,1,2,3]) function to set the level of verbosity on the output of your script.
 

sanity_check script is there so that you don't have to build that functionality into your script, all you need do is supply the MYNAME, and call sanity_check from your new titan script.
Lastly the is_root sub-function is called by the sanity_check script to check and report if the caller is running as root.

7) Question: Where do I get the latest version of titan?

Answer: http://trouble.org/titan/index.html

8) Question: If I write a titan module and want to share it, how do I get it into the next release?

Answer: Send a message to titan@trouble.org

Back to Titan Main Documentation Page
Last Modified: 0:00 PDT, October 31, 1998