Basic BMC and IPMI Management Security Practices

In light of multiple stories about BMC security breaches, we wanted to put a basic BMC and IPMI management security practices article together. This is likely a piece we will update over time. It is also one where there is an entire industry catering to management interface security, so this is only going to provide some bare minimum basics. If you are a new administrator, this should help avoid the top mistakes at a minimal incremental cost.

Change Default Passwords

The basic BMC and IPMI default logins are well-known. If your default username and password is something like “admin / admin”, “root / password”, “root / calvin” for Dell EMC, “ADMIN / ADMIN” for Supermicro, or similar, it is exceedingly easy for a malicious user to try default logins.

This may seem overly easy, but a huge number of servers worldwide still use default IPMI and BMC passwords.

Manage Users and Privileges

Along with changing passwords is changing users. Modern BMC solutions can handle local users. Some leave default admin accounts with a changed password. Instead, we suggest creating a new administrative account then disabling the default admin account.

Modern servers also allow integrations with LDAP, Active Directory, and RADIUS services for enterprise management. Some organizations are wary of this because it provides another security surface to monitor by enabling this type of service.

Another key aspect to the modern BMC is that it allows different privileges levels beyond a global administrator role. You can use these roles to tailor specific levels of access to the management interfaces. Like with other systems, it is unlikely you want every account created to be a global administrator account.

BMC and IPMI Management Networks

Worst practice is easy: there are still small installations where BMCs and IPMI management interfaces are directly routable to the Internet. One needs to be slightly careful here. While most guides suggest private IPv4 networks, newer BMC management interfaces are also IPv6 enabled. A DHCP served publicly routable IPv6 address is not something many users were thinking about setting up their networks a decade ago.

To many, this would seem like a “nobody would do this” type setup. When we published iDRACula in September2018, 750 or so Dell iDRAC interfaces were exposed to the public Internet directly just on IPv4. This is still an issue.

Slightly better is something that we see in many SMB and lab networks. Here, the BMC management interfaces of servers are put on the same private IP network as other machines and applications. While one cannot reach the BMC management interfaces directly from the public Internet, one can reach them from vectors like POS systems and users’ computers.

Again, this is better, but it still risks a user’s machine being compromised and then giving a direct BMC attack vector.

One of the better solutions and the way one should be approaching this is to create a totally private BMC and IPMI management network. This is similar to other management networks. One of the keys to this type of network is that it should be extremely limited access. Here is a basic diagram:

Key features here are that the network is segregated. You will generally utilize either a VLAN or in some cases, a dedicated switch network to take the management interfaces. The only way to get into this network is by VPN and usually utilizing some sort of jump box. This allows fine-grained access restrictions and provides ample opportunities to log access to the network.

Another key feature is blocking egress from the management network. Virtually every network of appreciable scale has this in place. Since BMC’s are a known security vector, early on in the technology’s roll-out it became a leading practice to stop traffic passing from BMCs to the external Internet, or even other parts of an organizations intranet. By blocking this egress, a compromised BMC is unable to reach remote command and control servers that may carry additional payloads.

This is a starting point. There are a lot of significantly better setups and features that can be used. A simple example is that modern BMCs also allow access restrictions to be set on the BMC itself. Still, this is a good starting point for setting up a basic dedicated management network.

Logging

As part of this, administrators should create some basic logging. Attempts to access the BMC / IPMI interface remotely should be logged and failed logins flagged.

You should also log who is logging into the jump boxes and VPN portals to reach management networks. The primary goal on a management network should be that any device being logged into on the network should have logs that show both successful and unsuccessful login attempts. Depending on how you utilize these interfaces, you may want to flag either or both for review once servers are deployed.

Logging will allow you to see potential breaches in security. It also will allow you to set access and firewall rules appropriately if there is a malicious actor attempting to penetrate your network.

Update Firmware

BMC and IPMI management firmware often undergoes security patches and feature upgrades. There are a number of underlying technologies that need to be updated over time. Security researchers are constantly probing different management solutions from vendors. As a result, BMC firmware is updated regularly.

Most solutions allow you to update BMC firmware using management tools for clusters. For single server installations, one can often utilize the tools that are found on the server. Updating firmware usually will cause the BMC to reboot, but most modern servers will leave the primary system running during a BMC reboot.

Keep your firmware up-to-date with the latest from your vendor.

Dedicated Network Interfaces

Part of the original 1998 IPMI specification was to use a shared network interface. In modern systems, most servers utilize a low cost (often based on Realtek chips) Ethernet interface that serves as a dedicated NIC for management.

This means that many systems have the ability to present the management interface over two different physical network ports. One is a shared network port. The second is a dedicated network port. Some solutions will failover automatically. That means if the dedicated port is unplugged, the management interface will automatically present itself on the shared port. If you have physically segregated your management interfaces onto a different switch or port-based VLAN, this can mean that the IPMI and BMC interface will connect to another switch.

Every solution we have seen allows an administrator to configure this to dedicated only. Other steps you can take is to whitelist the main server’s interfaces and/or blacklist BMC interfaces from your primary network. That means even if a BMC fails over to a primary network, it will not have access to the network.

Final Words

The above is far from rocket science, but there are a lot of companies that do not follow the above steps. For hyper-scale deployments and large enterprises, the above will seem like basics at best. At the same time, as an industry, we need to get these practices in place at every installation. The above steps are the bare minimum that new administrators should know how to setup. Each BMC and IPMI management solution is slightly different, but these are practices that can be implemented with very little cost even on small installations of two to five servers.

We also recognize that since this is a vast area, we will encourage our users to add comments or other leading practices to a discussion thread in our forums. We may from time to time add some of those practices to this article.