Detectar spammers no meu servidor

Recentemente, recebi uma Undelivered Mail Returned to Senderao enviar meu boletim para um dos meus 1500 clientes. Meu site usa um procedimento de inscrição dupla para garantir que o usuário deseje explicitamente receber meu boletim.

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.

Eu recebi um exemplo de email de spam (do provedor de email do servidor 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" <posteitaliane@test123.it>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500

O provedor também declarou que meu servidor parece estar hackeado. Ele afirmou ainda que "o servidor de email do destinatário simplesmente registrou o rDNS apresentado pelo IP de conexão, neste caso mail.com ([94.130.34.42])" - o que definitivamente não é como eu configurei minha entrada de rDNS (mail.lotsearch.de) para o meu endereço IP. Portanto, se eu entendi o rDNS corretamente, o servidor de email que solicita uma consulta ao IP do remetente solicita uma entrada do rDNS (94.130.34.42 => deve resolver para => mail.lotsearch.de, o que definitivamente acontece quando eu testá-lo na minha máquina local via $ host 94.130.34.42)

Como é possível falsificar rDNS? Não consigo imaginar como isso funcione tecnicamente (apenas com um ataque intermediário em algum lugar da infraestrutura entre o servidor de recebimento e o meu servidor).

O provedor mencionou também que "é provável que uma máquina conectando-se ao meu IP tenha sido comprometida e enviando essas mensagens por meio de conexões diretas ao servidor de email do destinatário (também conhecido como MX direto)". O que direct MXsignifica isso ? Alguém roubou ou encontrou credenciais de correio vazadas em uma das minhas contas de correio e as usou para o envio de correio?

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

• procurou os logs de correio ( var/log/mail*): nada de especial lá
• verificou os logs de login do ssh ( last, lastb): nada de anormal
• verificado se o postfix é retransmitido: não, não (verificado via telnet)
• verificado quanto a malware via clamav: nenhum resultado
• fail2ban instalado e configurado para ssh, postfix e dovecot
• instalou os patches / atualizações mais recentes para o Ubuntu 16.04 (eu faço isso toda semana)
• verifiquei se meu endereço IP está em qualquer lista negra: não está
• entrada rDNS verificada no console de gerenciamento do meu provedor de hospedagem: está definido corretamente como mail.lotsearch.de.
• senhas alteradas de todas as contas de email
• chaves públicas alteradas para acesso ao shell

Mais importante: não havia informações sobre posteitaliane@test123.itos logs. Portanto, se meu servidor fosse mal utilizado por um remetente de spam (por causa de credenciais de smtp vazadas em uma das contas de email), eu veria isso nos arquivos de log.

A última possibilidade em que consigo pensar é que um invasor colocou malware no meu servidor que ainda não encontrei.

Como posso monitorar o tráfego de mensagens enviadas (por processo e por porta)?

Monitorar apenas a porta de saída 25 não ajudaria, pois só interceptaria 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 usar outra porta que 25 para enviar emails diretamente / se comunicar com os servidores de email destinatários) . Se eu monitorar o tráfego de saída em todas as portas, receberei um caminho para um arquivo de log enorme, no qual não posso procurar atividades suspeitas com eficiência.

EDIT - Adicionado teste para relé aberto:

$ telnet mail.lotsearch.de 25
$ HELO test@test.de
250 mail.lotsearch.de
$ MAIL FROM: test@test.com
250 2.1.0 Ok
$ RCPT TO:<realEmail@gmail.com>
454 4.7.1 <realEmail@gmail.com>: Relay access denied

EDIT - Executando webapps

• Plataforma personalizada baseada no Zend Framework 3 ( https://framework.zend.com/ )
• Mediawiki ( https://www.mediawiki.org/ )
• Mantis Bug Tracker ( https://www.mantisbt.org/ )

Antes de chegar à minha sugestão, quero comentar um pouco sobre o 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.comem sua HELO(ou EHLO) linha. (Um servidor de email bem configurado teria rejeitado completamente essa conexão, mas isso é na Swisscom, não você ...) Esta linha não indica nenhuma entrada DNS reversa. Se tivesse, teria aparecido entre 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 email se identificou como no seu EHLO. O segundo nome do host é o DNS reverso registrado no momento em que a conexão foi estabelecida.

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

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

Agora, parece que você executa um serviço de hospedagem na web e possui vários aplicativos da web. Se um deles estiver comprometido, ele poderá começar a enviar spam. Geralmente, eles fazem conexões diretas com servidores de correio remoto, pesquisando seus registros MX e conectando-se à porta 25, como se fossem um servidor de correio, em vez de entregarem correio ao spool de correio local ou a um serviço de correio autenticado nas portas 587 ou 465 como aplicativos da web legítimos.

Uma maneira de parar isso é implementando uma regra de firewall que impede 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 entregar emails diretamente para servidores SMTP remotos, mas devem usar o spool de email local ou um serviço de email autenticado.

Hoje em dia, tentar criar seu próprio servidor de correio é, na maior parte, uma batalha perdida e é melhor encontrar um serviço acessível. Tendo dito isto..

• Olhe para os seus logs indo para o provedor que o bloqueou e veja se você pode encontrar algo suspeito. É possível, e acontece com frequência, que alguém esqueça que se inscreveu no seu boletim informativo e o marque como spam. Então, dependendo do provedor, você pode entrar na lista negra do provedor, mesmo que não tenha feito nada de errado.

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

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

• Verifique seus logs diariamente em busca de situações semelhantes em qualquer provedor e examine-os diariamente ou mais rapidamente. O segundo em que você é bloqueado e se continuar tentando enviá-lo pode piorar. Você pode passar de um bloqueio temporário para um permanente. A ser denunciado a uma lista negra.

• Não tenho certeza de como eles o implementam, mas uma coisa que sei que muitos provedores fazem para serviços de correio de saída é que, no segundo em que um provedor / IP bloqueia um email, nenhum outro email é tentado a ser enviado. Idealmente, você quer algo assim. Como o segundo fica bloqueado, o envio de mais agravará o problema.