Всем привет! Мы (Олег Герцев и Лиля Кондратьева) работаем в сервисном центре Positive Technologies и отвечаем за поддержку MaxPatrol SIEM и MaxPatrol VM соответственно.
Мы не только обрабатываем более десяти тысяч заявок в год, но и активно развиваем экспертизу клиентов и партнеров: среди наших сотрудников есть активные участники комьюнити-чата в Телеграме, в прошлом году мы выступали с лекциями на ДОД, а также готовили материалы для разработки курса по траблшутингу.
Ранее коллеги, работающие с PT Sandbox и PT NAD, рассказывали, с решением каких вопросов сталкиваются инженеры. Мы решили не останавливаться и в этой статье хотим приоткрыть завесу тайны над буднями специалистов поддержки уже других продуктов, приведя несколько историй на основе реальных событий. Кстати, пока мы готовили этот текст, так вдохновились, что придумали несколько тематических ребусов, к которым перейдем в самом конце. Пока же – ныряем в будни техподдержки!
С чего начинается анализ
MaxPatrol SIEM и MaxPatrol VM входят в состав многофункциональной платформы MaxPatrol 10 и имеют микросервисную архитектуру, поэтому при анализе клиентских ситуаций, помимо внешнего описания симптомов, необходимо вооружиться рядом данных: журналами и конфигурационными файлами.
Для этого мы разработали утилиту сбора диагностических данных — MaxPatrol 10 Diagnostic Utility (MP10DU). Она собирает:
журналируемые файлы системы;
конфигурационные файлы;
аппаратные метрики (например, размеры баз, ОЗУ, запущенные процессы).
На выходе мы получаем архив, где в тематически отсортированных каталогах видим нужную для анализа информацию. Это избавляет наших клиентов от необходимости вчитываться в длинные строки с указанием нужных папок и искать данные — скрипт все делает сам. Имея этот архив можно и погрузиться в анализ.
MaxPatrol SIEM позволяет собирать события со всех источников в ИТ-инфраструктуре компании, преобразовывать их в человекочитаемый вид, используя правила нормализации, а также фиксировать инциденты и подозрительную активность благодаря правилам корреляции.
Для дальнейшего понимания объясним несколько терминов:
MaxPatrol SIEM Server — основной компонент, проводящий нормализацию, корреляцию, обогащение событий, создающий инциденты.
MaxPatrol SIEM Events Storage — хранит события в базе Elasticsearch или LogSpace (собственная разработка Positive Technologies).
Данные об узлах и событиях собирает модуль Collector (ранее известный как MaxPatrol 10 Agent), и событие отправляется через шину данных RabbitMQ на MaxPatrol SIEM Server, где обрабатывается с целью нормализации, корреляции и обогащения и помещается в MaxPatrol SIEM Events Storage. После этого мы увидим событие в готовом виде уже в веб-интерфейсе компонента Core.
Недоступность хранилища Elasticsearch
Разберем интересный случай. К нам обратился клиент с проблемой: периодически недоступен компонент MaxPatrol SIEM Events Storage. Описываемые симптомы: соответствующее уведомление в Health Monitor и остановка служб базы данных событий Elasticsearch.
Так как возникла проблема со службой ES, мы начинаем с анализа журнала ES и видим неудачную попытку обратиться к шардам.
Загуглив эту ошибку, можно узнать, что наиболее вероятной причиной такого поведения является недостаток оперативной памяти (напишите в комментариях, если вам это удалось).
Чтобы окончательно убедиться в этом или опровергнуть предположение, возвращаемся в журналы Elasticsearch и смотрим, как настроен параметр HeapSize:
Видим, что на ноду выделено 30 ГБ, которые сервис резервирует под постоянное пользование.
Теперь проверяем количество свободной памяти.
На сервере доступно 14 ГБ, а для запуска сервиса необходимо 30 ГБ. Всего на сервере есть 64 ГБ. Суммарный объем оперативной памяти всех узлов кластера, умноженный на коэффициент 1,7, не должен превышать объем оперативной памяти сервера для хранения событий. В нашем случае памяти оставалось крайне мало (порядка 14 ГБ), а согласно формуле расчета суммарного объема необходимо порядка 50 ГБ ОЗУ.
Вывод: из-за неверно настроенного параметра HeapSize объема памяти ОЗУ было недостаточно для работы всех служб, что и приводило к незапланированной остановке службы Elasticsearch.
Как этого можно избежать? В инсталляторе предусмотрена проверка параметров в режиме Basic, но нам удалось обойти эту проверку, перейдя в параметры Advanced (что и привело к ситуации, описанной выше, — не рекомендуем повторять этот трюк в домашних условиях).
Для исправления положения дел рекомендуем компании привести параметры конфигурационного файла в соответствие с приведенными выше рекомендациями по настройке суммарного объема используемой оперативной памяти.
Этот кейс является классическим с точки зрения подхода к анализу, но это не единственное, с чем можно столкнуться при эксплуатации SIEM-системы. Как и в любой подобной системе, случаются подозрения на ложные срабатывания правил, ложные корреляции инцидентов, или же события от источника отображаются не так, как хотелось бы.
С этим мы тоже умеем справляться, но рассказ получится слишком объемным для одной ознакомительной статьи. С удовольствием почитаем в комментариях, о каких случаях хотелось бы узнать подробнее :)
Подозрения на ложные срабатывания MaxPatrol VM
MaxPatrol VM умеет определять ПО и уязвимости в системах, в том числе трендовые — опасные уязвимости, которые активно используются в атаках или с высокой вероятностью будут использоваться в ближайшее время. Любая система, как известно, надежна настолько, насколько надежно ее самое слабое звено, поэтому важно держать активы в актуальном состоянии: регулярно выполнять сканирования, а также проводить патчинг найденных уязвимостей (например, устанавливать последние обновления систем безопасности и актуальные версии ПО).
Любое СЗИ может дать ложные обнаружения. Их можно разделить на два типа:
False positive — уязвимость определилась, хотя известно, что ее нет. Например, отсутствует ПО, которое такой уязвимости подвержено.
False negative — уязвимости нет в отчете, хотя мы точно знаем, что в системе есть уязвимое ПО.
В случае ниже было проведено сканирование в режиме Audit — поиск уязвимостей ПО под учетной записью с минимально необходимыми привилегиями.
Неверное определение версии
Наблюдаем подозрение на false-positive-срабатывание: в карточке актива отображается уязвимая версия ПО PostgreSQL, которая предположительно неверно определена сканером.
В подтверждение этому видим пакеты.
Проверим, какая версия установлена на сервере на самом деле.
Результат запроса apt list показал, что установлена другая версия PostgreSQL — 12.17. Придется погрузиться глубже — в снапшот актива. Специальным запросом в консоли мы можем выгрузить информацию об активе, которая будет представлена уже не в виде карточки, а единым XML-файлом, содержащим все, что удалось выяснить при сканировании.
Поиск по postgresql показал, что на активе расположены два экземпляра БД разных версий, что может произойти, если до этого уже устанавливался экземпляр, но по другому пути — PostgreSQL не требует дефолтного каталога установки.
Так мы подтвердили, что на узле есть два экземпляра PostgreSQL, один из которых действительно уязвим. Он оказался неиспользуемым, и его благополучно удалили.
Призрачный пакет Ubuntu
MaxPatrol VM показывает уязвимость пакета mc (GNU Midnight Commander), который уже удален в системе. В интерфейсе нашего продукта это выглядит так.
Как видно, у уязвимости есть глобальный идентификатор — CVE-2021-36370. Этот идентификатор уникален, и каждый желающий может ознакомиться с подробной информацией об этой уязвимости. Гуглим и выясняем, что уязвимы версии с 4.8.26 и ниже.
Определенный механизмами MaxPatrol VM пакет (версии 4.8.24) попадает в список уязвимых версий. Нужно проверить, на самом ли деле этот пакет удален из системы. Ищем mc-пакеты с помощью команды:
apt list --installed | grep mc
Выходит, MaxPatrol VM действительно обнаружил пакет, которого в системе нет. Но сдаваться мы не привыкли, поэтому допускаем: а что, если mc был установлен не через apt-get, а другим способом? Например, через deb-пакет?
Пишем: dpkg -l | grep mc
Теперь мы видим искомый mc-пакет уязвимой версии. Возможно, его удаляли, но остался невычищенный конфигурационный файл.
После удаления конфигурационного файла остается только задуматься: действительно ли уязвимость можно считать актуальной, если исполняемых файлов нет в системе?
Уязвимости можно условно разделить на версионные (чтобы их исправить, надо обновиться) и конфигурационные (надо перенастроить источник, изменив какой-нибудь параметр).
Этот случай не был признан ложноположительным срабатыванием, потому что для эксплуатации уязвимости бывает достаточно и конфигурационного файла. Чтобы спать спокойно, лучше удалять ПО корректно — не оставляя хвостов.
Поскольку в этом случае не подтвердилось, что остатки mc повышают вероятность атаки, механизм обнаружения такой уязвимости MaxPatrol VM был доработан.
Подводя итоги
Описанные выше случаи — лишь верхушка айсберга в работе команды техподдержки. Мы надеемся, что вам не только было интересно заглянуть за кулисы сервисного центра, но и стало чуть более понятно, сколько действий таится за простым обращением в поддержку, пока мы анализируем ваши журналы.
Кто работает с вашими заявками? Инженер сервисного центра — это человек-оркестр, который обладает многими талантами, разбирается в разных технологиях и непрерывно гуглит развивает навыки, чтобы непредвзято судить о поведении различных систем, например ОС, БД, файловых систем, сетевых приложений.
Зачастую описанный клиентом симптом не раскрывает полной картины происходящего, и, анализируя большой объем запрошенных данных, мы можем даже обнаружить нечто, на что запросов не поступало, но что уже можно превентивно оптимизировать исходя из клиентских потребностей. Таким образом, чем больше данных, тем быстрее удается исследовать систему комплексно и оценить ситуацию со всех сторон.
Обязательно обращайтесь к нам в поддержку, если у вас возникают вопросы по работе MaxPatrol SIEM и MaxPatrol VM, — мы всегда на связи и рады помочь!
Лилия Кондратьева
Руководитель группы поддержки систем управления уязвимостями
Олег Герцев
Руководитель группы поддержки систем мониторинга событий безопасности
И еще немного пищи для ума 😉
На картинках ниже зашифрованы пять терминов из сферы ИБ, с которыми сталкиваются как инженеры поддержки, так и все, кто интересуется информационной безопасностью. Пригодится знание английского, кино, школьной программы по химии и музыки. Приз тому, кто первым разгадает все пять ребусов. Ждем ваших ответов в комментариях!
