Friday Feb 13, 2009

Solaris Security Chat in SecondLife

Virtual Glenn is a pretty strange concept, but for those who can move past it, check this out! This is a picture of my SecondLife avatar in front of the Solaris Campus stage. On February 24th, 2009 at 9 AM PT / 12 PM ET, I will be participating in an expert chat that will be loosely based around my blog article titled Top 5 Solaris 10 Security Features You Should Be Using. I will be talking a bit about each of the five items as well as answering questions. In total, the event will last about an hour and should be a lot of fun (assuming I can overcome being a SecondLife n00b!)

This will be my first presentation inside of a virtual world, and I would encourage anyone who is interested to get a login, a copy of the client, and join me on the 24th to have a little fun a world away. For more information, check out the Sun Virtual Worlds posting for the event! Hope to see you there!

Wednesday Aug 23, 2006

New Solaris Secure by Default Presentation



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:

Wednesday Jul 19, 2006

Solaris Secure by Default - Part 3



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
ServiceFMRIPropertyValues
rpcbindsvc:/network/rpc/bindconfig/local_onlytrue, false
syslogsvc:/system/system-logconfig/log_from_remotetrue, false
sendmailsvc:/network/smtp:sendmailconfig/local_onlytrue, false
smcwebserversvc:/system/webconsole:consoleoptions/tcp_listentrue, false
wbemsvc:/application/management/wbemoptions/tcp_listentrue, false
X11svc:/application/x11/x11-serveroptions/tcp_listentrue, false
CDEsvc:/application/graphical-login/cde-logindtlogin/args[null], -udpPort 0
ToolTalksvc:/network/rpc/cde-ttdbserver:tcpprototcp, ticotsord
Calendarsvc:/network/rpc/cde-calendar-managerprototcp, ticlts
BSD Printingsvc:/application/print/rfc1179:defaultbind_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:

Thursday Jul 13, 2006

Solaris Secure by Default - Part 2



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:

Friday Jun 30, 2006

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

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:

About

gbrunett

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today