Cover V11, I13


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

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.


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


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.


The TITAN Web site --

The JASS Web site --

The Solaris Security Toolkit- Installation, Configuration and Usage, Alex Noodergraaf and Glenn Brunette, June 2001 --

The Solaris Security Toolkit- Quick Start, Alex Noodergraaf and Glenn Brunette, June 2001 --

The Solaris Security Toolkit- Internals, Alex Noodergraaf and Glenn Brunette, June 2001 --

Maximum Security, Third Edition, Anonymous, SAMS Publishing

The Bastille Linux page --

The YASSP page --

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: