Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Securing the System Controller
When the platform and domains of the SC are configured, make sure to configure them securely. Some of the tasks are performed by the platform administrator, while others are performed by the appropriate domain administrator.
This article focuses on the SC configuration changes required to secure the SC. Normal administrative issues are addressed only when they are impacted by a security modification. For full details on configuring the SC, refer to the system controller publications listed in "Related Resources" on page 58.
NOTE
Implement the security modifications immediately after the Sun Fire RTOS and SC application has been flashed with the latest firmware updates and before any Sun Fire domains are configured or installed.
Always use the most recent updates available from SUNSOLVE ONLINE Web site.
Securing the SC consists of performing the following tasks:
"Configuring Platform Administrator Settings"
"Rebooting the SC to Implement Settings"
"Configuring Domain Administrator Settings"
CAUTION
We recommend that you disable the SC failover mechanism before hardening the SCs. Re-enable failover only after you harden and test the entire configuration.
Configuring Platform Administrator Settings
Most of the platform administrator setting configurations are performed through the setupplatform command. You can run this command either in an interactive mode where it asks specific questions or a non-interactive mode by specifying the configuration modification required. For the purposes of this article, we run the command in non-interactive mode by using the -p option.
To secure the SC, perform the following tasks:
- "Configure Network Settings"
- "Configure the Platform Loghost"
- "Define Platform Password"
- "Define Domain Password"
- "Choose Method for Managing Networked Devices"
- "Use the SNTP Default Configuration"
- "Define Hardware Access Control Lists (ACLs)"
- "Configure Telnet"
Configure Network Settings
The first task in setting up an SC is to enable networking. This task defines whether the system uses dynamic or static IP addresses, what its hostname is, its IP address, DNS server, and other network information.
In this secured topology, we use static IP addresses. Dynamic host configuration protocol (DHCP) is certainly an option and a DHCP server could be set up and populated with the appropriate MAC and hostname information for the SCs on the MSP. However, the effort required to set up and manage the DHCP server is appropriate only if there are many SCs to configure.
If you use DHCP, configure the DHCP server to provide services only for the private SC network and no other network segments.
All network traffic to the SC is routed through the MSP. Because IP forwarding is not enabled on the MSP, all the packets must be proxied through the MSP. As an additional security measure, this practice allows us to not specify a default router on the SC.
For network-based name resolution, the SC requires a DNS server. In this secured environment, this requirement is not necessary, because the only system the SC communicates with is the MSP. Consequently, no DNS server information is entered while configuring the SC.
We used the following command to enter the changes on the SC:
sc0:SC> setupplatform -p network Network Configuration --------------------- Is the system controller on a network? [yes]: yes Use DHCP or static network settings? [dhcp]: static Hostname [unknown]: ds7-sc0 IP Address [0.0.0.0]: 192.168.100.20 Netmask [0.0.0.0]: 255.255.255.0 Gateway [0.0.0.0]: DNS Domain [none]: none Primary DNS Server [0.0.0.0]: Secondary DNS Server [0.0.0.0]: Rebooting the SC is required for changes in network settings to take effect.
Configure the Platform Loghost
The next task in configuring the SC is to configure the platform loghost to which all SYSLOG messages are forwarded. The SC has no local disk, so it cannot store these messages locally. They must be forwarded to a central location for storage, reconciliation, and review (for unusual activity). If DNS is not being used, you must take care to define the loghost through the IP addresses. In our example, DNS is not being used, so we enter the IP address.
In addition to specifying the name/IP address of the loghost, the facility level included in the SYSLOG messages can be specified. The SYSLOG protocol provides eight user-defined facility levels: local0 through local7, in addition to the 18 system-defined facilities. However, only the user-defined facility levels can be used while customizing the SC's SYSLOG behavior.
All SC generated SYSLOG messages come from the same IP address—that of the SC. The different SYSLOG facilities must be used to distinguish between messages originated from the platform and each domain. For example, the platform would use the SYSLOG facility local0, while domain-a would use the SYSLOG facility local1, and so on.
The MSP is functioning as the SYSLOG server, so we enter its IP address in the following manner with the corresponding SYSLOG facility level (local0) for the platform:
ds7-sc0:SC> setupplatform -p loghost Loghosts -------- Loghost [ ]: 192.168.100.10 Log Facility [local0]: local0
Details on how to configure the SYSLOG service on the MSP are provided in "Configuring the MSP SYSLOG" on page 43.
Use the showplatform command to display the loghost and log facility for the platform:
ds7-sc0:SC> showplatform -p loghost Loghost for Platform: 192.168.100.10 Log Facility for Platform: local0
Define Platform Password
The next task is to set the platform password. The only restrictions on SC platform and domain passwords are the character set supported by ASCII and the terminal emulator in use. The SC uses the MD5 software to generate a hash of the password entered. Correspondingly, all characters entered are significant.
A minimum password length of 16 characters is recommended to promote the use of pass-phrases instead of passwords. Passwords should be comprised of at least lowercase, uppercase, numeric, and punctuation marks. Given the capabilities of current systems to either brute-force access or guess encrypted passwords, an eight character length string is no longer secure.
The following command sets the platform shell password:
ds7-sc0:SC> password Enter new password: xxxxxxxxxxxxxxxx Enter new password again: xxxxxxxxxxxxxxxx
NOTE
If a platform administrator's password is lost, refer to "Resetting a Platform Administrator's Lost Password" on page 53.
Define Domain Password
A domain shell is always present for a domain, whether any hardware is assigned to that domain. To avoid potential unauthorized reallocation of hardware to an unused domain, define passwords for all domain shells.
The passwords for each domain should be different from each other, the platform shell, and the Solaris OE images running on the domains. A reliable and secure method of password management is recommended to track all these passwords.
With the release of SCapp 5.13, the platform shell can reset domain passwords. Prior to this release, the only supported method to reset domain password was the setdefaults command.
You can set a domain's password from either the shell of the domain or the platform shell with the password command. As with the platform password, a minimum password length should be 16 mixed-case alphanumeric characters.
The following command sets the password of domain-a from the platform shell:
ds7-sc0:SC> password -d a Enter new password: xxxxxxxxxxxxxxxx Enter new password again: xxxxxxxxxxxxxxxx
NOTE
All domain shells should have passwords set—regardless of whether they are used and have hardware assigned.
The same command, with the appropriate domain name, sets the passwords for domains b through d.
If a password was defined for either a platform or domain shell, the password command requires its entry before allowing a new password to be entered. The only exception to this is that the platform administrator can change a domain password without knowing the old password with the release of 5.13 as follows:
ds7-sc0:SC> console d Enter Password: Connected to Domain D Domain Shell for Domain D ds76-sc0:D> disc Connection closed. ds7-sc0:SC> password -d d Enter new password: Enter new password again:
Choose Method for Managing Networked Devices
Simple Network Management Protocol (SNMP) is commonly used to monitor and manage networked devices and systems. Early versions of SNMP, such as SNMPv1 and SNMPv2, suffer from security issues because they don't address issues such as authentication, data integrity checks, and encryption. Updated versions of the protocol are proposed, such as SNMPv2usec and SNMPv3, yet are not fully approved by the IETF, the organization that controls these standards. For more information, refer to "Related Resources" on page 58.
While the full specification of SNMPv2usec does address many of the limitations of the SNMPv1 and v2 protocols, certain components of SNMPv2usec (such as encryption for privacy) are optional and not required for SNMPv2usec compatibility.
The Sun Fire SC only supports the use of SNMPv1. Due to this limitation, we make the following recommendations for choosing a method of monitoring and managing networked devices.
Using Sun Management Center Software
You can use Sun_ Management Center 3.0 (Sun MC) software to manage and maintain your Sun Fire midframe systems. To use Sun MC 3.0 securely, we recommend, in addition to using SNMPv2usec capabilities, that you isolate all of its management traffic to a physically isolated and dedicated management network. This recommendation is based on the network segmentation recommendations presented in the Sun BluePrints OnLine article titled Building Secure N-Tier Environments.
Sun MC requires platform agent software to manage the Sun Fire midframe SC. We recommend that you install the software on either the Sun MC server or a separate server. Do not connect the system to the public intranet. Limit access to the platform agent software by not installing it on the MSP.
If isolating the Sun MC server to a completely separate and isolated network is not possible, then install the platform agent software on a separate system. This server requires at least two network interfaces. One connects to the private SC network and the other connects to a private management network, connecting it to the Sun MC server.
Regardless of where the platform agent software is installed, the entire network from the SC to the Sun MC server must be a physically separated and dedicated network. Harden and secure all additional servers, including the Sun MC server.
Disabling SMNP
The alternative is to disable SNMP on the SC and not use any SNMP-based management products. This option provides protection against all possible SNMP-based attacks. It should be noted, however, that disabling these services on the SC prevents SNMP-based management tools from managing the SunFire SC.
Disable the SNMP daemon on the SC as follows:
ds7-sc0:SC> setupplatform -p snmp SNMP ---- Platform Description [Serengeti-24 P1.2]: Platform Contact [ppb]: Platform Location []: Enable SNMP Agent? [yes]: no May 16 20:59:36 ds7-sc0 Chassis-Port.SC: Stopping SNMP agent.
Use the SNTP Default Configuration
The default SC configuration for SNTP is off, and we recommend that you configure it to on, so that you can use SNTP.
Simple Network Time Protocol (SNTP), described in RFC 2030, is an adaptation of the Network Time Protocol (NTP), described in RFC 1305, and is used to synchronize computer clocks. SNTP does not change the NTP specification; rather it clarifies certain design features of NTP to allow operation in a simple, stateless remote-procedure call (RPC) mode. SNTP clients such as the Sun Fire midframe SC can interoperate with existing NTP or SNTP clients and servers. SNTP is intended to be used only at the extremities of the time synchronization subnet.
A full description of how to architect and implement a time synchronization subnet is out of the scope of this document. We recommend that you understand the concepts described in the following Sun BluePrints OnLine articles:
Using NTP to control and Synchronize System Clocks - Part I: Introduction to NTP
Using NTP to control and Synchronize System Clocks - Part II: Basic NTP Administration and Architecture
Using NTP to Control and Synchronize System Clocks - Part III: NTP Monitoring and Troubleshooting
If configured for SNTP, the SC sends a request to a designated SNTP or NTP unicast server and expects a reply from that server. The SC does not implement the optional authentication method specified in RFC 1305. The SC neither accepts remote administration commands via SNTP, nor does it accept any broadcast traffic.
Because the SC SNTP client uses port 123 UDP without authentication, it is not difficult to spoof the designated NTP or SNTP server; therefore, the SC is vulnerable to a port 123 DoS attack.
The use of RPC-based SNTP introduces another reason why the SCs must be isolated to a physically separate network. We recommend that the MSP be used as the SNTP server for the SC. However, it is important that the MSP be configured to secure its NTP traffic as described in the previously mentioned Sun BluePrints OnLine articles.
The configuration and operation of the SC for failover is not within the scope of this article. If you want to configure the SC for failover, then we recommend that you use SNTP for synchronization of the system clocks. For details, refer to the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
Define Hardware Access Control Lists (ACLs)
This task applies and is important only if the Sun Fire server has multiple domains and their resources are restricted in some way. Only when these conditions are present should ACLs be implemented.
By default, all hardware present in the system is accessible to all domains. In our example, a Sun Fire 6800 server is divided into three domains—where each domain has one CPU and I/O board.
Use the platform administrator shell to assign the different CPU and I/O boards into the appropriate domains.
NOTE
ACLs only limit hardware assignments made while using the domain shells. Hardware assignments made while using the platform shell supersede all ACL definitions.
The capability of the platform shell to assign and reassign hardware components is not restricted by ACLs. We recommend that the platform administrator account be used initially only to assign hardware components to the appropriate domain. After hardware components are assigned to each domain, the administrators should log into the appropriate domain shell account to manage the hardware assigned to that domain. The remainder of this section provides a sample implementation of our recommendations.
First, we use the following command to determine which boards are present:
ds7-sc0:SC> showboard Slot Pwr Component Type State Status ---- -- ------------- ---- ----- SB0 On CPU Board Available Passed SB2 On CPU Board Available Passed SB3 On CPU Board Available Passed IB6 On PCI I/O Board Available Passed IB7 On PCI I/O Board Available Passed IB8 On PCI I/O Board Available Passed
We view the current set of ACLs defined on the system with the following commands:
ds7-sc0:SC> showplatform -p acl ACL for Domain A: SB0 SB2 SB3 IB6 IB7 IB8 ACL for Domain B: SB0 SB2 SB3 IB6 IB7 IB8 ACL for Domain C: SB0 SB2 SB3 IB6 IB7 IB8 ACL for Domain D: SB0 SB2 SB3 IB6 IB7 IB8
We assign the resources to the appropriate domains with the following commands:
ds7-sc0:SC> addboard -d a SB0 IB6 ds7-sc0:SC> addboard -d b SB2 IB8 ds7-sc0:SC> addboard -d c SB3 IB7
We use the showboard command to produce the following output:
ds7-sc0:SC> showboard Slot Pwr Component Type State Status Domain ---- -- ------------- ---- ----- ------ /N0/SB0 On CPU Board Assigned Passed A /N0/SB2 On CPU Board Assigned Passed B /N0/SB3 On CPU Board Assigned Passed C /N0/IB6 On PCI I/O Board Assigned Passed A /N0/IB7 On PCI I/O Board Assigned Passed C /N0/IB8 On PCI I/O Board Assigned Passed B
As a final verification, we check the output from setupplatform and showplatform commands, which appears as follows for our example:
ds7-sc0:SC> setupplatform -p acl ACLs ---- ACL for domain A [ SB0 SB2 SB3 IB6 IB7 IB8 ]: sb0 ib6 ACL for domain B [ SB0 SB2 SB3 IB6 IB7 IB8 ]: sb2 ib8 ACL for domain C [ SB0 SB2 SB3 IB6 IB7 IB8 ]: sb3 ib7 ACL for domain D [ SB0 SB2 SB3 IB6 IB7 IB8 ]: ds7-sc0:SC> showplatform -p acl ACL for Domain A: SB0 IB6 ACL for Domain B: SB2 IB8 ACL for Domain C: SB3 IB7 ACL for Domain D:
Now three domains, a through c, are defined on our Sun Fire server; each with one CPU and I/O board.
NOTE
Although a platform administrator can assign hardware into specific domains, it is up to domain administrators to use those resources appropriately and determine whether those resources are configured into a running domain.
Hardware already assigned to a running domain is not removed if its ACL is modified to restrict it from being used in that domain. Therefore, it is important to assign hardware into domains as soon as it is available in the chassis and before domain administrators assign it.
Configure Telnet
The Telnet service on the SC is enabled by default. You can define the session idle timeout period that applies to all Telnet connections to the SC. The default is no session idle timeout period. The Telnet configuration does not affect the operation of the platform console.
Based on the configuration in this article, we recommend that Telnet timeouts be enabled to a value appropriate for your organization. This practice allows Telnet sessions to be established from the MSP. Refer to the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual for details on how to configure Telnet timeouts.
If the SC is on a general purpose network, then we recommend that you disable the Telnet service and restrict access to SSH-enabled terminal server access.
To disable the Telnet service, use the setupplatform -p security command as follows:
ds7-sc0:SC> settupplatform -p security Security Options ---------------- Enable telnet servers? [yes]: no Idle connection timeout (in minutes; 0 means no timeout) [0]: ds7-sc0:SC>
For additional instructions, refer to the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
Rebooting the SC to Implement Settings
If needed, reboot the SC to implement your configuration settings. The SC has to be rebooted only if a console message similar to the following is displayed:
Rebooting the SC is required for changes in network settings to take effect.
To reboot the SC, enter the following command from the platform shell:
ds7-sc0:SC> reboot -y
NOTE
The SC can be rebooted while domains are up and running.
After rebooting the SC, use the showplatform command to validate that all the modifications are implemented.
Configuring Domain Administrator Settings
After all of the platform shell configuration modifications are made, implement the domain-specific configuration modifications. Most of the recommended changes are performed using the platform shell.
Only a few domain-specific changes require using domain shells. These modifications are as follows:
Setting the Loghost and facility for each domain
Setting the SNMP information
Each of these must be defined individually for each domain. The following samples show these changes for domain-a.
Define a Loghost
You must define a Loghost for each of the domains individually. The configuration is similar to that in the "Configure the Platform Loghost" on page 15. In addition, we recommend that you use a facility unique to the frame. By having separate definitions of Loghost for each domain and platform shell, you can use separate SYSLOG servers to collect information. In this secured network environment, only one system collects and parses the SYSLOG data—the MSP. The facility option helps differentiate SYSLOG messages coming from the four different domains and platform shells.
Before using the setupdomain command to define the Loghost for each domain, log into the appropriate domain shell.
We perform the following to set our example domain-a shell Loghost to be the MSP:
ds7-sc0:A> setupdomain -p loghost Loghosts -------- Loghost [ ]: 192.168.100.10 Log Facility for Domain A: local1
In our example, the Loghost definition defines a facility of local1. Previously, the platform shell used local0. This example is specific to domain-a. Correspondingly, domain-b uses local2, domain-c uses local3, and domain-d uses local4.
NOTE
The domain shell definition of Loghost has no effect on where the SYSLOG messages generated by a Solaris OE image running on that domain are forwarded. Define the Solaris OE SYSLOG server in the /etc/syslog.conf configuration file of the Solaris OE.
For information about how to configure the SYSLOG service on the MSP, refer to "Configuring the MSP SYSLOG" on page 43.
Use the showdomain command to display the Loghost and Log Facility for the domain:
ds7-sc0:A> showdomain -p loghost Loghost for Domain A: 192.168.100.10 Log Facility for Domain A: local1
Configure Domain SNMP Information
Each domain has unique SNMP configurations that must be configured separately. Some of the domain SNMP information can be the same (for example, domain contact and trap host); however, the public and private community strings must be different for each domain. Different public and private community strings are required so that each domain can be accessed separately. The two community strings provide the mechanism by which individual domains are accessed.
In our secured configuration, the SNMP daemon was disabled in the platform shell. Correspondingly, it is unnecessary to set the public and private community strings, because we are not using SNMP.
If SNMP management or monitoring is used, then non-default SNMP community strings must be selected.
Configure Domain setkeyswitch
The setkeyswitch command provides functionality similar to the physical key setting on the Sun Enterprise server line. When a Sun Enterprise server is functioning, the keyswitch should be in the secure setting. With a Sun Fire server, there is no physical key to turn, so this functionality is provided with the setkeyswitch command from the platform and domain shells.
The recommended setkeyswitch setting for a running domain is secure. This setting is very similar to the setkeyswitch on position, with a few additional restrictions. Most importantly, in the secure setting, the ability to flash update the CPU/Memory and I/O boards is disabled. Flash updating these boards should only be done by an administrator who has domain shell access on the SC. If the administrator has domain shell access, then using setkeyswitch to change from secure to on is straightforward. Administrators without domain and/or platform access cannot perform this command.
We use the following command to set our example domain-a into secure mode:
ds7-sc0:A> setkeyswitch secure
You can disable two other Sun Fire domain features by using the setkeyswitch secure option. When a domain is running in secure mode, it ignores break and reset commands from the SC. This practice is not only an excellent precaution from a security perspective, it also ensures that an accidently issued break or reset command does not halt a running domain.
Restricting SC OS Access
Some organizations have security policies that require a high degree of protection against the risk of improper access to the RTOS. Where such a requirement exists, you can use the write-protect jumper to provide protection. For more information about the jumper, refer to "Write-Protect Jumper" on page 9.
Although the jumper provides a higher degree of protection, be advised that using it requires additional maintenance effort. When updates are required for the RTOS, a qualified, trained person must power down the system and remove the SC to change the jumper configuration both before and after the RTOS update.
In configurations with a single SC, this task results in platform downtime. For this reason, we recommend that the platform be configured with a redundant SC, using the SC failover feature to avoid Sun Fire frame downtime.
For more details about configuring the SC failover feature, refer to the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
During an RTOS update, while the EPROM is not write-protected, appropriate measures must be taken to avoid unauthorized access to the console serial port.