- Goal
- Background Information
- Securing Sun Fire Domains
- Verifying Domain Hardening
- 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"
"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:
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.