Привет, Хабр! На связи Евгений Лавров, архитектор отдела инжиниринга комплексных проектов компании Positive Technologies. Я занимаюсь разработкой проектных решений и внедрением наших продуктов совместно с партнерами или собственными силами у клиентов. Сегодня я хочу рассказать об интеграции нашей песочницы PT Sandbox со сторонними системами, даже если они не заявлены как поддерживаемые в документации, на примере интеграции с почтовым сервером CommuniGate Pro.
Здесь рассказываю, что из себя представляет PT Sandbox, если кто-то не знаком с продуктами класса «песочница».
Основное назначение системы — это проверка файлов и ссылок на вредоносность (как антивирус, но только лучше – так как песочницы умеют ловить и новое вредоносное ПО, которое не успело попасть в антивирусные базы?).
В PT Sandbox доступны следующие виды проверок:
Помимо классического антивирусного и IOC-анализа, PT Sandbox реализует множество продвинутых способов обнаружения: комбинированный поведенческий анализ в виртуальных машинах с применением технологий машинного обучения, динамическая и репутационная проверка ссылок.
1.Статические проверки c помощью антивирусов, собственных правил от нашего экспертного центра PT ESC, индикаторов компрометации PT IoC и средства проверки ссылок PT Crawler.
2. Динамический анализ, который работает по принципу эмуляции пользовательского окружения и наблюдения за поведением файла в динамике. Бывают такие случаи, когда хеш файла еще не попал в антивирусные базы, поэтому статика молчит и мы получаем вердикт, что файл вполне себе безопасный, а по его поведению видно, что занимается он совсем другими делами (например шлет что-то в Telegram, ищет определенные папки или создает скрипты в планировщике заданий), тут-то и срабатывают правила экспертизы для поведенческого анализа и выносится правильный вердикт.
Файлы могут попадать в песочницу несколькими разными способами. Можно:
· отправить копию электронного письма по SMTP;
· встроиться в маршрутизацию почтового трафика;
· отправить файлы по ICAP;
· просканировать сетевую папку;
· отправить файл через форму самообслуживания;
· воспользоваться API системы.
Однажды к нам пришел клиент с почтовым сервером CommuniGate, который использовался в паре с PT Sandbox в режиме скрытой копии. Этот метод поддерживается «из коробки» и не требует сложной настройки — нужно просто добавить маршруты на почтовый приемник PT Sandbox и Bcc-адресата к каждому письму. У этого метода есть один существенный недостаток: в этом режиме проверяется копия письма, а оригинал сразу доставляется в почтовый ящик, и на полученный от песочницы вердикт реагировать приходится уже вручную. Поэтому клиент попросил настроить работу с почтовым сервером в блокирующем режиме, когда зараженная или нежелательная почта отбрасывается и не доходит до почтового ящика пользователя. Такой режим существует по умолчанию для некоторых популярных почтовых серверов, но CommuniGate не так много, поэтому полноценная поддержка для него только в планах. Первым делом я попробовал поиграть со встроенной системой почтовой маршрутизации, чтобы «грязные» письма приходили на отдельный прослушиваемый порт, сразу перенаправлялись в песочницу, после проверки уже «чистые» письма маршрутизировались на другой прослушиваемый порт CommuniGate, а затем попадали в почтовый ящик пользователя.
Но настройка не увенчалась успехом: CommuniGate упорно отправлял письма в петлю и они так и не доходили до ящика пользователя, или же параметры приобретали совсем странный вид (например, отдельные домены использовались для «чистых» и «грязных ящиков», фильтрация происходила на основе кастомных служебных заголовков SMTP и т. п.).
После того как были испробованы стандартные методы, мы подробнее изучили раздел документации почтовой системы, посвященный средствам интеграции со сторонними системами (API или чему-то подобному).
В документации обнаружилось то, что мне было нужно, — протокол помощников, где как раз описывается интеграция с внешней системой фильтрации сообщений. Начав углубляться в эту функциональность, я понял, что она имеет довольно своеобразную архитектуру взаимодействия с внешними системами:
На сервере CommuniGate указывается путь к файлу для помощника внешней фильтрации, который будет запущен вместе с сервером (файл должен быть исполняемым и может быть написан на любом языке).
В стандартный поток ввода (stdin) этого файла будет передаваться сообщение в формате seqNum FILE fileName, где seqNum — это, по сути, ID задания, FILE — название функции, а fileName — относительная ссылка на файл.
-
После проверки помощник должен выдать в стандартный поток вывода (stdout):
seqNum ОК — если файл признан безопасным,
seqNum DISCARD — если письмо не прошло проверку.
Так как поток stdin нужно слушать постоянно, то было принято решение разделить обработку на два сервиса:
Коннектор. Его задача — слушать протокол помощников, передавать файл дальше на обработку и отвечать серверу по результатам проверки файла.
Gateway — реализует всю логику работы с API PT Sandbox: принимает файлы от коннектора, правильно заполняет все поля, отправляет файл на проверку по API, ждет вердикт и отправляет его коннектору.
По итогам получилась такая схема работы:
Логика работы максимально проста. Файл добавляется в отдельную почтовую очередь (штатная функциональность CommuniGate), ссылка передается на помощника, он обрабатывает сообщение и отправляет файл на проверку. Если возвращается любой вердикт, отличный от CLEAN, то письмо отбрасывается (настройка параметров проверки и сами задания доступны в интерфейсе PT Sandbox); если приходит вердикт CLEAN, то письмо отправляется в почтовый ящик пользователя. Стоит отметить, что эта реализация, в отличие от коробочной, использует механизм API, который не предполагает функциональности карантина и досылки письма после ручной верификации.
После того как появилось понимание базовой архитектуры и схемы решения, можно приступить к его реализации.
Оба сервиса было решено написать на Python, для реализации API использовать библиотеку FastAPI, а в качестве БД для временного хранения — SQLite.
Механизм работы получился следующий.
Модуль коннектора:
-
работает в два потока:
поток 1 — сервер API для обработки вердиктов и отправки в stdout,
поток 2 — цикл для чтения stdin;
работает по протоколу помощников, принимает команды и забирает файл по ссылке;
приводит письмо к каноничному EML*;
отправляет файл по API на Gateway;
получает от gateway ответ по API (gоток 1) и отправляет в stdout для общения с CommuniGate.
* CommuniGate использует .msg (не формат Microsoft, просто расширение, по сути — EML с кастомными транспортными заголовками). Чтобы письмо корректно отображалось в нашей песочнице, необходимо убрать эти заголовки (первые шесть строк).
Gateway:
получает по REST файл и UID запроса от коннектора;
направляет полученную информацию в БД (SQLite);
по настраиваемому таймеру отправляет задачи на сканирование в песочницу и ждет ответ, записывает вердикт в БД;
по второму настраиваемому таймеру запрашивает задания, для которых есть вердикт, и отправляет результат по API в коннектор; после успешной отправки удаляет сведения о задаче из БД.
Для удобства развертывания и эксплуатации сервис Gateway завернут в Docker-контейнер и может быть размещен отдельно от коннектора на любом другом сервере.
Порядок настройки примерно следующий:
-
настроить помощник со стороны CommuniGate:
заполнить файл .env с переменными для работы скрипта;
создать рядом со скриптом директорию с названием files для временных файлов;
настроить фильтрацию: Установки →Общее → Помощники → Фильтрация данных;
указать строку для запуска /usr/local/bin/python -u /var/CommuniGate/PTConnector/connector/connector.py (ключ -u для отключения буферизации как требования протокола);
настроить правило обработки почты, например:
-
настроить источник в PT Sandbox:
перейти в интерфейсе системы по пути: Источники → Добавить источник → API с выбранными параметрами проверки;
сгенерировать токен доступа, который будет использоваться в параметрах для Gateway;
настроить необходимые параметры проверки (поведенческий анализ, пользовательские правила определения опасных и потенциально опасных файлов, правила проверки и извлечения ссылок);
-
подготовить контейнер с Gateway:
собрать контейнер, используя Dockerfile (ссылка на все материалы будет ниже);
заполнить файл .env для работы Gateway;
отредактировать Compose-файл Docker;
запустить контейнер и убедиться, что он работает (файл с журналами настроили в Compose-файле, детализацию можно настроить в .env);
проверить в журналах CommuniGate, коннектора и Gateway, что все корректно настроено и работает.
Если все успешно настроено и запущено, письма должны появляться на вкладке «Задания». По результатам их проверки будет доступен подробный отчет, а пользователям CommuniGate будут поступать только проверенные письма (в качестве теста я настроил систему, чтобы она ругалась на все файлы .log, и положил такой как вложение).
Вот и вся история, которая, как вы помните, возникла отнюдь не из воздуха – запрос об интеграции PT Sandbox c почтовым сервисом возник на стороне клиента.
Надеюсь, данный материал будет полезен всем, кто рассматривает возможность интеграции по API со сторонними источниками файлов, официальная поддержка для которых не заявлена. А материалы для интеграции с CommuniGate Pro, описанные выше, доступны на нашем портале открытых дополнений Positive Technologies.
Евгений Лавров
Архитектор комплексных проектов, Positive Technologies