Заливаем прошивку AOS 3.9.2 в контроллер APC NMC AP9618 для поддержки TLS 1.0

В очередной раз мне в руки попалась пара старых контроллеров первого поколения APC UPS Network Management Card (NMC1) AP9618, которые потребовалось настроить для удалённого управления и мониторинга ИБП серии APC Smart-UPS. И в очередной раз столкнулся с проблемой настройки повышения уровня безопасности доступа к этим контроллерам. После обновления до последней имеющейся на сайте APC для этих контроллеров версии Firmware AOS 3.7.3 / SUMX 3.7.2 и включения поддержки HTTPS, я не смог получить доступ по протоколу HTTPS к такому контроллеру ни из одного из современных браузеров.

Например, в конфигурации по умолчанию браузер Internet Explorer 11 (11.672 в составе Windows 10.0.10586) потребовал включения в параметрах браузера поддержки TLS 1.0-1.2, хотя такая поддержка уже была включена: 

Дело в том, что в конфигурации по умолчанию, практически все современные версии браузеров имеют либо отключенную поддержку протокола SSLv3 (как например используемая в моём случае версия IE), либо вовсе больше не поддерживают этот протокол. А у AOS 3.7.3 максимально возможная версия защиты HTTPS реализована именно на уровне SSLv3, то есть фактически вендор в плане решения этой проблемы на текущий момент времени нам ничего хорошего предложить не может. 

Разумеется, в качестве обходного решения для подключения к контроллеру можно использовать и SSH, с которым, кстати говоря, тоже не всё гладко. Ранее уже описывалась проблема с доступом по протоколу SSH2 в AOS 3.7.3 на контроллере AP9619, и насколько я вижу из документа APC FAQ — FA242581 — «Received ssh2_msg_channel_success for nonexistent channel 65536» error message using SSH with PuTTy v0.63 and higher with APC Network Management Card 1 (NMC1) devices, ситуация до сих пор не сдвинулась в лучшую сторону.

Если же всё же говорить про HTTPS, то мы можем включить в настройках браузера поддержку SSLv3, если, конечно, такая возможность всё ещё есть. Однако, как показала практика, веб-интерфейс по протоколу HTTP over SSLv3 если и заработает, то может жутко «тормозить» на выше-обозначенных контроллерах.

Поиск обсуждения аналогичных проблем привёл меня на форум APC в ветку Unable to access my APC Network Management Card (NMC) enabled device via HTTPS (SSL/TLS), где в качестве «костыля» обсуждается вариант обновления прошивки AOS до версии 3.9.0, в которой имеется хотя-бы поддержка TLS 1.0. Далее в этой заметке я и опишу свой опыт выполнения данной процедуры.

Разумеется, описываемые далее манипуляции не снимают полностью проблему с HTTPS на контроллерах APC NMC1, но хотя бы позволяют несколько смягчить эту проблему, по крайней мере на данный момент. И разумеется, это не поддерживаемое решение со стороны APC, так что, если вы решите делать нечто подобное, то всевозможные катаклизмы и стихийные бедствия, вызванные неправильной работой контроллера с «некошерной» прошивкой лежат на вашей совести.      

***

Для начала ознакомимся с тем, какие методы обновления прошивки нам предлагает APC в документе: APC FAQ — FA156047 — How do I upgrade the firmware on an APC Network Management Card (NMC) or NMC embedded device (Rack PDU, etc)?

И как я уже отметил ранее, в моём случае будет использоваться контроллер первого поколения NMC1AP9618, а обновлять я его буду с помощью консольной утилиты NMC Upgrade Tool v1.2

***

Переходим на страницу описания продукта UPS Network Management Card w/ Environmental Monitoring & Out of Band Management и находим страничку с программой обновления прошивки Network Management Card v3.7.2 Firmware for Smart-UPS with AP9617/8/9.
Загружаем файл apc_hw02_aos373_sumx372.exe

Распаковываем файл, как архив, архиватором 7zip, например в каталог /apc_hw02_aos373_sumx372

***

Затем загружаем прошивку Switched & Metered Rack Power Distribution Unit Firmware Revision 3.9.2 (Part Number SFRPDU392) в виде файла apc_hw02_aos392_rpdu392.exe.

Этот архив содержит прошивку версии AOS 3.9.2 с поддержкой TLS 1.0. В Relese Notes (JKUR-7NXU6D_R5_EN.pdf) можно почитать о замечаниях к релизу для этого пакета обновлений, где описаны изменения AOS в отличие от упомянутой на форуме APC версии 3.9.0.

Распаковываем файл, как архив архиватором 7zip, например в каталог /apc_hw02_aos392_rpdu392

***

Копируем файл apc_hw02_aos_392.bin из каталога /apc_hw02_aos392_rpdu392 в каталог /apc_hw02_aos373_sumx372.

После этого в каталоге /apc_hw02_aos373_sumx372 правим файл config.txt, чтобы он принял следующий вид:

AOS = apc_hw02_aos_392.bin
APP = apc_hw02_sumx_372.bin

***

Перед запуском процедуры обновления нужно сделать пару вещей:

— включить на контроллере FTP-Server, если ранее он был выключен;
— отключить RADIUS-авторизацию, если используется, так как с включенной RADIUS-авторизацией процедура обновления может завершиться не корректно, так как утилита не сможет подключиться к FTP-серверу.

Запускаем утилиту upgrd_util.exe из каталога /apc_hw02_aos373_sumx372.

В верхней части вывода утилиты мы должны увидеть то, что используется AOS 3.9.2. Введём IP-адрес контроллера и имя пользователя и пароль локальной учётной записи (по умолчанию apc):

Обратите внимание на то, что пароль пользователя при этом не должен превышать 11 символов. Это ограничение утилиты обновления.

Дождёмся успешного завершения процедуры обновления сначала базовой системы AOS, а затем Application модуля SUMX (применимо для Smart-UPS). Между этими обновлениями контроллер будет перезагружен.

В конце жмём Enter и утилита обновления завершит свою работу.

***

Проверяем результат. Подключаемся к контроллеру по протоколу SSH или заходим на веб-интерфейс (без шифрования) и проверяем информацию о текущих версиях AOS и модуля SUMX:

По моим наблюдениям после установки AOS 3.9.2 никаких проблем с работой контроллера AP9618 не выявлено. Все протоколы доступа работают (SSH, Web, FTP), клиенты DNS/NTP/SMTP работают, SNMP-трапы летают, опрос по SNMP (GET,WALK) работает. Управляемые контроллерами ИБП (Smart-UPS 6000 и 1500 KVA) ведут себя штатно.

***

При включении HTTPS контроллер генерирует само-подписанный сертификат с 768-битным ключом. Использование такого сертификата может быть недостаточно для работы современных версий браузеров, так как они могут блокировать сертификаты с ключом менее 1024 бита. Подтверждение этому можно найти в документе APC FAQ — FA162031 — Network Management Card 1 (NMC1) Information Bulletin: Effects of Microsoft Internet Explorer and other web browsers blocking key lengths less than 1024 bits.

Для того, чтобы исправить данную проблему нужно создать свой сертификат с ключом в 1024 бита и установить его на контроллер. Для генерации запроса и конвертации в удобоваримый для MNC1 формат можно воспользоваться утилитой APC Security Wizard, о которой я писал ранее в заметке Замена сертификата APC Web/SNMP Management Card.

Имеющаяся у меня версия этой утилиты (1.04) при генерации запроса на создание сертификата позволяет определить ключ 1024 или 2048 бит. Крайне рекомендую выбирать именно 1024-битный ключ, так как с сертификатом, который будет иметь 2048-битный ключ, встроенный в контроллер веб-сервер работать будет, но опять же веб-страницы будут глючить и лагать совершенно безбожно (проверено на практике). Где-то в документах встречал информацию о том, что контроллеры NMC1 попросту не поддерживают ключи больше чем 1024 бита, но сейчас уже не вспомню где.

После генерации запроса с ключом нужной длины получаем из локального центра сертификации сертификат в формате X.509 в кодировке DER и с помощью этой же утилиты APC Security Wizard конвертируем в удобоваримый для NMC1 и устанавливаем через веб-интерфейс, как описывалось ранее.

*** 

После установки сертификата с 1024-битным ключом и успешного подключения к контроллеру по HTTPS в Internet Explorer 11 посмотрим свойства защиты веб-страницы.

***

Если вы используете Mozilla Firefox, то лучше обновиться до последней версии ESR 45.5.0, где несмотря на то, что мы получим сообщение типа SSL_ERROR_NO_CYPHER_OVERLAP, у нас будет возможность подключиться к веб-узлу в режиме пониженной безопасности (кнопка Дополнительно, потом переход по ссылке)

При этом браузер автоматически изменит свою конфигурацию, добавив узел в значение настройки security.tls.insecure_fallback_hosts. Это можно проверить, открыв режим конфигурирования настроек через адрес about:config и найдя соответствующую настройку. В старых версиях Firefox подобные исключения безопасности приходилось править вручную конфигурируя указанную настройку.

***

С современной версией Google Chrome 54.0.2840 нам «ловить нечего», так как попытка подключения к контроллеру по протоколу HTTP over TLS 1.0 будет завершаться сообщением ERR_SSL_VERSION_OR_CIPHER_MISMATCH, от которого избавиться не получится. По некоторой информации поддержка SSL3/TLS1.0 была безвозвратно отключена в предыдущих версиях этого браузера. Поэтому теперь если перейти в режим расширенной настройки конфигурации браузера через ссылку chrome://flags/, то мы увидим, что минимально возможная версия — TLS 1.2

Как я понял, в предыдущих версиях браузера откат на понижение безопасности был возможен с помощью параметров реестра, которые предполагалось контролировать групповыми политиками (GPO): The Chromium Projects — Documentation for Administrators — Policy List, где имелись такие параметры как SSLVersionMin (значения ssl3/tls1/tls1.1/tls1.2). Но в текущей версии браузера всё это хозяйство попросту не работает.

***

Если дополнительно поговорить о доступе к контроллерам NMC1 по протоколу SSH, то здесь тоже есть возможность немножко улучшить ситуацию, заменив используемый по умолчанию 768-битный SSH Host Key, на 1024-битный, который мы опять же можем сгенерировать с помощью ранее упомянутой утилиты APC Security Wizard.

Установить сгенерированный ключ можно также через веб-интерфейс контроллера (Administration > Network > Console > ssh host key)

После этого при попытке подключения по протоколу SSH мы получим сообщение об использовании нового 1024-битного ключа.

Однако, как я заметил выше, проблема с использованием Putty версий 0.63 и новее остаётся, и поэтому для доступа к контроллерам AP9617/8/9 всё же придётся использовать старую версию Putty 0.62.

 

Дополнительные источники информации:

Только один комментарий Комментировать

  1. MAD.MAX /

    Алексей, скажу так, по-простому: алгоритмы шифрования для контроллеров управления первой серии слишком, как это по-мягче выразиться, тяжелы — собственно, частично (разумеется, еще и потому, что уже давно есть второе поколение) в этом ответ на вопрос почему АРС не внедрит поддержку официально. Причем, тяжелы — не то слово.

Добавить комментарий