Conexão Postfix perdida após AUTH

12

Observando os logs dos meus servidores de correio, notei mensagens como as seguintes:

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]

Não há falhas no SASL nesses casos. Há falhas de SASL registradas em outros momentos, mas nunca com lost connection after AUTH.

O que está acontecendo aqui e devo fazer algo a respeito?
Estes não são MXs e já foram smtpd_client_connection_rate_limitdefinidos.

Possivelmente relacionado:
os sistemas requerem SMTPS ou STARTTLS antes do AUTH ser anunciado.

postfix

— 84104
fonte

Você pode aumentar o nível de depuração do postfix?

— Khaled

Eu posso, mas isso aumentará os arquivos de log em uma taxa consideravelmente mais alta e esses eventos são esporádicos. O que esse aumento de registro ajudará a desambiguar?

— 84104

1

Portanto, você precisa aumentá-lo por um pequeno período de tempo e quando espera obter esse erro. Esperamos que isso dê mais dicas sobre o que esse erro significa.

— Khaled

9

Este é um botnet da China que se conecta à sua caixa tentando fornecer spam. Mas o bot é burro demais para saber o que fazer ao receber instruções para se autenticar. O bot simplesmente para de entregar e-mail e se desconecta por atacar a próxima vítima.

Absolutamente nada para se preocupar.

— mailq
fonte

3

Perto o suficiente. Parece que é algum tipo de script que emite AUTH e sai de maneira suja após o recebimento 503 5.5.1 Error: authentication not enabled. Foi capaz de replicar com o ncat. Embora por que ele continue tentando até atingir o limite de taxa esteja além de mim. Talvez esteja tentando forçar pares de nome de usuário / senha de força bruta? De qualquer maneira, estúpido demais, se preocupe.

— 84104

2

Como teste, só recebo essa linha nos meus logs e nunca vejo falhas no SASL apenas usando o Thunderbird e uma senha inválida para uma conta conhecida. Como o correio autenticado sempre passa pelo Postfix sem impedimentos, a resposta correta é, se possível, usar o script fail2ban publicado para manter o número mínimo de tentativas de força bruta. Tentativas de senha de força bruta são algo com que se preocupar absolutamente, para evitar transformar sua caixa em um relé aberto - especialmente se essa for a única linha em seus logs.

— CubicleSoft

Os logs parecem que ele está recebendo um por segundo, que pode ser alguém tentando fazer força bruta no servidor, o que é algo para se preocupar. Eu recomendo usar o fail2ban, no mínimo. Não resolverá completamente um problema de força bruta, mas o reduzirá substancialmente.

— Severun

21

Meus arquivos de log estavam ficando cheios, e é um desperdício de CPU permitir uma conexão desses idiotas. Eu criei uma fail2banregra.

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

Conteúdo de /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

Conteúdo de /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
fonte

2

Isso salvou meu dia. Eu adicionei a seguinte regra: failregex = ^%(__prefix_line)slost connection after AUTH from \S+\[<HOST>\].$. Eu tive muitas centenas dessas tentativas de conexão em alguns minutos. Eu tinha que fazer algo sobre isso.

— chmike

Isto é um pouco mais genérica:failregex = lost connection after AUTH from (.*)\[<HOST>\]

— CubicleSoft

@chmike: O ponto antes do final $deve ser removido. Não funcionou aqui com ele no regex.

— Cwiske

3

Em smtpd_recipient_restrictionsapenas definir reject_unknown_client_hostnameassim:

smtpd_recipient_restrictions = reject_unknown_client_hostname

e isso resultará na rejeição de clientes e bots zumbis perdidos ou burros com nomes de host desconhecidos. Seus logs ficarão assim quando definidos:

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]

— senhor
fonte

Já existe uma resposta aceita para essa pergunta (muito antiga).

— BE77Y

1

O nome do host desconhecido foi / não é o problema. lost connection after AUTHera é.

— 84104

1

A questão deles é "O que está acontecendo aqui, e devo fazer algo a respeito?" E esta é uma resposta perfeitamente válida.

— inorganik

2

Não tenho certeza se há muito com o que se preocupar, basicamente um cliente / 'alguém' esteja se conectando, emitindo AUTH e desconectando por conta própria. Pode ser uma tentativa de analisar os recursos do servidor de um cliente de email - ou uma tentativa de localizar o daemon.

Contanto que você tenha segurança suficiente, é apenas mais uma batida na porta do mundo.

— gelo fino
fonte

Mesmo que isso aconteça 3 ou 4 vezes seguidas?

— Alexis Wilke