Level 1 (Must Have)
There are some basic measures you must take to secure your HMCs.
- Change default password of hscroot user. Please refer to link for password policy.
- Set grub password if your HMC is not in a physically secure environment.
chhmc -c grubpasswd -s enable --passwd <new grub password>
- If you have configured IMM on HMC, set strong IMM password.
- Set strong password for admin and general users on all servers.
- Keep HMC updated with all released security fixes. Fixes are available in Fix Central.
Level 2 (Optional)
If you have multiple users:
- HMC supports fine-grained control on resources and roles. Create account for each user on HMC.
- Assign only necessary roles to users. Here is a link on various roles in HMC.
- Assign only necessary resources (Systems, Partitions, etc.) to users.
- Both resources and roles assigned to the users must be minimum that’s required for doing the job. Create custom roles if necessary.
- Enable user data replication between HMCs. It can be done in Master-Slave mode or Peer-Peer mode.
- Import a certificate signed by Certificate Authority.
- Enable secure boot
Level 3 (Optional)
If you have many HMCs and Sysadmins:
- Use centralized authentication – LDAP or Kerberos (no, HMC doesn’t use SSO feature). There is a whitepaper on how to configure LDAP here.
- Enable user data replication between HMCs.
- Put HMC in NIST SP 800-131A mode so that it uses strong ciphers only.
- Block unnecessary ports in firewall. See below for details.
You may have many questions about HMC’s security which are put together in Q&A format below.
Which ports are open on HMC and are they secure?
HMC is primarily a Java based application built on Linux and various open source components. Following table lists important ports that a user interacts with.
Port
|
Description
|
Type
|
Protocol Version (Default Mode)
|
Protocol Version (NIST Mode)
|
22
|
Open SSH
|
TCP
|
SSH v2.0
|
SSH v2.0
|
123
|
NTP
|
UDP
|
NTP
|
NTP
|
161
|
SNMP Agent
|
UDP
|
SNMP v3
|
SNMP v3
|
162
|
SNMP Trap
|
UDP
|
SNMP v3
|
SNMP v3
|
427
|
SLP
|
UDP
|
-
|
-
|
443
|
HMC GUI & REST API
|
TCP
|
https (TLS 1.3, 1.2)
|
https (TLS 1.3, TLS 1.2)
|
657
|
RMC
|
TCP
|
RSCT (Plain Text + Hash & Sign)
|
RSCT (Plain Text + Hash & Sign)
|
2,300
|
5250 Terminal for IBMi
|
TCP
|
Plain Text
|
Plain Text
|
2,301
|
5250 Secure Terminal for IBMi
|
TCP
|
TLS 1.3, TLS1.3
|
TLS 1.3, TLS 1.2
|
5,989
|
CIM (Legacy, Removed)
|
TCP
|
Non-functional
|
Non-functional
|
9,900
|
FCS: HMC-HMC Discovery
|
UDP
|
FCS
|
FCS
|
9920
|
FCS: HMC-HMC Communication
|
TCP
|
https (TLS 1.3, TLS 1.2)
|
https (TLS 1.3, TLS 1.2)
|
9960
|
VTerm Applet in GUI
|
TCP
|
https (TLS 1.3, TLS 1.2)
|
https (TLS 1.3, TLS 1.2)
|
12347
|
RSCT Peer Domain
|
UDP
|
RSCT (Plain Text + Hash & Sign)
|
RSCT (Plain Text + Hash & Sign)
|
12348
|
RSCT Peer Domain
|
UDP
|
RSCT (Plain Text + Hash & Sign)
|
RSCT (Plain Text + Hash & Sign)
|
I would recommend to keep only ssh (port 22), https (ports 443), and VTerm (9960) exposed to intranet. Remaining ports should be put in private / isolated network. It is a good idea to use a separate Ethernet port & VLAN for RMC (port 657), FCS (ports 9900 & 9920), and RSCT Peer Domain (12347, 12348).
How secure is HMC’s connection to System?
HMC connects to the system (actually the Service Processor, a.k.a. FSP) for managing it. A proprietary binary protocol called NETC is used for managing both FSP and Hypervisor. Following table lists ports that are used by HMC:
Port on FSP
|
Description
|
Protocol Version (Default Mode)
|
Protocol Version (NIST Mode)
|
443
|
Advanced System Management Interface
|
https (TLS 1.2)
|
https (TLS 1.2)
|
30000
|
NETC
|
NETC (TLS 1.2)
|
NETC (TLS 1.2)
|
30001
|
VTerm
|
NETC (TLS 1.3, TLS 1.2) [falls back to SSLv3 for support of older firmware]
|
NETC (TLS 1.3, TLS 1.2)
|
How do I lock down HMC?
Though it is not required, if you want to have an extra layer of security around your infrastructure, you can use an IPS Device or put all HMCs and Power Servers behind a firewall. Alternatively, you can disable network services on HMC if you don’t use it remotely or want to lock it down.
You can make the following changes to disable network services:
- Disable remote command execution (ssh port).
- Disable remote virtual terminal (VTerm port).
- Disable remote web access (HMC GUI and REST API).
- Block ports in firewall using HMC network settings for each configured Ethernet port
How do I set HMC in NIST SP 800-131A compliance mode?
Once you set HMC in this mode, only strong ciphers listed by NIST SP 800-131A will be used. You may not be able to connect to older Power servers like Power 5 that don’t support TLS 1.2. Follow the steps here to switch. This feature is available only on HMC V8.8.1.0 and later.
How do I see and change ciphers used by HMC?
Default configuration is good enough for most users. Ciphers used in default mode are strong. You can check that using lshmcencr command. If your corporate standards require use of a different set of ciphers, it can be modified using chhmcencr command.
Ciphers used to encrypt user password:
lshmcencr -c passwd -t c
Ciphers used for GUI and REST API:
lshmcencr -c webui -t c
Ciphers and MAC used by ssh server:
lshmcencr -c ssh -t c
lshmcencr -c sshmac -t c
Is the certificate on HMC strong enough?
The self-signed certificates on HMC use SHA256 with 2048-bit RSA Encryption. It is strong enough. If you are using CA signed certificates, please make sure you are not using weaker 1024-bit encryption.
You will find two different certificates on HMC:
- For HMC GUI and REST API (Ports 443): This certificate can be replaced by a CA signed certificate.
- For HMC-HMC Communication (Port 9920): This port is used for communication between HMCs. You cannot replace this certificate with your own.
Should I use self-signed certificate (default) or CA Signed?
HMC auto-generates a certificate during installation. It may be good enough for you if your corporate security standard allows. If necessary, you can generate a CSR (Certificate Signing Request) from HMC and get a new certificate issued by a Certificate Authority. You can import this certificate into HMC. Remember to get a domain name also for the HMC. Steps are here.
How to audit HMC?
HMC’s audit should focus on configured ciphers and usage activity.
Ciphers Used:
Purpose
|
Command
|
Password Encryption (Global Setting)
|
lshmcencr -c passwd -t c
|
Password Encryption for each user
|
lshmcusr -Fname:password_encryption
|
SSH Ciphers
|
lshmcencr -c ssh -t c
|
SSH MAC
|
lshmcencr -c sshmac -t c
|
SSH key exchange
|
lshmcencr -c sshkey -t c
|
Cipher used for GUI and REST API
|
lshmcencr -c webui -t c
|
User Activity:
You can monitor logon and operations activity using various commands.
Information
|
Command
|
GUI Users
|
lslogon –r webui –u
|
GUI Tasks
|
lslogon –r webui –t
|
CLI Users
|
lslogon –r ssh –u
|
CLI Tasks
|
lslogon –r ssh –t
|
Operations on HMC
|
lssvcevents -t console -d <number of days>
|
Operations on System
|
lssvcevents –t hardware –m <managed system> -d <number of days>
|
Centralized monitoring of Events:
If you have many HMCs, collecting this data from each HMC may be tedious. You can setup rsyslog to collect all the data in one place.
How do I find version of OpenSSH running on HMC?
HMC doesn’t have a command that shows versions of open source software running on it but you can detect it using the following procedure:
- Get Kali linux if you don’t have it already. It’s a nice tool for penetration testing of your servers. I prefer Kali Linux 64 bit.
- Start Metasploit framework. It is one of the many tools available in Kali.
- Run the following commands:
- use auxiliary/scanner/ssh/ssh_version
- set RHOSTS <HMC IP / DNS Name>
- run
- Output should be something like this: “SSH server version: SSH-2.0-OpenSSH-6.6.1 ( service.version=6.6.1 ...”
If you want to run this for multiple HMCs in a subnet, you can try the following procedure:
- Start Metasploit framework.
- Run the following commands:
- use auxiliary/scanner/ssh/ssh_version
- set RHOSTS <Range of IPs in CIDR format>. Eg: set RHOSTS 10.0.1.0/24
- set THREADS 100
- run
Note: If it shows version of OpenSSH as 6.6.1, it doesn’t mean HMC remains vulnerable to fixes made in upstream versions of OpenSSH. We do back-port security fixes while keeping the same version. You will be getting regular fixes in Security PTFs / eFixes.
How actively does IBM fix HMC security vulnerabilities?
IBM has a very strong security incidence response process called PSIRT. Open Source and IBM components shipped with HMC are
actively monitored and analyzed. We try to get you the fixes as soon as we can. All supported releases of HMC get regular security fixes.
GDPR Queries:
Q1 - What kind of data are stored by the HMC?
A1 - Power hardware, PowerVM virtualization configuration, and performance metrics on both.
Q2 - Does the HMC process any personal data?
A2 - Optional customer-provided contact info for call home.
Q3 - Which predefined accounts are used for system administration of the HMC?
A3 - hscroot
Q3.1 - Do any of this accounts relate to a specific person?
A3.1 - No.
Q4 - Is it always optional (i.e. not mandatory) to provide personal data?
A4 - Yes.
Q5 - Is any personal data written to log files?
A5 - No.
Q6 - Is it possible to delete personal data completely and permanently?
A6 - Yes. Deconfigure call home.
Spectre-Meltdown queries
Please refer to security bulletin for spectre-meltdown updates and information.
Contacting the PowerVM Team
Have questions for the PowerVM team or want to learn more? Follow our discussion group on LinkedIn IBM PowerVM
Note: This information is provided for the purpose of generally outlining optional actions intended to increase the security of the HMCs. Please note that this information does not address every possible option and was made based on information available at the time of review. This information is provided "AS IS" WITH NO WARRANTIES OF ANY KIND. IBM makes no guarantee that the optional actions provided to you shall increase the security of the HMCs. The information provided does not supersede any obligations you may have under agreements with IBM to protect your own data.