Налаштування обмежень SMTP в Postfix

1. Вступ
2. Управління пересиланням (relay), блокування спам-а (junk mail), політики для окремих користувачів (per-user policies)
3. Обмеження, які впливають на всю SMTP пошту
4. Списки обмежень для окремих етапів SMTP з'єднання
5. Відкладене обробка списків управління доступом до SMTP
6. Небезпечне використання smtpd_recipient_restrictions
7. Тестування правил доступу до SMTP

Наша взаимовыгодная связь https://banwar.org/

головна - статті - Пошта - Postfix + Dovecot + MySQL

Теги: Поштовий сервер захист пошти

джерело: carantin2006.narod.ru

Вступ

Сервер Postfix SMTP приймає пошту з мережі і схильний до дії з боку спамерів і вірусів. Даний документ описує вбудовані і зовнішні методи Postfix, які вказують, яку SMTP пошту він повинен приймати. Також ви дізнаєтеся, яких помилок слід уникати і як тестувати свою конфігурацію.

Теми, охоплені в документі:

Управління пересиланням (relay), блокування спам-а (junk mail), політики для окремих користувачів (per-user policies)

У далекому минулому Інтернет вдавав із себе дружнє середовище. Поштові сервера без обмежень пересилали пошту від кого завгодно кому завгодно. Сьогодні спамери створюють проблеми для серверів, які пересилають пошту від довільних клієнтів (т.зв. open relay сервера), так як надалі ці сервера можуть бути додані в антиспамерські чорні списки (anti-spammer blacklists).

За замовчуванням, Postfix використовує помірно строгий підхід до пересилання пошти. Postfix пересилає пошту тільки від клієнтів з дружніх мереж (trusted networks) або для доменів, пересилання пошти яким дозволена явно. Для ознайомлення з поведінкою Postfix за замовчуванням читайте опис параметра smtpd_recipient_restrictions , А також документацію, на яку посилається вказане опис.

Більшість можливостей по управлінню доступом до SMTP сервера Postfix спрямовані на боротьбу зі спамом.

• З орієнтацією на протокол. Деякі засоби управління доступом до сервера SMTP блокують пошту від клієнтів, які нестрого дотримуються протоколу SMTP. Таким чином, блокуються погано реалізовані і / або погано налаштовані спамерські програми, так само як і поштові черв'яки, які користуються власною нестандартною реалізацією SMTP клієнта. Засоби контролю, орієнтовані на протокол, втрачають ефективність з часом, так як спамери і автори вірусів вчаться читати документи RFC.

• Орієнтовані на чорні списки. Деякі засоби управління доступом до SMTP сервера опитують чорні списки (blacklists), в яких зберігається інформація про "поганих" сайтах таких, як відкриті релеі (open mail relays), відкриті WEB-проксі сервера, скомпрометовані домашні комп'ютери, які віддалено керовані криміналітетом. Ефективність чорних списків залежить від їх повноти та актуальності (сучасності) інформації (up to date).

• Орієнтація на підвищення вимог. Деякі засоби управління доступом до SMTP сервера дозволяють підняти планку вимог для клієнта, або змушуючи клієнта виконувати більше роботи (greylisting, сірі списки), або проводячи додаткові перевірки (SPF [Sender Policy Framework] і перевірку адрес відправника / одержувача). Сірі списки і політики SPF реалізовані поза Postfix і є темою документа SMTPD_POLICY_README . Перевірка адрес відправника / одержувача описана в документі ADDRESS_VERIFICATION_README .

На жаль, всі засоби боротьби зі спамом можуть помилятися, відкидаючи легітимні листи. Це може бути серйозною проблемою для сервера, який займається обробкою пошту для великої кількості користувачів. Для одних користувачів неприйнятно отримання хоч одного листа спаму, в той час як для інших одне помилково відкинуте легітимне повідомлення може обернутися трагедією. Так як немає певної політики, яка б удовлітворяла побажанням усіх без винятку користувачів, Postfix підтримує різні обмеження щодо доступу до SMTP сервера для різних користувачів. Ця можливість описана в документі RESTRICTION_CLASS_README .

Обмеження, які впливають на всю SMTP пошту

Крім обмежень, які можуть бути налаштовані для окремих клієнтів або користувачів, в Postfix реалізовані кілька обмежень, які впливають на всю SMTP пошту.

• Вбудовані обмеження по вмісту header_checks (Перевірки заголовка) і body_checks (Перевірки вмісту листа), які описані в документі BUILTIN_FILTER_README . Ці перевірки проводяться під час прийому пошти, до приміщення листи в чергу вхідних повідомлень ( incoming queue ).

• Зовнішня (за допомогою сторонніх програм) перевірка вмісту до приміщення в чергу, яка описана в документі SMTPD_PROXY_README . Ця перевірка виконується під час прийому пошти, до приміщення листи в чергу вхідних повідомлень ( incoming queue ).

• Вимога до клієнтів відсилати команду HELO або EHLO перед використанням команди MAIL FROM або ETRN. Це може викликати проблеми при роботі з "доморощеними" поштовими клієнтами. З цієї причини обмеження відключено за замовчуванням ( " smtpd_helo_required = No ").

• Заборона некоректного синтаксису в командах MAIL FROM або RCPT TO. Це може викликати проблеми при роботі з "доморощеними" або древніми поштовими клієнтами. З цієї причини вимога відключено за замовчуванням ( " strict_rfc821_envelopes = No ").

• Заборона використання синтаксису адрес RFC 822 (Приклад: "MAIL FROM: the dude <[email protected]>").

• Заборона використання адрес, які не укладені в кутові дужки <> (приклад: "MAIL FROM: [email protected]").

• Відхилення листів з неіснуючим адресою відправника. Ця форма фільтрації "на вході" може допомогти в боротьбі з "хробаками" і спамерами, але може викликати проблеми при роботі з "доморощеними" поштовими клієнтами, які відсилають листи з неіснуючим адресою відправника. З цієї причини даної обмеження відключено за замовчуванням ( " smtpd_reject_unlisted_sender = No ").

• Відхилення листів з неіснуючим адресою одержувача. Ця форма фільтрації "на вході" допомагає утримувати поштову чергу вільної від повідомлень MAILER-DAEMON, які не можуть бути доставлені. Це обмеження включено за замовчуванням ( " smtpd_reject_unlisted_recipient = Yes ").

Списки обмежень для окремих етапів SMTP з'єднання

Postfix дозволяє задавати списки обмежень для кожного етапу SMTP діалогу. Окремі обмеження описані на сторінці документації postconf (5) .

Приклади простих списків обмежень:

/etc/postfix/main.cf: # Дозволити з'єднання тільки від дружніх (trusted) мереж. smtpd_client_restrictions = permit_mynetworks , Reject # Чи не спілкуватися з поштовими системами, які не знають імені свого хоста. smtpd_helo_restrictions = reject_unknown_hostname # Не приймати пошту від доменів, які не існують. smtpd_sender_restrictions = reject_unknown_sender_domain # "Білі" списки. Локальні клієнти можуть вказувати будь-якого одержувача. Інші клієнти не можуть. smtpd_recipient_restrictions = permit_mynetworks , reject_unauth_destination # Блокувати клієнтів, які починають спілкуватися рано. smtpd_data_restrictions = reject_unauth_pipelining # Перевіряти квоти на обсяг пошти, звертаючись до зовнішніх сервісів. smtpd_end_of_data_restrictions = check_policy_service unix: private / policy

Кожен список обмежень обробляється зліва направо до тих пір, поки будь-яке обмеження не видасть результат PERMIT (дозволити), REJECT (відхилити) або DEFER (відкласти для подальшої повторної спроби). Досягнення кінця списку еквівалентно отриманню результату PERMIT. Вказуючи обмеження PERMIT перед обмеженням REJECT, ви можете робити виняток для певних клієнтів або користувачів (т.зв. білі списки, whitelisting). Приклад нижче дозволяє відправляти пошту локальним клієнтам, але іншим клієнтам відсилання пошти для довільних одержувачів заборонена.

# "Білі" списки. Локальні клієнти можуть вказувати будь-якого одержувача. Інші клієнти не можуть. smtpd_recipient_restrictions = permit_mynetworks , reject_unauth_destination

Нижче показана таблиця, яка пояснює призначення всіх списків обмежень доступу до SMTP. Синтаксис написання списків однаковий, вони відрізняються лише часом застосування і ефектом, який породжують результати REJECT або DEFER.

Відкладене обробка списків управління доступом до SMTP

Ранні версії Postfix виконували дії, передбачені списками обмежень доступу до SMTP, настільки рано, наскільки це можливо. Список обмеження клієнтів (client restriction list) перевірявся перед тим, як Postfix відсилав вітання "220 $ myhostname ... "SMTP клієнту. Список smtpd_helo_restrictions оброблявся перед тим, як Postfix відповідав на команду HELO (EHLO). список smtpd_sender_restrictions оброблявся перед відповіддю на команду MAIL FROM. І так далі. Ця практика була дуже складною в застосуванні.

Поточні версії Postfix відкладають обробку списків обмеження для клієнтів, відправників і HELO до отримання команди RCPT TO або ETRN. Це поведінка контролюється параметром smtpd_delay_reject . Списки обмежень обробляються в правильному порядку (client, helo, etrn) або (client, helo, sender, recipient, data, end-of-data). Коли список обмежень (наприклад, client) видає результат REJECT або DEFER, обробка наступних списків (приклад: helo, sender, і т.д.) не виконується.

У той час як був доданий параметр smtpd_delay_reject , В Postfix також була введена підтримка змішаних списків обмежень, які комбінують інформацію про клієнта, відправника, одержувача та інформацію команд helo, etrn.

Переваги відкладеної обробки списків обмежень і змішаних списків:

• Деякі SMTP клієнти не очікують негативних відповідей на ранніх етапах SMTP сесії. Коли погані новини відкладаються до відповіді на RCPT TO, клієнт йде, що і потрібно, а не висить до розриву з'єднання по таймаут, або, гірше того, входить в нескінченний цикл з'єднання-відмова-з'єднання.

• Postfix може реєструвати більше корисної інформації. Наприклад, коли Postfix відхиляє ім'я або адреса клієнта і чекає команди RCPT TO, він отримує інформацію про адресу відправника і одержувача. Це корисніше, ніж реєстрація імені хоста і IP адреси клієнта укупі з повним незнанням того, чия пошта була заблокована.

• Змішування необхідно для реалізації комплексних політик "білих списків". Наприклад, щоб відхилити локальні адреси відправників в повідомленнях від нелокальних клієнтів, вам необхідно скористатися інформацією про клієнта та адресу відправника в одному і тому ж списку управління доступом. Без цієї можливості багато подібні обмеження для окремих користувачів неможливо описати.

Небезпечне використання smtpd_recipient_restrictions

Тепер читач може запитати, навіщо потрібні списки обмежень client, helo або sender, якщо їх обробка відкладається до команди RCPT TO або ETRN. Деякі люди рекомендують поміщати ВСЕ обмеження в список smtpd_recipient_restrictions . На жаль, це може привести до дуже довірливому поведінки SMTP сервера Postfix. Як це можливо?

мета списку smtpd_recipient_restrictions - це управління тим, як Postfix відповідає на команду RCPT TO. Якщо список обмеження видає результат REJECT або DEFER, то адреса одержувача відхиляється, що і потрібно. Якщо результат - PERMIT, то адреса одержувача приймається. І тут слід чекати сюрпризів.

Ось приклад, який ілюструє вищезгадану ситуацію:

1 /etc/postfix/main.cf: 2 smtpd_recipient_restrictions = 3 permit_mynetworks 4 check_helo_access hash: / etc / postfix / helo_access 5 reject_unknown_hostname 6 reject_unauth_destination 7 8 / etc / postfix / helo_access: 9 localhost.localdomain PERMIT

У 5-му рядку відхиляється пошта від всіх клієнтів, які не вказують правильне ім'я хоста в команді HELO. У рядках 4-ої і 9-ої зроблено виняток для деякого клієнта, який представляється, як "HELO localhost.localdomain".

Проблема цієї конфігурації в тому, що список smtpd_recipient_restrictions видає результат PERMIT для БУДЬ-ЯКОГО хоста, який анонсує себе, як "localhost.localdomain". В результаті, Postfix стає відкритим релеем (open relay) для всіх таких машин.

Щоб уникнути подібних непорозумінь зі списком smtpd_recipient_restrictions , Вам слід поміщати обмеження, не пов'язані з адресою одержувача (non-recipient restrictions), ПІСЛЯ обмеження reject_unauth_destination , А не до нього. В наведеному вище прикладі обмеження для HELO має бути розміщено ПІСЛЯ reject_unauth_destination , Або, ще краще, помістити обмеження HELO в список smtpd_helo_restrictions , Де воно не викличе проблем.

Тестування правил доступу до SMTP

У Postfix є кілька можливостей, які допомагають тестувати правила доступу до SMTP:

• soft_bounce

  Це засіб замінює дії SMTP сервера REJECT на DEFER (спробувати пізніше). Це дозволяє залишати повідомлення в черзі, які в іншому випадку були б повернуті відправнику. вкажіть " soft_bounce = Yes "в файлі main.cf, щоб запобігти постійне відхилення пошти SMTP сервером Postfix. З цією метою Postfix замінить всі коди відповідей 5xx на 4xx.

• warn_if_reject

  Ця можливість дозволяє замінити дії SMTP сервірують REJRCT на зауваження (warnings). Замість відхилення команди клієнта Postfix реєструє, що він збирався відкинути. вкажіть " warn_if_reject "В списку обмежень доступу до SMTP перед тим обмеженням, яке ви хочете протестувати без реального відхилення пошти.

• XCLIENT

  Завдяки цій можливості (Postfix 2.1 і наступні версії) авторизовані SMTP клієнти можуть імітувати інші системи, таким чином ви можете проводити ралистичности тести правил доступу до SMTP сервера Postfix. Приклади використання XCLIENT для тестування правил доступу містяться в документі XCLIENT_README .

Авторизуйтесь для додавання коментарів!