                                   

TITAN 3.0 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.

                    :
                    #
                    umask 022
                    # This tool suite was written by and is copyright by
                    Brad Powell Dan Farmer, and
                    # Matt Archibald 1992, 1993, 1994, 1995, 1996, 1997,
                    1998 with input
                    # from Casper Dik, and Alec Muffett.
                    # The copyright holder disclaims all responsibility or
                    liability with
                    # respect to its usage or its effect upon hardware or
                    computer
                    # systems, and maintains copyright as set out in the
                    "LICENSE"
                    # document which accompanies distribution.

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)



                    MYNAME=`basename $0`
                    # did things work out or not?
                    action=`./sanity_check $MYNAME $1`
                    if test $? -ne root; then
                    exit 1
                    fi

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.



                    Intro() {
                    cat << EOF_INTRO
                    Add in the information on what the script does here
                    EOF_INTRO
                    }

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.

                    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 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.

                    Fix() {
                    if [ -f /etc/init.d/init.dmi ]; then
                    echo " Saving /etc/init.d/init.dmi to
                    /etc/init.d-init.dmi.ORIG"
                    /bin/mv /etc/init.d/init.dmi
                    /etc/init.d-init.dmi.ORIG.$$
                    /bin/mv /etc/rc2.d/K77dmi /etc/rc2.d-K77dmi.ORIG.$$
                    /bin/mv /etc/rc3.d/S77dmi /etc/rc3.d/S77dmi.ORIG.$$
                    chmod 0100 /etc/init.d-init.dmi.ORIG.$$
                    chmod 0100 /etc/rc2.d-K77dmi.ORIG.$$
                    chmod 0100 /etc/rc3.d/S77dmi.ORIG.$$
                    if [ $? -ne 0 ]; then
                    echo " ERROR: Could not rename /etc/rc3.d/S77dmi ;
                    exiting"
                    exit 1
                    else
                    echo "Done ... "
                    fi
                    fi
                    }

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.

                    action=$1
                    case $action in
                     -[Ff]*)
                    Fix
                    ;;
                     -[Vv]*)
                    Check
                    ;;
                     -[Ii]*)
                    Intro
                    ;;

                    *)
                            echo "        ERROR: Invalid arg $action"
                            echo "        ERROR: Usage $MYNAME -[ivf]
                    (I)ntro/(V)erify/(F)ix"

                            echo " "

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.

                    MYNAME=`basename $0`
                    # did things work out or not?
                    action=`./sanity_check $MYNAME $1`
                    if test $? -ne root ; then
                    exit 1
                    fi

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

