Postfix e contas comprometidas

Question

Primeiro, desculpe pelo meu inglês.

Acho muito comum definir as restrições permit_mynetworks e permit_sasl_authenticated nas primeiras posições da lista smtpd_recipient_restriction , mas, se uma conta for comprometida (um vírus usa credenciais roubadas - dos arquivos de configuração do Outlook, por exemplo - para enviar SPAM), e clientes autenticados podem enviar e-mails sem mais restrições, sua última oportunidade é que seus milters rejeitem corretamente as mensagens de spam de contas comprometidas; mas não é menos eficiente?

Acho que o postfix é mais eficiente rejeitando o SPAM, já que ele usa informações do protocolo SMTP e assim por diante, mas os milters devem verificar o conteúdo das mensagens para detectar se um email é SPAM ou não.

No entanto, todos os meus clientes usam o TLS para se conectar ao meu servidor. Os vírus / spammers podem usar conexões criptografadas para enviar e-mails (desde que roubem uma senha)? Eu não penso assim, já que os spammers tentam entregar as mensagens o mais rápido possível, e as conexões criptografadas são muito lentas para esses propósitos.

Se for o caso, não tenho problemas para permitir que clientes autenticados enviem e-mails, mas gostaria de ter certeza sobre isso.

    

Answer 1

Com base em nossa discussão nos comentários, posso pensar em outra maneira de abordar o problema. Isso costumava acontecer comigo o tempo todo no negócio de hospedagem - você tem que deixar qualquer um com basicamente qualquer cliente se conectar ao seu servidor smtp, e se sua estação de trabalho for comprometida, eles podem fazer o que quiserem.

Novamente, minha abordagem era a defesa em profundidade, com uma pequena ofensa no lado do atendimento ao cliente (ou seja, diga a eles se você nos causar um problema de spam novamente, estamos perdendo você).

1) Use os Controles de Taxa do Postfix (você pode pesquisar no Google para mais informações - muito extenso) Isso é bom para salvar ciclos de CPU e memória em seu servidor no caso de um usuário começar a enviar spam. Isso reduzirá o dano e não afogará um host de destino se você tiver um problema - por isso, ajuda você a ser um cidadão educado, além de proteger a si mesmo e a outros usuários.

local_destination_concurrency_limit = 2
default_destination_concurrency_limit = 10

2) Limite de taxa com base no usuário SMTP

O postfix tem a capacidade de usar complementos de políticas como este projetado para fazer exatamente o que você quer

link

link

Você pode ser tão agressivo quanto quiser com essas políticas, incluindo a desativação completa da conta do usuário para que ele não possa fazer login até que liguem para você.

3) Não se esqueça dos vírus

Configure o postfix para verificar e-mails de saída com o link

Espero que esta seja uma resposta aceitável. Deixe-me saber se você tem outras perguntas.

Felicidades!

    

Answer 2

... if an account is compromised (a virus uses stolen credentials -from Outlook configuration files, for example- to send SPAM), and authenticated clients can send email without further restriction, your last opportunity is your milters correctly reject SPAM messages from compromised accounts; but, isn't it less efficient?

I think postfix is more efficient rejecting SPAM since it uses information from the SMTP protocol and so on, but milters must scan the contents of the messages to detect if a mail is SPAM or not.

Como @Binary disse em seus posts, é tudo sobre defesa multicamadas . Na primeira linha, o postfix tem verificações leves, como postscreen e stmpd _ * _ restriction ( incluindo permit_mynetworks e permit_sasl_authenticated ). Essa defesa será eficiente e economizará muitos recursos.

Após verificações leves, o postfix passará a verificação de spam para content_filter externo (antes ou depois da fila). É claro que consumirá mais recursos, mas essa verificação só invoca por (poucos por cento) de e-mails aprovados na primeira linha de defesa. O fundo da camada de defesa será determinado pelos seus recursos.

However, all of my clients uses TLS to connect to my server. Can viruses/spammers use encrypted connections to send email (provided they stole a password)? I don't think so since spammers try to delivery messages as fastest as possible, and encrypted connections are too slow for these purposes.

É claro que a conexão TLS / criptografada é mais lenta que a não criptografada. Mas a técnica como cache TLS melhorou o desempenho do handshake SSL por muito tempo. E, claro, o cliente infectado por spam / spam não se preocupa com isso. Eles só precisam de um vetor de ataque para lançar o e-mail de spam / vírus pelo seu servidor.

    

Answer 3

Concordo que usar a filtragem de spam de saída como uma defesa de linha de frente contra o envio de spam é ineficiente, mas ainda assim é importante. A alternativa é que o spam chega e coloca você em uma lista negra, então todo o seu domínio está com problemas. Então, eu acho que uma abordagem de defesa em profundidade é realmente a única abordagem aqui, incluindo freqüentes rotações de senha, 2FA, etc. O filtro de spam de saída é apenas uma camada dessa cebola - e é um importante. Pense nisso como a última linha de defesa, não a primeira. Além disso, você deve executar isso em hardware separado do cluster de email.

A implementação específica (milters, contra todo o resto) é menos importante que a eficiência geral do seu sistema. Na abordagem em camadas, você pode determinar a eficácia de cada etapa medindo o spam obtido em relação ao total de emails, estabelecendo assim uma maneira quantitativa de medir a eficiência ou a eficácia. Esperemos que quando o spam de saída chegar ao ponto, haverá tão pouco que não prejudicará o desempenho.

Para responder à sua última pergunta: não vejo motivo para que qualquer cliente não use o TLS em 2014. É outra camada em um sólido processo de segurança. Novas técnicas de spam acontecem todos os dias, e o uso do TLS apenas protege você de forma incremental melhor do que nenhuma criptografia TLS / outros.