Привет!
Все мы знаем и любим такие продукты для vulnerability assessment процессов как , , и всякие прочие .
Одной из основных задач, которые они решают, является обеспечение контроля версионных уязвимостей.
Это довольно простой процесс сравнения установленных версий программного обеспечения на попадание в диапазон "не содержит известных уязвимостей". Ну а дальше ребята, ответственные за информационную безопасность, совместно с разработкой и админами решают какие риски можно принять, а что нужно пропатчить прямо сегодня.
Существует масса разнообразных инструментов для решения этой задачи, но у всех них с нашей точки зрения есть одна общая проблема — они требуют отдельного хлопотного развертывания и порождают в вашей инфраструктуре еще один инструмент с root-овой учетной записью. Но ведь для такого простого действия как сбор информации об установленных пакетах root не нужен! Да и обычно в инфраструктуре уже присутствуют развернутые системы с возможностью консолидации данных, совместной работы и удаленного исполнения команд на серверах. Поэтому мы решили сделать инструмент, который позволил бы в пару кликов развернуть в своей среде систему контроля уязвимостей Linux с минимальными изменениями продакшена.
Что развернуто в большинстве продуктовых систем? Конечно же мониторинг. И довольно часто это . Так давайте к нему и прикрутимся!
В одной руке Zabbix
Все просто: распределенная система агентов, дашборды для визуализации, многопользовательская система доступа, выполнение действий по заданным критериям уже сделаны без нас. Нам не нужно изобретать велосипед и делать это все с нуля.
Прав у Zabbix-а хватает на получение информации о пакетах, куда их сложить тоже есть. Осталось их объединить и отправить на анализ в . А затем обработать полученные знания об уязвимостях.
Но давайте начнем с небольшого вступления, что умеет Zabbix и что нам потребуется сделать.
Zabbix-агенты устанавливаются на сервера и позволяют:
Анализируя полученные данные и основываясь на достаточно гибкой логике он может выполнять различные действия:
Также через веб-интерфейс осуществляется администрирование Zabbix.
Zabbix API является API на основе веб и поставляется как часть веб-интерфейса. Он использует протокол JSON-RPC.
В другой руке Vulners
Zabbix Threat Control
Это к Zabbix, с открытым исходным кодом, написан на Python, который:
Использование данной методики позволяет привести уязвимости найденные в различных системах и обладающие разными свойствами к единому знаменателю, что упрощает приоритезацию обнаруженных проблем.
Про этот плагин мы рассказыали на . Для тех, кто не любит читать, но любит смотреть — есть доклада.
Консолидируйте информацию об уязвимостях
Результат работы плагина в Zabbix выглядит следующим образом:
Это дашборд в Zabbix. На котором, слева на право, отображается следующая информация:
Информация об уязвимых серверах:
Панель отображает список всех серверов с уровнем уязвимости выше критического. Минимально допустимый уровень критичности, после которого сервер начинает отображаться как уязвимый, задается в настройках плагина.
По каждому серверу доступна следующая информация:
Следующая панель показывает уязвимые пакеты:
Здесь для каждого уязвимого пакета в нашей инфраструктуре мы имеем краткую сводку:
Индекс влияния — это количество затронутых уязвимым пакетом серверов, умноженное на CVSS-балл уязвимости. Зачастую бывает что уязвимость с не самым выскоким балом имеет гораздо большее распространение в инфраструктуре, и поэтому потенциально более опасна.
Выбирайте стратегии устранения уязвимостей
Однако нельзя просто так взять и обновить все пакеты на всех серверах до последней версии, которая устраняет существующие уязвимости.
В любой инфраструктуре, состоящей более чем из нескольких серверов существует множество ограничений: зависимость одного софта от версии другого, риски нарушения функциональности и так далее.
Поэтому всегда стоит выбор — какие пакеты мы можем безболезненно обновить. По каким пакетам необходим отдельный план работ по реализации компенсирующих мер. А по каким мы можем принять риски.
Предлагаемый в плагине подход позволяет выбирать подходящую вам стратегию устранения уязвимостей:
Но мало знать какие у нас уязвимости и определить как и какие из них можно устранить. Необходимо ещё и сделать это!
Для централизованного управления конфигурациями и обновления ПО широко используются такие системы как Puppet или Ansible. Вы можете использовать fix-команду, устраняющую уязвимость, и централизованно её выполнить с помощью таких систем.
Если же в вашей инфраструктуре не используются такие системы — позволяет устранять уязвимости прямо из веб-интерфейса Zabbix.
Для этого плагин использует стандартный функционал Zabbix: подтверждение событий и выполнение удаленных команд:
И как результат работы — отсутствие уязвимых серверов, ваш спокойный сон и отличное настроение
Установка
Мы рассказали, что такое , зачем он нужен и как работает. Теперь расскажем как его установить и настроить!
Зависимости
Для работы плагин не требует ничего сверхестественого. Необходимо чтобы на Zabbix-сервере, на который мы ставим планиг, было следующее:
Для начала подключаем репозиторий с пакетами:
RPM-дистрибутивы
RPM-дистрибутивы
RPM-дистрибутивы
Если вы предпочитаете установку из исходиников, то сделать это тоже очень просто:
На Zabbix-сервере устанавливаем основные скрипты, обеспечивающие всю логику работы плагина и скрипт, формирующий отчетность об ОС:
После установки необходимо сконфигурировать плагин и подготовить систему мониторинга для его работы. Далее пошаговое описание всех необходимых действий.
Настраиваем сервера, требующие сканирования
Необходимо разрешить Zabbix агенту выполнять удаленные команды. Для этого на всех серверах, для ктороых требуется сканирование, измените параметры в файле конфигурации zabbix-agent как показано ниже:
Если вы хотите использовать функционал по устранению найденных уязвимостей с помощью Zabbix Threat Control, вам необходимо разрешить пользователю zabbix выполнять обновление пакетов (но не их установку или удаление).
Для этого необходимо добавить следующую строку в файл /etc/sudoers:
Для RPM-дистрибутивов строка выглядит так:
Для использования Vulners API вам нужен api-ключ. Чтобы получить его:
Теперь вам нужно добавить api-ключ Vulners в конфигурационный файл плагина /opt/monitoring/zabbix-threat-control/ztc_config.py
Пример:
Чтобы плагин смог подключиться к Zabbix, вам нужно указать следующие данные в файле конфигурации: /opt/monitoring/zabbix-threat-control/ztc_config.py
Пример:
Необходимо создать в Zabbix объекты, обеспечивающие работу плагина. Для этого нужно запустить скрипт /opt/monitoring/zabbix-threat-control/ztc_create.py. Скрипт проверит что плагин сконфигурирован верно и, используя API создаст в Zabbix:
После создания в Zabbix всех объектов скрипт покажет:
После этого остается дождаться запуска плагина в указанное при инсталляции время.
Сканируем!
Запуск основного скрипта обработки данных (ztc.py) происходит автоматически, один раз в сутки, через "Service Item..." на хосте "Vulners — Statistics" в указанное скриптом время.
Вы можете поменять время запуска плагина на любое удобное вам, изменив "Scheduling interval" в этом элементе данных. При этом необходимо откорректировать и время сбора статистики в трех элементах данных шаблона "Vulners OS-Report" – метрики в шаблоне должны срабатывать минут на 10…15 раньше, чем основная метрика "Service Item..." на хосте "Vulners — Statistics".
Время за которое будут обработаны все данные об уязвимостях зависит от количества серверов в инфраструктуре и количества установленных на них пакетов. Ориентировочно на обработку 1 тысячи серверов тратится около 30 минут.
Планы
Это лишь первая версия плагина Zabbix Threat Control. И мы продолжаем его разработку.
В планах:
Все мы знаем и любим такие продукты для vulnerability assessment процессов как , , и всякие прочие .
Одной из основных задач, которые они решают, является обеспечение контроля версионных уязвимостей.
Это довольно простой процесс сравнения установленных версий программного обеспечения на попадание в диапазон "не содержит известных уязвимостей". Ну а дальше ребята, ответственные за информационную безопасность, совместно с разработкой и админами решают какие риски можно принять, а что нужно пропатчить прямо сегодня.
Существует масса разнообразных инструментов для решения этой задачи, но у всех них с нашей точки зрения есть одна общая проблема — они требуют отдельного хлопотного развертывания и порождают в вашей инфраструктуре еще один инструмент с root-овой учетной записью. Но ведь для такого простого действия как сбор информации об установленных пакетах root не нужен! Да и обычно в инфраструктуре уже присутствуют развернутые системы с возможностью консолидации данных, совместной работы и удаленного исполнения команд на серверах. Поэтому мы решили сделать инструмент, который позволил бы в пару кликов развернуть в своей среде систему контроля уязвимостей Linux с минимальными изменениями продакшена.
Что развернуто в большинстве продуктовых систем? Конечно же мониторинг. И довольно часто это . Так давайте к нему и прикрутимся!
В одной руке Zabbix
Все просто: распределенная система агентов, дашборды для визуализации, многопользовательская система доступа, выполнение действий по заданным критериям уже сделаны без нас. Нам не нужно изобретать велосипед и делать это все с нуля.
Прав у Zabbix-а хватает на получение информации о пакетах, куда их сложить тоже есть. Осталось их объединить и отправить на анализ в . А затем обработать полученные знания об уязвимостях.
Но давайте начнем с небольшого вступления, что умеет Zabbix и что нам потребуется сделать.
Zabbix-агенты устанавливаются на сервера и позволяют:
- получать широкий диапазон метрик операционной системы;
- запускать скрипты и программы и получать результат их выполнения;
- выполнять любые команды в отдельном процессе (fork), не зависимом от процессов Zabbix-агента;
- работать сразу с несколькими Zabbix-серверами;
- работать за файерволлом, инициируя соединение к серверу или же наоборот, ожидая входящих подключений.
Анализируя полученные данные и основываясь на достаточно гибкой логике он может выполнять различные действия:
- Отправлять оповещения по различным каналам (почта, смс, мессенджеры и т.д.);
- Подключаться к серверам по SSH или IPMI и выполнять на них различные команды;
- Или же выполнять различные корректирующие команды на серверах используя подключения к ним Zabbix-агент;
Также через веб-интерфейс осуществляется администрирование Zabbix.
Zabbix API является API на основе веб и поставляется как часть веб-интерфейса. Он использует протокол JSON-RPC.
- Позволяет получать, создавать, конфигурировать и удалять любые объекты в системе мониторинга.
- Используя API можно с легкостью интегрировать систему мониторинга с различными внешними системами.
В другой руке Vulners
- Агрегатор данных об уязвимостях из более чем 115 источников
- Выдает данные в нормализованном, машино-читаемом виде
- Работает очень быстро
- Позволяет коррелировать данные из различных источников
Zabbix Threat Control
Это к Zabbix, с открытым исходным кодом, написан на Python, который:
- Отображает в веб-интерфейсе Zabbix информацию об уязвимостях, найденных в вашей инфраструктуре.
- Показывает уровень угрозы каждой уязвимости по стандарту CVSS.
- И предлагает легко применимые способы устранения найденных уязвимостей.
Использование данной методики позволяет привести уязвимости найденные в различных системах и обладающие разными свойствами к единому знаменателю, что упрощает приоритезацию обнаруженных проблем.
Про этот плагин мы рассказыали на . Для тех, кто не любит читать, но любит смотреть — есть доклада.
Консолидируйте информацию об уязвимостях
Результат работы плагина в Zabbix выглядит следующим образом:
Это дашборд в Zabbix. На котором, слева на право, отображается следующая информация:
- Распределение CVSS-балла по серверам. Круговая диаграмма показывает соотношение — как много у нас серверов с критическими уязвимостями, сколько имеют не критичные уязвимости или же вовсе не имеют известных уязвимостей.
- Медианное значение CVSS-балла всей инфраструктуры. Отображается в виде графика, что позволяет наблюдать динамику его изменения.
- Список уязвимых пакетов с индексом влияния уязвимости на инфраструктуру.
- Полный список уязвимых серверов с уровнем угрозы для каждого из них.
- Список бюллетеней безопасности, которые были «найдены» в инфраструктуре.
Информация об уязвимых серверах:
Панель отображает список всех серверов с уровнем уязвимости выше критического. Минимально допустимый уровень критичности, после которого сервер начинает отображаться как уязвимый, задается в настройках плагина.
По каждому серверу доступна следующая информация:
- Собственно имя уязвимого сервера.
- Максимальный CVSS-балл сервера. Отображается самый высокий балл из всех найденных уязвимостей для этого сервера.
- Команда для устранения всех обнаруженных уязвимостей на этом сервере. Выполнив которую мы получим сервер, на котором отсутствуют известные вёрстанные уязвимости.
Следующая панель показывает уязвимые пакеты:
Здесь для каждого уязвимого пакета в нашей инфраструктуре мы имеем краткую сводку:
- Имя уязвимого пакета.
- Уязвимая версия пакета.
- Количество серверов, на которых установлена уязвимая версия пакета.
- CVSS-балл данной версии пакета.
- Индекс влияния этой уязвимости на инфраструктуру.
- Список всех серверов, на которых обнаружена уязвимая версия пакета.
- Ссылка на бюллетень безопасности. Позволяет прочитать и понять насколько эта уязвимость критична именно в нашей ситуации.
- Команда исправляющая уязвимость в данном пакете.
Индекс влияния — это количество затронутых уязвимым пакетом серверов, умноженное на CVSS-балл уязвимости. Зачастую бывает что уязвимость с не самым выскоким балом имеет гораздо большее распространение в инфраструктуре, и поэтому потенциально более опасна.
Выбирайте стратегии устранения уязвимостей
Однако нельзя просто так взять и обновить все пакеты на всех серверах до последней версии, которая устраняет существующие уязвимости.
В любой инфраструктуре, состоящей более чем из нескольких серверов существует множество ограничений: зависимость одного софта от версии другого, риски нарушения функциональности и так далее.
Поэтому всегда стоит выбор — какие пакеты мы можем безболезненно обновить. По каким пакетам необходим отдельный план работ по реализации компенсирующих мер. А по каким мы можем принять риски.
Предлагаемый в плагине подход позволяет выбирать подходящую вам стратегию устранения уязвимостей:
- Одна уязвимость во всей инфраструктуре: если для вас критична какая то определенная уязвимость — плагин предоставляет вам информацию где в вашей инфраструктуре эта уязвимость существует, и каким образом ее можно исправить сразу во всей инфраструктуре.
- Все уязвимости на определенном сервере: если вам необходимо иметь целиком безопасный сервер, к примеру находящийся в DMZ или за периметром компании — используя плагин вы получаете информацию о том как устранить все найденные на нем уязвимости.
Но мало знать какие у нас уязвимости и определить как и какие из них можно устранить. Необходимо ещё и сделать это!
Для централизованного управления конфигурациями и обновления ПО широко используются такие системы как Puppet или Ansible. Вы можете использовать fix-команду, устраняющую уязвимость, и централизованно её выполнить с помощью таких систем.
Если же в вашей инфраструктуре не используются такие системы — позволяет устранять уязвимости прямо из веб-интерфейса Zabbix.
Для этого плагин использует стандартный функционал Zabbix: подтверждение событий и выполнение удаленных команд:
- Как только проблема будет подтверждена через веб-интерфейс авторизованным на это пользователем;
- Запустится удаленная команда, которая выполнит на целевом сервере, или списке серверов, fix-команду исправляющую уязвимость.
- Zabbix-сервер получает через zabbix-агенты информацию о пакетах и об операционной системе всех серверов в инфраструктуре.
- Плагин (с помощью Zabbix API) получает ранее собранный Zabbix-сервером отчет об ОС. Непосредственно с серверов плагин ничего не получает. И на данном этапе не треует с ними прямого контакта.
- Обработав полученную от Zabbix информацию плагин передает её в Vulners. От которого в ответ получает список найденных уязвимостей, их критичность и способ устранения.
- Плагин обрабатывает полученные данные, агрегирует их для формирования статистики и формирует пакеты данных для передачи в Zabbix.
- Плагин пушит в Zabbix данные в необходимом системе мониторинга формате. Делает он это с помощью утилиты zabbix-sender. После этого вы уже имеете в мониторинге все о найденных уязвимостях, которые отображаются на показанном ранее дашборде.
- После подтверждения проблемы выполняется удаленная команда, которая передает плагину:
- Имя того, кто её инициировал
- Fix-команду исправления уязвимости
- Cписок серверов
- Получив все это Zabbix Threat Control:
- Проверяет что команда на исправление инициирована тем, кем нужно. От того, кого не нужно — он команду не принимает
- Выполняет переданную ему команду на нужном количестве серверов.
И как результат работы — отсутствие уязвимых серверов, ваш спокойный сон и отличное настроение
Установка
Мы рассказали, что такое , зачем он нужен и как работает. Теперь расскажем как его установить и настроить!
Зависимости
Для работы плагин не требует ничего сверхестественого. Необходимо чтобы на Zabbix-сервере, на который мы ставим планиг, было следующее:
- zabbix v3.4 для использования кастомных дашбордов (они появились только в этой версии).
- zabbix-sender нужен для отправки в данных об уязвимостях в систему мониторинга.
- zabbix-get для отправки fix-команд, исправляющих уязвимости, на сервера.
- python v3 с модулями: pyzabbix, jpath, requests для запуска основных скриптов плагина.
- zabbix-agent для сбора данных и запуска скриптов.
- python v2 для запуска скрипта собирающего отчет об ОС.
Для начала подключаем репозиторий с пакетами:
RPM-дистрибутивы
DEB-дистрибутивыrpm -Uhv
После этого на Zabbix-сервере устанавливаем основной пакет, обеспечивающий всю логику работы плагина и пакет, формирующий отчетность об ОС:wget
dpkg -i vulners-repo.deb
RPM-дистрибутивы
DEB-дистрибутивыyum install zabbix-threat-control-main zabbix-threat-control-host
И на всех остальных серверах, для которых требуется сканирование на уязвимости, устанавливаем пакет, формирующий отчетность об ОС:apt-get update && apt-get install zabbix-threat-control-main zabbix-threat-control-host
RPM-дистрибутивы
DEB-дистрибутивыyum install zabbix-threat-control-host
Установка из исходниковapt-get update && apt-get install zabbix-threat-control-host
Если вы предпочитаете установку из исходиников, то сделать это тоже очень просто:
На Zabbix-сервере устанавливаем основные скрипты, обеспечивающие всю логику работы плагина и скрипт, формирующий отчетность об ОС:
На всех остальных серверах, для которых требуется сканирование на уязвимости ставим только скрипт, формирующий отчетность об ОС:git clone
# main
mkdir -p /opt/monitoring/zabbix-threat-control
cp zabbix-threat-control/ztc* /opt/monitoring/zabbix-threat-control/
chown -R zabbix:zabbix /opt/monitoring/zabbix-threat-control
chmod 640 /opt/monitoring/zabbix-threat-control/ztc_config.py
touch /var/log/zabbix-threat-control.log
chown zabbix:zabbix /var/log/zabbix-threat-control.log
chmod 664 /var/log/zabbix-threat-control.log
# host
cp -R zabbix-threat-control/os-report /opt/monitoring/
chown -R zabbix:zabbix /opt/monitoring/os-report
Настройкаgit clone
# host
mkdir -p /opt/monitoring/
cp -R zabbix-threat-control/os-report /opt/monitoring/
chown -R zabbix:zabbix /opt/monitoring/os-report
После установки необходимо сконфигурировать плагин и подготовить систему мониторинга для его работы. Далее пошаговое описание всех необходимых действий.
Настраиваем сервера, требующие сканирования
Необходимо разрешить Zabbix агенту выполнять удаленные команды. Для этого на всех серверах, для ктороых требуется сканирование, измените параметры в файле конфигурации zabbix-agent как показано ниже:
Файл конфигурации zabbix-агента обычно расположен здесь: /etc/zabbix/zabbix_agentd.confEnableRemoteCommands=1
LogRemoteCommands=1
Если вы хотите использовать функционал по устранению найденных уязвимостей с помощью Zabbix Threat Control, вам необходимо разрешить пользователю zabbix выполнять обновление пакетов (но не их установку или удаление).
Для этого необходимо добавить следующую строку в файл /etc/sudoers:
Для RPM-дистрибутивов строка выглядит так:
Для DEB-дистрибутивов немного по-другому:zabbix ALL=(ALL) NOPASSWD: /usr/bin/yum -y update *
Подключаемся к Vulnerszabbix ALL=(ALL) NOPASSWD: /usr/bin/apt-get --assume-yes install --only-upgrade *
Для использования Vulners API вам нужен api-ключ. Чтобы получить его:
- Зарегистрируйтесь на
- В личном кабинете перейдите на вкладку API KEYS
- Выберите "Scan" в области Scope и нажмите «GENERATE NEW KEY».
Теперь вам нужно добавить api-ключ Vulners в конфигурационный файл плагина /opt/monitoring/zabbix-threat-control/ztc_config.py
Пример:
Подключаемся к Zabbixvuln_api_key = 'RGB9YPJG7CFAXP35PMDVYFFJPGZ9ZIRO1VGO9K9269B0K86K6XQQQR32O6007NUK'
Чтобы плагин смог подключиться к Zabbix, вам нужно указать следующие данные в файле конфигурации: /opt/monitoring/zabbix-threat-control/ztc_config.py
- адрес веб-интерфейса Zabbix для работы с Zabbix-API;
- имя и пароль пользователя, под которым будем подключаться к Zabbix API.
Пример:
Подготавливаем Zabbixzbx_pass = 'yourpassword'
zbx_user = 'yourlogin'
zbx_url = ''
zbx_server_fqdn = 'zabbixserver.yourdomain.com'
zbx_server_port = '10051'
Необходимо создать в Zabbix объекты, обеспечивающие работу плагина. Для этого нужно запустить скрипт /opt/monitoring/zabbix-threat-control/ztc_create.py. Скрипт проверит что плагин сконфигурирован верно и, используя API создаст в Zabbix:
- Хост-группу, в которую добавятся хосты, отображающие уязвимости.
- Шаблон, с помощью которого собирается отчет об ОС со всех серверов.
- Хосты для отображения уязвимостей по пакетам, серверам, бюллетеням и общей статистики.
- Экшен для выполнения удаленных команд по исправлению уязвимостей.
- Дашборд для удобного отображения все этой информации.
После создания в Zabbix всех объектов скрипт покажет:
- Ссылку на созданный дашборд в Zabbix, на котором будут отображаться уязвимости.
- Время, когда будет запускаться сканирование инфраструктуры на уязвимости.
После этого остается дождаться запуска плагина в указанное при инсталляции время.
Сканируем!
Запуск основного скрипта обработки данных (ztc.py) происходит автоматически, один раз в сутки, через "Service Item..." на хосте "Vulners — Statistics" в указанное скриптом время.
Вы можете поменять время запуска плагина на любое удобное вам, изменив "Scheduling interval" в этом элементе данных. При этом необходимо откорректировать и время сбора статистики в трех элементах данных шаблона "Vulners OS-Report" – метрики в шаблоне должны срабатывать минут на 10…15 раньше, чем основная метрика "Service Item..." на хосте "Vulners — Statistics".
Время за которое будут обработаны все данные об уязвимостях зависит от количества серверов в инфраструктуре и количества установленных на них пакетов. Ориентировочно на обработку 1 тысячи серверов тратится около 30 минут.
Планы
Это лишь первая версия плагина Zabbix Threat Control. И мы продолжаем его разработку.
В планах:
- Добавить на дашборд информацию по найденным в инфраструктуре CVE.
- Отказаться установки каких либо скриптов на агенты и собирать всю необходимую информацию об ОС и пакетах с помошью встроенных в Zabbix-агент ключей элементов данных.
isox