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
Now let´s install the package:
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:
Now you should look into the desired drivers. An example: The hardening.driver
contains a like to disable the nscd.
Well, 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:
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
:
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
:
Many reports of this kind will scroll along and at the end jass.execute
prints out some diagnostic:
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:
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:
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.
The choice is easy, we have just one old version, so we choose 1
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:
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