- Goal
- Background Information
- Securing Sun Fire Domains
- Verifying Domain Hardening
- About the Authors
- Related Resources
Like this article? We recommend
Like this article? We recommend
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" on page 3
"Obtaining Support" on page 5
"Default Domain Software and Configurations" on page 5
"Domain Security Options in SMS 1.3" on page 8
"Solaris OE Defaults and Modifications" on page 10
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 newer
System Management Services (SMS) 1.3 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
NOTE
The examples in this article are for a domain running Solaris 9 OE.
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 a JumpStart server with the Solaris Security Toolkit software, refer to the Sun BluePrints OnLine article "Building a JumpStart™ Infrastructure" or to the Solaris Security Toolkit documentation.
In this article, we do not describe the installation of the Solaris 9 OE, installation of the SUNWCall cluster, and 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 this 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 SCs, 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 fails over 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, serviceability, and security (RASS) 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.
The configuration of IPsec on the domain is maintained in the /etc/inet/ipsecinit.conf file, which, by default, contains at least the following entries requiring that all communication to the domain-side daemons be authenticated using IPsec:
{ dport sun-dr ulp tcp } permit { auth_algs md5 }
{ sport sun-dr ulp tcp } apply { auth_algs md5 sa unique }
{ dport cvc_hostd ulp tcp } permit { auth_algs md5 }
{ sport cvc_hostd ulp tcp } apply { auth_algs md5 sa unique }
For more detailed information on this file, refer to the ipsecconf(1m) man page.
Domain Security Options in SMS 1.3
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 in SMS 1.3:
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
The use of showdevices, from the SC, to display devices associated with domains
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."
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 Sun BluePrints OnLine article titled "Solaris Operating Environment Security: Updated for Solaris 9 Operating Environment."
Based on the Solaris OE installation cluster (SUNWCall) typically used for Sun Fire domains, over 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 the Solaris Security Toolkit version 0.3.11 and newer.
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 Sun BluePrints OnLine article titled "Solaris Operating Environment Security, Updated for Solaris 9 Operating Environment."
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 security implications are available in the following BluePrint OnLine articles:
"Solaris Operating Environment Security, Updated for the Solaris 9 Operating Environment"
"Solaris Operating Environment Network Settings for Security, Updated for Solaris 8"
"Minimizing the Solaris Operating Environment for Security, Updated for Solaris 9"
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 each of the scripts used to harden domains, refer to the sunfire_15K-domain drivers mentioned previously or the Solaris Security Toolkit documentation available from: