Locking down your Solaris system

In preparation for a forthcoming public trial of a new web service powered by Solaris, we recently spent some time investigating some different ways to lock down the system down. Here is an overview of our findings.

Solaris Installation

If you have the option of (re)installing Solaris, then take it. And in doing so, be sure to choose the Solaris Core installation cluster (SUNWCreq) as this is the most secure (mainly due to reduced number of packages that it includes). Of course this cluster will almost certainly not provide you with everything that you need (and you will have to manually install several packages thereafter) but it is generally worth while as you will know exactly what is and is not installed on your system.

Useful Tools and Utilities

I found the following utilities very useful:

  • netstat
  • nmap
  • lsof

The first is natively available on Solaris and the other two can be downloaded from the sunfreeware.com website. The combination of these utilities make it very to diagnose which ports are open (by which process) on a system. Refer to some of the articles below to see some good ways in which you can do this.

Solaris Security Toolkit

If you want to, you can manually lock down your system using the netstat, svcs and svcadm commands but you really need to know what you are doing. However, there is a far simpler way to do this and that is to use the Solaris Security Toolkit (SUNWjass). This is a very powerful (and extremely well documented) utility that is pretty easy to use, to very good effect. It is also free.

All you need to do is run one simple command (there are 16 variations to choose from depending on paranoid you are) and the SST will do the rest – disabling all the appropriate services, setting file permissions, creating hosts.allow and hosts.deny files and even invalidating non-root user passwords in certain cases. So be sure that you have console access to your system before you run it.

You can even run it again in analyse mode to ensure that the system is still locked down the same degree as it was when you first ran it (although I have not tested this).

Useful Links
Here are some good postings on the Solaris Security Toolkit

Apache + Mongrel on Solaris

Apache is an excellent Web Server but does not handle Rails projects very well. Mongrel is a Ruby-based library that can assist things like Apache with management of dynamic content.

Credit / Reference Site

We owe a great deal of thanks to this article posted by codehale on the same topic. The article you are reading here is a summation of notes taken during a recent installation of Apache and Mongrel on the Solaris operating system, based on codehale’s article.
Prerequisites

Several software packages need to be pre-installed on Solaris in order for Mongrel to install and operate correctly. I have listed them below along with the version I used. The version of Apache and Ruby were both taken from the Solaris CoolStack software bundle.

  1. Apache 2.2
  2. Ruby 1.8.5
  3. Ruby Gems 0.9.2
  4. Ruby on Rails 1.2.3
  5. Sun Studio 11

To install the software, simply download (and unzip) the relevant file from the above site(s) and install it (as root) using the pkgadd –d command.

Installation Procedure
The system used for this installation was a SunFire T1000 running Solaris 2.10 (U3).

Step 1 – Download Mongrel

Commands

# gem install daemons gem_plugin mongrel mongrel_cluster --include-dependencies --no-rdoc --no-ri

Notes

  • When asked about which version of Mongrel and FastThread, we chose the newest version for ruby (not win32).
  • The above command will attempt to compile and install some native code and requires a C compiler. If you are using Sun Studio, you should also read my other post regarding Ruby and Sun Studio.
  • If you are using GCC, then you may also require ginstall. However, ginstall is not available for Solaris so we overcame this by installing the GNU coreutils package and then creating a symbolic link: /usr/local/bin/ginstall pointing at /usr/local/bin/install (after coreutils was installed).
  • The reference site above also recommends that the “sendfile” utility be removed from your system (if installed). We used the “pkginfo | grep sendfile” command to verify that it was not present on our system.

Step 2 – Configuring Mongrel Clusters

Commands

# cd /opt/tssg/feedhenry/wc
# mongrel_rails cluster::configure -e production -p 8000 -a 127.0.0.1 -N 3 -c /opt/myrubyapp/public
# vi /opt/myrubyapp/config/mongrel_cluster.yml (and change port setting to 8000 - see below)
# mongrel_rails cluster::start -c /opt/myrubyapp/config/mongrel_cluster.yml

Notes

  • The -N value above represents the number of clusters required. We followed the example and chose 3.
  • The second command above creates a mongrel_cluster.yml file. However, we noticed that the port setting in this file was incorrect after it was created. It was “ath” instead of 8000 (not sure why).
  • The final command should produce one line of output for each cluster configured indicating that each cluster was correctly started.
  • You should also examine the logs/mongrel.log file and ensure that the clusters started on the correct ports (8000, 8001, 8002 etc). This is how we noticed that the .yml file had the wrong port setting.
  • You can use the mongrel_rails cluster::stop command to stop the clusters again (-c option also required here)

Step 3 – Configuring Apache

You will need use some additional Loadable Modules for Apache. Refer to this post for details on which ones you need and how to build them. You can then follow the instruction in the reference post.

Once these files were configured and placed in the conf/extra directory, we simply had to make one change to the main Apache configuration file (conf/httpd.conf) to ensure that these new files were loaded by Apache. This consisted of the following command:

Include conf/extra/myapp*.conf

You should now be ready to start Apache (/opt/coolstack/apache2/bin/apachectl start)

Best of luck!

Solaris CoolStack, Sun Studio and Ruby

If you are using the Solaris CoolStack edition of Ruby (CSKruby) with Sun Studio 11 (SUNWspro) then you may need to make a small change to one of the Ruby configuration files to tell it where Sun Studio is installed. I would have have expected the installer for the Ruby package to detect this but, alas, it does not.

In my case, this problem will only manifested itself when I attempted to install some platform-specific Ruby Gems packages (hpricot, fastthreads, mongrel).
To remedy this problem:

  1. Edit the file /opt/coolstack/lib/ruby/1.8/sparc-solaris2.10/rbconfig.rb
  2. Search for all instances of SUNWspro and change to the correct location
  3. Save the file and repeat your “gem install” command