Less known Solaris Feature: Solaris Security Toolkit
When you want to place a system into a network, it´s a good practice to harden the system. Hardening is the configuration of a system to minimize the attack vectors for an intruder by closing down services, configuring stricter security policies and activating a more verbose logging or auditing.
But hardening is not a really simple task: You have to switch off as much services as possible and modify the configuration of many daemons. Furthermore you have to know, what your application needs to run, you can´t close down a service that another service needs to execute. Those dependencies may be simple for a server with an apache daemon, but to harden a Sun Cluster needs a little bit more knowledge. Furthermore you have to keep the configuration in a way, that´s supported by Sun.
What is the Solaris Security Toolkit?
People at Sun do this at their everyday job, thus we have experience to do such hardings. It would be nice to have this knowlege in a framework to automate all this steps. The Sun Security Toolkit was designed with this objective. As the SST website states:
The Solaris Security Toolkit, formerly known as the JumpStart Architecture and Security Scripts (JASS) toolkit, provides a flexible and extensible mechanism to harden and audit Solaris Operating Systems (OSs). The Solaris Security Toolkit simplifies and automates the process of securing Solaris Operating Systems and is based on proven security best practices and practical customer site experience gathered over many years. This toolkit can be used to secure SPARC-based and x86/x64-based systems.
The SST is an old tool. I use it for years to harden my own systems and in the past any Jumpstart installation made at customer sites contained this toolkit to give them automatic hardening. Futhermore it´s a good practice to use this toolkit on freshly iinstalled systems as a first step in the deployment process of new server hardware before you start to install your application.
How to install the Solaris Security Toolkit?
Installation of the Toolkit is really easy. At first you have to gather it from the Sun Download Center. Sorry, you need a account for it, but you can register for free. You will find it here.Before login in as root, i´ve copied the file SUNWjass-4.2.0.pkg.tar.Z via scp to my freshly installed system with Solaris 10 Update 5
# cd /tmp<br />
# ls<br />
SUNWjass-4.2.0.pkg.tar.Z hsperfdata_root typescript<br />
hsperfdata_noaccess ogl_select216<br />
# bash<br />
# uncompress SUNWjass-4.2.0.pkg.tar.Z<br />
# tar xfv SUNWjass-4.2.0.pkg.tar<br />
x SUNWjass, 0 bytes, 0 tape blocks<br />
x SUNWjass/pkgmap, 33111 bytes, 65 tape blocks<br />
[...]<br />
x SUNWjass/install/preremove, 1090 bytes, 3 tape blocks<br />
x SUNWjass/install/tsolinfo, 52 bytes, 1 tape blocksNow let´s install the package:
<br />
# pkgadd -d . SUNWjass
Processing package instance <SUNWjass> from </tmp>
Solaris Security Toolkit 4.2.0(Solaris) 4.2.0<br />
Copyright 2005 Sun Microsystems, Inc. All rights reserved.<br />
Use is subject to license terms.<br />
Using </opt> as the package base directory.<br />
## Processing package information.<br />
## Processing system information.<br />
## Verifying package dependencies.<br />
## Verifying disk space requirements.<br />
## Checking for conflicts with packages already installed.<br />
## Checking for setuid/setgid programs.
Installing Solaris Security Toolkit 4.2.0 as <SUNWjass>
## Installing part 1 of 1.<br />
/opt/SUNWjass/Audit/disable-IIim.aud<br />
[...]<br />
/opt/SUNWjass/sysidcfg <symbolic link><br />
[ verifying class <none> ]
Installation of <SUNWjass> was successful.Now i can use the Sun Security Toolkit for system hardening. It´s installed at /opt/SUNWjass/
A look into the framework
At the end the SST is a collection of scripts and files and some code to distribute those changes throughout the system.
Each script was developed to execute a single job in the process of system hardening. When you look into the directory /opt/SUNWjass/Finish you will find a vast amount of them. For example enable-bart.fin for the automatic execution of BART to generate a system baseline or disable-remote-root-login.fin to automatically disable root logins, when an admin had activated those logins.
On the other side you will some configuration files in the Sun Security Toolkit as well. Sometimes a service needs some additional configuration for hardining, for example an really paranoid hosts.deny. Those configuration templates are contained in the directory /opt/SUNWjass/Files.
But you don´t use both types of directly … you use them in collections called drivers. You find those drivers in /opt/SUNWjass/Drivers. These drivers execute all such scripts in a certain sequence. Some drivers are really simple … they just call other drivers. A good example is the secure.driver which just calls the hardening.driver and the configuration.driver. The hardening.driver is a better example. This driver calls many of the scripts mentioned before.
At this moment, you should take some time and examine some files in /opt/SUNWjass/Drivers, /opt/SUNWjass/Files and /opt/SUNWjass/Finish to get more insight into the inner workings of SST. Don´t be shy, it´s just clever shell scripting.
Use the Solaris Security Toolkit for hardening
A tip from the field at first: Open a second ssh connection to the system, login as root, and leave this window untouched and minimized. This connection is quite handy to have a second limb, when you sawed away the one you sit on.
Okay, how do you use such a driver? This is really simple. But you shouldn´t execute the drivers blindly. They can lock you out of your system in the case you use them without caution. So change in to the directory for the Drivers:
# cd /opt/SUNWjass/DriversNow you should look into the desired drivers. An example: The hardening.driver contains a like to disable the nscd.
disable-nscd-caching.fin<code></blockquote>
But you want another behaviour for some reason. You just have to add an <code>#</code> in front of the line:<br />
<blockquote><code># disable-nscd-caching.finWell, there is another behaviour i don´t want. The default locks sshd via tcpwrapper to accesses from the local host. But there is a better template at /opt/SUNWjass/Files/etc/hosts.allow allowing ssh access from all hosts. You can force SST to use it by adding another line to the hardening.driver. I´ve added the bold line to do so:
JASS_FILES="<br />
<b>/etc/hosts.allow</b><br />
/etc/dt/config/Xaccess<br />
/etc/init.d/set-tmp-permissions<br />
/etc/issue<br />
/etc/motd<br />
/etc/rc2.d/S00set-tmp-permissions<br />
/etc/rc2.d/S07set-tmp-permissions<br />
/etc/syslog.conf<br />
"</blockquote>
</code> Now the Toolkits copies the file <code>/opt/SUNWjass/Files/etc/hosts.allow</code> to <code>/etc/hosts.allow</code>. As you may have noticed, the template as to be in the same directory as the file you want to substitue with the difference, that the directory of the template has to be relative to <code>/opt/SUNWjass/Files/</code> and not to <code>/</code>
Okay, now we have modified our driver, now we can execute it:<br />
<blockquote><code># cd /opt/SUNWjass/bin<br />
# ./jass-execute secure.driver<br />
[NOTE] The following prompt can be disabled by setting JASS_NOVICE_USER to 0.<br />
[WARN] Depending on how the Solaris Security Toolkit is configured, it<br />
is both possible and likely that by default all remote shell and file transfer<br />
access to this system will be disabled upon reboot effectively locking out any<br />
user without console access to the system.
Are you sure that you want to continue? (yes/no): [no]<br />
<b>yes</b>This warning is not a joke. Know what you do, when you use this toolkit. Hardening means “real hardening” and this process may leave you with a paranoid hosts.allow locking you out from accessing the sshd on your system. Without console access you would be toast now. But as we use the more sensible template for hosts.allow, we can proceed by answering with yes:
<br />
Executing driver, secure.driver
==============================================================================<br />
secure.driver: Driver started.<br />
==============================================================================
==============================================================================<br />
Toolkit Version: 4.2.0<br />
Node name: gondor<br />
Zone name: global<br />
Host ID: 1911578e<br />
Host address: 10.211.55.200<br />
MAC address: 0:1c:42:24:51:b9<br />
OS version: 5.10<br />
Date: Wed Apr 16 16:15:19 CEST 2008<br />
==============================================================================<br />After a first satus report , a long row of scripts will print log messages to the terminal. For example the finish script enable-coreadm.fin:
==============================================================================<br />
secure.driver: Finish script: enable-coreadm.fin<br />
==============================================================================
Configuring coreadm to use pattern matching and logging.
[NOTE] Creating a new directory, /var/core.<br />
[NOTE] Copying /etc/coreadm.conf to /etc/coreadm.conf.JASS.20080416161705
coreadm change was successful.Many reports of this kind will scroll along and at the end jass.execute prints out some diagnostic:
==============================================================================<br />
secure.driver: Driver finished.<br />
==============================================================================
==============================================================================<br />
[SUMMARY] Results Summary for APPLY run of secure.driver<br />
[SUMMARY] The run completed with a total of 97 scripts run.<br />
[SUMMARY] There were Failures in 0 Scripts<br />
[SUMMARY] There were Errors in 0 Scripts<br />
[SUMMARY] There were Warnings in 3 Scripts<br />
[SUMMARY] There were Notes in 81 Scripts
[SUMMARY] Warning Scripts listed in:<br />
/var/opt/SUNWjass/run/20080416161504/jass-script-warnings.txt<br />
[SUMMARY] Notes Scripts listed in:<br />
/var/opt/SUNWjass/run/20080416161504/jass-script-notes.txt
==============================================================================When you look around at you system, you will notice some new files. Every file in the system changed by the SST will be backuped before the change is done. For example you will find a file named vfstab.JASS.20080416161812 in /etc. JASS contains a finish script to limit the size of the /tmp. As the /tmp filesystem resides in the main memory, this is a sensible thing to do.
Let´s check for the differences:
# diff vfstab vfstab.JASS.20080416161812<br />
11c11<br />
< swap - /tmp tmpfs - yes size=512m<br />
---<br />
> swap - /tmp tmpfs - yes -The script has done it´s job and added the size=512m option to the mount.
Effects of the hardening
Many effects are not directly obivious like changes to security or password policies. You will recognize them, when the system forces you to change your password and when it´s getting harder to change a new one because of higher requirements for new passwords enforces by solaris.
A more obvious change is the new message of the day. It doesn´t print out the version. The new version is a little bit … uhmmm … more unfriendly:
<small>
<pre>aragorn:~ joergmoellenkamp$ ssh jmoekamp@10.211.55.200
Password:
Last login: Wed Apr 16 19:12:19 2008 from 10.211.55.2
|-----------------------------------------------------------------|
| This system is for the use of authorized users only. |
| Individuals using this computer system without authority, or in |
| excess of their authority, are subject to having all of their |
| activities on this system monitored and recorded by system |
| personnel. |
| |
| In the course of monitoring individuals improperly using this |
| system, or in the course of system maintenance, the activities |
| of authorized users may also be monitored. |
| |
| Anyone using this system expressly consents to such monitoring |
| and is advised that if such monitoring reveals possible |
| evidence of criminal activity, system personnel may provide the |
| evidence of such monitoring to law enforcement officials. |
|-----------------------------------------------------------------|
</pre>
</small>Undo the hardening
All these file ending with .JASS. are not just for you to lookup the changes of SSTThis files enables the SST to undo the changes and to fall back to a different configuration.
# ./jass-execute -u<br />
Executing driver, undo.driver
Please select a Solaris Security Toolkit run to restore through:<br />
1. April 16, 2008 at 16:15:04 (/var/opt/SUNWjass/run/20080416161504)<br />
Choice ('q' to exit)? <b>1</b><br />The choice is easy, we have just one old version, so we choose 1
<br />
[NOTE] Restoring to previous run from /var/opt/SUNWjass/run/20080416161504
==============================================================================<br />
undo.driver: Driver started.<br />
==============================================================================You may have changed some files since using the toolkit, thus the SST will ask you if you what it should do with those files. For example, i´ve changed the password of my account, thus the /etc/shadow has changed:
==============================================================================<br />
undo.driver: Undoing Finish Script: set-flexible-crypt.fin<br />
==============================================================================
[NOTE] Undoing operation COPY.<br />
[WARN] Checksum of current file does not match the saved value.<br />
[WARN] filename = /etc/shadow<br />
[WARN] current = 8e27a3919334de7c1c5f690999c35be8<br />
[WARN] saved = 86401b26a3cf38d001fdf6311496a48c
Select your course of action:<br />
1. Backup - Save the current file, BEFORE restoring original.<br />
2. Keep - Keep the current file, making NO changes.<br />
3. Force - Ignore manual changes, and OVERWRITE current file.
NOTE: The following additional options are applied to this and ALL subsequent files:<br />
4. ALWAYS Backup.<br />
5. ALWAYS Keep.<br />
6. ALWAYS Force.
Enter 1, 2, 3, 4, 5, or 6:<br />
<b>2</b><br />After this command the Solaris Security Toolkit has reverted all changes.
Conclusion
With the Solaris Security Toolkit you can deploy an certain baseline of security configurations to all your systems in an automatic manner. But it isn´t limited to run once after the installation, you can run it as often as you want to ensure that you get to an known secured state of your system after patching or reconfigurations of your system. By doing this automatically, you get a big advantage. Once you´ve developed your own driver for your site, nobody forgets to set a certain configuration leaving an attack vector open, you assumed as being closed down. This tutorial demonstrated only a small subset of the capabilties of the toolkit. For example you can integrate it into Jumpstart to automatically harden systems at their installation, you can use it to install a minimal patch cluster on each system where you execute the toolkit. So you should really dig down into the documentation of this toolkit to explore all the capabilities.
Do you want to learn more?
Documentation
docs.sun.com: Solaris Security Toolkit 4.2 Administration Guide