Reference Guide
Table Of Contents
- iDRAC9 Security Configuration Guide
- 1 Overview of iDRAC9 Security Configuration Guide
- 2 Built in iDRAC and PowerEdge Security
- 2.1 Silicon-based Root-of-Trust
- 2.1.1 Let us look at the chain of trust in more detail. Each BIOS module contains a hash of the next module in the chain. The key modules in BIOS are the IBB (Initial Boot Block), SEC (Security), PEI (Pre-EFI Initialization), MRC (Memory Reference Cod...
- 2.1.2 Also, AMD Secure Run Technology is designed to encrypt main memory, keeping it private from malicious intruders having access to the hardware. No application modifications are needed to use this feature, and the security processor never exposes ...
- 2.2 Cryptographically Verified Trusted Booting
- 2.3 SELinux
- 2.4 Signed Firmware Updates
- 2.5 Non-Root Support
- 2.6 iDRAC Credential Vault
- 2.7 BIOS Recovery and Hardware Root of Trust (RoT)
- 2.8 Live Scanning
- 2.1 Silicon-based Root-of-Trust
- 3 Securely Configuring iDRAC Web Server
- 4 Securely Using TLS/SSL Certificate
- 5 Federal Information Processing Standards (FIPS)
- 6 Secure Shell (SSH)
- 7 Network Security Configuration
- 8 Interfaces and Protocols to Access iDRAC
- 9 iDRAC Port Configuration
- 10 IPMI and SNMP Security Best Practices
- 11 Secure Enterprise Key Manager (SEKM) Security
- 12 iDRAC9 Group Manager
- 13 Virtual Console and Virtual Media Security
- 14 VNC Security
- 15 User Configuration and Access Control
- 15.1 Configuring Local Users
- 15.2 Disabling Access to Modify iDRAC Configuration Settings on Host System
- 15.3 iDRAC User Roles and Privileges
- 15.4 Recommended Characters in Usernames and Passwords
- 15.5 Password Policy
- 15.6 Secure Default Password
- 15.7 Changing the Default Login Password using Web Interface
- 15.8 Force Change of Password (FCP)
- 15.9 Simple 2-Factor Authentication (Simple 2FA)
- 15.10 RSA SecurID Two Factor Authentication (2FA) iDRAC9 Datacenter
- 15.11 Active Directory
- 15.12 LDAP
- 15.13 Customizable Security Banner
- 16 System Lockdown Mode
- 17 Securely Configuring BIOS System Security
- 18 Secure Boot Configuration
- 19 Securely Erasing Data
- 20 LCD Panel
- 21 Server Inventory, Lifecycle Log, Server Profiles, and Licenses Import and Export
- 22 Security Events Lifecycle Log
- 23 Default Configuration Values
- 24
- 25 Network Vulnerability Scanning
- 26 Security Licensing
- 27 Best Practices
- 28 Appendix - Whitepapers
25
MD5 and SHA1 are the most commonly used key types, since they meet basic security and provides time accuracy in millisecond
level with timeservers within the company infrastructure. In theory, any encryption type that is supported by openssl can be used
for symmetric keys, but higher encryption can result in high CPU usage and high latency in processing the time data.
Secure NTP Configuration
iDRAC group and property name to enable NTP is “NTPConfigGroup.NTPEnable”. When this property is set to “Enabled”, iDRAC
uses the properties NTP1, NTP2, NTP3 to set up to three timeserver FQDN or IP addresses (IPv4 or IPv6).
The new addition in iDRAC NTPConfigGroup to support secure NTP are:
1. NTP1SecurityType
2. NTP1SecurityKeyNumber
3. NTP1SecurityKey
4. NTP2SecurityType
5. NTP2SecurityKeyNumber
6. NTP2SecurityKey
7. NTP3SecurityType
8. NTP3SecurityKeyNumber
9. NTP3SecurityKey
• SecurityType is an enumeration with options Disabled, MD5, SHA1. Higher encryption options could be supported in the
future.
• SecurityKeyNumber is a number between 1 to 65534. It should be the same key number that is used in the NTP server
corresponding to the selected key.
• SecurityKey - The key is a hex-encoded ASCII string of up to 40 characters.
The key number, type and key value should match in the NTP server and iDRAC, for secure NTP to work.
The NTP configuration has a limitation that the key numbers must be unique. Hence NTP1SecurityKeyNumber,
NTP2SecurityKeyNumber and NTP3SecurityKeyNumber should be different values. This limitation comes from open-source ntpd
code usage on iDRAC, even though in theory, different NTP servers could issue the same key number. If the same key number is
repeated in a configuration, the second instance of the key number is ignored.
Even though iDRAC can support up to three secure NTP server addresses, Dell guidance is to use only one secure NTP server
and leave the other two entries that are not populated for best iDRAC performance. It is a common practice to use multiple
timeservers when using plain unencrypted NTP, however the present secure NTP installations mostly use a single secure NTP
server.
iDRAC allows mixing secure and unsecure NTP servers in the configuration. However, this is not advised, since unencrypted NTP
packets always become the primary NTP source, with the current ntpd implementation.
For security reasons, the SecurityKey attribute is write-only. If SecurityType is set to Disabled (default setting), the corresponding
key entry is ignored.
Note: For MX blade servers, there is also a “chassis” option, where NTP is set to synchronize time with the chassis Management
Module (MM). Chassis option continues to use unencrypted NTP, to listen to chassis MM. This is already a secure path since the
communication between iDRAC and MM is through a chassis private VLAN.
Example showing RACADM script to set security configuration in NTP group:
racadm set idrac.ntpconfiggroup.NTPEnable 1
racadm set idrac.ntpconfiggroup.ntp1 100.64.25.20
racadm set idrac.ntpconfiggroup.NTP1SecurityKey calvin
racadm set idrac.ntpconfiggroup.NTP1SecurityType 1
racadm set idrac.ntpconfiggroup.NTP1SecurityKeyNumber 65
racadm set idrac.ntpconfiggroup.ntp2 100.64.24.202
racadm set idrac.ntpconfiggroup.NTP2SecurityKey da39a3ee5e6b4b0d3255bfef95601890afd80709