Como detectar e evitar que o postfix envie emails de spam de uma conta de email comprometida

Question

Hospedamos e-mails e sites para inúmeros clientes em um servidor dedicado rodando o CentOS e configurados através do Virtualmin.

O email é tratado através do Postfix.

Durante o fim de semana, notamos que uma conta de e-mail de clientes foi comprometida e o servidor foi usado para bombear spam. Como resultado, nosso servidor estava na lista negra, afetando todas as outras contas no servidor. Acreditamos que uma máquina desktop foi infectada com malware, o que permitiu aos spammers o acesso às credenciais de login do SMTP para a conta em questão. Daquele ponto em diante, foi a temporada de abertura.

A minha pergunta é: existe alguma maneira de colocar qualquer coisa no lugar para detectar automaticamente spam como atividade desta natureza?

Obrigado

    

Answer 1

Se você usar o SASL / TLS para autenticar seus usuários, poderá configurar "caminhos" diferentes em seu servidor. Um caminho pode ser a porta de entrada clássica, que será executada no amavisd-new, para ser verificada quanto a spam e vírus, e você pode configurar outro caminho que tenha padrões mais permissivos, possivelmente com um limite maior de spam. Você também pode permitir ou proibir diferentes tipos de anexos de e-mail.

Você pode limitar o tipo de e-mail ou, mais especificamente, com quais endereços seus usuários podem enviar como.

Como você vai depender do tipo de software que você tem no momento.

    

Answer 2

Como eu postei acima como comentário, também tive o mesmo problema. Depois de fazer uma pesquisa, descobri essa solução rápida (ainda em teste - use a seu próprio risco -):

no seu arquivo postfix main.cf :

smtpd_relay_restrictions =
    ...
    permit_mynetworks,
    reject_unknown_reverse_client_hostname,
    permit_sasl_authenticated,
    ...

Esteja ciente de que as "smtpd_relay_restrictions" estão disponíveis no postfix 2.10, mas você pode aplicá-las também antes de 2.10, por favor, verifique a Documentação .

No meu caso, precisei realizar duas alterações:

1. mova "permit_sasl_authenticated" para baixo nas minhas regras. Antes, eu confiava muito em meus usuários autenticados.
2. adicione a regra: "reject_unknown_reverse_client_hostname", como a maioria dos "spammers autorizados" que informam host "desconhecido" (infelizmente, alguns deles continham informações de nome de host). Eu também adicionei uma lista branca (usando: regra check_client_access) de alguns dos servidores do meu cliente que são conhecidos por não estarem resolvendo seu IP - > hostname.

Até agora, tudo bem. Melhor ainda, como está sendo mostrado como "rejeitado" no registro de e-mail, agora posso proibir esses clientes usando minha configuração atual do fail2ban.

Como nota lateral, você pode executar uma verificação extensiva (como talvez a verificação de rbl, antes de permitir que seus usuários de autenticação enviem e-mails). Eu não tentei isso embora.

Seria bom adicionar spamassassin ao jogo e sinalizar e bloquear os emails de SPAM antes de entregá-los. No entanto, como o spamassassin não estava tocando muito bem com mensagens em japonês (todos os meus clientes são japoneses), não sinto vontade de dar tanto poder por enquanto.

Espero que possa ajudar você.

    

Answer 3

Algum tempo depois que eu postei minha resposta anterior, eu vim com esse pequeno truque que acho mais eficaz para lidar com credenciais roubadas (pode não funcionar para todos):

1) Instale o fail2ban (se ainda não o tiver) para bloquear tentativas de login malsucedidas de endereços IP específicos.

2) Acompanhe (por meio de um script) os IPs de localização geográfica que se conectam ao seu servidor. Se você detectar dois países diferentes em menos de um minuto, bloqueie a conta e notifique o usuário.

O bloqueio da conta bloqueia automaticamente todos os clientes que tentam usar essa conta.

Esse cenário provou ser eficaz no meu caso, pois não espero que meus clientes estejam em dois países diferentes em menos de um minuto (meus servidores estão no Japão).

No entanto, se você tiver clientes de e-mail em todo o mundo, sugiro aumentar o número de países, já que os dispositivos móveis poderiam mostrar esse padrão se alguém estiver na fronteira de dois países.

Além disso, essa técnica implica que você tenha uma maneira de entrar em contato diretamente com seus clientes (por telefone ou de outra forma, além da conta comprometida).

Isso é especialmente bom contra malware que rouba credenciais, pois eu tenho visto que, nesses casos, esse malware parece compartilhar essas credenciais entre vários clientes infectados (que estão localizados em todo o mundo). No entanto, não será eficaz se o spam vier de um único cliente localizado no mesmo país em que reside o proprietário da conta original.

O script de acompanhamento pode ser facilmente codificado dessa maneira: tail -n0 -F mail.log e passa cada linha em um script de análise que extrairá endereços IP e obterá sua localização usando geoiplookup . Mantenha em um banco de dados (ou arquivo) com a conta e último país / países que foi detectado. Se você estiver usando contas UNIX, a maneira mais fácil de bloqueá-las é usar: passwd ACCOUNT -l . Não se esqueça de enviar um e-mail para você saber sobre o problema.

Se você não tem habilidades de script, ou não quer começar do zero, me avise e compartilharei meu script.

    

Answer 4

My question is: is there anyway to put anything in place to automatically detect spam like activity of this nature?

Para o seu caso de uso, recomendo usar postfwd . Tem um sistema flexível de regras que podem fazer filtragem inteligente.

Recursos

• Combinações complexas de parâmetros smtp em uma única regra
• Macros / ACLs / Grupos para instruções usadas com frequência
• Pesquisas dnsbl assíncronas combinadas com ações arbitrárias dependendo do resultados (por exemplo, permite whitelists dns ou greylisting seletivo com base em resultados de pesquisa rbl)
• Desativação automática de dnsbls não respondentes
• Taxa de limites para contagem e tamanho de mensagens para qualquer item disponível (usuário, cliente, remetente, destinatário, ...)
• Sistema de pontuação para controle de acesso granular fino Regras baseadas em data / hora
• Saltos condicionais para certas regras (como iptables -j)
• Cache interno para solicitações e pesquisas de DNS
• é executado como daemon de rede (não é necessário gerar processos)
• Estatísticas integradas para análise de eficiência de regras

Por exemplo,

Não permita mais de 20MB ou 1000 destinatários por dia para usuários alice e bob:

id=RULE003
    sasl_username=~/^(alice|bob)$/
    action=size(sasl_username/20971520/86400/REJECT only 20mb per day for $$recipient)
id=RULE004
    sasl_username=~/^(alice|bob)$/
    action=rcpt(sasl_username/100/86400/REJECT only 100 recipients per day for $$sasl_username)

Ou você pode configurar políticas diferentes para clientes diferentes

# Class 1: high volume clients
# - per mail: max 30MB, max 200 concurrent recipients
id=CLASS100; client_address=table:/etc/postfwd/class1.cf; action=jump(CLASS101)

# Class 2: medium limited access
# - per mail: max 10MB, max 50 concurrent recipients
# - rate limit: 1000 recipients or 100MB per day
id=CLASS200; client_address=table:/etc/postfwd/class2.cf; action=jump(CLASS201)

# Class 3: very tight limits
# - per mail: max 4MB, max 10 concurrent recipients
# - rate limit: 100 recipients or 20MB per day
id=CLASS300; client_address=table:/etc/postfwd/class3.cf; action=jump(CLASS301)

# Does not fit anywhere? REJECT
id=DEFAULT; action=REJECT please contact [email protected]

E assim por diante. A única restrição - é a sua fantasia:)