exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

FAQ.html

FAQ.html
Posted Aug 17, 1999

FAQ about Titan.

tags | tool, scanner
systems | unix
SHA-256 | d0a0d1aad6c5b079f2849be565b957cb9d6090dccaecce13909225a0149cc5b2

FAQ.html

Change Mirror Download
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.07 [en] (X11; U; SunOS 5.5.1 i86pc) [Netscape]">
<TITLE> TITAN 3.0 FCS FAQ</TITLE>
</HEAD>
<BODY>

<DIV CLASS="Body">
<CENTER><IMG SRC="atlas-small.jpg" HEIGHT=458 WIDTH=381></CENTER>
</DIV>

<DIV CLASS="Body"><A NAME="pgfId=424068"></A></DIV>

<H1 CLASS="Heading1">
<A NAME="pgfId=424069"></A>TITAN 3.0 FCS FAQ</H1>

<H3>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <TT>1) Question: Titan isn't
as chatty as it used to be. How do I get the verbose output back?</TT></H3>

<H3>
<TT>Answer: Why would you want to? :-)</TT></H3>

<H3>
<TT>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&nbsp; 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:</TT></H3>

<H3>
<TT>$TITANDIR/lib/misc_functions.sh (TITANDIR/lib is a symlink). Change
"print_level=1" and "echo_out=t_echo.res"</TT></H3>
<TT>#</TT>
<BR><TT># File name that t_echo prints to if it doesn't go to the screen</TT>
<BR><TT>#</TT>
<BR><TT>#echo_out="/dev/null"</TT>
<BR><TT>echo_out="t_echo.res"</TT>
<BR><TT>#</TT>
<BR><TT># t_echo (output_level, output)</TT>
<BR><TT>#</TT>
<BR><TT># Where output_level is one of these:</TT>
<BR><TT>#</TT>
<BR><TT>#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 = Actions done or problems
found, not even error messages</TT>
<BR><TT>#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 = Error messages</TT>
<BR><TT>#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 = Pass/fail informational,
chatty stuff</TT>
<BR><TT>#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 = debug</TT>
<BR><TT>#</TT>
<BR>&nbsp;
<H3>
&nbsp;&nbsp;&nbsp; <TT>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?</TT></H3>

<H3>
<TT>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"</TT></H3>

<P><BR><TT>------------------cut---here----------------------------------------------------</TT>
<BR><TT># Short sample configuration file</TT>
<BR><TT># Titan is smart enough to not run lines starting with a "#" so
put in comments</TT>
<BR><TT># to remind yourself why you changed things</TT>
<P><TT># You can mix and match "-f", "-v", (or -i for that matter, not
that -i makes sense</TT>
<BR><TT># here)</TT>
<P><TT># Titan expects that each line has two arguments; the module to
run AND the run</TT>
<BR><TT># flag</TT>
<P><TT># run the following line in "-v" verify mode. Titan only verifies
the fix is in</TT>
<BR><TT># place. no change is made to the system. See system audit Q&A
below!</TT>
<P><TT>add-umask.sh -v</TT>
<P><TT># go ahead and change the file ownership's using the "-f" (fix)
flag</TT>
<BR><TT>file-own.sh -f</TT>
<P><TT># run these module as well in fix mode</TT>
<BR><TT>utmp.sh -f</TT>
<BR><TT>vold.sh -f</TT>
<BR><TT>my-new-module.sh -f</TT>
<BR><TT>------------------end sample configuration--------------------------------------</TT>
<BR>&nbsp;
<H3>
<TT>3) Question: Wait. Titan as a system audit tool? Tell me more!</TT></H3>

<H3>
<TT>Answer:&nbsp; 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&nbsp; 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</TT></H3>

<H3>
<TT>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?)</TT></H3>

<H3>
<TT>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.</TT></H3>

<H3 CLASS="MarginNote">
<P>

<BR><TT></TT>
<BR><TT></TT>


</P>
<A NAME="pgfId=424267"></A><TT>4) Question: Which Modules should I use
for a Server, a Firewall, A desktop?</TT></H3>

<H3 CLASS="MarginNote">
<A NAME="pgfId=426777"></A><TT>Answer: That depends. Take a look at Server.config,
Firewall.config, and Desktop.config</TT></H3>

<H3 CLASS="MarginNote">
<A NAME="pgfId=426779"></A><TT>Here are my recommendations broken down
by OS.</TT></H3>

<H3 CLASS="Heading1">
<A NAME="pgfId=426772"></A><U>SunOS 4.1.X</U></H3>

<H6 CLASS="Heading2">
<A NAME="pgfId=426781"></A>Firewall -</H6>

<DIV CLASS="Paragraph"><A NAME="pgfId=426927"></A><TT>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.</TT></DIV>

<DIV CLASS="Body"><A NAME="pgfId=426782"></A></DIV>

<H6 CLASS="Heading2">
<A NAME="pgfId=426783"></A>Server</H6>

<DIV CLASS="Paragraph"><A NAME="pgfId=427256"></A><TT>Run all titan modules
except possibly routed.sh if the system is a router.</TT></DIV>

<DIV CLASS="Paragraph"><TT>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</TT></DIV>

<DIV CLASS="Body"><A NAME="pgfId=426784"></A></DIV>

<H6 CLASS="Heading2">
<A NAME="pgfId=426785"></A>Desktop</H6>

<DIV CLASS="Paragraph"><A NAME="pgfId=427275"></A><TT>Run all titan scripts
except tftpServer.sh. Inetd.conf.sh might need to be modified. Also consider
running ASET in the tune-low mode</TT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=427269"></A></DIV>

<H3 CLASS="Heading1">
<A NAME="pgfId=426773"></A><U>Solaris 2.X</U></H3>

<DIV CLASS="MarginNote"><A NAME="pgfId=426769"></A></DIV>

<H6 CLASS="Heading2">
<A NAME="pgfId=426792"></A>Firewall -</H6>

<DIV CLASS="Paragraph"><A NAME="pgfId=426918"></A><TT>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.</TT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426917"></A><FONT FACE="Courier New,Courier">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.</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426797"></A></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426798"></A><FONT FACE="Courier New,Courier">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)</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426799"></A></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426800"></A><FONT FACE="Courier New,Courier">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?</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426801"></A><FONT FACE="Courier New,Courier">All
the Audio applications unless you have some sort of audio alert set up
to detect intrusion attempts (doubtful)</FONT></DIV>


<P CLASS="Paragraph"><A NAME="pgfId=426802"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426803"></A><FONT FACE="Courier New,Courier">All
the SunOS Binary Compatibility packages. its amazing how many older breaking
tools will no longer work if this package isn't available.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426804"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426805"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426806"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426807"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426808"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426809"></A><FONT FACE="Courier New,Courier">Again
if your not using any GUI, then remove all the CDE (common desktop environment)</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426810"></A><FONT FACE="Courier New,Courier">windowing
system stuff. Note; you can still re-display GUI application to a remote
server without this being installed.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426811"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426787"></A><FONT FACE="Courier New,Courier">Remove
all the DT (desktop login environment).</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426816"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426817"></A><FONT FACE="Courier New,Courier">Remove
all the HotJava browser portions</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426822"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426821"></A><FONT FACE="Courier New,Courier">Remove
all the UTF-8 unless your using a GUI *on* the Firewall system.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426823"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426824"></A><FONT FACE="Courier New,Courier">If
you are not using the Federated naming System (man fns) then remove all
the references to this such as SUNWfns</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426825"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426826"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426818"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426838"></A><FONT FACE="Courier New,Courier">All
the X11 fonts also go unless you run a windowing system locally</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426839"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426840"></A><FONT FACE="Courier New,Courier">Any
Java support unless you run java locally (a DMZ Web server might; but the
Firewall shouldn't)</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426841"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426842"></A><FONT FACE="Courier New,Courier">Remove
all the KCMS support unless your using a GUI (even then consider it)</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426846"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426847"></A><FONT FACE="Courier New,Courier">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)</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426848"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426820"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426852"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426853"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426854"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426855"></A><FONT FACE="Courier New,Courier">All
the Motif support can be removed unless the CDE window system is run.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426856"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426857"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426858"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426860"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426861"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426862"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426863"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426864"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426865"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426866"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426868"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426869"></A><FONT FACE="Courier New,Courier">The
Solstice Enterprise agent can probably be removed as well.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426870"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426875"></A><FONT FACE="Courier New,Courier">Sparc
Compilers binary compatibility can be removed unless you are cross compiling
SunOS binaries on your firewall (not recommended)</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426876"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426877"></A><FONT FACE="Courier New,Courier">The
Solaris Naming Enabler I can't find what it does.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426878"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426879"></A><FONT FACE="Courier New,Courier">Spell
Checking Engine can probably be removed from most firewalls</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426880"></A>

<P CLASS="Paragraph"><A NAME="pgfId=426881"></A><FONT FACE="Courier New,Courier">SUNWsregu
can be removed</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426886"></A><FONT FACE="Courier New,Courier">SUNWsrh
can be removed</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426891"></A><FONT FACE="Courier New,Courier">All
the ToolTalk utilities can be removed</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426892"></A><FONT FACE="Courier New,Courier">All
the vold utilities can be removed unless you are lazy about mounting floppies
or CD's.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426893"></A><FONT FACE="Courier New,Courier">All
the XGL, XIL, and X window system can be removed unless you run a local
GUI.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426849"></A>
<H6 CLASS="Heading2">
<A NAME="pgfId=426788"></A>Server</H6>

<DIV CLASS="Body"><A NAME="pgfId=426934"></A></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426935"></A><TT>All titan modules
should be run except the following.</TT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426941"></A></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426942"></A><TT>a</TT><FONT FACE="Courier New,Courier">non-ftp.setup.sh
should only be run on a system that you want people to anonymously ftp
to (limited number of systems).</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426944"></A><FONT FACE="Courier New,Courier">lpsched.sh
should be left on if the system is a print server or if persons login and
print from the system.</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426945"></A><FONT FACE="Courier New,Courier">nsswitch.sh
may need to be modified for Servers if NIS or DNS is being used.</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426946"></A><FONT FACE="Courier New,Courier">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.</FONT></DIV>


<P CLASS="Paragraph"><A NAME="pgfId=426940"></A><FONT FACE="Courier New,Courier">The
snpmdx and dmi titan modules would not be run if the system was being remotely
monitored/managed via SNMP.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426790"></A><FONT FACE="Courier New,Courier">inetd.sh
may need to be modified if other services that run out of inetd.conf are
required on the server.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426947"></A><FONT FACE="Courier New,Courier">routed.sh
would not be run on a Server system that was acting as a router.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426948"></A><FONT FACE="Courier New,Courier">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.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426956"></A><FONT FACE="Courier New,Courier">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.</FONT>
<H6 CLASS="Heading2">
<A NAME="pgfId=426789"></A><TT>Desktop</TT></H6>

<DIV CLASS="Body"><A NAME="pgfId=426957"></A></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426958"></A><FONT FACE="Courier New,Courier">All
titan modules can be run except the following.</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426960"></A><FONT FACE="Courier New,Courier">anon-ftp.setup.sh
should not be run.</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426961"></A><FONT FACE="Courier New,Courier">automount.sh
may be left on if the Automounter of file systems is permitted</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426770"></A><FONT FACE="Courier New,Courier">inetd.sh
may need to be modified if things like calendar manager is run on the desktop</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426973"></A><FONT FACE="Courier New,Courier">lpsched.sh
might be left on so users can print.</FONT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=426974"></A><FONT FACE="Courier New,Courier">nsswitch.sh
may need to be modified if DNS and NIS is used.</FONT></DIV>


<P CLASS="Paragraph"><A NAME="pgfId=426980"></A><FONT FACE="Courier New,Courier">vold.sh
should not be run if users are allowed to mount floppies or CD's locally</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426981"></A><FONT FACE="Courier New,Courier">ziplock.sh
should NOT be run on desktops.</FONT>

<P CLASS="Paragraph"><A NAME="pgfId=426986"></A>Note- depending on the
windowing system used you may need to leave on some RPC services
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;
<H3 CLASS="MarginNote">
<A NAME="pgfId=426758"></A>5) Question: Why the SCCS directories?</H3>

<H3 CLASS="MarginNote">
<A NAME="pgfId=426999"></A>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.</H3>

<H3 CLASS="MarginNote">
<A NAME="pgfId=426764"></A>6 )Question: How do I build my own titan module?</H3>

<H3 CLASS="MarginNote">
<A NAME="pgfId=427006"></A>Answer: Start out with the arch/sol2sun4/src/stubs/skeleton
script. It was put there for just that reason. Lets examine it in detail.</H3>

<DIV CLASS="MarginNote"><TT>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"</TT></DIV>

<DIV CLASS="MarginNote"><TT>The second line sets the umask value so that
any files created by the script have a sane default file mask.</TT></DIV>

<DIV CLASS="MarginNote"><TT>The next few lines are Copyright and License
notices and required for legal purposes.</TT></DIV>

<DIV CLASS="Paragraph"><A NAME="pgfId=427026"></A></DIV>

<UL>
<UL>
<DIV CLASS="Paragraph1">
<UL>
<UL><FONT COLOR="#3366FF">:</FONT></UL>
</UL>
</DIV>

<UL>
<UL>
<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF">#</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF">umask 022</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># This tool suite was written
by and is copyright by Brad Powell Dan Farmer, and</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># Matt Archibald 1992, 1993,
1994, 1995, 1996, 1997, 1998 with input</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># from Casper Dik, and Alec
Muffett.</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># The copyright holder disclaims
all responsibility or liability with</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># respect to its usage or
its effect upon hardware or computer</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># systems, and maintains
copyright as set out in the "LICENSE"</FONT></DIV>

<DIV CLASS="Paragraph1"><FONT COLOR="#3366FF"># document which accompanies
distribution.</FONT></DIV>
</UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><A NAME="pgfId=427009"></A></DIV>

<DIV CLASS="MarginNote"><TT>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)</TT></DIV>

<H6 CLASS="MarginNote">
<A NAME="pgfId=427038"></A></H6>

<UL>&nbsp;</UL>

<UL>
<UL>
<UL>
<DIV CLASS="Paragraph1">
<UL><TT><FONT COLOR="#3366FF">MYNAME=`basename $0`</FONT></TT></UL>
</DIV>

<UL>
<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF"># did things work out
or not?</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">action=`./sanity_check
$MYNAME $1`</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">if test $? -ne root;
then</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">exit 1</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">fi</FONT></TT></DIV>
</UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><A NAME="pgfId=427039"></A></DIV>

<DIV CLASS="MarginNote"><TT>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.</TT></DIV>

<BR>&nbsp;
<UL>
<UL>
<UL>
<UL>
<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">Intro() {</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">cat << EOF_INTRO</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">Add in the information
on what the script does here</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">EOF_INTRO</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">}</FONT></TT></DIV>
</UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><TT>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.</TT></DIV>

<UL>
<DIV CLASS="MarginNote"><A NAME="pgfId=427064"></A></DIV>
</UL>

<UL>
<UL>
<UL>
<UL>
<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">Check() {</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">if [ -f /etc/init.d/init.dmi
]; then</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">echo " dmi daemon is
enabled: FAILS CHECK"</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">exit 1</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">else</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">echo " dmi doesn't start
at boot time: PASSES CHECK"</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">fi</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">}</FONT></TT></DIV>
</UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><TT>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.</TT></DIV>

<DIV CLASS="Paragraph1"><A NAME="pgfId=427109"></A></DIV>

<UL>
<UL>
<UL>
<UL>
<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">Fix() {</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">if [ -f /etc/init.d/init.dmi
]; then</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">echo " Saving /etc/init.d/init.dmi
to /etc/init.d-init.dmi.ORIG"</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">/bin/mv /etc/init.d/init.dmi
/etc/init.d-init.dmi.ORIG.$$</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">/bin/mv /etc/rc2.d/K77dmi
/etc/rc2.d-K77dmi.ORIG.$$</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">/bin/mv /etc/rc3.d/S77dmi
/etc/rc3.d/S77dmi.ORIG.$$</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">chmod 0100 /etc/init.d-init.dmi.ORIG.$$</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">chmod 0100 /etc/rc2.d-K77dmi.ORIG.$$</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">chmod 0100 /etc/rc3.d/S77dmi.ORIG.$$</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">if [ $? -ne 0 ]; then</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">echo " ERROR: Could not
rename /etc/rc3.d/S77dmi ; exiting"</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">exit 1</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">else</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">echo "Done ... "</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">fi</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">fi</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">}</FONT></TT></DIV>
</UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><TT>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.</TT></DIV>

<UL>
<UL>
<UL>
<UL><TT><FONT COLOR="#3366FF">action=$1</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">case $action in</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">&nbsp;-[Ff]*)</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">Fix</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">;;</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">&nbsp;-[Vv]*)</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">Check</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">;;</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">&nbsp;-[Ii]*)</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">Intro</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">;;</FONT></TT>
<P><TT><FONT COLOR="#3366FF">*)</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
echo "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ERROR: Invalid arg $action"</FONT></TT>
<BR><TT><FONT COLOR="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
echo "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ERROR: Usage $MYNAME -[ivf]
(I)ntro/(V)erify/(F)ix"</FONT></TT>
<P><TT><FONT COLOR="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
echo " "</FONT></TT></UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><TT>That is basically it.</TT></DIV>

<DIV CLASS="MarginNote"><TT>There are a few other functions you should
be aware of.</TT>
<P><TT>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"</TT>
<BR>&nbsp;</DIV>

<DIV CLASS="MarginNote"><TT>The Titan script runs *all* commands in the
$TITANDIR/bin/modules directory that are</TT>
<BR><TT>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.</TT></DIV>

<DIV CLASS="MarginNote"><TT>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&nbsp;
directory to be run&nbsp; with the "-f" flag including your new module.</TT></DIV>

<DIV CLASS="MarginNote"><TT>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"</TT><TT></TT>
<P><TT>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.</TT>
<BR><TT></TT>&nbsp;</DIV>

<DIV CLASS="MarginNote"><TT>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.</TT></DIV>

<UL>
<UL>
<UL>
<UL>
<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">MYNAME=`basename $0`</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF"># did things work out
or not?</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">action=`./sanity_check
$MYNAME $1`</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">if test $? -ne root ;
then</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">exit 1</FONT></TT></DIV>

<DIV CLASS="Paragraph1"><TT><FONT COLOR="#3366FF">fi</FONT></TT></DIV>
</UL>
</UL>
</UL>
</UL>

<DIV CLASS="MarginNote"><TT>Lastly the is_root sub-function is called by
the sanity_check script to check and report if the caller is running as
root.</TT></DIV>

<H3 CLASS="MarginNote">
<TT>7) Question: Where do I get the latest version of titan?</TT></H3>

<H3 CLASS="MarginNote">
<TT>Answer: http://trouble.org/titan/index.html</TT></H3>

<H3 CLASS="MarginNote">
<TT>8) Question: If I write a titan module and want to share it, how do
I get it into the next release?</TT></H3>

<H3 CLASS="MarginNote">
<TT>Answer: Send a message to titan@trouble.org</TT></H3>
<A NAME="418156"></A><A HREF="TITAN_documentation.html">Back to Titan Main
Documentation Page</A>
<H5>
<A NAME="418157"></A></H5>

<H5>
Last Modified: 0:00 PDT, October 31, 1998</H5>
</UL>

</BODY>
</HTML>
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close