Eu tenho um servidor sendmail. Periodicamente (ou seja, várias vezes por hora) recebo entradas de log como esta:
Sep 3 10:06:49 lory sendmail[30561]: v8396nsQ030561: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep 3 10:06:49 lory sendmail[30564]: v8396nmv030564: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
[29 very similar lines deleted]
Sep 3 10:06:50 lory sendmail[30654]: v8396or0030654: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep 3 10:06:50 lory sendmail[30657]: v8396ou3030657: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Esse servidor em particular continuou um pouco nessa taxa, depois ficou em rajadas, aumentando no total cerca de 600 conexões em 110s; outros são menos prolixos. Eles não causam problemas ao meu servidor; fail2banfica um pouco exercitado, observando o arquivo de log de correio para falhas de SMTP AUTH, e tendo que ignorar todas essas novas entradas, mas não é nada para fazer o servidor suar.
O que estou curioso, e o que estou perguntando, é por que alguém faria uma coisa dessas. Eles estão esperando que meu mecanismo de retransmissão / lista cinza / SPF tenha um cérebro muito pequeno e, depois de 500 conexões, diga a si mesmo , meu Deus, eles estão realmente ansiosos para falar comigo, é melhor eu aceitar qualquer coisa que eles enviarem agora ? Eles estão esperando que meu servidor não tenha uma VM sobressalente e o sendmail inche e invoque o assassino OOM, me DoSsing? Presumo que alguém esteja fazendo esse tipo de coisa por um motivo, mas alguém tem a menor idéia de qual possa ser esse motivo?
Os avisos do sendmail "não emitiu MAIL/EXPN/VRFY/ETRN durante a conexão com o MTA" são, não inesperados, acionados por tentativas de autenticação que são rejeitadas, mas não apenas quando uma combinação incorreta de senha de nome de usuário é fornecida, mas você vê o mesmo erro mesmo quando a autenticação não é suportada (ou pelo menos não é permitida sem TLS):
Isso gera o tipo de evento de log que você vê:
Você não vê nenhum nome de usuário real registrado porque os "invasores" nem chegam ao estágio em que podem fornecer um nome de usuário ou senha.
Quando eu me conecto com o STARTTLS e forneço um nome de usuário e senha (incorreto) combo, o sendmail registra exatamente o mesmo erro.
Isso gera uma linha de log adicional, mas depois exatamente o mesmo evento.
Nunca atribua à malícia o que se explica adequadamente pela estupidez:
Meu próprio domínio não recebe muito e-mail, mas ruído de fundo suficiente na Internet com relação a varreduras de portas e tentativas de força bruta. Eu capturei todo o tráfego SMTP nos últimos dois dias e, além de alguns endereços IP exclusivos que acionam esses eventos de log, meu servidor tinha dois endereços IP que não recuaram quando meu sendmail respondeu que
AUTHnão é suportado ( sem TLS) resultando em um grande número de avisos desses IPs.Pelo menos para esses dois endereços IP foi como eu esperava, eles parecem apenas programas de malware estúpidos e estúpidos aparentemente trabalhando em uma lista de nomes de usuários/senhas sem realmente fazer nenhum controle de erros e não recuar após a falha inicial (o que me faz pensar se eles pudessem detectar se/quando eles são bem sucedidos ...)
e o log associado: