Настройка mutual (взаимной, клиент-серверной) аутентификации для защиты Intel AMT
Используя Intel AMT внутри какой-то большой сети вполне логично возникает вопрос использования двусторонней (mutual, взаимной, клиент-серверной и другие подобные термины) аутентификации, т.е. когда при создании HTTPS-соединения идёт проверка не только сертификата сервера (в таком случае - АМТ-компьютера), но и обратный процесс, когда сервер (АМТ-компьютер) проверяет сертификат запрашивающей стороны (того, кто хочет им управлять). И лишь только после успешной проверки покажет привычный web-интерфейс или даст доступ, например, Командиру.
Подобная защита исключает всяческие подборы паролей да и просто скрывает от глаз такой важный интерфейс, как управление с помощью Intel AMT. Потому даже зная, что ваш компьютер поддерживает AMT, хакер в локальной сети, при доступе к Intel AMT интерфейсу вашего компьютера получит запрос на сертификат:
И если у него не будет правильного, то получит отлуп:
Подобная защита является распространённой в критически важных системах, настроим такую же и для Intel AMT.
Для этого я сначала проверяю/устанавливаю сертификаты на АМТ-компьютер, где будет настроена mutual-аутентификация. Захожу на нужный АМТ-компьютер с помощью Командира:
В закладке Security переходим в хранилище сертификатов:
Смотрим какие стоят доверенные root-сертификаты:
В моём случае тут два - один, как видно, остался от предыдущей работы этого компьютера с MeshCentral-сервером. Это не важно, важно лишь то, что АМТ-компьютер будет согласится принять лишь сертификат выданный от имени этих рутов, т.е. будет проверять, что представленный пытающейся присоединиться стороной сертфикат в качестве рута имеет один из этого списка.
Итак, проверили, запомнили и, если нужно, экспортировали или, наоборот, установили нужный трастовый рут.
Далее главная закладка - настройки TLS. В общем случае она обычно имеет следующий вид:
Внизу стоит галка "Accept Non-TLS Connectoins", что обозначает, что ваш АМТ-компьютер будет доступен также и без HTTPS (т.е. на порту 16992) - снимаем.
Далее ставим галку "Include Remote Authentication (Console)", которая как раз и включает проверку АМТ-компьютером сертификата удалённого сервера, который хочет им управлять. Появятся дополнительные настройки:

- Trusted Root Certificates — показывает сколько/какие рут-сертфикаты имются в хранилище сертификатов.
- Trusted Certificate Names — позволяет перечислить FQDN-имена (именно FQDN, имена из одного слова дадут ошибку), которые примет АМТ-компьютер в процессе mutual-аутентификации. Это первая стадия проверки - только имена/шаблоны из данного списка, обязательная стадия проверки их рут-сертификатов также остаётся.
Реальной какой-то привязки к домену нет, т.е. нет проверки, что запрос пришёл именно с такого-то сайта. Потому указывать можно любой, лишь в FQDN-форме и лишь с условием после получить сертификат, подписанный рутом из списка доверенных в хранилище АМТ-сертификатов.
Для этого я на компьютере, где когда-то создавался рут-сертификат AMT-guide запускаю Manageability Director и создаю новый сертификат с именем "apple.rom" от имени рута AMT-guide, который имеется в доверенных на АМТ-компьютере:
Ещё раз повторюсь на счёт имени, специально выбрал не существующее "apple.rom", чтобы показать, что связи с реальными адресами нет, потому Common Name можно было выбирать любым, лишь в FQDN-формате.
Полученный сертификат экспортирую в pfx:

И ставлю его на систему, с которой планирую управлять АМТ-компьютером.
В результате при запросе можно указать данный сертификат:
После проверки получаем доступ к привычной консоли:

В случае Командира проще: ничего указывать не надо, он сам переберёт все установленные в системе сертификаты и если найдёт подходящий - автоматически подключится к АМТ-компьютеру.
Итого, отключение доступа без TLS + взаимная аутентификация = максимальная защита вашего АМТ-компьютера.
п.с. Напоминаю, что VNC-порт для Intel AMT KVM не получится защитить подобным образом.
Добавить комментарий