Out-of-band (BMC IPMI, IP KVM)
IPMI
IPMI (Intelligent Platform Management Interface) – отдельный контроллер BMC (Baseboard Management Controller) с сетевым интерфейсом out-of-band. Нужен для управления серверами через отдельный канал. Контроллер BMC имеет отдельное (от основных компонентов) питание и независимые от основной системы NIC, BIOS, CPU (обычно на архитектуре ARM), OS (внутри контроллера). В результате, даже если сервер выключен, но есть питание на БП – можно зайти используя IPMI (CLI/WEB/ETC) и включить питание сервера. Подключение контроллера к материнской плате обычно происходит через PCI интерфейс, используя переходник.
Серверные продукты производителей типа HP iLO (Intergrated Lights Out), DELL iDRAC, Huawei iBMC/iMANA основаны именно на IPMI. iBMC Huawei бесплатен (в отличии от других вендоров) – BMC встроен в каждый сервер и ключ для активации функционала не нужен. Asus IPMI использует интегрированные или устанавливаемые чипы ASMB (ASUS ASMB7-iKVM, ASMB6-iKVM, ASMB4-iKVM), софт для подключения на базе Java + Internet Explorer.
Многие сервера после shutdown держат включенными сетевые линки, на случай если BMC на том же порту и для прослушивания wake-on-lan.
Основные кейсы применения
IP KVM
В IP KVM клавиатура/мышь реализуются обычно через USB, поэтому если не подключить USB, то работать они не будет (л-логика). Все это идет в одном проводе который к стороне сервера/сетевого устройства расщепляется в VGA-USB/PS-2.
Часто идут с монитором (спереди монитор, сзади интерфейсы) – это олдскул KVM.
remote CD-ROM/USB/floppy в IP KVM – зачастую очень полезен и встречается на многих IP KVM, но работает далеко не на всех хорошо. На основе практики:
HP IP Console Switch G2 4x1Ex32 с консольниками HPE KVM USB replace 336047-B21 (AF628A) – работает не очень
Aten KN8132V – умеет монтировать ISO (Virtual Media) через USB, работает ок
Aten
Aten довольно бюджетный вариант и в чем то убогий по практике – один терминал в один момент времени, нет web, глюки с синхронизацией под экран, etc
Софт можно скачать для соответствующей модели, например cs1708i.
Hint: чтобы выйти из полного экрана приложения нажимаем на hotkey setup (значок клавиатуры), видим там настройки по выходу (toggle screen mode – по умолчанию Alt+f).
Крут тем, что для подключения к серверам можно использовать как десктоп приложение, так и HTML5 WEB. Есть многопользовательский режим (5 одновременных клиентов).
Плата управления сервером — зачем она и что внутри
Тут, может быть, сразу последует вопрос — а зачем вообще выносить функции управления с материнской платы на отдельную карточку? Зачем умножать число компонентов, не проще ли всё засунуть на материнку, как это обычно делают производители серверов?
Согласен, в обычных условиях и мы поступили бы именно так — но в этом проекте и в таком вопросе пришлось поступить нестандартно. Из-за плотности компоновки материнской платы просто не было лишнего места для размещения чипов BMC, USB-хоста, PCIe-коммутатора и разводки всех связанных с ними цепей. А кроме того, просто не было места на задней панели шасси для установки коннекторов Ethernet/USB напрямую на материнской плате. В общем, мы решили не усложнять и без того сложную системную плату, и вынесли все эти компоненты на отдельную плату управления. Этот способ, кроме всего прочего, даёт больше гибкости в плане будущих доработок и изменений.
Что внутри?
Собственно, структурная схема платы весьма проста:
Структурная схема платы управления сервером.
Главный компонент — чип BMC ASPEED AST2400, очень популярный и наверняка многим хорошо знакомый. У него есть своя выделенная память DDR3 объёмом 512 МБ.
К BMC подключен хост USB3.0, для которого мы используем чип TI7340. От него два порта USB3.0 выводятся наружу. Также к BMC прицеплен двухканальный контроллер Gigabit Ethernet (BCM5720), порты которого выведены наружу. Это очень распространённый контроллер, который отлично поддерживается архитектурой POWER.
Всю эту компанию объединяет PCIe-коммутатор (по цене оптимально было поставить PEX8714), напрямую присоединённый к разъёму для подключения к системной плате. Он разводит PCIe x4 на x2 и 2 по x1.
Разъём для подключения к системной плате имеет небольшую особенность. Сам-то коннектор полностью стандартный. Но чтобы полностью исключить установку платы управления в обычный PCIe-слот (на материнке у нас есть специальный выделенный слот для платы управления), мы развернули коннектор на 180 градусов и сдвинули его относительно стандартного для PCIe размещения.
На схеме можно также заметить видеовыход VGA и два последовательных порта — их наружу не выводили, оставили в виде header-ов. Они нужны в основном для отладочных целей — да и на внешней панели низкопрофильной PCIe-карты просто не осталось места после размещения двух USB и двух Ethernet портов.
Как выглядит плата
Собственно, геометрия платы получилась такая (плата низкопрофильная, но длинная):
В левой стороне изображения задняя панель платы — из неё выведены 2 порта USB3.0, а под ними — сдвоенные порты GbE.
Покажу и нашу любимую техноживопись дорожками по плате:
Сигналы и питание разведены по 8 слоям.
Пожалуй, стоит ещё немного сказать про BMC. Прошивку для него мы разрабатываем сами на основе OpenBMC. Собственно, задачи стоят простые:
Управление серверными платформами через интерфейс IPMI
Реализацией удаленного управления и мониторинга компьютерных систем крупные производители оборудования вплотную занялись еще в конце прошлого века. При стремительном росте компьютеризации и возникновении распределенных сетей крупных предприятий и организаций потребовалась технология, которая бы позволяла централизовано управлять наиболее важными узлами без непосредственного локального доступа к компьютеру. В первую очередь, крупные производители серверных платформ реализовали возможность выполнения на сервере, который может находиться в соседнем здании или на другом конце планеты, удаленного доступа, позволяющего обслуживающему персоналу выполнить следующие операции:
— Включить или выключить электропитание.
— Выполнить аппаратный сброс компьютера.
— Посмотреть или изменить настройки BIOS.
— Установить операционную систему с использованием виртуальных носителей.
— Управлять операционной системой удаленно с использованием стандартных устройств ввода – вывода.
— Отслеживать техническое состояние наиболее важных узлов оборудования.
— Выполнять операции по обслуживанию аппаратной платформы (прошивка BIOS материнской платы или определенных контроллеров) и обеспечения авторизованного доступа к ней.
Назначение и реализация интерфейса IPMI.
IPMI (от англ. Intelligent Platform Management Interface) — интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ. Другими словами IPMI – это средство управления, которое реализовано независимо от основного оборудования сервера и обеспечивает его включение, выключение, сброс, удаленное подключение виртуальных мониторов, клавиатур и мышей, наблюдение за работой оборудования и оповещение о важных событиях, связанных с работоспособностью сервера. Спецификация IPMI версии 1.0 была опубликована еще в 1998г. и базировалась на подключении к модулю IPMI через последовательный интерфейс RS-232. Последующие спецификации IPMI 1.5 b 2.0 базируются на использовании стандартного сетевого интерфейса.
Спецификация IPMI не задает жестких стандартов по реализации IPMI-устройств. Они могут быть выполнены в виде отдельного адаптера, могут быть распаяны непосредственно на материнской плате или выполнены в виде отдельного микроконтроллера. В настоящее время, наиболее распространены интегрированные в серверные материнские платы контроллеры BMC на базе технологии “система на одном кристалле” (System-on-Chip, SoC), позволяющие реализовать как эффективное взаимодействие с управляемой платформой, так и огромное количество функций по удаленному мониторингу, оповещению о важных событиях по e-mail или SNMP, ведению журналов и т.п.
Основные возможности управления материнской платой через интерфейс IPMI.
Рассмотрим возможности управления сервером через интерфейс IPMI на примере материнской платы Supermicro X8DTT-IBQF с интегрированным контроллером Nuvoton WPCM450 Baseboard Management Controller с поддержкой IPMI 2.0.
Контроллер Nuvoton WPCM450 поддерживает графическое ядро с PCI-интерфейсом, устройства Virtual Media ( виртуальные CD/DVD ) и перенаправление клавиатуры-видео-мыши (Keyboard/Video/Mouse, KVM ). Для подключения к локальной сети используется внешний контроллер Ethernet, распаянный на материнской плате.
Подключение к локальной сети выполняется через порт RJ-45, обозначенный как IPMI_LAN
Первичная настройка интерфейса IPMI выполняется в разделе Adnanced – IPMI Configuration основного BIOS.
Status of BMC состояние контроллера BMC
Вкладка “Server Health” позволяет контролировать состояние оборудования сервера:
Просмотр журнала событий позволяет определить время возникновения фиксируемого состояния датчика, получить его краткое описание и оценить уровень опасности для функционирования оборудования. Пример отображаемой информации:
Вкладка Configuration позволяет выполнить настройки оповещений о состоянии оборудования, изменять сетевые параметры, настроить политику доступа к устройству IPMI.
Вкладка Remote Control используется для включения, выключения и сброса сервера.
Кроме ручного контроля оборудования, интерфейс IPMI позволяет настроить систему оповещения с использованием электронной почты о важных событиях, связанных с работой оборудования – изменении температуры, напряжений, скорости вращения вентиляторов, возникновении корректируемых ошибок памяти ( ECC ) и т.п. Также имеется возможность мониторинга с использованием протокола SNMP (Simple Network Management Protocol).
Реализация интерфейса IPMI может отличаться в зависимости от производителя оборудования и модели материнской платы. Так, например, для многих серверных платформ Intel подключение по IPMI через веб-браузер обеспечивается специальным модулем удаленного управления – Remote Management Module ( RMM ), который не входит в стандартную комплектацию и закупается отдельно. При чем, существует несколько редакций данных модулей, совершенно не совместимых между собой, модуль RMM3 невозможно установить на платформу, поддерживающую RMM4 и наоборот. При установке или замене модуля RMM необходимо руководствоваться документацией к материнской плате.
Кроме того, например, на многих платформах производства Supermicro при включении оборудования IPMI на входе порта Ethernet должен присутствовать линк, в противном случае, доступ к интерфейсу IPMI по сети работать не будет.
Для управления платформами через интерфейс IPMI может использоваться не только браузер, но и программное обеспечение, разрабатываемое производителями оборудования, как например утилита с графическим интерфейсом от Supermicro IPMI View
Кроме того, существует открытое программное обеспечение с реализацией интерфейса IPMI:
Делаем собственный имплант для электроники
История от Bloomberg о том, что на материнских платах якобы были установлены некие импланты [Китайцы использовали микрочип, чтобы контролировать американские компьютеры], не прошла незамеченной. После неё многие люди делились идеями по поводу возможности создания подобных имплантов (их предполагаемого размера, возможностей или способа их обнаружения).
Через несколько дней журнал Bloomberg выпустил статью с дополнительными доказательствами. Вот что конкретно подогрело наш интерес:
Легальный сервер отправлял сообщения одним способом, имплант – другим, но казалось, что весь трафик происходит от одного доверенного сервера.
Существуют способы взаимодействия с сетевой картой прямо с материнской платы. Несколько людей указали на то, что можно поиграться с BMC (Baseboard Management Controller – компонент, разрешающий доступ к серверу помимо основного канала), что позволит импланту контролировать BMC и получать доступ к сетевой карте. Но как это работает на практике? Давайте посмотрим, сможем ли мы это воспроизвести.
Начальная позиция
Посмотрим на наличие возможных интерфейсов между NIC (сетевой платой) и BMC. Один из основных протоколов для работы по выделенному каналу – это интеллектуальный интерфейс управления платформой IPMI.
Википедия говорит, что IPMI — «интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ. Ключевые характеристики IPMI — мониторинг, восстановление функций управления, журналирование и инвентаризация, которые доступны независимо от процессора, BIOS’a и операционной системы. Функции управления платформой могут быть доступны, даже если система находится в выключенном состоянии». Весьма похоже на то, что нам нужно.
На следующей блок-схеме показан возможный путь реализации проекта:
IPMI на самом деле определяет два Sideband-канала для NIC: SMBus и NC-SI. NC-SI – это современная замена SMBus, поддерживающая увеличенную скорость передачи данных и другие новые возможности. Проблема в том, что ей требуется больше сигналов (порядка 10), и в её работу гораздо сложнее вмешаться в случае, когда мы работаем с имплантом. Так что пока остановимся на SMBus.
SMBus
SMBus (System Management Bus) — последовательный протокол обмена данными для устройств питания. Односторонняя простая двухпроводная шина, обеспечивающая несложные коммуникации. Чаще всего используется в компьютерах для связи материнской платы с источником питания и отправки инструкций вида вкл/выкл. Основан на шине I 2 C, обычно использующейся в микроконтроллерах. Интерфейсу нужно всего два сигнала (тактовая частота и данные), и третий сигнал — прерывание. Идеально подходящий для игр с имплантом протокол.
Первый контакт
Приходится проявлять смекалку, не имея доступа к материнской плате с BMC. Изучая технические характеристики серверных материнок, мы обнаружили, что некоторые из них используют чип Intel 82574L. Он, согласно документации, обеспечивает «SMBus advanced pass-through interface» – как раз то, что нужно. А что лучше всего, он бывает в формате карт PCI-E.
Доступ к SMBus
Мы сходили в магазин, и теперь у нас есть карточки Intel EXPI9301CTBLK с чипом 82574L. Что теперь?
В документации можно отследить SMB_DAT и SMB_ALRT_N. К счастью, все они оказались доступными на контактных площадках. Вроде бы всё достаточно легко.
NIC PCB. Слева вверху – EEPROM, справа вверху — коннектор для SMBus [ALRT|CLK|DAT]. Обратите внимание, что R39 и R40 отпаяны, что запрещает доступ к SMBus для коннектора PCIe.
Мы подключили зонд I 2 C и просканировали SMBus, но ничего полезного не считали. Документация говорит, что SMBus включается только при установке определённого битового регистра. Это значение загружается с EEPROM. Пришло время копнуть глубже.
Включаем доступ к SMBus
Нам снова помогает документация. Доступ к SMBus определяется значением регистра, загружаемого с NIC EEPROM. К счастью, EEPROM можно прочесть при помощи flashrom. Сбросив содержимое EEPROM, мы можем проанализировать и изменить значения:
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip «W25X40» (512 kB, SPI) on buspirate_spi.
Reading flash. done.
Судя по NVM map (глава 6.1 документации), видно, что нам надо изменить два значения:
После этого нам надо ещё разобраться со значением Checksum. В главе 6.1.2.11 указано, что сумма всех слов в диапазоне [0x00-0x40] должна равняться 0xBABA. Немного Python поможет нам подсчитать правильную контрольную сумму:
import struct
data = open(‘/tmp/flash.mod’, ‘rb’).read()
tot = 0
for i in range(0x3f):
tot = (tot + struct.unpack(‘
И вот, наконец, все наши изменения для EEPROM:
00000000: 6805 ca89 b22e 3014 46f7 8010 ffff ffff h. 0.F.
00000010: 69e4 0881 6b02 1fa0 8680 d310 ffff 5adc i. k. Z.
После внесения изменений и прошивки EEPROM мы подсоединили I 2 C зонд и:
i2c1> scan
Device found at address 0x49
i2c1>
Адрес I 2 C кодируется в семи битах, требуемый нам адрес получается, как 0x49 [START] [@SLAVE] [CMD] ( [START] [@SLAVE] [READ_DATA] ) [STOP]
[START] и [STOP] – это условия START и STOP, определяемые протоколом I 2 C.
К примеру, команда на чтение MAC-адреса (описанная в главе 8.8.2.3) будет 0xD4. Отправляем команду в SMBus в режиме I 2 C:
[START] [0x92] [0xD4] [START] [0x92] [read 8 bytes] [STOP]
При переводе в команды Hydrabus это будет:
i2c1> [ 0x92 0xd4 [ 0x92 hd:2 hd:6 ]
I2C START
WRITE: 0x92 ACK 0xD4 ACK
И, да, мы получаем наш MAC-адрес!
Делаем имплант
Теперь, зная, как можно общаться с NIC, посмотрим, как можно использовать этот канал для кражи сетевого трафика и отправки данных по сети. В главе 8 документации описано всё, что нужно для этого.
Отправка пакетов
Описана в главах 8.6 и 8.8.1. Мы можем просто создать фрейм Ethernet при помощи команд. Вот пример скрипта для Hydrabus или Bus Pirate для отправки пакета:
import serial
import struct
from scapy.all import *
def send_frame(pkt):
# Define the frame size
pktlen = struct.pack(«B», len(pkt))
# Define the data length to be sent
fulllen = struct.pack(«>h», len(pkt)+3)
# I2C write-then-read. Send frame + SMBus header, receive 0
ser.write(‘\x08’+fulllen+’\x00\x00’)
ser.write(«\x92\xc4″+pktlen+pkt)
# If packet has been sent successfully
if ser.read(1) == ‘\x01’:
print «Send OK»
else:
print «Error sending»
ser.write(‘\x00’)
ser.write(‘\x00’)
ser.write(‘\x0F\n’)
quit()
# Open Hydrabus in binary mode
for i in xrange(20):
ser.write(«\x00»)
if «BBIO1» not in ser.read(5):
print «Could not get into binary mode»
quit()
# Switch to I2C mode
ser.write(‘\x02’)
if «I2C1» not in ser.read(4):
print «Cannot set I2C mode»
quit()
#Create the frame to send
p = Ether(src=»https://habr.com/ru/post/429190/11:22:33:44:55:66″, dst=»ff:ff:ff:ff:ff:ff») / IP(src=»https://habr.com/ru/post/429190/10.31.32.82″, dst=»10.31.32.80″)/ICMP()
#Send the frame
send_frame(str(p))
# Return to main binary mode
ser.write(‘\x00’)
#reset to console mode
ser.write(‘\x0F\n’)
После выполнения скрипта можно увидеть пакет, идущий от машины с имплантом, и, что самое интересное, сам сервер вообще не видит этого пакета:
Tcpdump с машины атакующего слева, сервера – справа
Чтение пакетов
Фильтрация
Чтобы узнать, какие фреймы должны пойти в SMBus, NIC использует управляющие фильтры. Они сопоставляют трафик из сети, и либо перенаправляют его на PCIe, либо на SMBus, либо одновременно и туда и туда. С нашей точки зрения это даёт нам большую гибкость:
Доступно семь независимых фильтров MDEF[0:6], и каждый из них можно настроить на перенаправление соответствующего трафика на PCIe поверх SMBus при помощи регистра MANC2H (подробности в главе 8.4.3).
Реализация
Настроить всё правильно оказалось довольно сложно, мы пробовали множество различных комбинаций, чтобы заставить фильтр работать. К счастью, примечание к приложению от Intel дало нам больше деталей по поводу запуска фильтров нужным нам способом.
Используя наш I 2 C-зонд, мы можем настроить всё это четырьмя командами:
// Глобальный запрет фильтров
[ 0x92 0xca 0x01 0x40 ]
// Настроить MDEF[0] на получение фреймов, идущих к UDP/664 и UDP/623
[ 0x92 0xcc 0x06 0x61 0x00 0x00 0x00 0x0c 0x00 ]
// Настроить MANC2H на запрет перенаправления к ОС
[ 0x92 0xcc 0x05 0x0a 0x00 0x00 0x00 0x00 ]
// Включить фильтрацию (SMBus alerting, status reporting / Enable)
[ 0x92 0xca 0x01 0x45 ]
Как описано в главе 8.8.1.3, необходимо установить несколько битов для того, чтобы разрешить получение данных и для отправки фреймов обратно на наш имплант. Мы выбрали SMBus alert, поскольку другие модели позволяют сетевой карте осуществлять асинхронные запросы к SMBus (детали в главе 8.4.5).
Чтение фреймов
Поскольку мы использовали метод SMBus alert, нам нужно было ожидать отключения сигнала SMB_ALRT_N перед отправкой команды Receive TCO Packet. Если бы мы ждали слишком долго, пакет был бы отвергнут NIC.
Чтобы просто проиллюстрировать схему, мы будем отправлять фреймы периодически и отправлять команды на чтение – просто, чтобы подтвердить, что этот принцип работает. Схема выглядит так:
Получается нечто интересное:
Слева SMBus читает фрейм, данные фрейма показаны внизу. Справа tcpdump, работающий на сервере с имплантом, не показывает входящих фреймов.
Ретрансляция фреймов
Меняя регистр MANC2H, возможно сделать так, чтобы трафик, который отправляется на SMBus и PCIe, корректно отображался на сервере. К примеру, давайте создадим перехватывающий фильтр, реагирующий на трафик UDP/161 (SNMP) и отправляющий его на SMBus и PCIe:
// Глобальный запрет фильтров
[ 0x92 0xca 0x01 0x40 ]
// Создать флекс-фильтр 0 на порту 161 (0xa1)
[ 0x92 0xcc 0x04 0x63 0x00 0x00 0xa1 ]
// Настроить MDEF[0] на получение трафика, совпадающего с флекс-фильтром 0
[ 0x92 0xcc 0x06 0x61 0x00 0x00 0x00 0x10 0x00 ]
// Настроить MANC2H на разрешение перенаправления трафика MDEF[0] на PCIe
[ 0x92 0xcc 0x05 0x0a 0x00 0x00 0x00 0x00 ]
// Включить фильтрацию (SMBus alerting, status reporting / Enable)
[ 0x92 0xca 0x01 0x45 ]
Включив фильтры, мы можем отправить SNMP-запрос на сервер с имплантом и увидеть пакет, который перехватил имплант. При этом сервер отвечает на запрос – а значит, пакет был правильно перенаправлен на SMBus и PCIe:
Вверху – перехваченный SNMP-запрос с импланта. Внизу — SNMP-запрос дошёл до сервера.
Заключения
Мы описали возможный метод внедрения небольшого и недорогого микроконтроллера в качестве импланта на уровне NIC. Такому импланту нужны, по меньшей мере, четыре контакта (Vcc, GND, CLK, DAT), и он может управлять картой сервера. Среди его возможностей:
Однако в реальной жизни доступ у такого импланта был бы только к SMBus. В зависимости от схемы материнской платы это устройство может быть единственным из доступных, и тогда взаимодействие с ОС сервера будет невозможно. В случае, когда требуется полный контроль над ОС, лучше всего будет изменить код BMC, поскольку у него и так уже есть доступ ко всем интересным шинам, и он не оставляет видимых следов на материнке.
Ещё один недостаток такого импланта состоит в том, что он может передавать данные на скорости порядка 100 Кб/с, чего недостаточно для полного изучения трафика. Кроме того, имплант способен перехватывать только трафик, приходящий из сети. В результате данное решение кажется неэффективным по сравнению с теми усилиями, которые требуются для его внедрения в оборудование цели.
