SMTP smuggling в Postfix: где проверять и что менять

CVE-2023-51764 — это SMTP smuggling: из-за разного разбора окончаний строк два почтовых узла могут увидеть разные границы сообщения, что помогает подделать MAIL FROM и обойти SPF. Я покажу, как проверить сборку Postfix, выбрать исправление и пройти цепочку фильтров без ложного вывода по одному номеру версии.

Что именно ломает CVE-2023-51764

CVE-2023-51764 описывает SMTP smuggling в Postfix. Почтовый сервер и следующий узел цепочки могут по-разному трактовать нестандартное окончание строки: один принимает голый LF, другой ищет штатное сочетание CRLF и точку, завершающую блок DATA. В результате границы сообщения расходятся. Это дефект разбора SMTP-потока, а не удалённое выполнение кода и не волшебный способ положить почтовый сервер. Если вы отвечаете за защиту корпоративной почты, сначала стоит понять, какие именно узлы принимают внешнюю почту и как они передают письмо дальше.

Практический риск — подмена SMTP-отправителя MAIL FROM и обход проверки SPF в сценарии, где атакующий может отправить специально составленное письмо через подходящую цепочку серверов. Это не означает, что любой получатель автоматически увидит вредоносное вложение, а каждая проверка SPF станет бесполезной. Результат зависит от конфигурации принимающего Postfix, промежуточных фильтров и следующего MTA. Речь идёт о нарушении согласованности между компонентами; сам факт наличия Postfix в инфраструктуре ещё не доказывает успешную атаку.

Особенно легко ошибиться, когда письмо проходит через несколько SMTP-узлов. Первый сервер принимает DATA, фильтр анализирует содержимое, затем сообщение передаётся на следующий узел — и каждый участник должен одинаково понимать конец данных. Если трактовки расходятся, фильтр может оценить не тот набор байтов, который затем получит следующий компонент. Это объясняет, почему проверять нужно не только баннер SMTP на внешнем сервере, но и фактическую схему передачи. В статье о рисках почтовой инфраструктуры есть отдельный разбор того, почему один защитный слой не заменяет проверку всей цепочки.

Как определить затронутую сборку

Номер версии — начало проверки, но не её итог. В upstream-описании CVE указаны исправленные версии разных веток: 3.5.23, 3.6.13, 3.7.9, 3.8.4 и 3.9.0. В дистрибутиве исправление могло попасть в пакет с другим номером или быть перенесено отдельным патчем, поэтому сравнивать только строку «3.7» или «3.8» недостаточно. Сверьте полную версию пакета с бюллетенем безопасности именно вашей ОС. Если пакет обслуживается панелью или контейнерным образом, выясните, кто выпускает его обновления и когда образ был пересобран.

Версию Postfix можно запросить штатной командой postconf mail_version. Команда показывает параметр mail_version; это лучше, чем угадывать версию по приветствию SMTP, которое администратор мог изменить. Чтобы увидеть нестандартные значения конфигурации, используйте postconf -n, а затем сопоставьте их с документацией той версии, которая действительно установлена. Важная оговорка: некоторые параметры появились только в исправленных выпусках. Старый сервер может не знать новой директивы, поэтому отсутствие строки в выводе не доказывает, что настройка действует.

Для этой уязвимости смотрят не на header_checks и body_checks: они не являются универсальным исправлением разбора SMTP. В документации Postfix перечислены настройки, связанные с запретом неавторизованной конвейерной передачи команд и обработкой голых LF; доступность и значения по умолчанию зависят от ветки. Не копируйте найденный в интернете фрагмент в main.cf, пока не проверили синтаксис вашей сборки и уже заданные ограничения. Для самостоятельной сверки пригодится материал о проверке почтовой уязвимости, но окончательное решение принимайте по бюллетеню производителя пакета.

• Посмотрите mail_version через postconf
• Сверьте полный пакет с бюллетенем ОС
• Проверьте активные параметры и маршрут письма

Условный пример: галерея мебели и Postfix 3.7.2

Разберу тот пример, который задан для статьи: условная галерея мебели «Комната и стиль» в Москве, 21 рабочее место. Допустим, при инвентаризации администратор получил mail_version = 3.7.2. Это учебный сценарий, а не описание реального клиента, проведённого аудита или случившейся атаки. По одному этому номеру я не объявляю сервер взломанным; я фиксирую, что нужно проверить пакетный патч, настройки SMTP и место узла в почтовой схеме. Так цифры помогают принять решение, а не изображают доказательство инцидента.

Дальше я выясняю, принимает ли этот узел сообщения непосредственно из интернета, пропускает ли их через фильтр перед очередью и куда доставляет после проверки. Если на входе стоит шлюз, а Postfix получает почту только от него, проверяю конфигурацию обоих узлов и их договорённость о передаче DATA. Если же Postfix сам принимает внешнюю почту, рассматриваю его как входной MTA. Для каждой роли важны собственная сборка и активные параметры: установка исправления на одном сервере не обновит соседний фильтр автоматически.

Затем сверяю точный пакет 3.7.2 с источником обновлений конкретного дистрибутива. Версия upstream и версия пакета — не одно и то же: поставщик ОС может включить исправление в пакет с прежней основной веткой. Если подтверждения патча нет, планирую установку поддерживаемого обновления и отдельно проверяю совместимость фильтра и почтовых клиентов с настройками, которые запрещают неоднозначные строки. Никаких заявлений «в логах пропала атака» здесь быть не может: сценарий не содержит ни логов, ни подтверждённого инцидента. Проверить нужно факты, а не красивую легенду.

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

Как закрыть проблему без случайных правок

Первый выбор — установить обновление безопасности от сопровождающего вашу ОС поставщика или перейти на поддерживаемую им сборку Postfix. Не ориентируйтесь на универсальный совет «ставьте 3.8.6»: для этой CVE исправления выходили в нескольких ветках, а дистрибутивы выпускали собственные обновлённые пакеты. Сначала проверьте пакетный бюллетень, затем согласуйте окно изменения и резервную копию конфигурации. Установка нового пакета и перезапуск действующего процесса — разные этапы; способ перезапуска зависит от того, как Postfix установлен и управляется в вашей системе.

Для временного смягчения риска официальная документация Postfix описывает настройки, запрещающие неавторизованный SMTP pipelining, и ограничение команды CHUNKING. Среди вариантов — smtpd_forbid_unauth_pipelining = yes либо ограничение reject_unauth_pipelining в smtpd_data_restrictions вместе с отказом от chunking. Выбор зависит от версии и уже настроенных правил. Не заменяйте существующий список ограничений одной строкой из примера: Postfix применяет правила в определённом порядке, и неосторожная замена может поменять приём легитимной почты.

В более новых ветках есть smtpd_forbid_bare_newline, которое задаёт поведение для строк с голым LF. В Postfix 3.9.0 нормализация включена по умолчанию; в ряде более ранних исправленных веток настройку нужно явно проверить и включить, если это соответствует политике совместимости. Официально перечисленные минимальные версии для этой функции — 3.5.23, 3.6.13, 3.7.9, 3.8.4 и 3.9.0. Это не повод откатывать систему на старую ветку: используйте текущий поддерживаемый пакет и проверяйте требования к директиве в документации к нему.

После редактирования конфигурации проверьте синтаксис и примените изменение штатным для вашей установки способом. Для обычной установки Postfix команда postfix reload перечитывает конфигурацию; обновление бинарных файлов требует действий, которые задаёт пакет и система управления сервисом. Затем повторно проверьте версию, состояние очереди, приём внешнего письма и прохождение через фильтр. Короткое изменение параметра не заканчивается нажатием Enter. Если после запрета голых LF какой-то старый отправитель перестал работать, сначала выясните, какой компонент нарушает SMTP-формат, а не ослабляйте ограничение для всех.

Если у вас уже сложный набор ограничений, разберите его отдельно: порядок правил для ограничений SMTP-релея влияет на то, кто может передавать почту. Для SMTP smuggling же важны специальные правила обработки команд и окончаний строк. Смешивать эти задачи в одну «универсальную настройку безопасности» опасно: можно случайно открыть релей, не устранив причину разночтения. Я предпочитаю сначала зафиксировать текущие эффективные значения, затем внести минимальное изменение и проверить его в тестовой среде.

• Установить исправленный пакет от поставщика ОС
• Проверить настройки для своей ветки Postfix
• Перечитать конфигурацию и проверить доставку

Где проверять цепочку SMTP

Инвентаризируйте точки, которые принимают SMTP-трафик извне, и внутренние переходы между ними: MX-шлюз, фильтр, Postfix и следующий почтовый узел. Не каждый из них обязательно уязвим, но каждый переход может изменить или повторно разобрать поток. Отметьте, где заканчивается SMTP-сеанс, где письмо помещается в очередь и какой компонент получает результат фильтрации. Если внешний шлюз завершает соединение и создаёт новое, граница между этими сеансами особенно важна для понимания фактического маршрута.

Проверяйте действительные значения конфигурации и версии пакетов на каждом соответствующем узле. В контейнерной установке команда на хосте может показать не тот Postfix, который принимает SMTP внутри контейнера; смотрите именно на работающий экземпляр и его образ. Уточните также, не используется ли smtpd_proxy_filter и какие значения передаются службе после фильтра. Это не повод срочно перестраивать почтовую архитектуру. Сначала составьте схему двух-трёх переходов и найдите конкретную несовпадающую обработку.

Заголовок Received помогает восстановить маршрут сообщения, но сам по себе не доказывает, что фильтр и следующий сервер увидели одинаковое тело. Сверяйте его с журналами принимающих систем, идентификаторами очереди и логами фильтра. Не включайте постоянную подробную отладку для всех клиентов ради поиска одной аномалии: она может создать лишний объём журналов и раскрыть адреса или содержимое служебных полей. Для проверки результата применяйте контролируемый тест на стенде и валидный SMTP-поток, согласованный с документацией Postfix.

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

Приоритет работ и что считать результатом

Если Postfix получает внешнюю почту и пакет не подтверждён как исправленный, я ставлю обновление выше косметических настроек фильтра. Если почтовый сервер изолирован за шлюзом, всё равно проверяю его и шлюз отдельно: фильтрация на периметре снижает вероятность сценария, но не заменяет исправление принимающего ПО. Отсутствие жалоб пользователей также ничего не доказывает — подмена MAIL FROM может не вызвать заметной ошибки доставки. При этом не нужно сообщать руководству о «взломе», пока нет признаков инцидента: уязвимая конфигурация и состоявшаяся атака — разные утверждения.

Результат проверки должен быть конкретным: записана версия пакетной сборки, ссылка на бюллетень поставщика, список затронутых SMTP-узлов, значения нужных параметров и итог контролируемой проверки. После обновления зафиксируйте, что служба действительно использует новую сборку, а не только что пакетный менеджер завершил установку. Проверьте очередь и штатную доставку через фильтр. Если производитель рекомендует особое поведение для голых LF, проверьте и его; если вы добавили временное ограничение, назначьте ответственного за повторную проверку совместимости.

Не называйте CVE «активно эксплуатируемой» без подтверждения NVD, производителя или профильного CERT. В проверенных первоисточниках достаточно оснований объяснить механизм и закрыть дефект, но не обещать, что именно вашу организацию атаковали. Здесь важна точность формулировки: мы устраняем известное условие для SMTP smuggling и подтверждаем работу нужной цепочки. SPF, DKIM и DMARC остаются полезными настройками почтовой аутентификации, но ни одна из них не заменяет исправление неодинакового разбора SMTP-данных.

Если нужен разбор вашей конфигурации, я с командой сверю версии пакетов и параметры Postfix, помогу спланировать обновление и проверю доставку через фильтры. Обслуживание сервера стоит от 7 000 ₽/мес; объём работ и окно изменения согласуем после инвентаризации.

Частые вопросы