Детальная архитектура CuckooMX

Поток обработки письма

  1. Клиент или релей доставляет сообщение на Postfix (обычно порт 25).

  2. В master.cf для сервиса smtp … smtpd задан параметр content_filter=cuckoomx: после приёма Postfix передаёт уже собранное сообщение во внешний фильтр.

  3. Сервис cuckoomx типа pipe запускает cuckoomx.pl от выбранного непривилегированного пользователя; в argv передаются путь к скрипту и макросы Postfix (-f ${sender} ${recipient}).

  4. Скрипт сохраняет сырое тело письма и аргументы во временный каталог (карантин/рабочий каталог), разбирает MIME (MIME::Parser), рекурсивно обходит части multipart/*, при необходимости распаковывает ZIP, формирует список файлов для анализа.

  5. Для каждого извлечённого файла вызывается постановка задачи в Cuckoo (в upstream — запись в SQLite tasks; в поставке Arachnid.UTM — запросы к REST API по базовому URL из api-url).

  6. В конце всегда вызывается deliverMail: письмо возвращается в Postfix через sendmail, независимо от того, удалось ли поставить все задачи в Cuckoo.

Отличия от upstream CuckooMX (GitHub)

В оригинале xme/cuckoomx подключение к Cuckoo реализовано через модуль DBI и файл SQLite (cuckoo.db): новая задача добавляется SQL-оператором INSERT INTO tasks с полями file_path, md5, package, machine и т.д. Перед вставкой выполнялась проверка MD5, чтобы не дублировать уже поставленные файлы.

В модифицированном cuckoomx.pl (поставка из каталога cuckooMX modified в решении Arachnid.UTM):

  • Модуль DBI и путь к базе в конфигурации не используются; с узла Postfix не требуется доступ к файлам данных Cuckoo.

  • Подключены LWP::UserAgent и HTTP::Request::Common (POST); тело запроса — multipart/form-data.

  • Для файлов вызывается HTTP-метод POST на путь /tasks/create/file относительно базового URL из элемента api-url в cuckoomx.conf; в теле запроса — поля формы file (путь к образцу), package (имя пакета анализа из getPackage) и machine (значение узла guest из XML).

  • При включённой обработке URL (process-url) используется POST на путь /tasks/create/url с тем же базовым префиксом (api-url) и полями url и machine.

  • Если в конфигурации задан непустой api-token, к запросу добавляется заголовок Authorization: Bearer <токен>. Если токен в Cuckoo отключён, элемент api-token можно оставить пустым.

  • При неуспешном ответе API (включая 401 и 404) ошибка подробно пишется в syslog, функция постановки задачи завершается без exit; доставка почты не блокируется сбоем анализа.

  • Проверка «уже есть в БД по MD5», как в upstream, не выполняется; MD5 по-прежнему вычисляется и попадает в журнал, но повторная отправка того же содержимого на сторону API скриптом не подавляется.

Пользователь процесса pipe в Postfix должен иметь чтение cuckoomx.conf, запись в outputdir и право вызывать sendmail; он не обязан совпадать с учётной записью Cuckoo на другой машине.

Схема Postfix (content_filter + pipe), разбор MIME, ZIP и список игнорируемых MIME/URL в целом следуют upstream; комментарии и пример cuckoomx.conf в поставке дополнены под API и Cuckoo Sandbox 2.x.

Связь с периметром и Cuckoo

Postfix и Cuckoo Sandbox часто ставят на разных узлах: почтовый сервер в DMZ, песочница во внутреннем сегменте. API-режим упрощает такое разделение: открывается только HTTPS/HTTP к API Cuckoo (и при необходимости отдельные правила файрвола), без общих путей к файловой системе песочницы.

Следующая страница: Конфигурация и сценарии настройки CuckooMX.