 Tools
to Help Harden SolarisTM
Kristy Westphal
There are several checklists on the Internet to help you lock
down an out-of-the-box installation of Solaris. But, if you have
followed any of them, you know how time consuming they can be, especially
for a large enterprise. The Solaris community, however, is in luck
when it comes to system hardening because a few forward-thinking
Sun engineers have built some tools that can help to automate this
procedure. In this article, I will discuss two such tools, TITAN
and JASS.
Default Installations
Over time, Solaris has improved its default security settings
in some areas. However, it still needs additional hardening to secure
some default settings. Areas that are fairly loose by default include:
- Unnecessary services enabled by default.
- Warning banners not included with default telnet and ftp services.
- More in-depth auditing not enabled.
- Generic system accounts not well secured.
- Strong password parameters not set.
- File permissions not adequately secure.
- More secure network settings not enabled.
The most recommended way to solve many of these problems is to
install only an End User software group, which contains the bare
minimum requirements to get the OS running. Unfortunately, this
is not possible for many systems administrators and an Entire Distribution
plus OEM installation is typically done. It can take a long time
to address these issues for every server, and tools like TITAN and
JASS help systems administrators fill this gap by utilizing a more
automated approach.
TITAN
TITAN, the Toolkit for Interactively Toughening Advanced Networks
and Systems, was created by Brad M. Powell (an employee of Sun)
with the help of Matt Archibald and Dan Farmer. Powell wanted to
make a default Solaris installation more "security conscious",
especially trying to ensure that the operating system was hardened
enough to run on firewalls. TITAN consists of a series of tools
tied together via a Bourne shell, which makes it easy to configure
for any environment. The current version works on Solaris 2.6 through
8, on Sparc and Intel, and the beta version will work on Linux and
FreeBSD as well as Solaris.
What TITAN Will and Won't Do
As the Web site says, TITAN does not replace the other invaluable
tools that you can install on your Sun system, such as OpenSSH,
sudo, tcp_wrappers, AIDE, or Crack. However, it does include one
add-on security tool: the fix-modes script developed by Casper Dik,
which changes default file permissions to a more secure setting.
It also can't manage the patches that will need to be installed
on your system; this responsibility is still up to the systems administrator.
It will, however, lock down many items that are open by default
on a Solaris system. (Details on exactly what gets locked down are
in the following config section.) TITAN will also assist with auditing
what needs to be hardened with the ability to run it in a -v
mode to check for vulnerabilities.
For this article, I am using version 4.0 Beta 2 of the tool on
a Solaris 8 x86 installation with no previous hardening. The particular
installation of Solaris that I am using is an entire distribution
plus OEM support.
How to Configure
There are several files that can be configured to customize TITAN
to fit your site. Setup of the files takes a bit of work up front,
but as with many good tools, once you have the configuration the
way you like it, you can easily roll it out to other systems.
The scripts include the following in the top-level directory.
(Note that these change slightly according to the version of Solaris,
so check that the file applies to your version.):
Titan-Config -- This config script determines which operating
system it is working with, looks for any dependencies, and then
makes the appropriate links to other files in the distribution.
It will also ask whether you want to run the backup script (see
backtit.sh), which will back up your files before running
TITAN.
Titan -- The main script that calls the other scripts in the
distribution.
TitanReport -- The script that will run all of the modules
in the distribution, checking the operating system for possible
vulnerabilities. This is essentially the auditing function of TITAN;
furthermore, the authors recommend that this script be used in a
cron job.
Sample files -- Four files: a server, a desktop, a firewall,
and a config file that can be used when TITAN is run with a -c
config-file parameter. These files are used in conjunction with
a certain type of system build.
backtit.sh -- This script is run when Titan-Config is used
with the -i option to install and backs up files that will
be changed when TITAN is run. As the FAQ notes, this does not back
up any changes made to file permissions.
untit.sh -- Run when Titan-Config is executed with the -d
option to de-install.
At the heart of TITAN are the various modules. More than 50 modules
are run in addition to two optional modules. The modules cover areas
such as system-wide umask settings, disabling the automounter at
boot time, enabling the Basic Security Module (BSM), changing default
cron settings, disabling default system accounts, turning off most
services in the /etc/inetd.conf file, setting kernel network settings
to be more secure using nddconfig, scanning for .rhost files, changes
the default sendmail.cf file, and much more. The Web site and documentation
have a complete listing of the modules and their purposes.
The scripts are very comprehensive, and don't need much tweaking,
unless you find that the fixes that they put in place are too strict
for your environment. It is a good idea to read through the descriptions
of each module and understand what you are about to implement prior
to doing so. An ideal method of testing would be to take a development
box that mirrors production and test the tool on that box first.
Then you can pick and choose which modules you do not want to implement,
and configure your setup accordingly. It is also noted on the FAQ
that it is not recommended to remove things from these modules unless
you are absolutely sure that you do not need that service or run
setting used. By removing one of these parameters, you are effectively
weakening the security of your system.
How TITAN Works
To begin, you have to download the TITAN tarball from the Web
site. Then unzip the distribution:
gunzip Titan,v4.0BETA2.tar.gz
Then untar the distribution:
tar xvf Titan,v4.0BETA2.tar
Once untarred, cd into the TITAN ,v4.0BETA2 directory and run:
Titan-Config -i
Running the config file with the -i parameter sets up the system
by running the backup script and ensuring the uninstall portion works.
Make sure that the backup files are stored in a safe place. If they
become compromised in any way, you will not be able to use them properly
to restore your system. One suggestion is to tar and copy them (located
in the arch directory, under the appropriate architecture for your
system, then under the Backup directory) to another location --
either another safe system or to tape/CD.
In the case of my install, I used TITAN as my auditing software,
then ran JASS, then re-ran the auditing piece to check whether all
the holes were fixed. So, I did:
TitanReport root@mocha
to audit my system, where the root@mocha should be the name of the
person to whom you want to send the final report. This capability
makes the TitanReport function easily put into a cron job for regular
use. The report is also stored in the logs directory under titan.rpt.
Note that the report can be very large (on my Intel box, it was 1.5
MG), so keep this in mind when sending many of these reports via email
and storing them on servers. The TitanReport script essentially does
the same function as using the -v option when running. The
main difference is that TitanReport puts all the tests into one file,
where Titan -v makes the "modules" directory under the logs
directory, with a separate file for each test.
A few things passed the audit, but not many. The next step is
to run JASS to see how many things will get fixed.
JASS
JASS, the JumpStart Architecture and Security Scripts (also referred
to as the Toolkit), was originally developed to run with Sun's
JumpStart. JumpStart is a program that will take an image of an
installed Sun system and automatically install that image on new
systems. Developed by members of the Engineering and Professional
Services teams (using feedback from a large group of folks in the
security community), JASS's main goal, like TITAN's, is
to ease the process of securing a Solaris system.
JASS is not a "traditional" Sun product, so it is also
not supported as such. However, the version of the operating system
that is left after the JASS installation will be supported. Therefore,
like freeware, you are pretty much on your own when using it. Currently,
JASS runs on versions 2.5.1 up to 8, both on Sparc and Intel platforms.
JASS also has the capability to run in either 32- or 64-bit mode,
and can be run on systems up to the E10000 platform. The latest
release version is 3.5, but for this article, I used version 3.4.
What JASS Will and Won't Do
As with TITAN, JASS will not install other valuable security tools
except for the fix-modes script. An undo function has been added
to JASS in case it needs to be uninstalled, and in general, JASS
locks down functions similar to those that TITAN addresses. One
bug that has been reported for users of Role Based Access Controls
(RBAC) is that JASS disables ncsd, which is required to run RBAC.
The JASS Web site says RBAC will be fixed in Solaris 9, so it is
no longer dependent on this daemon. The workaround for version 8
is to not use the disable-nscd-caching.fin script or to change
the /etc/ncsd.conf file to maintain a short caching time period.
How to Configure
JASS is broken up into directories addressing various areas of
focus: Drivers, Files, Finish, Packages, Patches, Profiles, Sysidcfg,
and Documentation. These directories are similar to the recommended
directory structure of the JumpStart server. It is recommended to
run JASS as configured by default first, because it can be a bit
of work to custom configure. Fortunately, customization is not impossible,
as the scripts in each directory are plain text, utilized by the
main JASS executable.
The scripts in each directory differ based on function. The Driver
directory contains files that contain the main configuration files
and specify which finish scripts will run. There are: an audit file,
a config file, a run, finish and hardening file, a special file
for iPlanet servers, a secure file, and undo files. The Files directory
has several files that are necessary for update, such as /etc/motd
and /etc/nsswitch.conf.
The Finish directory contains the scripts that perform the changes
to the system, based on what it finds in the driver directory. It
contains numerous scripts that contain fixes ranging from disabling
Apache, to setting parameters for core file generation to dhcp settings
and snmp settings. The Packages directory can be used to install
packages when the finish scripts are used. The Patches directory
can then be used to place the latest recommended patch set.
The Profiles directory can then be used for setting up profiles
for different types of installations. In the case of JASS, it contains
profiles for different types of iPlanet servers, as well as an end-user
profile, an entire-distribution profile, and a 32-bit minimal profile
for 32-bit platforms. The Sysidcfg directory also can be used to
help automate installations, separating installations by operating
system version.
How JASS Works
To run JASS as configured, you must download the distribution
and unzip it:
gunzip jass-0.3.4.tar.gz
Then untar it:
tar xvf jass-0.3.4.tar
Then cd into the jass-0.3.4 directory and run:
./jass-execute -d secure.driver -o jass.output
A key variable to note is the -o variable, which specifies
the name of an output file for record. JASS also makes a backup of
each file that it changes in its native directory. One drawback to
this is that, if an attacker gets on your system to modify something,
these backup files are easily identifiable. They are tagged with a
time and date stamp for easy recognition. So, for instance, the /etc/notrouter
file ended up as such:
notrouter.JASS.20020519231659
You should back up the system first or make a tar of these files and
then back up the tar file.
To find the other options when running JASS, you can run jass-execute
with a -h variable.
A Comparison between TITAN and JASS
The experiment of seeing the differences between JASS and TITAN
was very surprising. The first surprise was that the out-of-the-box,
vanilla Solaris 8 installation passed several tests that I didn't
expect it to. Tests such as NFS running on privileged TCP and UDP
ports, some default file permissions being set correctly (e.g.,
root owning /sbin, /etc not world writable), root cannot log in
directly except on the console, and several default users were found
in the ftpusers file. However, the issues that needed to be addressed
far outweighed the default checks that passed the TITAN audit.
After running the JASS tool on an already installed machine, I
re-ran the TitanReport script to see what had been done and what
had been left open. JASS left open a few things that TITAN did not,
such as not configuring kernel auditing, not locking down X access,
setting strong default password strength in /etc/default/passwd,
setting login defaults, not disabling sendmail, not adding all system
users to ftpusers (like audit and news), and not setting a banner
for telnet.
To see how TITAN stacks up, I ran it with the following:
<install dir>/Titan -f
The -f parameter is for "fix".
Once TITAN was done fixing the system, I ran the TitanReport function
again. There were only a handful of issues that TITAN could not
fix because some of them still needed to be addressed outside of
the environment (e.g., setting up a remote loghost and installing
smrsh (sendmail restricted shell)) at the discretion of the sys
admin. Some of the checks that failed will have to be investigated
further to determine whether they are just not applicable to the
system or if they just need to be manually fixed. For instance,
the last run of TitanReport claimed that the system did not pass
the first check of XDMCP. Upon further investigation, it appears
that although the system failed check one, it passed check two and
is sufficiently secured. (Note that XDMCP (X Display Manager Control
Protocol Description) looks for remote connections allowable through
Xaccess.)
How to Use These Tools
Both JASS and TITAN are great tools for more than one reason.
First, they have been developed by teams who know Solaris, know
security, and know how to combine them. Second, these scripts can
automate a long list of fixes and require little to no thought on
the part of the busy sys admin. The key is to test which tool (or
both) that you want to use and ensure that it does not lock down
a needed item.
So, how do you decide which tool to use and then, how do you best
deploy it? JASS was originally intended to work with the Solaris
JumpStart server and to become part of an automated imaging process.
If you are using JumpStart in your environment, then JASS is a great
way to deploy this from an automated standpoint across your enterprise.
JASS completes many of the security fixes that should be addressed
and is sufficient for most environments.
However, if you have Internet-facing boxes running Web servers
and other services, then TITAN may be the way to go. TITAN concentrates
on the nitty-gritty and closes things like IP protocol parameters
and runs fix-modes automatically to fix default file permissions.
TITAN tends to go a bit further than the recommended Sun Toolkit,
because it is developed outside of the company as an open source
community project.
Deploying TITAN on an enterprise basis can be a bit of work. TITAN
should be run first as an audit on each system, then run to lock
down things on the server, and then to establish a cron job to run
the TitanReport periodically. This will ensure compliance of the
security policy set up for that server. TITAN can be dangerous if
it is run automatically on live systems throughout the enterprise.
Before you use either of these tools, you should complete a full
backup of your system. After running either tool, do a reboot of
the system to ensure that all is in working order. Ideally, you
wouldn't test these tools on live production boxes, but run
them on test systems first. The tools mentioned in this article
are a great step in closing the gap between hardened and non-hardened
systems in an automated, customizable approach.
Other Tools to Consider
The tools mentioned in this article are not the only hardening
tools available for Solaris and other flavors of UNIX. YASSP (Yet
Another Solaris Security Package) by Jean Chouanard is another good
tool. YASSP works on the 2.6, 7, and 8 versions of Solaris, both
on the Intel and Sparc platforms. YASSP does much of what TITAN
and JASS do. It also runs the fix-modes script, and comes bundled
with gzip, OpenSSH, Tripwire, tcp_wrappers, and other automated
scripts.
Bastille
Another tool that deserves mention is Bastille, which currently
supports Red Hat and Mandrake Linux, with the promise of supporting
HP-UX, Debian, TurboLinux, and SuSE in the near future. Bastille
comes in rpm format, or you can download the tarball and compile.
This hardening tool includes most of the steps outlined in the SANS
step-by-step guide to hardening Linux, as well as those from many
"major reputable sources on Linux security".
Conclusions
Using JASS or TITAN can not only help automate the hardening of
your Solaris operating system, but can also help consistently do
so. Often when this procedure is done manually, a systems administrator
will get interrupted and miss a step. When that happens, the security
is not consistently applied across all systems. Establishing the
set configuration files with these tools helps prevent that.
These tools, however, do not do everything. Important elements
of any good security architecture include strong policies and procedures
to support them. These policies must include things that these automated
tools cannot cover, such as strong password parameters, reviewing
log files for anomalies, and keeping up with patches.
Resources
The TITAN Web site -- http://www.fish.com/titan/
The JASS Web site -- http://wwws.sun.com/software/security/jass/
The Solaris Security Toolkit- Installation, Configuration and
Usage, Alex Noodergraaf and Glenn Brunette, June 2001 -- http://www.sun.com/blueprints/0601/jass_conf_install-v03.pdf
The Solaris Security Toolkit- Quick Start, Alex Noodergraaf and
Glenn Brunette, June 2001 -- http://www.sun.com/blueprints/0601/jass_quick_start-v03.pdf
The Solaris Security Toolkit- Internals, Alex Noodergraaf and
Glenn Brunette, June 2001 -- http://www.sun.com/blueprints/0601/jass_internals-v03.pdf
Maximum Security, Third Edition, Anonymous, SAMS Publishing
The Bastille Linux page -- http://bastille-linux.sourceforge.net/
The YASSP page -- http://www.yassp.org
Kristy Westphal, CISSP, is a versatile network administrator,
skilled in troubleshooting and process analysis. Her 8+ years of
experience in the IS field have allowed her to become knowledgeable
in UNIX and NT, as well as project management and security/disaster
recovery planning. She currently works as Information Security Officer
for Pegasus Solutions. She can be reached at: ckwestphal@cox.net.
| 
