Out-of-band управління сервером: IPMI, iDRAC, iLO та Redfish API

Out-of-band управління сервером: IPMI, iDRAC, iLO та Redfish API

Класична нічна історія у чергового адміністратора: агент моніторингу зафіксував падіння сервера. Всі індикатори червоні, сайт віддає connection refused, зовнішні probe-ноди підтверджують, що машина недоступна з різних локацій. Заходите по SSH, з'єднання не встановлюється. Пінг не проходить. За whitebox-даними до останнього моменту все виглядало нормально: CPU 30%, RAM 40%, диск живий. І раптом нічого.

Що робити? Замовляти послугу Remote Hands у хостера, чекати 15-40 хвилин, поки хтось підійде до сервера і фізично його огляне? Це реальність, з якою стикається більшість адміністраторів. Але існує інший рівень доступу, який працює саме тоді, коли операційна система «мертва»: out-of-band management через BMC.

Це третій, найглибший рівень контролю над сервером, який замикає повну схему моніторингу і управління. On-server агенти бачать метрики зсередини. Зовнішні probe-ноди фіксують доступність ззовні. А out-of-band дає доступ до самого заліза, повз ОС, навіть якщо вся система повністю заморожена.

1. Що таке BMC і чому це працює завжди

BMC (Baseboard Management Controller) це окремий мікрокомп'ютер, який фізично живе на материнській платі сервера, поруч з основними CPU і чіпсетом. У нього власний ARM-процесор (зазвичай 400-1200 МГц), власна оперативна пам'ять (256-512 МБ у сучасних поколіннях), окремий Ethernet-контролер з виділеним RJ45-портом, власна прошивка (firmware) і власна операційна система (як правило, вбудований Linux).

Ключова властивість: BMC працює незалежно від основної системи. Він живиться від standby-лінії блока живлення, тому активний навіть тоді, коли сервер «вимкнений» кнопкою (насправді тоді PSU все одно подає +5V standby). BMC ініціалізується одразу як тільки блок живлення отримав живлення з розетки — ще до того як BIOS/UEFI взагалі починає POST, і продовжує працювати незалежно від того, що відбувається з основною ОС. Kernel panic на Linux? BMC працює. Windows Blue Screen? BMC працює. Сервер завис при завантаженні GRUB? BMC працює. Живлення на самому сервері обірвалося, але блок живлення все ще під'єднаний до розетки? BMC працює.

Це і дає out-of-band управлінню унікальну цінність: він не залежить ні від чого, крім фізичного живлення материнської плати. Тобто працює саме тоді, коли всі інші механізми моніторингу і управління вже безсилі.

1.1 IPMI як стандарт взаємодії

Історично протокол взаємодії з BMC називається IPMI (Intelligent Platform Management Interface). Це відкритий стандарт, який Intel, HP, NEC та Dell представили у 1998 році як IPMI 1.0. Ключова еволюція: IPMI 1.5 (2001) додала можливість керувати сервером по мережі через LAN і serial-over-LAN, а IPMI 2.0 (2004) додала шифрування через cipher suites, ролі користувачів і покращену автентифікацію. Сьогодні на серверах у продакшн-використанні майже завжди IPMI 2.0, старіші версії лишилися хіба на легасі-залізі.

IPMI сам по собі це не інтерфейс, а протокол: набір команд, які можна надіслати BMC. Комунікація йде через UDP-порт 623. Через IPMI можна вмикати/вимикати сервер, читати сенсори температури, отримувати список hardware-подій, отримувати доступ до системної консолі. У наступному розділі ми окремо розберемо, як конкретні вендори (Dell, HPE, Supermicro) розширили цей стандарт власними реалізаціями і що прийшло на зміну IPMI у 2020-х.

2. Варіанти реалізації: як це виглядає у різних вендорів

Стандарт IPMI єдиний, але кожен великий виробник серверів побудував поверх нього власну систему з фірмовим веб-інтерфейсом, розширеним функціоналом і, звичайно, власною системою ліцензування.

2.1 iDRAC від Dell

Integrated Dell Remote Access Controller. Стандарт для PowerEdge-серверів. Актуальні покоління: iDRAC 9 для PowerEdge 14-16 поколінь (з 2017 року), iDRAC 10 для PowerEdge 17-го покоління (з 2024 року).

Ліцензування у Dell дійсно здатне попсувати нерви: Express (базові функції, безкоштовно з сервером), Enterprise (KVM over IP, virtual media, тобто те, що зазвичай треба), Datacenter (розширена телеметрія, thermal management, integration з корпоративними системами). Enterprise зазвичай вже включена в стандартну комплектацію dedicated серверів у хостинг-провайдерів, але при купівлі напряму у Dell це окрема стаття витрат.

2.2 iLO від HPE

Integrated Lights-Out. Аналог у ProLiant-серверах. Актуальні покоління: iLO 5 (Gen10), iLO 6 (Gen11, з 2021), iLO 7 (Gen12, з 2025). Кожне нове покоління прив'язане до відповідного покоління серверів HPE.

iLO 7 у 2026 році цікаве кількома технічними моментами: quantum-resistant крипто-прошивка (NIST SP800-208), окремий Silicon Root of Trust як фізично ізольований security-процесор, оновлений веб-інтерфейс з дашбордом. Ліцензування простіше ніж у Dell: iLO Standard (безкоштовно з сервером) і iLO Advanced (KVM over IP, virtual media, розширена телеметрія).

2.3 ASMB від ASUS

ASUS Server Management Board. Плата керування, що встановлюється на серверні материнські плати ASUS з підтримкою BMC-сокета. Актуальні моделі — ASMB9-iKVM і ASMB10-iKVM. Ринкова частка менша, ніж у Dell і HPE, але серед менших системних інтеграторів і у сегменті ASUS ESC (AI/GPU-серверів) вони поширені. Особливість ASUS: KVM over IP, virtual media і Redfish уже входять в базову комплектацію модуля, окремі ліцензії не потрібні.

2.4 Supermicro BMC

Supermicro не має маркетингової назви на кшталт «iDRAC», вони називають це просто BMC або IPMI. Це один з найпоширеніших варіантів на ринку хостингу через нижчу ціну плат Supermicro порівняно з брендованими Dell/HPE. Веб-інтерфейс традиційно поступався конкурентам за юзабіліті, але у X13/X14-поколіннях (з 2023 року) його суттєво оновили. З ліцензуванням є нюанси: базовий KVM over IP і сам веб-доступ безкоштовні починаючи ще з X10-поколінь. А ось Virtual Media через HTML5-консоль (тобто монтування ISO прямо з браузера) вимагає окремий ключ SFT-DCMS-SINGLE. Для Redfish API базові функції доступні відразу, а частина розширених endpoint-ів так само потребує ліцензії. Це не критично для повсякденної роботи, але треба знати заздалегідь, якщо планується активна автоматизація.

2.5 Порівняльна таблиця

3. Що конкретно дає out-of-band управління

Тепер, коли зрозуміло, як це працює апаратно, розберемо що саме адміністратор отримує на практиці.

3.1 KVM over IP — консоль коли ОС мертва

Це та функція, заради якої out-of-band має сенс у більшості реальних аварій. KVM over IP означає, що ви бачите відеовихід сервера так, ніби фізично сидите перед монітором, підключеним до нього. Клавіатура і мишка перенаправляються з вашого клієнта на BIOS/ОС сервера через мережу.

Ключове тут: це працює на рівні заліза. Ви бачите POST-логи при завантаженні, BIOS/UEFI меню, GRUB, стадії старту ОС. Якщо Linux завис при завантаженні і показує kernel panic-повідомлення на консолі, ви побачите його дослівно, з номерами рядків коду і stack trace. Якщо Windows видає Blue Screen, ви побачите його з кодом помилки. Це діагностична інформація, недоступна ніякими іншими методами.

3.2 Remote power management

Через BMC доступні всі варіанти керування живленням:

• Power on: увімкнути сервер, коли він вимкнений
• Power off: жорстке вимкнення (як натиснути кнопку і тримати)
• Graceful shutdown: коректне вимкнення через ACPI-сигнал ОС
• Power cycle: вимкнення і увімкнення (для випадків, коли reset не допомагає)
• Warm reset: перезавантаження без переривання живлення (еквівалент фізичної кнопки reset на корпусі)

Це рятівне коло у випадках, коли ОС повністю заморожена. SSH не відповідає, ping не проходить, консоль підвисла. Але кнопкою reset через BMC ви за 2 хвилини можете перезавантажити машину без виїзду в дата-центр.

3.3 Virtual Media — монтування ISO-образів

Дуже потужна функція для сценаріїв «треба переставити ОС на віддаленому сервері». Ви завантажуєте ISO-образ (наприклад, Ubuntu Server 24.04 або Rocky Linux 9) до себе на робочу машину або на HTTP-сервер, у веб-інтерфейсі BMC «монтуєте» його як віртуальний CD/DVD, і сервер бачить цей ISO так, ніби у нього фізично вставили CD.

Далі: перезавантажуєте сервер через BMC, у BIOS обираєте віртуальний CD як boot-пристрій, встановлюєте ОС. Все з дому, без виїзду. Це те, як хостинг-провайдери насправді роблять «reinstall OS» через панель: вони автоматизують саме цей процес через API.

3.4 Моніторинг заліза

BMC читає всі hardware-сенсори материнської плати і зберігає їх стан в реальному часі. Це включає:

• Температури CPU, чіпсету, окремих зон материнської плати
• Оберти всіх вентиляторів (chassis fans, CPU coolers, PSU fans)
• Стан блоків живлення: справність, потужність споживання
• Напруги на всіх ключових лініях (+12V, +5V, +3.3V, VRM для CPU)
• Стан оперативної пам'яті: помилки ECC на конкретних DIMM-слотах
• SMART-показники дисків через RAID-контролер (якщо є)

Цінність тут не в самих даних (їх також можна отримати через IPMI-tools в ОС), а в тому, що вони доступні незалежно від стану ОС. Якщо сервер завис через перегрів CPU, ви це побачите у веб-інтерфейсі BMC ще до того, як ОС взагалі почне подавати ознаки життя.

3.5 System Event Log (SEL)

BMC веде постійний журнал апаратних подій: включення/вимкнення, зміни стану сенсорів (наприклад, «температура CPU перевищила поріг warning»), проходження POST-етапів, детект/відсутність компонентів (наприклад, «блок живлення 2 відключений»). Цей журнал переживає перезавантаження і навіть повну відсутність живлення (зберігається у NVRAM самого BMC).

Для діагностики після інциденту SEL часто цінніший за системні логи ОС: якщо був перегрів або збій живлення, це буде видно тут з точним таймстампом, тоді як журнал ОС може бути пошкоджений або обірваний.

3.6 POST-логи і boot-діагностика

BMC зберігає останній екран POST перед завантаженням ОС і логи ранніх стадій boot. Це рятує ситуації типу «сервер не завантажується, а ми не можемо зрозуміти на якій саме стадії». Через BMC ви бачите: чи пройшла ініціалізація CPU, чи знайдено пам'ять, чи знайдено дисковий контролер, чи знайдено boot-диск, чи стартував UEFI/BIOS-завантажник.

4. Базове налаштування

Розберемо мінімально необхідні кроки для того, щоб BMC був корисним і безпечним. Порядок важливий: якщо переставити місцями, ви або отримаєте недоступний BMC, або залишите відкритий периметр для атак.

4.1 Виділений мережевий інтерфейс

Більшість серверних материнських плат мають два варіанти мережі для BMC: shared (спільний з основним LAN-портом сервера) і dedicated (окремий фізичний RJ45-роз'єм, підписаний як «BMC», «IPMI», «iLO», «iDRAC»).

Використовуйте dedicated. Shared режим зручний, коли у сервері мало портів, але він створює проблему: BMC-трафік йде через ту саму мережеву карту, що і трафік ОС, тобто якщо у сервері зависне мережевий стек ОС, BMC теж стане недоступний. У продакшн-конфігурації це недопустимо.

4.2 Ізольована management VLAN

Виділений порт треба вставляти не в ту саму VLAN, що і продакшн-трафік, а в окрему management VLAN, яка ізольована від публічної мережі на рівні комутатора. Причина проста: BMC-інтерфейси історично мають велику кількість вразливостей у веб-серверах і IPMI-стеках. Якщо BMC доступний з інтернету, ви граєте в російську рулетку з CVE-статистикою.

Мінімальна безпечна схема: BMC-порти всіх серверів підключені у виділений комутатор або окрему VLAN, доступ до цієї VLAN тільки через bastion-host або VPN. Ніякого прямого NAT-у з публічного IP на BMC.

4.3 Перший вхід і зміна default credentials

Кожен BMC приходить з завода з дефолтним паролем. У Dell iDRAC логін завжди `root`, а пароль на сучасних PowerEdge (з iDRAC 9 і новіше) генерується унікальним для кожного сервера і друкується на висувному Service Tag спереду корпуса; легендарний історичний пароль `calvin` тепер треба явно замовляти окремо для сумісності з legacy-скриптами. У HPE iLO пароль теж генерується випадковий і друкується на етикетці на самому сервері. У Supermicro за замовчуванням історично було ADMIN/ADMIN, але у нових моделях (X13/X14) вже використовується унікальний пароль з етикетки.

Найперше, що ви робите після першого підключення, це змінюєте пароль. Не «пізніше», не «як зможу», а прямо зараз. Дефолтні паролі BMC це одна з найпопулярніших цілей автоматизованих сканерів: якщо через випадковість або помилку конфігурації BMC на якусь мить став доступний з інтернету з дефолтним паролем, повний контроль над сервером буде втрачений за хвилини.

4.4 Окремий користувач з мінімальними правами

Після зміни root/admin пароля створіть окремого користувача з обмеженими правами для щоденних задач. Логіка та сама, що і в Linux: не працюйте від root там, де досить sudo. У BMC зазвичай є градація прав: read-only (тільки перегляд), user (перегляд + power management), operator (плюс KVM), administrator (все, включно з керуванням користувачами).

Для більшості щоденних задач достатньо operator. Root-акаунт лишіть для критичних сценаріїв і зберігайте його credentials у окремому secure storage (KeePass, 1Password Business).

4.5 Оновлення firmware BMC

BMC firmware оновлюється окремо від BIOS/UEFI і окремо від ОС. Це важливо усвідомлювати: якщо ви думаєте, що «регулярно оновлюєте сервер», це стосується ОС, але не BMC. Firmware BMC треба оновлювати вручну через веб-інтерфейс або через спеціальні вендорські інструменти.

Оптимальна частота: перевіряти оновлення раз на квартал, встановлювати з певним лагом (2-4 тижні після релізу), щоб дати вендору час випустити hotfix, якщо у релізі є критичні баги. Виняток становлять critical security releases (наприклад, коли з'являється reference exploit): їх треба ставити швидше, у планове maintenance-вікно найближчих днів.

5. Безпека BMC як окрема тема

BMC заслуговує окремої уваги з точки зору безпеки. Скомпрометований BMC це найгірший сценарій, який може статися з сервером: атакувальник отримує повний контроль над залізом, включно з можливістю переставити ОС, читати/писати у пам'ять напряму, стежити за завантаженням, встановлювати firmware-rootkit, який виживає перевстановлення ОС.

5.1 Ізольована мережа — не рекомендація, а вимога

Повторюся, бо це критично: BMC не повинен бути доступний з публічного інтернету. Ніколи. За жодних обставин. Це не порада з «best practices», це базова гігієна.

Реальність трохи гірша: за даними Shodan регулярно скануються десятки тисяч BMC-інтерфейсів з відкритими портами в інтернеті. Багато з них із дефолтними паролями або застарілим firmware з відомими CVE. Кожен з цих серверів це чиясь виробнича система, яка перебуває на межі повної компрометації.

5.2 Firewall навіть у management мережі

Навіть у ізольованій management VLAN варто мати firewall-правила: доступ до BMC-адрес тільки з конкретних admin-workstation IP або з bastion-host. Це захищає від сценарію, коли зловмисник вже отримав доступ до однієї з машин у management-мережі і намагається розширити атаку на BMC інших серверів.

5.3 BMC-вразливості — реальна проблема, не теорія

Це не абстрактна загроза. Свіжі приклади:

• CVE-2024-54085: критична вразливість в AMI MegaRAC BMC (використовується Supermicro, Gigabyte, ASRock Rack, Lenovo серед інших), додана до CISA Known Exploited Vulnerabilities Catalog у 2025. Дозволяє неавторизований authentication bypass.
• CVE-2024-10237: signature verification bypass у Supermicro BMC firmware update mechanism. Атакувальник може встановити модифіковану прошивку, яка виглядає легітимно.
• CVE-2025-6198: розширення попереднього класу вразливостей у Supermicro BMC, дозволяє встановити persistent malware в BMC-firmware, який виживає перевстановлення ОС.

Патерн повторюється: BMC-firmware має великий attack surface (веб-сервер, IPMI-стек, virtual media handler), розробляється у прошивковій моделі без багатьох сучасних безпекових практик, і при цьому має найвищий рівень доступу до системи. Це створює клас атак, який значно важче виявити і виправити, ніж звичайні OS-level компрометації.

5.4 Мінімізація attack surface

Вимкніть все, що не використовуєте. Typical checklist:

• Вимкнути IPMI over LAN, якщо ви використовуєте тільки Redfish
• Вимкнути SNMP, якщо не інтегровано в моніторинг
• Вимкнути SSH-доступ до BMC, якщо не потрібен для автоматизації
• Вимкнути анонімний login у веб-інтерфейсі (у деяких вендорів увімкнено за замовчуванням)
• Використовувати HTTPS з валідним сертифікатом (можна навіть Let's Encrypt через ACME для management-домена)
• Увімкнути 2FA або TOTP, якщо BMC підтримує (iLO 6+, iDRAC 9+)

6. Мінімально прийнятна конфігурація

Якщо коротко резюмувати те, нижче чого опускатися не варто у продакшні:

Обов'язково

• Dedicated мережевий порт для BMC, не shared з ОС
• Ізольована management VLAN, недоступна з публічного інтернету
• Змінені default credentials на першому ж вході
• Актуальний BMC firmware (не старіше 6-12 місяців)
• Окремий адмінський користувач з логуванням дій, root тільки для аварій

Бажано

• Firewall-правила на рівні management-мережі (доступ тільки з admin-IP)
• 2FA/TOTP для веб-інтерфейсу
• Redfish API замість IPMI для автоматизації
• Централізований моніторинг стану BMC (доступність, версія firmware, зміни конфігурації)
• Регулярні планові оновлення firmware з maintenance-вікном

Типові помилки

• BMC на публічному IP. Класика жанру. Через 2-3 дні вже сканують і брутфорсять.
• Дефолтні паролі. «Тимчасово, поки не налаштую все інше»: потім забувають.
• Застарілий firmware. «Все ж працює, навіщо оновлювати»: до першої публікації CVE.
• Shared мережа. Заощадили порт, а BMC відвалюється разом з ОС.
• Один admin-акаунт на всіх адмінів. Неможливо аудитити, хто що робив.

7. Підсумок: трирівнева схема повного контролю

Out-of-band управління це не окрема технологія, а логічне завершення трирівневої моделі, у якій кожен рівень працює тоді, коли попередній вже безсилий:

• On-server whitebox моніторинг дає глибину: метрики CPU, RAM, диску, логи додатків. Працює, поки ОС жива.
• Зовнішній blackbox моніторинг дає незалежність від сервера: агенти з інших локацій пінгують сервіс і фіксують, коли він недоступний. Працює, поки жива хоча б мережа.
• Out-of-band через BMC дає доступ до самого заліза: KVM, power control, virtual media, hardware sensors. Працює, поки є фізичне живлення материнської плати.

Разом ці три рівні закривають майже всі можливі сценарії збою: від зависання конкретного додатку до повної кернел-паніки, від мережевого блекауту у ДЦ до апаратних відмов CPU і пам'яті. Без будь-якого з них у вашій схемі буде сліпа пляма.

Що варто винести з цієї статті у практику:

• BMC це не додаткова опція, а базова частина продакшн-серверу. Якщо у вас dedicated-сервер без out-of-band доступу, це неповний контроль над інфраструктурою.
• Мінімальна безпечна конфігурація за 4 кроки: dedicated порт, ізольована VLAN, змінені паролі, актуальний firmware. Все інше вже опція.
• BMC-вразливості реальна проблема з реальними CVE-2024/2025. Пропускати оновлення firmware BMC небезпечніше, ніж пропускати оновлення ОС, бо привести систему у безпечний стан після компрометації BMC на порядок складніше.

Ця стаття покрила базу: що таке BMC, як він працює у різних вендорів, як його налаштувати і захистити. Наступна велика тема: практична робота через CLI і автоматизація: використання ipmitool для управління з shell-скриптів, робота з Redfish API для інтеграції у CI/CD, збирання BMC-метрик у Prometheus/Grafana, автоматичне оновлення firmware через Ansible-playbook. Це вже інженерна щоденна робота, яку розберемо окремо.

Часті питання