Out-of-band správa serveru: IPMI, iDRAC, iLO a Redfish API

Out-of-band správa serveru: IPMI, iDRAC, iLO a Redfish API

Klasický noční příběh service adminů: monitorovací agent zaznamenal výpadek serveru. Všechny indikátory jsou červené, web vrací connection refused, externí probe uzly potvrzují nedostupnost stroje z různých lokalit. Zkoušíte SSH, spojení se nenaváže. Ping neprochází. Podle whitebox metrik ještě do poslední chvíle vypadalo vše normálně: CPU 30 %, RAM 40 %, disk žije. A najednou nic.

Co teď? Objednat Remote Hands u hostingu a čekat 15-40 minut, než někdo přijde server fyzicky zkontrolovat? To je realita, se kterou se potýká většina administrátorů. Existuje ale jiná úroveň přístupu, která funguje právě tehdy, když je operační systém „mrtvý": out-of-band management přes BMC.

Jde o třetí, nejhlubší úroveň kontroly nad serverem, která uzavírá kompletní schéma monitoringu a správy. On-server agenti vidí metriky zevnitř. Externí probe uzly potvrzují dostupnost zvenčí. A out-of-band přístup dává přístup přímo k hardwaru, mimo OS, i když je celý systém úplně zamrzlý.

1. Co je BMC a proč funguje vždy

BMC (Baseboard Management Controller) je samostatný mikropočítač, který fyzicky žije na základní desce serveru, hned vedle hlavního CPU a čipsetu. Má vlastní ARM procesor (obvykle 400-1200 MHz), vlastní operační paměť (256-512 MB u současných generací), samostatný Ethernet řadič s vyhrazeným RJ45 portem, vlastní firmware a vlastní operační systém (zpravidla vestavěný Linux).

Klíčová vlastnost: BMC funguje nezávisle na hlavním systému. Je napájen ze standby linky napájecího zdroje, takže je aktivní i tehdy, když je server „vypnutý" tlačítkem (ve skutečnosti tehdy PSU stále dodává +5V standby). BMC se inicializuje ihned poté, co napájecí zdroj dostane proud ze zásuvky, ještě předtím, než BIOS/UEFI vůbec začne POST, a pokračuje v běhu nezávisle na tom, co se děje s hlavním OS. Kernel panic na Linuxu? BMC funguje. Windows Blue Screen? BMC funguje. Server zamrzl při načítání GRUB? BMC funguje. Napájení samotného serveru je přerušené, ale napájecí zdroj je stále zapojen do zásuvky? BMC funguje.

Právě to dává out-of-band správě jedinečnou hodnotu: nezávisí na ničem kromě fyzického napájení základní desky. Funguje přesně tehdy, kdy jsou všechny ostatní mechanismy monitoringu a správy už bezmocné.

1.1 IPMI jako standard komunikace

Protokol pro komunikaci s BMC se historicky nazývá IPMI (Intelligent Platform Management Interface). Jde o otevřený standard, který Intel, HP, NEC a Dell představili v roce 1998 jako IPMI 1.0. Klíčová vývojová etapa: IPMI 1.5 (2001) přidalo možnost spravovat server po síti přes LAN a serial-over-LAN, IPMI 2.0 (2004) přidalo šifrování přes cipher suites, role uživatelů a vylepšenou autentizaci. Dnes na produkčních serverech běží téměř vždy IPMI 2.0, starší verze zůstaly jen na legacy hardwaru.

IPMI samo o sobě není rozhraní, ale protokol: sada příkazů, které lze BMC odeslat. Komunikace probíhá přes UDP port 623. Přes IPMI lze server zapínat/vypínat, číst teplotní senzory, získávat seznam hardwarových událostí, přistupovat k systémové konzoli. V další kapitole rozebereme, jak konkrétní výrobci (Dell, HPE, Supermicro) tento standard rozšířili vlastními implementacemi a co v 2020. letech začalo IPMI nahrazovat.

2. Implementace u jednotlivých výrobců

Standard IPMI je jednotný, ale každý velký výrobce serverů si na něm postavil vlastní systém s firemním webovým rozhraním, rozšířenou funkcionalitou a samozřejmě vlastním licenčním modelem.

2.1 iDRAC od Dellu

Integrated Dell Remote Access Controller. Standard pro servery PowerEdge. Aktuální generace: iDRAC 9 pro PowerEdge 14.-16. generace (od 2017), iDRAC 10 pro PowerEdge 17. generace (od 2024).

Licencování u Dellu dokáže pořádně potrápit: Express (základní funkce, zdarma se serverem), Enterprise (KVM over IP, virtual media, tedy to, co obvykle potřebujete), Datacenter (rozšířená telemetrie, thermal management, integrace s podnikovými systémy). Enterprise bývá u dedikovaných serverů od hostingových poskytovatelů obvykle už součástí standardní konfigurace, ale při koupi přímo od Dellu jde o samostatnou položku nákladů.

2.2 iLO od HPE

Integrated Lights-Out. Obdoba u serverů ProLiant. Aktuální generace: iLO 5 (Gen10), iLO 6 (Gen11, od 2021), iLO 7 (Gen12, od 2025). Každá nová generace je vázaná na odpovídající generaci serverů HPE.

iLO 7 je v roce 2026 zajímavé několika technickými prvky: quantum-resistant kryptografický firmware (NIST SP800-208), samostatný Silicon Root of Trust jako fyzicky izolovaný bezpečnostní procesor, aktualizované webové rozhraní s dashboardem. Licencování je jednodušší než u Dellu: iLO Standard (zdarma se serverem) a iLO Advanced (KVM over IP, virtual media, rozšířená telemetrie).

2.3 ASMB od ASUSu

ASUS Server Management Board. Řídicí karta instalovaná na serverové základní desky ASUS s podporou BMC socketu. Aktuální modely jsou ASMB9-iKVM a ASMB10-iKVM. Podíl na trhu je menší než u Dellu a HPE, ale mezi menšími systémovými integrátory a v segmentu ASUS ESC (AI/GPU serverů) jsou rozšířené. Zvláštnost ASUSu: KVM over IP, virtual media a Redfish jsou už součástí základního modulu, samostatné licence nejsou potřeba.

2.4 Supermicro BMC

Supermicro nemá marketingový název typu „iDRAC", označuje to prostě jako BMC nebo IPMI. Je to jedna z nejrozšířenějších variant na hostingovém trhu díky nižší ceně desek Supermicro ve srovnání s brandovaným Dell/HPE hardwarem. Webové rozhraní tradičně zaostávalo za konkurencí v použitelnosti, ale v generacích X13/X14 (od 2023) prošlo výraznou aktualizací. U licencování jsou nuance: základní KVM over IP a samotný webový přístup jsou zdarma už od generací X10. Virtual Media přes HTML5 konzoli (tedy mountování ISO přímo z prohlížeče) ale vyžaduje samostatný klíč SFT-DCMS-SINGLE. Základní funkce Redfish API jsou dostupné rovnou, část rozšířených endpointů rovněž vyžaduje licenci. Pro běžný provoz to není kritické, ale je dobré to vědět dopředu, pokud plánujete intenzivní automatizaci.

2.5 Srovnávací tabulka

3. Co konkrétně dává out-of-band správa

Teď, když je jasné, jak to funguje na hardwarové úrovni, rozebereme, co konkrétně administrátor v praxi získá.

3.1 KVM over IP – konzole, když je OS mrtvý

Toto je funkce, kvůli které má out-of-band přístup smysl ve většině reálných havárií. KVM over IP znamená, že vidíte video výstup serveru, jako byste fyzicky seděli před monitorem k němu připojeným. Klávesnice a myš se přesměrovávají z vašeho klienta na BIOS/OS serveru přes síť.

Klíčové je, že to funguje na úrovni hardwaru. Vidíte POST logy při startu, menu BIOS/UEFI, GRUB, fáze startu OS. Pokud Linux zamrzne při startu a zobrazí zprávu kernel panic na konzoli, uvidíte ji doslovně, s čísly řádků kódu a stack trace. Pokud Windows vyhodí Blue Screen, uvidíte ho s kódem chyby. Jde o diagnostické informace nedostupné žádnou jinou metodou.

3.2 Vzdálená správa napájení

Přes BMC jsou dostupné všechny varianty ovládání napájení:

• Power on: zapnutí serveru, když je vypnutý
• Power off: tvrdé vypnutí (jako držení tlačítka)
• Graceful shutdown: korektní vypnutí přes ACPI signál OS
• Power cycle: vypnutí a zapnutí (pro případy, kdy reset nepomáhá)
• Warm reset: restart bez přerušení napájení (ekvivalent fyzického tlačítka reset na skříni)

Toto je záchranné kolo v případech, kdy je OS úplně zamrzlý. SSH neodpovídá, ping neprochází, konzole visí. Ale pomocí tlačítka reset přes BMC můžete stroj restartovat za 2 minuty bez výjezdu do datacentra.

3.3 Virtual Media – mountování ISO obrazů

Velmi silná funkce pro scénáře „potřebuji přeinstalovat OS na vzdáleném serveru". ISO obraz (například Ubuntu Server 24.04 nebo Rocky Linux 9) stáhnete na svůj pracovní stroj nebo HTTP server, ve webovém rozhraní BMC ho „připojíte" jako virtuální CD/DVD a server tento ISO vidí, jako by do něj bylo fyzicky vloženo CD.

Dál: restartujete server přes BMC, v BIOSu zvolíte virtuální CD jako boot zařízení, nainstalujete OS. Vše z domova, bez výjezdu. Takto hostingoví poskytovatelé ve skutečnosti implementují tlačítko „reinstall OS" ve svém panelu: automatizují přesně tento proces přes API.

3.4 Monitoring hardwaru

BMC čte všechny hardwarové senzory základní desky a v reálném čase ukládá jejich stav. To zahrnuje:

• Teploty CPU, čipsetu, jednotlivých zón základní desky
• Otáčky všech ventilátorů (chassis fans, CPU coolers, PSU fans)
• Stav napájecích zdrojů: funkčnost, spotřeba
• Napětí na všech klíčových linkách (+12V, +5V, +3,3V, VRM pro CPU)
• Stav operační paměti: chyby ECC na konkrétních DIMM slotech
• SMART hodnoty disků přes RAID řadič (pokud je k dispozici)

Hodnota zde není v samotných datech (lze je získat i přes IPMI nástroje v OS), ale v tom, že jsou dostupná nezávisle na stavu OS. Pokud server zamrzl kvůli přehřátí CPU, uvidíte to ve webovém rozhraní BMC dřív, než OS vůbec začne dávat jakékoli známky života.

3.5 System Event Log (SEL)

BMC vede trvalý žurnál hardwarových událostí: zapnutí/vypnutí, změny stavu senzorů (například „teplota CPU překročila práh warning"), průběh POST fází, detekci/absenci komponent (například „napájecí zdroj 2 odpojen"). Tento žurnál přežívá restart a dokonce úplnou absenci napájení (ukládá se do NVRAM samotného BMC).

Pro diagnostiku po incidentu bývá SEL často cennější než systémové logy OS: pokud došlo k přehřátí nebo výpadku napájení, bude to zde vidět s přesným timestampem, zatímco žurnál OS může být poškozený nebo přerušený.

3.6 POST logy a boot diagnostika

BMC ukládá poslední obrazovku POST před startem OS a logy raných fází bootu. To zachraňuje situace typu „server se nespouští a nevíme, v jaké přesně fázi uvízl". Přes BMC vidíte: zda proběhla inicializace CPU, zda byla nalezena paměť, zda byl nalezen diskový řadič, zda byl nalezen boot disk, zda naskočil UEFI/BIOS bootloader.

4. Základní nastavení

Projdeme minimálně nutné kroky k tomu, aby byl BMC užitečný a bezpečný. Na pořadí záleží: pokud ho prohodíte, buď získáte nedostupný BMC, nebo necháte otevřený perimetr pro útoky.

4.1 Vyhrazené síťové rozhraní

Většina serverových základních desek nabízí pro BMC dvě síťové varianty: shared (sdílené s hlavním LAN portem serveru) a dedicated (samostatný fyzický RJ45 konektor, označený jako „BMC", „IPMI", „iLO", „iDRAC").

Používejte dedicated. Shared režim je pohodlný, když má server málo portů, ale vytváří problém: provoz BMC jde přes stejnou síťovou kartu jako provoz OS, takže pokud zamrzne síťový stack OS, stane se nedostupným i BMC. V produkční konfiguraci je to nepřípustné.

4.2 Izolovaná management VLAN

Vyhrazený port je třeba zapojit ne do stejné VLAN jako produkční provoz, ale do samostatné management VLAN, izolované od veřejné sítě na úrovni switche. Důvod je prostý: rozhraní BMC měla historicky velké množství zranitelností ve webových serverech a IPMI stacích. Pokud je BMC dostupný z internetu, hrajete ruskou ruletu se statistikou CVE.

Minimální bezpečné schéma: porty BMC všech serverů zapojené do vyhrazeného switche nebo samostatné VLAN, přístup do této VLAN jen přes bastion host nebo VPN. Žádný přímý NAT z veřejné IP na BMC.

4.3 První přihlášení a změna výchozích přihlašovacích údajů

Každý BMC přichází z výroby s výchozím heslem. U Dell iDRAC je login vždy `root`, heslo se u současných PowerEdge (od iDRAC 9 a novějších) generuje unikátně pro každý server a je vytištěné na výsuvném Service Tagu vpředu skříně; legendární historické heslo `calvin` je teď třeba výslovně objednat samostatně kvůli kompatibilitě s legacy skripty. U HPE iLO se heslo rovněž generuje náhodně a je vytištěné na štítku přímo na serveru. U Supermicro bylo výchozí historicky ADMIN/ADMIN, ale u nových modelů (X13/X14) se už používá unikátní heslo ze štítku.

Úplně první věc, kterou po prvním připojení uděláte, je změna hesla. Ne „později", ne „až budu mít čas", ale hned teď. Výchozí hesla BMC jsou jedním z nejoblíbenějších cílů automatizovaných skenerů: pokud se BMC kvůli náhodě nebo chybě konfigurace na okamžik stal dostupným z internetu s výchozím heslem, plná kontrola nad serverem bude ztracena během minut.

4.4 Samostatný uživatel s minimálními právy

Po změně hesla root/admin vytvořte samostatného uživatele s omezenými právy pro každodenní úkoly. Logika je stejná jako u Linuxu: nepracujte jako root tam, kde stačí sudo. V BMC bývá gradace práv: read-only (pouze náhled), user (náhled + power management), operator (plus KVM), administrator (vše včetně správy uživatelů).

Pro většinu každodenních úkolů stačí operator. Root účet ponechte pro kritické scénáře a jeho přihlašovací údaje uchovávejte v samostatném secure storage (KeePass, 1Password Business).

4.5 Aktualizace firmwaru BMC

Firmware BMC se aktualizuje odděleně od BIOS/UEFI a odděleně od OS. Je důležité si to uvědomit: pokud si myslíte, že „server pravidelně aktualizujete", týká se to OS, ne BMC. Firmware BMC je třeba aktualizovat ručně přes webové rozhraní nebo přes speciální vendorské nástroje.

Optimální frekvence: kontrolovat aktualizace jednou za čtvrtletí, instalovat s určitým zpožděním (2-4 týdny po vydání), aby měl výrobce čas vydat hotfix, pokud release obsahuje kritické bugy. Výjimkou jsou critical security releases (například když se objeví reference exploit): ty je třeba nasadit rychleji, v plánovaném maintenance okně nejbližších dnů.

5. Bezpečnost BMC jako samostatné téma

BMC si zaslouží samostatnou pozornost z hlediska bezpečnosti. Kompromitovaný BMC je nejhorší scénář, který se serveru může stát: útočník získá plnou kontrolu nad hardwarem, včetně možnosti přeinstalovat OS, číst/zapisovat přímo do paměti, sledovat boot, instalovat firmware rootkit, který přežije přeinstalaci OS.

5.1 Izolovaná síť – nejde o doporučení, ale o požadavek

Opakuji, protože je to kritické: BMC nesmí být dostupný z veřejného internetu. Nikdy. Za žádných okolností. Nejde o radu z „best practices", jde o základní hygienu.

Realita je trochu horší: podle dat ze Shodanu jsou pravidelně skenovány desítky tisíc rozhraní BMC s otevřenými porty na internetu. Mnoho z nich má výchozí hesla nebo zastaralý firmware se známými CVE. Každý z těchto serverů je něčí produkční systém, který se nachází na hraně úplné kompromitace.

5.2 Firewall i v management síti

I v izolované management VLAN se vyplatí mít firewall pravidla: přístup na adresy BMC jen z konkrétních admin-workstation IP nebo z bastion hostu. To chrání před scénářem, kdy útočník už má přístup k jednomu ze strojů v management síti a snaží se rozšířit útok na BMC dalších serverů.

5.3 Zranitelnosti BMC – reálný problém, ne teorie

Nejde o abstraktní hrozbu. Čerstvé příklady:

• CVE-2024-54085: kritická zranitelnost v AMI MegaRAC BMC (používá Supermicro, Gigabyte, ASRock Rack, Lenovo a další), přidaná do CISA Known Exploited Vulnerabilities Catalog v roce 2025. Umožňuje neautorizovaný authentication bypass.
• CVE-2024-10237: signature verification bypass v mechanismu aktualizace firmwaru Supermicro BMC. Útočník může nainstalovat upravený firmware, který vypadá legitimně.
• CVE-2025-6198: rozšíření předchozí třídy zranitelností v Supermicro BMC, umožňuje instalaci persistentního malwaru do firmwaru BMC, který přežije přeinstalaci OS.

Vzorec se opakuje: firmware BMC má velký attack surface (webový server, IPMI stack, virtual media handler), vyvíjí se ve firmwarovém modelu bez mnoha moderních bezpečnostních praktik, a přitom má nejvyšší úroveň přístupu k systému. To vytváří třídu útoků, kterou je výrazně těžší odhalit a napravit než běžné kompromitace na úrovni OS.

5.4 Minimalizace attack surface

Vypněte vše, co nepoužíváte. Typický checklist:

• Vypnout IPMI over LAN, pokud používáte pouze Redfish
• Vypnout SNMP, pokud není integrováno do monitoringu
• Vypnout SSH přístup k BMC, pokud ho nepotřebujete pro automatizaci
• Vypnout anonymní login ve webovém rozhraní (u některých výrobců zapnuto ve výchozím stavu)
• Používat HTTPS s platným certifikátem (lze i Let's Encrypt přes ACME pro management doménu)
• Zapnout 2FA nebo TOTP, pokud to BMC podporuje (iLO 6+, iDRAC 9+)

6. Minimálně přijatelná konfigurace

Stručné shrnutí toho, pod co byste v produkci neměli klesat:

Povinné

• Dedicated síťový port pro BMC, ne shared s OS
• Izolovaná management VLAN, nedostupná z veřejného internetu
• Změněné výchozí přihlašovací údaje při prvním přihlášení
• Aktuální firmware BMC (ne starší než 6-12 měsíců)
• Samostatný admin uživatel s logováním akcí, root jen pro havárie

Doporučené

• Firewall pravidla na úrovni management sítě (přístup jen z admin IP)
• 2FA/TOTP pro webové rozhraní
• Redfish API místo IPMI pro automatizaci
• Centralizovaný monitoring stavu BMC (dostupnost, verze firmwaru, změny konfigurace)
• Pravidelné plánované aktualizace firmwaru s maintenance oknem

Typické chyby

• BMC na veřejné IP. Klasika žánru. Za 2-3 dny už ho skenují a brute-forcují.
• Výchozí hesla. „Dočasně, než nastavím všechno ostatní": pak se na to zapomene.
• Zastaralý firmware. „Stejně to funguje, proč aktualizovat": do prvního zveřejnění CVE.
• Sdílená síť. Ušetřili jste port, ale BMC spadne spolu s OS.
• Jeden admin účet pro všechny adminy. Nelze auditovat, kdo co dělal.

7. Shrnutí: třívrstvý model plné kontroly

Out-of-band správa není samostatná technologie, ale logické završení třívrstvého modelu, ve kterém každá vrstva funguje právě tehdy, kdy je ta předchozí už bezmocná:

• On-server whitebox monitoring dává hloubku: metriky CPU, RAM, disku, logy aplikací. Funguje, dokud OS žije.
• Externí blackbox monitoring dává nezávislost na serveru: agenti z jiných lokalit pingují službu a zaznamenávají, kdy je nedostupná. Funguje, dokud žije alespoň síť.
• Out-of-band přes BMC dává přístup přímo k hardwaru: KVM, power control, virtual media, hardwarové senzory. Funguje, dokud má základní deska fyzické napájení.

Dohromady tyto tři vrstvy pokrývají téměř všechny možné scénáře výpadku: od zamrznutí konkrétní aplikace po úplnou kernel panic, od síťového blackoutu v datacentru po hardwarové poruchy CPU a paměti. Bez kterékoli z nich bude ve vašem schématu slepé místo.

Co si z tohoto článku odnést do praxe:

• BMC není volitelná doplňková funkce, ale základní součást produkčního serveru. Pokud máte dedikovaný server bez out-of-band přístupu, nemáte nad infrastrukturou plnou kontrolu.
• Minimální bezpečná konfigurace ve 4 krocích: dedicated port, izolovaná VLAN, změněná hesla, aktuální firmware. Vše ostatní už je volitelné.
• Zranitelnosti BMC jsou reálný problém s reálnými CVE z let 2024/2025. Přeskakovat aktualizace firmwaru BMC je nebezpečnější než přeskakovat aktualizace OS, protože uvést systém do bezpečného stavu po kompromitaci BMC je o řád složitější.

Tento článek pokryl základy: co BMC je, jak funguje u různých výrobců, jak ho nastavit a zabezpečit. Další velké téma: praktická práce přes CLI a automatizace – použití ipmitool pro správu z shell skriptů, práce s Redfish API pro integraci do CI/CD, sběr BMC metrik do Prometheus/Grafana, automatická aktualizace firmwaru přes Ansible playbook. To je už každodenní inženýrská práce, kterou rozebereme samostatně.

Časté dotazy