IPMI Explained: BMC LAN Access, RMCP+ and How to Isolate It

IPMI, the Intelligent Platform Management Interface, is the 1998 standard that lets a server's baseboard management controller (BMC) report sensors, keep an event log, switch power and redirect the serial console, locally or over UDP port 623. Its IPMI 2.0 login design leaks a guessable password hash, so keep it off any network you do not fully control, and switch it off where Redfish can do the job.

That is the short answer. The rest of this post walks through what the specification actually defines, how an RMCP+ session is negotiated byte by byte at a conceptual level, why cipher suite 0 and the RAKP handshake are design weaknesses rather than bugs, and a step by step audit you can run with ipmitool against your own fleet. It extends our Redfish explainer and the OpenBMC post, so it does not repeat their material on the Redfish data model or BMC firmware internals.

Key takeaways

• IPMI v1.0 was released on 16 September 1998, v1.5 on 21 February 2001 and v2.0 on 12 February 2004. The current document is IPMI v2.0 revision 1.1, dated 1 October 2013. There has been no newer revision.
• A BMC is a separate microcontroller with its own firmware, network stack and credentials. Anyone who controls it can power cycle the host, attach a serial console and, depending on the platform, reach firmware settings, without touching the host operating system.
• Over the network IPMI rides on RMCP, a DMTF protocol on UDP 623 (with 664 reserved as a secure port). IPMI 2.0 added RMCP+ sessions, negotiated with a four message handshake called RAKP and a numbered cipher suite.
• Cipher suite 0 means no authentication, no integrity and no encryption. If a BMC offers it for privileged users, a password is not needed to send commands. CISA told operators to disable it in 2013.
• In RAKP message 2 the BMC returns an HMAC keyed with the user's password over values the requester already knows. That lets anyone who can start a handshake for a valid user name test password guesses offline. It is a property of the specification, recorded as CVE-2013-4786, and no firmware update can remove it while keeping IPMI 2.0 compatibility.
• The defence is architectural: long random passwords unique to each BMC, no anonymous or null users, only HMAC-SHA256 or HMAC-SHA1 cipher suites with AES, BMC interfaces on an isolated management network, and IPMI over LAN disabled wherever Redfish over HTTPS can replace it.
• Redfish (DMTF DSP0266, first released 4 August 2015) is the modern replacement. Its schema even includes a switch, IPMI.ProtocolEnabled, for turning IPMI over LAN off.

What IPMI is and what a BMC does with it

IPMI is a message based interface specification for platform management. It was written by four promoter companies, a processor maker and three server makers, and adopted by a large number of hardware makers since. The idea was to give every server a common way to answer basic questions, such as how hot the processors are, whether a fan has failed, or what happened just before the machine rebooted, and to take basic actions, such as power off, power on or reset, without depending on the operating system or even on the main processor running at all.

The component that implements IPMI is the baseboard management controller. NIST SP 800-193 describes the BMC as an out of band management device that lets administrators "manage a platform without requiring the host operating system to be running". In practice it is a small system on chip on the motherboard, powered from standby power whenever the server is plugged in, with its own firmware, its own memory, its own network interface (dedicated or shared with a host port) and its own user accounts.

What the BMC does through IPMI falls into a handful of functional areas, all defined in the specification:

The FreeIPMI project summarises what most users actually want from IPMI as "sensor monitoring, system event monitoring, power control, and serial-over-LAN (SOL)". That list is also a useful threat model. Power control is a denial of service lever. SOL is console access. Boot device override plus power cycle is a way to start the server from media the attacker chooses. The 2013 CISA alert put it bluntly: attackers can use IPMI "to essentially gain physical-level access to the server".

Versions

The revision history in the current document dates IPMI v1.0 to 16 September 1998, v1.5 to 21 February 2001 and v2.0 to 12 February 2004, with errata markups through 2009 and a final revision 1.1 on 1 October 2013. The full dated timeline, including the security milestones, is near the end of this post.

One correction to a commonly repeated claim: IPMI v1.5 was not released alongside v2.0 in 2004; it came three years earlier.

The interfaces: KCS, SSIF, IPMB and LAN

IPMI defines several ways to reach the BMC. Each is a "channel" with its own number and its own access settings, which matters later because disabling IPMI over LAN does not disable local access.

System interfaces

The host operating system talks to the BMC through a system interface. The specification defines three that sit on the host's I/O or memory bus: KCS (Keyboard Controller Style, named after the old keyboard controller register layout it mimics), SMIC (Server Management Interface Chip) and BT (Block Transfer). A fourth, SSIF, carries IPMI over SMBus. The Linux kernel's IPMI documentation describes the same split: boards with a standard interface "will generally be either 'KCS', 'SMIC', or 'BT'", handled by the ipmi_si driver, while the SMBus driver (ipmi_ssif) handles SSIF. Firmware tables (SMBIOS and ACPI) tell the kernel which one exists and where.

System interfaces are sessionless. There is no password: the assumption is that anyone with kernel level access to the host is already trusted. That is why ipmitool's open interface, which uses the kernel driver through /dev/ipmi0, can change BMC users and network settings without credentials. It is also why a root compromise of the host usually means a compromise of the BMC's configuration.

IPMB

The Intelligent Platform Management Bus is an I2C based bus inside the chassis that connects the BMC to satellite management controllers, such as controllers on power supplies, blades or add in boards. The BMC can bridge messages from a LAN session onto IPMB. Linux has a separate IPMB driver for satellite controllers. IPMB is internal wiring, so it is not a network exposure in itself, but bridging means a LAN session can reach controllers that were never designed to see untrusted traffic.

LAN

The LAN channel is the one that matters for this post. IPMI over LAN uses RMCP, the Remote Management and Control Protocol, which DMTF defined in its Alert Standard Format (ASF) specification. The IPMI specification lists two well known UDP ports: 623 (the "Primary RMCP Port", always supported, used for clear text discovery and for sessions) and 664 (the "Secondary RMCP Port" or secure port, used only by implementations that cannot mix encrypted and unencrypted packets on one port). The IANA registry lists them as asf-rmcp on 623/udp and asf-secure-rmcp on 664/udp. In practice almost every BMC does IPMI over LAN on 623.

There is also a serial/modem channel and a terminal mode. These are rare in data centres today, but the specification notes that terminal mode supports only straight password authentication.

Interface comparison

How IPMI 1.5 sessions worked

IPMI v1.5 introduced authenticated sessions over LAN. The specification lists the authentication types as "'none', 'straight password', the MD2 and MD5 message-digest algorithms". A remote console asks the BMC for a challenge, then activates a session, and every packet afterwards carries an AuthCode computed with the user's password.

Three problems made v1.5 unsuitable for untrusted networks:

1. The weakest options were real options. "None" and "straight password" are both in the list. With straight password, the password is the AuthCode.
2. One key did everything. The user's password authenticated the session and protected every packet. ipmitool's man page warns that changing a password over the v1.5 lan interface sends the new password across the network "as clear text".
3. No confidentiality. Nothing in a v1.5 session is encrypted, so sensor values, SEL contents and console data are visible to anyone on the path.

ipmitool still exposes these types (none, md2, md5, password, oem) as values you can enable per privilege level with lan set <channel> auth, which is useful mainly for turning them off.

How an RMCP+ session works in IPMI 2.0

IPMI 2.0 kept the v1.5 packet format for compatibility and added a new one, RMCP+, with a proper key exchange. The specification builds RMCP+ around RAKP, the RMCP+ Authenticated Key-Exchange Protocol, which it says "was developed based on the Authenticated Key Exchange Protocol (AKEP) defined by Bellare and Rogaway". RAKP uses pre shared symmetric keys, the user passwords, to authenticate both sides and to derive per session keys.

Here is the sequence a remote console and BMC go through, in the order the specification describes it:

After message 2 validates, the console computes the Session Integrity Key (SIK), an HMAC over both random numbers, the role and the user name, keyed with a 160 bit key called KG. After message 3 validates, the BMC computes the same SIK. From the SIK both sides derive further keys: K1 keys the integrity algorithm that signs each packet, and the first 128 bits of K2 become the AES-CBC-128 key for encrypted payloads.

One-key and two-key logins

KG is the "BMC key". The specification says a user "needs to know both KG and a user password" to establish a session, "unless the channel is configured with a 'null' KG", in which case the user's password is used in place of KG. A null KG is the common default, which the specification calls a "one-key" login. Setting a KG gives a "two-key" login, where the session keys depend on a secret that is not the user's password. FreeIPMI and ipmitool both accept a KG on the command line (-y for a hex key in ipmitool, -k in FreeIPMI tools).

Two-key logins improve the secrecy of the session keys, but as the next sections show, they do not change what RAKP message 2 reveals, because that message is keyed with the user's password, not with KG.

Privilege levels

Every session is opened at a requested maximum privilege: Callback, User, Operator, Administrator or OEM. Each user has a privilege limit per channel. The specification also lets the BMC limit which cipher suites may be used at which privilege, through LAN configuration parameter 24, "RMCP+ Messaging Cipher Suite Privilege Levels". That parameter is the main lever for shutting off weak suites.

Session integrity and replay protection

Once a session is active, every packet carries a sequence number. The specification uses a sliding window: a packet is accepted only if its number is within "plus 15 or minus 16 counts" of the highest number already accepted and is not a duplicate. Sessions close on a Close Session command or after an inactivity timeout.

Cipher suites, one by one

A cipher suite in IPMI is a triple of algorithm numbers: one for authentication (the RAKP variant), one for integrity (how each packet is signed) and one for confidentiality (how payloads are encrypted). The specification assigns standard IDs 0 to 19 in Table 22-19, reserves 80h to BFh for vendor defined suites and makes some algorithms mandatory for BMCs: RAKP-none, RAKP-HMAC-SHA1, integrity "none" and HMAC-SHA1-96, and confidentiality "none" and AES-CBC-128.

In the spec's key, S means "authenticated session setup (correct role, username and password/key required to establish session)", A means authenticated payload data and E means authentication and encrypted payload data.

Clients have moved their defaults over time. ipmitool's man page says the default for the lanplus interface is now suite 17, and that in ipmitool 1.8.18 and earlier the default was 3, "which was insecure and was not supported by some more recent BMC implementations". FreeIPMI's ipmi-config man page still says it "Defaults to cipher suite ID 3 if not specified". Neither default matters if the BMC refuses everything weaker than what you want, which is the point of the audit later in this post.

One caution about the table: even the best standard suite uses AES-CBC with a 128 bit key derived through HMAC from a password. It was a reasonable design in 2004. It does not offer forward secrecy, and its strength still traces back to the password, which leads to RAKP's main weakness.

Why cipher suite 0 and anonymous or null users are dangerous

Cipher suite 0

Cipher suite 0 pairs RAKP-none with no integrity and no encryption. The specification is explicit about what RAKP-none means: it "does not provide password authentication or RAKP packet level data integrity checking", and the RAKP steps "establish Session IDs and privilege level using only the given username/role".

Read that carefully. With cipher suite 0, a session is established on the strength of a user name and a requested role. If the BMC allows suite 0 at Administrator privilege and the requester names an existing administrator account, the session is created without the password ever being checked. Everything after that, power control, user changes, SOL, is available at that privilege.

The 2013 CISA alert TA13-207A described "cipher 0" as "an option enabled by default on many IPMI enabled devices that allows authentication to be bypassed", and told operators to disable it. The specification makes suite 0 support mandatory for BMCs, which is why it shows up in the supported list on so many platforms; the defence is to give it no privilege at all through parameter 24, or "X" (unused) in ipmitool's notation.

Anonymous and null users

The specification has a convention for anonymous login: User ID 1 is configured with a null user name and a null password. It even provides bits in Get Channel Authentication Capabilities so a console can tell whether anonymous login is enabled, whether User ID 1 has a null name but a non null password, and whether other named users exist. User ID 1 is permanently the null user; there is "no configurable name" for it.

Null user names also change how keys are looked up. The specification allows a BMC to be configured with null user names "whereby key lookup is done based on 'privilege level only'". In that model the password is tied to a role, not to a person, so there is no way to attribute actions and every operator shares one secret.

The combination of a null user name, a null password and RAKP-none is, in the specification's own words, "a way to enable access the BMC without requiring a username and password". CISA's 2013 advice was that "Anonymous logins should also be disabled". In practice that means: disable User ID 1 on every LAN channel, or at minimum give it no access, and make sure the authentication capabilities response reports no anonymous login.

Why RAKP lets anyone obtain a salted hash for offline guessing

This is the weakness that cannot be patched away, so it deserves a careful, defender level explanation. No exploit steps follow; what matters is the property and what it means for policy.

The property

Look again at RAKP message 2. The specification defines its authentication code as an HMAC, keyed with K[UID], the password of the named user, over these fields:

• both session IDs,
• the console's random number (which the console chose),
• the BMC's random number (which the BMC just sent in the same message),
• the BMC's GUID (also in the same message),
• the requested role, the user name length and the user name (all chosen by the console).

Every input to that HMAC is known to whoever sent message 1. The only unknown is the key, which is the user's password. So the requester holds a value of the form "HMAC of known data under the password", which is exactly what an offline password guesser needs: for each candidate password, compute the HMAC over the same data and compare.

Three details make this worse than an ordinary hash leak:

1. The BMC sends it before the requester proves anything. Message 2 comes before message 3, the step where the console proves it knows the password. A requester does not need to know the password to receive the value; it only needs a valid user name.
2. The guessing is offline. After the value is captured, no further packets go to the BMC. Lockout settings such as the Bad Password Threshold, which ipmitool exposes as lan set <channel> bad_pass_thresh, count failed attempts at the BMC. They never see offline guesses.
3. KG does not help. The message 2 HMAC is keyed with the user's password, not with KG. A two-key login protects the derived session keys, not this value.

The random numbers act as a salt: they stop precomputed tables from working across BMCs, but they do nothing to slow down guessing against one captured value.

How it was recorded

NVD published CVE-2013-4786 on 8 July 2013 with this description: "The IPMI 2.0 specification supports RMCP+ Authenticated Key-Exchange Protocol (RAKP) authentication, which allows remote attackers to obtain password hashes and conduct offline password guessing attacks by obtaining the HMAC from a RAKP message 2 response from a BMC." NVD's CVSS 3.0 score is 7.5, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: network reachable, low complexity, no privileges needed, high confidentiality impact.

Note that the CVE names the specification, not a product. Any BMC that implements IPMI 2.0 RAKP as specified has this property. A firmware update cannot remove it without breaking the protocol that every IPMI client expects. The specification's revision 1.1 came out in October 2013, after the CVE, as an errata update; the RAKP message 2 definition it contains is the one quoted above.

What it means for BMC password policy

Treat every IPMI password on a BMC that answers RAKP from a network as if its hash is already in an attacker's hands. Then the policy follows:

• Use the full key length. The specification says that for IPMI v2.0 "the BMC shall support 20-byte passwords", and it recommends "that a full 160-bit user key be used when 'one-key' logins are enabled". ipmitool's man page confirms the 20 character maximum for IPMI v2.0 and 16 for v1.5. A 20 character password drawn at random from a large character set is far outside what offline guessing reaches; a word plus a year is not.
• Make it unique per BMC. CISA's 2013 alert lists, among issues raised by researcher Dan Farmer, that "Knowledge of one IPMI password gives you the password for all computers in the IPMI managed group" when a group shares one. A cracked unique password costs you one machine.
• Never reuse it. ipmitool's man page says the password "should not be the same as any other password on that system". If a BMC password is also a domain, hypervisor or root password, offline guessing against the BMC becomes a way into those.
• Know which user names exist. The attack needs a valid user name. Rename default administrator accounts where the BMC allows it, and delete unused accounts. This raises the bar slightly; it is not a substitute for the steps above, because user names are often predictable.
• Rotate on schedule and on events. Rotate after staff changes, after a BMC has been reachable from an untrusted network, and after any hardware returns from repair.
• Remove reachability. The only complete fix is that no untrusted party can send RAKP message 1 to the BMC. That means a management network, and IPMI over LAN disabled where it is not needed.

Redfish: how DMTF replaces IPMI

Redfish is DMTF's REST and JSON management standard. The specification, DSP0266, has a revision history that starts with version 1.0.0 on 4 August 2015; the version fetched for this post, 1.21.0, is dated 1 August 2024. DMTF also publishes the schemas separately; the ManagerNetworkProtocol schema fetched for this post is version 1.14.0 from release 2026.2.

Compared with IPMI over LAN, the security model is different in kind:

The specification states that all requests using HTTP Basic authentication "shall require HTTPS". That alone removes the clear text and offline guessing problems of IPMI over LAN, provided the BMC's TLS configuration and certificate handling are sound. Our Redfish post covers the resource model and Redfish specific hardening.

Why many fleets still have IPMI enabled

If Redfish is better, why does UDP 623 still answer on so many management networks? The reasons are mostly operational:

• Tooling. Monitoring agents, cluster managers, provisioning systems and power fencing agents were built on ipmitool or FreeIPMI. Replacing a fencing agent in a high availability cluster is a change many teams postpone.
• Defaults. Many BMCs ship with IPMI over LAN enabled for compatibility. The Redfish schema itself says the default IPMI port "should be 623 for compatibility with established client implementations".
• Mixed fleets. Older servers may have weak or partial Redfish implementations. Teams standardise on the protocol every machine supports, which is IPMI.
• Invisibility. IPMI is UDP, it is not in most web vulnerability scans, and it does not appear in the host's own port list because the BMC, not the host, answers. Teams often do not know it is on.

The practical stance: use Redfish for anything new, keep IPMI over LAN only for the specific tools that cannot yet move, restrict it to a management network, and keep a dated plan to turn it off.

IPMI commands every admin uses with ipmitool

ipmitool is the most widely packaged IPMI client. Its upstream GitHub repository is now a public archive, so check your distribution's package for the version and patches you actually run; FreeIPMI, maintained by the GNU project, offers equivalent tools (ipmi-sensors, ipmi-sel, ipmi-chassis, ipmi-config) and published release 1.6.20 on 5 October 2026.

Run these locally with -I open (the kernel driver, no credentials) or remotely with -I lanplus -H <bmc> -U <user> -E (password from the IPMI_PASSWORD or IPMITOOL_PASSWORD environment variable, which keeps it out of the process list and shell history).

Channel numbers vary by platform. LAN is often channel 1, sometimes 2 or 8. ipmitool's man page suggests running channel info <number> until you find one whose medium type is "802.3 LAN".

Warning: sel clear destroys the event log on the BMC. Export it first with ipmitool sel elist > sel-$(hostname)-$(date +%F).txt, confirm the file has content, and confirm you are connected to the BMC you mean to clear (ipmitool mc guid and ipmitool fru print show which machine you are talking to).

Step by step: audit, restrict, isolate and rotate

The following walkthrough audits one BMC from its own host and from a management workstation, tightens it, and then moves on to the network and credential steps that apply to a fleet. Commands are ipmitool; FreeIPMI's ipmi-config can do the same through configuration sections. Run them on a test server first: BMC implementations differ in which settings persist, which are volatile and which require a BMC reset.

Before you start: Make sure you have another way into the server, a physical console or a crash cart, in case you lock yourself out of the BMC. Note every current setting before changing it. Some changes apply immediately to the LAN channel you are using.

Step 1: inventory every BMC

You cannot isolate what you have not found. Start from three sources and compare them:

1. Your asset system or provisioning records, which should list each server's BMC address.
2. Each host's view of its own BMC:

sudo modprobe ipmi_devintf ipmi_si 2>/dev/null
sudo ipmitool -I open mc info
sudo ipmitool -I open lan print 1 | grep -E 'IP Address Source|IP Address|MAC Address|802.1q VLAN ID'

3. A UDP scan of your own address space, limited to networks you are authorised to scan, to find BMCs that answer where they should not:

# Run only against address ranges you own and are authorised to test
sudo nmap -sU -p 623 --open 10.20.0.0/16 -oG ipmi-623.gnmap
grep '623/open' ipmi-623.gnmap | awk '{print $2}' | sort -u > ipmi-responders.txt

Any responder on a user, server or internet facing network is a finding, regardless of its configuration. Any BMC in your records that does not respond on the management network is also a finding: it may have a DHCP address somewhere else.

Step 2: list the cipher suites and their privilege limits

On each BMC, read what the LAN channel offers:

sudo ipmitool -I open channel getciphers ipmi 1
sudo ipmitool -I open lan print 1 | grep -E 'Auth Type|Cipher Suite'

lan print shows two lines that matter: "RMCP+ Cipher Suites", the list of supported IDs, and "Cipher Suite Priv Max", a string of privilege letters. Read the letters as X for unused, c callback, u user, o operator, a administrator and O OEM.

There is an ambiguity here that is worth knowing about. ipmitool's man page says each character position "identifies the cipher suite number", starting at suite 0. The IPMI specification defines the underlying parameter 24 per "1st Cipher Suite", "2nd Cipher Suite" and so on, matched to the list of supported suite entries in parameter 23. On a BMC whose supported list is 0 to 14 in order, the two readings agree. On a BMC whose list skips IDs or includes 15 to 17, they may not. Compare the order of "RMCP+ Cipher Suites" with the privilege string, and check the BMC's documentation before you write a new string.

Step 3: allow only strong suites

On a BMC whose supported list is 0 through 14 in order and which supports suite 3, the following removes every suite except 3, and lets suite 3 reach Administrator:

# Positions: suite 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
sudo ipmitool -I open lan set 1 cipher_privs XXXaXXXXXXXXXXX
sudo ipmitool -I open lan print 1 | grep 'Cipher Suite Priv Max'

ipmitool requires the string to be exactly 15 characters. If your BMC lists suite 17 in "RMCP+ Cipher Suites" and you want to allow it, the BMC's own configuration tool or Redfish OEM settings may be the only way to address entries beyond the fifteenth; set it there and use ipmitool to verify.

Then confirm from the management workstation that the weak suites are refused and the strong one works:

export IPMI_PASSWORD='read-from-your-vault'
ipmitool -I lanplus -H 10.99.1.21 -U opsadmin -E -C 3 mc info   # expect success
ipmitool -I lanplus -H 10.99.1.21 -U opsadmin -E -C 1 mc info   # expect failure
unset IPMI_PASSWORD

Also turn off IPMI v1.5 authentication types you do not need. On most fleets that is all of them:

sudo ipmitool -I open lan set 1 auth ADMIN,OPERATOR,USER,CALLBACK MD5
sudo ipmitool -I open lan print 1 | grep -A5 'Auth Type Enable'

The command keeps only MD5 for any client that still speaks v1.5. If nothing in your environment uses the v1.5 lan interface, check whether your BMC accepts an empty set; many do not, so MD5 is the least bad remaining value.

Step 4: remove anonymous access and audit users

sudo ipmitool -I open user list 1
sudo ipmitool -I open channel authcap 1 4

In user list, User ID 1 usually shows with an empty name. Disable it and remove its channel access:

sudo ipmitool -I open user disable 1
sudo ipmitool -I open channel setaccess 1 1 callin=off ipmi=off link=off privilege=15
sudo ipmitool -I open channel authcap 1 4

Privilege 15 means "no access". After the change, the authentication capabilities output should no longer report that anonymous login or a null user is enabled.

Then go through every other enabled user. For each one ask: does a named person or service own it, does it need Administrator, and does it need the LAN channel at all? Disable what you cannot justify, and lower privilege where you can:

sudo ipmitool -I open user priv 3 2 1     # user ID 3 to USER (2) on channel 1
sudo ipmitool -I open user disable 4

Step 5: set long, unique passwords

Generate a random 20 character password per BMC and store it in your secrets manager before setting it, so you never hold a password that only the BMC knows. Set it over the local interface, never over the v1.5 lan interface:

NEWPW="$(LC_ALL=C tr -dc 'A-Za-z0-9!#%+=' < /dev/urandom | head -c 20)"
# Store "$NEWPW" in your vault for this BMC's serial number before continuing
sudo ipmitool -I open user set password 2 "$NEWPW" 20
sudo ipmitool -I open user test 2 20 "$NEWPW"
unset NEWPW

The trailing 20 tells ipmitool to store a 20 byte password. The specification notes that a password stored as 20 bytes cannot be used as a 16 byte password, so v1.5 clients will no longer authenticate as that user. That is usually what you want.

If you use two-key logins, set KG with your BMC's configuration tool (ipmitool's -y option supplies it as a client) and store it alongside the password. Remember that KG protects session keys, not the RAKP message 2 value.

Step 6: turn IPMI over LAN off where Redfish can replace it

Find out what still uses IPMI before you switch it off: grep your monitoring, fencing and provisioning configuration for ipmitool, lanplus, ipmi-sensors, fence_ipmilan and port 623, and check firewall logs for UDP 623 traffic to the management network.

Where nothing needs it, disable it through Redfish. The standard property is IPMI.ProtocolEnabled on the manager's NetworkProtocol resource. Find the manager ID first, then patch:

BMC=https://10.99.1.21
curl -s --cacert bmc-ca.pem -u "opsadmin:${REDFISH_PASSWORD}" "$BMC/redfish/v1/Managers" | jq -r '.Members[]."@odata.id"'

curl -s --cacert bmc-ca.pem -u "opsadmin:${REDFISH_PASSWORD}" \
  -X PATCH -H 'Content-Type: application/json' \
  -d '{"IPMI": {"ProtocolEnabled": false}}' \
  "$BMC/redfish/v1/Managers/1/NetworkProtocol"

curl -s --cacert bmc-ca.pem -u "opsadmin:${REDFISH_PASSWORD}" \
  "$BMC/redfish/v1/Managers/1/NetworkProtocol" | jq '.IPMI'

Use the CA certificate you installed on the BMC, not -k, so the step that removes one weak path does not create another. Where Redfish is not available, the IPMI way is to disable access on the LAN channel:

sudo ipmitool -I open lan set 1 access off
sudo ipmitool -I open channel info 1

Then verify from the management workstation that RMCP no longer answers, for example with ipmitool -I lanplus -H 10.99.1.21 -U opsadmin -E mc info, which should time out. The local system interface still works after this; that is expected and is how you get back in.

Step 7: put BMCs on an isolated management network

CISA's 2013 guidance was to restrict IPMI "to a management VLAN segment with strong network controls", and the 2023 joint CISA and NSA information sheet on hardening BMCs repeats the theme of network segmentation, along with credentials and firmware updates, as steps that are often overlooked. A management network for BMCs typically has these properties:

• Separate layer 2 and layer 3. BMC ports go to dedicated switch ports or a dedicated VLAN that is not trunked to server, user or guest networks. If the BMC shares a host network port (a "shared LOM" setting), set a separate management VLAN on the BMC or move it to its dedicated port.
• No default route to the internet. BMCs do not need outbound internet access. Firmware updates can be staged from an internal repository.
• Access only through a bastion. Administrators connect to a jump host with multi factor authentication, and only the jump host and named management services (monitoring, provisioning) may reach the BMC network.
• Allow lists, not deny lists. Permit HTTPS (443) and, only where still needed, UDP 623 from those named sources. Deny everything else, including BMC to BMC traffic.
• Logging. Log accepted and denied flows into the management network.

A minimal nftables policy on a Linux router or firewall between the bastion network (10.99.0.0/24) and the BMC network (10.99.1.0/24) might look like this:

table inet mgmt {
  set bastions { type ipv4_addr; elements = { 10.99.0.10, 10.99.0.11 } }
  set monitors { type ipv4_addr; elements = { 10.99.0.20 } }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ip saddr @bastions ip daddr 10.99.1.0/24 tcp dport 443 accept
    ip saddr @monitors ip daddr 10.99.1.0/24 tcp dport 443 accept
    # Remove the next line once nothing uses IPMI over LAN
    ip saddr @monitors ip daddr 10.99.1.0/24 udp dport 623 accept
    ip daddr 10.99.1.0/24 log prefix "bmc-deny " drop
    ip saddr 10.99.1.0/24 log prefix "bmc-out-deny " drop
  }
}

Load it with sudo nft -c -f mgmt.nft to check syntax, then sudo nft -f mgmt.nft.

Step 8: rotate credentials across the fleet

Rotation is where shared passwords creep back in, because doing it per BMC by hand is slow. Automate it:

1. Read the list of BMCs from inventory, keyed by server serial number.
2. For each BMC, generate a new random password, write it to the vault under that serial, then set it through Redfish (PATCH on the account resource under /redfish/v1/AccountService/Accounts/) or through ipmitool over an encrypted lanplus session with suite 17 or 3.
3. Verify the new password works, and only then mark the old one retired in the vault.
4. Log the change in your change system, with the BMC serial, not the password.

Rotate on a schedule your policy sets, and immediately after any event that might have exposed a RAKP exchange: a BMC found answering on the wrong network, a management network misconfiguration, or a server returning from repair or decommissioning.

Step 9: watch the BMC itself

BMCs are hard to monitor; CISA noted in 2013 that there were "few, if any, monitoring tools available to detect if the BMC is compromised". Do what is available:

ipmitool -I lanplus -H 10.99.1.21 -U monitor -E -C 3 sel elist | tail -50
ipmitool -I lanplus -H 10.99.1.21 -U monitor -E -C 3 session info active

Use a separate low privilege monitoring user for this. Forward SEL entries and BMC syslog, where supported, to central logs, and alert on new users, password changes, firmware updates and power actions you did not schedule.

Where BMC firmware updates and NIST SP 800-193 fit

Isolation reduces who can talk to the BMC. Firmware updates reduce what they can do once they do. Both matter because the BMC is a full computer with a long service life, and because its firmware is software assembled from components, often including an embedded Linux kernel, a web server, a TLS library and an IPMI daemon.

NIST SP 800-193, Platform Firmware Resiliency Guidelines, published in May 2018, organises firmware security around three goals: protecting firmware from unauthorised changes, detecting changes that happen, and recovering to a known good state. It names the BMC explicitly as a platform device whose firmware must "not negatively affect the state of integrity of the host processor's security domain".

The parts that map directly to BMC operations:

• Authenticated updates. SP 800-193 calls for an "authenticated update mechanism" that uses digital signatures, rooted in a Root of Trust for Update (RTU) that holds the verification key and algorithm. When you buy servers, ask whether the BMC verifies signed firmware images before applying them, and whether that key store can be changed outside the authenticated path.
• Authorisation is separate from authentication. NIST notes that authentication of an image is "typically rooted in the device or system manufacturer", while authorisation to perform an update is "typically rooted in the device or system owner". In BMC terms: only a small set of administrators, through the management network, should be able to start an update, and that should be logged.
• Rollback protection. SP 800-193 discusses preventing rollback to older, vulnerable images, sometimes with a physical presence requirement. Ask whether your BMC enforces a minimum version.
• Detection and recovery. Roots of Trust for Detection and Recovery let a platform notice corrupted firmware and restore a known good copy. Some BMC designs keep a second firmware image for this.

The operating pattern that follows:

1. Track the BMC firmware version of every server (ipmitool mc info or the Redfish FirmwareInventory collection under UpdateService) in the same inventory as the host operating system.
2. Subscribe to your server maker's security advisories and check BMC firmware in each patch cycle, not only when something breaks.
3. Stage firmware images on an internal repository on the management network, verify the published checksum or signature, and apply them through Redfish UpdateService or the vendor's documented tool.
4. Re-audit cipher suites, users and protocol settings after each update; some updates reset BMC configuration to defaults.

Our OpenBMC post covers the internals of open source BMC firmware, and the rack server post covers how BMC firmware and credentials are set in the factory. For host firmware updates on Linux, see fwupd and LVFS.

A dated timeline of IPMI security milestones

Where Safeguard fits

Safeguard does not scan networks for BMCs, configure IPMI, test cipher suites, analyse BMC firmware or generate hardware bills of materials, and nothing in the walkthrough above depends on it. The fit is indirect and sits with the software around your management plane. Monitoring exporters that poll IPMI or Redfish, provisioning and fencing tools, the automation that rotates BMC passwords and the container images those tools ship in are built from open source dependencies, and some of them wrap IPMI libraries. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), shows which projects carry a given component and version, matches them against vulnerability data and applies policies and gates. That tells you which management tooling builds still carry a vulnerable library when a fix ships. BMC firmware itself is outside that scope; its fixes still come from your server maker.

Common mistakes

• Leaving default credentials in place. Factory accounts and passwords are documented publicly for many platforms. Change them during provisioning, before the BMC ever joins a network, and check for them again after any BMC reset or firmware update.
• Putting BMC ports on the internet or a flat network. CISA's 2013 alert warned that attackers "can easily identify and access systems that run IPMI". A BMC on a server VLAN is reachable by anything that compromises any server on it.
• Sharing one admin password across the fleet. One offline guessing success from one RAKP exchange then unlocks every BMC. Use a unique password per BMC from a vault.
• Trusting lockout to stop RAKP guessing. Bad password thresholds count online attempts. Offline guessing never touches the BMC again.
• Disabling suite 0 but leaving suites 1, 6 and 15. Those authenticate the session setup but then send unsigned, unencrypted packets. Allow only suites with both integrity and AES encryption.
• Forgetting User ID 1. The null user is a fixed slot. Disable it on every LAN channel and verify with channel authcap.
• Passing passwords with -P. The password lands in shell history and the process list. Use -E with an environment variable or -f with a protected file.
• Disabling IPMI on the BMC but not removing firewall rules. The rule becomes a standing path if a later firmware update re-enables IPMI over LAN.
• Not re-auditing after firmware updates or BMC resets. Some resets restore factory network, user and cipher suite settings.
• Forgetting the end of life step. CISA's 2013 alert advises following manufacturer guidance to sanitise BMC credentials at end of life; servers sent for resale or recycling carry BMC configuration and passwords in flash.

FAQ

What is IPMI used for?

IPMI is a standard interface to a server's baseboard management controller. Administrators use it to read sensors, read the system event log, check field replaceable unit inventory, power the server on, off or cycle it, set a one time boot device and redirect the serial console with Serial Over LAN. It works whether or not the host operating system is running.

What port does IPMI use?

IPMI over LAN uses RMCP on UDP port 623. The specification also defines UDP 664 as a secondary "secure" RMCP port for implementations that cannot mix encrypted and clear text packets on one port, but most BMCs use 623 for everything. The Redfish schema says a BMC's IPMI port should default to 623.

What is IPMI cipher suite 0 and why is it dangerous?

Cipher suite 0 uses RAKP-none authentication with no integrity and no encryption. The specification says RAKP-none establishes a session "using only the given username/role", without password authentication. If a BMC allows suite 0 at a privileged level, a requester who knows a user name can get a session without the password. Disable it through the cipher suite privilege settings.

What is the IPMI RAKP vulnerability (CVE-2013-4786)?

In the IPMI 2.0 RAKP handshake, the BMC's message 2 contains an HMAC keyed with the user's password over values the requester already knows. Anyone who can start a handshake for a valid user name can capture that value and test password guesses offline. Because it is part of the specification, it cannot be patched while keeping IPMI 2.0 compatibility. The defences are long unique passwords and no untrusted network access.

Is IPMI 2.0 encrypted?

It can be. IPMI 2.0 defines AES-CBC-128 (and older xRC4 options) for payload encryption once an RMCP+ session is up, used by cipher suites 3, 8, 12 and 17. Suites without the "E" flag, including 0, 1, 2, 15 and 16, send payloads unencrypted. IPMI 1.5 sessions are never encrypted.

Should I disable IPMI over LAN?

Where Redfish over HTTPS can do the job, yes. The Redfish ManagerNetworkProtocol resource has an IPMI.ProtocolEnabled property for this. Where tools still require IPMI, keep it only on an isolated management network, allow only strong cipher suites and restrict UDP 623 to the specific hosts that need it.

Does disabling IPMI over LAN stop ipmitool from working on the host?

No. Local access through the kernel driver (ipmitool -I open) uses the system interface, not the LAN channel. Disabling LAN access leaves local management working, which is useful for recovery and is also why host root access remains equivalent to BMC configuration access.

Is Redfish more secure than IPMI?

Its design is. Redfish requires HTTPS with TLS 1.2 or later and only IANA "Recommended" TLS cipher suites, and it supports session based and multi factor authentication. It does not have RAKP's offline guessing property. A Redfish service can still be weak if it keeps default passwords, uses an untrusted certificate or is exposed to untrusted networks, so the isolation rules still apply.

How long can an IPMI password be?

IPMI v2.0 supports 20 byte passwords, and the specification recommends a full 160 bit key for one-key logins. IPMI v1.5 limits passwords to 16 bytes. ipmitool rejects IPMI v2.0 passwords longer than 20 characters.

Fix it without waiting for upstream

IPMI is a protocol, and its weaknesses are fixed by configuration and network design rather than by a package upgrade. The tools that surround it are ordinary software, though: BMC exporters, fencing agents, provisioning systems and the containers they run in all pull open source dependencies, and when one of those has a vulnerability the fix path is the same as for any other code you build.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real session with the Safeguard CLI. The assistant reads a finding and its advisory, asks before each command, upgrades a dependency, runs the tests and pushes nothing. The same flow applies when a library inside a BMC monitoring exporter or a password rotation script needs an upgrade.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. Management tooling often lives on hosts inside the management network, and the runner lets you scan those repositories and images from a machine you control rather than opening the network up.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. Approving each command is the same discipline this post asks for on a BMC: nothing privileged happens without a named person saying yes.

Click through it at your own pace, or open it full screen.

Download the apps at safeguard.sh/download and read the CLI docs at docs.safeguard.sh/docs/cli.

Quick check

Sources

• Intelligent Platform Management Interface Specification, Second Generation, v2.0 Document Revision 1.1 (1 October 2013)
• NVD: CVE-2013-4786, IPMI 2.0 RAKP authentication allows offline password guessing
• CISA Alert TA13-207A: Risks of Using the Intelligent Platform Management Interface (IPMI) (26 July 2013, revised 7 October 2016)
• CISA: CISA and NSA Release Joint Guidance on Hardening Baseboard Management Controllers (14 June 2023)
• NIST SP 800-193: Platform Firmware Resiliency Guidelines (May 2018)
• NIST SP 800-193 full text (PDF)
• DMTF DSP0266: Redfish Specification 1.21.0 (1 August 2024)
• DMTF Redfish schema: ManagerNetworkProtocol v1.14.0
• ipmitool manual page (ipmitool.1)
• ipmitool repository
• GNU FreeIPMI project home and release history
• FreeIPMI ipmi-config(8) manual page
• Linux kernel documentation: The Linux IPMI Driver
• IANA Service Name and Transport Protocol Port Number Registry (asf-rmcp 623, asf-secure-rmcp 664)

Related reading: Redfish explained, OpenBMC explained and how a rack server is made.

Last reviewed: 24 October 2026. IPMI v2.0 revision 1.1 is the current specification and Redfish is revised several times a year; check DMTF, NVD and your server maker's documentation before relying on a specific behaviour or default.