Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Background Information

The following sections provide helpful information for understanding security issues involving Sun Fire domains, hardware and software requirements, and other topics. This section contains the following topics:

  • "Assumptions and Limitations"

  • "Obtaining Support"

  • "Default Domain Software and Configurations"

  • "Domain Security Options in SMS 1.2"

  • "Solaris OE Defaults and Modifications"

Assumptions and Limitations

In this article, our recommendations are based on several assumptions and limitations as to what can be done to secure Sun Fire domains.

Our recommendations assume a platform based on the following characteristics:

  • Solaris 8 OE 2/02 (Update 7) software or later

  • System Management Services (SMS) 1.2 software

  • SUNWCall Solaris OE cluster

  • Sun Quad FastEthernet™ card installed in each domain

  • Solaris OE minimization is not discussed in this article, but is supported

Using other software versions and platform characteristics may produce results that vary from those presented in this article.

A Solaris OE configuration hardened to the degree described in this article may not be appropriate for all environments. When installing and hardening a Solaris OE instance, you can perform fewer hardening operations than are recommended. For example, if your environment requires Network File System (NFS)-based services, you can leave them enabled. However, hardening beyond that which is presented in this article should not be performed and is neither recommended, nor supported.

NOTE

Standard security rules apply to hardening Sun Fire domains: That which is not specifically permitted is denied.

Solaris OE hardening can be interpreted in many ways. For purposes of hardening Sun Fire domains, we address hardening all possible Solaris OE options. That is, anything that can be hardened, is hardened. When there are good reasons for leaving services and daemons as they are, we do not harden or modify them.

You can harden Sun Fire domains automatically during a JumpStart™ installation of the operating system (OS), or you can harden it after the installation of the OS. This article documents the process for manually hardening a domain after the OS installation, because addressing the JumpStart environment is beyond the scope of this article.

For information about setting up a JumpStart server and integrating the Solaris Security Toolkit software with a JumpStart server, refer to the following Sun BluePrints OnLine articles:

  • "The Solaris_ Security Toolkit - Quick Start: Updated for version 0.3"

  • "Building a JumpStart™ Infrastructure"

In this article, we do not describe the installation of the Solaris OE 2/02 SUNWCall cluster and do not detail the initial configuration of Sun Fire 12K or 15K domain software. Refer to the product documentation for more information on how to install domain software. Instead, in this article, we focus on the tasks for securing a domain. These tasks include installing security-related software, installing the latest patch clusters, and hardening the OS. This hardening is critical to the security of the domain, because the default configuration of Solaris OE may not provide the required level of security.

NOTE

Although this article focuses on domains built using the SUNWCall Solaris OE installation cluster, using the Solaris OE cluster is not required. Other Solaris OE installation clusters containing fewer packages can be installed on Sun Fire domains. Also, individual packages can be removed from these clusters. Solaris OE minimization is supported on Sun Fire domains just as it is on other Sun systems.

Obtaining Support

Sun Fire 12K and 15K domain configurations implemented by the Solaris Security Toolkit domain driver are Sun supported configurations.

The Solaris Security Toolkit provides an error free, standardized mechanism for performing the hardening process, and it enables you to undo most changes after they are made. Although we do not require that you use the Solaris Security Toolkit to harden domains, we strongly recommend it.

NOTE

Sun supports hardened and minimized domains whether security modifications are performed manually or by using the Solaris Security Toolkit software.

Please note that the Solaris Security Toolkit is not a supported Sun product; only the end-configuration created by the Solaris Security Toolkit is supported. Solaris Security Toolkit support is available through the Sun™ SupportForum discussion group at:

http://www.sun.com/security/jass

Default Domain Software and Configurations

This section describes the default packages, daemons, startup scripts, and other configurations of Sun Fire domains. Although not all of these affect the security of the system directly, from a security perspective, you should always be aware of them and their impact on the system.

Default Packages

The following Sun Fire domain-specific packages are installed as part of the SUNWCall cluster:

system SUNWdrcrx  Dynamic Reconfiguration Modules for Sun Fire 15000 (64-bit)
system SUNWsckmr  Init script & links for Sun Fire 15000 Key Management daemon
system SUNWsckmu  Key Management daemon for Sun Fire 15000
system SUNWsckmx  Key Management Modules for Sun Fire 15000 (64-Bit)

The Sun Fire domain software does not change the /etc/passwd, /etc/shadow, or /etc/group files. This behavior differs from the Sun Fire System Management Services (SMS) software on the system controller (SC), which modifies these files.

Default Daemons

The Sun Fire domain-specific daemons are as follows:

root  11  1 0 17:28:32 ? 0:00 /platform/SUNW,Sun-Fire-15000/lib/cvcd 
root  121 1 0 17:28:46 ? 0:00 /usr/platform/SUNW,Sun-Fire-15000/lib/sckmd

Dynamic Reconfiguration Daemons

Although they are not Sun Fire 12K nor 15K domain-specific, the following daemons are used for dynamic reconfiguration on Sun Fire domains.

Do not disable the following daemons:

root  324   1 0 07:47:24 ?    0:00 /usr/lib/efcode/sparcv9/efdaemon 
root  58    1 0 05:32:57 ?    0:00 /usr/lib/sysevent/syseventd
root  60    1 0 05:32:57 ?    0:00 /usr/lib/sysevent/syseventconfd 
root  65    1 0 05:32:59 ?    0:00 devfsadmd
root  371   1 0 05:33:12 ?    0:00 /usr/lib/saf/sac -t 300
root  631 295 0 16:30:34 ?    0:00 /usr/lib/dcs

Startup Scripts

Sun Fire daemons are started by several startup scripts including the /etc/init.d/cvc and /etc/init.d/sckm scripts.

Domain-to-System Controller Communication

The additional network used on Sun Fire domains to communicate with the Sun Fire system controller (SC) is defined similarly to regular network connections through an /etc/hostname.* entry.

This /etc/hostname.dman0 entry sets up the I1 or domain-to-SC Management Network (MAN). The IP address in our example, 192.168.103.2, is defined for this domain as follows:

# more /etc/hostname.dman0
192.168.103.2 netmask 255.255.255.224 private up

From a security perspective, the network between the domains and the SC, in addition to any network connection between the domains, is of concern. The I1 network mitigates these concerns by permitting only SC-to-domain and domain-to-SC communication.

The I1 network is implemented as separate point-to-point physical network connections between the SCs and each of the 9 domains supported by a Sun Fire 12K system or 18 domains supported by a Sun Fire 15K system. Each of these connections terminates at separate I/O boards on each domain and SC.

On the SCs, these multiple separate networks are consolidated into one meta-interface to simplify administration and management. The MAN driver software performs this consolidation, enforces domain separation, and fail overs to redundant communication paths.

Direct communication between domains over the I1 network is not permitted by the hardware implementation of the I1 network. By implementing the network in this manner, each SC-to-domain network connection is physically isolated from other connections.

The network configuration appears as follows:

dman0: flags=1008843<UP,BROADCAST,RUNNING,MULTICAST,PRIVATE,IPv4> 
mtu 1500 index 2 inet 192.168.103.2 netmask ffffffe0 
broadcast 192.168.103.31 ether 8:0:20:be:f8:f4

CAUTION

Although the dman0 network supports regular Internet Protocol (IP)-based network traffic, it should only be used by Sun Fire management traffic. Any other use of this internal network may affect the reliability, availability, and serviceability (RAS) of the entire platform. Refer to the scman (7D) and dman (7D) man pages for more information.

System Controller-to-Domain Communication

All Sun Fire SC-to-domain communication over the MAN network is authenticated through IPsec. The IPsec protocol suite provides authentication services at the IP layer as defined by the Internet Engineering Task Force (IETF). For additional information about IPsec, refer to RFC 2411 at http://www.ietf.org.

Unauthorized attempts to access Sun Fire domains or SC-specific daemons generate syslog messages indicating that an access attempt was made. The syslog message is generated by IPsec because the request fails the authentication check required for all MAN-based traffic. A log message appears as follows:

Sep 20 08:04:26 sun15-a ip: [ID 993989 kern.error] 
ip_fanout_tcp_listen: Policy Failure for the incoming 
packet (not secure); Source 192.168.181.252, 
Destination 010.001.073.042.

Domain Security Options in SMS 1.2

To improve network performance on the MAN network, sequential MAC addresses are used by default on each of the up to 18 domains. With this configuration, it is straightforward to determine what the MAC address is of any given domain. It is, therefore, possible for a domain to broadcast gratuitous address resolution protocol (ARP) information containing erroneous MAC addresses. The SC accepts these malicious MAC packets and uses them to misroute packets destined for domains. To protect against this type of ARP spoofing attack and other IP-based attacks, two options are available beginning with SMS 1.2:

  • Disable ARP on the I1 MAN network between the SCs and domains.

  • Disable all IP traffic between the SC and a domain by excluding that domain from the SCs MAN driver

Disabling ARP on the MAN network provides some protection against ARP attacks, but it still leaves all other IP functionality present in the I1 network. If more stringent security is required, disabling all IP traffic between the SCs and one or more individual domains on the I1 network may be necessary. Instructions for implementing these two options are provided later in this article.

If a domain is excluded from the MAN network, the domain-to-SC network interface dman0 is not configured at installation time. Even if the dman0 interface is manually configured, the domain cannot communicate with the SC because the domain is excluded from the SC perspective. This solution provides excellent protection for a Sun Fire 12K or 15K chassis against malicious domains attempting to attack either the SC or other domains in the chassis. We recommend this solution for environments that require strongly enforced separation between domains and the SCs.

The Solaris Security Toolkit supports disabling ARP on the I1 MAN network as an option. You can modify a copy of the Sun Fire domain module of the sunfire_15k_domain-secure.driver to use the s15k-static-arp.fin hardening script. This hardening script is not enabled by default.

When all IP traffic between SCs and domains is disabled by the SC configuration, some functionality over the MAN network is not available. The unavailable services are as follows:

  • Dynamic reconfiguration (DR) from the SC: commands such as addboard, removeboard, deleteboard, and rcfgadm cannot be used for domains excluded from the I1 MAN network

  • I1 MAN domain-console access from the SC

  • IP-based services from the SC such as network time protocol (NTP) and JumpStart or Flash-based OS installations

Domain-side DR is available for domains that are excluded from the MAN network. Console access to the domains is available because console traffic can use either the internal I1 MAN network or an Input Output Static Random Access Memory (IOSRAM) based communication path. The IOSRAM interface is totally separate from the TCP/IP based MAN connection. Services using the IOSRAM interface, such as domain booting, remain available even if IP traffic to one or more domains is disabled.

Ultimately, security policy and enterprise application requirements may be the deciding factor as to which option is most suitable. Disabling ARP on the MAN network provides some protection for domains against ARP attacks, but it still leaves all the functionality present in the MAN network. If more stringent security is required, disable all IP traffic between the SCs and one or more individual domains on the MAN network.

To enforce strict separation between a domain and all other domains and SCs in a Sun Fire high-end chassis, we recommend that the domain be excluded from the MAN network. This change can be performed only on the SC. For instructions on how to make these SC modifications, refer to the BluePrint OnLine article titled "Securing Sun Fire 12K and 15K System Controllers: Updated for SMS 1.2."

Solaris OE Defaults and Modifications

The Solaris OE configuration of Sun Fire domains has many of the same issues as other default Solaris OE configurations. For example, too many daemons are used and other insecure daemons are enabled by default. Some insecure daemons include: in.telnetd, in.ftpd, fingered, and sadmind. For a complete list of default Solaris OE daemons and security issues associated with them, refer to the "Solaris Operating Environment Security: Updated for Solaris 8 Operating Environment" Sun BluePrints OnLine article.

Based on the Solaris OE installation cluster (SUNWCall) typically used for Sun Fire domains, almost 100 Solaris OE configuration modifications are recommended to improve the security configuration of the Solaris OE image running on Sun Fire domains.

Implementing these modifications is automated when you use the driver script sunfire_15k_domain-secure.driver available in the Solaris Security Toolkit. An updated version of this driver is available in version 0.3.8 and later of the Solaris Security Toolkit.

Disabling Unused Services

We recommend that you disable all unused services. Reducing services offered by Sun Fire domains to the network decreases the access points available to an intruder. The modifications to secure Sun Fire domains result in reducing the number of TCP, UDP, and RPC services available from a domain.

The security recommendations in this article include all Solaris OE modifications that do not impact required Sun Fire domain functionality. This does not mean these modifications are appropriate for every domain. In fact, it is likely that some of the services disabled by the default sunfire_15k_domain-secure.driver script will affect some applications. Because applications and their service requirements vary, it is unusual for one configuration to work for all applications.

NOTE

A secured configuration must be considered in the context of the application and services provided. The secured configuration implemented in this article is a high-water mark for system security; every service not required is disabled. Using the information in this article, you can determine clearly what can be disabled without adversely affecting the behavior of Sun Fire domains in your environment.

Recommendations and Exceptions

Our recommendations for securing Sun Fire domains follow closely with the hardening described in the "Solaris Operating Environment Security - Updated for Solaris 8 Operating Environment" Sun BluePrints OnLine article.

Solaris Basic Security Module (BSM) is not enabled. The BSM subsystem can be difficult to optimize for appropriate logging levels and produces log files which may be time consuming to interpret. This subsystem should only be enabled at sites where you have the expertise and resources to manage the generation and data reconciliation tasks required to use BSM effectively.

For more information on how to configure BSM, refer to the Sun BluePrint OnLine article titled "Auditing in the Solaris 8 Operating Environment."

Mitigating Security Risks of Solaris OE Services

Detailed descriptions of Solaris OE services and recommendations on how to mitigate their security implications are available in the following BluePrint OnLine articles:

  • "Solaris Operating Environment Security - Updated for the Solaris 8 Operating Environment"

  • "Solaris Operating Environment Network Settings for Security - Updated for Solaris 8"

  • "Solaris Operating Environment Minimization for Security - Updated for Solaris 8"

The recommendations in these articles are implemented with the Solaris Security Toolkit software in standalone and JumpStart modes.

Using Scripts to Perform Modifications

You can implement the recommendations using the Solaris Security Toolkit in either standalone or JumpStart mode. The three drivers used by the Solaris Security Toolkit to harden Sun Fire domains are as follows:

  • sunfire_15k_domain-secure.driver (executes the other drivers)

  • sunfire_15k_domain-config.driver

  • sunfire_15k_domain-hardening.driver

The modifications performed by these drivers are organized into the following categories:

  • Disable
  • Enable
  • Install
  • Remove
  • Set
  • Update

For more detailed information about what each of the scripts do, refer to the Sun BluePrints OnLine article titled "The Solaris Security Toolkit - Internals - Updated for Version 0.3."

In addition to these modifications, the Solaris Security Toolkit copies files from the Solaris Security Toolkit distribution to increase the security of the system. These files are system configuration files that change the default behavior of syslogd, system network parameters, and other Solaris OE options.

The following sections briefly describe the categories and the modifications the scripts within the drivers perform to harden Sun Fire domains. For a complete list of the scripts in the sunfire_15k_domain-secure.driver, refer to the Solaris Security Toolkit Drivers directory.

Disable Scripts

These scripts disable services on the system. Disabled services include the NFS client and server, the automounter, the DHCP server, printing services, and the window manager. The goal of these scripts is to disable all of the services that are not required by the system.

A total of 31 disable scripts are included with the Sun Fire domain-hardening driver. These scripts impose the following modifications to disable all, or part, of the following services and configuration files:

TABLE 1 Scripts Affected By Domain Hardening

apache

lpsched

printd

aspppd

mipagent

rpcbind

automountd

mountd

sendmail

core generation

nfsd

slp

dhcp

nscd

smcboot

dtlogin

pam.conf

snmpdx

IPv6

picld

snmpXdmid

keyservd

pmconfig

syslogd

ldap_cachemgr

lpsched

 


Enable Scripts

These scripts enable the security features that are disabled by default on Solaris OE. These modifications include:

  • Enabling optional logging for syslogd and inetd

  • Requiring NFS clients to use a port number below 1024

  • Enabling process accounting

  • Enabling improved sequence number generation per RFC 1948

  • Enabling optional stack protection and logging

Although some of these services are disabled by the Solaris Security Toolkit, optional security capabilities present are still enabled so that they are used securely if used in the future.

Install Scripts

These scripts create new files to enhance system security. In the Sun Fire driver, the following Solaris OE files are created to enhance the security of the system:

  • An empty /etc/cron.d/at.allow file to restrict access to at commands.

  • An updated /etc/ftpusers file with all system accounts restricts FTP access to the system.

  • An empty /var/adm/loginlog to log unsuccessful login attempts.

  • An updated /etc/shells file to limit which shells can be used by system users.

  • An empty /var/adm/sulog to log su attempts to root.

In addition to creating the preceding files, some install scripts add software to the system. On Sun Fire domains, the following software is installed:

  • Recommended and Security Patch Clusters
  • MD5 software
  • OpenSSH software
  • FixModes software
Remove Scripts

Only one remove script is distributed with the Sun Fire driver; it removes unused Solaris OE system accounts. The accounts that are removed are no longer used by the Solaris OE and can safely be removed. The removed accounts include:

  • smtp
  • nuucp
  • listen
  • nobody4
Set Scripts

These scripts configure the security features of the Solaris OE that are not defined by default. A total of 13 scripts are distributed with the Sun Fire domain driver and can configure the following optional Solaris OE features not enabled by default:

  • root password
  • ftpd banner
  • telnetd banner
  • ftpd UMASK
  • Login RETRIES
  • Power restrictions
  • SUID on removable media
  • System suspend options
  • TMPFS size
  • User password requirements
  • User UMASK
Update Scripts

These scripts update the configuration files that are shipped with the Solaris OE and that do not have all of their security settings properly set. Modifications are made to the following configuration files:

  • at.deny
  • cron.allow
  • cron.deny
  • logchecker
  • inetd.conf

The modifications made to the inetd.conf file include disabling all of the entries the Solaris OE includes in the /etc/inetd.conf file. Disabling these entries turns off all interactive access mechanisms to the domain including Telnet, FTP, and all of the r* services. Console access to the domains is not affected.

  • + Share This
  • 🔖 Save To Your Account