TITAN 4.0 FAQ

Check out the What is New in 4.0 sections for changes/additions in this release

        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 you're 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 you're 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 you are 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 you are not using a 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 you are 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 you're 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 you're 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 NT$ 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.
  • All or at least most all of the /etc/rc*.d directories and the start up scripts that are in each of them.
    • 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: 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 mot unicies is the bourn shell "sh". In Linux its bash, but since bash has all the standard bourne shell syntax (and more) things just work.
    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)

    Next add in a SAVEFILE definition. This is important so that on every new system installed with Titan, the backtit.sh module will be able to save off a copy of the origional file. A SAVEFILE lines commonly looks like this:

                                                       SAVEFILE='etc/foo /etc/bar /usr/bin/function'

    All files that are to be backed are listed here with a comma separating each file name.

    Notice the .misc_functions.sh. This is a simple library-like include. It sets up the verbosity for the "t_echo" functions you see in all titan modules. We use t_echo instead of "echo" so that the user of Titan can control just how chatty titan output is.

     

     

    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.

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

    Answer:

             http://www.fish.com/titan/index.html

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

    Answer:

     

    Send Mail to titan@fish.com

    8) Question: When I run rhosts.sh Titan goes off and reports huge amounts of rhosts users. What is going on?

    Answer:

    Titan is dutifully reporting the fact that automounter is running and most likely NIS. Thus all these users not only have access to your current system, but if any one of their accounts is compromised, and a "+ +" rhosts entered into their account then your system is now compromised. We don't line automounter for this reason. If you don't want Titan finding these, then either turn off automounter (permanently) using automounter.sh and or use the nsswitch.sh module to turn off NIS.

     

    9) What is noshell.c?

    Answer:

    Noshell.c is the proper way for Titan to be able to disable users (or non-users) login shell. The module disable-accounts.sh places a simple shell script into /sbin/noshell and sets the login shell of non-users

    such as "bin" and "sys" to /sbin/noshell. This should only be temporary until you can compile and install the

    Titan/src1/noshell.c program. Both the shell script as well as the noshell binary do roughly the same thing, but building a statically linked binary to disable the users shell is much safer that using a bourne shell script for this purpose.

     

    10) Question: What IS runas.c?

    Answer:

    Runas.c is a small C program that allows administrators a generic way to run daemons as non privileged users.

    Runas.c is the moral equivalent of doing a "su - daemon -c /usr/bin/blah" The difference is that runas first strips off the environment and also doesn't require that the users shell in /etc/password be a valid/real shell. If for example you already ran disable-accounts.sh on your system, then the user's shell for user "daemon" would be /sbin/noshell which isn't a shell at all but a warning device that someone is trying to break in using a system account. Runas in this regard is cleaner than using "su -c"

    So why do a su -c or runas in the first place? Well many daemons get started up in system run files such as

    /etc/rc2.d/S*. These daemons are started as root and as such hold root privileged. If there is a bug in the daemon code and a remote user can connect to the daemon they can potentially run programs as root. Runas allows you to start system daemons or (any non-standard daemons) after setting the user ID the daemon should run at.

    Assumptions:

    NOTE- For things that don't need to read system utilities, it is better to run the daemon in a chrooted environment as well as under a non privledged user ID. Look for Wietse Venema's  chrootuid.c as a better approach for things like httpd.

     

    11) How do I use runas?

    Answer:

    After first compiling the source in Titan,v3.6/src1 (we always ship using source code so you can review it) you would check if the daemon can run as a non-root process (see assumptions above) then you would modify the start-up line to call runas before the daemon is called.

    Example:

        /etc/rc2.d/S73nfs.client

                             ORIGINAL LINE:

                                           /usr/lib/nfs/lockd > /dev/console 2>&1

                              NEW LINE using runas:

                                            /sbin/runas 60001 60001 /usr/lib/nfs/lockd > /dev/console 2>&1

                                                        ^^^^^ ^^^^^

                                                         UID and GID of user "nobody"

    This example would run the NFS lockd as user nobody (example only)

     

     

    12) After running Titan I can't login

    Answer:

    Its possible that in the event you didn't have a root password set (blank root password) before running Titan, that the disable-accounts.sh will have done its job (correctly) and disabled all accounts that don't have a password including root! To eliminate this issue make sure you have a root password set before running titan.

    Back to Titan Main Documentation Page
    Last Modified Mon July 1 14:28:21 PST 2002