Конфігурація Postfix, залежна від напруги

Огляд

Теми, розглянуті в цьому документі:

• Ознаки перевантаження SMTP-сервера Postfix
• Автоматична поведінка адаптації до напруги
• Обслуговування більше клієнтів SMTP одночасно
• Витрачайте менше часу на клієнта SMTP
• Від'єднайте підозрілих клієнтів SMTP
• Тимчасові заходи для старіших випусків Postfix
• Виявлення підтримки поведінки адаптації до напруги
• Примусове ввімкнення або вимкнення поведінки адаптації до напруги
• Інші заходи для розвантаження зомбі
• Кредити

Ознаки перевантаження SMTP-сервера Postfix

За звичайних умов SMTP-сервер Postfix негайно відповідає, коли до нього під'єднується клієнт SMTP; час доставки пошти помітний лише для великих повідомлень. Продуктивність різко знижується, коли кількість SMTP-клієнтів перевищує кількість процесів SMTP-сервера Postfix. Коли клієнт SMTP під'єднується в той час, як всі процеси сервера Postfix SMTP зайняті, клієнт повинен зачекати, доки процес сервера стане доступним.

Перевантаження SMTP-сервера може бути спричинене різким збільшенням легітимної пошти (приклад: реєстратор DNS відкриває нову зону для реєстрації), помилкової (вибух електронної пошти, спричинений циклом пересилання) або зі злого наміру (спалах хробака, ботнет або інша незаконна діяльність).

Ознаки перевантаження SMTP-сервера Postfix:

• Віддалені клієнти SMTP відчувають тривалу затримку, перш ніж Postfix надішле привітання "220 hostname.example.com ESMTP Postfix".

       ПРИМІТКА. Несправні конфігурації DNS також можуть спричинити тривалі             затримки, перш ніж Postfix надішле «220 hostname.example.com ...». Ці затримки   також існують, коли Postfix НЕ перевантажений.

     ПРИМІТКА. Щоб уникнути затримок із «перевантаженням» для кінцевих поштових користувачів, активуйте функцію «submission» («підтвердження») у master.cf (яка існує починаючи з Postfix 2.1) і повідомте користувачів, щоб вони під'єдналися до неї замість загальнодоступної служби SMTP.

• SMTP-сервер Postfix реєструє збільшену кількість подій «втрачене з’єднання після CONNECT(під’єднатися)». Це відбувається тому, що віддалені клієнти SMTP від'єднуються ще до того, як Postfix відповість на під'єднання.

     ПРИМІТКА. Сканування портів для відкритих портів SMTP також може призвести до повідомлень у файлі журналу «втрачено з’єднання…».

• Postfix 2.3 і пізніші версії реєструють попередження про те, що всі порти сервера зайняті:

Oct  3 20:39:27 spike postfix/master[28905]: warning: service "smtp"

 (25) has reached its process limit "30": new clients may experience

 noticeable delays

Oct  3 20:39:27 spike postfix/master[28905]: warning: to avoid this

 condition, increase the process count in master.cf or reduce the

 service time per client

Oct  3 20:39:27 spike postfix/master[28905]: warning: see

  http://www.postfix.org/STRESS_README.html for examples of

  stress-adapting configuration settings

(3 жовтня 20:39:27 spike postfix/master[28905]: попередження: служба "smtp"

 (25) досягнула обмеження процесу "30": нові клієнти можуть відчути

 помітні затримки

3 жовтня 20:39:27 spike postfix/master[28905]: попередження: щоб уникнути цієї

 ситуації, збільште кількість процесів у master.cf або зменште

 час обслуговування на одного клієнта

3 жовтня 20:39:27 spike postfix/master[28905]: попередження: див.

  http://www.postfix.org/STRESS_README.html для прикладів

  параметри конфігурації, які адаптуються до напруги)

Легітимна пошта, яка не проходить під час періоду перевантаження сервера SMTP Postfix, не обов’язково втрачається. Вона все одно має надійти, коли ситуація повернеться до нормального стану, якщо стан перевантаження є тимчасовим.

Автоматична поведінка адаптації до напруги

Postfix версії 2.5 вводить автоматичну поведінку адаптації до напруги. Вона працює наступним чином. Коли «загальнодоступна» мережева служба, така як сервер SMTP, потрапляє в стан «усі порти сервера зайняті», демон Postfix master(8) реєструє попередження, перезапускає службу (без переривання наявних мережевих сеансів) і запускає службу з "-o stress=yes" у командному рядку процесу сервера:

     80821  ??  S      0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes

Зазвичай демон Postfix master(8) запускає таку службу з "-o stress=" у командному рядку (тобто з порожнім значенням параметра):

     83326  ??  S      0:00.28 smtpd -n smtp -t inet -u -c -o stress=

Ви не побачите параметри командного рядка "-o stress" у службах, які мають лише локальні клієнти. До них належать внутрішні служби Postfix, такі як диспетчер черги, і служби, які прослуховують лише інтерфейс петлі, наприклад служби SMTP після фільтрації.

Значення параметра «stress» є ключовим для того, щоб зробити налаштування параметра main.cf адаптивним до напруги. Наступні параметри є типовими для Postfix 2.6 і пізніших версій.

     1 smtpd_timeout = ${stress?{10}:{300}}s

     2 smtpd_hard_error_limit = ${stress?{1}:{20}}

     3 smtpd_junk_command_limit = ${stress?{1}:{100}}

     4 # Parameters added after Postfix 2.6:

     5 smtpd_per_record_deadline = ${stress?{yes}:{no}}

     6 smtpd_starttls_timeout = ${stress?{10}:{300}}s

     7 address_verify_poll_count = ${stress?{1}:{3}}

У версіях Postfix до версії 3.0 використовується старіша форма ${stress?x}${stress:y} замість нової форми ${stress?{x}:{y}}.

Синтаксис ${name?{value}:{value}}, ${name?value} і ${name:value} пояснюється на початку сторінки посібника postconf(5).

Переклад:

• Рядок 1: в умовах напруги використовуйте значення smtpd_timeout 10 секунд замість 300 секунд за замовчуванням. Досвід роботи зі списком postfix-users від різних системних адміністраторів показує, що скорочення «нормального» smtpd_timeout до 60 с навряд чи вплине на легітимних клієнтів. Однак навряд чи воно стане стандартним для Postfix, оскільки він не сумісний з RFC. Встановлення smtpd_timeout на 10 або навіть 5 секунд під напругою все одно дозволить більшості легітимних клієнтів під'єднатися та надіслати пошту, але може затримати пошту від деяких клієнтів. Жодна пошта не повинна бути втрачена, якщо цей захід використовується лише тимчасово.

• Рядок 2: в умовах напруги використовуйте smtpd_hard_error_limit 1 замість 20 за замовчуванням. Вона від'єднує клієнтів після однієї помилки, даючи іншим клієнтам можливість під'єднатися. Однак це може спричинити значні затримки з легітимною поштою, як-от список розсилки, який містить кілька неактивних імен користувачів, які не потрудилися скасувати підписку. Жодна пошта не повинна бути втрачена, якщо цей захід використовується лише тимчасово.

• Рядок 3: в умовах напруги використовуйте smtpd_junk_command_limit 1 замість стандартного значення 100. Це не дозволяє клієнтам підтримувати з’єднання відкритими шляхом повторного надсилання команд HELO, EHLO, NOOP, RSET, VRFY або ETRN.

• Рядок 5: в умовах напруги змініть поведінку smtpd_timeout і smtpd_starttls_timeout з обмеження часу для системного виклику читання чи запису на обмеження часу для надсилання чи отримання повного запису (командний рядок SMTP, рядок відповіді SMTP, рядок, що містить вміст повідомлення SMTP або повідомлення протоколу TLS).

• Рядок 6: в умовах напруги зменште ліміт часу для повідомлень про рукостискання протоколу TLS до 10 секунд зі значення за замовчуванням у 300 секунд. Дивіться також обговорення smtpd_timeout вище. 

• Рядок 7: в умовах напруги не чекайте до 6 секунд для завершення перевірки адреси. Якщо результату ще немає в кеші перевірки адреси, негайно надішліть відповідь $unverified_recipient_tempfail_action або $unverified_sender_tempfail_action. Жодна пошта не повинна бути втрачена, якщо цей захід використовується лише тимчасово.

ПРИМІТКА. Будь ласка, майте на увазі, що функція адаптації до напруги є досить відчайдушним заходом для забезпечення надходження деякої легітимної пошти в умовах перевантаження. Якщо сайт досягає ліміту процесів SMTP-сервера, коли немає атаки чи флуд бота, тоді потрібно або збільшити ліміт процесу, або додати більше обладнання.

Обслуговування більше клієнтів SMTP одночасно

У цьому та наступних розділах розглядаються постійні заходи проти перевантаження поштового сервера.

Одним із заходів, щоб уникнути стану «всі серверні процеси зайняті», є одночасне обслуговування більшої кількості клієнтів SMTP. Для цього вам потрібно збільшити кількість процесів SMTP-сервера Postfix. Це підвищить швидкість реагування віддалених клієнтів SMTP, якщо серверна машина має достатньо апаратних і програмних ресурсів для запуску додаткових процесів і поки файлова система може витримати додаткове навантаження.

• Ви збільшуєте кількість процесів SMTP-сервера, збільшуючи default_process_limit у main.cf (рядок 3 нижче), або шляхом збільшення поля "maxproc" сервера SMTP у master.cf (рядок 10 нижче). У будь-якому випадку, вам потрібно виконати команду "postfix reload", щоб зробити зміни ефективними.

• Ліміти процесів понад 1000 вимагають Postfix версії 2.4 або новішої та операційної системи, яка підтримує фільтри подій на основі ядра (BSD kqueue(2), Linux epoll(4) або Solaris /dev/poll).

• Більше процесів використовує більше пам’яті. Ви можете зменшити обсяг пам’яті Postfix, використовуючи таблиці пошуку cdb: замість таблиць hash: або btree: Berkeley DB.

 1 /etc/postfix/main.cf:

 2     # Raise the global process limit, 100 since Postfix 2.0.

 3     default_process_limit = 200

 4

 5 /etc/postfix/master.cf:

 6     # ===========================================================

 7     # service type  private unpriv  chroot  wakeup  maxproc command

 8     # ===========================================================

 9     # Raise the SMTP service process limit only.

10     smtp      inet  n       -       n       -       200     smtpd

• ПРИМІТКА: старіші версії документа SMTPD_POLICY_README містять помилку: вони налаштовують фіксовану кількість процесів демона політики. Коли ви підіймете поле "maxproc" сервера SMTP у master.cf, процеси сервера SMTP повідомлять про проблеми під час під'єднання до процесів сервера політики, оскільки їх недостатньо. Приклади помилок: «Відмова у з’єднанні» або «Час очікування операції минув».

Щоб виправити це, відредагуйте master.cf і вкажіть нульове поле "maxproc" у всіх записах сервера політики; дивіться рядок 6 у прикладі нижче. Видайте команду "postfix reload", щоб зробити зміни ефективними.

     1 /etc/postfix/master.cf:

     2     # =============================================================

     3     # service type  private unpriv  chroot  wakeup  maxproc command

     4     # =============================================================

     5     # Disable the policy service process limit.

     6     policy    unix  -       n       n       -       0       spawn

     7         user=nobody argv=/some/where/policy-server

Витрачайте менше часу на клієнта SMTP

Якщо збільшення кількості процесів SMTP-сервера є недоцільним, ви можете покращити швидкість реакції сервера Postfix, усунувши затримки. Коли Postfix витрачає менше часу на сеанс SMTP, така сама кількість процесів сервера SMTP може обслуговувати більше клієнтів за певний проміжок часу.

• Усуньте нефункціональні пошуки RBL (чорні списки, які більше не працюють). Ці пошуки можуть погіршити продуктивність. Postfix записує попередження, коли сервер RBL не відповідає.

• Усуньте надлишкові пошуки RBL (люди часто використовують кілька RBL Spamhaus, які включають один одного). Щоб дізнатися, чи RBL включають інші RBL, знайдіть вебсайти, які документують політику RBL.

• Усуньте header_checks і body_checks і збережіть лише кілька аварійних шаблонів, щоб заблокувати останній спалах хробака або зворотну пошту. Перегляньте BACKSCATTER_README для прикладів останнього.

• Згрупуйте свої шаблони header_checks і body_checks, щоб уникнути непотрібних операцій зіставлення шаблонів:

 1  /etc/postfix/header_checks:

 2      if /^Subject:/

 3      /^Subject: virus found in mail from you/ reject

 4      /^Subject: ..other../ reject

 5      endif

 6 

 7      if /^Received:/

 8      /^Received: from (postfix\.org) / reject forged client name in received header: $1

 9      /^Received: from ..other../ reject ....

10      endif

Від'єднайте  підозрілих клієнтів SMTP

За умов перевантаження ви можете покращити швидкість реагування SMTP-сервера Postfix, від'єднавши підозрілих клієнтів, щоб інші клієнти мали можливість спілкуватися з Postfix.

• Використовуйте коди відповіді SMTP «521» (Postfix 2.6 і новіші версії) або «421» (Postfix 2.3-2.5), щоб від'єднати клієнтів, які відповідають пов’язаним із ботнетом RBL (див. наступний пункт) або ті, для яких вибрано обмеження, не пов’язані із RBL, наприклад карти доступу SMTP. Сервер SMTP Postfix відхилить пошту та від’єднається, не чекаючи, поки віддалений клієнт SMTP надішле команду QUIT.

• Щоб розірвати з’єднання від заборонених зомбі, ви можете встановити спеціальні коди відхилення SMTP-сервера Postfix для певних RBL та для окремих відповідей від певних RBL. Ми використаємо zen.spamhaus.org як приклад; до того часу, як ви прочитаєте цей документ, деталі можуть змінитися. Наразі в їхніх документах сказано, що відповідь 127.0.0.10 або 127.0.0.11 вказує на динамічну IP-адресу клієнта, що означає, що на цьому пристрої, ймовірно, запущено якийсь бот. Щоб дати відповідь 521 замість відповіді 554 за замовчуванням, використовуйте щось на зразок:

      1  /etc/postfix/main.cf:

      2      smtpd_client_restrictions =

      3         permit_mynetworks

      4         reject_rbl_client zen.spamhaus.org=127.0.0.10

      5         reject_rbl_client zen.spamhaus.org=127.0.0.11

      6         reject_rbl_client zen.spamhaus.org

      7 

      8      rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps

      9 

     10  /etc/postfix/rbl_reply_maps:

     11      # With Postfix 2.3-2.5 use "421" to hang up connections.

     12      zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;

     13       $rbl_class [$rbl_what] blocked using

     14       $rbl_domain${rbl_reason?; $rbl_reason}

     15 

     16      zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;

     17       $rbl_class [$rbl_what] blocked using

     18       $rbl_domain${rbl_reason?; $rbl_reason}

Хоча наведений вище приклад демонструє три пошуки RBL (рядки 4-6), Postfix виконає лише один DNS-запит, тому це не впливає на продуктивність.

• Для Postfix 2.3-2.5 використовуйте код відповіді 421 (521 не призведе до від'єднання Postfix). Недоліком відповіді 421 є те, що вона працює лише для зомбі та інших шкідливих програм. Якщо клієнт використовує справжню MTA, він може під'єднатися знову кілька разів, доки не закінчиться термін дії пошти в її черзі. Якщо це проблема, дотримуйтеся стандартної відповіді 554 і використовуйте «smtpd_hard_error_limit = 1», як описано нижче.

• Ви можете автоматично ввімкнути наведений вище показник перевантаження з Postfix 2.5 і пізніших версій або з попередніми випусками, які містять виправлення вихідного коду поведінки адаптації до напруги з дзеркал, перелічених на http://www.postfix.org/download.html. Просто замініть рядок над 8 на:

     8      rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}

Детальніше про автоматичну поведінку адаптації до напруги можна знайти в розділі «Автоматична поведінка адаптації до напруги».

Тимчасові заходи для старіших випусків Postfix

Перегляньте розділ «Автоматична поведінка адаптації до наруги», якщо ви використовуєте Postfix версії 2.5 або пізнішої, або якщо ви застосували патч вихідного коду для поведінки адаптованої до напруги з дзеркал, перелічених на http://www.postfix.org/download .html.

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

• Зменште smtpd_timeout (за замовчуванням: 300 с). Досвід роботи зі списком postfix-users від різних системних адміністраторів показує, що скорочення «нормального» smtpd_timeout до 60 с навряд чи вплине на легітимних клієнтів. Однак навряд чи воно стане стандартним для Postfix, оскільки воно не сумісне з RFC. Встановлення smtpd_timeout на 10 с (рядок 2 нижче) або навіть на 5 с під час напруги все одно дозволить більшості легітимних клієнтів під'єднуватися та надсилати пошту, але може затримувати пошту від деяких клієнтів. Жодна пошта не повинна бути втрачена, якщо цей захід використовується лише тимчасово.

• Зменште smtpd_hard_error_limit (за замовчуванням: 20). Встановлення значення 1 під напругою (рядок 3 нижче) допомагає від'єднувати клієнтів після однієї помилки, даючи іншим клієнтам можливість під'єднатися. Однак це може спричинити значні затримки з легітимною поштою, як-от список розсилки, який містить кілька неактивних імен користувачів, які не потрудилися скасувати підписку. Жодна пошта не повинна бути втрачена, якщо цей захід використовується лише тимчасово.

• Використайте smtpd_junk_command_limit 1 замість 100 за замовчуванням. Це не дозволяє клієнтам зберегти незалучені з’єднання відкритими шляхом повторного надсилання команд NOOP або RSET.

     1  /etc/postfix/main.cf:

     2      smtpd_timeout = 10

     3      smtpd_hard_error_limit = 1

     4      smtpd_junk_command_limit = 1

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

Виявлення підтримки поведінки адаптації до напруги

Щоб дізнатися, чи підтримує ваша інсталяція Postfix поведінку адаптації до напруги, скористайтеся командою «ps» і знайдіть процеси smtpd. Postfix підтримує адаптацію до напруги, коли ви бачите параметри командного рядка "-o stress=" або "-o stress=yes". Пам’ятайте, що Postfix ніколи не вмикає поведінку адаптації до напруги на серверах, які слухають лише локальні адреси.

Наступний приклад для FreeBSD або Linux. У Solaris, HP-UX та інших версіях System-V використовуйте "ps -ef" замість "ps ax".

$ ps ax|grep smtpd

83326  ??  S      0:00.28 smtpd -n smtp -t inet -u -c -o stress=

84345  ??  Ss     0:00.11 /usr/bin/perl /usr/libexec/postfix/smtpd-policy.pl

Ви не можете використовувати postconf(1) для виявлення підтримки адаптації до напруги. Команда postconf(1) ігнорує наявність параметра напруги у main.cf, оскільки параметр там не впливає. Параметри командного рядка "-o parameter" завжди мають пріоритет над параметрами main.cf.

Якщо ви налаштуєте поведінку адаптації до напруги в main.cf, коли вона не підтримується, нічого поганого не станеться. Процеси виконуватимуться так, ніби параметр напруги завжди має порожнє значення.

Примусове ввімкнення або вимкнення поведінки адаптації до напруги

Ви можете вручну ввімкнути поведінку адаптації до напруги, додавши параметр командного рядка "-o stress=yes" у master.cf. Це може бути корисним для перевірки перевизначення в службі SMTP. Виконайте "перезавантаження постфікса", щоб зробити зміни ефективними.

Примітка: встановлення параметра напруги в main.cf не впливає на служби, які приймають віддалені підключення.

     1 /etc/postfix/master.cf:

     2     # =============================================================

     3     # service type  private unpriv  chroot  wakeup  maxproc command

     4     # =============================================================

     5     #

     6     smtp      inet  n       -       n       -       -       smtpd

     7         -o stress=yes

     8         -o . . .

Щоб назавжди вимкнути поведінку адаптації до напруги певної служби, вкажіть "-o stress=" у її командному рядку master.cf. Це може бути бажаним для послуги «підтвердження». Виконайте "перезавантаження постфікса", щоб зробити зміни ефективними.

Примітка: встановлення параметра напруги в main.cf не впливає на служби, які приймають віддалені підключення.

     1 /etc/postfix/master.cf:

     2     # =============================================================

     3     # service type  private unpriv  chroot  wakeup  maxproc command

     4     # =============================================================

     5     #

     6     submission inet n       -       n       -       -       smtpd

     7         -o stress=

     8         -o . . .

Інші заходи для розвантаження зомбі

Демон postscreen(8), представлений у Postfix 2.8, забезпечує додатковий захист від перевантаження поштового сервера. Один процес postscreen(8) обробляє кілька вхідних SMTP-з’єднань і вирішує, які клієнти можуть спілкуватися з процесом SMTP-сервера Postfix. Не допускаючи спам-ботів, postscreen(8) залишає більше процесів SMTP-сервера доступними для легітимних клієнтів і затримує настання умов перевантаження сервера.

Кредити

• Дякуємо членам списку розсилки postfix-users за те, що вони поділилися раннім досвідом роботи з функцією адаптації до напруги.
• Приклад RBL і кілька інших абзаців тексту були адаптовані з публікацій postfix-users Ноеля Джонса.
• Вітсе реалізував поведінку адаптації до напруги як найменший можливий патч, поки він повинен працювати над іншими речами.