如何在伺服器上設定 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，你的伺服器管理體系才算完整。