Por que as pessoas estão se conectando repetidamente ao meu MTA, não fazendo nada e saindo?

Question

Eu tenho um servidor sendmail. Periodicamente (ou seja, várias vezes por hora) recebo entradas de registro 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

Este servidor em particular funcionou um pouco a essa taxa, depois ficou em rajadas, totalizando cerca de 600 conexões em 110s; outros são menos prolixo. Eles não causam problemas ao meu servidor; fail2ban é um pouco exercitado, observando o arquivo de log de correio para falhas SMTP AUTH, e ignorando todas essas novas entradas, mas não é nada que faça o servidor suar.

O que eu estou curioso, e o que eu estou perguntando, é porque alguém faria uma coisa dessas. Eles estão esperando que meu motor de transmissão / greylisting / SPF tenha um cérebro muito pequeno, e depois de 500 conexões ele diz para si mesmo, eles estão realmente interessados em falar comigo, é melhor eu aceitar qualquer coisa que eles enviem agora ? Eles estão esperando que o meu servidor não tenha uma VM sobressalente, e o sendmail irá inchar e invocar o killer da OOM, assim DoSsing me? Presumo que alguém esteja fazendo esse tipo de coisa por uma razão, mas alguém tem a menor idéia de qual poderia ser essa razão?

    

Answer 1

O sendmail "não emitiu MAIL / EXPN / VRFY / ETRN durante a conexão ao MTA" os avisos são, não inesperados, acionados por tentativas de autenticação que são rejeitadas, mas não apenas quando uma senha de nome de usuário incorreta combo é fornecido, mas você vê o mesmo erro mesmo quando a autenticação não é suportada (ou pelo menos não permitido sem TLS):

telnet localhost 25
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   220 hbruijn ESMTP Sendmail 8.14.4/8.14.4; Fri, 8 Sep 2017 13:06:31 +0200
AUTH LOGIN
   504 5.3.3 AUTH mechanism LOGIN not available
QUIT

Isso gera o tipo de evento de log que você vê:

Sep 8 13:06:39 hbruijn sendmail[11333]: v88B6VYg011333: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Você não vê nenhum nome de usuário real registrado porque os "atacantes" 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 combo de nome de usuário e senha (incorretos), o sendmail registra exatamente o mesmo erro.

openssl s_client -starttls smtp -connect localhost:25
   250 HELP
AUTH LOGIN
   334 VXNlcm5hbWU6
bXl1c2VybmFtZUBkb21haW4uY29t
   334 UGFzc3dvcmQ6
d2Vha3Bhc3M=
   535 5.7.0 authentication failed
QUIT
   DONE

Isso gera uma linha de log adicional, mas depois exatamente o mesmo evento.

Sep 8 13:24:22 hbruijn sendmail[11648]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256
Sep 8 13:24:32 hbruijn sendmail[11648]: v88BOMvW011648: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Nunca atribua à malícia o que é adequadamente explicado pela estupidez:

Meu próprio domínio não recebe muitos e-mails, mas há suficiente ruído de fundo com relação a varreduras de portas e tentativas de força bruta. Capturei todo o tráfego SMTP nos últimos dias e, além de alguns endereços IP exclusivos que acionaram esses eventos de log, meu servidor tinha dois endereços IP que não recuaram quando meu sendmail respondeu que AUTH isn ' t suportado (sem TLS) resultando em um grande número de avisos desses IPs.

Pelo menos para esses dois endereços IP era como eu esperava, eles parecem apenas programas de malware idiotas e estúpidos aparentemente trabalhando através de uma lista de nomes de usuário / senhas sem realmente fazer nenhum controle de erros e não retroceder após a falha inicial me faz pensar se eles poderiam até detectar se / quando eles são bem sucedidos ...)

e o log associado:

Sep 10 04:04:34 hbruijn sendmail[7558]: v8A24YLM007558: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:34 hbruijn sendmail[7561]: v8A24Yi1007561: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:34 hbruijn sendmail[7564]: v8A24YHM007564: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:35 hbruijn sendmail[7567]: v8A24YSY007567: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:35 hbruijn sendmail[7570]: v8A24ZC2007570: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:35 hbruijn sendmail[7573]: v8A24ZYo007573: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:35 hbruijn sendmail[7576]: v8A24ZLt007576: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 10 04:04:35 hbruijn sendmail[7579]: v8A24Zva007579: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA