Интерфейс интеллектуального управления платформой ( IPMI ) — это набор спецификаций компьютерного интерфейса для автономной компьютерной подсистемы, которая обеспечивает возможности управления и мониторинга независимо от центрального процессора , встроенного ПО ( BIOS или UEFI ) и операционной системы хост-системы . IPMI определяет набор интерфейсов, используемых системными администраторами для управления компьютерными системами по внешнему каналу и мониторинга их работы. Например, IPMI предоставляет способ управления компьютером, который может быть выключен или иным образом не отвечать, с помощью сетевого подключения к оборудованию, а не к операционной системе или оболочке входа в систему. Другим вариантом использования может быть удаленная установка пользовательской операционной системы . Без IPMI установка пользовательской операционной системы может потребовать от администратора физического присутствия рядом с компьютером, вставки DVD-диска или USB-флеш-накопителя с установщиком ОС и завершения процесса установки с помощью монитора и клавиатуры. Используя IPMI, администратор может смонтировать образ ISO , смоделировать установочный DVD-диск и удаленно выполнить установку. [1]
Спецификация разработана компанией Intel и впервые опубликована 16 сентября 1998 года. Она поддерживается более чем 200 поставщиками компьютерных систем, такими как Cisco , Dell , [2], Hewlett Packard Enterprise и Intel. [3] [4]
Использование стандартизированного интерфейса и протокола позволяет программному обеспечению управления системами на основе IPMI управлять несколькими разрозненными серверами. Как спецификация интерфейса на уровне аппаратного обеспечения, основанная на сообщениях, IPMI работает независимо от операционной системы (ОС), позволяя администраторам управлять системой удаленно при отсутствии операционной системы или программного обеспечения управления системой . Таким образом, функции IPMI могут работать в любом из трех сценариев:
Системные администраторы могут использовать сообщения IPMI для мониторинга состояния платформы (например, температуры системы, напряжения, вентиляторов, источников питания и проникновения в корпус); для запроса информации об инвентаризации; для просмотра журналов оборудования при состояниях, выходящих за пределы диапазона; или для выполнения процедур восстановления, таких как отправка запросов с удаленной консоли через те же соединения, например, выключение и перезагрузка системы или настройка сторожевых таймеров . Стандарт также определяет механизм оповещения для системы для отправки простого ловушки событий платформы (PET) протокола сетевого управления (SNMP).
Контролируемая система может быть выключена, но должна быть подключена к источнику питания и к среде мониторинга, обычно к подключению к локальной сети (LAN). IPMI также может функционировать после запуска операционной системы и предоставляет данные и структуры управления программному обеспечению управления системой. IPMI предписывает только структуру и формат интерфейсов в качестве стандарта, в то время как подробные реализации могут различаться. Реализация IPMI версии 1.5 может взаимодействовать через прямое внеполосное LAN или последовательное соединение или через боковое LAN-соединение с удаленным клиентом . Боковое LAN-соединение использует контроллер сетевого интерфейса платы (NIC). Это решение менее затратно, чем выделенное LAN-соединение, но также имеет ограниченную пропускную способность и проблемы безопасности.
Системы, совместимые с IPMI версии 2.0, также могут взаимодействовать через последовательный интерфейс по локальной сети , благодаря чему последовательный консольный вывод может быть удаленно просмотрен по локальной сети. Системы, реализующие IPMI 2.0, обычно также включают KVM по IP , удаленные виртуальные носители и встроенный интерфейс веб-сервера, хотя, строго говоря, они выходят за рамки стандарта интерфейса IPMI.
DCMI (интерфейс управления центром обработки данных) — это аналогичный стандарт, основанный на IPMI, но разработанный для более удобного управления центром обработки данных : он использует интерфейсы, определенные в IPMI, но сводит к минимуму количество дополнительных интерфейсов и включает в себя управление ограничением мощности, а также другие отличия.
Подсистема IPMI состоит из главного контроллера, называемого контроллером управления базовой платой (BMC), и других контроллеров управления, распределенных по различным системным модулям, которые называются сателлитными контроллерами. Сателлитные контроллеры в одном шасси подключаются к BMC через системный интерфейс, называемый шиной/мостом интеллектуального управления платформой (IPMB) — улучшенная реализация I²C (межинтегральная схема). BMC подключается к сателлитным контроллерам или другому BMC в другом шасси через шину или мост интеллектуального контроллера управления платформой (IPMC). Им можно управлять с помощью протокола удаленного управления (RMCP), специализированного проводного протокола, определенного этой спецификацией. RMCP+ ( протокол на основе UDP с более надежной аутентификацией, чем RMCP) используется для IPMI через локальную сеть.
Несколько поставщиков разрабатывают и продают чипы BMC. BMC, используемый для встраиваемых приложений, может иметь ограниченную память и требовать оптимизированного кода прошивки для реализации полной функциональности IPMI. Высокоинтегрированные BMC могут предоставлять сложные инструкции и обеспечивать полную внеполосную функциональность сервисного процессора. Прошивка, реализующая интерфейсы IPMI, предоставляется различными поставщиками. Репозиторий заменяемых в полевых условиях блоков (FRU) содержит инвентарь, такой как идентификатор поставщика и производитель, потенциально заменяемых устройств. Репозиторий записей данных датчиков (SDR) предоставляет свойства отдельных датчиков, присутствующих на плате. Например, плата может содержать датчики температуры, скорости вращения вентилятора и напряжения.
Контроллер управления основной платой (BMC) обеспечивает интеллект в архитектуре IPMI. Это специализированный микроконтроллер, встроенный в материнскую плату компьютера — обычно сервера . BMC управляет интерфейсом между программным обеспечением управления системой и аппаратным обеспечением платформы. BMC имеет свою собственную прошивку и оперативную память .
Различные типы датчиков, встроенных в компьютерную систему, сообщают BMC о таких параметрах , как температура , скорость вращения вентилятора охлаждения , состояние питания , состояние операционной системы (ОС) и т. д. BMC контролирует датчики и может отправлять оповещения системному администратору по сети, если какой-либо из параметров не остается в пределах заданных ограничений, что указывает на потенциальный сбой системы. Администратор также может удаленно связываться с BMC, чтобы предпринять некоторые корректирующие действия, такие как сброс или выключение и включение питания системы, чтобы снова запустить зависшую ОС. Эти возможности снижают общую стоимость владения системой.
Системы, совместимые с IPMI версии 2.0, также могут взаимодействовать через последовательный интерфейс по локальной сети , благодаря чему последовательный консольный вывод может быть удаленно просмотрен по локальной сети. Системы, реализующие IPMI 2.0, обычно также включают KVM по IP , удаленные виртуальные носители и встроенный интерфейс веб-сервера, хотя, строго говоря, они выходят за рамки стандарта интерфейса IPMI.
Физические интерфейсы BMC включают SMBuses , последовательную консоль RS-232 , адресные и информационные линии, а также IPMB, который позволяет BMC принимать сообщения-запросы IPMI от других контроллеров управления в системе.
Прямое последовательное соединение с BMC не шифруется, поскольку само соединение защищено. Соединение с BMC по локальной сети может использовать или не использовать шифрование в зависимости от проблем безопасности пользователя.
Растет обеспокоенность по поводу общей безопасности BMC как закрытой инфраструктуры. [5] [6] [7] [8] OpenBMC — это проект Linux Foundation Collaborative BMC с открытым исходным кодом. [9]
2 июля 2013 года Rapid7 опубликовал руководство по тестированию на проникновение в систему безопасности новейшего протокола IPMI 2.0 и его реализаций различными поставщиками. [10]
Некоторые источники в 2013 году рекомендовали не использовать старую версию IPMI [5] из-за проблем безопасности, связанных с конструкцией и уязвимостями контроллеров управления платой (BMC). [11] [12]
Однако, как и в случае с любым другим интерфейсом управления, передовые методы обеспечения безопасности диктуют размещение порта управления IPMI в выделенной локальной сети управления или виртуальной локальной сети, доступ к которой ограничен доверенными администраторами. [13]
Спецификация IPMI была обновлена с помощью RAKP+ и более сильного шифра, который с вычислительной точки зрения нецелесообразно взломать. [14] В результате поставщики предоставили исправления, которые устраняют эти уязвимости. [ необходима цитата ]
Организация DMTF разработала безопасную и масштабируемую спецификацию интерфейса под названием Redfish для работы в современных средах центров обработки данных. [15]
Некоторые потенциальные решения существуют за пределами стандарта IPMI, в зависимости от фирменных реализаций. Использование коротких паролей по умолчанию или взломов "cipher 0" можно легко преодолеть с помощью сервера RADIUS для аутентификации, авторизации и учета (AAA) через SSL, как это обычно бывает в центрах обработки данных или в любом среднем или крупном развертывании. Сервер RADIUS пользователя можно настроить для безопасного хранения AAA в базе данных LDAP с использованием FreeRADIUS/OpenLDAP или Microsoft Active Directory и связанных служб.
Доступ на основе ролей обеспечивает способ реагирования на текущие и будущие проблемы безопасности путем увеличения количества ограничений для более высоких ролей. Доступ на основе ролей поддерживается тремя доступными ролями: Администратор, Оператор и Пользователь.
В целом, роль пользователя имеет доступ только для чтения к BMC и не имеет возможности удаленного управления, например, выключения питания или возможности просмотра или входа в основной ЦП на материнской плате. Таким образом, любой хакер с ролью пользователя не имеет доступа к конфиденциальной информации и контроля над системой. Роль пользователя обычно используется для мониторинга показаний датчиков после получения оповещения SNMP программным обеспечением для мониторинга сети SNMP.
Роль оператора используется в редких случаях, когда система зависает, для генерации файла аварийного дампа NMI/core и перезагрузки или выключения питания системы. В таком случае оператор также будет иметь доступ к системному программному обеспечению для сбора файла аварийного дампа/core.
Роль администратора используется для настройки BMC при первой загрузке во время ввода системы в эксплуатацию после ее первой установки.
Поэтому благоразумной практикой будет отключить использование ролей оператора и администратора в LDAP/RADIUS и включать их только при необходимости администратора LDAP/RADIUS. Например, в RADIUS можно изменить настройку Auth-Type роли на:
Тип аутентификации := Отклонить
Это предотвратит успешные атаки с использованием хэш-функции RAKP, поскольку имя пользователя будет отклонено сервером RADIUS.
Спецификация стандарта IPMI прошла ряд итераций: [16] [17]
{{cite journal}}: Цитировать журнал требует |journal=( помощь )