Out-of-Band Server Management: IPMI, iDRAC, iLO, and Redfish API

Out-of-band server management: IPMI, iDRAC, iLO, and the Redfish API

A classic on-call horror story: your monitoring agent flags a server as down. Every indicator is red, the site returns connection refused, and external probe nodes confirm the machine is unreachable from multiple locations. You try SSH — no connection. Ping doesn't go through. According to your whitebox metrics, everything looked normal up to the last moment: CPU 30%, RAM 40%, disk alive. And then, suddenly, nothing.

What now? Order Remote Hands from your hosting provider and wait 15-40 minutes for someone to walk over and physically inspect the box? That's the reality most admins face. But there's another level of access that works precisely when the operating system is "dead": out-of-band management through the BMC.

This is the third, deepest layer of server control, and it completes the full monitoring-and-management picture. On-server agents see metrics from the inside. External probe nodes confirm availability from the outside. And out-of-band access reaches the hardware itself, bypassing the OS entirely — even when the whole system is completely frozen.

1. What a BMC is, and why it always works

A BMC (Baseboard Management Controller) is a separate microcomputer that physically lives on the server's motherboard, right next to the main CPU and chipset. It has its own ARM processor (typically 400-1200 MHz), its own RAM (256-512 MB in current generations), a dedicated Ethernet controller with its own RJ45 port, its own firmware, and its own operating system (usually an embedded Linux).

The key property: a BMC runs independently of the main system. It's powered from the PSU's standby rail, so it stays active even when the server is "off" via the power button (in reality the PSU still supplies +5V standby in that state). The BMC initializes as soon as the power supply gets power from the outlet — well before BIOS/UEFI even starts POST — and keeps running regardless of what happens to the main OS. Kernel panic on Linux? The BMC works. Windows Blue Screen? The BMC works. Server stuck at the GRUB stage? The BMC works. Power cut at the server itself, but the PSU still plugged into the outlet? The BMC works.

This is what gives out-of-band management its unique value: it depends on nothing except the physical power reaching the motherboard. It works precisely when every other monitoring and management mechanism has already run out of options.

1.1 IPMI as the interaction standard

Historically, the protocol for talking to a BMC is called IPMI (Intelligent Platform Management Interface). It's an open standard that Intel, HP, NEC, and Dell introduced in 1998 as IPMI 1.0. Key milestones: IPMI 1.5 (2001) added the ability to manage a server over the network via LAN and serial-over-LAN, and IPMI 2.0 (2004) added encryption through cipher suites, user roles, and improved authentication. Today, production servers almost always run IPMI 2.0; older versions survive only on legacy hardware.

IPMI itself isn't an interface but a protocol: a set of commands you can send to the BMC. Communication runs over UDP port 623. Through IPMI you can power a server on/off, read temperature sensors, pull a list of hardware events, and get access to the system console. In the next section we'll look at how specific vendors (Dell, HPE, Supermicro) extended this standard with their own implementations, and what has started replacing IPMI in the 2020s.

2. Vendor implementations: how this looks in practice

The IPMI standard is uniform, but every major server manufacturer has built its own system on top of it — with its own web interface, extended functionality, and, of course, its own licensing scheme.

2.1 Dell's iDRAC

Integrated Dell Remote Access Controller. The standard for PowerEdge servers. Current generations: iDRAC 9 for PowerEdge 14th-16th generation servers (since 2017), iDRAC 10 for 17th-generation PowerEdge (since 2024).

Dell's licensing can genuinely be a headache: Express (basic functions, free with the server), Enterprise (KVM over IP, virtual media — i.e. what you usually need), Datacenter (extended telemetry, thermal management, integration with enterprise systems). Enterprise is typically already included in the standard configuration of dedicated servers from hosting providers, but if you buy directly from Dell it's a separate line item.

2.2 HPE's iLO

Integrated Lights-Out. The equivalent on ProLiant servers. Current generations: iLO 5 (Gen10), iLO 6 (Gen11, since 2021), iLO 7 (Gen12, since 2025). Each new generation is tied to the corresponding HPE server generation.

iLO 7 in 2026 stands out for a few technical reasons: quantum-resistant crypto firmware (NIST SP800-208), a separate Silicon Root of Trust as a physically isolated security processor, and a refreshed web interface with a dashboard. Licensing is simpler than Dell's: iLO Standard (free with the server) and iLO Advanced (KVM over IP, virtual media, extended telemetry).

2.3 ASUS's ASMB

ASUS Server Management Board. A management card installed on ASUS server motherboards with BMC-socket support. Current models are the ASMB9-iKVM and ASMB10-iKVM. Market share is smaller than Dell's or HPE's, but it's common among smaller system integrators and in the ASUS ESC segment (AI/GPU servers). ASUS's distinguishing feature: KVM over IP, virtual media, and Redfish already ship in the base module — no separate licenses needed.

2.4 Supermicro's BMC

Supermicro doesn't use a marketing name like "iDRAC" — they just call it BMC or IPMI. It's one of the most common options in the hosting market thanks to the lower price of Supermicro boards compared to branded Dell/HPE hardware. The web interface traditionally lagged competitors on usability, but the X13/X14 generations (since 2023) brought a substantial refresh. There are licensing nuances: basic KVM over IP and web access itself have been free since the X10 generations. Virtual Media through the HTML5 console (i.e. mounting an ISO straight from the browser), however, requires a separate SFT-DCMS-SINGLE key. Basic Redfish API functions are available out of the box, while some extended endpoints likewise need a license. This isn't critical for day-to-day work, but it's worth knowing in advance if you're planning heavy automation.

2.5 Comparison table

3. What out-of-band management actually gives you

Now that it's clear how this works at the hardware level, let's break down what an administrator actually gets in practice.

3.1 KVM over IP — a console when the OS is dead

This is the feature that makes out-of-band access worthwhile in most real incidents. KVM over IP means you see the server's video output as if you were physically sitting in front of a monitor connected to it. Keyboard and mouse input is redirected from your client to the server's BIOS/OS over the network.

The key point: this works at the hardware level. You see POST logs during boot, the BIOS/UEFI menu, GRUB, and OS startup stages. If Linux hangs during boot and shows a kernel panic message on the console, you'll see it verbatim, with line numbers and a stack trace. If Windows throws a Blue Screen, you'll see it with the error code. This is diagnostic information unavailable through any other method.

3.2 Remote power management

All power-control options are available through the BMC:

• Power on: turn the server on when it's off
• Power off: hard shutdown (like holding the power button)
• Graceful shutdown: a clean shutdown via an ACPI signal to the OS
• Power cycle: off then on (for cases where a reset doesn't help)
• Warm reset: reboot without cutting power (the equivalent of the physical reset button on the chassis)

This is the lifeline when the OS is completely frozen. SSH doesn't respond, ping doesn't go through, the console is stuck. But with a reset button through the BMC, you can reboot the machine in 2 minutes without a trip to the datacenter.

3.3 Virtual Media — mounting ISO images

A very powerful feature for "I need to reinstall the OS on a remote server" scenarios. You download an ISO image (say, Ubuntu Server 24.04 or Rocky Linux 9) to your workstation or an HTTP server, "mount" it as a virtual CD/DVD in the BMC's web interface, and the server sees that ISO as if a physical disc had been inserted.

From there: reboot the server through the BMC, pick the virtual CD as the boot device in BIOS, install the OS. All from home, no trip required. This is how hosting providers actually implement "reinstall OS" buttons in their panels — they automate exactly this process through the API.

3.4 Hardware monitoring

The BMC reads every hardware sensor on the motherboard and keeps their state in real time. This includes:

• CPU, chipset, and individual motherboard-zone temperatures
• RPM of every fan (chassis fans, CPU coolers, PSU fans)
• Power supply status: health, power draw
• Voltages on all key rails (+12V, +5V, +3.3V, CPU VRM)
• RAM status: ECC errors on specific DIMM slots
• SMART readings from drives via the RAID controller (if present)

The value here isn't the data itself (you can also get it via IPMI tools inside the OS), but the fact that it's available regardless of the OS's state. If the server locked up due to CPU overheating, you'll see it in the BMC's web interface before the OS even shows any signs of life.

3.5 System Event Log (SEL)

The BMC keeps a continuous log of hardware events: power on/off, sensor state changes (e.g. "CPU temperature crossed the warning threshold"), POST stage completions, component detection/absence (e.g. "power supply 2 disconnected"). This log survives reboots and even a complete loss of power (it's stored in the BMC's own NVRAM).

For post-incident diagnostics, the SEL is often more valuable than OS system logs: if there was overheating or a power failure, it will show up here with a precise timestamp, whereas the OS log may be corrupted or cut off.

3.6 POST logs and boot diagnostics

The BMC saves the last POST screen before the OS boots, plus logs from the early boot stages. This saves you in "the server won't boot and we can't tell at which stage" situations. Through the BMC you can see: whether CPU initialization completed, whether memory was detected, whether the disk controller was found, whether a boot disk was found, whether the UEFI/BIOS bootloader started.

4. Basic setup

Let's go over the minimum steps needed to make the BMC both useful and secure. Order matters: get it out of sequence and you'll end up with either an unreachable BMC or an open attack surface.

4.1 A dedicated network interface

Most server motherboards offer two networking options for the BMC: shared (uses the server's main LAN port) and dedicated (a separate physical RJ45 connector labeled "BMC," "IPMI," "iLO," or "iDRAC").

Use dedicated. Shared mode is convenient when a server has few ports, but it creates a problem: BMC traffic runs through the same network card as OS traffic, so if the OS's network stack hangs, the BMC becomes unreachable too. That's unacceptable in a production setup.

4.2 An isolated management VLAN

The dedicated port should go not into the same VLAN as production traffic, but into a separate management VLAN, isolated from the public network at the switch level. The reasoning is simple: BMC interfaces have historically had a large number of vulnerabilities in their web servers and IPMI stacks. If a BMC is reachable from the internet, you're playing Russian roulette with CVE statistics.

A minimal secure setup: every server's BMC port connects into a dedicated switch or a separate VLAN, and access to that VLAN goes only through a bastion host or VPN. No direct NAT from a public IP to the BMC.

4.3 First login and changing default credentials

Every BMC ships from the factory with a default password. On Dell iDRAC the login is always `root`, and on current PowerEdge servers (iDRAC 9 and newer) the password is uniquely generated per server and printed on the pull-out Service Tag at the front of the chassis; the legendary historic password `calvin` now has to be explicitly requested for compatibility with legacy scripts. On HPE iLO the password is likewise randomly generated and printed on a label on the server itself. Supermicro historically defaulted to ADMIN/ADMIN, but newer models (X13/X14) already use a unique password from the label.

The very first thing you do after the initial connection is change the password. Not "later," not "when I get to it" — right now. Default BMC passwords are one of the most popular targets for automated scanners: if a misconfiguration or bad luck exposes a BMC to the internet for even a moment with a default password, full control over the server can be lost within minutes.

4.4 A separate account with minimal privileges

After changing the root/admin password, create a separate, restricted account for day-to-day tasks. The logic mirrors Linux: don't operate as root where sudo is enough. BMCs typically offer a tier of privileges: read-only (view only), user (view + power management), operator (plus KVM), administrator (everything, including user management).

Operator is enough for most day-to-day tasks. Reserve the root account for critical scenarios and keep its credentials in a dedicated secure storage (KeePass, 1Password Business).

4.5 Updating BMC firmware

BMC firmware updates separately from BIOS/UEFI and separately from the OS. This is important to internalize: if you think you "regularly update the server," that covers the OS, not the BMC. BMC firmware has to be updated manually through the web interface or via vendor-specific tools.

Optimal cadence: check for updates quarterly, install with a bit of lag (2-4 weeks after release) so the vendor has time to ship a hotfix if the release has critical bugs. The exception is critical security releases (for example, once a reference exploit appears): those should go in faster, within a planned maintenance window in the coming days.

5. BMC security as its own topic

The BMC deserves dedicated attention from a security standpoint. A compromised BMC is the worst-case scenario for a server: the attacker gets full control over the hardware, including the ability to reinstall the OS, read/write memory directly, watch the boot process, and install a firmware rootkit that survives OS reinstallation.

5.1 An isolated network — a requirement, not a recommendation

Worth repeating because it's critical: the BMC must not be reachable from the public internet. Ever. Under any circumstances. This isn't "best practice" advice — it's basic hygiene.

The reality is a bit grimmer than that: Shodan data regularly shows tens of thousands of BMC interfaces scanned with open ports on the internet. Many of them still have default passwords or outdated firmware with known CVEs. Every one of those servers is someone's production system, sitting on the edge of full compromise.

5.2 A firewall even on the management network

Even inside an isolated management VLAN, it's worth having firewall rules: access to BMC addresses only from specific admin-workstation IPs or a bastion host. This protects against a scenario where an attacker already has access to one machine on the management network and is trying to expand the attack to other servers' BMCs.

5.3 BMC vulnerabilities — a real problem, not theory

This isn't an abstract threat. Recent examples:

• CVE-2024-54085: a critical vulnerability in AMI MegaRAC BMC (used by Supermicro, Gigabyte, ASRock Rack, Lenovo, and others), added to the CISA Known Exploited Vulnerabilities Catalog in 2025. Allows unauthenticated authentication bypass.
• CVE-2024-10237: signature verification bypass in the Supermicro BMC firmware update mechanism. An attacker can install a modified firmware image that appears legitimate.
• CVE-2025-6198: an extension of the previous vulnerability class in Supermicro BMC, allowing persistent malware to be installed in the BMC firmware that survives OS reinstallation.

The pattern repeats: BMC firmware has a large attack surface (web server, IPMI stack, virtual media handler), is developed under a firmware model without many modern security practices, and at the same time has the highest level of access to the system. This creates a class of attacks that's significantly harder to detect and remediate than ordinary OS-level compromises.

5.4 Minimizing the attack surface

Turn off anything you don't use. Typical checklist:

• Disable IPMI over LAN if you're using Redfish exclusively
• Disable SNMP if it isn't wired into your monitoring
• Disable SSH access to the BMC if you don't need it for automation
• Disable anonymous login in the web interface (enabled by default on some vendors)
• Use HTTPS with a valid certificate (you can even use Let's Encrypt via ACME for the management domain)
• Enable 2FA or TOTP if the BMC supports it (iLO 6+, iDRAC 9+)

6. Minimally acceptable configuration

To summarize what you shouldn't go below in production:

Required

• A dedicated network port for the BMC, not shared with the OS
• An isolated management VLAN, unreachable from the public internet
• Default credentials changed at first login
• Current BMC firmware (no older than 6-12 months)
• A separate admin account with action logging; root reserved for emergencies

Recommended

• Firewall rules at the management-network level (access only from admin IPs)
• 2FA/TOTP for the web interface
• Redfish API instead of IPMI for automation
• Centralized monitoring of BMC health (availability, firmware version, configuration changes)
• Regular, scheduled firmware updates with a maintenance window

Common mistakes

• BMC on a public IP. The classic mistake. It's being scanned and brute-forced within 2-3 days.
• Default passwords. "Temporary, until I finish setting up everything else" — then it gets forgotten.
• Outdated firmware. "It still works, why update it" — until the first CVE gets published.
• Shared network. Saved a port, and now the BMC drops along with the OS.
• One admin account for every admin. Impossible to audit who did what.

7. Summary: the three-tier model of full control

Out-of-band management isn't a separate technology — it's the logical conclusion of a three-tier model in which each layer works exactly when the one before it has run out of options:

• On-server whitebox monitoring gives you depth: CPU, RAM, disk metrics, application logs. Works as long as the OS is alive.
• External blackbox monitoring gives you server independence: agents in other locations ping the service and flag when it becomes unreachable. Works as long as the network is alive.
• Out-of-band access via the BMC gives you access to the hardware itself: KVM, power control, virtual media, hardware sensors. Works as long as the motherboard has physical power.

Together, these three layers cover almost every possible failure scenario: from a single app hanging to a full kernel panic, from a network blackout at the datacenter to CPU and memory hardware failures. Miss any one of them, and your setup has a blind spot.

What's worth taking from this article into practice:

• The BMC isn't an optional extra — it's a baseline part of a production server. If you have a dedicated server without out-of-band access, you don't have full control over your infrastructure.
• A minimal secure configuration in 4 steps: dedicated port, isolated VLAN, changed passwords, current firmware. Everything else is already optional.
• BMC vulnerabilities are a real problem with real CVEs from 2024/2025. Skipping BMC firmware updates is more dangerous than skipping OS updates, because bringing a system back to a secure state after a BMC compromise is an order of magnitude harder.

This article covered the basics: what a BMC is, how it works across vendors, and how to set it up and secure it. The next big topic: practical CLI work and automation — using ipmitool to manage servers from shell scripts, working with the Redfish API for CI/CD integration, collecting BMC metrics in Prometheus/Grafana, and automating firmware updates through an Ansible playbook. That's the day-to-day engineering work we'll cover separately.

Frequently Asked Questions