Solaris Secure by Default - Part 1

Welcome to the first installment of Getting to Know - Solaris Secure by Default) (SBD).

Solaris Secure by Default or more simply SBD was a project introduced into Nevada in build 42. It is scheduled to also appear in an update to Solaris 10 real soon now! ;-) The goal of the SBD project was to reduce the network-facing attack surface of Solaris by either (1) disabling those services that were not absolutely necessary by default and (2) configuring the remaining services to only accept connections from the local system itself. The one exception to this rule is Secure Shell which is enabled and listening by default. This is very similar to (the network service) configurations traditionally generated by the Solaris Security Toolkit, but the big difference is that SBD is an integrated part of the Solaris OS.

The SBD effort has already been completed for the ON, X11, CDE and Admin/Install consolidations. Work is still progressing to make the JDS/Gnome consolidation SBD compliant. So far, however, it is looking pretty darn good!

Let's look at an example. The following is the output of netstat on a freshly installed Ultra 10:

# netstat -f inet -P tcp -a

   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
      \*.\*                  \*.\*                0      0 49152      0 IDLE
      \*.sunrpc             \*.\*                0      0 49152      0 LISTEN
      \*.\*                  \*.\*                0      0 49152      0 IDLE
      \*.ssh                \*.\*                0      0 49152      0 LISTEN
localhost.smtp             \*.\*                0      0 49152      0 LISTEN
localhost.submission       \*.\*                0      0 49152      0 LISTEN

Note that this particular system did not have a "head" and was therefore not running any form of window manager. What you see left running is sshd, rpcbind, and sendmail. Clearly, sendmail will only accept incoming connections from localhost. rpcbind appears to be able to accept connections from the network, but in fact it will not.

A great side effect of this work is that there are now fewer network services started from run-control scripts as many were converted during this effort to use SMF. Some services were disabled by default using SMF while others now support SMF properties to control whether they should run in a "local only" mode or not. A "local only" SMF property is in fact how rpcbind is controlled in the example above.

In Nevada, SBD will be the default option for Solaris installations - no questions asked. For Solaris 10, you will still be given a choice, however, the SBD configuration will be the default. SBD will not have any impact on systems that are upgraded. Only initial installations will be able to take advantage of SBD out of the box.

That said, you can enable the SBD settings or revert back to the traditional Solaris settings at any point post-installation thanks to the handy, dandy, netservices command. Located in the /usr/sbin directory, this tool offers one stop shopping for switching network services between a traditional (open) and SBD state:

# /usr/sbin/netservices
netservices: usage: netservices [ open | limited ]

As you can see, the netservices command offers two options. The option open will change service states and properties to place a system into the traditional state. The option limited will place a system into the SBD state. Note that these commands are basically hammers that will forcibly change your state between the two values. If you have made service state customizations (e.g., disabling or enabling specific services), you may find that your settings will be modified.

TIP: It is best to use the netservices command immediately after installation (if you need to change values set during the installation of the system). If you need to make changes later on in the life of the system, you may be better off using the svccfg and svcadm commands to make those specific changes. That way, you should not run into any "surprises".

That is all for this installment. In our next Getting to Know - SBD article I will go into more detail regarding some of the service changes so that you can see for yourself not only how it was done but also how you will be able to adjust settings based on your requirements and policies. Take care,


References: Part 2 of 3 Part 3 of 3

Technorati Tag:


Woah, it sounds great, before that people had to look into various guides of securing solaris! Thanks Sun :)

Posted by guest on July 01, 2006 at 02:14 AM EDT #

Post a Comment:
Comments are closed for this entry.

This area of cyberspace is dedicated the goal of raising cybersecurity awareness. This blog will discuss cybersecurity risks, trends, news and best practices with a focus on improving mission assurance.


« June 2016