BMC 带外管理加固实战：iDRAC 与 iLO 收敛配置

BMC 带外管理加固在服务器安全评估里最容易被跳过：操作系统补丁打得很勤，管理口却还留着出厂口令、IPMI over LAN 和公网可达的 623/UDP。带外管理芯片（iDRAC、iLO 以及各类 IPMI BMC）是独立于操作系统的 SoC，一旦失守，攻击者可以挂载虚拟光驱重装系统、抓取 KVM 画面、直接下发上下电指令，等于拿到这台物理机的最高控制权。本文按暴露面盘点、网络收敛、服务收敛、账号收敛、日志与验证的顺序，给出可直接复制执行的命令与配置。

适用场景

自建机房、托管机柜、云上裸金属服务器，管理口与业务网处于同一网段，甚至直接映射到公网。
等保测评或客户安全基线核查中，需要证明「带外管理面不可从业务网直连」。
出现过弱口令登录告警、默认账号异地登录，需要一次性把 BMC 账号体系收紧。
批量服务器（几十到上千台）需要脚本化盘点 BMC 固件版本与开放端口。

前置条件

服务器带外管理可用：Dell iDRAC7 及以上、HPE iLO4 及以上，或支持 IPMI 2.0 的通用 BMC。
一台位于管理网段的跳板机或堡垒机，已启用多因素认证。
跳板机安装 ipmitool、curl、nmap；排查 iLO 时可选安装 HPE 的 hponcfg。
管理网段与 VLAN 已规划，交换机侧可下发 ACL；服务器 BMC 使用独立管理网口，不与业务口复用。

原理说明

BMC 的软件栈与主机操作系统完全独立，供电走待机电源，因此操作系统内的防火墙、EDR、加固脚本对它没有任何约束力。它的攻击面是固定的几组端口：

623/UDP：IPMI 2.0（RMCP+）。历史上的 cipher 0 认证方式会泄露用户口令的 HMAC 摘要（CVE-2013-4786），可离线爆破；老固件还存在匿名登录与 RAKP 认证缺陷。
443/TCP 与 80/TCP：Web 管理台与 Redfish API。出厂默认账号（如 root/calvin、admin/admin）和未授权 API 是重灾区。
5900/TCP：部分厂商的 KVM 远程控制台直连端口。
22/TCP：iLO、iDRAC 自带的 SSH 命令行，走 BMC 自己的账号体系。

加固思路不是逐个堵端口，而是先把它塞进一张只允许跳板机访问的网，再在 BMC 内部关掉不需要的协议、删掉不需要的账号。网络层做减法收益最大：即使 BMC 存在未公开漏洞，公网和业务网都摸不到它，攻击面直接归零。

操作步骤

步骤一：盘点暴露面与固件版本

先摸清有多少台 BMC 暴露、开了哪些服务。下面的命令在管理网段执行，只做探测不做爆破：

# 1) 确认管理网段内存活的 BMC（IPMI 623/UDP 响应）
nmap -sU -p 623 --open 10.20.30.0/24 -oG bmc_alive.txt

# 2) 查看单个 BMC 的固件版本与厂商信息
ipmitool -I lanplus -H 10.20.30.21 -U monitor -P 'ReadOnly@2026' mc info

# 3) 检查管理口还开了哪些 TCP 服务
nmap -Pn -sT -p 22,80,443,5900,623 10.20.30.21

把结果整理成资产台账：IP、厂商、型号、BMC 固件版本、开放端口、账号归属人。固件版本低于厂商安全公告要求的设备，先列入更新计划，因为相当一部分 BMC 漏洞只能靠刷固件解决，配置层面绕不过去。

步骤二：管理 VLAN 加 ACL，只放行跳板机

BMC 单独划一个管理 VLAN，交换机上只允许跳板机网段访问，其余一律丢弃。若服务器管理口与业务口复用同一物理链路，用 nftables 在主机侧做兜底（不能替代交换机 ACL，但能挡住误配）：

# /etc/nftables.d/bmc-guard.nft
table inet bmc_guard {
    set jumphost {
        type ipv4_addr
        elements = { 10.20.30.11, 10.20.30.12 }
    }
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif "eth1" ip saddr @jumphost tcp dport { 22, 443, 5900 } accept
        iif "eth1" ip saddr @jumphost udp dport { 623, 664 } accept
        iif "eth1" counter log prefix "bmc-drop: " level warn drop
    }
}
# 生效并查看
nft -f /etc/nftables.d/bmc-guard.nft
nft list table inet bmc_guard

注意 664/UDP 是部分厂商的 IPMI 备用端口，不用就一并关掉。日志前缀 bmc-drop: 便于在 SIEM 里单独建一条告警，出现外部 IP 试探管理口时能第一时间发现。

步骤三：关闭 IPMI over LAN 与 SOL

Web 管理台已经能完成绝大多数运维动作，IPMI over LAN 和串口重定向（SOL）属于典型的「留着不用、被打才想起」的服务。先确认通道号再关：

# channel 1 是常见的 LAN 通道，先用 lan print 确认
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' lan print 1
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' lan set 1 access off

# 关闭 SOL 串口重定向
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' sol set enabled false 1

iDRAC 还可以直接通过 Redfish 关掉 IPMI 与 SNMP，把带外访问统一收敛到 HTTPS + Redfish：

# 关闭 IPMI over LAN 与 SNMP 代理（iDRAC9 属性接口）
curl -sk -u admin:'******' -X PATCH \
  -H 'Content-Type: application/json' \
  -d '{"Attributes":{"IPMILan.1.Enable":"Disabled","SNMP.1.AgentEnable":"Disabled"}}' \
  https://10.20.30.21/redfish/v1/Managers/iDRAC.Embedded.1/Attributes

HPE iLO 的做法是用 hponcfg 下发 XML，一次把 IPMI over LAN 与 SNMP 访问关掉：

<!-- /root/ilo-disable-ipmi.xml -->
<RIBCL VERSION="2.0">
  <LOGIN USER_LOGIN="Administrator" PASSWORD="******">
    <RIB_INFO MODE="write">
      <MOD_GLOBAL_SETTINGS>
        <IPMI_OVER_LAN VALUE="N"/>
        <SNMP_ACCESS_ENABLE VALUE="N"/>
      </MOD_GLOBAL_SETTINGS>
    </RIB_INFO>
  </LOGIN>
</RIBCL>

# 执行下发
hponcfg -f /root/ilo-disable-ipmi.xml

步骤四：收敛账号与权限

默认账号必须删除或改名，只保留两类身份：运维管理员（Administrator）与只读监控（Operator）。先用 Redfish 查账号列表，再删默认账号、建只读账号：

# 列出全部 BMC 账号，记下默认账号的 @odata.id
curl -sk -u admin:'******' \
  https://10.20.30.21/redfish/v1/AccountService/Accounts | python3 -m json.tool

# 删除出厂默认账号（ID 以实际查询结果为准，不要照抄示例值）
curl -sk -u admin:'******' -X DELETE \
  https://10.20.30.21/redfish/v1/AccountService/Accounts/2

# 新建只读监控账号，供 Zabbix / Prometheus 拉取传感器数据
curl -sk -u admin:'******' -X POST \
  -H 'Content-Type: application/json' \
  -d '{"UserName":"monitor","Password":"Monitor#2026","RoleId":"Operator","Enabled":true}' \
  https://10.20.30.21/redfish/v1/AccountService/Accounts

通用 BMC 用 ipmitool 时对应另一组子命令，权限值 0x04 是 Operator、0x05 是 Administrator，监控账号不要给到管理员权限：

ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' user list 1
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' user set password 3 'Monitor#2026'
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' user priv 3 0x04 1
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' user enable 3
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' user disable 2

步骤五：日志外发与证书检查

BMC 的登录日志、配置变更日志是入侵取证的关键证据，必须外发到 SIEM，避免被攻击者清空。iDRAC 的生命周期日志可以通过 Redfish 定时增量拉取：

# 拉取 iDRAC 生命周期日志（LC Log）最近 50 条
curl -sk -u admin:'******' \
  'https://10.20.30.21/redfish/v1/Managers/iDRAC.Embedded.1/LogServices/Lclog/Entries?$top=50' \
  | python3 -m json.tool

# 检查 BMC 管理台证书是否仍是出厂自签
openssl s_client -connect 10.20.30.21:443 -servername idrac-10-20-30-21 /dev/null \
  | openssl x509 -noout -subject -issuer -dates

证书主题里出现厂商默认名称（如 iDRAC Default Certificate）说明还没替换。换成内部 CA 签发的证书并接入到期提醒，否则运维会因为证书告警习惯性点「继续访问」，等于给中间人留出稳定窗口。

步骤六：固件更新与基线复核

最后把固件补齐。BMC 固件更新会重启管理芯片，通常不影响业务，仍建议放在维护窗口执行，并确认服务器接在 UPS 上：

# 更新前后对比固件版本
ipmitool -I lanplus -H 10.20.30.21 -U admin -P '******' mc info | grep -i 'firmware revision'

# 通过 Redfish 查询固件清单，确认各组件版本（更新包由厂商工具或 LC 界面推送）
curl -sk -u admin:'******' \
  https://10.20.30.21/redfish/v1/UpdateService/FirmwareInventory | python3 -m json.tool

配置验证

加固完必须从攻击者视角复测，四条命令覆盖网络、协议、账号、证书四个面：

# 1) 业务网段应完全扫不到 623/UDP，管理网段仅跳板机可达
nmap -sU -p 623 10.0.1.21

# 2) 未认证访问 Redfish 应返回 401，而不是 200
curl -sk -o /dev/null -w '%{http_code}\n' https://10.20.30.21/redfish/v1/Systems

# 3) IPMI over LAN 关闭后，ipmitool 应直接连接失败
ipmitool -I lanplus -H 10.20.30.21 -U monitor -P 'Monitor#2026' mc info

# 4) 默认账号已删除，账号列表只剩运维与监控两类
curl -sk -u admin:'******' https://10.20.30.21/redfish/v1/AccountService/Accounts \
  | grep -o '"UserName":"[^"]*"'

期望结果：第 1 条无输出或显示 filtered；第 2 条返回 401；第 3 条报连接错误；第 4 条看不到 root、admin、Administrator 之类的默认名。

常见问题

Q1：关掉 IPMI over LAN 后，监控采不到硬件传感器数据怎么办？

监控侧改用 Redfish 采集，不要为了省事把 IPMI 重新打开。Zabbix 有现成的 Redfish 模板，Prometheus 可用 redfish_exporter，只读账号拉取 /redfish/v1/Chassis/*/Thermal 与 /Power 就能拿到温度、风扇、电源、功耗。采集间隔控制在 30 秒以上，BMC 的 CPU 性能有限，高频轮询会导致管理台卡死甚至触发看门狗重启。

Q2：怎么判断 BMC 已经被人动过？

重点看四处：账号列表出现陌生用户，或监控账号权限被改到 Administrator；LC Log 与 SEL 里出现异常时段的登录、虚拟介质挂载、一次性启动项修改；固件版本比资产台账记录的更旧，降级通常意味着有人在刷定制固件；SOL 或 KVM 会话在无人操作时建立。命中任一项，先把 BMC 网络隔离并导出日志，再重置配置、升级固件，最后按「主机可能已被物理接触」评估影响面。

Q3：管理网段没有独立 VLAN，只能和业务网混跑怎么办？

临时方案是在服务器侧用 nftables 限制源地址，把管理台监听绑定到管理口，同时把 BMC 口令换成 20 位以上随机串存入密码库并开启登录失败锁定。真正的解法还是推动网络侧划分管理 VLAN：混跑环境下任何一台业务机被拿下，攻击者都能横向摸到同网段所有 BMC，这是内网横向移动最短的一条路。

总结

BMC 带外管理加固的核心是「网络不可达优先于配置正确」：先把管理口放进独立 VLAN 且只允许跳板机访问，再关闭 IPMI over LAN、SOL 等不用的协议，删默认账号只留管理员与只读监控两类，最后把日志外发、证书换新、固件补齐。这四步做完，服务器最底层的那扇门才算真正关上，也就堵住了绕过操作系统加固的最短路径。