Собрание заметок об информационных технологиях
В ходе проведения обновления микрокода для модуля управления APC NMC2 AP9630 в ИБП APC Smart-UPS с версии 6.9.6 на новую версию 7.0.4 столкнулись с проблемой, с которой мы сталкивались и ранее при использовании модулей предыдущего поколения NMC1. И так как это был уже не первый случай, было решено описать эту проблему и способ её решения.
В прошлом году компанией JSOF была публично раскрыта информация о целом наборе уязвимостей, корни которых уходят в древнюю библиотеку компании Treck, реализующую функции стека протоколов TCP/IP. Эту библиотеку на протяжении многих лет использовали разные производители аппаратного обеспечения для обеспечения работы TCP/IP во встроенном микрокоде firmware на множестве разных типов устройств. Данный пакет уязвимостей получил общее название Ripple20.
Уязвимости, входящие в состав Ripple20, имеют разные уровни критичности и среди них есть некоторые опасные уязвимости, позволяющие удалённо вызвать отказ в обслуживании или даже получать полный доступ над устройством со всеми вытекающими последствиями.
Данная проблема была освещена на множестве интернет-ресурсов, связанных с темой информационной безопасности. Вот некоторые из них:
Часть вендоров на протяжении нескольких месяцев после огласки Ripple20 выпустили обновления микрокода для своих продуктов, в которых закрываются данные уязвимости. Однако некоторые производители намеренно отказались от обновления микрокода некоторых своих продуктов, снятых с текущей поддержки. Таким образом, все уязвимые устройства, не имеющие обновления, но по прежнему эксплуатируемые в рамках локальных/глобальных сетей, вошли в группу повышенных рисков нарушения режима ИБ.
Проблема с уязвимостями Ripple20 заключается в том, что работа по снижению рисков в рамках больших корпоративных сетей с множеством устройств разных производителей и моделей, требует комплексного подхода с применением разных методик защиты, таких как обновление микрокода, ужесточение правил меж-узлового взаимодействия на уровне сети, использование систем обнаружения сетевых аномалий и т.д.
Применительно к вопросу обновления микрокода на эксплуатируемых сетевых устройствах, требуется отдельное планирование и немалый объём работы по устройствам каждого отдельно взятого производителя и модели. В данной заметке мы рассмотрим вариант сбора информации относительно модулей управления источников бесперебойного питания (ИБП) марки APC ("APC by Schneider Electric"), которые широко используются для защиты электропитания серверного и сетевого оборудования.
Продолжая тему мониторинга сетевых устройств по протоколу SNMP в Icinga на примере модулей управления источников бесперебойного питания (ИБП), можно в очередной раз отметить тот факт, что рассмотренная ранее схема с использованием плагина check_snmp дает нам лишь базовые возможности обработки получаемых по SNMP данных. Когда описанным базовым методом мы начали мониторить входное напряжение ИБП разных производителей и разных моделей, со временем пришли к выводу, что использование статически заданных границ (верхней и нижней) для входного напряжения – не очень приемлемый вариант. Проблема заключалась в том, что даже в рамках одной марки ИБП в нашем окружении присутствует множество разных моделей, каждая из которых имеет свои допустимые рабочие диапазоны входного напряжения. При этом на некоторых моделях ИБП эти диапазоны могут регулироваться администратором, как в сторону сужения, так и в сторону расширения.
Ранее мы рассматривали пример настройки мониторинга контроллеров управления источников бесперебойного питания (ИБП) марки APC в Icinga с использованием протокола SNMP. При этом мы использовали плагин check_snmp, который использовался для создания каждой отдельной службы Icinga, использующей простую логику сравнения полученного по SNMP показателя с неким допустимым значением. Однако такой подход позволяет отслеживать не все состояния ИБП, которые можно отнести к нештатным и требующим внимания администратора.
Многим администраторам, обслуживающим серверную инфраструктуру так или иначе приходилось сталкиваться в своей работе с широко распространённой линейкой источников бесперебойного питания (ИБП) Smart-UPS торговой марки APC by Schneider Electric. Многие из тех, кому самостоятельно приходилось заниматься заменой батарейных картриджей и/или (о боже!) заменой аккумуляторных батарей в батарейных картриджах в этих ИБП, хорошо знают о том, что после замены батарей нужно проводить калибровку ИБП (Runtime Calibration) для того, чтобы ИБП скорректировал расчётное время работы от батарей. Однако далеко не все знают о том, что после смены батарей на некоторых моделях "умных" ИБП APC требуются дополнительные манипуляции по сбросу внутренних регистров блока управления ИБП для того, чтобы время работы от батарей рассчитывалось действительно корректно. В этой заметке мы рассмотрим пример того, как отсутствие необходимых действий может привести к некорректной работе ИБП и то, как это можно исправить.
После базовой настройки мониторинга сетевых устройств (Хостов) по протоколу SNMP в Icinga Director, может возникнуть желание как-то расширить объём информации, хранящейся в Icinga об этих самых Хостах. Например, у тех же модулей управления ИБП в интерфейсе Icinga Web 2 хочется видеть серийные номера устройств, версии прошивок firmware и т.п.. Учитывая то, что в нашем случае в Icinga уже есть базовая информация, необходимая для того, чтобы подключаться к Хостам по протоколу SNMP, возникла идея как-то автоматизировать процесс сбора дополнительных данных о Хосте, используя этот самый протокол SNMP.
В данной части цикла заметок об Icinga мы продолжим тему мониторинга сетевых устройств по протоколу SNMP и рассмотрим пошаговый пример настройки ловушки SNMP Trap в конфигурации Icinga Director. Сразу хочу отметить тот факт, что в Icinga нет встроенных механизмов получения и обработки SNMP Trap. Поэтому, для того, чтобы реализовать нужный нам функционал, нам потребуется настроить стек состоящий из ряда элементов:
В данной части цикла заметок об Icinga будет рассмотрен пример настройки мониторинга сетевых устройств с использованием периодических опросов по протоколу SNMP. В качестве опрашиваемых по SNMP сетевых устройств будут использованы контроллеры управления источниками бесперебойного питания (ИБП) фирм EATON и APC. Эти два типа устройств выбраны для того, чтобы продемонстрировать как возможности опроса по протоколу SNMPv1, так и возможности опроса по расширенному протоколу SNMPv3 с использованием дополнительных средств аутентификации. На стороне сервера мониторинга основная настройка будет производиться в веб-интерфейсе Icinga Director 1.3.1. Читать далее...
В очередной раз мне в руки попалась пара старых контроллеров первого поколения APC UPS Network Management Card (NMC1) AP9618, которые потребовалось настроить для удалённого управления и мониторинга ИБП серии APC Smart-UPS. И в очередной раз столкнулся с проблемой настройки повышения уровня безопасности доступа к этим контроллерам. После обновления до последней имеющейся на сайте APC для этих контроллеров версии Firmware AOS 3.7.3 / SUMX 3.7.2 и включения поддержки HTTPS, я не смог получить доступ по протоколу HTTPS к такому контроллеру ни из одного из современных браузеров.
В ходе эксплуатации источников бесперебойного питания (ИБП) фирмы APC мы используем веб-интерфейс модулей управления UPS Network Management Card (NMC). В нашем случае используется несколько моделей NMC, самой распространённой из которых является AP9619 c прошивкой 3.7.2 от 2010 года (более свежей версии на сайте производителя найти мне не удалось). И периодически мы сталкиваемся с проблемой блокировки доступа к этому самому веб-интерфейсу. То есть при попытке авторизации для доступа к веб-интерфейсу NMC можно получить сообщение о том, что кто-то другой в данный момент уже захватил управление…
РАБОТАЕТ. PS был косяк, при сохранении из УПП-Пользователи с УЗ gMSA в Крнфигураторе оставалась/не обновлялась "старая" УЗ.
Поставил на Астра Линукс 1,8 Нет слов чтобы описать радость от Вашей статьи. Здоровья Вам крепче стали.
RSS - Записи
Последние комментарии