BMC — автономный контроллер управления, который работает независимо от основной ОС, круглосуточно: включает и перезагружает сервер, собирает показания датчиков, даёт доступ к консоли. Когда таких машин у компании десятки или сотни, ехать к каждой при инциденте — нереально. На помощь приходит IPMI — стандарт удаленного управления сервером, который работает поверх отдельного управляющего контроллера и доступен даже при выключенной ОС. В статье разберем, как устроен BMC, чем отличается IPMI от современного Redfish, как правильно подключать management-сеть (dedicated NIC vs shared), как защититься от типовых атак на cipher 0 и дефолтные пароли, и чем заменить iDRAC после ухода западных вендоров из РФ.
Что такое IPMI и BMC простым языком
Сначала разберемся с базовой архитектурой — что именно работает внутри сервера и через какой интерфейс мы к нему обращаемся.
BMC: маленький компьютер внутри сервера
BMC (Baseboard Management Controller) — это отдельный SoC на материнской плате сервера. У него собственное CPU (как правило, ARM-ядро), собственная RAM на 256–512 МБ, собственная встроенная прошивка и собственный сетевой интерфейс. BMC работает даже когда основной сервер выключен — нужно только дежурное питание блока питания. То есть это, по сути, маленький компьютер внутри большого, который занимается обслуживанием хоста.
IPMI: протокол управления, заложенный в BMC
IPMI (Intelligent Platform Management Interface) — это сетевой протокол, разработанный Intel в 1998 году, по которому администратор обращается к BMC. Через IPMI можно включить или выключить сервер, перезагрузить его, посмотреть температуру, считать журнал событий, открыть удаленную консоль. Актуальная версия — IPMI 2.0 (с 2004 года). Стандартный порт — 623/UDP по протоколу RMCP+. Утилиты для работы — ipmitool и ipmiutil под Linux, родные клиенты вендоров под Windows.
Redfish: современная замена IPMI поверх HTTPS/REST
В 2014 году консорциум DMTF представил Redfish — современный стандарт, который постепенно вытесняет классический IPMI. В отличие от него Redfish работает поверх HTTPS на стандартных портах 80/443, использует REST API с JSON-ответами, легко скриптуется на любом языке. Старые серверы знают только IPMI, новые поддерживают и то, и другое, а edge-платформы 2025–2026 годов часто только Redfish. Современные серверы на платформах последних двух лет почти всегда имеют поддержку Redfish 1.16+ из коробки.
Чем отличается outband management от inband
Два термина, которые важно не путать. Inband (внутриполосное) управление — через основную ОС сервера: SSH в Linux, RDP в Windows, агент мониторинга. Если ОС упала, такой доступ пропадает. Outband, или out-of-band (внеполосное) — через BMC. Работает независимо от ОС, даже когда сервер выключен. Outband — это страховка на случай зависшей ОС, поврежденного загрузчика или физически офлайн-сервера.
Что умеет IPMI/BMC
Контроллер управления — это не просто кнопка перезагрузки. Под капотом у него богатый набор функций, которые администратор использует ежедневно.
Включение, выключение, перезагрузка сервера
Базовая функция, ради которой BMC изначально и придумали. Команды ipmitool power on/off/cycle/reset запускают, выключают или перезагружают сервер удаленно. Cycle — это hard-reset с разрывом питания, reset — software-перезагрузка. Полезно для зависшего сервера, к которому нет физического доступа.
Удаленная консоль iKVM, console и SOL
iKVM (integrated Keyboard, Video, Mouse) — главное преимущество BMC. Это полноценная графическая удаленная console прямо из браузера. Дополнительный режим — SOL (Serial Over LAN), который проксирует консольный COM-порт сервера через IPMI: удобно для отладки загрузки ядра Linux, когда iKVM-картинка еще не работает. Через web-интерфейс открывается виртуальная консоль с картинкой VGA, клавиатурой и мышью. Можно увидеть, что происходит в BIOS, нажать F2 для входа в настройки UEFI, выбрать загрузочное устройство. Дополнительно BMC умеет монтировать ISO-образ с компьютера администратора как виртуальный CD — это позволяет установить ОС с нуля без физического присутствия в серверной.
Мониторинг температур, вентиляторов, питания
BMC собирает данные с сенсоров материнской платы: температуры CPU и чипсета, обороты вентиляторов, напряжения на линиях питания, потребление в ваттах. Эти данные доступны через IPMI-команды и Redfish API, легко экспортируются в Prometheus или Zabbix. Превентивная замена вентилятора, который начал шуметь — это типовая профилактика, которая делается на основе данных BMC.
Считывание SEL — журнал событий сервера
SEL (System Event Log) — журнал событий, который BMC ведет независимо от ОС. Туда пишутся факты включения и выключения, изменения температуры, перепады напряжения, сообщения от RAID-контроллера, неудачные попытки входа в IPMI. Журнал хранится в энергонезависимой памяти контроллера и переживает выключение сервера. Анализ SEL — первое, что делают при разборе инцидента с железом.
Управление RAID, NIC, BIOS без присутствия
Современные BMC интегрированы с RAID-контроллерами и сетевыми картами. Через web-интерфейс можно создать или удалить RAID-массив, изменить настройки сетевой карты, обновить прошивку любого компонента. Все это — не выезжая в серверную, что критично для распределенной инфраструктуры с парком в сотни серверов.
Как подключить BMC: dedicated vs shared NIC
Сеть управления — отдельная история. От правильного подключения зависит и удобство, и безопасность.
Dedicated IPMI-порт: правильный выбор для продакшена
Большинство серверов имеют отдельный физический порт под BMC — он подписан как «IPMI», «MGMT» или «BMC». Этот порт не имеет ничего общего с пользовательскими сетевыми картами, у него своя MAC-адрес, свой IP. Это правильный выбор для любого продакшена: management-трафик идет по отдельной сети, отдельному коммутатору, и не виден из пользовательского VLAN. Так строится грамотная защищенная инфраструктура — подключение через сетевое оборудование с отдельным management-сегментом и ACL.
Shared LAN-режим: дешевле, но рискованно
Альтернатива — режим shared, когда BMC использует один из основных сетевых портов сервера. Экономия на одном кабеле и порте коммутатора, но безопасность сразу страдает: management-трафик идет по той же сети, что и пользовательский, виден сниферу в этом VLAN, доступен из любой точки сети без правильной сегментации. Допустим только в изолированных контурах или dev-стендах, в проде использовать не стоит.
Failover между интерфейсами и резервирование
Большинство современных BMC поддерживают failover: если один сетевой интерфейс умер, контроллер автоматически переключается на резервный. Это полезно для критичных серверов в кластерах высокой доступности. Настраивается через web-интерфейс BMC или через Redfish API — нужно указать основной и резервный порт и интервал проверки связи.
Безопасность: главные угрозы и защита
IPMI исторически — одна из самых уязвимых частей серверной инфраструктуры. Разберем главные угрозы и способы защиты.
IPMI наружу — массовая ошибка с последствиями
По данным Shodan, десятки тысяч серверов в публичных сетях имеют открытый IPMI-порт с дефолтными паролями или старыми прошивками. Это означает, что любой желающий может подключиться к BMC, перезагрузить сервер, открыть iKVM, перенастроить BIOS. Правило простое: BMC никогда не должен быть доступен из интернета. Только через VPN и только из management-сети. Перед сдачей проекта в эксплуатацию полезно сделать аудит безопасности, чтобы убедиться, что management-порты действительно закрыты от внешних атак.
Cipher 0, IPMI 1.5, дефолтные пароли
IPMI 2.0 поддерживает несколько cipher suites — наборов шифрования. Cipher Suite 0 разрешает анонимный доступ без пароля — это известная уязвимость CVE-2013-4786. Должен быть отключен на всех BMC без исключения. IPMI 1.5 устарел и тоже отключается. Cipher 3 и Cipher 17 — современные защищенные варианты, оставляются только они. Дефолтные пароли вроде ADMIN/ADMIN — отдельная проблема: их меняют сразу после установки, желательно через автоматизированный скрипт при первой загрузке.
Изолированный management VLAN
Все BMC сервера в инфраструктуре подключаются в отдельный management VLAN. Этот сегмент полностью изолирован от пользовательских сетей через ACL на маршрутизаторе. Доступ внутрь — только с jump-host (бастион) под контролем SIEM. Прямой доступ с рабочих мест администраторов запрещен.
Доступ только через VPN/бастион-хост
Администратор не должен иметь возможности подключаться к BMC напрямую с ноутбука или с домашнего компьютера. Правильная схема: VPN в офисную сеть, оттуда через jump-host (Linux-сервер с записью всех сессий через teleport, jumpcloud или собственный pam-stack) в management VLAN. Все действия фиксируются и пишутся в журнал.
Жесткая политика паролей и MFA
Пароли BMC — не на стикерах под клавиатурой и не «12345678». Жесткая политика: 16+ символов, верхний и нижний регистр, цифры, спецсимволы, ротация раз в полгода. Современные BMC поддерживают MFA через TOTP или сертификаты — нужно включать. Идеально — централизованная авторизация через LDAP/AD с проверкой членства в группе «BMC-admins».
Обновление прошивок BMC и BIOS
Прошивки BMC и BIOS требуют регулярного обновления — в них регулярно находят критичные уязвимости.
Почему важно держать BMC актуальным
В прошивках BMC регулярно находят уязвимости — от обхода аутентификации до выполнения произвольного кода. Старые BMC превращаются в точку входа для атакующего: получив доступ к контроллеру, он может перепрошить BIOS вредоносной версией, которая переживет переустановку ОС. Регламент простой: обновление прошивки BMC и BIOS раз в полгода, как минимум.
Регламент обновления и тестовый стенд
Любое обновление прошивки сначала тестируется на стенде — на одном-двух идентичных серверах вне продакшена. Проверяется, что после обновления загрузка проходит штатно, iKVM работает, мониторинг возвращает корректные данные. Только после этого — раскат на продакшен в окно обслуживания. Особенно критично для серверов в кластерах высокой доступности: одно неудачное обновление на ноду — приемлемо, на все сразу — катастрофа.
CVE по типовым BMC: AHB Aspeed, MegaRAC
В последние годы были громкие уязвимости в популярных BMC-чипах ASpeed AST2500/2600 (используются у Supermicro, Asus, Gigabyte и Yadro) и в прошивках AMI MegaRAC SP-X. Рекомендация: подписаться на CVE-рассылку вендора BMC, следить за PSIRT и устанавливать патчи в течение 30 дней с выхода.
Российские реалии: чем заменить iDRAC и iLO
После ухода западных производителей западных из РФ обновления прошивок iDRAC и iLO стали недоступны. Разберем, как с этим жить.
Положение с управлением серверов западных вендоров
Системы удаленного управления у западных производителей (так называемые iDRAC alternative задачи) продолжают работать на действующих сертификатах и старых прошивках. Но новых апдейтов нет — критичные CVE не патчатся, новые функции (Redfish, расширенный SIEM) не добавляются. Для не-критичных задач это терпимо, для значимых объектов КИИ — нет, нужен аналог из российского реестра.
BMC российских серверных платформ (Yadro, Sitronics)
Российские серверные вендоры — Yadro, Sitronics, Аквариус, Гравитон — используют собственные BMC-сборки. У Yadro это VeGa-BMC на базе OpenBMC, активно развивается, поддерживает Redfish 1.16+. У Sitronics и Аквариуса — типовой ASpeed AST2600 с локализованной прошивкой. Под полное импортозамещение управления серверов есть готовое направление — импортозамещение серверов с подбором платформ и регламентом перехода.
Универсальные ASpeed AST2500/2600 и open-source решения
Большинство современных серверов независимых производителей (Supermicro, Asus, Gigabyte) используют ASpeed AST2500 или 2600 с прошивкой от AMI или ASpeed. С 2023 года активно развивается OpenBMC — open-source прошивка, на которую переходят несколько российских вендоров. Она обеспечивает полноценный Redfish API, iKVM, мониторинг, регулярно обновляется сообществом.
Эксплуатация: автоматизация и интеграция
Когда серверов десятки и сотни, ручное управление BMC через web-интерфейс не работает. Все автоматизируется.
Redfish-скрипты для массовой настройки парка
Redfish — это REST API, поэтому скриптуется любыми средствами: bash + curl, Python с библиотекой sushy, Ansible с модулем community.general.redfish. Типовые задачи: смена пароля BMC на всех серверах одновременно, изменение настроек сети, обновление прошивки, сбор инвентарных данных. Без автоматизации настройка парка из 100 серверов — это работа на месяц вручную, скриптами — несколько часов.
Интеграция с Zabbix, Prometheus IPMI exporter
BMC отдает метрики через IPMI и Redfish — это можно собирать в любую систему мониторинга. Для Prometheus есть готовый ipmi_exporter, для Zabbix — встроенный шаблон IPMI. Метрики: температура, обороты вентиляторов, мощность, состояние RAID, заполнение SEL. Алерты — на критичные пороги: температура выше 80°C, остановившийся вентилятор, ошибки RAID.
SIEM: пересылка SEL и аудит-логов BMC
Журнал событий сервера (SEL) и журнал аутентификации BMC пересылаются в SIEM (MaxPatrol SIEM, RuSIEM, Kaspersky KICS) через syslog или Redfish webhook. Это позволяет коррелировать события на железе с событиями на ОС и в сети — например, отследить попытку взлома BMC с одновременной активностью в management VLAN.
Типовые ошибки в работе с IPMI
Опыт показывает, какие промахи делают команды при первой настройке BMC.
Открытый BMC в публичной сети без firewall
Самая частая и самая опасная ошибка — оставить BMC на публичном IP без правильной сегментации. Через пару дней сервер уже сканируется ботами на cipher 0 и слабые пароли. Правило: BMC всегда за firewall, всегда в отдельном management VLAN, доступ — только через VPN.
Один логин/пароль на все серверы
Удобство для админа, кошмар для безопасника. Если злоумышленник получил один пароль — он получает все серверы парка. Решение: уникальный пароль для каждого BMC (хранится в Vault или другом менеджере секретов), либо централизованная авторизация через LDAP с per-server permission. Регулярная ротация — раз в 3–6 месяцев.
Отсутствие отдельного management-сегмента сети
Третья частая ошибка — поставить BMC в тот же VLAN, что и пользовательские машины «потому что один свитч». Любой компрометированный пользовательский ПК получает доступ к management-сегменту. Правильно: management VLAN на отдельном свитче или с жесткой ACL-изоляцией, доступ только с jump-host.
Разворачиваете парк серверов и хотите грамотно настроить удаленное управление? Наши инженеры спроектируют management-сеть, настроят BMC, Redfish и iKVM, помогут с интеграцией мониторинга и регламентом безопасности. Закажите аудит ИТ-инфраструктуры — на выходе будет готовый план и спецификация.
Сравнительная таблица: IPMI vs Redfish
Часто задаваемые вопросы (FAQ)
Что такое IPMI простыми словами?
Это сетевой протокол, через который администратор управляет сервером удаленно, минуя основную операционную систему. Через IPMI можно включить или выключить сервер, открыть консоль, посмотреть температуру и журнал событий. Работает поверх отдельного контроллера BMC, который живет на материнской плате и питается даже при выключенном сервере.
Чем BMC отличается от IPMI?
BMC — это физический контроллер (микрокомпьютер на материнской плате). IPMI — это протокол управления, по которому администратор обращается к BMC. То есть BMC — это «что», а IPMI — это «как». Современная замена IPMI — Redfish (REST API поверх HTTPS), но работает он с тем же BMC.
Можно ли управлять сервером без присутствия в серверной (серверная комната)?
Да, именно для этого и нужен BMC. Через web-интерфейс или скрипты можно перезагрузить машину, открыть удаленную консоль iKVM, изменить настройки BIOS, обновить прошивку — все без физического присутствия. При наличии корректной management-сети это работает с любого места через VPN.
Как защитить IPMI от внешних атак?
Главное — никогда не выводить BMC в публичную сеть. Все контроллеры подключаются в отдельный management VLAN, изолированный ACL от пользовательских сетей. Доступ — только через VPN и jump-host. Cipher 0 и IPMI 1.5 отключаются. Дефолтные пароли меняются на длинные уникальные. Прошивки обновляются раз в полгода.
Чем Redfish лучше классического IPMI?
Redfish работает по HTTPS на стандартных портах, использует REST API с JSON-ответами и легко скриптуется на любом языке. IPMI же — бинарный протокол по UDP с массой устаревших схем шифрования. Поэтому современные серверы все чаще переходят только на Redfish, а IPMI оставляют только для совместимости со старыми утилитами.
Зачем dedicated NIC для BMC?
Чтобы изолировать management-трафик от пользовательского. Отдельный физический порт идет в management VLAN на отдельный коммутатор, и злоумышленник из пользовательской сети просто не видит BMC. Shared LAN-режим объединяет management и пользовательский трафик на одном порту — это упрощает атаки и снижает уровень безопасности.
Что делать с iDRAC, если вендор ушел из РФ?
Действующие iDRAC и iLO работают на текущих прошивках. Но новых обновлений нет, критичные CVE не патчатся. Для не-критичных задач — терпимо, для значимых объектов КИИ — мигрировать на российские серверные платформы (Yadro, Sitronics, Аквариус) с собственными BMC или OpenBMC.
Как массово настроить BMC на 50 серверах?
Через Redfish и автоматизацию. Скрипт на bash + curl или Ansible-плейбук пробегает по списку IP-адресов BMC, меняет пароль, настраивает сеть, выставляет нужные cipher suites. На 50 серверах — это 30–60 минут вместо нескольких дней ручной настройки.
Итоги
IPMI и BMC — это не «дополнительная фича», а критичный компонент серверной инфраструктуры, без которого не обходится ни один продакшен. Главные принципы: отдельный физический dedicated NIC под BMC, изолированный management VLAN с ACL, доступ только через VPN и jump-host, отключенный cipher 0, уникальные длинные пароли на каждый сервер, регулярное обновление прошивок раз в полгода.
