How to Configure IPMI Out-of-Band Management on Servers
IPMI (Intelligent Platform Management Interface) provides out-of-band control for server hardware. In 2026 this capability remains critical. You can manage servers without relying on an operating system. When an OS becomes unresponsive or a server loses power, BMC gives you direct access. This independence reduces downtime. However, IPMI ships with weak default security. Many administrators overlook this, leading to vulnerabilities. A misconfigured BMC exposes your infrastructure. Proper configuration is essential. This guide teaches you to configure IPMI out-of-band management securely. You will explore core operations, security hardening, and the Redfish alternative. Automation and incident recovery are also covered. Protect your management network now.
Key Takeaways
Change default IPMI passwords immediately to block the most common attack.
Isolate the BMC on a separate management VLAN for security.
Assign a static IP address to the BMC for reliable access.
Use Redfish for new servers and keep IPMI skills for older hardware.
Automate IPMI configuration to apply consistent security across all servers.
How to Configure IPMI Out-of-Band Management
Understanding the BMC and Out-of-Band Management
The baseboard management controller, or BMC, is a small dedicated processor that lives on your server motherboard. It runs its own firmware and draws standby power. This design lets the BMC operate independently of the host CPU, the operating system, and the main power state. That independence defines out-of-band management. You reach the server through a separate network path, not through the OS itself.
In-band management works through the operating system. You log in over SSH or a local console, and every action depends on a healthy OS. Out-of-band management bypasses that dependency entirely. The BMC answers even when the OS hangs, the boot process fails, or the server sits powered off. This distinction matters during incidents. A frozen kernel blocks in-band tools, but the BMC still responds.
Setting Up IPMI Access with Static IP and BMC Network
Setting up IPMI access starts with physical connectivity. Plug the dedicated BMC port into a separate switch or a VLAN-tagged management interface. Never share this path with production traffic. Restrict reachability to a VPN, a private management network, or a tightly scoped firewall rule. Exposing the BMC to the public internet invites automated scanners.
Next, assign a static network address to the BMC. Configure the IP, subnet mask, and gateway through the BIOS menu or with ipmitool. Do not leave the interface on DHCP. A static address keeps your management path predictable across reboots and firmware updates.
Once the address is live, open the web interface over HTTPS or connect with ipmitool from a trusted host. Both routes give you the same control plane. The web UI suits occasional tasks, while ipmitool fits scripting and repeatable configuration.
Follow this order for a new server:
Change default credentials immediately. Factory-default IPMI usernames and passwords are publicly documented and actively targeted by automated scanners.
Assign the static BMC address described above.
Restrict network access to the management VLAN.
Update BMC firmware before production. Check the vendor’s release notes and patch if the shipped version lags by more than a release or two. Budget a short maintenance window, since the BMC may reboot.
Create individual named accounts scoped to the right IPMI privilege level: Callback, User, Operator, or Administrator. Avoid granting everyone full Administrator rights.
Replace the self-signed web certificate with a properly issued one. This step stops training users to click past browser warnings.
Change every default factory password before the server enters production. This single step closes the most common attack path against IPMI. Treat the BMC as a privileged system, because that is exactly what it is.
Core IPMI Operations and Remote Console
Power Control, Sensors, and Event Logs
You control server power through ipmitool or the web interface. The command ipmitool chassis power on starts a halted system. Use power off for a graceful shutdown, power cycle for a full restart, and power reset for a hard reboot. The web UI offers the same buttons. These actions work even when the operating system is frozen.
Sensor monitoring gives you real-time hardware health. Check temperatures, voltages, and fan speeds with ipmitool sensor list. The System Event Log (SEL) records hardware faults, thermal warnings, and power events. Run ipmitool sel list to review entries. Clear old logs with ipmitool sel clear after you resolve the underlying issue.
Remote KVM and Serial-over-LAN
KVM-over-IP provides a full graphical console. You see the boot process, BIOS menus, and OS screens remotely. This remote access works when the network stack is down. Enable KVM in the BMC web interface and connect through a Java or HTML5 viewer.
Serial-over-LAN (SOL) offers a text-based console over the management network. Configure SOL with ipmitool sol set enabled true and connect using ipmitool sol activate. SOL suits Linux servers and headless systems. It uses far less bandwidth than graphical KVM.
Both tools depend on a secured, isolated management network. Never expose KVM or SOL to untrusted networks. A weak security posture on the baseboard management controller turns these powerful features into an attack vector. Restrict access to your management VLAN and require strong authentication for every session.
IPMI Security Hardening and Network Isolation
Essential Hardening Checklist for the BMC
Securing the BMC begins with deliberate actions. The following steps form a practical checklist for ipmi security hardening. Follow this sequence for every server.
Change default credentials immediately. Factory usernames and passwords are public knowledge. Use a dedicated password manager to generate and store strong credentials. This single step closes the most common vulnerability.
Disable IPMI-over-LAN if your environment does not require it. This feature uses UDP and lacks encryption. Attackers scan for open UDP ports on the management network. Turning off this protocol reduces your attack surface.
Enforce HTTPS and disable HTTP. The web interface should only accept encrypted connections. Use a certificate from an internal certificate authority or a public issuer. This prevents credential theft during transit.
Disable unused services. Common BMC services include Telnet, SNMP, and SMTP clients. Each running service presents a potential entry point. Disable anything you do not actively use.
Enable logging and monitoring. Configure the BMC to forward system event logs to a central collector. Monitor these logs for failed login attempts and abnormal events. This gives you visibility into potential attacks.
Update BMC firmware to the latest stable release. Vendors release patches that close known security flaws. Check the release notes for each version. Schedule a brief maintenance window for the update.
Create individual accounts with least privilege. Grant Operator or Administrator rights only to users who need them. Avoid sharing a single admin account across your team.
Store these credentials in a secure password management system. Do not save them in plain text files or spreadsheets. A password manager enforces complexity and rotation policies. It also provides an audit trail of who accesses the BMC.
Automated configuration scripts help enforce consistent hardening across your fleet. Write a script that applies the same settings to every BMC. Tools like Ansible or Redfish enable programmatic control. This method ensures each device meets your security baseline without manual errors.
Isolating the Management Network
Network isolation is a critical component of security hardening. Place all BMC interfaces on a dedicated management VLAN. Never share this VLAN with production data traffic. Use strict firewall rules that permit only necessary protocols. Allow HTTPS and ipmitool traffic from a defined set of management hosts. Block all other inbound and outbound traffic.
Monitor the management network for anomalous traffic. Unexpected SSH connections, repeated login failures, or scans from unknown IPs signal a potential breach. Forward firewall logs to a SIEM tool for correlation and alerting.
Use a bastion host to provide a controlled access point for out-of-band management. The bastion host sits inside the management VLAN. It serves as a jump box for reaching the BMC web interface and ipmitool commands. The bastion host ensures you log every remote session. The bastion host also enforces multi-factor authentication. The bastion host simplifies firewall rules because you only allow traffic from a single IP address. Keep the bastion host software updated and restrict its user accounts. The bastion host creates a single choke point for auditing and monitoring. The bastion host reduces complexity and improves security posture.
Manufacturers often ship IPMI devices with minimal security settings. They prioritize compatibility over protection. Without explicit hardening, your BMC remains exposed to vulnerabilities. Automated configuration scripts address this gap. You apply the same security baseline to every device, regardless of the vendor defaults.
Combine network isolation with strict credentials and regular firmware updates. This layered approach reduces the risk of compromise. Treat the BMC as a privileged system, because it controls the power and console of your server.
Redfish, Automation, and Incident Recovery
IPMI vs. Redfish in Modern Environments
Redfish represents the next generation of out-of-band management. This standard uses RESTful APIs over HTTPS with JSON payloads. Redfish suits modern environments better than the older IPMI protocol. You send HTTP requests to Redfish endpoints and parse responses in any language. This approach works with automation tools and cloud-native infrastructure.
IPMI remains a reliable standard for legacy hardware. Many servers shipped before 2020 depend on the IPMI command set. You cannot replace this hardware overnight. You must maintain IPMI skills for these systems. Both protocols coexist in most data centers. You connect to legacy BMC interfaces with ipmitool. Modern servers respond to Redfish endpoints. Your toolkit should support both protocols.
Security posture differs between the two. Redfish enforces HTTPS by default. It supports token-based authentication. IPMI often relies on weaker authentication. Prefer Redfish for new deployments. Keep tools ready for older hardware. A single incident can require both protocols.
Automation and Recovery Playbook
You automate IPMI configuration across your server fleet. Write a script that applies consistent settings to every BMC. The script changes default credentials. It sets static addresses. It disables unused services. Use Ansible or a shell script with ipmitool commands. These tools ensure consistent protection and reduce manual errors.
Consider a real incident. Your server freezes during production hours. The OS does not respond. You reach the BMC through the bastion host on your management network. You power-cycle the server with an IPMI command. The system boots cleanly.
You review the System Event Log. The SEL shows a thermal warning before the freeze. A cooling fan failed. You verify the fan status through sensor monitoring. The issue required no data center visit. Your bastion host provided a secure access point for the entire recovery. The bastion host logged every command you executed. The bastion host enforced multi-factor authentication for the BMC session. The bastion host remains essential for secure out-of-band management in 2026.
Document every recovery step in your runbook. Your team repeats the same process without confusion. Automated IPMI configuration and a secure bastion host reduce downtime significantly.
You now know how to configure IPMI out-of-band management. Set up the BMC network first. Assign a static IP. Then reach the interface through HTTPS or ipmitool.
Security is not optional. Change default credentials at once. Disable legacy protocols. Enforce HTTPS. Isolate the management network. These steps protect every server you manage.
Evaluate Redfish for new deployments. Keep your IPMI skills sharp for legacy hardware. Both protocols will coexist for years.
Treat out-of-band management as a critical infrastructure layer in 2026. Harden it, monitor it, and document your configuration. Your uptime depends on it.
FAQ
How does IPMI differ from Redfish for out-of-band management?
IPMI uses command-line tools and UDP for control. Redfish uses RESTful APIs over HTTPS with JSON. Both standards coexist. IPMI works with legacy hardware. Redfish suits modern automated environments. You need knowledge of both protocols.
Why must you change default credentials on the BMC?
Factory-default IPMI credentials are publicly documented. Automated scanners target these accounts continuously. Changing passwords before production closes the most common entry point. Use a password manager to generate strong unique credentials for your BMC.
Can you access a server through the BMC when the operating system fails?
Yes. The BMC operates independently of the host system. It draws standby power and runs its own firmware. You can power-cycle the server with an ipmitool command and review event logs without OS assistance.
Do you need a dedicated network for the BMC management port?
Yes. Place the BMC port on a separate management VLAN. Never share this path with production traffic. Restrict access through firewall rules. Use a bastion host as a controlled entry point for all management connections.
Is IPMI still necessary in 2026?
Yes. Many legacy servers depend on the IPMI protocol. You cannot replace this hardware immediately. Redfish works better for new deployments. Maintain tools for both standards. Your toolkit must support IPMI for comprehensive server management.
