IPMI and BMC basics - the lights-out management foundation

IPMI (Intelligent Platform Management Interface) and BMC (Baseboard Management Controller) are the out-of-band management foundation. They allow power, console, and sensor access independent of the host OS.

What IPMI is

IPMI is a standard interface for out-of-band management. The BMC is the chip on the motherboard that implements IPMI. The BMC runs independently of the host OS:

• Has its own CPU, RAM, network.
• Can power the host on and off.
• Provides serial console access.
• Reads hardware sensors (temperature, voltage, fan).
• Accessible via dedicated management network.

ipmitool

The standard tool for IPMI from Linux.

Never put the password on the command line

ipmitool -P <password> works, and it is the wrong way to run it. Arguments are not private:

• Every local user can read /proc/<pid>/cmdline while the command runs. ps aux shows the same thing, including to unprivileged monitoring agents that sample the process table.
• The line lands verbatim in ~/.bash_history on whichever jump host you typed it on.

ipmitool provides two safe alternatives. Use a credential file for anything scripted, and the environment for interactive work:

# One-time, on each host that drives the BMC.
sudo install -d -m 0700 /etc/ipmi
sudo install -m 0600 /dev/null /etc/ipmi/bmc.pw

# read -rs does not echo, and the value never appears in argv.
read -rs -p 'BMC password: ' BMC_PW; echo
printf '%s' "$BMC_PW" | sudo tee /etc/ipmi/bmc.pw >/dev/null
unset BMC_PW

-f <file> reads the password from that file. -E reads it from the IPMI_PASSWORD environment variable, which is readable only by the process owner and by root:

# Environment form, for a one-off interactive session
export IPMI_PASSWORD
read -rs IPMI_PASSWORD
ipmitool -I lanplus -H <bmc-ip> -U admin -E chassis power status

The commands

Every example uses the credential file created above:

# Substitute your own values before running:
BMC_IP=192.0.2.50
NEW_IP=192.0.2.30
MASK=24
GATEWAY=192.0.2.1

# Configure IPMI networking (one-time)
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw lan set 1 ipsrc static
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw lan set 1 ipaddr "$NEW_IP"
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw lan set 1 netmask "$MASK"
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw lan set 1 defgw ipaddr "$GATEWAY"

# Read sensors
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw sensor

# Power status
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw chassis power status

# Power on
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw chassis power on

# Power off (used for fencing)
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw chassis power off

# Console (serial over LAN)
ipmitool -I lanplus -H "$BMC_IP" -U admin -f /etc/ipmi/bmc.pw sol activate

Security considerations

IPMI / BMC is a powerful attack surface:

• Default credentials: many BMCs ship with admin/admin or similar. Change immediately.
• Management network: separate from production. Treat as critical infrastructure.
• Firmware updates: keep BMC firmware current. Old firmware has known vulnerabilities.
• IPMI v1.5: weak authentication, and the session is not encrypted. Use v2.0 (RMCP+ with RAKP) — -I lanplus, never -I lan.
• Access logging: log who accessed the BMC and when.

Two things about IPMI v2.0 are not obvious and both change how you have to treat the credential.

Cipher suite 0 accepts any password. It is a null cipher suite: no authentication, no integrity, no encryption. Several vendors ship it enabled, and ipmitool -C 0 against such a BMC gets full Administrator access with an empty password. Audit every BMC for it:

BMC=bmc01.example.com
ipmitool -I lanplus -H "$BMC" -U admin -f /etc/ipmi/bmc.pw \
  channel getciphers ipmi 1

Cipher suite 0 must not appear in the supported list. If it does, disable it in the BMC’s channel configuration — that is a configuration fix, not a password fix, and no password strength helps until it is done.

RAKP leaks a hash to unauthenticated requesters. The v2.0 handshake returns an HMAC of the user’s password before the requester has proved anything (CVE-2013-4786). Anyone who can send a packet to UDP/623 can collect that hash and crack it offline at their leisure. There is no patch; it is how the protocol works. The consequences are operational:

• BMC passwords must be long, random, and unique per host. One shared BMC password across a rack means one cracked hash is power control over the rack.
• UDP/623 must never be reachable from the production network, let alone the internet. The management network is the control, because the protocol offers none.
• Prefer Redfish over HTTPS where the platform supports it; it authenticates inside TLS and does not hand out hashes.

Knowledge check