Если вы их перед этим не пробрасывали, то и закрывать незачем. Технология Intel AMT по дефолту подразумевает локальную сеть (потому за роутером она, что логично, не работает — без его настройки под это).
В случае Intel AMT, сконфигурированной на использование Intel MPS (Manageability Proxy Server) или так называемый режим CIRA (Client Initiated Remote Access) — никакие закрытые порты не помогут (т.к. это исходящий трафик). Однако такая система (сделанная вами или до вас) не будет (напрямую, через веб) подвержена данной уязвимости (с некоторой поправкой на то, что адрес MPS-сервера известен лишь вам), т.к. подключиться к веб-интерфейсу через MPS не получится. Хотя сама дырка останется и теоретически её задействовать можно. Но «коммутаторы» тут точно ни при чём.
Смотря о чём речь. Если речь о системе с поддержкой Intel AMT, то защититься можно:
Отключив AMT, но теоретически и по опыту это может иметь проблемы — условно говоря BIOS пишут вендоры, а Intel предоставляет им готовый модуль в виде MEBx, что для них по сути «чёрный ящик» со всеми вытекающими.
Расконфигурировав AMT, но теоретически (и точно практически) можно запустить локальное конфигурирования с помощью функции HostBasedSetup, как минимум в клиентский режим (если он не отключён).
Включив TLS (порт АМТ 16993), отключив HTTP (порт АМТ 16992) и добавив к дефолтной парольной защите аутентификацию по сертификатам и тогда прежде чем будет запрошен пароль, произойдёт запрос на клиентский сертификат, а если его нет — соединение не будет установлено (т.е. не произойдёт запрос «дырявого» пароля).
Если же у вашей системы нет поддержки Intel AMT, то можно не беспокоиться, т.к. у неё не будет доступа («аппаратного» — через Intel ME в так называемом outbound — внеполосном режиме, когда трафик перехыватывается Intel ME/AMT и он не доходит до ОС) по сети через 16992/16993, т.к. такие порты лишь у Intel AMT (а у Intel SBT нет).
Всё верно, вообще этот веб-интерфейс лишь для баловства и демонстрации. Реальное управление через специальные утилиты (самая лучшая с поправкой на условный Small Business — Manageability Commander) или пакеты ПО (Kaseya, Spiceworks etc), которые знают про возможности и требования Intel AMT.
Всё-таки как не повлияло наличие технологии Intel AMT на IPMI, так она (или же её кончина) не повлияет и на RedFish.
Intel AMT поддерживает RMCP (порты 623/664), собственно, это, как поддержка DASH и прочих других признанных промышленных стандартов, было требованием интегрирования в имеющуюся корпоративную инфраструктуру.
RedFish, мне кажется, просто новая инкарнация IPMI (в частности — из-за использования таких морально древних протоколов как RMCP). При чём, не обязательно успешная, как и всё в таком страшно консервативном сегменте, как серверный.
Это другой уровень во всех смыслах данного слова. Можно сравнить с уязвимостью/ошибкой в приложении на PHP и вероятностью уязвимости/ошибки в nginx/Apache.
TLS 1.0 only. Потому старая Опера и работает, во всех современных принудительно включается неподдерживаемый Intel AMT протокол TLS1.2.
Включить TLS 1.0 в новом Chrome проблематично (если подскажете как — спасибо), а в Firefox в about:config поставьте security.tls.version.max в 1 (единичку).
Однако это касается протокола. Если же речь про вообще решение проблемы с дыркой АМТ, то это два шага — создать и добавить TLS-сертификаты плюс включить mutual:
В статье указано грубое деление чипсетов, где Intel SBT подразумевается у настольных чипсетов B77 и выше.
Размер модуля SBT в Intel ME в разы меньше модуля AMT, потому требования много меньше (и, например, на мобильных он мог быть практически с любым чипсетом). В попытках пристроить технологии «для малого бизнеса», Intel экспериментировал, пытаясь найти подходящую нишу (как среднее между «корпоративным» и «для обычных пользователей»), что дало на выходе включение SBT (или другое название — Small Business Advantage — SBA) и в настольные чипсеты более новых поколений Hxx, например, из вашей ссылки H97. Потому в этом плане утилита, скорей всего права — найдя в системе возможность использования (не обязательно активированную) технологии Intel SBT — она написала про уязвимость.
vPro Verification Table Parameter Definitions
MeCapabilities: 12 bytes of data.
Bytes 0-3: SKU/Capabilities
Bit 0 — ME enabled/disabled (1 = Enabled)
Bit 1 — Intel QST FW support (1 = Supported)
Bit 2 — Intel ASF FW support (1 = Supported)
Bit 3 — Intel AMT FW support (1 = Supported)
Bit 4 — Reserved for future capabilities (must be set to “0”).
Bit 5 – Intel SBT FW support (1 = Supported)
Bit 6 – Intel Level III management (1 = Supported)*
7-31 — Reserved for future capabilities (must be set to “0”).
Bytes 4-11: ME FW Version.
Bits 32:47 — ME FW Minor Version.
Bits 48:63 — ME FW Major Version.
Bits 64:79 — ME FW Build Number.
Bits 80:95 — ME FW Hotfix Number.
Note: If ME is disabled then other data cannot be retrieved.
*Level III management is no longer supported beginning in Release 9.0.
Т.е. утилите без разницы — есть ли реально что-то в вашей системе, стоит бит 3 или 5 — значит система «потенциально уязвима». Однако если в случае AMT понятно, как можно эксплуатировать подобную дырку, то в случае SBA/SBT это совсем не так, ибо если грубо, то SBT это AMT минус сетевой интерфейс (т.е. лишь локальный и так называемый inbound в отличие от поддержки outbound — внеполосного доступа у АМТ, когда её трафик перехватывается до ОС) плюс работа исключительно в режиме CCM (Client Control Mode) — ограниченный по фукнционалу (по отношению к АМТ), а также с ограниченным набором возможностей — в первую очередь это обычно включение-выключение по расписанию с помощью имеющегося у AMT «будильника» (собственно — это и есть «использование функционала АМТ»).
Итого, говорить о уязвимости по отношению к SBT можно, но на практике она, в отличие от дырки АМТ, скажем обтекаемо, сложно (мало, не) применима. Но, конечно, это не отменяет наличие дырки и при наличии обновления, те, кто морально страдает от данного факта, может обновиться.
В основном случае достаточно просканировать порты 16992/16993 (редиректные порты 16994/16995 и мониторинговые 623/664 не важны).
Только вот с «просканировать» могут возникнуть вопросы, ибо сделать локально будет недостаточно, т.к. сконфигурированная AMT-система может управляться удалённо с выключенным локальным агентом (LMS) и такие порты недоступны с проверяемого компьютера, а только из локальной сети. Но для этого нужно точно знать, что речь идёт именно о AMT-варианте, который в простом случае идентифицируется характерной наклейкой а-ля «vPro support» на вашем компьютере/ноутбуке/планшете.
Конечно «могут быть», т.к. Intel ME это «движок», а Intel AMT — это модуль («плагин»), выполняющийся на таком движке. Однако этот модуль (Intel AMT) должен быть в прошивке, а он достаточно объёмный (~5MB). Кроме того другие компоненты — процессор, сетевые компоненты (Ethernet/WiFi), управление питанием должны также иметь компоненты, соответствующие работе Intel AMT.
Потому «могут быть и на других чипсетах, только выключенные» — некорректная формулировка. Если утрировать, то чипсеты Qxx — это «полная версия», а все остальные — версии разной степени урезанности от полной, в том числе это касается и Intel AMT.
И, наконец, потому не «выключенные», а «не включённые», таки это разные вещи.
Для того, чтобы «рулить своим компом», требуется наличие поддержки Intel AMT, а не Intel SBT (SBA), которая в случае материнских плат требует чипсета Qxx (например, Q87 или Q170).
Несколько комментариев по вышеописанной уязвимости Intel AMT. Несмотря на действительно болезненную и досадную ошибку «беспарольного доступа», затрагивающую все AMT6+ системы, нужно отметить, что:
Технология Intel AMT должна быть проинициализирована/сконфигурирована (по умолчанию AMT находится в состоянии unconfigured)
Через AMT нельзя устанавливать и как-то манипулировать установленным на компьютере ПО (без специально предварительно установленного для такой процедуры дополнительного ПО с поддержкой Intel AMT, предназначенного для таких целей)
Удалённая загрузка (IDE-R) с помощью Intel AMT не самое простое дело (а главное — проблемное), потому говорить об этом как о уязвимости — нужно иметь действительно хорошую фантазию
Самый реальный ущерб и неприятность от потенциального доступа с использованием данной дыры — это баловство взломщика, который может включить/выключить/перезагрузить компьютер
Заметить доступ с использованием Intel AMT KVM на взломанный компьютер можно достаточно просто — по моргающей рамке вокруг экрана и соответствующем предупреждении в System Tray (если стоит IMSS)
Если кто-то используя данную дырку зайдёт и изменит ваш АМТ-админский пароль, с помощью той же дыры вы сможете изменить его повторно (после чего см. следующий пункт)
Защититься от уязвимости можно просто — добавив аутентификацию по сертификатам (парольная защита — это прошлый век) и отключив доступ по http (порт 16992) в ностройках Intel AMT
В случае Intel AMT, сконфигурированной на использование Intel MPS (Manageability Proxy Server) или так называемый режим CIRA (Client Initiated Remote Access) — никакие закрытые порты не помогут (т.к. это исходящий трафик). Однако такая система (сделанная вами или до вас) не будет (напрямую, через веб) подвержена данной уязвимости (с некоторой поправкой на то, что адрес MPS-сервера известен лишь вам), т.к. подключиться к веб-интерфейсу через MPS не получится. Хотя сама дырка останется и теоретически её задействовать можно. Но «коммутаторы» тут точно ни при чём.
Если же у вашей системы нет поддержки Intel AMT, то можно не беспокоиться, т.к. у неё не будет доступа («аппаратного» — через Intel ME в так называемом outbound — внеполосном режиме, когда трафик перехыватывается Intel ME/AMT и он не доходит до ОС) по сети через 16992/16993, т.к. такие порты лишь у Intel AMT (а у Intel SBT нет).
Intel AMT поддерживает RMCP (порты 623/664), собственно, это, как поддержка DASH и прочих других признанных промышленных стандартов, было требованием интегрирования в имеющуюся корпоративную инфраструктуру.
RedFish, мне кажется, просто новая инкарнация IPMI (в частности — из-за использования таких морально древних протоколов как RMCP). При чём, не обязательно успешная, как и всё в таком страшно консервативном сегменте, как серверный.
Включить TLS 1.0 в новом Chrome проблематично (если подскажете как — спасибо), а в Firefox в about:config поставьте security.tls.version.max в 1 (единичку).
Однако это касается протокола. Если же речь про вообще решение проблемы с дыркой АМТ, то это два шага — создать и добавить TLS-сертификаты плюс включить mutual:
Размер модуля SBT в Intel ME в разы меньше модуля AMT, потому требования много меньше (и, например, на мобильных он мог быть практически с любым чипсетом). В попытках пристроить технологии «для малого бизнеса», Intel экспериментировал, пытаясь найти подходящую нишу (как среднее между «корпоративным» и «для обычных пользователей»), что дало на выходе включение SBT (или другое название — Small Business Advantage — SBA) и в настольные чипсеты более новых поколений Hxx, например, из вашей ссылки H97. Потому в этом плане утилита, скорей всего права — найдя в системе возможность использования (не обязательно активированную) технологии Intel SBT — она написала про уязвимость.
Bytes 0-3: SKU/Capabilities
Bit 0 — ME enabled/disabled (1 = Enabled)
Bit 1 — Intel QST FW support (1 = Supported)
Bit 2 — Intel ASF FW support (1 = Supported)
Bit 3 — Intel AMT FW support (1 = Supported)
Bit 4 — Reserved for future capabilities (must be set to “0”).
Bit 5 – Intel SBT FW support (1 = Supported)
Bit 6 – Intel Level III management (1 = Supported)*
7-31 — Reserved for future capabilities (must be set to “0”).
Bytes 4-11: ME FW Version.
Bits 32:47 — ME FW Minor Version.
Bits 48:63 — ME FW Major Version.
Bits 64:79 — ME FW Build Number.
Bits 80:95 — ME FW Hotfix Number.
Note: If ME is disabled then other data cannot be retrieved.
*Level III management is no longer supported beginning in Release 9.0.
Т.е. утилите без разницы — есть ли реально что-то в вашей системе, стоит бит 3 или 5 — значит система «потенциально уязвима». Однако если в случае AMT понятно, как можно эксплуатировать подобную дырку, то в случае SBA/SBT это совсем не так, ибо если грубо, то SBT это AMT минус сетевой интерфейс (т.е. лишь локальный и так называемый inbound в отличие от поддержки outbound — внеполосного доступа у АМТ, когда её трафик перехватывается до ОС) плюс работа исключительно в режиме CCM (Client Control Mode) — ограниченный по фукнционалу (по отношению к АМТ), а также с ограниченным набором возможностей — в первую очередь это обычно включение-выключение по расписанию с помощью имеющегося у AMT «будильника» (собственно — это и есть «использование функционала АМТ»).
Итого, говорить о уязвимости по отношению к SBT можно, но на практике она, в отличие от дырки АМТ, скажем обтекаемо, сложно (мало, не) применима. Но, конечно, это не отменяет наличие дырки и при наличии обновления, те, кто морально страдает от данного факта, может обновиться.
Только вот с «просканировать» могут возникнуть вопросы, ибо сделать локально будет недостаточно, т.к. сконфигурированная AMT-система может управляться удалённо с выключенным локальным агентом (LMS) и такие порты недоступны с проверяемого компьютера, а только из локальной сети. Но для этого нужно точно знать, что речь идёт именно о AMT-варианте, который в простом случае идентифицируется характерной наклейкой а-ля «vPro support» на вашем компьютере/ноутбуке/планшете.
Потому «могут быть и на других чипсетах, только выключенные» — некорректная формулировка. Если утрировать, то чипсеты Qxx — это «полная версия», а все остальные — версии разной степени урезанности от полной, в том числе это касается и Intel AMT.
И, наконец, потому не «выключенные», а «не включённые», таки это разные вещи.