IPMI Best Practices
The past few years have seen an increase in security incidents where intrusion occurred via BMC IPMI interfaces that were exposed to the public Internet without the sysadmin's knowledge. In some cases, sysadmins may not be aware that their servers have IPMI interfaces in the first place. This page provides some information about IPMI and its myriad security issues.
IPMI (Intelligent Platform Management Interface), is a protocol supported by many hardware vendors, e.g., in Out Of Band or Lights Out-type management suites. It is used by the server's Baseboard Management Controller (BMC), which is essentially an embedded computer used to provide out-of-band monitoring for servers. The BMC has near complete access and control over the server's resources -- including, but not limited to, memory, power, and storage. It also supports remote boot from CD or via the network, in addition to server environment monitoring. The Baseboard Management Controller runs a set of network services as well.
Devices with IPMI exposed have the potential to be completely compromised at Baseboard Management Controller (BMC) level. Intruders accessing the IPMI can perform such actions as: rebooting the system; installing a new OS; and accessing data, bypassing any operating system controls. IPMI may also permit remote console access, as well as the ability to modify the BIOS.
Note that typically, IPMIs have default passwords, or may have no password at all. In addition, the IPMI password can be obtained from a root-compromised server, and then used to gain access to other hosts in the IPMI managed group. The IPMI protocol itself also has some security flaws.
IPMI is usually implemented as a network service that runs on UDP port 623 and often runs on a dedicated Ethernet port on the server, sometimes labeled "management".
IPMI is a server technology; laptops don't use it and typically end-user workstations don't either. If there's any doubt, check your vendor documentation.
In particular, the following server management technologies use IPMI:
HP Integrated Lights Out (iLO)
IBM Remote Supervisor Adapter
There are open source IPMI suites as well.
There are several disastrous flaws in the IPMI 2.0 protocol specification itself (and even more in 1.0). Some examples are below. These interfaces must not be publicly exposed as they pose a serious system security risk.
In addition to many IPMI implementations using default, known passwords, the IPMI 2.0 specification has a serious flaw in which, if a client specifies "cipher type 0" for encryption (which is meant to indicate that the client wants to use clear-text authentication), actually any password will be accepted. Cipher 0 issues were identified in HP, Dell, and Supermicro BMCs, with the issue likely encompassing all IPMI 2.0 implementations. Unlike many IPMI implementations, HP systems typically have a random default password -- but they are subject to this cipher 0 issue. Disable support for cipher 0 in your device. It's enabled by default in many implementations. If possible, allow support only for ciphers 3, 8 and 12.
Password hash exposure:
IPMI 2.0 allows the client to retrieve the hashed password for the account it is attempting to access. So, even if cipher 0 support is disabled and the host is not using a default password, it's possible for an attacker to retrieve the password hash for offline cracking. Use a long (20 characters or greater) passphrase in order to mitigate this risk.
IPMI should be restricted to private management networks only. If you won't be using it, but have no way to disable IPMI on your device, or you have no alternative but to run an IPMI on the public network, consider having its MAC address blocked by Information Security at your local building switch, which will limit access to your local network VLAN only. If you don't intend to use it, assign it a non-routable IP address in an address range you will never use for anything else. If you do intend to use it and must do so on the campus network, get a static IP address for it. In no case should IPMI be using a public, routable, DHCP address.
Note that this interface should always be on a separate management network, but we have seen cases of BMC's made accessible on public network interfaces, sharing the same physical network interface card (NIC) as the operating system, but using a separate virtual interface that receives a DHCP address -- all without the admin's knowledge. Setting a static IP address should help avoid surprises like this. In particular, if your BMC has its own NIC, but you haven't connected that NIC, be advised that it may default to "piggybacking" IPMI on your public NIC. If you won't be using it, explicitly disable it and assign it a non-routable static IP.
BMC's typically support service network services. Disable all unused services on the BMC -- this can usually be done via a web interface, but may require command line or API use.
Good writeup from Rapid7 from an exploitation standpoint
Security recommendations document from Dan Farmer, whose excellent research led to much of the current knowledge and discussion regarding IPMI security problems