Detectar spammers no meu servidor

Question

Recentemente recebi um Undelivered Mail Returned to Sender ao enviar meu boletim informativo para um dos meus 1500 clientes. Meu site usa um procedimento double-opt-in para garantir que o usuário deseja receber minha newsletter.

A mensagem de erro:

smtp; 554 ...
    Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
    refer to xyz.com if you feel this is in error.

Recebi um exemplo de email de spam (do provedor de email do servidor de email de recebimento):

Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <[email protected]>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500

O provedor também afirmou que meu servidor parece ter sido invadido. Ele afirmou ainda, que "o servidor de e-mail do destinatário simplesmente gravou o rDNS apresentado a ele pelo IP de conexão, neste caso mail.com ([94.130.34.42]) " - que definitivamente NÃO é como eu configurei minha entrada rDNS (mail.lotsearch.de) para meu Endereço de IP. Então, se eu entendi o rDNS corretamente, o servidor de e-mail receptivo consulta o IP do remetente para uma entrada rDNS (94.130.34.42 = > deve resolver para = > mail.lotsearch.de, o que definitivamente faz, quando eu testo do meu local máquina via $ host 94.130.34.42 ).

Como é possível falsificar o rDNS? Eu não consigo imaginar como isso pode tecnicamente funcionar (apenas com um ataque man-in-the-middle em algum lugar na infra-estrutura entre o servidor de recebimento de mensagens e meu servidor).

O provedor mencionou também que "é provável que uma máquina conectada do meu IP tenha sido comprometida e enviado essas mensagens através de conexões diretas com o servidor de mensagens do destinatário (também conhecido como MX direto)". O que significa direct MX ? Alguém roubou ou encontrou as credenciais de e-mail vazadas para uma das minhas contas de e-mail e as usou para o envio de e-mails?

O que eu fiz até agora para garantir que meu servidor NÃO seja invadido / não seja invadido:

• pesquisou os registros de e-mail ( var/log/mail* ): nada especial lá
• verificou os logs de login do ssh ( last , lastb ): nada incomum
• verificado se o postfix é retransmitido: não, não (verificado via telnet)
• verificado por malware via clamav: sem resultados
• instalado e configurado fail2ban para ssh, postfix e dovecot
• instalou as últimas correções / atualizações para o Ubuntu 16.04 (eu faço isso toda semana)
• verificado se meu endereço IP está em qualquer lista negra: não é
• verifiquei a entrada do rDNS no console de gerenciamento do meu provedor de hospedagem: ela está definida corretamente como mail.lotsearch.de .
• alterou as senhas de todas as contas de e-mail
• alterou chaves públicas para acesso ao shell

Mais importante: não havia informações sobre [email protected] nos registros. Então, se o meu servidor tivesse sido mal utilizado por um spammer (por exemplo, devido a vazamento de credenciais smtp de uma das contas de email), eu veria isso nos arquivos de log.

A última possibilidade que posso pensar é que um intruso colocou malware no meu servidor que ainda não encontrei.

Como posso monitorar o tráfego de e-mail de saída (por processo e por porta)?

Somente monitorar a porta de saída 25 não ajudaria, pois isso traria apenas emails irregulares enviados via postfix, mas não o tráfego de email causado por uma possível infecção por malware (se o malware usa outra porta de 25 para enviar emails diretamente / se comunicar com o destinatário servidores de correio). Se eu monitorar o tráfego de saída em todas as portas, obterei um caminho para um arquivo de log enorme, no qual não posso pesquisar com eficiência por atividades suspeitas.

EDIT - Teste adicionado para retransmissão aberta:

$ telnet mail.lotsearch.de 25
$ HELO [email protected]
250 mail.lotsearch.de
$ MAIL FROM: [email protected]
250 2.1.0 Ok
$ RCPT TO:<[email protected]>
454 4.7.1 <[email protected]>: Relay access denied

EDIT - Execução de webapps

• Plataforma personalizada com base no Zend Framework 3 ( link )
• Mediawiki ( link )
• Mantis Bug Tracker ( link )

Answer 1

Antes de responder à minha sugestão, quero comentar um pouco sobre algo que seu provedor disse a você:

 Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100

Isso não indica que o DNS reverso para 94.130.34.42 é (ou era) mail.com. Em vez disso, indica que o cliente SMTP enviou mail.com em sua linha HELO (ou EHLO ). (Um servidor de e-mail bem configurado teria rejeitado totalmente essa conexão, mas isso é na Swisscom, não você ...) Essa linha não indica nenhuma entrada de DNS reverso. Se o fizesse, teria aparecido dentro dos parênteses. Por exemplo:

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

Nesse caso, o primeiro nome do host é o que o servidor de e-mail identificou como seu EHLO . O segundo nome de host é o DNS reverso registrado no momento em que a conexão foi feita.

A seção 4.4 da RFC 5321 explica o formato da linha Received:, com uma gramática formal. / p>

No seu caso, nenhum DNS reverso foi registrado. Como o seu endereço IP tem um registro PTR, isso pode ser porque eles não procuraram ou houve uma falha temporária no DNS.

Agora, parece que você administra um serviço de hospedagem na Web e tem vários aplicativos da web. Se um deles estiver comprometido, ele pode começar a enviar spam. Eles geralmente fazem conexões diretas com servidores de email remotos procurando seus registros MX e conectando-se à porta 25, como se fossem eles mesmos um servidor de email, em vez de entregar emails no spool de correio local ou em um serviço de email autenticado nas portas 587 ou 465 como aplicativos da web legítimos.

Uma maneira de interromper isso é implementar uma regra de firewall que impeça conexões de saída na porta 25, a menos que o usuário seja o usuário do servidor de email. Por exemplo:

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

Os aplicativos da Web não podem mais enviar mensagens diretamente para servidores SMTP remotos, mas devem usar o spool de correio local ou um serviço de correio autenticado.

    

Answer 2

Neste dia e idade, tentar fazer o seu próprio servidor de e-mail é, na maior parte, uma batalha perdida e é melhor você encontrar um serviço acessível. Tendo dito isso ..

• Veja seus registros indo até o provedor que bloqueou você e veja se você pode encontrar algo suspeito. É possível, e acontece com frequência, que alguém esqueça de assinar sua newsletter e marcar você como spam. Então, dependendo do provedor, você pode entrar na lista negra do provedor mesmo que não tenha feito nada errado.

• Separe as correspondências em massa de todos os seus outros e-mails em dois servidores.

• Mantenha os registros por semanas no mínimo e em melhores meses. Então, sempre que algo acontecer, você pesquisa.

• Verifique seus registros diariamente para situações semelhantes de qualquer provedor e analise-os diariamente ou com mais rapidez. O segundo em que você é bloqueado e se continuar tentando enviá-lo pode piorar. Você pode ir de um bloco temporário para um bloco permanente ... até ser denunciado a uma lista negra.

• Não sei como eles implementam, mas uma coisa que eu sei que muitos provedores fazem para serviços de e-mail de saída é que no segundo caso um provedor / IP bloqueia um e-mail, nenhum outro e-mail é enviado. Idealmente, você quer algo assim. Porque o segundo fica bloqueado, enviar mais apenas agravará o problema.