Introduction
Secure Network Operations
Monitor Cisco Security Advisories
Using Authentication, Authorization, and Accounting
Centralize Log Collection and Monitoring
Use of Secure Protocols
Configuration Management
Management Plane
General Management Plane Hardening
Password Management
Password Strength
User Management and Administrative Access
Securing Interactive Management Sessions
Disable Unused Services
Limit Network Access with ACLs on Routers and Firewalls
Control and Encrypt Management Sessions
User Management
Local Users and Passwords
Password Profile
Role-Based Access Control
Authentication Domains
SSL Key Management
Logging Best Practices
Communications
Cisco UCS Manager Web Client
Managing the Equipment
Conclusion
Additional Information
This document provides information to help users secure Cisco Unified Computing System (Cisco UCS) platform devices to improve network security. Structured around the three planes by which the functions of a network device are categorized, this document provides an overview of each Cisco UCS Software feature and references related documentation.
The three functional planes of a network, the management, control, and data planes, each provide a different functionality that must be protected.
The modular, physically, and logically distributed architecture of Cisco UCS offers tremendous advantages in creating a highly available, secured computing platform and network. Discrete software components (subsystems) are implemented as separate software processes that run in their own protected memory address spaces. This implementation enables true fault isolation and compartmentalization in the event of a security incident by preventing faults in one subsystem from negatively affecting others.
The logical distribution of processes across three planes, each with its own access control for secure network operation, is the means to the deep fault isolation and implementation of security instrumentation within Cisco UCS Software and hardware.
Management Plane: The management plane contains the logical group of all traffic that supports provisioning, maintenance, and monitoring functions for the Cisco UCS. Traffic in this group includes, HTTP/HTTPS, SSH, FTP, Simple Network Management Protocol (SNMP), Syslog, TACACS+ and Remote Authentication Dial-In User Service (RADIUS), DNS, and Cisco Discovery Protocol. Management plane traffic is always destined to the local Cisco UCS.
Control Plane: The control plane contains the logical group of all switching, signaling, link-state, and other control protocols that are used to create and maintain the state of the network and interfaces such as Link Layer Discovery Protocol (LLDP), Fiber Channel over Ethernet (FCoE) and Address Resolution Protocol (ARP), and Layer 2 keepalive. Control plane traffic is always destined to the local Cisco UCS device.
Data Plane: The data plane contains the logical group of customer application traffic generated by hosts, clients, servers, and applications that are sourced from and destined to other similar devices supported by the network. Data plane traffic is mainly forwarded in the fast path and is never destined to the local Cisco UCS device.
The security features discussed in this document often provide enough detail for a network administrator (or operator) to configure the feature. However, in cases where it does not, the feature is explained to allow administrators to evaluate whether additional attention to the feature is required. Where possible and appropriate, this document contains recommendations that, if implemented, will help secure a Cisco UCS deployment. Figure 1 shows the structure of a Cisco UCS device.
Figure 1. Cisco UCS Structure
Secure network operations is a substantial topic. Although most of this document is devoted to the secure configuration of a Cisco UCS device, configurations alone do not completely secure a network. The operational procedures in use on the network, as well as the people who administer the network, contribute as much to security as the configuration of the underlying devices.
The following sections contain operational recommendations that Cisco UCS administrators are advised to implement. These sections highlight specific critical areas of network operations and are not comprehensive.
The Cisco Product Security Incident Response Team (PSIRT) creates and maintains publications, commonly referred to as Cisco Security Advisories, for security-related issues in Cisco products. Security advisories are available at http://www.cisco.com/go/psirt.
For information about Cisco PSIRT vulnerability reporting, see the Cisco Security Vulnerability Policy.
To maintain a secure system, Cisco UCS administrators should be aware of the information communicated in Cisco Security Advisories. Detailed knowledge of the vulnerability is required before evaluating the threat that the vulnerability can pose to a network. For assistance with this evaluation process, see Risk Triage for Security Vulnerability Announcements.
The Authentication, Authorization, and Accounting (AAA) framework is vital to securing network devices. The AAA framework provides authentication of management sessions, limits users to specific, administrator-defined commands, and logs all commands entered by all users.
RADIUS and TACACS+ are both supported on the UCS system. TACACS+ encrypts the entire TCP payload, which includes both the username and password. Radius only encrypts the password. Therefore, it is suggested to use TACACS+ for maximum authentication security.
Additionally, LDAP can be used for user authentication. To encrypt the LDAP authentication exchange, use the CLI option to use SSL.
UCS_Server /security/ldap/server # set ssl yes
To gain an understanding of existing, emerging, and historic events that are related to security incidents, an organization should have a unified strategy for event logging and correlation. This strategy must leverage logging from all network devices and use prepackaged and customizable correlation capabilities.
After centralized logging is implemented, a structured approach must be developed to log analysis and incident tracking. Based on the needs of the organization, this approach can range from a simple diligent review of log data to an advanced rule-based analysis.
For more information on how to implement logging on Cisco UCS network devices, see the "Logging Best Practices" section of this guide.
Many protocols are used to carry sensitive network management data. Secure protocols should be used whenever possible. A secure protocol choice includes the use of SSH instead of Telnet so that both authentication data and management information are encrypted.
For more information about the secure management of Cisco UCS, see the "Securing Interactive Management Sessions" section of this document.
Configuration management is a process by which configuration changes are proposed, reviewed, approved, and deployed. In the context of a Cisco UCS, there are configure commit point records for each configuration change. These records can be used to determine what security changes were made and when these changes occurred. In conjunction with AAA log data, this information can assist in the security audit of network devices.
The configuration of a Cisco UCS device contains many sensitive details, including usernames, passwords, and the contents of access control lists (ACLs). The repository used to archive Cisco UCS device configurations should be secured and access should be restricted to only those roles and functions that require access. Insecure access to this information can undermine the security of the entire network.
The management plane consists of functions that achieve the management goals of the network. These goals include interactive management sessions using SSH, as well as statistics gathering with SNMP or NetFlow. When considering the security of a network device, it is critical that the management plane is protected. If a security incident undermines the functions of the management plane, network recovery or stabilization may not be possible.
The following sections detail the security features and configurations available in Cisco UCS Software that help fortify the management plane.
The management plane is used to access, configure, and manage a device, as well as monitor its operations and the network on which it is deployed. The management plane receives and sends traffic for operations of these functions. Both the management plane and control plane of a device must be secured, because operations of the control plane directly affect operations of the management plane. The following list includes protocols that are used by the management plane:
Administrators should take measures to ensure the survival of the management and control planes during security incidents. If one of these planes is successfully exploited, all planes can be compromised.
Passwords control access to resources or devices, and administrators define passwords to authenticate requests. When a request is received for access to a resource or device, the request is challenged for verification of the password and identity, and access can be granted, denied, or limited based on the result. Security best practices dictate that passwords should be managed with an LDAP, TACACS+ or RADIUS authentication server. However, a locally configured password for access is still required in the event that LDAP, TACACS+ or RADIUS services fail. A device can also have other password information present within its configuration, such as an NTP key, a SNMP community string.
The Password Strength option is used to require strong passwords. Ensure Password Strength Check is enabled and do not disable it. The passwords are stored securely on the Cisco UCS using password hashing. Figure 2 shows the configuration settings for locally authenticated users.
Figure 2. Locally Authenticated Users
To determine whether password strength is enabled, issue the show security detail command from the command-line interface (CLI).
UCS-TME-MARS-A# show security detail Security mode: Password Strength Check: Yes Current Task:
The Password Strength option is enabled by default. Strong passwords must meet the following requirements:
Additional password profile options:
Administrators should control access to resources or devices. When a request for access to a resource or device is received, the request is challenged for verification of the password and identity, and access can be granted, denied, or limited based on the result. Cisco UCS Manager Software provides tools to allow for multiple levels of permissions using the concepts of task and user groups. User groups are defined to have access to a certain set of capabilities. Some of these capabilities are debug commands, show commands, and configuration commands. Different user groups have configuration access to different parts of the Cisco UCS.
Managed servers do one-time authentication to the Fabric Interconnect every time a user logs in to the Cisco Integrated Management Controller (CIMC) of the device for accessing like IP-KVM or vMedia. These requests all use the standard role-based access control (RBAC); however, the Intelligent Platform Management Interface (IPMI) user list is downloaded to each blade on startup of the CIMC and registers with the Fabric Interconnect. This user list is separate from the normal RBAC, and IPMI privileges must be assigned separately.
Admin Account
Per Account Properties
For more information on RBAC, see the Configuring Role-Based Access Control guide.
Management sessions allow administrators to view and collect information about a Cisco UCS device and its operations. If this information is disclosed to a malicious user, the device can become the target of an attack or used as a source of additional attacks. Anyone with privileged access to a Cisco UCS device has the capability for full administrative control of the device. It is imperative to secure management sessions to prevent information disclosure and unauthorized access.
As a security best practice, administrators should disable unnecessary services. Most services are disabled by default in Cisco UCS Manager Software; however, these services can be enabled by issuing their respective configuration commands.
Devised to prevent unauthorized direct communication to network devices, infrastructure ACLs (iACL) are a critical security control mechanisms that can be implemented in the network.
An iACL is applied to specify necessary connections between hosts or networks and network devices. Common examples of these types of connections are SMTP, SSH, and SNMP. After the required connections have been permitted, all other traffic to the infrastructure is explicitly denied. All transit traffic that crosses the network and is not destined to infrastructure devices is explicitly permitted.
The protection provided by ACLs is relevant to both the management and control planes. The implementation of ACLs can be made easier with distinct addressing for network infrastructure devices.
The following ACL configuration example illustrates the structure that is required as a basis for starting the ACL implementation process:
In this example, 192.168.10.0 is the trusted source and 192.168.1.1 is the management interface on the Cisco UCS server. The iACL will be attached to a router upstream of the Cisco UCS system.
In this example, the iACL will be implemented on an upstream Cisco IOS router running Cisco IOS Software Release 15.2(1).
ipv4 access-list ACL-INFRASTRUCTURE-IN ! access-list 102 permit tcp 192.168.10.0 0.0.0.255 host 192.168.1.1 any eq 443 access-list 102 permit tcp 192.168.10.0 0.0.0.255 host 192.168.1.1 eq smtp access-list 102 permit tcp 192.168.10.0 0.0.0.255 host 192.168.1.1 eq pop3 access-list 102 permit tcp 192.168.10.0 0.0.0.255 host 192.168.1.1 eq 21 access-list 102 permit tcp 192.168.10.0 0.0.0.255 host 192.168.1.1 eq 20
When created, the iACL must be applied to all interfaces that face non-infrastructure devices, including interfaces that connect to other organizations, remote access segments, user segments, and segments in data centers.
Because information can be disclosed during an interactive management session, traffic must be encrypted so that a malicious user cannot read the data that is being transmitted. Encrypting the traffic allows a secure remote access connection to the device. If the traffic for a management session is sent over the network in plain text, an attacker could obtain sensitive information about the device and the network.
Telnet is not a secure protocol, and administrators of Cisco UCS devices are advised not to use Telnet, but use use SSHv2.
SSHv2 Enabled is enabled by default using TCP port 22. Key strengths options are RSA 768-2048, DSA 1024 with Ciphers of 3des-cbc, aes-128-cbc, aes-192-cbc, aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr, arcfour128, arcfour256, arcfour, blowfish-cbc, cast128-cbc. There can be a 32 maximum of SSHv2 concurrent sessions
Client to Cisco UCS Manager should use SSL3.1 or TLS1.0. The suggested key length is 1024 or higher using a cipher of AES-128 and SHA-1.
The Cisco Internet services process daemon, Cinetd, which is similar to the UNIX daemon, inetd, is a multithreaded server process that is started by the system manager after the system has booted. Cinetd listens on a well-known port on behalf of the server program. When a service request is received on the particular port, Cinetd notifies the server program that is associated with the service request. By default, Cinetd is not configured to listen for any services.
The Telnet service is disabled by default on Cisco UCS devices. If telnet is enabled, issue the disable telnet-server command to disable the Telnet service on a Cisco UCS device.
UCS-A# scope system UCS-A /system # scope services UCS-A /services # disable telnet-server UCS-A /services* # commit-buffer UCS-A /services #
The administrator account is created by default and cannot be deleted. Use a strong password chosen at Cisco UCS Manager installation. The system does not ship with a predefined default password.
Clearing password history requires the user to use new passwords and not reuse old passwords. Users not actively administrating should have their Account Status in a status inactive. Accounts can be set to expire at certain time intervals using the Expire Account Timeframe configuration option. This allows the administrator to selectively expire accounts that may be setup for short durations. Figure 3 shows how to expire the account at a certain date.
Figure 3. Expiration Date
User roles are assigned privileges that define what that user can do on the system. Multiple privileges can be assigned to a single user. Additionally, locales (UCS domains) can be assigned to users to manage different locations.
For locally authenticated accounts, for maximum security, configure SSH for encrypted sessions. There are two public key formats—OpenSSH and SECSH. Both provide good security.
You can limit the number of login sessions each user is permitted to have. It is suggested to limit the session to one.
Password Strength option is used to require strong passwords. Use the Password Strength Option Enabled, which is enabled by default. Strong passwords must meet the following requirements:
Additional password profile options:
Local Authentication is enabled by default. Use SSH for maximum security when accessing the Cisco UCS device. Numerous authentication methods provide enhanced security. There is a maximum of 48 local user accounts. Remote authentication uses LDAP, RADIUS and TACACS+ with a maximum of 16 TACACS+ servers, 16 RADIUS servers, and 16 LDAP providers for a total of 48 providers.
The default (local) authentication and the console authentication can utilize different providers. Furthermore, authentication grouping uses a maximum of 16 groups and a maximum 8 providers per group. The provider authentication ordering method provides flexibility on what providers use and what backups will be in place. The default authentication ports are configurable.
Default roles include AAA, Admin, Facility-manager, Network, Operations, Read-only, Server-equipment, Server-profile, Server-security, and Storage. Additionally, roles can be customized by creating new roles and assigning privileges.
The locales are used to define one or more organizations a user is allowed to access.
Cisco UCS ships with a self-signed certificate using a default 1024 length key pair. To employ a more secure method, use trusted third-party certificates from a trusted source that affirms the identity of the Cisco UCS device.
Event logging provides visibility into the operation of the Cisco UCS device and how it is related to the network. Cisco UCS logging provides flexible logging options. Logging from the Cisco UCS server is done by UDP and is not encrypted. Therefore, administrators should take care in selecting the destination and use encryption to encrypt the transfer of the logs if they are sent to a remote destination over a public or untrusted network.
Fault conditions are logged, cleared, or stored for a configurable interval. When the retention interval field is set, then this configures the length of time the system retains the fault in memory on the Cisco UCS fabric. It can be forever or a set amount of time. Figure 4 shows the Global Fault Policy settings.
Figure 4. Global Fault Policy
Administrators are advised to use the syslog feature to report faults. Up to three destinations can be defined. The severity of the logs is selected with a range from the least severe (emergency) to most severe (debugging).
The system event log (SEL) resides on the CIMC in NVRAM. This log records the most server events including temperature, fan, BIOS, and more. The limit is 40KB in size. When the backup feature is used to send the events to a remote server, the system can be configured to clear the NVRAM log after export. Additionally, the events can be exported using Secure Copy Protocol (SCP) and Secure File Transfer Protocol (SFTP) for more secure transfers.
Unsecured protocols are disabled by default. These include Telnet and HTTP. HTTP requests will be redirected to HTTPS when HTTPS is enabled, which is the default setting.
SNMP is disabled by default. UCS supports SNMP versions 1, 2, and 3. Use SNMPv3 and implement the authPriv method because it provides HMAC-MD5 or HMAC-SHA authentication and data encryption based on DES 56 bit with authentication based on Cipher Block Chaining (DES-56).
Note: Cisco UCS is not able to configure SNMP community strings with ACLs to limit what trusted IP addresses have access to the SNMP services. This filtering should be done on an upstream router or firewall using iACLs.
Serial over LAN (SOL) can be set up to use encryption. Use the CLI to enable the feature.
SSH to the Cisco UCS device and set the encryption to enabled:
UCS_Server# scope kvm UCS_Server/kvm# set encrypted yes UCS/kvm # show detail KVM Settings: Encryption Enabled: yes Max Sessions: 4 Local Video: yes Active Sessions: 0 Enabled: yes KVM Port: 2068
Cisco UCS image transfers should be done using the supported secure transfer methods, SCP or SFTP, even though clear text protocols, FTP and TFTP, are available.
The client accessing the Cisco UCS Manager should use SSL3.1 or TLS1.0. The suggested key length is 2048 or higher using a cipher of AES-128 and SHA-1.
The web client will automatically reconnect after a break in communications to the Cisco UCS Manager. The Cisco UCS Manager has a web session refresh period and a web session timeout period. The web session refresh period kicks off when the client becomes inactive for 600 seconds, which is the default setting. The session is considered inactive, but the session is not terminated. A web session timeout period should be used to terminate these stale sessions. The default is 7200 seconds.
The login banner should be used to properly identify the system. It should provide a definitive warning to anyone accessing the system that illegal activities may not be performed and will be reported to law enforcement. Important elements of a login banner include the following notices:
Web session limits are configurable for the entire system and per user. The default for the system is 256 and 256 for each user. It is suggested to have a limit on the number of user sessions (1–2) and a limit for the maximum amount of connections for the total system based on how many users there are. You do not want one user to be able to take complete control of access to the system.
The SEL resides on the CIMC in NVRAM. It records physical events and is mainly used for troubleshooting hardware issues. Administrators should use SCP or SFTP to transfer the log entries to a secure storage device and use the option to clear the SEL after the transfer is complete.
IPMI allows administrators to access system hardware, control system components, and retrieve logs. IPMI operates independently of the CIMC operating system. The admin account has full access to the baseboard management controller (BMI) where the read-only account is only able to view the configurations. For the standalone C-Series, there are three user privileges: admin, user, and read-only. Admin is the equivalent of IPMI administrator. User is the equivalent of IPMI operator, and a read-only user is the lowest IPMI privilege level.
Suggested best practices:
In addition, use Serial over LAN Policy. The virtual console emulates direct keyboard, video, and mouse (KVM) to the server. The service uses self-signed certificates so the user must allow an exception for the certificate in the browser cache. The default, and only, access protocol is HTTPS. KVM management is encrypted using RC4 and should not be disabled.
There are also front panel security options in the BIOS setup:
Figure 5. USB Non Bootable
This document provides methods to harden Cisco UCS features. We focused on the management plane with hardening techniques that highlight securing user access through the UCS client manager and using strong encryption methods. Furthermore, provided techniques on secure logging techniques dealing with nvram logging and using the system event log. Implementing the hardening best practices discussed in this document will increase the security of the UCS system thus increasing overall security to the network the UCS is located in.
Cisco Unified Computing System
//www.cisco.com/c/en/us/products/servers-unified-computing/index.html
Cisco UCS Manager CLI Configuration Guide, Release 2.0
//www.cisco.com/en/US/docs/unified_computing/ucs/sw/cli/config/guide/2.0/b_UCSM_CLI_Configuration_Guide_2_0.html
Open Source Used in UCS 2.0(1)
//www.cisco.com/en/US/docs/unified_computing/ucs/3rd-party/UCS_2_0_1_Open_Source_Documentation.pdf
IPMI Security Vulnerabilities
//www.cisco.com/web/about/security/intelligence/IPMI_security.html
Common Criteria EAL4 Certification (Applies to UCS 1.4x, 2.x Certification in Progress)
http://www.niap-ccevs.org/cc-scheme/st/vid10403/
Cisco Security Advisories
https://sec.cloudapps.cisco.com/security/center/publicationListing.x
Cisco Guide to Harden Cisco IOS Devices
//www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
Cisco Guide to Securing Cisco NX-OS Software Devices
http://www.cisco.com/c/en/us/about/security-center/securing-nx-os.html
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.