Postfix: ризик відкритого ретранслятора — протестуйте, доведіть, закрийте

November 7, 2025 • February 3, 2026 • Читання: 6 хв • Views: 6

Було корисно?

Немає нічого, що старить швидше, ніж відмова пошти через причину «ми стали відкритим ретранслятором». Одної хвилини ви випускаєте нормальний реліз; наступної ви спостерігаєте, як ваш публічний IP потрапляє в блок-лист, а ваш CEO дивується, чому «наш сервер розсилає спам у Молдову».

Це не теоретичний ризик. Це режим відмови конфігурації з чіткими, повторюваними тестами й однозначними доказами в логах. Виправлення нудне, точне та повністю під вашим контролем. Робимо так, як вимагають продакшн-системи: протестуйте, доведіть, закрийте і задокументуйте, щоб це не повернулося.

Що насправді означає «відкритий ретранслятор» (і чого це не стосується)

Відкритий ретранслятор — це SMTP‑сервер, який приймає повідомлення від неавторизованого, неперевіреного клієнта і пересилає його на зовнішній домен. Простими словами: випадковий хост з інтернету підключається до вашого Postfix, дає йому повідомлення «від» будь‑кого «до» будь‑кого, і ваш сервер погоджується доставити його далі.

Це ядро проблеми. Все інше — шум.

Не відкритий ретранслятор: сервер, який приймає пошту для своїх доменів (mydestination, віртуальні домени) з інтернету і доставляє локально.
Не відкритий ретранслятор: сервер, який ретранслює вихідну пошту лише для автентифікованих користувачів (SASL на submission) або довірених мереж (mynetworks).
Відкритий ретранслятор: приймає пошту з довільних джерел і ретранслює її на довільні призначення.

Небезпечне непорозуміння: «Ми за фаєрволом» або «Порт 25 тільки для вхідних з’єднань» може перетворитися на «Добре, давайте дозволимо ретрансляцію з 10.0.0.0/8», а потім хтось додає VPN, неправильно маршрутизовану підмережу або контейнерну мережу, які не мали б викликати довіру. Вітаємо, ви видали вашій інфраструктурі електронний еквівалент пропуску для гостей, який ніколи не закінчується.

Фраза, яку ви маєте вміти сказати вголос: «З не довіреного IP, без автентифікації, Postfix відхиляє спроби ретрансляції на не‑локальні домени з чіткою політичною помилкою.» Це ваше доказ. Все інше — відчуття.

Факти та історія: чому це повторюється

Відкриті ретранслятори — стара проблема, але вони постійно повертаються, бо електронна пошта — це поле сумісності, і люди ставляться до неї як до галочки у списку.

Ранні SMTP припускали дружню мережу. Первісна екосистема пошти поводилася як клуб, де всі знали одне одного. Це припущення вмерло в публічному інтернеті.
У 1990‑х відкриті ретранслятори були повсюди. Їх часто налаштовували, щоб «допомагати» доставки пошти з dial‑up користувачів або неправильно налаштованих мереж малого бізнесу.
Блок‑лісти стали механізмом виживання. Після вибухового зростання спаму оператори почали публікувати IP відомих ретрансляторів і спамерів. Доставлюваність стала операційним, а не лише технічним питанням.
Postfix створювався з думкою про більшу безпеку за попередників. Одна з причин популярності Postfix у тому, що він прагнув бути secure‑by‑default у порівнянні з культурою «змініть цей один файл і надійся».
Існує submission (587), бо порт 25 хаотичний. Індустрія розділила «сервер‑до‑сервера» SMTP і «відправку користувача», щоб покращити автентифікацію й контроль політик.
SASL і TLS не «вирішили» проблему спаму, але змінили місце, де застосовують політику. Сучасний підхід: автентифікувати користувачів на 587, бути жорстким на 25.
NAT і хмарні мережі створили нові межі довіри. «Внутрішній IP» більше не означає «керований оператором хост». Це може бути «контейнер, про який ви забули».
Неправильна конфігурація — домінуюча причина. Відкриті ретранслятори рідко бувають результатом складного зламу. Зазвичай це «ми встановили mynetworks=0.0.0.0/0 під час тесту і забули».

Цитата, яка має бути на папірці біля вашого конфігу MTA: «Сподівання — не стратегія.» — Gordon R. Dickson

Модель загроз: як нападники знаходять і експлуатують ретранслятори

Нападникам не потрібно «вламуватися» в Postfix, щоб його використовувати. Достатньо, щоб сервер сказав «ОК» у невірний момент.

Виявлення

Вони сканують. Постійно. Цілі IPv4‑діапазони перевіряються на SMTP порти 25, 465, 587. Хост-сканер може бути вузлом ботнету, VPS або хостом, що вже в блок‑листі. Ви побачите короткі підключення, HELO рядки, що виглядають як випадковий набір символів, і спробу швидко відправити на зовнішній домен.

Експлуатація

Якщо ретрансляція дозволена, нападник передає вашому серверу купу пошти. Ваша система стає гарматою; ваш IP — відбитком. Ви платите за трафік, сховище черги, CPU і репутацію.

Наслідки

Негайні: ріст черги пошти, стрибки використання диска, насичення SMTP‑воркерів, затримка або втрата легітимної вихідної пошти.
Вторинні: потрапляння в блок‑лісти; партнери відхиляють пошту; листи для скидання паролів не приходять; кількість звітів у службу підтримки зростає.
Довготривалі: відновлення доставлюваності триває навіть після виправлення ретранслятора. Репутація затримується; як і блок‑лісти.

Жарт №1: відкритий ретранслятор — це як залишити напис «безкоштовна доставка» на вашому вантажному майданчику. Інтернет не делікатно забере тільки одну коробку.

Швидкий план діагностики (перші/другі/треті перевірки)

Якщо підозрюєте відкриту ретрансляцію — або відповідаєте на «чому черга пошти вибухнула» — не тиняйтеся по конфігах, ніби шукаєте загублений ключ. Виконуйте ті самі три перевірки щоразу.

Перше: Підтвердіть симптом (чи ми ретранслюємо?)

Шукайте status=sent до зовнішніх доменів, що походять із підозрілих IP.
Шукайте Relay access denied (добре) проти успішної ретрансляції (погано).
Перевірте, чи натиск припадає на порт 25 (server‑to‑server) або 587 (submission).

Друге: Визначте, який політичний елемент не спрацював

Перевірте smtpd_recipient_restrictions, smtpd_relay_restrictions, mynetworks та налаштування SASL.
Підтвердіть, що Postfix вважає «локальним» через mydestination та карти віртуальних доменів.

Третє: Зупиніть кровотечу безпечно

Тимчасово посильте обмеження (відхиляйте ретрансляцію з усіх, крім відомих мереж / автентифікації).
Обмежуйте швидкість і/або відхиляйте підозрілих клієнтів; розгляньте блокування на фаєрволі, якщо трафік екстремальний.
Керуйте чергою і фільтруйте (не видаляйте сліпо — спочатку ідентифікуйте масштаб).

Коли пожежу загашено, можна зайнятися ретельнішою роботою: довести відсутність ретрансляції ззовні, перевірити конфігурацію submission і оновити робочі інструкції.

Доведіть тестами: команди, виводи, рішення (12+ завдань)

Нижче практичні завдання, які можна виконати на типовому Linux‑хості з Postfix. Мета не милуватися виводом. Мета — приймати рішення на його основі.

Завдання 1: Підтвердіть, що Postfix працює і на яких портах слухає

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-01-03 08:11:32 UTC; 3h 14min ago
       Docs: man:postfix(1)
   Main PID: 1223 (master)
      Tasks: 4 (limit: 18921)
     Memory: 18.4M
        CPU: 1min 12s

Що це означає: Postfix активний. Якщо він не запущений — ви не відкритий ретранслятор, ви просто недоступні.

Рішення: Перейдіть до перевірки портів. Якщо сервіс неактивний, відновіть його спочатку, потім перевірте конфіги перед відкриттям фаєрволу.

cr0x@server:~$ ss -lntp | egrep ':(25|465|587)\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1223,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1223,fd=15))

Що це означає: Порти 25 і 587 відкриті на всіх інтерфейсах. Це нормально для багатьох серверів; це також причина, чому треба суворо контролювати політику ретрансляції.

Рішення: Якщо цей хост не має приймати публічний SMTP, зв’яжіть служби з конкретними інтерфейсами або закрийте порти на фаєрволі/групі безпеки.

Завдання 2: Перегляньте ефективну конфігурацію Postfix (не те, що ви думаєте, ви встановили)

cr0x@server:~$ postconf -n
myhostname = mx1.example.net
mydestination = $myhostname, localhost.example.net, localhost
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_tls_security_level = may

Що це означає: Це ефективна недефолтна конфігурація. Найбільше вас цікавлять mynetworks, smtpd_relay_restrictions і позиція reject_unauth_destination.

Рішення: Якщо defer_unauth_destination або reject_unauth_destination відсутні, ви в небезпечній зоні. Виправляйте негайно.

Завдання 3: Переконайтеся, що `mynetworks` не є «інтернетом у маскуванні»

cr0x@server:~$ postconf mynetworks
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16

Що це означає: Довіра надається 10.10.0.0/16. Це прийнятно лише якщо ви повністю контролюєте цю мережу і можете поручитися за кожний хост, що має доступ до портів 25/587.

Рішення: Якщо ви бачите 0.0.0.0/0, 10.0.0.0/8 «тому що це внутрішнє» або CIDR хмарної VPC, що включає сторонні або тимчасові робочі навантаження — звузьте його. Надавайте перевагу явним підмережам для клієнтів пошти або взагалі уникайте permit_mynetworks для ретрансляції.

Завдання 4: Перевірте, що обмеження ретрансляції стоять у правильному місці (нюанси версії Postfix)

cr0x@server:~$ postconf smtpd_relay_restrictions
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

Що це означає: Postfix дозволяє ретрансляцію для довірених мереж і автентифікованих клієнтів, і відкладає/забороняє неавторизовані призначення. Сучасний Postfix очікує політику ретрансляції саме тут.

Рішення: Якщо smtpd_relay_restrictions порожній або надмірно дозволяючий — ви кандидат на відкритий ретранслятор. Виправляйте перш ніж робити щось інше.

Завдання 5: Протестуйте поведінку ретрансляції з самого сервера (базова перевірка)

Цей тест сам по собі недостатній (оскільки localhost може бути в mynetworks), але підтверджує інструментарій і базові DNS‑налаштування.

cr0x@server:~$ swaks --server 127.0.0.1 --from test@external.example --to someone@gmail.com
=== Trying 127.0.0.1:25...
=== Connected to 127.0.0.1.
<--  220 mx1.example.net ESMTP Postfix
 --> EHLO server
<--  250-mx1.example.net
<--  250 PIPELINING
 --> MAIL FROM:<test@external.example>
<--  250 2.1.0 Ok
 --> RCPT TO:<someone@gmail.com>
<--  554 5.7.1 <someone@gmail.com>: Relay access denied

Що це означає: Сервер відмовив у ретрансляції до Gmail. Добре. Якщо він прийняв RCPT і пішов до DATA — це червоний сигнал.

Рішення: Навіть якщо це виглядає добре, потрібно тестувати з недовіриного хоста поза межами mynetworks.

Завдання 6: Протестуйте поведінку ретрансляції з зовнішнього хоста (доказ)

Запустіть з окремої машини в інтернеті, яка не знаходиться у ваших довірених мережах і не автентифікована. Використовуйте домен‑призначення, яким ви не володієте.

cr0x@server:~$ swaks --server mx1.example.net --from probe@external.example --to someone@yahoo.com --timeout 15
=== Trying 203.0.113.10:25...
=== Connected to 203.0.113.10.
<--  220 mx1.example.net ESMTP Postfix
 --> EHLO probehost
<--  250-mx1.example.net
<--  250 STARTTLS
 --> MAIL FROM:<probe@external.example>
<--  250 2.1.0 Ok
 --> RCPT TO:<someone@yahoo.com>
<--  554 5.7.1 <someone@yahoo.com>: Relay access denied

Що це означає: Це ваше свідчення. Сервер відхиляє ретрансляцію для неавтентифікованих зовнішніх клієнтів.

Рішення: Збережіть цей вивід (тікет, нотатки інциденту, аудиторські докази). Якщо він не відхиляє — поводьтеся як із інцидентом.

Завдання 7: Переконайтеся, що сервер все ще приймає вхідну пошту для локальних доменів

cr0x@server:~$ swaks --server mx1.example.net --from probe@external.example --to postmaster@example.net --timeout 15
=== Trying 203.0.113.10:25...
=== Connected to 203.0.113.10.
<--  220 mx1.example.net ESMTP Postfix
 --> EHLO probehost
<--  250-mx1.example.net
 --> MAIL FROM:<probe@external.example>
<--  250 2.1.0 Ok
 --> RCPT TO:<postmaster@example.net>
<--  250 2.1.5 Ok
 --> DATA
<--  354 End data with <CR><LF>.<CR><LF>

Що це означає: Ваш сервер не «закритий для бізнесу». Він приймає пошту для локальних одержувачів, відхиляючи ретрансляцію до третіх сторін.

Рішення: Якщо локальна доставка не працює, перевірте mydestination, віртуальні домени та таблиці одержувачів перед тим, як торкатися правил ретрансляції.

Завдання 8: Перегляньте логи пошти для рішень про ретрансляцію (що фактично зробив Postfix)

cr0x@server:~$ sudo grep -E "Relay access denied|reject_unauth_destination|status=sent" /var/log/mail.log | tail -n 20
Jan 03 10:44:11 mx1 postfix/smtpd[18844]: NOQUEUE: reject: RCPT from unknown[198.51.100.77]: 554 5.7.1 <someone@yahoo.com>: Relay access denied; from=<probe@external.example> to=<someone@yahoo.com> proto=ESMTP helo=<probehost>
Jan 03 10:44:42 mx1 postfix/smtpd[18845]: NOQUEUE: reject: RCPT from unknown[198.51.100.78]: 554 5.7.1 <random@gmail.com>: Relay access denied; from=<payroll@external.example> to=<random@gmail.com> proto=ESMTP helo=<workstation>

Що це означає: NOQUEUE і «reject at RCPT» — те, що ви хочете: дешеве відхилення до прийому даних повідомлення.

Рішення: Якщо ви бачите успішні ретрансляції (status=sent) від клієнтів, яких не впізнаєте, негайно починайте ізоляцію та перегляд конфігурації.

Завдання 9: Перевірте розмір черги та чи це runaway‑спам

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     1423 Tue Jan  3 10:49:02  spammer@fake.example
                                         victim1@gmail.com

F6G7H8I9J0     1501 Tue Jan  3 10:49:03  spammer@fake.example
                                         victim2@yahoo.com

Що це означає: Зовнішні одержувачі і підозрілі відправники — типовий патерн зловживання ретранслятором. Черга з’їдає диск і IOPS, доки ваш сервер не перетвориться на дуже дорогий обігрівач.

Рішення: Якщо черга росте активно — ізолюйте: посильте правила ретрансляції, блокуйте зловмисні IP і розгляньте тимчасові ліміти. Потім вирішіть, чи очищувати чергу після збереження доказів.

Завдання 10: Перегляньте конкретне повідомлення в черзі (обсяг і походження)

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,60p'
*** ENVELOPE RECORDS ***
message_size: 1423
message_arrival_time: Tue Jan  3 10:49:02 2026
sender: spammer@fake.example
recipient: victim1@gmail.com
*** MESSAGE CONTENTS ***
Received: from unknown (unknown [198.51.100.77])
        by mx1.example.net (Postfix) with ESMTP id A1B2C3D4E5
        for <victim1@gmail.com>; Tue,  3 Jan 2026 10:49:02 +0000 (UTC)
Subject: Urgent invoice

Що це означає: Показує підключення з недовіреного IP. Це ваша смолоскипна доказова нитка, якщо ретрансляцію прийнято.

Рішення: Якщо ви підтвердите зловживання — збережіть зразок заголовків і відповідні рядки логів. Потім видаліть спам із черги і, якщо було автентифіковано, скиньте облікові дані.

Завдання 11: Перевірте `master.cf` на непередбачені служби (submission, smtps, політики‑override)

cr0x@server:~$ sudo postconf -M | egrep '^(smtp|submission|smtps)/'
smtp/inet/smtp
submission/inet/submission

Що це означає: Служби існують. Це нормально. Небезпека — в пер‑службових переоприділеннях, які випадково дозволяють ретрансляцію широко.

Рішення: Перевірте секції submission і smtps на -o переоприділення, що ослаблюють обмеження.

cr0x@server:~$ sudo sed -n '1,160p' /etc/postfix/master.cf
smtp      inet  n       -       y       -       -       smtpd
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Що це означає: Submission вимагає TLS і автентифікації та відхиляє інакше. Це добре: запобігає «анонімній відправці».

Рішення: Якщо ви бачите permit_mynetworks на submission без суворого mynetworks, ви довіряєте не тому рівню.

Завдання 12: Переконайтеся, що SASL справді працює на 587 (інакше ви проб’єте дірки десь ще)

cr0x@server:~$ swaks --server mx1.example.net --port 587 --tls --auth LOGIN --auth-user 'user@example.net' --auth-password 'wrongpass' --from user@example.net --to someone@gmail.com
=== Trying 203.0.113.10:587...
=== Connected to 203.0.113.10.
<--  220 mx1.example.net ESMTP Postfix
 --> EHLO probehost
<--  250-AUTH PLAIN LOGIN
 --> AUTH LOGIN
<--  334 VXNlcm5hbWU6
 --> dXNlckBleGFtcGxlLm5ldA==
<--  334 UGFzc3dvcmQ6
 --> d3JvbmdwYXNz
<--  535 5.7.8 Error: authentication failed: authentication failure

Що це означає: Автентифікація працює. Неправильний пароль відхиляється. Добре.

Рішення: Якщо автентифікація відключена або не афішується — виправляйте це замість розширення mynetworks як тимчасового рішення.

Завдання 13: Перевірте локальні домени сервера і уникайте випадкового «локальний = ретрансляція»

cr0x@server:~$ postconf mydestination
mydestination = $myhostname, localhost.example.net, localhost

Що це означає: Лише ці домени вважаються локальними для класичної локальної доставки. Якщо ви хостите example.net як вхідний домен, він має з’являтися через virtual_mailbox_domains або подібні, а не обов’язково в mydestination.

Рішення: Тримайте визначення локальних доменів точними. Надто широкі «локальні домени» можуть спричинити петлі маршрутизації й політичні сюрпризи.

Завдання 14: Підтвердіть, який IP Postfix вважає клієнтом (пастки проксі і балансувальників)

cr0x@server:~$ postconf smtpd_upstream_proxy_protocol
smtpd_upstream_proxy_protocol =

Що це означає: Проксі‑протокол вимкнений. Якщо ви стоїте за TCP‑балансувальником чи реверс‑проксі для SMTP і неправильно налаштували збереження IP клієнтів, Postfix може вважати кожного клієнта «внутрішнім» (IP проксі), випадково надаючи право ретрансляції.

Рішення: Якщо ви перед SMTP ставите проксі, проектуйте уважно: зберігайте IP клієнта і обмежуйте за реальними джерелами, а не за IP проксі.

Ментальна модель конфігурації Postfix: регулятори, що мають значення

Postfix може виглядати як мішок параметрів, доки ви не зрозумієте форму дерева прийняття рішень.

Ключова відмінність: приймати пошту vs ретранслювати пошту

Політика SMTP переважно вирішується на етапі RCPT TO:

Якщо одержувач локальний (домени, які ви хостите), Postfix може прийняти його з інтернету. Це нормальна вхідна пошта.
Якщо одержувач не локальний, то прийняття — це ретрансляція. Ретрансляція має бути обмежена автентифікованими користувачами або явно довіреними мережами.

`reject_unauth_destination` — це швейцар

Найважливіший контроль проти відкритого ретранслятора в Postfix — reject_unauth_destination (або його defer‑варіант). Він відхиляє спроби відправити на не‑локальні домени, якщо клієнт не довіряється попередніми правилами.

У сучасному Postfix це зазвичай розміщується в smtpd_relay_restrictions. У старіших конфігураціях його часто ставили в smtpd_recipient_restrictions. Можна мати його в обох, але ви маєте чітко розуміти, який список і коли оцінюється. Те, чого не можна робити — видаляти його тому, що «він колись поламав форвардинг». Це не виправлення; це зняття гальм, бо машина скрипить.

`mynetworks`: найпростіший спосіб вистрілити собі в ногу

permit_mynetworks зручний і небезпечний. Він каже: «якщо ви з цих джерел — вам довіряють для ретрансляції». Це нормально для маленького контрольованого середовища. Ризикований підхід у сучасних мережах, де «внутрішнє» включає ноутбуки, BYOD, вузли Kubernetes і епhemeral інстанси, створені CI.

Хороші практики:

Тримайте mynetworks обмеженим до loopback і конкретної підмережі, де живуть ваші автентифіковані клієнти пошти (якщо воно потрібно).
Віддавайте перевагу автентифікованій відправці через submission (587) для користувачів.
Якщо додаткам потрібна ретрансляція, вимагайте від них автентифікацію або обмежуйте по IP з хірургічною точністю.

`mydestination` і «локальні домени» визначають, що не є ретрансляцією

Якщо Postfix вважає домен локальним, він прийме пошту для нього (залежно від інших обмежень). Якщо домен не локальний — прийняття означатиме ретрансляцію. Неправильне визначення локальних доменів спричиняє дві поширені проблеми:

Відхилення легітимної вхідної пошти («user unknown» або «relay access denied» для ваших доменів).
Випадкове прийняття пошти, що ніколи не мала оброблятися цим сервером (петлі маршрутизації, поштові шторми, незручна експозиція для відповідності правилам).

Submission — тут варто бути щедрими (але з автентифікацією)

Порт 587 — місце, де дозволено відправляти вашу пошту назовні, з вимогами:

TLS у вимозі
СASL‑автентифікація
Явні обмеження, щоб submission не став бекдором для ретрансляції

Закрийте: безпечні шаблони для продакшн Postfix

Будемо категоричні. Якщо ваш екземпляр Postfix доступний в інтернеті на порті 25, за замовчуванням він має приймати лише пошту для ваших доменів; не ретранслювати для незнайомців; надавати вихідну пошту через автентифіковану submission.

Шаблон A: Інтернет‑MX для вхідної пошти, без публічної вихідної ретрансляції

Класична роль MX. Приймаєте вхідну пошту для ваших доменів. Не дозволяєте випадковим клієнтам ретранслювати назовні.

Критичні налаштування (ілюстративно, не копіпаст святе):

smtpd_relay_restrictions: має закінчуватися defer_unauth_destination або reject_unauth_destination
mynetworks: лише loopback, якщо немає контрольованого внутрішнього випадку ретрансляції
mydestination/віртуальні домени: точно ваші хостовані домени

Шаблон B: Вихідний ретранслятор для внутрішніх додатків (рекомендовано: автентифікований)

Ваші додатки хочуть відправляти листи. Не варто приймати рішення про довіру по IP у складних мережах.

Використовуйте submission з SASL. Якщо ваш додаток не може робити SASL — це проблема продукту; вирішуйте її як таку. Якщо вам критично потрібна IP‑довіра, ізолюйте її: окремий слухач, прив’язаний до внутрішнього інтерфейсу, суворий фаєрвол і мінімальні CIDR.

Шаблон C: Smart host / relayhost (уникайте випадкового транзиту)

Деякі хости Postfix не повинні прямо розмовляти з інтернетом. Вони мають відправляти все через корпоративний relayhost або шлюз безпеки для пошти.

Це безпечніше для контролю виходу, але не плутайте з запобіганням відкритому ретранслятору. Система може пересилати всю пошту до smart host і все одно бути відкритим ретранслятором, якщо вона приймає неавтентифіковану зовнішню пошту і пересилає її далі.

Два практичні запобіжні заходи, які слід впровадити

Зробіть «доведіть, що не відкритий ретранслятор» воротами для деплою. Простий зовнішній swaks‑тест у CI/CD або хоч би в процесі зміни конфігурації.
Зменшіть зону ураження мережею. Групи безпеки/фаєрволи, що обмежують доступ до 587, а в деяких проєктах навіть до 25 (якщо ви не MX).

Жарт №2: Postfix робитиме точно те, що ви йому скажете, тому іноді він поводиться як дуже ввічливий, але катастрофічний стажер.

Три корпоративні міні‑історії з практики

Міні‑історія 1: Інцидент, спричинений хибним припущенням

Вони мігрували поштові сервіси з легасі VM‑кластера до хмари. Стара архітектура покладалася на «внутрішня мережа = довірена». Це працювало роками, бо «внутрішнє» означало кілька аплікаційних серверів на статичному VLAN. Потім компанія модернізувалася.

У новому VPC «внутрішнє» включало вузли Kubernetes, раннери збірки, jump‑box‑и і VPN‑клієнтів підрядників, що заходили в одну велику адресу. Ніхто не мав повної карти в голові. Конфіг Postfix робив те, що завжди робив: permit_mynetworks для ретрансляції, з mynetworks, встановленим на великий RFC1918 діапазон.

Перший сигнал був не від скарг на спам. Це були алерти на диск. Черга швидко збільшилася до меж, що спричинили пороги файлової системи. Інженер на чергуванні побачив багато вихідних доставок до безкоштовних веб‑поштових доменів. Спочатку вони думали, що «утечка облікових даних» на порту submission.

Поворот виявився простішим: автентифікації не було. Скомпрометований CI‑раннер у VPC підключався до порту 25 і ретрансльовував, бо він підпадав під mynetworks. Раннер був короткоживучим, тому IP швидко мінявся і блокування виглядало як whack‑a‑mole.

Виправлення було нудним та рішучим: прибрали широкий RFC1918‑довіру, вимагали автентифікації для виходу і обмежили доступ до порту 25 лише для вхідного шлюзу. Також додали зовнішній swaks‑тест як частину валідації після змін. Ключове речення у звіті про інцидент: «Ми сприймали місце в мережі як ідентичність». Таке припущення колись було поширеним. Нині воно дороге.

Міні‑історія 2: Оптимізація, яка обернулася проти

Інша компанія використовувала Postfix як комбайн вхідного MX і вихідного ретранслятора для внутрішніх додатків. Вони оптимізували під продуктивність, бо маркетингові кампанії створювали величезні піки вихідної пошти. Хотіли менше «SMTP rejects» в логах, бо хтось помилково сприймав їх як помилки.

Тому інженер «оптимізував» шляхом послаблення обмежень і переніс перевірки пізніше в SMTP‑розмову. Ідея: швидко прийняти повідомлення, поставити в чергу, а потім вирішити, що з ним робити. Вони також дозволили більший внутрішній CIDR у mynetworks, щоб уникнути помилок автентифікації з дивних підмереж.

Ця зміна зменшила відхилення на етапі RCPT. Вона також підвищила вартість сказати «ні». Коли зловживання почалося — викликане скомпрометованим хостом у довіреній підмережі — Postfix прийняв дані повідомлення і поставив у чергу перш ніж політика відхилила його вниз по ланцюжку. CPU зріс. Дискова активність зросла. Затримки зросли. MTA став рушієм DoS проти самого себе.

Потім впала доставлюваність, бо система витрачала ресурси на обробку сміття. Легітимна вихідна пошта приходила з затримкою, що спричинило збої у потоках скидання паролів. Бізнес‑наслідок виглядав як збій автентифікації, поки хтось не перевірив глибину черги.

Вони відкотили зміни до раннього відхилення на RCPT і затягнули межі довіри. Продуктивність покращилася, бо відхиляти раніше дешевше, ніж приймати спам. Урок: «менше шуму в логах» — не ціль оптимізації. Це марна метрика з інцидентом у комплекті.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Команда фінансових послуг запускала Postfix для внутрішніх систем і використовувала окремий зовнішній шлюз безпеки для інтернет‑пошти. Їхня конфігурація не була хитрою; вона була явною. Порт 25 був у фаєрволі і приймав з’єднання лише з IP шлюзу. Порт 587 вимагав TLS і SASL і був обмежений діапазонами офісу/VPN.

У них також був маленький рукопис: після будь‑якої зміни запускати два swaks‑тести з зовнішнього probe‑хоста — один до локального одержувача (повинен пройти), другий до зовнішнього одержувача (повинен відхилитися з relay denied). Виводи приєднувалися до тікету зміни. Аудиторам це подобалося, але ще важливіше — операторам: політика пошти стала доказом.

Одного дня зміна в мережі випадково розширила доступ до порту 25 з усього інтернету. Це не було навмисно; це був неправильно застосований шаблон групи безпеки. Моніторинг помітив нові патерни з’єднань одразу, але більша порятунок був у рукописі: наступна рутинна зміна включала swaks‑крок, який провалив тест «має відхилити ретрансляцію», бо ще один пов’язаний дрейф конфігурації послабив обмеження.

Вони виправили це до того, як зловживання розгорнулося. Ніяких драм з блок‑листами, ніякої імплозії черги, ніяких сердитих дзвінків постачальникам. Практика не була гламурною. Це був чекліст і доказ. У продакшні нудне — це функція.

Типові помилки: симптом → корінь проблеми → виправлення

Цей розділ має скоротити ваш час на інцидент. Знайдіть свій симптом, припиніть гадати і застосуйте конкретне виправлення.

1) Симптом: зовнішній swaks‑тест успішно ретранслює до Gmail/Yahoo

Корінь проблеми: Відсутній або неправильно розміщений reject_unauth_destination/defer_unauth_destination в обмеженнях ретрансляції/одержувача.
Виправлення: Встановіть smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination (або reject). Перезавантажте і протестуйте зовні.

2) Симптом: «Relay access denied» для ваших доменів

Корінь проблеми: Ваш домен не вважається локальним (неправильний mydestination, відсутній віртуальний домен, неправильні transport maps).
Виправлення: Визначте хостовані домени правильно (віртуальні домени або mydestination). Не «виправляйте» це шляхом широкого дозволу ретрансляції.

3) Симптом: Працює всередині, не працює для мобільних користувачів

Корінь проблеми: Користувачі покладаються на IP‑довіру (mynetworks) замість автентифікації submission; VPN/офісні IP не включені.
Виправлення: Налаштуйте submission (587) з TLS + SASL; повідомте клієнтам використовувати його. Перестаньте розширювати mynetworks у пошуках роумінгу.

4) Симптом: Черга росте, диск заповнюється, логи показують багато вихідних доставок

Корінь проблеми: Відкритий ретранслятор або скомпрометований автентифікований відправник; відхилення відбувається занадто пізно; немає ліміту швидкості.
Виправлення: Доведіть поведінку ретрансляції зовні, посильте обмеження ретрансляції, блокуйте зловмисні джерела та розгляньте policyd/обмеження швидкості. Очищайте спам після оцінки масштабу.

5) Симптом: Кожен клієнт виглядає в логах як одна і та ж IP‑адреса

Корінь проблеми: SMTP стоїть за проксі/балансувальником без правильного збереження реального IP; Postfix довіряє IP проксі.
Виправлення: Використовуйте дизайн, що зберігає IP клієнта (proxy protocol якщо підтримується) або не покладайтеся на mynetworks для довіри. Обмежуйте на мережевому краю.

6) Симптом: Порт submission дозволяє відправку без автентифікації

Корінь проблеми: Неправильна секція master.cf для submission; відсутній smtpd_sasl_auth_enable=yes або надто дозволяючі обмеження одержувача.
Виправлення: Вимагайте автентифікацію і відхиляйте інакше на submission. Перевірте swaks з неправильним паролем і без автентифікації.

7) Симптом: Деякі внутрішні хости можуть ретранслювати, інші не можуть, і ніхто не знає чому

Корінь проблеми: Непослідовна маршрутизація/NAT або перекриваючі CIDR; невідповідність mynetworks; кілька екземплярів Postfix з різною конфігурацією.
Виправлення: Ідентифікуйте справжні IP джерел, звужуйте списки довіри, стандартизуйте конфіг через CM, і додавайте зовнішні доказові тести.

Чеклісти / поетапний план

Чекліст A: «Чи ми відкритий ретранслятор?» (15 хвилин, на підставі доказів)

З зовнішнього хоста запустіть swaks до стороннього одержувача. Очікуйте Relay access denied.
З того ж зовнішнього хоста запустіть swaks до локального одержувача. Очікуйте 250 Ok і прийом DATA.
На Postfix‑хості захопіть postconf -n і підтвердіть, що smtpd_relay_restrictions включає відхилення для не‑автентифікованих призначень.
Перевірте логи пошти на останні відмови ретрансляції та будь‑які підозрілі успішні ретрансляції.
Додайте вивід swaks + релевантні рядки логів до вашого тікету/запису зміни.

Чекліст B: Безпечне закриття відкритого ретранслятора (резім інциденту)

Ізоляція: Негайно виправте обмеження ретрансляції; якщо трафік надмірний, блокуйте зловмисні джерела на фаєрволі.
Збережіть докази: Збережіть витяги логів і кілька заголовків повідомлень (postcat -q) для підтвердження походження.
Перевірте зовні: Повторіть зовнішній swaks‑тест, поки він не відхилить ретрансляцію.
Тріаж черги: Перегляньте чергу; визначте, чи пошта легітимна або спам.
Очищення: Видаліть спам з черги після підтвердження масштабу; уникайте видалення легітимної пошти.
Відновлення доставлюваності: Якщо ви в блок‑листі — координуйте делістинг і комунікуйте зі стейкхолдерами.
Запобігання рецидиву: Зменшіть mynetworks, вимагайте submission‑автентифікацію і додайте регулярний доказовий тест.

Чекліст C: Загартування, яке можна стандартизувати

Обмежте експозицію порту 25 лише тим, що потрібно (MX‑трафік або IP шлюзів).
Вимагайте TLS + SASL на порті 587. Не робіть 587 зручною доріжкою для ретрансляції.
Зробіть mynetworks маленьким і рецензованим, як правила фаєрволу.
Відхиляйте раніше на етапі RCPT. Не приймайте DATA, якщо не маєте наміру його обробити.
Додайте моніторинг для глибини черги, кількості deferred і незвичного вихідного обсягу.

Часті питання (FAQ)

1) Як однозначно довести, що Postfix не є відкритим ретранслятором?

Запустіть SMTP‑транзакцію з зовнішнього, не‑довіреного хоста до домену третьої сторони. Якщо RCPT відхилено з «Relay access denied», у вас є доказ. Збережіть вивід.

2) Чому тестування з localhost недостатнє?

Бо localhost зазвичай довірений через mynetworks. Ретранслятор, який широко відкритий в інтернеті, може виглядати «безпечним», коли тестувати з 127.0.0.1.

3) У чому різниця між `smtpd_recipient_restrictions` і `smtpd_relay_restrictions`?

smtpd_relay_restrictions — сучасне місце для прийняття рішень щодо ретрансляції. smtpd_recipient_restrictions контролює прийом одержувачів загалом. Неправильне розміщення правил може послабити контроль ретрансляції.

4) Використовувати `reject_unauth_destination` чи `defer_unauth_destination`?

Обидва запобігають відкритому ретранслятору. reject одразу і чітко відмовляє. defer може бути застосований у деяких політичних потоках, але для загартування легше мислити з reject.

5) Чи можна покладатися лише на `mynetworks` для внутрішніх додатків?

Можна, але, ймовірно, не варто. «Внутрішні» мережі часто розростаються і стають пористими. Віддавайте перевагу автентифікованій submission для додатків; якщо мусите використовувати IP‑довіру — ізолюйте її.

6) Якщо порт 25 заблокований для світу, чи можна ігнорувати ризик відкритого ретранслятора?

Ні. Якщо будь‑яка недовірена мережа може дістатися до 25 (включно з VPN, пірингом VPC або неправильно налаштованими групами безпеки), вас все одно можуть зловживати. Також конфіг‑дріфт буває; доказові тести це виявляють.

7) Чому ми потрапили в блок‑лист, якщо швидко закрили ретранслятор?

Блок‑лісти реагують на спостережуваний обсяг спаму і поведінку, і репутація відстає від реальності. Усунення ретрансляції зупиняє кровотечу; делістинг і відновлення репутації займають час.

8) Як відрізнити «відкритий ретранслятор» від «скомпрометованої скриньки, що надсилає спам»?

Спам від відкритого ретранслятора походить від неавтентифікованих з’єднань (зазвичай порт 25) і багатьох IP‑адрес. Скомпрометовані акаунти зазвичай показують SASL‑автентифіковані відправлення на 587 від конкретних ідентичностей і меншої кількості IP.

9) Чи захистить від відкритого ретранслятора включення TLS?

Ні. TLS шифрує з’єднання; він не визначає, кому дозволено ретранслювати. Вам все одно потрібні обмеження ретрансляції і/або автентифікація.

10) Яка найменш ризикована мінімальна конфігурація?

На порті 25: приймайте пошту лише для доменів, які ви хостите; відхиляйте неавторизовану ретрансляцію. На порті 587: вимагайте TLS і SASL; дозволяйте автентифіковану вихідну пошту.

Наступні кроки, які слід зробити

Не чекайте листа про блок‑лист, щоб дізнатися, чи ви відкритий ретранслятор. Зробіть це рутинним доказом.

Запустіть зовнішній swaks‑тест сьогодні (Завдання 6). Збережіть вивід у місці, доступному аудиторам і майбутньому вам.
Перегляньте postconf -n і підтвердіть, що smtpd_relay_restrictions закінчується відхиленням для неавтентифікованих призначень.
Зменшіть mynetworks до того, що ви зможете захистити на зборах. Loopback — хороша відправна точка.
Зробіть submission (587) офіційним шляхом виходу з TLS + SASL і припиніть вирішувати проблеми автентифікації CIDR‑ами.
Додайте одну панель моніторингу: розмір черги, кількість deferred і вихідний обсяг. Це часто помічає «пошту дивною» раніше за користувачів.
Перетворіть доказ у процес: кожна зміна, що стосується пошти, включає два swaks‑тести (локальний accept, зовнішній relay deny). Приєднуйте докази. Повторюйте вічно.

Схожі статті

Port 25 заблоковано: як усе одно відправляти пошту (без сумнівних хаків) Електронна пошта: Пошта переповнена — як запобігти та відновитися без втрат