Wednesday Aug 23, 2006
Scott Rotondo just posted a new Solaris Secure by Default presentation that is being used to raise awareness of SBD including what it is, why it is important and how it is implemented and used. Check it out!
For more information check out these other SBD references:
References:
Part 1 of 3
Part 2 of 3
Part 3 of 3
Technorati Tag:
OpenSolaris
Solaris
security
SMF
SBD
Wednesday Jul 19, 2006
Before I begin, I would like to point everyone to a posting by Scott Rotondo, one of the architects behind the Secure by Default project. Check it out and let him know what you think of this new Solaris enhancement!
Today, SBD is an all or nothing proposition - it is either enabled or disabled using the new netservices(1M) command. For many organizations, this is not enough. Very often, they must configure their systems such that some services are "off" or in a "local only" mode while others must be enabled or "open" to support a business or technical requirement. It is important therefore to be able to understand exactly what SBD is doing so that you can better tune the security configuration of your systems based on your specific needs and requirements. As we have noted previously, a SBD configuration is created by (1) disabling services or (2) adjusting service properties to put the service into a "local only" mode.
The enabling and disabling of services is a trivial matter. Simply using the svcadm command with the enable or disable action to adjust the services that interest you. Since this is a very easy
matter, this will not be the focus of this posting. For the third and final (for now) installment of Getting to Know - Solaris Secure by Default) (SBD), I would like to focus specifically on those services that are not disabled by default but instead are configured to accept only local connections (originating with the system itself).
Taking a look at the Secure by Default design document, you see that the list of services impacted are (expressed as FMRIs):
- svc:/network/rpc/bind
- svc:/system/system-log
- svc:/network/smtp:sendmail
- svc:/system/webconsole:console
- svc:/application/management/wbem
- svc:/application/x11/x11-server
- svc:/application/graphical-login/cde-login
- svc:/network/rpc/cde-ttdbserver:tcp
- svc:/network/rpc/cde-calendar-manager
- svc:/application/print/rfc1179:default
SMF property is used to set the Secure by Default behavior or to return the service to its traditional operating mode. In the table below, the property values set when operating in a SBD mode are presented in
bold.
Solaris SBD SMF Properties and Values
| Service | FMRI | Property | Values
|
|---|
| rpcbind | svc:/network/rpc/bind | config/local_only | true, false
|
| syslog | svc:/system/system-log | config/log_from_remote | true, false
|
| sendmail | svc:/network/smtp:sendmail | config/local_only | true, false
|
| smcwebserver | svc:/system/webconsole:console | options/tcp_listen | true, false
|
| wbem | svc:/application/management/wbem | options/tcp_listen | true, false
|
| X11 | svc:/application/x11/x11-server | options/tcp_listen | true, false
|
| CDE | svc:/application/graphical-login/cde-login | dtlogin/args | [null], -udpPort 0
|
| ToolTalk | svc:/network/rpc/cde-ttdbserver:tcp | proto | tcp, ticotsord
|
| Calendar | svc:/network/rpc/cde-calendar-manager | proto | tcp, ticlts
|
| BSD Printing | svc:/application/print/rfc1179:default | bind_addr | [null], localhost
|
Pretty easy, right? So, let's say you were running in a SBD mode (after having run netservices limited) and you find that you want to be able to receive syslog messages from another host. All you would need to do is:
# svccfg -s system-log setprop config/log_from_remote = true
# svcadm refresh system-log
If you wanted this change to take effect immediately, you should also run:
# svcadm restart system-log
Another cool thing about this is that communication is prevented between non-global zones and the global zone since the service is either bound to localhost or simply will not accept external connections:
# ifconfig hme0
hme0: flags=1000843 mtu 1500 index 2
inet 192.168.1.250 netmask ffffff00 broadcast 192.168.1.255
ether 0:0:0:0:0:0
# rpcinfo -p 192.168.1.250
program vers proto port service
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
# zlogin time ifconfig hme0:2
hme0:2: flags=1000843 mtu 1500 index 2
inet 192.168.1.240 netmask ffffff00 broadcast 192.168.1.255
# zlogin time rpcinfo -p 192.168.1.250
rpcinfo: can't contact portmapper: RPC: Authentication error; why = Failed (unspecified error)
Pretty neat! Well, that's all for this installment. Please let me know what you think or if
you have any questions! We love to get feedback and your input is very important to us!
Take care,
Glenn
References:
Part 1 of 3
Part 2 of 3
Technorati Tag:
OpenSolaris
Solaris
security
SMF
SBD
Thursday Jul 13, 2006
For the second installment of Getting to Know - Solaris Secure by Default) (SBD), I would
like to point you to the newly published Secure by Default OpenSolaris project page. In particular, please be sure to check out the very cool design document.
The design document goes a long way toward explaining exactly what was done by the SBD project when it integrated into
Nevada in build 42. It provides a handy quick reference for what changes were made by SBD including the introduction of new service FMRIs, service state (enabled or disabled) as well as any properties that are being used to control service behavior.
So, please give it a look and let us know what you think!
Take care,
Glenn
References:
Part 1 of 3
Part 3 of 3
Technorati Tag:
OpenSolaris
Solaris
security
SMF
SBD
Friday Jun 30, 2006
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
TCP: IPv4
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,
Glenn
References:
Part 2 of 3
Part 3 of 3
Technorati Tag:
OpenSolaris
Solaris
security
SMF
SBD
|
|
|
|
Prasad,
You are absolutely correct. The next v...