Проверка, что сервер не open relay: тестируем руками, чиним mynetworks, читаем аудиторов
Зелёная галочка внешнего аудитора проверяет один сценарий open relay из трёх. Разбираем, как воспроизвести SMTP-сессию руками, найти дыру в mynetworks и порядке restrictions, и почему authenticated relay abuse не виден ни одному тесту.
EvilMail Team25 июля 2026 г.11 мин чтения
Сервер полдня работал ровно, а потом на графике исходящего трафика по 25/tcp появилась ступенька высотой с небоскрёб. Открываете postqueue -p — очередь забита письмами на @gmail.com, @yahoo.com, @mail.ru от отправителей, которых у вас в системе нет и никогда не было. Через сорок минут ваш IP уже в CBL, ещё через час — в Spamhaus CSS, и любое легитимное письмо от реальных клиентов отбивается с 550 5.7.1. Кто-то нашёл в вашем сервере open relay раньше, чем вы.
Важно понять одну вещь: в 2026 году open relay почти никогда не возникает от того, что «забыли настроить ограничения». Postfix 2.10 и новее из коробки ставит безопасный smtpd_relay_restrictions и чужую почту в никуда по умолчанию не пускает. Open relay сегодня — это результат ручной ошибки: кто-то расширил mynetworks, поменял mynetworks_style, переставил местами restrictions или проглядел скомпрометированную SASL-учётку. И единственный способ узнать правду — не смотреть на postconf
Как проверить, что сервер не open relay: методика теста и типичные ошибки Postfix — EvilMail Blog
и не верить зелёной галочке внешнего сканера, а открыть SMTP-сессию с внешнего адреса и прочитать код ответа своими глазами.
Что именно считается open relay (и что нет)
Строгое определение: сервер является open relay, если он принимает письмо, где отправитель не ваш (клиент не в mynetworks и не прошёл аутентификацию) и получатель не ваш (домен не обслуживается локально и не является backup-relay), и после этого доставляет письмо дальше в интернет. Оба условия обязательны.
На практике путают три разных сценария, и разница принципиальна:
Настоящий open relay — сервер релеит чужую почту чужим получателям без всякой авторизации. Именно это проверяют внешние аудиторы.
Backscatter (обратное рассеивание) — сервер принимает письмо на несуществующий локальный ящик с ответом 250, а потом сам генерирует NDN (bounce) и отправляет его на подделанный адрес отправителя наружу. Формально это не relay, но для чужого IP в поле From последствия те же — жалобы и листинг.
Authenticated relay abuse — сервер настроен идеально, но у одного из ваших пользователей увели SASL-пароль, и злоумышленник рассылает спам через легальную аутентификацию. Технически это не open relay вообще, а с точки зрения инцидента — тот же залитый спамом IP и та же очередь.
Главный вывод: внешние тесты флагуют только первый сценарий. Реальные же инциденты в 2026 чаще происходят по третьему. Поэтому «тест показал OK» и «сервер чист» — это не одно и то же.
Воспроизводим SMTP-сессию руками
Это ядро проверки. Забудьте про сканеры на пять минут и проведите транзакцию сами. Критично важное условие: делать это надо с внешнего хоста, который не входит в `mynetworks` — с домашнего интернета, с дешёвого VPS в другом ДЦ, с телефона в режиме модема. Тест с самого сервера или из доверенной сети даёт 250 на всё и абсолютно бесполезен. По моему опыту, 90% ложно-успокаивающих «проверок» сделаны именно с localhost.
Открываем сессию с шифрованием и посимвольным вводом:
Если же вы видите 250 2.1.5 Ok — сервер согласился релеить чужое чужому, и перед вами живой open relay. Закрывайте сессию (QUIT) и бегите чинить конфиг, пока очередь пуста.
Дальше — автоматизация через swaks, чтобы прогнать вектора, которые руками набивать долго. Все команды запускаются с того же внешнего хоста:
На каждую пробу здоровый сервер обязан ответить 554 на этапе RCPT TO. Percent-hack и source route — древние трюки, но я до сих пор встречаю их сработавшими на серверах, где кто-то отключил современные защиты «чтобы совместимость не ломалась». Проверьте, что стоят:
bash
postconf allow_percent_hack swap_bangpath resolve_dequoted_address
# Ожидаем:
# allow_percent_hack = no
# swap_bangpath = no
# resolve_dequoted_address = yes
Ниже — как именно Postfix принимает решение по каждой транзакции. Держите эту схему в голове, когда будете читать свой конфиг.
Три ошибки в mynetworks, из-за которых всё ломается
Практически все реальные open relay сводятся к трём конфигурационным ошибкам. Разберём каждую с диагностикой.
Ошибка 1: `mynetworks_style = subnet` (или `class`). Самая коварная. При subnet Postfix доверяет не одному вашему адресу, а всей подсети сетевого интерфейса — по маске, которую видит система. Если сервер стоит у хостера и интерфейс поднят с маской /16, доверенными окажутся все соседи по этому блоку. А class расширяет доверие до целого классового блока A/B/C. На практике это значит, что сотни чужих машин соседей по хостингу могут релеить через вас. Проверяем, что реально считается доверенным:
Ошибка 2: руками вписали лишнее. Классика полевых инцидентов: 0.0.0.0/0 («временно для отладки» и забыли), забытый ::/0 в IPv6 при закрытом IPv4, docker-сети 172.16.0.0/12 и 10.0.0.0/8, которые внезапно оказались маршрутизируемыми наружу, весь /24 офиса, проброшенный через VPN на публичный интерфейс. Читайте postconf mynetworks построчно и на каждый диапазон отвечайте: «я точно контролирую все машины в этом блоке?». Сомневаетесь — убирайте.
Ошибка 3: порядок в restrictions. Если permit_mynetworks или любой широкий permit стоит в smtpd_recipient_restrictionsдоreject_unauth_destination, relay-защита обходится. Хуже того — иногда кто-то переопределяет smtpd_relay_restrictions пустым значением, чтобы «убрать лишние отбивки», и сносит защиту релея разом. Безопасный дефолт выглядит так:
На этапе диагностики defer_unauth_destination предпочтительнее reject_unauth_destination: он отвечает 450 (временный отказ) вместо 554. Если вы случайно передавили и заблокировали легитимный поток, письма встанут в очередь у отправителя, а не отобьются навсегда. После проверки возвращаете reject.
Authenticated relay: дыра, которую аудитор не увидит
Вы прогнали все пробы, получили честные 554, MXToolbox показал зелёное — а сервер всё равно однажды утром рассылает спам. Это третий сценарий: у кого-то из ваших пользователей слабый или утёкший SASL-пароль, и злоумышленник аутентифицируется совершенно легально. Ни один open-relay-тест это не поймает: для сервера это ваш законный клиент.
Первым делом найдите источник в логах — какой аккаунт внезапно шлёт тысячи писем:
Аккаунт с аномальным числом отправок наверху списка — ваш скомпрометированный ящик. Меняем пароль, дальше закрываем структурные дыры:
AUTH только на submission. На порту 25 аутентификацию отключаем, разрешаем только на 587 (STARTTLS) и 465 (implicit TLS). В master.cf на smtp inet ставим -o smtpd_sasl_auth_enable=no, а на submission/smtps — -o smtpd_sasl_auth_enable=yes.
`smtpd_tls_auth_only = yes` — пароли не летают по открытому каналу никогда.
Rate-limit через anvil.smtpd_client_message_rate_limit = 100 и smtpd_client_connection_rate_limit не остановят компрометацию, но превратят «залили 200k писем за час» в «упёрлись в лимит на первой тысяче» — а у вас появится время среагировать.
Алерт на очередь.postqueue -p | grep -c '^[A-F0-9]' в мониторинге: резкий рост длины очереди — самый ранний сигнал, часто раньше, чем прилетит листинг.
Внешние аудиторы: чем пользоваться и как читать результат
Внешние сканеры полезны как финальная страховка, но их границы надо понимать. MXToolbox Open Relay Test отправляет около 17 разных relay-проб — прямую, percent-hack, bang path, source route, quoted-варианты. Тест хороший, но узкий: он проверяет только сценарий «чужой отправитель → чужой получатель без auth». Authenticated abuse и backscatter он не увидит принципиально. Дополняют картину multirbl.valli.org (агрегатор RBL) и relay-чекеры вроде allaboutspam.
Если инцидент уже случился, проверяйте себя по чёрным спискам: Spamhaus (SBL/CSS/XBL/PBL), Spamcop, CBL (cbl.abuseat.org), PSBL, SORBS, Barracuda (b.barracudacentral.org). CBL реагирует на рассылку за десятки минут — если вы туда попали, поток идёт уже какое-то время.
Два предостережения из практики. Первое: не гоняйте open-relay-тесты по крону через сторонний сервис. Регулярные relay-пробы от внешнего IP осядут в ваших же логах как подозрительный источник, а некоторые системы репутации это учитывают. Тестируйте по необходимости и после изменений конфига, а не «каждые 15 минут для спокойствия». Второе: сначала закройте дыру, потом делистинг. Запросите исключение из CBL при открытом relay — вас через час залистят повторно, а второй листинг снимается тяжелее.
Чеклист перед выкатом
postconf mynetworks — прочитать каждый диапазон глазами и оправдать каждый; всё сомнительное убрать.
mynetworks_style = host — зафиксировано явно, не subnet и не class.
swaks-проба чужой→чужой с внешнего IP (не из mynetworks!) → ждём 554.
Пробы percent-hack, bang path, source route → все дают 554; allow_percent_hack = no, swap_bangpath = no.
AUTH выключен на 25, включён только на 587/465, smtpd_tls_auth_only = yes.
smtpd_client_message_rate_limit и connection-limit выставлены.
smtpd_relay_restrictions не переопределён пустым и содержит defer/reject_unauth_destination в конце.
Мониторинг длины очереди с алертом; в логах настроен поиск по sasl_username.
MXToolbox — как финальная страховка, а не единственный источник правды.
Зелёная галочка внешнего аудитора проверяет один сценарий open relay из трёх. Доверяйте коду 554 из ручной сессии, поднятой с внешнего адреса, и содержимому postconf -n — а не чужому дашборду, который не знает ни про вашу утёкшую SASL-учётку, ни про docker-сеть в mynetworks. Инфраструктура evilmail.pro проходит этот чеклист на каждом релизе именно потому, что postconf показывает то, что настроено, а живая SMTP-сессия — то, что происходит на самом деле.
