Как сканировать любую инфраструктуру на уязвимости — без агентов, бесплатно, через Jump Host и без боли? Мы в K2 Облаке искали именно такое решение — и не нашли. Зато взяли Open Source-инструмент Vuls и сделали из него полноценный автоматизированный сервис с GitLab-интеграцией, красивыми PDF-отчётами и работой с облачным API. В статье рассказываем, как превратили «сырое» решение в удобный инструмент с CI-пайплайнами, алертами и конфигами, которые генерируются за секунды.

Привет, Хабр! На связи Роман Масягутов и Анастасия Козлова из команды K2 Облака. В этой статье — краткий разбор нашей практики по автоматизации сканирования инфраструктур: как организовали удалённое сканирование без агентов, с одного хоста, без вмешательства в работу приложений и без дополнительных затрат. 

Что повлияло на выбор решения

У инфраструктуры, которую мы сканируем могут быть ограничения:

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

Ограниченный доступ через Jump Host. В большинстве случаев внешние подключения к серверам закрыты. Получить доступ можно только через единую точку входа — Jump Host. Это сервер, к которому у нас есть доступ по SSH, а от него — уже к остальной внутренней инфраструктуре. Такой подход диктует требования к инструментам: они должны уметь работать через промежуточный хост, без установки дополнительных компонентов на целевые машины.

Ограничения по ресурсам. Часто заказчики используют машины с ограниченными ресурсами — например, 1 vCPU и 1–2 ГБ RAM. Это значит, что любые ресурсоёмкие действия (например, полное локальное сканирование) могут привести к деградации производительности или сбоям. Поэтому важно, чтобы сканирование было максимально «бережным».

Эти ограничения напрямую повлияли на выбор архитектуры сканирования: agentless, через Jump Host, с одного внешнего хоста. Далее расскажем, как мы реализовали это решение на практике — с помощью Open Source-инструмента Vuls и собственной надстройки для автоматизации.

Описание решения

Мы проанализировали несколько вариантов инструментов и в итоге выбрали open-source решение Vuls. 

Vuls — набор инструментов, позволяющий собирать и обновлять базы данных уязвимостей, проводить сканирование с использованием сохраненных баз данных и составлять отчеты по итогам сканирования.

Решение подошло нам по ключевым требованиям: Vuls позволяет выполнять сканирование без установки агентов, подключаясь к инфраструктуре по SSH. Это особенно важно, поскольку в большинстве случаев доступ к внутренним серверам ограничен и осуществляется только через один промежуточный хост (Jump Host).

Многие популярные решения не поддерживают такой сценарий, а нам было важно обеспечить доступ к инфраструктуре, закрытой за одним внешним IP-адресом. Вторая причина — безагентская архитектура: Vuls не требует установки дополнительного ПО на целевых серверах. Он подключается по SSH, собирает информацию об установленных пакетах, сравнивает её с базами уязвимостей и формирует список рекомендаций по обновлению. Подключившись к нему, мы получаем возможность обращаться по SSH ко всем остальным серверам инфраструктуры.

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

Чтобы автоматизированно выполнять сканирование инфраструктур мы сделали автоматизацию на базе Gitlab CI\CD.

Архитектура vuls и связанных компонентов

В базовой версии решение не обеспечивало необходимого уровня автоматизации и ряда функций, необходимых нашей инфраструктуре. Поэтому мы доработали его, добавив собственные компоненты для генерации конфигураций, формирования отчётов и интеграции с CI/CD.

Для решения задач автоматизации мы реализовали несколько собственных компонентов, дополняющих базовый функционал Vuls.

Генерация конфигураций

В оригинальной версии Vuls отсутствует возможность шаблонизации или динамического создания конфигурационных файлов — они формируются вручную, что неудобно и трудозатратно при работе с большим числом хостов. Чтобы упростить процесс, мы разработали собственный компонент vulsconfig, который автоматически формирует конфигурационные файлы. Он получает данные об инстансах — их имена, IP-адреса и другие параметры — через API нашего облака и на основе этих данных генерирует конфигурационный файл в нужном формате.

Формирование отчётов

По результатам сканирования Vuls сохраняет данные в формате JSON. Для предоставления этих данных в удобной и читаемой форме мы разработали компонент vulsreport. Он преобразует JSON-вывод в PDF-отчёты по заданному шаблону. Это позволяет систематизировать информацию, включать в отчёты нужные поля (например, список CVE, имена хостов, оценки критичности) и использовать их в работе с клиентами.

Хранение результатов и нотификации

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

Автоматизация процесса сканирования

Наряду с генерацией конфигов и отчётов мы автоматизировали весь процесс сканирования. Вся логика — от получения списка инстансов до формирования и рассылки отчётов — реализована в рамках CI/CD-процессов, что исключает необходимость ручного запуска и позволяет выполнять сканирование по расписанию. Это значительно ускоряет цикл обнаружения и устранения уязвимостей и минимизирует ручной труд.

Автоматизация реализована с использованием механизма GitLab CI и планировщика задач (Schedule). Для этого выделена отдельная группа проектов vuls, содержащая все необходимые компоненты:

• vuls — форк оригинального Vuls с внесёнными изменениями, адаптированными под используемую инфраструктуру.

• vulsconfig — модуль для автоматической генерации конфигурационных файлов на основе данных из облачного API.

• vulsreports — компонент генерации PDF-отчётов на основе JSON-результатов работы Vuls.

• scan-base — основной шаблон пайплайна, включающий последовательность всех этапов сканирования.

• scan-<name> — индивидуальные проекты, настраиваемые для каждого контура.

Ключевым элементом автоматизации выступает проект scan-base. В нём реализованы следующие этапы пайплайна:

1. Генерация конфигурационных файлов (vulsconfig).

2. Проверка подключения ко всем узлам.

3. Запуск сканирования уязвимостей через Vuls.

4. Формирование отчётов в JSON и PDF-формате (vulsreports).

5. Архивация и отправка результатов.

Этот пайплайн запускается не напрямую, а только из проектов scan-<name> — один проект, который наследует scan-base. Такая структура позволяет передавать уникальные переменные окружения, например, адреса виртуальных машин, пути до ключей, ограничения по сканируемым зонам. А ещё благодаря этому легко адаптировать конфигурацию под особенности клиента, исключая, например, определённые хосты из сканирования или изменяя параметры SSH-доступа.

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

Структура пайплайна

Каждый запуск пайплайна включает следующие этапы:

1. Проверка подключения ко всем нодам — тестируется доступность хостов, которые должны быть проверены, посредством SSH.

2. Выполнение сканирования — запуск vuls, подключение к узлам и сбор информации о версиях пакетов.

3. Генерация отчётов в формате JSON:

   • minus — отчёт об устранённых уязвимостях (сравнение с предыдущим запуском, фиксация удалённых или обновлённых уязвимостей).

   • plus — отчёт о новых найденных уязвимостях.

4. Формирование итогового отчета (summary) — сводный PDF-документ по всей инфраструктуре, подготовленный на основе JSON-файлов.

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

Например, один из внутренних проектов, Netbox, показывает результат сканирования с устранением критических уязвимостей в установленных пакетах.

Кроме сводного отчёта по всей инфраструктуре, доступны и отчёты по отдельным серверам — для более детального анализа. В PDF-отчёте сканирования содержится информация по каждой уязвимости: идентификатор CVE, название виртуальной машины, название уязвимого пакета, статус устранения. Есть прямая ссылка на описание CVE в публичной базе данных.

Такая структура позволяет команде эксплуатации отслеживать динамику уязвимостей, быстро локализовать проблему и демонстрировать изменения как для внутренних целей, так и в отчётности перед клиентами. Чтобы добавить инфраструктуру для сканирования, достаточно указать данные для подключения к API облака.

Улучшения

Мы добавили в Vuls улучшения: автоматическую генерацию конфигураций и сканирование.

Генерация конфигурационных файлов

Одним из ключевых улучшений стала разработка компонента vulsconfig, отвечающего за автоматическое формирование конфигурационных файлов для сканирования.

В оригинальной реализации Vuls предполагается ручное составление конфигурации — указание всех узлов, их IP-адресов, параметров SSH-доступа и прочего. Это не масштабируется при работе с облачными инфраструктурами, где количество виртуальных машин может достигать десятков и сотен. Чтобы избежать рутинной ручной работы, мы внедрили механизм интеграции с API облака.

Компонент vulsconfig обращается к API, получает список всех активных инстансов в инфраструктуре, извлекает необходимые параметры (имя, IP-адрес, регион и т. д.) и автоматически формирует конфигурационный файл, совместимый с Vuls.

Сформированный конфиг далее используется в CI/CD-пайплайне:

• На первом этапе он проходит проверку доступности всех указанных хостов.

• После этого используется для запуска основного сканирования.

• Затем данные передаются в блоки генерации отчетов (JSON и PDF).

Это решение позволяет подключать к сканированию новые инфраструктуры без ручного редактирования конфигураций — достаточно передать параметры облачного проекта, и конфиг будет собран автоматически. Такая интеграция, ориентированная на работу с динамической инфраструктурой, является нашей доработкой и на текущий момент в open-source-версии Vuls отсутствует.

Контроль нагрузки и шаблонизация пайплайнов

Одним из доработанных элементов Vuls стала система лимитов на потребление ресурсов при сканировании. В ходе эксплуатации мы выявили, что при работе на маломощных виртуальных машинах (например, с 1 CPU и 1 GB RAM) стандартное поведение Vuls может приводить к полной загрузке и зависанию инстанса. Это особенно критично при сканировании большого количества пакетов или запуске на слабых виртуальных машинах.

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

Эту модификацию мы разработали как внутреннюю функциональность для команды эксплуатации, чтобы автоматизировать процесс поддержки большого количества инфраструктур. На этапе анализа существующих решений оказалось, что ни одно из доступных open-source-решений не отвечает нашему требованию: работать без агентов, иметь поддержку Jump Host и быть интегрируемым в CI/CD. Поэтому за основу был выбран Vuls, к которому мы добавили необходимую функциональность.

Эффект автоматизации: сокращение времени подготовки

Одним из ключевых факторов ускорения процесса стало использование мультипроектной структуры и автоматизированного генератора конфигурационных файлов. Благодаря компоненту vulsconfig нам не требуется вручную собирать сведения о каждой виртуальной машине: система запрашивает актуальные данные через API облачной платформы и формирует конфигурацию автоматически.

В ручном режиме подготовка конфигурации может занимать значительное время. Например, если в инфраструктуре 30–50 виртуальных машин, сбор информации об адресах, именах и параметрах подключения может занять от одного до двух часов. При объёмах в 500 VM эта задача может растянуться на целый день и стать источником ошибок.

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

Сканирование

Ключевым элементом является шаблон scan-base, к которому могут быть подключены различные инфраструктурные проекты. Все сканирования, генерации конфигураций и отчётов, обновления баз уязвимостей происходят централизованно и управляются через пайплайны CI/CD.

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

Основная цель системы — поддержка актуального и безопасного состояния программного обеспечения на серверах без необходимости ручного контроля. Уведомления об уязвимостях приходят на почту и содержат:

• идентификатор инстанса;

• количество и критичность уязвимостей;

• таблицу CVE с оценками и статусами;

• указание, доступен ли фикс.

Информация в уведомлениях не является критичной: речь идёт лишь о наличии уязвимых пакетов, а не о фактических инцидентах.

Система поддерживает широкий перечень дистрибутивов Linux: как rpm-based (RedHat, CentOS 6–9), так и deb-based (Debian, Ubuntu), включая ARM-архитектуры.

Сканер интегрирован с пайплайнами CI/CD — все операции, включая обновление базы уязвимостей, проходят через GitLab CI. При этом можно проследить историю изменений конфигураций и обеспечить контроль за процессом сканирования. Среди преимуществ — работа сразу с несколькими источниками для выявления уязвимостей: NVD (National Vulnerability Database), ExploitDB, Metasploit и специализированные базы (например, Red Hat CVE Database).

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

Как правило, подробные внутренние метрики (например, тестовые пакеты, не влияющие на безопасность) не отображаются в клиентских отчётах, чтобы не перегружать информацию. Однако при необходимости можно подключить расширенные поля — версии пакетов, дату последнего обновления, список CVE и прочее.

Основные преимущества сканирования с помощью Vuls

Мы для себя выделили такие преимущества от внедрения Vuls:

• Agentless-архитектура: не требуется установка ПО на сервера;

• Автоматизация: всё управление через CI/CD, без crontab и ручных скриптов;

• Поддержка множества ОС;

• «Гибкость» изначального продукта, которая позволила нам настроить для себя уведомления только по релевантным уязвимостям.

• Возможность масштабирования и гибкой настройки под любую инфраструктуру.

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