Chapter 1 Oracle VM Server for SPARC Security Overview
Security Features Used by Oracle VM Server for SPARC
Oracle VM Server for SPARC Product Overview
Applying General Security Principles to Oracle VM Server for SPARC
Security in a Virtualized Environment
Securing the Execution Environment
Threat: Unintentional Misconfiguration
Countermeasure: Creating Operational Guidelines
Threat: Errors in the Architecture of the Virtual Environment
Countermeasure: Carefully Assigning Guests to Hardware Platforms
Countermeasure: Planning an Oracle VM Server for SPARC Domain Migration
Countermeasure: Correctly Configuring Virtual Connections
Countermeasure: Using VLAN Tagging
Countermeasure: Using Virtual Security Appliances
Threat: Side Effects of Sharing Resources
Evaluation: Side Effects Through Shared Resources
Countermeasure: Carefully Assigning Hardware Resources
Countermeasure: Carefully Assigning Shared Resources
Summary: Side Effects Through Shared Resources
Threat: Manipulation of the Execution Environment
Evaluation: Manipulation of the Execution Environment
Countermeasure: Securing Interactive Access Paths
Countermeasure: Minimizing the Oracle Solaris OS
Countermeasure: Hardening the Oracle Solaris OS
Countermeasure: Using Role Separation and Application Isolation
Countermeasure: Configuring a Dedicated Management Network
Threat: Breaking the Isolation
Evaluation: Breaking the Isolation
Countermeasure: Validating Firmware and Software Signatures
Countermeasure: Validating Kernel Modules
Threat: Control Domain Denial-of-Service
Evaluation: Control Domain Denial-of-Service
Countermeasure: Securing Console Access
Threat: Unauthorized Use of Configuration Utilities
Evaluation: Unauthorized Use of Configuration Utilities
Countermeasure: Applying the Two-Person Rule
Countermeasure: Using Rights for the Logical Domains Manager
Countermeasure: Hardening the Logical Domains Manager
Countermeasure: Auditing the Logical Domains Manager
Threat: Manipulation of a Service Domain
Evaluation: Manipulation of a Service Domain
Countermeasure: Granularly Segregating Service Domains
Countermeasure: Isolating Service Domains and Guest Domains
Countermeasure: Restricting Access to Virtual Consoles
Threat: Experiencing a Denial-of-Service of an I/O Domain or a Service Domain
Evaluation: Experiencing a Denial-of-Service of an I/O Domain or a Service Domain
Countermeasure: Granularly Configuring I/O Domains
Countermeasure: Configuring Redundant Hardware and Root Domains
Threat: Manipulation of an I/O Domain
Evaluation: Manipulation in an I/O Domain
Countermeasure: Protecting Virtual Disks
Countermeasure: Securing the Guest Domain OS
Chapter 2 Secure Installation and Configuration of Oracle VM Server for SPARC
All current Oracle SPARC systems include a built-in system controller (ILOM), which has the following capabilities:
Manages basic environmental controls such as fan speed and chassis power
Enables firmware upgrades
Provides the system console for the control domain
You can access the ILOM through a serial connection or use SSH, HTTP, HTTPS, SNMP, or IPMI to access it through a network port. The Fujitsu M10 systems use XSCF instead of ILOM to perform similar functions.
An attacker that gains control of the ILOM can compromise the system in many ways, including the following:
Removing power from all running guests
Installing manipulated firmware to gain access to at least one guest domain
These scenarios apply to any system that has such a controller device. In a virtualized environment, the damage can be that much greater than in a physical environment because many domains that are housed in the same system enclosure are at risk.
Likewise, an attacker that gains control over the control domain or an I/O domain can easily disable all dependent guest domains by shutting down the corresponding I/O services.
While the ILOM is usually connected to an administrative network, you can also access the ILOM from the control domain by using IPMI with the BMC access module. As a result, both of these connection types should be well protected and isolated from normal production networks.
Likewise, an attacker can breach a service domain from the network or through an error in the virtualization stack, and then block guest I/O or perform a system shutdown. While the damage is limited as data is neither lost nor compromised, the damage can affect a large number of guest domains. So, ensure that you protect against the possibility of this threat to limit the potential damage.
As the system service processor, the ILOM controls critical features such as chassis power, Oracle VM Server for SPARC startup configurations, and console access to the control domain. The following measures enable you to secure the ILOM:
Placing the ILOM's network port in a network segment that is separate from the administrative network, which is used for the domains in the execution environment.
Disabling all services that are not required for operation, such as HTTP, IPMI, SNMP, HTTPS, and SSH.
Configuring dedicated and personal administrator accounts that grant only the required rights. To maximize accountability of the actions taken by administrators, ensure that you create personal administrator accounts. This type of access is especially important for console access, firmware upgrades, and managing startup configurations.