З'єднання Postfix втрачено після AUTH

12

Переглядаючи журнали моїх поштових серверів, я помітив такі повідомлення:

Nov 29 12:09:38 mta postfix/smtpd[8362]: connect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: disconnect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8409]: connect from unknown[183.13.165.14]
Nov 29 12:09:40 mta postfix/smtpd[8409]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:40 mta postfix/smtpd[8409]: disconnect from unknown[183.13.165.14]

У цих випадках відмов SASL немає. Є помилки SASL, які реєструються в інший час, але ніколи lost connection after AUTH.

Що тут відбувається, і чи варто мені щось робити?
Це не MX, і вже smtpd_client_connection_rate_limitвстановили.

Можливо, пов'язано:
Системи вимагають або SMTPS, або STARTTLS до оголошення AUTH.

postfix

— 84104
джерело

Чи можете ви підвищити рівень налагодження постфікса?

— Халед

Я можу, але це зробить файли журналів значно більшими темпами, і ці події носять епізодичний характер. Що допоможе розширити цей журнал?

— 84104

1

Отже, вам потрібно збільшити її за невеликий проміжок часу, і коли ви очікуєте отримати цю помилку. Це, сподіваємось, дає більше натяків на те, що означає ця помилка.

— Халед

9

Це ботнет з Китаю, який підключається до вашої скриньки, намагаючись доставити спам. Але бот занадто нерозумний, щоб знати, що робити, коли йому кажуть, щоб підтвердити себе. Бот просто перестає доставляти пошту, а потім відключається для нападу на наступну жертву.

Абсолютно нічого турбуватися.

— mailq
джерело

3

Достатньо близько. Здається, що це якийсь сценарій, який видає AUTH і закривається нечисто після отримання 503 5.5.1 Error: authentication not enabled. Вмів реплікувати з ncat. Хоча чому він продовжує намагатися, поки не досягне межі ставки, - це не в мене. Можливо, він намагається грубо примусити пари імені користувача / пароля? Так чи інакше, занадто дурне занадто хвилюється.

— 84104

2

Як тест, я отримую лише цей рядок у своїх журналах і ніколи не бачу помилок SASL, лише використовуючи Thunderbird та недійсний пароль для відомого облікового запису. Оскільки аутентифікована пошта завжди безперешкодно проходить через Postfix, правильна відповідь, якщо це можливо, використовувати розміщений скрипт fail2ban, щоб мінімізувати кількість спроб грубої сили мінімальним. Спроби з грубою формою пароля - це те, про що потрібно абсолютно непокоїти, щоб уникнути перетворення коробки у відкрите реле - особливо, якщо це єдиний рядок у ваших журналах.

— CubicleSoft

Журнали виглядають так, ніби він отримує одну секунду, а це може бути хтось, хто намагається жорстоко змусити сервер. Я рекомендую використовувати як мінімум fail2ban як мінімум. Це не дозволить повністю вирішити грубу силу, але суттєво пом'якшить її.

— Северун

21

Мої файли журналів заповнювалися, і це марно витрачати процесор, щоб навіть дозволити з'єднання від цих ривків. Я створив fail2banправило.

Jul 11 02:35:08 mail postfix/smtpd[16299]: lost connection after AUTH from unknown[196.12.178.73]

Зміст /etc/fail2ban/jail.conf

[postfix]
# Ban for 10 minutes if it fails 6 times within 10 minutes
enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 6
bantime  = 600
findtime = 600

Зміст /etc/fail2ban/filter.d/postfix.conf

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision$
#

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#

# Jul 11 02:35:08 mail postfix/smtpd[16299]: lost connection after AUTH from unknown[196.12.178.73]

failregex = lost connection after AUTH from unknown\[<HOST>\]

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

— the7erm
джерело

2

Це врятувало мені день. Я додав наступне правило: failregex = ^%(__prefix_line)slost connection after AUTH from \S+\[<HOST>\].$. У мене було кілька сотень таких спроб підключення за кілька хвилин. Мені довелося щось робити.

— chmike

Це трохи більш загальне:failregex = lost connection after AUTH from (.*)\[<HOST>\]

— CubicleSoft

@chmike: крапку перед закінченням $потрібно видалити. Тут не працювали з нею в регулярному виразі.

— cweiske

3

У smtpd_recipient_restrictionsпросто встановити , reject_unknown_client_hostnameяк це:

smtpd_recipient_restrictions = reject_unknown_client_hostname

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

postfix/smtpd[11111]: NOQUEUE: reject: RCPT from unknown[183.13.165.14]: 450 4.7.1 Client host rejected: cannot find your hostname, [183.13.165.14]

— Пане
джерело

На це (дуже старе) питання вже є прийнята відповідь.

— BE77Y

1

Невідоме ім'я хоста було / не проблема. lost connection after AUTHбув / є.

— 84104

1

Їхнє питання - "Що тут відбувається, і чи варто мені щось робити?" І це цілком коректна відповідь.

— inorganik

2

Я не впевнений, чи варто багато про що турбуватися, в основному клієнт / «хтось» підключається, видає AUTH та відключається за власним бажанням. Це може бути спроба перевірити можливості сервера від поштового клієнта - або спроба випробовувати демона.

Поки у вас є достатня безпека, це просто черговий стук у двері від світу.

— толстянка
джерело

Навіть якщо це трапляється 3 чи 4 рази поспіль?

— Алексіс Вільке