Hardening Solaris with Jass

By SeŠn Boran

This article presents a concise step-by-step approach to securely installing Solaris for use in a firewall DMZ or other sensitive environment, using Sun's Jass tool (and with Solaris 8 the Sunscreen EFS lite firewall).  This article was written (and tested) for Solaris 8, but the techniques described here should work fine on earlier versions too.

The hardening process is divided into the following steps:

  1. Preparation

    27.Jan'03 Corrections to sendmail setup.
    22.Mar'02: The latest version of Jass is v0.3
    .5. The changes to Jass between these versions  concern primarily new Driver profiles, new template and support for Solaris 

  2. Initial OS installation
  3. Install Jass
  4. Mounting file systems restrictively in /etc/vfstab
  5. Install a local firewall: Sunscreen EFS lite or IPF
  6. More hardening: routing, email, resolver, tools
  7. Patches
  8. RPC
  9. Logging, Cron, Permissions
  10. Limiting SUID Files
  11. Install an Integrity Checker: e.g. Tripwire
  12. Install, test, harden applications
  13. Going Live

Reference section

1. Preparation

2. Initial OS installation

We assume that a "manual", as opposed to automated Jumpstart installation is used.

Connect the serial console, switch on, halt to the OK prompt by sending a Stop-A (~#, ~%b, or F5 depending on whether you use tip, cu or a vt100 terminal), then start the installation procedure:  boot cdrom - install .
Note: On Solaris 8, make sure your use "Software CD#1" and not the "Installation CD".

Install the end user bundle (or even better only the core packages which take only 110MB), set hostname, terminal, IP parameters, timezone, etc. Don't enable any naming services like NIS or NFS. Don't enable power management, or mount any remote file systems (NFS).

C-shell fans:

If you use the C-Shell, the following will make command-line editing easier and enable history functions:

setenv TERM vt100;
setenv VISUAL vi;
setenv EDITOR vi;
set filec;
set history=40;
alias h history;
alias ls 'ls -aF \!*';

Note: On Solaris 8, the user bundle can be customised via "F4", packages can be added or removed.

Choose manual disk partitioning:


Set a strong password (7 or 8 chars with numbers, letters and punctuation) for root.

The installation is documented in /var/sadm/install_data/install_log

Next, we install man pages not included in the User Bundle and the recommended patches.

Package notes:
"core" bundle users may wish to add other useful packages now, for example:

Terminfo: SUNWter
Accounting: SUNWaccr SUNWaccu
NTP: SUNWntpr SUNWntpu
UCB tools: SUNWscpu
Man pages tools: SUNWlibC SUNWdoc

Showrev: SUNWadmfw SUNWadmc

The user bundle needs extra packages for compiling: SUNWarcx SUNWarc SUNWbtoox SUNWbtool SUNWbtoox SUNWdplx SUNWsprox SUNWhea SUNWlibm SUNWdfbh SUNWcg6h SUNWscpux

For Sunscreen 3.1: SUNWeuluf SUNWsprot SUNWmfrun 
For Sunscreen 3.2: SUNWeulux SUNWapchr SUNWapchu SUNWeu8os SUNWeu8osx SUNWeu8ox

No man pages are installed with the user bundle, so install them while the Solaris CD is still mounted. Note: if you only installed the core bundle, SUNWlibc is needed for viewing the man pages (which needs sgml2roff), so add this package as well if needed (it is on CD#1 on Solaris8).

cd /cdrom/cdrom0/s0/Solaris_2.6/Product;
pkgadd -d . SUNWman SUNWdtma SUNWjvman SUNWpmowm SUNWolman SUNWxwman

cd /cdrom/cdrom0/s0/Solaris_2.7/Product;
pkgadd -d . SUNWman SUNWdtmaz SUNWdtma SUNWjvman SUNWpmowm SUNWxwman

On Solaris 8, insert CD#2. To save space, the man pages could be limited to the standard ones and java:cd /cdrom/cdrom0/Solaris_*/Product;
pkgadd -d . SUNWman SUNWjvman SUNWj2man

While we're here, we'll install compression tools- 

 zlib (for OpenSSH) and bash/tcsh (because they are nice shells :).
pkgadd -d . SUNWgzip SUNWbash SUNWbzip SUNWtcsh SUNWzlib

Update indices, so that "man -k keyword" will allow searching of relevant man pages:

/usr/lib/makewhatis /usr/man;
/usr/lib/makewhatis /usr/openwin/man;


If you're impatient to learn about patch management tools for existing hosts, jump to the Patches section.

Download and install the latest recommended and security patch bundle from Sun:

Solaris URL
2.6 SPARC ftp://sunsolve.sun.com/pub/patches/2.6_Recommended.tar.Z
7 SPARC ftp://sunsolve.sun.com/pub/patches/7_Recommended.zip
7 Intel ftp://sunsolve.sun.com/pub/patches/7_x86_Recommended.zip
8 SPARC ftp://sunsolve.sun.com/pub/patches/8_Recommended.zip
8 Intel ftp://sunsolve.sun.com/pub/patches/8_x86_Recommended.zip
9 SPARC ftp://sunsolve.sun.com/pub/patches/9_Recommended.zip

These files can be many tens of megabytes, since they cover all Solaris packages, not just those relevant to your installation. The uncompressed versions can run to over 150MB.

a) On a new system where de-installation is unlikely to be necessary, install without being able to remove patches. This will save lots of disk space:
cd *Recommended;
./install_cluster -nosave;

b) Installation on an existing system, or where de-installation of the patches must be possible if the patch cluster messes things up (this will take more disk space as copies are saved in /var/sadm/patch). Patches can only be individually de-installed, there is not "deinstall_cluster" functionality.
cd *Recommended;

Reboot and logon again as root.

Note: patches will be checked and updated again, in more detail, in the Patch section below.

3. Install Jass

See the section Jass Overview for an overview of this tool. This section has been tested with Jass v0.30 and v0.31.

First: Record a log of all command actions/taken in the this section, by running:

script -a /jassinstall.log
which will keep a log of all commands and results in jassinstall.log. This may be useful for browsing through later.

Download SUNWjass-0.3.5.pkg [1] to the target, e.g. to /opt/install.

Shutdown the network interface during this next phase, just in case (the interface name depends on the architecture e.g. le0 on old SPARCs):

ifconfig hme0 down

Install the Jass package, no actual hardening is done at this stage. An example log of the output is at [1]

pkgadd SUNWjass-0.3.5.pkg

Next we tune some Jass configuration settings

a) /opt/SUNWjass/Drivers/user.init is created with some custom settings, to tailor behaviour for this system. First copy /opt/SUNWjass/Drivers/user.init.SAMPLE to  /opt/SUNWjass/Drivers/user.init and add the following to the bottom: 

# user.init
# sb, 02.Oct.01
## v0.3.1
## Don't save files replaced by patches:

b) I don't wish to enable BSM auditing or have process accounting, so comment out the lines "enable-bsm.fin" and "enable-process-accounting.fin" in Drivers/hardening.driver and Drivers/undoable-hardening.driver (jass v0.31).

d) If you didn't install the latest recommended patches above, Jass will do it for you, if you extract them into the 'Patches' directory. For example the Solaris 8 recommended bundles would be extracted into Patches/8_Recommended.

e) Jass with run Casper Dik's Fix-modes to tighten up file permissions, if you download FixModes.tar.Z from the Jass site to /opt/SUNWjass/Packages. I recommend you do this. 

Then we run Jass to do the actual hardening for standalone use:

/opt/SUNWjass/jass-execute -d hardening.driver

Reboot, check processes

Switch off the scripting, remove the install directory if desired.

# exit
Script done, file is /jassinstall.log

Now reboot for the changes to have effect:

# reboot

Check for error messages on the console, fix if necessary.  Login as root and check the process list, it should be something like the following example for Solaris 8:

# ps -ef
root 0 0 3 17:05:33 ? 0:17 sched
root 1 0 0 17:05:33 ? 0:00 /etc/init -
root 2 0 0 17:05:33 ? 0:00 pageout
root 3 0 0 17:05:33 ? 0:00 fsflush
root 258 1 0 17:06:11 ? 0:00 /usr/lib/saf/sac -t 300
root 261 258 0 17:06:12 ? 0:00 /usr/lib/saf/ttymon
root 129 1 0 17:06:07 ? 0:00 /usr/sbin/in.routed -q
root 46 1 0 17:05:42 ? 0:00 /usr/lib/sysevent/syseventd
root 239 1 0 17:06:10 ? 0:00 /usr/lib/sendmail -q15m
root 218 1 0 17:06:08 ? 0:00 /usr/sbin/inetd -s -t
root 226 1 0 17:06:09 ? 0:00 /usr/sbin/syslogd -t
root 247 1 0 17:06:10 ? 0:00 /usr/sbin/vold
root 233 1 0 17:06:09 ? 0:00 /usr/sbin/cron
root 242 1 0 17:06:10 ? 0:00 /usr/sbin/nscd
root 251 1 0 17:06:11 ? 0:00 /usr/lib/utmpd

netstat -a shows only SSH listening (if you have SSH installed).

If at this stage, you're convinced that you really will run Jass on your system, first read through the Jass Tips section. The following sections go through further configuration issues to complement the Jass settings.

SSH note:

SSH is a good thing, essential for every UNIX box. There are several SSH variants (see the SSH section).


TBD: need to write a note about Jass + jumpstart and what follows later on.



4. Mounting file systems restrictively in /etc/vfstab

Several options can be set to improve the security and robustness of filesystems when they are mounted. Run the mount command to check that filesystems options are effective.

Mount option OS Description When to use it
nosuid 2.x Disables SUID programs, but also disables devices! /var or /home or data disks where no SUID programs, or devices (and hence chroot environments are used).
/tmp won't work either, unless it is on disk.
logging 2.7 or later keeps a transaction log within the mounted partition. The advantage is an almost instantaneous filesystem check - which may take a considerable while with larger hard-disks, e.g. 50 GB. The disadvantage is the additional time spent writing the transaction log. /usr /opt /home

Recommended for all file systems except: root (if Veritas VxVM is used), or where file write performance is critical.
noatime 2.7 or later allows mounting file systems without updating inodes at each access to any file. This will significantly speed up services like web caches or news servers, which do a lot of file IO with small files.

BUT, it make forensics more difficult in case of an intrusion, since access times are not recorded.

/var or any partition where lots of file access are expected (web cache or news partitions).
size=200m 2.5.1 or later Allow /tmp to only use 200MB of swap space. The value could be set to say 30% of swap space. /tmp
ro 2.x Read-only

Mounting filesystems read-only provides only a limited protection against Trojans/attackers (if they get root, they can remount read-write).

It may save time fsck'ing when booting, can improve performance (access times don't need to be updated) and can prevent the sysadmin from making mistakes or help detecting mistakes (accidentally deleting files etc.).

Mounting read-only is a major argument for maintaining separate file systems for /usr or /opt.

Note that to mount /usr read-only, /usr/local often needs to be on a different partition.

Be very careful when editing vfstab, e.g. an error on the / or /usr lines can render the system unbootable! If this happens, boot from cdrom in single user mode, mount the problem disk, correct vfstab and reboot. Some examples of vfstab entries are:

A simple server with only a root and /var partition, running Solaris 2.8:

fd                -                  /dev/fd fd - no -
/proc             -                  /proc proc - no -
/dev/dsk/c0t3d0s1 -                  -    swap  - no  logging
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 /    ufs   1 no  logging
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /var ufs   1 no  logging,nosuid,noatime
swap              -                  /tmp tmpfs - yes size=100m

and on a larger server:

fd                -                  /dev/fd fd - no -
/proc             -                  /proc proc - no -
swap              -                  /tmp tmpfs - yes size=200m 
/dev/dsk/c0t8d0s0 /dev/rdsk/c0t8d0s0 /    ufs   1 no  logging
/dev/dsk/c0t8d0s1 -                  -    swap  - no  -
/dev/dsk/c0t8d0s4 /dev/rdsk/c0t8d0s4 /usr ufs   1 no  logging
/dev/dsk/c0t8d0s6 /dev/rdsk/c0t8d0s6 /var ufs   1 no  nosuid,noatime,logging
/dev/dsk/c0t8d0s5 /dev/rdsk/c0t8d0s5 /opt ufs   2 yes logging
Reboot to allow the vfstab values to have effect.

5. Solaris 8: Install Sunscreen EFS

For maximum protection, a local firewall can be installed:

  1. On some versions of Solaris 8, the iPlanet CD#2 contains among other things, a restricted edition of the Sunscreen - the Sunscreen EFS lite firewall. It can also be download for free from Sun.
  2. IPfilter [20] can be used as an alternative for older Solaris versions.

Sunscreen lite can be used to protect network communications to the local machine (among other things).  Below we present a quick overview of setting up some simple rules on the command line, see [9] for a detailed discussion of Sunscreen configuration.

# cd /opt/SUNWicg/SunScreen/bin;

# ./ssadm active
Active configuration: www default Initial.2

# ./ssadm edit Initial
edit> list rule
1 "common" "*" "*" ALLOW
edit> list address
"le0.net" RANGE
"localhost" HOST
"smtp-server" HOST
"www_le0" GROUP { } { }
edit> list service common
"common" GROUP "tcp all" "udp all" "syslog" "dns" "rpc all" "nfs prog" "icmp all" "rip" "ftp" "rsh" "real audio" "pmap udp all" "pmap tcp all" "rpc tcp all" "nis" "archie" "traceroute" "ping"

So we see that the default policy allows quite a few services through.

Let's presume that we are setting up a HTTPD server (on port 80) and intend to manage it via SSH. We also want to allow ping and traceroute for initial trouble shooting. We could then create and active the new firewall policy restricting access to these services as follows

# ./ssadm edit Initial
edit> add service ssh      SINGLE FORWARD "tcp" PORT 22
edit> add service myhttp GROUP ping traceroute ssh www
edit> replace rule 1 ALLOW myhttp "*" "*"
edit> list rule
1 "myhttp" "*" "*" ALLOW
edit> save
edit> verify
Configuration verified successfully (not activated).
edit> quit
www# ./ssadm activate Initial
Configuration activated successfully on www.


# cd /opt/SUNWicg/SunScreen/bin;
# ./ssadm edit Initial
edit> add address mgt_net RANGE
edit> add service mgt GROUP ping traceroute ssh
edit> add service https SINGLE FORWARD "tcp" PORT 443
edit> add service outgoing GROUP ping traceroute dns
edit> replace rule 1 ALLOW www "*" localhost
edit> replace rule 2 ALLOW https "*" localhost
edit> replace rule 3 ALLOW mgt mgt_net localhost
edit> replace rule 4 ALLOW outgoing localhost "*"
edit> replace rule 5 ALLOW smtp localhost mgt_net
edit> save
edit> verify
Configuration verified successfully (not activated).
# ./ssadm activate Initial
Configuration activated successfully on www.

Now test the network connections, to ensure the rules have the desired effect. To rollback to the initial configuration, delete all rules and add:

replace rule 1 ALLOW "common" "*" "*"

Finally, we can stop the remote Firewall management GUI. Why would we do this? If we are comfortable with the command line "ssadm" then one daemon more and one more configuration interface, that needs to be correctly configured and watched.

Disabling the following line in /etc/rc2.d/S63sunscreen
$SS_LIBDIR/run_httpd start efshttpd

In /opt/SUNWicg/SunScreen/lib/ss_boot, disable:
$SS_LIBDIR/ssadmserver start >/dev/console 2>&1

See also [9] for a detailed discussion of Sunscreen configuration.


6. More hardening: routing, email, resolver, tools

The system has now gone through a first hardening phase and should be still working! Boot and login on the console as root. Check for error messages on the console, fix if necessary.

Reboot, check for errors.

Install tools and scripts: All tools should already have been compiled and tested extensively on another machine. [These can be installed via Jumpstart, see Jass Tips]


7. Patches

Wait, don't skip to the next section just yet! Yes, patches make us all yawn... are they a waste of time? This sections presents some strategies for handling patches and tools to make life easier.

During installation, the Solaris recommend patch bundle was installed. However, not all security fixes are included in this bundle, and as time goes by you'll have to check regularly for new patches. Systems which have security patches installed are more secure than those which don't. For overview of the concepts of Solaris Patching, see "A SunSolve Patch Primer"  [15].

Patch strategies

Weakness are continually discovered in Solaris and 3rd party applications. Not only do the weakness pose threats but the volume of weaknesses and patches can be a threat: if not managed carefully, they will consume too much time or they will be simple ignored.

The first problem is to be aware that weaknesses and/or patches actually exist. Possible strategies are:

  1. Get on all the mailing lists of organisations such as CERT/First, vendors like Sun, and especially Bugtraq. This can consume quite a lot of time.
  2. Get on the mailing list of an organisation which produces regular summaries of weakness/patches and security news, for example SecurityFocus (Sun section/ email list) or SANS. If a regular source of reliable information on Solaris and the applications that you use can be found, it may save much time.
  3. Run a tool on important servers that checks the current patch level and compares it with the newest list of patches available from Sun: This is the ideal situation (it is discussed below in more detail).
  4. Check Sun's recommended patch bundles for changes every month or two: This requires little effort, but security is not as tight and the recommended bundles do not cover all Security problems. The recommended bundles may cause problems with some applications though, if kernel patches are applied.
  5. 3rd party application patches need to be checked and applied too. Don't forget them!

How do you decide whether a weakness is worth patching?

Warning: Patches may reverse some of Jass's changes. So reboot after applying patches, check carefully that no unexpected daemons are running and consider re-running Jass (it is designed to allow multiple runs).

Some patches installations may give warnings/errors:

Patch Tools [15]:

8. RPC

RPC services should be avoided on sensitive servers, such as those on the Internet or in a DMZ. RPC uses dynamic ports and provides no standard access control methods. However, some programs insist on having RPC e.g. CDE, OpenWindows, Disksuite and Legato Networker. If possible avoid RPC, otherwise....

Improving Disksuite Security:

Disksuite is a tool bundled with Solaris that allows disks to be mirrored or gathered into RAID sets. This is useful feature to have in the system. The problem is that Disksuite uses RPC (specifically: two programs rpc.metamhd and rpc.metad which run from inetd).

How can Disksuite security be improved?

  1. Don't run Disksuite. This is my often choice.
    • Hardware RAID systems have the advantage that no special software like Disksuite is needed. This is better for secure systems (simplicity) and in disaster scenarios you may find Disksuite isn't all that easy to handle.
    • For system disks (where data does not change often), I've written a script for backing up boot disks with cpio. See also the section Boot disk backup.
  2. Run Disksuite but stop the associated RPC services (in /etc/inetd.conf) and stop rpcbind:
    • The "metad" service can be disabled but this means the "metatool" will not work. Command line tools will work fine -- and you should know them in any case for disaster scenarios with system disks.
    • The "metamhd" service can be disabled but this means you cannot share metadevices between systems.

OK, let's get back to general measures for RPC security:

9. Logging, root cron entries

Syslog logging: I replace Suns syslog.conf and that installed by Jass, with my own [3] - that enables more logging than the default and saves logs in /var/adm/messages. More details below.

I also disabled the Solaris log pruning and other lines in the root cron. I've written a script /secure/weekly [3] which includes the weekly entries listed below and can be run on both loghost and client, with a cron entry like:
50 23 * * 6 sh /secure/weekly >/dev/null 

Syslog configuration:

Syslog client: Designate one machine as the loghost (in /etc/hosts).

Syslog server or "loghost":

## Prune syslog logs weekly, keeping the last 6 months or so:
55 23 * * 6 /secure/rotate_log -n 40 alertlog
55 23 * * 6 /secure/rotate_log -n 40 authlog
55 23 * * 6 /secure/rotate_log -n 20 cronlog
55 23 * * 6 /secure/rotate_log -n 40 daemonlog
55 23 * * 6 /secure/rotate_log -n 40 kernlog
55 23 * * 6 /secure/rotate_log -n 40 local0log
55 23 * * 6 /secure/rotate_log -n 40 local2log
55 23 * * 6 /secure/rotate_log -n 40 local5log
55 23 * * 6 /secure/rotate_log -n 20 newslog
55 23 * * 6 /secure/rotate_log -n 40 userlog
55 23 * * 6 /secure/rotate_log -n 10 lprlog
55 23 * * 6 /secure/rotate_log -n 20 maillog

Add a root cron entry for cleaning of other local logs on both workstations and servers (note that /secure/weekly also includes this)

# Solaris 2.x logs:
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 loginlog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 sulog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 2 vold.log
0 4 * * 6 /secure/rotate_cron

Add a root cron entry for Yearly cleaning of login entries

## Empty login/logout records at year end
0 0 31 12 * /secure/wtrim.pl wtmp 20
0 0 31 12 * /secure/wtrim.pl wtmpx 20

Other root cron entries:

Set date once a day with a reliable source using rdate (you may prefer NTP, it's more accurate, but complex, uses bandwidth and is an additional security worry). See also the section Time Synchronisation.
## Synchronise the time:
0 * * * * /usr/bin/rdate YOURTIMEHOST  >/dev/null 2>&1
## Synchronise the time with NTP
#0 * * * * ntpdate YOURTIMEHOST1 YOURTIMEHOST2  >/dev/null 2>&1

Consider installing a script to check that important daemons are running. For example, install monitor_processes.pl [3] and add a root cron entry:

## Check that important processes are running during office hours:
0,30 8-19 * * 1-5 /secure/monitor_processes.pl sshd httpd


Document configuration changes in a text file such as /etc/mods, update after each change, with date, author, files affected, description.
cat > /etc/mods <<EOF
15.10.01  sb  New install of Solaris8 and tools according to hardening guidelines


10. Limiting SUID Files

Files which have the SUID bit set (an "s" where the execute bit for the owner/group is shown in 'ls' listings) allow the user executing the program to assume the identity/group of the owner of the program. This is typically used to allow normal users to access certain function typically only allowed to root, for example binding to low ports, mounting  a floppy disk, etc. The problem is that historically, many security weakness have been found in such programs allowing attackers with local accounts to become root by exploiting buffer over flows, race conditions etc.

• Solaris has many "SUID root" binaries and each one presents a risk, so when hardening systems it is advisable to disable as many SUID program as possible.
• The purpose of this section is to provide a brief overview of the subject, a list of documents and scripts for disabling SUID files is provided.
• See [8] for SUID references and further reading.

What SUID files are on the system?

The find command can be used to list all SUID files:
find / -perm -u+s -ls

or all SGID files:
find / -perm -g+s -ls

How should we handle SUID files? Possible courses of action, in order of preference, are:

What SUID files need to be limited?

Some auditing ideas:

Further reading:

More file permissions tightening:

chmod o-rx /etc/security          #Not needed for Solaris8 or later
chmod 400 /.shosts /etc/sshd_config /etc/ssh_known_hosts

To Do:

It would be useful to have packages that reset the SUID files for examples situations such as Bastion Hosts (high), multi-user servers (medium), workstations (low). The packages would also correct the pkg database so that 'pkgchk -n' would not report permissions errors after the SUID files had been adapted.

11. Install an Integrity Checker: e.g. Tripwire

You should regularly check the integrity of files on the system, to be assured that they have not been maliciously modified. Solaris provides "pkgchk -n" which checks the package databases against the size, permissions and checksums of actually installed files. This is useful and recommended, however checksums can be fooled and the package database can itself be manipulated, so it is no protection against the clever attacker (or the script Kiddie with a clever rootkit). What is required, is a file integrity checker that uses secure (one-way) hashing algorithms.

Which is why the Yassp Tarball installs tripwire in /secure/tripwire. Tripwire uses several secure hashing algorithms (and in it's commercial form, provides cryptographic signing of it's database).

At this stage of the installation, it is recommended to take a snapshot of the files on the newly configured system, i.e. initialise tripwire's database and then run regular checks to monitor for changes. If possible, keep the master database on another machine, offline or on write-once media.

What options do we have for integrity checking?

An example using the free Tripwire Version 1.2 (bundled with Yassp):

12. Install, test, harden applications

Depending on the function of the server, applications such as ftpd, BIND, proxies, etc. are installed at this point.

Hardening of specific applications like ftp, DNS, Email and also general application tips are discussed in a separate document [16].


13. Going live

Preparing to go live
  1. You probably won't need CD-ROMs or floppies anymore, so disable the volume manager in /etc/yassp.conf (if it was still enabled, which it not by default).
    If you do need to mount a CD in the future, start vold manually and check for new devices:
        drvconfig; disks; vold &; volcheck; df -k
  2. If partitions such as /opt or /usr had to be mounted read-write during the application install/testing, consider mounting them read-only now.
  3. Reinitialise tripwire (or equivalent integrity checker).
  4. Backup the system to two tapes, one offsite.
  5. Run a network scan on the system, to ensure that only expected services are visible. A commercial tool such as ISS or a free one like Nessus, nmap, Satan/Saint/Sara should do the job. Print out the results and archive.
  6. If possible, have additional people do the final testing, just in case something was forgotten.
  7. Test in detail - What works? What is forbidden? Check console/log entries. Does the system behave as expected? Watch the logs very frequently during the first few days of production.
Going Live

Connect to the live network. Test in detail. Check log entries. Does the system behave as expected?

Have applications been tested in detail, by different people with different points of view, from different access points on the network?

Regular maintenance

The following activities should take place hourly, daily, weekly or monthly, depending on how critical the system is:

Jass Overview

The primary goal behind the development of the Solaris Security Toolkit  ("Jass")  was to simplify and automate the process of securing Solaris systems through JumpStart or in a standalone mode. It implements the recommendations in Sun's BluePrints security articles. Jass is Sun's answer to Yassp and Titan, and has evolved into a capable, interesting, Solaris hardening tool.

"The Solaris Security Toolkit is a tool designed to assist in creation and deployment of secured Solaris Operating Environment systems. The Toolkit is comprised of a set of scripts and directories implementing the recommendations made in the Sun BluePrints OnLine program.
These scripts can be executed on Solaris systems through the JumpStart technology or directly from the command line. The Toolkit includes scripts to harden, patch, and minimize Solaris Operating Environment systems. Sun does not support the Toolkit."

Summary of changes since version 0.2 (November 2000) -> v0.3:


Test Drive

We start off with an example of running Jass on a new Solaris 8 workstation installed with a 'user bundle'. An example log of the output is [1]

First we install Jass:
pkgadd SUNWjass-0.3.8.pkg

Copy over FixModes.tar.Z to /opt/SUNWjass/Packages, so FixModes will be run as part of the Jass installation.

Then we run the default Jass hardening for standalone use:
/opt/SUNWjass/jass-execute -d hardening.driver

On rebooting we find:

Next we try the 'undo' feature which allows us to go back to the configuration before Jass was run. It very nicely asks us which 'Jass run' we would like to undo:

/opt/SUNWjass/jass-execute -u

The undo seems to work fine, except for BSM auditing which is not cleanly removed, see also the undo log [1]. Jass can be run several times, and the undo can remove the effects of each previous run or all runs. Nice.

How good is the Jass hardening?

What I like about Jass?

What don't I like?


Jass is an interesting tool, well worth checking out. The fact that is sponsored (although not supported) by Sun, has most of the features of other hardening packages and is under constant improvement, should ensure it's elevation to a quasi standard.

Jass tips

The following are improvements/ideas that you may find useful to Jass in your environment. Example scripts can be found here. We assume the main driver used is hardening.driver.

  1. If a patch bundle is copied to /opt/SUNWjass/Patches (or /jumpstart/Patches), they are automatically installed.
    In v0.30, it is useful to adapt the script Finish/install-recommended-patches.fin so that 'install_cluster' is called with the '-nosave' option. On a new installs, I don't see the point in saving old patches and tying up tens of megabytes of space.
    In v0.31 add JASS_REC_PATCH_OPTIONS="-o -d" to user.init
  2. Accounting and BSM auditing are enabled by default in v0.31 and v035, which I don't recommend. They can de disabled by commenting the lines 'enable-bsm.fin' and 'enable-process-accounting.fin' in Drivers/hardening.driver.
  3. Before running Jass, copy md5.tar.Z and FixModes.tar.Z to /opt/SUNWjass/Packages to ensure they are installed when Jass is run.
  4. Scripts can be added to disable other daemons. For example to disable the nscd daemon (which may not be needed in all environments), add a new script to Finish/disable-nscd.fin which contains:

    echo "Disabling nscd startup and shutdown scripts"
    echo ""
    if [ "${JASS_KILL_SCRIPT_DISABLE}" = "1" ]; then
    disable_rc_file ${JASS_ROOT_DIR}/etc/rcS.d K40nscd
    disable_rc_file ${JASS_ROOT_DIR}/etc/rc0.d K40nscd
    disable_rc_file ${JASS_ROOT_DIR}/etc/rc1.d K40nscd
    disable_rc_file ${JASS_ROOT_DIR}/etc/rc2.d S76nscd

    Then we add disable-nscd.fin to the JASS_SCRIPTS section of Drivers/hardening.driver, to activate the above script..

  5. We can set the default router automatically (to A.B.C.1) by adding a file Finish/set-defaultrouter.fin, that contains the following. A line containing set-defaultrouter.fin also needs to be added to Drivers/hardening.driver.

    # Get IP address, chop off the host part and add ".1"
    inet=`ifconfig -a | grep inet | egrep -v "" | awk '{print $2}'`
    #echo $inet
    router=`echo $inet | awk -F'.' '{print $1 "." $2 "." $3 ".1"}'`
    #echo $router
    echo $router >> /a/etc/defaultrouter

  6. Jass will replace some files on the system, the new versions are found in the Files subdirectory. Depending on your preferences, you may wish to tweak some files, such as:

    .cshrc, .login - improve the path + prompt, reduce umask and add some aliases.
    etc/syslog.conf - log to a central loghost and locally (see syslog.conf).
    etc/motd, etc/issue, etc/default/ftpd, etc/default/telnetd - warning banners
    etc/nsswitch.conf - add dns to host lookups or add NIS or NIS+

  7. If you use DNS and the client setup is the same for your jumpstart hosts, then copy a template /etc/resolv.conf into /jumpstart/Files/etc and then add '/etc/resolv.conf' to $JASS_FILES in Drivers/hardening.driver.
  8. This method can be used to add any other files that need to be copied over during Jumpstart installation.
    In addition, files that depend on hostname ('uname -n') and architecture ('uname -r') can be defined, which allow for a jumpstart customised for specific hosts, e.g.


  9. To remove the numerous suid/sgid files (see the section limiting SUID Files), a file Finish/remove-suid.fin can be created and added to Drivers/hardening.driver.
  10. The Drivers/user.init was created with some custom settings, to tailor behaviour for this system (for instance sendmail is configured for queuing and not as an smtp server, /tmp can only take up 200MB of swap space, daemons won't create world readable files, etc.

    # user.init
    # sb, 02.Oct.01

    ## When used with Jumpstart:

    ## v0.3.1
    ## Don't save files replaced by patches:

  11. The default terminal, TERM is set to vt100 in /etc/.login by Finish/set-term, which is fine for servers managed by the serial console, but less useful for Workstations, or servers when a GUI is console is necessary (of course avoiding a GUI console is recommend for security). To disable the TERM setting, comment the set-term line in Drivers/hardening.driver.
  12. Sun recommend that if you change hardening.driver (or other Jass scripts), it is best to copy it to xyz_hardening.driver and run this new driver (where 'xyz' would be an abbreviation of your company or department name). In this way, when you install new Jass versions, they can fearlessly overwrite the default scripts and you can use 'diff' to check for changes.

Additional Notes

This article has been very specific, in the interest of making it practical. However, each security administrator has his own methods and each site has different requirements. There are many more issues than just those above, we address some more advanced topics in this section:


[2] Sunworld security columns
Solaris Security FAQ www.sunworld.com/common/security-faq.html
Padded Cells: www.sunworld.com/swol-01-1999/swol-01-security.html
[3] Scripts included /references in this article:

See www.boran.com/security/sp/solaris or boran.dyndns.org/solaris

[4] Doug Hughes:
- tocsin
can be downloaded in source form (tocsin.tar.gz), or a Solaris package (AUBtocsin), from: ftp://ftp.eng.auburn.edu/pub/doug
- tips and links on Disksuite, VxVM and the SPARC Storagearray:
[5] Tripwire:
Free version V1.2 ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire (last updated in 1994).
Commercial Version www.tripwiresecurity.com (starts at $495.-/server) also runs on NT.
OpenSource Version www.tripwire.org on Linux only.
Sunworld article: sunworld.com/sunworldonline/swol-02-2000/swol-02-security.html?0306a

Policy examples: http://policy.tripwire.com 

Scripts - see www.boran.com/security/sp/solaris.

[6]  Sample tools for analysing logs:

- Logcheck www.psionic.com/abacus/logcheck
- My improved version of logcheck www.boran.com/security/sp/solaris
- Swatch  ftp.stanford.edu/general/security-tools/swatch

[7] All About SSH PartI - Sean Boran
All About SSH Part II - Sean Boran
[7a] ftp.cs.hut.fi/pub/ssh
[8] Disabling SUID files:

Solaris 7 Setuid/Setgid Files Information Systems and Technology University of Waterloo
[Reg Quinton's documentation on Solaris 7 SUID files and associated scripts].
Solaris 2.6:
Solaris 8:

Titan's ziplock module

Example listing of SUID/SGID files on a Solaris 7 system: solaris/suid_sol7.txt
Example listing of SUID/SGID files on a Solaris 8 system: solaris/suid_sol8.txt

Jass script for disabling SUID/SGID files.

[9] Review: Sunscreen EFS3 Firewall - Sean Boran

Protect yourself with SunScreen Lite - Mark Thacker

Sun Blueprint on the Sunscreen lite v3.1

Sunscreen Lite install documentation is now available online

[10] Casper Dik's fix-modes script contains a huge number of file permission improvements for most Solaris versions. ftp.wins.uva.nl:/pub/solaris/fix-modes.tar.gz
Jens VŲckler's nettune script www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html
See also the local copy nettune.
[11] The Titan Project  www.titan.org
[12] AIDE, a GPL file integrity checker. www.cs.tut.fi/~rammer/aide.html
Basic File Integrity Checking (using AIDE)
[13] My articles on BIND: bind_hardening.html
BIND sources and home page: www.isc.org/products/BIND
Testing Domains: www.ip-plus.net/tools/dns_check_set_en.html
Chroot BIND 4.9.x on Solaris:
Chroot BIND 8 on RedHat and OpenBSD
[14] Wietse Venema's tools and papers (tcp wrapper, rpcbind/portmapper, postfix, Satan, ....) ftp.porcupine.org/pub/security/index.html
[15] Patches:
[16] Hardening Applications, application_hardening.html
[17] syslog replacements:
syslog-ng www.balabit.hu/products/syslog-ng (tcp connections, content filtering, encryption, authentication)
secure syslog  www.core-sdi.com/english/slogging/ssyslog.html (encryption and authentication of a trusted auditors machine)
Nsyslogd coombs.anu.edu.au/~avalon/nsyslog.html (tcp connections and SSL)

'Security Issues in Network Event Logging' working group, a part of Internet Engineering Task Force (IETF) committee. 

[18] Security Advisories: www.cert.org, www.first.orgwww.ciac.org
CERT provide several useful firewall/hardening/intrusion detection papers online www.cert.org/tech_tips.
Technical Discussion of advisories: www.SecurityFocus.com/sun
[19] Security Newsletters: SecurityFocus, SANS.
[20] IPfilter
IP Filter Based Firewalls HOWTO
Firewalling with IPF
Introduction to IP Filter
Introduction to IP Filter Part 2.
[21] Routing:
Sun's Routing Support Document/FAQ is an old, but comprehensive overview of routing, how it works in Solaris and how to configure/debug routing.
Gated is a better routing daemon: www.gated.org 
[22] Solaris C2/BSM security notes - Sean Boran
Other Solaris hardening articles not listed above:

Securing a Solaris Server - ACCS

Armoring Solaris by Lance Spitzner

Center for Internet Security Solaris Security Benchmark

Other useful links:

Changes to this article

27.Aug.01 New: Rewritten for Jass v03, using the original article for Solaris+Yassp.
                 Updates: NTP, initial patches. Saveit link.
20.Sep.01 Update EFS lite.
04.Oct.01 Jass v0.31 update
22.Nov.01 Syslog server
03.May.02 Minor updates after testing Jass v0.35
25.Aug.02 Update package notes

Script to log user activity:

# Don't allow user to break out of this script: 
#trap exit 2>/dev/null 0 1 2 3 13 15
# ensure log is restricted 
umask 027
/bin/script -a /var/tmp/eyal.$$;
logout; echo bye

SeŠn Boran is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook.

© Copyright 2001, SeŠn Boran, All Rights Reserved, Last Update: 27 Januar, 2003