如何在服务器上配置 IPMI 带外管理

IPMI（智能平台管理接口）可为服务器硬件提供带外控制。即使到了 2026 年，这项能力依然至关重要。你可以在不依赖操作系统的情况下管理服务器。当操作系统无响应或服务器断电时，BMC 仍能为你提供直接访问能力。这种独立性可以减少停机时间。然而，IPMI 出厂时通常带有较弱的默认安全配置。许多管理员会忽视这一点，从而引发安全漏洞。配置不当的 BMC 会使你的基础设施暴露在风险之下。因此，正确配置至关重要。本指南将教你如何安全地配置 IPMI 带外管理。你将了解核心操作、安全加固，以及 Redfish 这一替代方案。文中还会介绍自动化与故障恢复相关实践。现在就保护好你的管理网络。

关键要点

• 立即修改 IPMI 默认密码，以阻断最常见的攻击路径。

• 将 BMC 隔离在独立的管理 VLAN 中，以提升安全性。

• 为 BMC 分配静态 IP 地址，确保访问稳定可靠。

• 新服务器优先使用 Redfish，旧硬件则保留 IPMI 运维能力。

• 通过自动化配置 IPMI，可在所有服务器上统一落实安全策略。

如何配置 IPMI 带外管理

理解 BMC 与带外管理

基板管理控制器（BMC）是服务器主板上一颗专用的小型处理器。它运行自己的固件，并依靠待机电源供电。正因如此，BMC 可以独立于主机 CPU、操作系统以及服务器主电源状态运行。这种独立性，正是带外管理的定义。你是通过一条独立于操作系统的网络路径访问服务器，而不是通过主机 OS 本身。

带内管理则依赖操作系统。你通过 SSH 或本地控制台登录，所有操作都建立在操作系统健康运行的前提之上。而带外管理则完全绕过这种依赖。即使操作系统死机、启动失败，或服务器处于关机状态，BMC 仍然可以响应。这一点在故障处理中尤为关键。内核卡死会让带内工具失效，但 BMC 依旧能够工作。

使用静态 IP 和 BMC 网络设置 IPMI 访问

配置 IPMI 访问的第一步是物理连接。将专用的 BMC 端口接入独立交换机，或接入带 VLAN 标记的管理接口。切勿与生产流量共用这条路径。应将访问范围限制在 VPN、私有管理网络，或严格收敛的防火墙规则之内。将 BMC 暴露到公共互联网会招致自动化扫描器的持续探测。

接下来，为 BMC 分配一个静态网络地址。通过 BIOS 菜单或使用 ipmitool 配置 IP、子网掩码和网关。不要让该接口继续使用 DHCP。静态地址可确保你的管理路径在重启和固件更新后依然可预测、可达。

地址生效后，通过 HTTPS 打开 Web 管理界面，或从受信任主机使用 ipmitool 连接。两种方式都能访问同一套控制平面。Web UI 适合偶发性操作，而 ipmitool 更适合脚本化与可重复执行的配置流程。

对于一台新服务器，建议按以下顺序操作：

1. 立即修改默认凭据。出厂默认的 IPMI 用户名和密码通常都是公开可查的，也是自动化扫描最常针对的目标。

2. 按上文所述为 BMC 分配静态地址。

3. 将网络访问限制在管理 VLAN 内。

4. 在投入生产前更新 BMC 固件。检查厂商发布说明；如果出厂版本落后当前版本一个或多个发布周期，应及时打补丁。请预留一个简短维护窗口，因为更新过程中 BMC 可能会重启。

5. 创建具名的独立账户，并根据需要授予合适的 IPMI 权限级别：Callback、User、Operator 或 Administrator。不要让所有人都拥有完整的 Administrator 权限。

6. 将 Web 界面的自签名证书替换为正式签发的证书。这样可以避免让用户养成无视浏览器证书警告的坏习惯。

在服务器进入生产环境之前，务必修改所有出厂默认密码。这一步可以封堵 IPMI 最常见的攻击入口。请将 BMC 视为一个高权限系统，因为它本质上就是如此。

IPMI 核心操作与远程控制台

电源控制、传感器与事件日志

你可以通过 ipmitool 或 Web 界面控制服务器电源。命令 ipmitool chassis power on 可启动已关闭的系统。使用 power off 执行关机，power cycle 执行完整重启，power reset 执行硬重启。Web UI 中也提供相同功能按钮。即使操作系统已经卡死，这些操作依然有效。

传感器监控可为你提供实时硬件健康状态。使用 ipmitool sensor list 检查温度、电压和风扇转速。系统事件日志（SEL）会记录硬件故障、温度告警和电源事件。运行 ipmitool sel list 可查看日志条目。在问题根因解决后，可使用 ipmitool sel clear 清理旧日志。

远程 KVM 与 Serial-over-LAN

KVM-over-IP 提供完整的图形控制台。你可以远程查看启动过程、BIOS 菜单以及操作系统画面。即使主机网络协议栈失效，这种远程访问依然可用。你可以在 BMC 的 Web 管理界面中启用 KVM，并通过 Java 或 HTML5 查看器连接。

Serial-over-LAN（SOL）则通过管理网络提供基于文本的控制台。使用 ipmitool sol set enabled true 配置 SOL，并通过 ipmitool sol activate 建立连接。SOL 非常适合 Linux 服务器与无头系统，而且它占用的带宽远低于图形化 KVM。

这两种工具都依赖于安全、隔离的管理网络。绝不要将 KVM 或 SOL 暴露给不受信任的网络。若基板管理控制器的安全策略薄弱，这些强大的功能就会反过来成为攻击入口。请将访问限制在管理 VLAN 中，并为每一次会话启用强身份认证。

IPMI 安全加固与网络隔离

BMC 的关键安全加固清单

BMC 的安全始于有意识、成体系的操作。以下步骤构成了一份实用的 IPMI 安全加固清单。请在每台服务器上按顺序执行。

1. 立即修改默认凭据。出厂用户名和密码几乎是公开信息。请使用专门的密码管理器生成并保存高强度密码。这一步可以封堵最常见的安全漏洞。

2. 如果你的环境并不需要 IPMI-over-LAN，就将其禁用。该功能使用 UDP，且缺乏加密。攻击者经常扫描管理网络中的开放 UDP 端口。关闭这一协议可以减少攻击面。

3. 强制使用 HTTPS，并禁用 HTTP。Web 管理界面应只接受加密连接。请使用内部 CA 或公共 CA 签发的证书，以防止凭据在传输过程中被窃取。

4. 禁用未使用的服务。常见的 BMC 服务包括 Telnet、SNMP 和 SMTP 客户端。每一项运行中的服务都可能成为潜在入口。凡是不需要主动使用的，都应关闭。

5. 启用日志与监控。将 BMC 配置为把系统事件日志转发到集中式日志收集端。重点监控登录失败和异常事件，以便及时发现潜在攻击。

6. 将 BMC 固件更新到最新稳定版本。厂商会通过补丁修复已知安全漏洞。请阅读每个版本的发布说明，并为更新预留一个简短维护窗口。

7. 创建具名账户，并遵循最小权限原则。只有确有需要的用户才授予 Operator 或 Administrator 权限。避免团队共用一个管理员账号。

请将这些凭据保存在安全的密码管理系统中。不要将它们保存在明文文件或电子表格里。密码管理器不仅能落实复杂度与轮换策略，还能提供谁访问过 BMC 的审计轨迹。

自动化配置脚本有助于在整个服务器群组中一致地实施安全加固。你可以编写脚本，将相同配置应用到每一台 BMC。Ansible 或 Redfish 等工具都支持编程式控制。这种方式能够确保每台设备都符合你的安全基线，同时避免人工配置失误。

隔离管理网络

网络隔离是安全加固中的关键环节。应将所有 BMC 接口放入专用的管理 VLAN。绝不要与生产数据流量共享这个 VLAN。使用严格的防火墙规则，仅允许必要协议通过。只允许来自指定管理主机的 HTTPS 和 ipmitool 流量，阻断其余所有入站与出站通信。

还应持续监控管理网络中的异常流量。意外出现的 SSH 连接、重复的登录失败，或来自未知 IP 的扫描行为，都可能是被入侵的信号。请将防火墙日志转发到 SIEM 平台，以便进行关联分析与告警。

使用堡垒机作为带外管理的受控入口点。堡垒机部署在管理 VLAN 内，充当访问 BMC Web 界面和执行 ipmitool 命令的跳板机。堡垒机能够记录每一次远程会话，同时强制启用多因素认证。由于只需放行一个 IP 地址，堡垒机还能简化防火墙规则。请保持堡垒机软件处于最新状态，并严格限制其用户账户。堡垒机会形成一个可审计、可监控的单一控制点，从而降低复杂度并改善整体安全态势。

厂商往往以兼容性优先，而不是以安全优先的方式交付 IPMI 设备。若不进行显式加固，你的 BMC 很可能长期暴露在漏洞风险中。自动化配置脚本正是解决这一问题的有效手段。无论厂商默认配置如何，你都可以为每台设备统一施加同样的安全基线。

请将网络隔离、严格凭据管理和定期固件更新结合起来。这种分层防御方法可以显著降低被攻陷的风险。始终将 BMC 视为一个高权限系统，因为它掌控着服务器的电源与控制台。

Redfish、自动化与故障恢复

现代环境中的 IPMI 与 Redfish

Redfish 代表了下一代带外管理标准。它基于 HTTPS 上的 RESTful API，并使用 JSON 负载。与较老的 IPMI 协议相比，Redfish 更适合现代化环境。你可以向 Redfish 端点发送 HTTP 请求，并用任意编程语言解析响应。这种方式天然契合自动化工具与云原生基础设施。

IPMI 对传统硬件而言依旧是可靠标准。许多 2020 年以前出厂的服务器仍依赖 IPMI 命令集。你不可能一夜之间替换所有这类硬件，因此必须继续保有 IPMI 运维能力。在大多数数据中心中，这两种协议会长期共存。你会使用 ipmitool 连接旧式 BMC 接口，而现代服务器则通过 Redfish 端点响应。因此，你的工具链必须同时支持这两种协议。

两者在安全性上也存在差异。Redfish 默认强制 HTTPS，并支持基于令牌的身份认证；而 IPMI 往往依赖较弱的认证机制。因此，对于新部署，优先选择 Redfish；而对于旧设备，则继续保留相应工具与技能。一次实际故障处置，往往就可能同时需要这两种协议。

自动化与恢复操作手册

你可以在整个服务器群组中自动化部署 IPMI 配置。编写脚本，将一致的设置应用到每一台 BMC。脚本应完成默认凭据修改、静态地址设置以及未使用服务禁用等动作。你可以使用 Ansible，或使用结合 ipmitool 命令的 shell 脚本。这些工具能够确保防护配置一致，并减少人工操作错误。

设想一个真实故障场景：你的服务器在生产时段突然卡死，操作系统无响应。你通过管理网络中的堡垒机访问 BMC，然后使用 IPMI 命令对服务器执行电源重启。系统顺利恢复启动。

接着，你查看系统事件日志。SEL 显示服务器卡死前曾出现过一次温度告警。进一步检查发现是一只散热风扇故障。你又通过传感器监控确认了风扇状态。整个问题处理过程无需前往机房。堡垒机为整套恢复流程提供了安全访问入口，同时记录了你执行的每一条命令，并对 BMC 会话强制实施多因素认证。到了 2026 年，堡垒机依然是实现安全带外管理的关键基础设施。

请将每一个恢复步骤都写入你的运行手册。这样你的团队就能在面对同类事件时无歧义地重复执行。自动化 IPMI 配置与安全堡垒机的配合，可以显著缩短停机时间。

至此，你已经了解了如何配置 IPMI 带外管理。首先应建立 BMC 管理网络，并为其分配静态 IP。随后，通过 HTTPS 或 ipmitool 访问其管理界面。

安全绝不是可选项。要立即修改默认凭据，禁用遗留协议，强制启用 HTTPS，并隔离管理网络。这些步骤将保护你管理的每一台服务器。

对于新部署，请评估并优先采用 Redfish；对于旧设备，则继续保持 IPMI 运维能力。未来几年，这两种协议仍将长期共存。

在 2026 年，请将带外管理视为关键基础设施层来对待。对其进行加固、监控并做好文档化管理，因为你的业务可用性很大程度上依赖于此。

常见问题

IPMI 与 Redfish 在带外管理方面有何不同？

IPMI 主要通过命令行工具和 UDP 实现控制；Redfish 则通过 HTTPS 上的 RESTful API 与 JSON 实现管理。两种标准会长期共存。IPMI 适用于传统硬件，Redfish 更适合现代化自动化环境。因此，你需要同时掌握这两种协议。

为什么必须修改 BMC 的默认凭据？

出厂默认的 IPMI 凭据通常是公开可查的，自动化扫描器会持续针对这些账户发起探测。在投入生产前更改密码，可以封堵最常见的入侵入口。请使用密码管理器为 BMC 生成高强度、唯一的凭据。

当操作系统故障时，是否仍可通过 BMC 访问服务器？

可以。BMC 独立于主机系统运行，依靠待机电源供电，并运行自己的固件。即使没有操作系统协助，你仍可通过 ipmitool 命令对服务器执行电源重启，并查看事件日志。

BMC 管理端口是否需要独立网络？

需要。请将 BMC 端口放在单独的管理 VLAN 中，绝不要与生产流量共享。通过防火墙规则限制访问，并使用堡垒机作为所有管理连接的统一受控入口。

到了 2026 年，IPMI 还有必要吗？

有必要。许多传统服务器仍依赖 IPMI 协议，无法立刻全部替换。Redfish 更适合新部署，但你仍需保留对两种标准的支持工具。只有同时支持 IPMI 与 Redfish，你的服务器管理体系才算完整。