В прошлом году компанией JSOF была публично раскрыта информация о целом наборе уязвимостей, корни которых уходят в древнюю библиотеку компании Treck, реализующую функции стека протоколов TCP/IP. Эту библиотеку на протяжении многих лет использовали разные производители аппаратного обеспечения для обеспечения работы TCP/IP во встроенном микрокоде firmware на множестве разных типов устройств. Данный пакет уязвимостей получил общее название Ripple20.
Уязвимости, входящие в состав Ripple20, имеют разные уровни критичности и среди них есть некоторые опасные уязвимости, позволяющие удалённо вызвать отказ в обслуживании или даже получать полный доступ над устройством со всеми вытекающими последствиями.
Данная проблема была освещена на множестве интернет-ресурсов, связанных с темой информационной безопасности. Вот некоторые из них:
- Блог Касперского - Ripple20: 19 уязвимостей в библиотеке TCP/IP
- SecurityLab - Уязвимости Ripple20 затрагивают миллиарды устройств по всему миру
- "Хакер" - Сотни миллионов IoT-устройств в опасности из-за уязвимостей Ripple20
Часть вендоров на протяжении нескольких месяцев после огласки Ripple20 выпустили обновления микрокода для своих продуктов, в которых закрываются данные уязвимости. Однако некоторые производители намеренно отказались от обновления микрокода некоторых своих продуктов, снятых с текущей поддержки. Таким образом, все уязвимые устройства, не имеющие обновления, но по прежнему эксплуатируемые в рамках локальных/глобальных сетей, вошли в группу повышенных рисков нарушения режима ИБ.
Проблема с уязвимостями Ripple20 заключается в том, что работа по снижению рисков в рамках больших корпоративных сетей с множеством устройств разных производителей и моделей, требует комплексного подхода с применением разных методик защиты, таких как обновление микрокода, ужесточение правил меж-узлового взаимодействия на уровне сети, использование систем обнаружения сетевых аномалий и т.д.
Применительно к вопросу обновления микрокода на эксплуатируемых сетевых устройствах, требуется отдельное планирование и немалый объём работы по устройствам каждого отдельно взятого производителя и модели. В данной заметке мы рассмотрим вариант сбора информации относительно модулей управления источников бесперебойного питания (ИБП) марки APC ("APC by Schneider Electric"), которые широко используются для защиты электропитания серверного и сетевого оборудования.
В конце Ноября и начале Декабря компания Hewlett Packard Enterprise опубликовала пару сервисных бюллетеней, описывающих критическую проблему с некоторыми моделями накопителей SSD, произведённых в Samsung и поставляемых в рамках комплектации серверных платформ и СХД от HPE.
Продолжая тему мониторинга сетевых устройств по протоколу SNMP в Icinga 
При создании RAID-массивов на контроллерах HPE Smart Array не допускается комбинированное использование дисков с разными интерфейсами (SAS и SATA) в рамках одного массива. Поэтому, в случае, если ранее операционная система сервера была установлена на RAID-массив, состоящий из дисков одного типа (например SAS HDD), то в случае необходимости переноса ОС на диски другого типа (например SATA SSD), нам потребуется создать отдельный RAID-массив из дисков такого типа. Здесь мы рассмотрим пример подобного переноса ОС Windows Server 2012 R2, развёрнутой на сервере HPE ProLiant Gen9, без необходимости переустановки ОС, то есть с минимальным временем простоя сервера.
Практическая работа с серверами HP ProLiant DL320s G1 Storage Server (AG651A) каждый раз приводит меня к мысли в том, что одним из наиболее проблемных узлов этой модели является RAID-контроллер. При этом стоит отметить тот факт, что сам по себе RAID-контроллер этой модели, то есть HP Smart Array P400, никаких особых нареканий не вызывает при работе на других серверных платформах, например на HP ProLiant DL380 G5. Однако на серверах DL320s с этим контроллером не редко возникают какие-то странные проблемы. Бывало такое, что на контроллере отказывает модуль кеш-памяти. Меняем модуль и контроллер возобновляет свою штатную работу. Снятый и, якобы неисправный, модуль для проверки ставим на другой аналогичный контроллер в другом сервере, и этот модуль … работает. Иногда установка заведомо рабочего модуля не даёт желаемого результата и приходится менять сам RAID-контроллер. В некоторых случаях бывает даже так, что установка заведомо рабочего контроллера с новым модулем памяти не решает проблемы. На одном из таких "мутных" серверов в попытке выявить и ликвидировать причину возникновения подобных "глюков" в своё время даже поочерёдно менялись платы дисковой корзины Backplane Board, но это тоже не дало вменяемого результата. На фоне такого безрадостного опыта мне в руки снова попался очередной аналогичный сервер DL320s с отваливающимся кеш-модулем на RAID-контроллере и мне подумалось, что нужно попробовать найти какой-то кардинальный способ решения этой проблемы.
