Валидная цифровая подпись на DLL со встроенным бэкдором

Практически по всем профильным СМИ прошла новость о взломе программного обеспечения SolarWinds в рамках глобальной кампании кибершпионажа. Здесь нужно понимать масштаб атаки: этот софт для мониторинга IT-инфраструктуры (CPU, RAM, сеть) используют тысячи частных компаний и государственных учреждений, включая АНБ, Пентагон, Госдеп и проч. В общей сложности 300 000 клиентов по всему миру (данная страница уже удалена с официального сайта SolarWinds, по ссылке копия из веб-архива).

Самое интересное в этой атаке: 1) внедрение бэкдора внутрь обновлений SolarWinds и 2) оригинальный механизм сокрытия данных в служебном HTTP-трафике программы SolarWinds. В двух словах расскажем о методе стеганографии (covert signaling), который здесь применялся.

Отдельные подробности об атаке опубликовала компания FireEye в отчёте от 13 декабря 2020 года. Эта американская компания должна защищать сети своих клиентов от подобных диверсий, но в итоге и сама пострадала от взлома вместе с ними.

Некоторые из клиентов SolarWinds:

Основные факты

• Бэкдор обнаружен спустя семь месяцев после начала атаки, ему присвоено кодовое название SUNBURST. Учитывая масштаб заражения, это серьёзный фейл антивирусных компаний.
  
• Заражённая DLL распространялась с обновлениями платформы SolarWinds Orion, которая служит для мониторинга корпоративной сети.
  
  
  Платформа SolarWinds Orion

Валидная цифровая подпись

Бэкдор обнаружен в библиотеке SolarWinds.Orion.Core.BusinessLayer.dll, которая подписана действительной цифровой подписью компании SolarWinds Worldwide, LLC (скриншот выше).

В частности, инфицирован ряд обновлений программы SolarWinds Orion за март-май 2020 года, которые распространялись с действительной цифровой подписью.

Это был стандартный файл Windows Installer Patch со всеми обычными ресурсами, включая заражённую библиотеку SolarWinds.Orion.Core.BusinessLayer.dll. После установки библиотека нормально загружалась в память штатным экзешником SolarWinds.BusinessLayerHost.exe.

Специалисты Microsoft пояснили, что злоумышленники использовали локальный взлом [on-premises compromise], чтобы получить доступ к доверенному сертификату подписи SAML-токенов организации [SolarWinds]. Это позволило им подделать токены SAML для всех существующих пользователей и аккаунтов организации, включая высокопривилегированные. Судя по всему, речь о физическом проникновении в офис компании (on-premises compromise).

Уникальные особенности

• Алгоритм Domain Generation Algorithm (DGA) для генерации поддоменов и изменения DNS-запросов. Троян отправлял запрос на резолв поддомена avsvmcloud[.]com, а в DNS-ответе содержалась запись CNAME с указанием командного сервера.
  
• Весь трафик маскировался под сетевой трафик по служебному протоколу Orion Improvement Program (OIP) через SolarWinds API. Таким образом, антивирусы и файрволы не могли отличить активность бэкдора от настоящей активности программы SolarWinds.
  
• Программный код бэкдора внедрялся в стандартные программные компоненты.

Стеганография

А вот самая интересная часть как именно бэкдор маскировал пакеты в обычном сетевом трафике:

Для получения данных зловред использовал запросы HTTP GET или HTTP HEAD, и для отправки HTTP PUT или HTTP POST. Метод PUT использовался, когда полезная нагрузка меньше 10000 байт; в противном случае используется POST. HTTP-заголовок If-None-Match содержит заксоренное представление userID, вычисленного ранее, с добавлением случайного массива байтов той же длины.

Полезная нагрузка JSON в запросах HTTP POST и PUT содержит ключи userId, sessionId и steps. Сообщения с данными для отправки на сервер сжаты DEFLATE и однобайтовым XOR. Каждое сообщение отдельно кодируется Base64.

В наблюдаемом трафике тела HTTP-ответов скрываются под доброкачественные XML, связанные со сборками .NET. Но на самом деле данные распределены по многим строкам GUID и HEX. Команды извлекаются из тел HTTP-ответов путём поиска hex-строк с использованием следующего регулярного выражения: \{[0-9a-f-]{36}\}"|"[0-9a-f]{32}"|"[0-9a-f]{16}. Командные данные распределены по нескольким строкам, замаскированным под строки GUID и HEX. Все совпадающие подстроки в ответе фильтруются на наличие символов не-HEX, объединяются вместе и декодируются HEX. Первое значение DWORD показывает фактический размер сообщения, за которым сразу же следует сообщение, а затем необязательные мусорные байты. Извлечённое декодируется однобайтным XOR с использованием первого байта сообщения, а затем разархивируется DEFLATE. Первый символ это целое число ASCII, которое соответствует команде JobEngine с необязательными дополнительными аргументами, разделёнными пробелами.

Заказчик
В случае таких продвинутых атак невозможно установить разработчиков программы. Исследователи делают предположения на основании совпадения кода с ранее обнаруженными хакерскими инструментами, а также исходя из того, кто именно стал жертвой шпионажа.

Например, в 2010 году были повреждены иранские установки для обогащения урана. Очень продвинутый зловред Stuxnet слегка менял скорость вращения установок и в конце концов вывел их из строя. Соответственно, логично предположить, что заказчиками и разработчиками зловредров были спецслужбы США и Израиля, поскольку эти страны планомерно пытаются помешать изготовлению ядерного оружия в Иране, действуя не всегда дипломатическими методами.

Что касается бэкдора SUNBURST, то его приписывают скорее российским хакерам из группировки APT29 (Cozy Bear), исходя из хитроумности применяемых техник, выбора целей и физического проникновения в офис жертвы. Хотя достоверно заказчик и исполнитель не известны.

Правила Snort для обнаружения и блокировки трафика SUNBURST опубликованы в свободном доступе.

---

Представьте, что все, у кого дома есть умная колонка Amazon Echo (Яндекс Алиса, Маруся подставить подходящее), узнали бы, что на протяжении последних 6 месяцев она отпирала их дом и впускала воров внутрь. Как теперь чувствовать себя в безопасности, если злоумышленники могли сделать копии ваших ключей, документов, носителей информации или, например, отравить систему водоснабжения?
В таком положении сейчас находятся тысячи организаций, пострадавших от взлома цепочки поставок программного обеспечения компании SolarWinds при помощи вредоносного приложения Sunburst. Пострадавшие компании отчаянно ищут признаки компрометации, проводят внеочередной аудит безопасности инфраструктуры, а некоторые могут даже приостановить ряд сервисов до окончания расследования.

8 декабря компания FireEye сообщила, что была взломана, и начала расследование с привлечением правительства США и компании Microsoft.
13 декабря FireEye выпустила подробный отчет о компрометации, где описан принцип распространения вредоносного кода через ПО Orion от компании SolarWinds.
17 декабря Агентство по Кибербезопасности и Безопасности Инфраструктуры (CISA) выпустило экстренное сообщение, в котором опросило все компании, использующие ПО SolarWinds, обновить или даже отключить компонент SolarWinds Orion от сети (в Шаге 2 вышеупомянутого сообщения). С тех пор служба расследований инцидентов безопасности Varonis заметила всплеск криминалистических расследований, связанных с этой кампанией, и выявила несколько активных атак.
Хотя большая часть материала на сегодняшний день сосредоточена на устранении последствий от скомпрометированных версий решения SolarWinds Orion, согласно CISA, есть свидетельства дополнительных векторов вторжений, связанных с этой кампанией.

От атак через цепочки поставок сложно защититься

При атаке через цепочку поставок злоумышленник выбирает своей целью доверенного поставщика или доверенный продукт вместо того, чтобы атаковать свои цели напрямую. В данном случае злоумышленники внедрили заранее заготовленный бэкдор (потайной ход) в доверенный программный продукт (SolarWinds Orion), который затем был автоматически разослан тысячам клиентов, замаскированный под обычное обновление.
На этом плохие новости не заканчиваются злоумышленники оказались достаточно изощренными, чтобы месяцами оставаться незамеченными. У них было время оставить дополнительные бэкдоры и получить доступ к множеству систем и данных. В настоящее время организации, получившие вредоносное обновление, вынуждены изучать абсолютно всё: начиная с систем и учетных записей, которые напрямую связаны с SolarWinds, и продолжая расследование далее по цепочке.

Первичное выявление

Независимо от того, являетесь ли вы клиентом Varonis или нет, первый шаг проверить наличие уязвимой версии ПО SolarWinds. Компания SolarWinds определила уязвимые версии, и, по состоянию на 16 декабря 2020 года, выпустила обновления и исправления для замены скомпрометированных компонентов.
Если ваша версия уязвима, вот какие шаги вам следует предпринять:

1. Проверьте подключения к avsvmcloud [.] com и к другим доменам, связанным с атакой
   Проверьте подключения DNS и прокси на предмет активности в доменах avsvmcloud [.] com, а также в других доменах, связанных с системой управления и контроля (C2) эксплойта SolarWinds Sunburst.
   Клиенты Varonis могут легко искать оповещения и события, связанные с активностью в этих доменах, с помощью панели управления Varonis Edge и предустановленных поисковых запросов для поиска угроз.
   
2. Проверьте необычную активность учетных записей и систем, связанных с ПО SolarWinds
   Клиенты Varonis обнаружили необычную активность учетных записей служб, связанных с SolarWinds, в том числе аномальную активность на общих сетевых файловых ресурсах и странные подключения к рабочим станциям пользователей. Любые необычные соединения, события безопасности из Active Directory, или активность на сетевых файловых ресурсах от учетных записей служб SolarWinds должны быть исследованы, особенно в отношении конфиденциальных данных или систем.
   Вот пример уведомления Varonis о необычном поведении сервисной учетной записи SolarWinds аномальная активность на общем сетевом ресурсе:
   
   
   
3. Проверьте необычные обращения и изменения ресурсов, сделанные другими учетными записями служб (не только теми, которые связаны с ПО SolarWinds)
   Просматривайте уведомления (алерты) и логи по необычным аутентификациям и доступу, уделяя особое внимание уведомлениям и действиям учетных записей служб и объектам, к которым они обращаются в гибридных средах (Azure Active Directory).
   Если вам нужна помощь нашего отдела расследований, свяжитесь с нашими представителями, также здесь можно запросить сессию для настройки продукта Varonis DatAlert.
   

Что мы знаем об этой APT-кампании (технический анализ)

Эта атака была проведена без использования уязвимости нулевого дня (по крайней мере такой уязвимости, о которой мы знаем на данный момент). Преобладающая теория, еще не подтвержденная компанией SolarWinds, заключается в том, что злоумышленники использовали открытые учетные данные FTP-сервера, обнаруженные на GitHub в 2018 году, для получения доступа к инфраструктуре обновления программного обеспечения компании.



Злоумышленник смог изменить пакет обновления программного обеспечения и добавить вредоносный бэкдор в одну из библиотек подключаемых модулей (DLL) программы SolarWinds Orion под названием SolarWinds.Orion.Core.BusinessLayer.dll.



Злоумышленники подписали свою вредоносную версию DLL закрытым ключом компании SolarWinds. Сертификат был выдан компанией Symantec.
Мы предполагаем, что злоумышленник смог подписать DLL одним из двух способов:

1. Злоумышленник вклинился в процесс разработки, добавил бэкдор и позволил SolarWinds подписать его в рамках легитимного процесса создания и развертывания ПО.
2. Злоумышленник украл закрытый ключ сертификата, подписал сами DLL и заменил официальную DLL своей вредоносной версией. Это менее вероятно.
   

Любая организация, которая использует ПО производства компании SolarWinds и получает обновления с их серверов, загрузила и запустила вредоносную DLL. Поскольку DLL была подписана и доставлена через официальные серверы обновлений SolarWinds, было чрезвычайно сложно обнаружить вредоносное содержимое.

Анализ бэкдора SolarWinds SUNBURST (BusinessLayer.dll)

Когда мы заглядываем внутрь вредоносной DLL, мы видим, что злоумышленники сделал ставку на скрытность. Они приложили немало усилий, чтобы написать код, который гармонировал бы с остальной частью исходного кода Orion, используя хорошо написанные аргументы и общие, не вызывающие подозрений имена классов и методов, такие как Initialize или Job.



Бэкдор SolarWinds Sunburst действует в несколько этапов:

1. Бомба замедленного действия
   Бэкдор ждет 12-14 дней перед отправкой своего первого сигнала на управляющий сервер (C2). Это значительно усложняет обнаружение и сопоставление атаки с вредоносным обновлением.
   
   
   
2. Сбор информации
   Бэкдор отправляет некоторую базовую информацию обратно на сервер C2 (имя пользователя, IP-адрес, версия ОС, установленные обновления), чтобы определить, стоит ли развивать атаку на данной машине.
3. Связь
   Бэкдор использует свой собственный алгоритм генерации домена (DGA) для поиска активного IP-адреса сервера управления и контроля (C2). При взаимодействии с сервером C2 бэкдор имитирует легитимный канал связи для улучшения ПО SolarWinds OIP (Orion Improvement Program).
   
4. Сокрытие
   Код сканирует машину на наличие антивирусов и других инструментов безопасности, которые могли бы обнаружить его присутствие.
   
   
   
5. Развитие атаки
   Если злоумышленник считает, что сеть стоит исследовать, он использует бэкдор для загрузки небольшого дроппера (загрузчика), известного как TEARDROP, который затем загрузит дополнительные инструменты для выполнения дальнейших действий после вторжения.
   

Алгоритм действий бэкдора

При первом сеансе связи бэкдор отправляет информацию об устройстве и его окружении, зашифрованную в DNS-пакетах.
Необычным является факт, что IP адрес в ответном DNS-пакете определяет следующий шаг бэкдора. В зависимости от того в каком диапазоне находится IP-адрес, процесс SUNBURST завершает работу или активирует дополнительный функционал, например, отключение антивируса или скачивание и запуск новых вредоносов.

Давайте более подробно рассмотрим начало коммуникации бэкдора с C2

1. После загрузки DLL SUNBURST выполняет ряд проверок, чтобы убедиться, что она работает в корпоративной сети, а не на изолированной машине.
2. Злоумышленники использовали то, что наши исследователи называют алгоритмом генерации субдоменов. Его принцип заключается в создании уникального субдомена для каждой жертвы. Алгоритм собирает информацию о локальном устройстве и кодирует ее в небольшую текстовую строку.
3. Затем генерируется часть FQDN сервера C2, к которому будет обращаться бэкдор. Алгоритм генерации использует две жестко заданные строки (domain1 и domain2) + а третья строка выбирается из четырех возможных значений, хранящихся в массиве строк (domain3):
   
   
   
   Расшифрованные значения:
   Domain1 =avsvmcloud[.]com
   Domain2 = appsync-api
   Domain3 = [eu-west-1, us-west-2, us-east-1, us-east-2]
   Функция GetStatus генерирует итоговую строку:
   
   
   
   
4. Далее бэкдор добавляет информацию о жертве (п. 2) к полученному домену (п. 3) и отправляет DNS запрос на получившийся адрес. Соответственно, DNS запрос достигнет сервера, контролируемого злоумышленником.
   Для сбора и передачи информации о жертве используется 4 функции:
   
   GetCurrentString и GetPreviousString используются для получения уникального идентификатора GUID и имени хоста/домена устройства.
   
   GetNextString и GetNextStringEx используются для получения списка запущенных процессов и их статуса вместе с идентификатором GUID.
   
   Отправляя эту информацию через DNS-запросы, серверу C2 предоставляется возможность принимать обоснованные решения о том, как отвечать.
   
   Вот несколько примеров доменных имен, запрошенных SUNBURST:
   
   
   
   Аналитики из Prevasio расшифровали некоторые из субдоменов, обнаруженных в журналах DNS, для идентификации жертв.
   
5. Как упоминалось выше, IP-адрес в DNS-ответе определяет дальнейшие действия SUNBURST. Класс IPAddressHelper содержит жестко заданные диапазоны IP-адресов, одному из которых будет соответствовать IP-адрес, полученный в DNS-ответе:
   
   
   
   В зависимости от того, какой IP-адрес возвращается злоумышленником, SUNBURST будет выполнять методы для получения списка текущих процессов текущих процессов, вызывать свой бэкдор HTTP и многое другое.
   
6. Вместо ответа с IP-адресом DNS-сервер может перенаправить жертву на вторичный C2, отправив соответствующий CNAME. Пример таких доменов, опубликованных в общем доступе:
   
   
   
7. Чтобы избежать обнаружения, SUNBURST выполняет DNS-запросы с низкой интенсивностью, используя случайную задержку между запросами для каждой жертвы / домена, в некоторых случаях ожидая до 120 минут между запросами.
8. SUNBURST также отправляет HTTP-запросы к домену C2 используя псевдослучайный и безвредный на вид URL-адрес для вызова команд, передавая полезную нагрузку в теле HTTP в формате JSON.
   Пример URI:
   
   hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml
   
   Ответ может запускать несколько команд, поддерживаемых бэкдором SUNBURST, таких как чтение/запись файлов, перезапуск устройства и т. д.:
   
   
   
   

   Обнаружение вредоносной DLL

   
   К сожалению, SolarWinds советует клиентам исключать свое программное обеспечение из антивирусного сканирования и из сканирования средствами обнаружения и реакции на вторжения (EDR), чтобы избежать ложных срабатываний. Многие службы безопасности применяют эти типы исключений самостоятельно, чтобы снизить уровень шума от ложных срабатываний.
   
   
   
   Как только бэкдор SolarWinds Sunburst установлен, злоумышленник использует дроппер TEARDROP, который считывает поддельный файл изображения с именем gracious_truth.jpg для декодирования встроенной в него полезной нагрузки Cobalt Strike Beacon, причем полезная нагрузка уже настроена злоумышленником под конкретную жертву.
   Затем выполняются дальнейшие действия после проникновения распространение, повышение привилегий, кража данных и обеспечение дальнейшего присутствия.
   
   Компания FireEye и агентство CISA проделали фантастическую работу, документируя индикаторы компрометации (IOC), выявленные после вторжения. Мы не можем утверждать, что паттерн развития атаки каждой жертвы будет выглядеть одинаково. Фактически, можно с уверенностью сказать, что злоумышленники с большей вероятностью будут использовать тщательно настроенные кампании, управляемые человеком, для кражи специфической информации у каждой жертвы например, инструменты, используемые тестировщиками на проникновение (красной командой) компании FireEye.
   
   Подобные атаки на цепочку поставок являются убедительным аргументом в пользу принятия модели нулевого доверия и обнаружения угроз на основе поведенческого анализа. Злоумышленники смогли сделать свою вредоносную версию DLL программы SolarWinds Orion похожей на обычную версию программного обеспечения. Обнаружить это было практически невозможно, потому что все выглядело легитимно и официально. Тем не менее, как только злоумышленники начинают перемещаться по сети после проникновения, они получают доступ к новым учетным записям и обращаются к данным. Какими бы изощренными ни были действия атакующих, они не знают, как точно сымитировать нормальное поведение всех пользователей и устройств, с которыми они работают, что открывает новое окно возможностей для обнаружения.
   
   Агентство CASA подчеркивает важность анализа поведенческих моделей в оповещении, посвященном рассмотренной угрозе:
   
   При вроде бы легитимном, но на самом деле несанкционированном использовании обычных учетных записей, выявление такой активности требует определенной зрелости системы защиты, чтобы отличить действия, совершаемые за пределами повседневной работы. Например, сложно себе представить, чтобы учетной записи сотрудника отдела кадров вдруг требовалось бы обращаться к базе данных о расследованиях киберугроз.

У сотрудников компании RSA закончился десятилетний срок действия соглашений о неразглашении (NDA), так что они наконец-то смогли рассказать о событиях, которые случились в 2011 году. Эти события навсегда изменили ландшафт мировой индустрии информационной безопасности. А именно, это было первая в истории атака на цепочку поставок (supply chain attack), которая вызвала серьёзную обеспокоенность у американских спецслужб, мягко говоря.

Что такое атака на цепочку поставок? Если вы не можете напрямую атаковать сильного противника типа АНБ или ЦРУ, то вы находите их партнёра и внедряетесь в его продукт. Один такой взлом даёт доступ сразу в сотни серьёзно защищённых организаций. Так произошло недавно с SolarWinds. Но бывшие сотрудники компании RSA смотрят на SolarWinds и испытывают чувство дежавю. Ведь в 2011 году неизвестные хакеры получили доступ к самому ценному, что было в компании RSA хранилищу сидов (векторов генерации). Они используются для генерации кодов двухфакторной аутентификации в аппаратных токенах SecurID, а это десятки миллионов пользователей в правительственных и военных агентствах, оборонных подрядчиках, банках и бесчисленных корпорациях по всему миру.

Впрочем, обо всё по порядку.

Энди Гринсберг из журнала Wired поговорил с несколькими бывшими сотрудниками RSA. Один из них Тодд Литхэм (Todd Leetham), лысый и бородатый аналитик из отдела реагирования на инциденты, которого называли углеродной машиной для поиска хакеров. Именно он первым заподозрил неладное, обратив внимание, что один из пользователей вышел в сеть не со своего компьютера и с нестандартными правами. Он посмотрел логи этого юзера за несколько дней и стало понятно, что тут взлом. Хакеры окопались во внутренней сети.

Хуже всего, что они добрались до хранилища сидов. Технически, этот сервер должен быть в офлайне, отключён от интернета и от остальной сети защита air gap. Но на практике он был защищён файрволом и подключался каждые 15 минут, чтобы выдать новую порцию зашифрованных сидов, которые записывались на компакт-диски и отдавались клиентам. Затем они оставались в хранилище в виде резервной копии.

Исходя из этих векторов генерации происходила генерация кодов двухфакторной аутентификации на токенах SecurID, которые раздавались сотрудникам клиента. То есть и токен, и сервер RSA независимо друг от друга генерировали одинаковые коды.

Алгоритм получения токен-кода

Согласно стандарту SecurID, каждому токену соответствует 128-битное случайное число начальный вектор генерации (сид). Также в каждый токен встроены часы. Токен-код результат работы запатентованного компанией RSA алгоритма, который в качестве параметров берёт текущее время и начальный вектор генерации. По токен-коду невозможно восстановить начальный вектор генерации, так как алгоритм работает в одну сторону.

Токен-код действителен в течение одной минуты (меняется раз в минуту и только один раз). Так как на сервере хранится соответствующие токенам начальные вектора генерации, то он в любой момент может по тому же самому алгоритму восстановить текущий токен-код. Для случая, если часы у сервера и токена расходятся, предусмотрена автоматическая синхронизация. Это достигается благодаря тому, что сервер вычисляет пароль не только для текущей минуты, но также прошлой и будущей минут. Таким образом, если PIN, введённый пользователем верен, а токен-код соответствует соседним минутам, то рассинхронизация учитывается для дальнейших операций.

Если кто-то добрался до хранилища сидов, то это компрометировало токены SecurID у всех клиентов. Поскольку это основной бизнес RSA, то в худшем раскладе компанию вообще можно закрывать

Изучив сетевые логи, Литхэм пришёл к выводу, что эти ключи к королевству RSA действительно украдены.

Он с ужасом читал в логах, как хакеры девять часов методично выкачивали сиды из хранилища и отправляли их по FTP на взломанный сервер у облачного провайдера Rackspace. Но затем он заметил кое-что, что дало лучик надежды: в логах проскочили украденные креденшиалы, имя пользователя и пароль для этого взломанного сервера. Литхэм быстро подключился к удалённой машине Rackspace и ввёл украденные учётные данные. И вот оно: в директории на сервере всё ещё лежала вся украденная коллекция сидов в виде сжатого файла .rar.

Использовать взломанную учётку для входа на сервер, принадлежащий другой компании, и возиться с данными там, по признанию Литхэма, в лучшем случае является неортодоксальным шагом, а в худшем серьёзное нарушение законов США о несанкционированном доступе к информации. Но, глядя на украденную святая святых RSA на этом сервере Rackspace, он не колебался: Я был готов к последствиям, говорит он. В любом случае я не мог отдать наши файлы, и он ввёл команду на удаление файла и нажал Enter.

Через несколько мгновений в консоль пришёл ответ: Файл не найден. Он снова изучил содержимое сервера. Папка была пуста. Хакеры забрали базу с сервера за несколько секунд до того, как он попытался её удалить!

Он охотился за хакерами несколько суток днём и ночью, и вот теперь почти схватил за рукав убегавшего вора. Но тот буквально ускользнул сквозь пальцы, скрывшись в тумане с самой ценной информацией (как показало дальнейшее расследование, это могли быть хакеры из подразделения киберразведки APT1 Народно-освободительной армии Китая на базе войсковой части 61398 в пригороде Шанхая. Или кто-то искусно выдавал себя за них).


Расположение войсковой части 61398, источник

Через несколько дней RSA была вынуждена объявить о взломе. И это поистине изменило ландшафт кибербезопасности. Первая успешная атака на цепочку поставок, жертвами которой стали тысячи организаций, самые защищённые агентства и военные подрядчики. Только спустя десять лет случилось нечто подобное с червём NotPetya, а затем с системой компании SolarWinds (18000 клиентов по всему миру), но для того времени история RSA была беспрецедентной. Практически никто даже не предполагал, что можно проводить атаки таким образом через прокси в цепочке поставок.

Это открыло мне глаза на атаки типа supply chain, говорит Микко Хиппонен, главный научный сотрудник F-Secure, которая опубликовала независимый анализ инцидента RSA. И изменило мой взгляд на мир: если вы не можете проникнуть в цель, то находите технологию, которую использует жертва, и вместо этого проникаете туда.

Его коллега Тимо Хирвонен говорит, что инцидент стал тревожной демонстрацией растущей угрозы от нового класса хакеров. От высококлассных специалистов, которые выполняют заказы внешней разведки. Компания RSA работает в сфере информационной безопасности и её бизнес защищать других. Если она не в силах защитить даже себя, то как она может защитить остальной мир?

Вопрос был вполне буквальным. Кража векторов генерации означала, что у тысяч клиентов RSA скомпрометирована критическая защита 2FA. После кражи векторов генерации злоумышленники могли вводить коды с токенов SecureID практически в любой системе.

Спустя десять лет закончился срок NDA у многих ключевых руководителей компании RSA и мы можем узнать подробности этого инцидента. Сегодня взлом RSA видится как предвестник нашей теперешней эры цифровой незащищённости и невероятной активности государственных хакеров во многих сферах общественной жизни, включая социальные сети, СМИ и политику. Взлом RSA это урок, как решительный противник может подорвать то, чему мы больше всего доверяем. А потому что не надо ничему доверять.

Анализ инцидента показал, с чего началась атака с невинного письма по электронной почте, которое получил один сотрудник австралийского подразделения, с темой План набора персонала на 2011 год и приложенной электронной таблицей Excel. Внутри был скрипт, который использовал 0day-уязвимость в Adobe Flash, устанавливая на компьютер жертвы хорошо известный троян Poison Ivy.

Точка входа в сеть RSA совершенно банальное внедрение, которое бы не сработало, если бы жертва работала под управлением более новой версии Windows или Microsoft Office или был ограничен доступ к установке программ на свой компьютер, как рекомендуют сисадмины во многих корпоративных и правительственных сетях.

Но после этого проникновения злоумышленники начали демонстрировать свои реальные способности. На самом деле аналитики пришли к выводу, что в сети одновременно орудовали по крайней мере две группы. Одна группа получила доступ в сеть, а вторая группа высококвалифицированных специалистов использовала этот доступ, возможно, без ведома первой группы. Вторая атака была гораздо более продвинутой.

На компьютере австралийского сотрудника кто-то использовал инструмент, который извлекает учётные данные из памяти. Затем он использует эти учётки для входа в другие машины. Потом сканируется память этих новых компьютеров в поисках новых учёток и так далее, пока не найдены логины привилегированных администраторов. В конце концов хакеры добрались до сервера, содержащего учётные данные сотен пользователей. Сегодня эта техника кражи учётных данных является распространённой. Но в 2011 году аналитики были удивлены, увидев, как хакеры продвигаются по всей сети: Это был действительно самый жестокий способ эксплойтить наши системы, который я когда-либо видел, говорит Билл Дуэйн (Bill Duane), опытный инженер-программист и разработчик алгоритмов RSA.

Обычно такие инциденты обнаруживают спустя месяцы после ухода хакеров. Но взлом 2011 года был особенным: в течение нескольких дней следователи, по сути, догнали хакеров и наблюдали за их действиями. Они пытались проникнуть в систему, мы обнаруживали их через минуту или две, и тогда отключали систему полностью или доступ к ней, говорит Дуэйн. Мы сражались неистово как звери, в реальном времени.

Именно в разгар этой лихорадочной схватки Литхэм поймал хакеров на краже сидов с центрального хранилища, что предположительно было их приоритетной целью. Вместо обычных подключений каждые 15 минут, Литхэм видел в логах тысячи непрерывных запросов каждую секунду. Хакеры собирали векторы генерации не на одном, а на трёх скомпрометированных серверах, передавая запросы через ещё одну подключённую машину. Они распределили коллекцию сидов на три части, перенесли их на удалённый сервер Rackspace, а затем объединили в полную базу хранилища RSA. Я подумал: это офигенно круто, говорит Литхэм. Я вроде как восхищался этим. Но в то же время понимал, что мы в полном дерьме.

Когда до Литхэма дошло, что коллекция сидов скопирована, и после того, как он сделал запоздалую попытку удалить файл с сервера, чудовищность события поразила его: он реально подумал, что компании RSA настал конец.

Паника

Поздно ночью служба безопасности узнала, что хранилище ограблено. Билл Дуэйн сделал звонок с предупреждением, что они физически отключат столько сетевых соединений, сколько необходимо, чтобы ограничить ущерб и остановить дальнейшую кражу данных. Они надеялись защитить информацию о клиентах, которая сопоставляется с конкретными векторами генерации. Кроме того, они хотели предотвратить кражу приватного ключа шифрования, необходимого для расшифровки сидов. Дуэйн с менеджером вошли в дата-центр и начали один за другим отсоединять кабели Ethernet, отключая все серверы и даже веб-сайт компании: Я фактически закрыл бизнес RSA, говорит он. Я искалечил компанию, чтобы остановить любую потенциальную дальнейшую публикацию данных.

На следующий день генеральный директор RSA Арт Ковиелло (Art Coviello) сделал публичное заявление о том, что взлом продолжается. Масштабы вторжения всё увеличивались по мере раскрытия новых деталей. О взломе хранилища сидов SecurID поначалу не было известно, но когда вскрылся этот факт, руководству нужно было принять решение. Некоторые советовали скрыть этот факт от клиентов (среди них спецслужбы, разведка, армия США). Но всё-таки решили раскрыть информацию персонально обзвонить каждого клиента и заменить все 40 с лишним миллионов токенов. Но у RSA и близко не было в наличии такого количества токенов Только через несколько недель компания сможет возобновить производство, и то в меньшем количестве.

Группа из почти 90 сотрудников RSA заняла конференц-зал и начала многонедельный обзвон всех клиентов. Они работали по сценарию, проводя клиентов через защитные меры, такие как добавление или удлинение PIN-кода как части логина SecurID, чтобы усложнить репликацию хакерами. Во многих случаях клиенты начинали орать, вспоминает Дэвид Кастиньола (David Castignola), бывший директор по продажам RSA в Северной Америке. Каждый сделал по сотне таких звонков, даже топ-менеджерам и руководству пришлось этим заниматься (клиенты встречались слишком важные).

В то же время в компании начала распространяться паранойя. Кастиньола вспоминает, как в первую ночь проходил мимо маленькой комнатушки с сетевым оборудованием а из неё вдруг начало выходить абсурдное количество людей, гораздо больше, чем он мог себе представить, что туда поместится. Кто эти люди? спросил он у другого руководителя, стоявшего неподалёку. Это правительство, неопределённо ответил тот.

На самом деле, к тому времени АНБ и ФБР уже прислали своих людей, чтобы расследованию компании, также как и оборонный подрядчик Northrop Grumman и компания по реагированию на инциденты Mandiant (по случайности, сотрудники Mandiant уже были на месте во время взлома, устанавливая сенсоры для системы безопасности в сети RSA).

Сотрудники RSA начали принимать решительные меры. Обеспокоенные тем, что телефонная система может быть скомпрометирована, компания сменила операторов связи, перейдя с AT&T на Verizon. Руководители не доверяли даже новым телефонам, они проводили личные встречи и передавали бумажные копии документов. ФБР, опасаясь крота в RSA из-за очевидного уровня знаний злоумышленников о системах компании, начало проверять биографические данные всех сотрудников.

Окна некоторых офисов руководителей и конференц-залов были покрыты слоями обёрточной бумаги, чтобы предотвратить прослушку с помощью лазерных микрофонов воображаемыми шпионами в окрестных лесах, прямо как во время нынешней истерии с гаванским синдромом. Здание проверили на наличие жучков. Несколько руководителей действительно нашли пару жучков, хотя некоторые из них были такими старыми, что у них сели батареи. Но не было понятно, имеют ли эти они какое-то отношение к инциденту.

Тем временем команда безопасности RSA и сторонние специалисты, привлечённые на помощь, начали разрушать здание до фундамента, как они выражались. На каждой машине, к которой прикасались хакеры, форматировались диски, и даже на соседних машинах. Мы физически обошли всё вокруг, и если на компьютере были хакеры, мы всё стирали, говорит Сэм Карри (Sam Curry), бывший директор по безопасности RSA. Если вы потеряли данные, очень жаль.

Вторая волна

В конце мая 2011 года, примерно через два месяца после объявления об инциденте, RSA всё ещё восстанавливалась и извинялась перед клиентами. Но здесь пошла вторая волна.

Влиятельный техноблогер Роберт Крингли опубликовал слухи о взломе крупного оборонного подрядчика из-за скомпрометированных токенов SecureID. Всем сотрудникам компании пришлось менять токены.

Спустя два дня агентство Reuters раскрыло имя взломанного подрядчика: это был Lockheed Martin, настоящая золотая жила для промышленного шпионажа.


Многофункциональный истребитель-бомбардировщик пятого поколения F-35 Lightning II производства Lockheed Martin

В последующие дни в новостях упоминались оборонные подрядчики Northrop Grumman и L-3 Communications, говорилось о хакерах с векторами генерации для токенов SecurID, хотя конкретных доказательств никто не предоставил, по понятным причинам, ведь речь идёт о военных подрядчиках (см. топ-100 подрядчиков правительства США).

Однако в июне 2011 года исполнительный директор RSA признал, что украденные сиды действительно использовались в атаке на Lockheed Martin. Спустя десять лет он уже отказывается от своих слов. Теперь бывшие руководители компании говорят, что использование сидов RSA никогда не было доказано.

Хотя в 2013 году представители Lockheed Martin на форуме Kaspersky Security Analyst Summit в Пуэрто-Рико подробно рассказали, как хакеры использовали векторы генерации кодов для токенов SecurID в качестве ступеньки для проникновения в сеть.

Сейчас источник в компании Lockheed Martin подтверждает выводы того расследования. По его словам, компания видела, как хакеры вводили коды SecurID в режиме реального времени, при этом пользователи не теряли свои токены. После замены этих токенов хакеры продолжали безуспешно вводить коды со старых токенов.

АНБ, со своей стороны, никогда особо не сомневалось в роли RSA в последующих взломах. На брифинге в Сенатском комитете по вооружённым силам через год после взлома директор АНБ генерал Кит Александер (Keith Alexander) заявил, что взлом RSA привёл к тому, что по крайней мере один американский оборонный подрядчик стал жертвой лиц, владеющих поддельными удостоверениями, а Министерство обороны было вынуждено заменить все токены RSA.

Когда стало известно о причастности группировки APT1, Билл Дуэйн распечатал фотографию их штаб-квартиры в Шанхае и приклеил к доске для игры в дартс в своём кабинете.

Дуэйн ушёл из RSA в 2015 году после более чем 20 лет работы в компании. Автор статьи в Wired Энди Гринберг задал ему такой вопрос: Как ты думаешь, в какой момент история со взломом RSA действительно закончилась: после отключения серверов в дата-центре? Или когда АНБ, ФБР, Mandiant и Northrop закончили расследование и ушли?. Инженер ответил: Мы считали, что атака никогда не закончилась. Мы знали, что они оставили бэкдоры и смогут проникнуть в сеть когда захотят.

Печальный опыт Дуэйна и компании RSA должен научить всех нас, что каждая сеть грязна, как он выразился. Теперь он советует компаниям сегментировать системы и изолировать самые ценные данные так, чтобы они были недоступны даже для противника, который уже проник внутрь периметра.

Что касается Тодда Литхэма, то он наблюдал фиаско SolarWinds в течение последних шести месяцев с мрачным чувством дежавю. Выводы из истории RSA он формулирует в более резких выражениях, чем его коллега. По его мнению, это было редкое свидетельство того, как хрупка сегодня мировая система информационной безопасности: Это карточный домик перед началом торнадо, говорит он.

Он утверждает, что SolarWinds продемонстрировал, насколько ненадёжной остаётся эта структура. По мнению Литхэма, мир безопасности слепо доверял чему-то за пределами своей модели угроз. Никто не предполагал, что противник может это скомпрометировать. И вот опять противник вытащил карту, которая стояла в самом основании карточного домика, а все думали, что это твёрдая почва.

Привет, Хабр! В начале июля Solarwinds анонсировал релиз новой версии платформы Orion Solarwinds 2020.2. Одно из нововведений в модуле Network Traffic Analyzer (NTA) поддержка распознавания IPFIX-трафика от VMware VDS.



Анализ трафика в среде виртуального коммутатора важен для понимания распределения нагрузки на виртуальную инфраструктуру. Анализируя трафик, можно также обнаружить миграцию виртуальных машин. В этой статье мы расскажем о настройках экспорта IPFIX на стороне виртуального коммутатора VMware и о возможностях Solarwinds по работе с ним. А в конце статьи будет ссылка на онлайн-демо Solarwinds (доступ без регистрации и это не фигура речи). Подробности под катом.

Для корректного распознавания трафика от VDS, сначала нужно настроить подключение через интерфейс vCenter, а уже потом анализ трафика и отображение точек обмена трафиком, получаемого от гипервизоров. При желании, коммутатор может быть настроен на получение всех записей IPFIX с одного IP-адреса, привязанного к VDS, но, в большинстве случаев, более информативно видеть данные, извлекаемые из трафика, полученного от каждого гипервизора. Трафик, который приходит, будет представлять соединения от или к виртуальным машинам, расположенных на гипервизорах.

Еще один доступный вариант конфигурации экспорт только внутренних потоков данных. Эта опция исключает потоки, которые обрабатываются на внешнем физическом коммутаторе, и предотвращает дублирование записей трафика для соединений от и к VDS. Но полезнее отключить эту опцию и наблюдать за всеми потоками, которые видны в VDS.

Настройка трафика от VDS

Начнём с добавления экземпляра vCenter в Solarwinds. После этого NTA будет обладать информацией о конфигурации платформы виртуализации.

Перейдите в меню Manage Nodes, далее Settings и выберите Add Node. После этого нужно ввести IP-адрес или полное доменное имя экземпляра vCenter и выбрать VMware, Hyper-V, or Nutanix entities в качестве метода опроса.



Перейдите в диалоговое окно добавления узла, добавьте учетные данные экземпляра vCenter и протестируйте их для завершения настройки.



В течении некоторого времени будет выполняться начальный опрос экземпляра vCenter, обычно 10-20 минут. Нужно дождаться завершения, а уже потом включить экспорт IPFIX на VDS.

После настройки мониторинга vCenter и получения инвентарных данных по конфигурации платформы виртуализации, включим на коммутаторе экспорт записей IPFIX. Самый быстрый способ сделать это через клиент vSphere. Перейдем на вкладку Networking, выберем VDS и на вкладке Configure найдём текущие настройки для NetFlow. VMware использует термин NetFlow для обозначения экспорта потока, но фактический протокол, который используется IPFIX.



Чтобы включить экспорт потока, выберите Settings в меню Actions вверху и перейдите к Edit NetFlow.



В этом диалоговом окне введите IP-адрес коллектора, который по совместительству является экземпляром Orion. По умолчанию обычно используется порт 2055. Рекомендуем оставить поле Switch IP Address пустым, что приведет к получению потоковых записей, получаемых именно от гипервизоров. Это даст гибкость при дальнейшей фильтрации потока данных от гипервизоров.

Оставьте поле Process internal flows only отключенным, что позволит видеть все коммуникации: как внутренние, так и внешние.

Как только включите экспорт потока для VDS, нужно будет включить его также и для распределенных порт-групп, от которых хотите получать данные. Самый простой способ сделать это щелкнуть правой кнопкой мыши на панели навигации VDS и выбрать Distributed Port Group, а затем Manage Distributed Port Groups.





Откроется диалоговое окно, в котором нужно установить флажок Monitoring и нажать Next.

На следующем шаге можете выбрать определённые или все группы портов.



На следующем шаге переключите NetFlow на Enabled.



Когда на VDS и распределенных порт-группах включен экспорт потока, вы увидите, что записи потоков для гипервизоров начинают поступать в экземпляр NTA.



Гипервизоры можно увидеть в списке источников данных потока на странице Manage Flow Sources в NTA. Переключитесь на Nodes.



Результаты настройки вы можете увидеть на демо-стенде. Обратите внимание на возможность провалиться на уровень узла, протокола взаимодействия и т.д.



Интеграция с другими модулями Solarwinds в одном интерфейсе, позволяет проводить расследования в различных разрезах: посмотреть какие пользователи входили на виртуальную машину, производительность сервера (посмотреть демо), и приложений на нём, посмотреть связанные сетевые устройства и много чего ещё. Например, если в вашей сетевой инфраструктуре используется протокол NBAR2, Solarwinds NTA может успешно распознавать трафик от Zoom, Teams или Webex.

Основная цель статьи показать простоту настройки мониторинга в Solarwinds и полноту собираемых данных. В Solarwinds есть шанс увидеть полную картину происходящего. Если хотите презентацию решения или проверить всё у себя оставьте заявку в форме обратной связи или позвоните.

На Хабре у нас также есть статья о бесплатных решениях Solarwinds.

Подписывайтесь на нашу группу в Фейсбуке.

Solarwinds очень известен своими решениями по мониторингу и удаленному управлению (Dameware). В этой статье мы расскажем об обновлениях платформы мониторинга Orion Solarwinds версии 2020.2 (вышла в июне 2020 года) и приглашаем вас на вебинар. Расскажем о решаемых задачах по мониторингу сетевых устройств и инфраструктуры, мониторингу flow- и span-трафика (а span Solarwinds тоже умеет, хотя, многие удивляются), мониторингу прикладного ПО, управлению конфигурациями, управлению адресным пространством и о реальных кейсах внедрения этого продукта у российских заказчиков в первую очередь, в организациях банковской и нефтегазовой отрасли.



Вебинар проведем 19 августа в 10 утра совместно с компанией-дистрибьютором Аксофт. Регистрация здесь.

А ниже под катом вы узнаете о новинках последней версии Solarwinds 2020.2. В конце статьи будет ссылка на онлайн-демо.

Платформа Orion Solarwinds это различные модули для мониторинга и управления. Каждый из модулей получил расширение функционала, появилась поддержка новых устройств и протоколов.

Network Performance Monitor (NPM) 2020.2

Мониторинг до 1000000 элементов на одном экземпляре платформы Orion. По сравнению с версией 2018.2, в которой максимальное число элементов ограничивалось 400000, рост производительности составил 250%. Кроме этого, увеличилась скорость холодного старта системы: слева версия 2020.2, справа версия 2019.4. Об улучшениях производительности можно узнать больше на этой странице в блоге Solarwinds.



Улучшились представления Solarwinds: создание и настройка текстовых полей, надписей или макетов, добавление пользовательских значков, добавление фигур, динамического фона, массовое администрирование и улучшенная работа с временной шкалой. Подробнее об улучшениях в части дашбордов можно узнать в блоге Solarwinds.



Модернизирован функционал создания кастомных дашбордов. Теперь представления можно создавать на основе языка запросов SWQL. Подробная информация в на странице блога Solarwinds.



Упрощение процесса обновления: возможность предварительного обновления, отчеты о плане обновления, автоматизация обновлений с помощью Orion SDK. Подробнее на этой странице.



Улучшение влияния состояния дисковых томов на статус родительского элемента инфраструктуры (ноды). Теперь влияет не только статус (доступен/не доступен), но и состояние утилизации дискового пространства. Можно также настраивать, что именно будет влиять на статус ноды. Подробности на этой странице.



Solarwinds разработал специальный SDK на базе PowerShell скриптов для загрузки языковых пакетов в систему. Может быть, когда-нибудь в Solarwinds появится и поддержка русского языка. Подробнее по этой ссылке.

Network Traffic Analyzer (NTA) 2020.2

Этот модуль улучшился по части поддержки распознавания трафика от VMware Virtual Distributed Switch (VDS) и интеграции с модулем Solarwinds IP Address Manager. Сейчас немного подробнее.

Анализ трафика крайне важен для понимания того, как нагрузки на элементы виртуальной инфраструктуры связаны и взаимодействуют между собой. Поддержка VDS помогает оценить влияние миграции и определить нагрузки с точки зрения трафика, который генерируется на других на виртуальных машинах, а также выявить зависимости от внешних сетевых служб.

VMware Virtual Distributed Switch коммутирует обмен данными между гипервизорами и на нём можно настроить экспорт данных по протоколу IPFIX.



После настройки отправки Netflow-трафика, в интерфейсе Solarwinds начнут появляться данные. О том, как настроить VMware VDS на отправку трафика на коллектор, можно прочитать в этой статье в блоге Solarwinds.

Улучшенная интеграция с IPAM позволяет повторно использовать уже созданные IP-группы, описывать точные условия отправки уведомления, которые ссылаются на трафик приложения с IP-группами или конкретными конечными точками.



При помощи IP-групп можно также описывать приложения, при этом в уведомлении будет указано это приложение. Подробнее об интеграции с IPAM в блоге Solarwinds.

Network Configuration Manager (NCM) 2020.2

Самое важное обновление появление возможности одновременного обновления прошивки сразу нескольких устройств.



Другое обновление появление встроенной базы с устройствами Cisco в статусе EOL и EOS. Подробнее в блоге Solarwinds.

IP Address Manager (IPAM) 2020.2

В центре внимания обновлений этого выпуска были пользовательские возможности и функциональность.



И модуль IPAM, и NTA имеют средства для создания и работы с группами IP, то есть коллекциями конечных точек или подсетей, которые ссылаются на группы конечных точек. Сейчас получаемый трафик можно характеризовать с точки зрения группы IP. Подробнее об обновлениях в IPAM в блоге Solarwinds.

User Device Tracker (UDT) 2020.2

Появилась поддержка технологии Cisco Viptela и устранены баги. Подробнее об обновлениях UDT читайте в блоге Solarwinds.

VoIP & Network Quality Manager (VNQM) 2020.2

В этом релизе появилась поддержка операций IPSLA от коммутационного центра Cisco Nexus для центров обработки данных. Для операций IPSLA, которые предварительно настроены на коммутаторах Cisco Nexus 3K, 7K и 9K, VNQM обнаружит их и запустит мониторинг. VNQM не включает возможности создания новых операций на устройствах. Ниже перечислены поддерживаемые операции.



В зависимости от платформы и конкретной операции, некоторые из них опрашиваются через командную строку. Для коммутаторов Cisco Nexus должны быть предоставлены текущие учетные данные CLI. Обратите внимание, что операции IPSLA не поддерживаются на коммутаторах серии Nexus 5K.





После настройки сбора данных по операциям, данные появятся в интерфейсе. Об обновлениях VNQM подробнее написано в блоге Solarwinds.

Log Analyzer 2020.2

Основное улучшение добавление возможности анализа плоских файлов журналов. Эту аналитику можно использовать при расследовании причин возникновения нештатных ситуаций. Подробнее об обновлениях Log Analyzer можно узнать в блоге Solarwinds.

Server & Application Monitor (SAM) 2020.2

В SAM появились поллеры, которые можно привязывать к объектам мониторинга, их аж 23 штуки. При помощи поллеров можно снимать данные от PaaS, IaaS, локальных и гибридных инфраструктур. Поллеры подключаются через REST APIs к целевым системам: Azure, JetBrains, Bitbucket, Jira и другим. На скриншоте ниже приведён пример карты инфраструктуры, обнаруженной при помощи стандартного шаблона для Office 365 и шаблона поллера для Azure AD.



Для отображения собираемых данных в Solarwinds SAM предусмотрены готовые представления:



Следующее улучшение расширение количества объектов мониторинга, которые поддерживает инсталляция Solarwinds, теперь это 550000 компонентов или 40000 нод (зависит от типа лицензий Solarwinds).

В версии SAM 2020.2 были обновлены некоторые шаблоны мониторинга, например, для JBoss и WildFly.

SAM 2020.2 получил сертификат Nutanix Ready Certified, который позволяет устанавливать SAM на гипервизоре Nutanix AHV и использовать Nutanix REST APIs для работы с AHV.



Появился мастер установки обновлений. При помощи него можно спланировать обновление и провести тестовую установку.



Solarwinds появился также и в магазине приложений AWS. В Azure он уже есть.



Узнать подробнее об обновлениях в модуле SAM можно узнать по ссылке.

Virtualization Manager (VMAN) 2020.2

Важное обновление этого модуля появление поддержки визуализации на картах инфраструктуры Nutanix.



С версии 2020.2 VMAN отслеживает показатели хранения на всех уровнях среды Nutanix от уровня кластера и хоста до отдельных виртуальных машин и хранилищ данных.



Подробнее об обновлениях VMAN можно узнать в блоге Solarwinds.

Storage Resource Manager (SRM) 2020.2

Появилась поддержка мониторинга здоровья NetApp 7-Mode, расширилась поддержка сбора метрик с контроллеров массивов Dell EMC VNX/CLARiiON, а также появилась совместимость с FIPS. Об обновлениях в модуле SRM можно узнать в блоге Solarwinds.

Server Configuration Monitor (SCM) 2020.2

Появилась возможность аудита изменений баз данных.



Из коробки поддерживается аудит следующих баз данных: MS SQL Server (31 элемент), PostgreSQL (16 элемент) и MySQL (26 элемент).

И ещё одно улучшение появился контроль атрибутов файла.



Обновления в модуле SCM подробнее описаны в блоге Solarwinds.

Web Performance Monitor (WPM) 2020.2

В новой версии появилась интеграция с инструментом для записи транзакций Pingdom. Pingdom также часть Solarwinds. Подробнее об обновлениях WPM в блоге Solarwinds.

Database Performance Analyzer (DPA) 2020.2

Появилась поддержка глубокого анализа PostgreSQL. Анализ поддерживается для следующих типов БД:

• Стандартный PostgreSQL
• EDB Postgres Advanced Server (EPAS)
• Including the Oracle Syntax option
• Amazon RDS for PostgreSQL
• Amazon Aurora for PostgreSQL
• Azure DB for PostgreSQL

Появилась поддержка следующих типов сертификатов для взаимодействия с БД:

• PKCS#12 (*.pf2 or *.pfx)
• JKS (*.jks)
• JCEKS (*.jceks)
• DER (*.der or *.cer)
• PEM (*.pem, *.crt, *.ca-bundle)

Обновления модуля DPA подробнее описаны в блоге Solarwinds.

Enterprise Operations Console (EOC) 2020.2

В продукте улучшились типы представлений.









Подробнее об обновлениях модуля EOC в блоге Solarwinds.

---

Это все улучшения, о которых мы хотели рассказать. Если у вас есть вопросы, вы можете нам позвонить или задать их через форму обратной связи. А ещё не забудьте зарегистрироваться на предстоящий вебинар.

Другие наши статьи на Хабре о Solarwinds:

Бесплатные утилиты Solarwinds для мониторинга, управления ИТ-инфраструктурой и безопасностью

Настраиваем экспорт IPFIX на VMware vSphere Distributed Switch (VDS) и последующий мониторинг трафика в Solarwinds

Подписывайтесь на группу Галс Софтвэр в Фейсбуке.