Собрание заметок об информационных технологиях
В этой части нашего плана развёртывания Icinga на Debian GNU/Linux 12 "Bookworm" мы рассмотрим особенности настройки поддержки протокола SNMP и интеграции механизма получения SNMP Trap с интерфейсом Icinga 2 API. Предполагается, что на предыдущих этапах мы уже успешно развернули фронтэнд Icinga Web 2 и провели базовую настройку и наполнение данными модуля Icinga Director.
В этой заметке мы рассмотрим пример настройки свободного программного обеспечения Network UPS Tools (NUT) для контролируемого выключения сервера виртуализации Hyper-V на базе ОС Windows Server 2022. В рассматриваемом примере NUT будет использоваться в связке с двумя ИБП APC Smart-UPS SURT6000XLI, в которые установлены ранее рассмотренные платы Инматикс ПСУ Спутник А21. То есть в нашем случае к двум блокам питания хоста виртуализации подключены два разных ИБП, а ПО NUT, установленное на хост, будет контролировать состояние обоих ИБП и в случае проблем с электропитанием на ИБП инициировать команду завершения работы виртуальных машин хоста и штатного выключения хостовой ОС.
В данной обзорной статье мы рассмотрим универсальные платы управления ИБП "ПСУ Спутник", выпускаемые под торговой маркой "Инматикс" на производственной базе российской компании ООО "НПО РПС" ("Научно-производственное объединение разработки промышленных систем"). Эту продукцию мы будем рассматривать как серьёзную альтернативу и антипод низкокачественным образцам импортозамещения.
Для начала расскажу небольшую предысторию о том, как мы вообще пришли к использованию ПСУ Спутник. Так исторически сложилось, что в рамках примыкающего к моим зонам ответственности парка оборудования основная масса ИБП относится к торговой марке APC by Schneider Electric. В былые времена вендор отличался довольно демократичной политикой распространения части своего базового ПО и обновлений микрокода для разных типов оборудования. Но с некоторых пор "эффективные менеджеры", которые точно не смотрели советский мультик про жадного раджу и золотую антилопу, захотели больше денег и началось…
Если у администратора появляется задача развернуть актуальную серверную ОС от Microsoft (Windows Server 2022) на физический сервер HPE не самой актуальной линейки Gen9 (HPE ProLiant DL380 Gen9), то возникает ощущение дежавю и задача принимает вид квеста. Привычный метод быстрого развёртывания драйверов и утилит поддержки оборудования с помощью инструмента HPE Smart Update из пакета Service Pack for ProLiant (SPP) здесь не сработает, так как последний SPP с поддержкой Gen9 ничего не знает о Windows Server 2022, а из последующих, более современных, версий SPP поддержка Gen9 уже выпилена. Поэтому в результате применения любого SPP на указанной связке ОС и модели сервера мы получим систему с парой утилит для управления Smart Array (SSA) и множеством неизвестных устройств в диспетчере устройств Windows. В этой заметке мы рассмотрим вариант решения этой проблемы путём ручного последовательного развёртывания определённых пакетов драйверов и утилит с учётом некоторых нюансов.
Под повсеместные разговоры про импортозамещение получили на одну из производственных площадок два новых ИБП Импульс Форвард 6000 с платами управления Импульс МКИ-211. В этой заметке мы не будем обсуждать сами ИБП Импульс, а поговорим именно о плате управления МКИ-211, внимательно посмотрев на то, что же за продукт предлагает нам производитель.
Когда, в своё время, мы начали работать с системой регистрации телефонных переговоров "Незабудка-II" и с регистраторами речевой информации "Smart Logger BOX" (далее SLBox) от компании "ЦРТ", то одним из первых логичных вопросов был вопрос мониторинга работоспособности этих самых регистраторов. Предложенная производителем на тот момент времени, так называемая, программа мониторинга "Status Monitor" (STC-S449) после развёртывания и изучения функционала показала себя, как не выдерживающее никакой критики программное решение, которое, по моим личным ощущениям, за миску супа писал какой-то голодный студент, прикованный наручниками к батарее. То, зачем это было реализовано именно в таком виде, для меня так и осталось непостижимым.
В прошлом году компанией JSOF была публично раскрыта информация о целом наборе уязвимостей, корни которых уходят в древнюю библиотеку компании Treck, реализующую функции стека протоколов TCP/IP. Эту библиотеку на протяжении многих лет использовали разные производители аппаратного обеспечения для обеспечения работы TCP/IP во встроенном микрокоде firmware на множестве разных типов устройств. Данный пакет уязвимостей получил общее название Ripple20.
Уязвимости, входящие в состав Ripple20, имеют разные уровни критичности и среди них есть некоторые опасные уязвимости, позволяющие удалённо вызвать отказ в обслуживании или даже получать полный доступ над устройством со всеми вытекающими последствиями.
Данная проблема была освещена на множестве интернет-ресурсов, связанных с темой информационной безопасности. Вот некоторые из них:
Часть вендоров на протяжении нескольких месяцев после огласки Ripple20 выпустили обновления микрокода для своих продуктов, в которых закрываются данные уязвимости. Однако некоторые производители намеренно отказались от обновления микрокода некоторых своих продуктов, снятых с текущей поддержки. Таким образом, все уязвимые устройства, не имеющие обновления, но по прежнему эксплуатируемые в рамках локальных/глобальных сетей, вошли в группу повышенных рисков нарушения режима ИБ.
Проблема с уязвимостями Ripple20 заключается в том, что работа по снижению рисков в рамках больших корпоративных сетей с множеством устройств разных производителей и моделей, требует комплексного подхода с применением разных методик защиты, таких как обновление микрокода, ужесточение правил меж-узлового взаимодействия на уровне сети, использование систем обнаружения сетевых аномалий и т.д.
Применительно к вопросу обновления микрокода на эксплуатируемых сетевых устройствах, требуется отдельное планирование и немалый объём работы по устройствам каждого отдельно взятого производителя и модели. В данной заметке мы рассмотрим вариант сбора информации относительно модулей управления источников бесперебойного питания (ИБП) марки APC ("APC by Schneider Electric"), которые широко используются для защиты электропитания серверного и сетевого оборудования.
В одной из прошлых заметок мы уже упоминали про некоторые особенности эксплуатации сетевых многофункциональных устройств Xerox WorkCentre. И в этой заметке мы снова вернёмся к этим устройствам, но уже в контексте их взаимодействия со службой сетевой печати на базе Windows Server 2012 R2.
Продолжая тему мониторинга сетевых устройств по протоколу SNMP в Icinga на примере модулей управления источников бесперебойного питания (ИБП), можно в очередной раз отметить тот факт, что рассмотренная ранее схема с использованием плагина check_snmp дает нам лишь базовые возможности обработки получаемых по SNMP данных. Когда описанным базовым методом мы начали мониторить входное напряжение ИБП разных производителей и разных моделей, со временем пришли к выводу, что использование статически заданных границ (верхней и нижней) для входного напряжения – не очень приемлемый вариант. Проблема заключалась в том, что даже в рамках одной марки ИБП в нашем окружении присутствует множество разных моделей, каждая из которых имеет свои допустимые рабочие диапазоны входного напряжения. При этом на некоторых моделях ИБП эти диапазоны могут регулироваться администратором, как в сторону сужения, так и в сторону расширения.
Ранее мы рассматривали пример настройки мониторинга контроллеров управления источников бесперебойного питания (ИБП) марки APC в Icinga с использованием протокола SNMP. При этом мы использовали плагин check_snmp, который использовался для создания каждой отдельной службы Icinga, использующей простую логику сравнения полученного по SNMP показателя с неким допустимым значением. Однако такой подход позволяет отслеживать не все состояния ИБП, которые можно отнести к нештатным и требующим внимания администратора.
РАБОТАЕТ. PS был косяк, при сохранении из УПП-Пользователи с УЗ gMSA в Крнфигураторе оставалась/не обновлялась "старая" УЗ.
Поставил на Астра Линукс 1,8 Нет слов чтобы описать радость от Вашей статьи. Здоровья Вам крепче стали.
RSS - Записи
Последние комментарии