Postfix 2.9 ou sendmail, prevenção de spam de saída (verifique se existe remetente)

1
  • Sistema operacional: Linux Ubuntu 12.04 TLS
  • Contexto: Plesk 11.5
  • Utilitário: Postfix 2.9.6 (atualizações restritas pela distribuição do Plesk 11.5)

Gostaria que o Postfix verificasse o campo 'remetente' de todos os e-mails smtp de saída (antes de enviar), para que o remetente correspondesse a qualquer uma das contas criadas (usuários de e-mail) válidas de qualquer um dos domínios hospedados no servidor (como condição para aprovar o envio).

A razão disso é que, sempre que um domínio é infectado pelo (s) script (s) do remetente de spam, ele geralmente usa um padrão como 'nome-aleatório'@infected-domain.tld . Ao aplicar um filtro de existência de remetente ao usuário , pode-se reduzir o impacto sobre a reputação do servidor e impedir que ele seja colocado na lista negra tão rapidamente como ocorre atualmente (sempre que um dos domínios hospedados for infectado por scripts mal-intencionados) ).

Portanto, não estou pedindo restrições específicas de domínio, mas restrições específicas de usuários para o campo "Mail From:" antes de enviá-lo pelo Postfix ( não ao receber emails de entrada ).

Editar 1

Por fim, adivinhei que o problema aqui é que o / usr / sbin / sendmail pode enviar, usando o Postfix, sem autenticação, não é? Ou está configurado em outro lugar sem que eu saiba disso?

Por favor, pelo menos, você poderia me ajudar com alguma documentação útil e compreensível para o sendmail? Eu não consegui encontrar nada realmente útil para entender como funciona, e menos para um ambiente multiusuário como o Plesk 11.5.

É por isso que eu gostaria de filtrar diretamente do Postfix, porque é o ponto central para confiar ou enviar e-mails.

Editar 2

Pesquisando, finalmente descartei a diretiva para o Postfix 2.4+ authorized_submit_users = > link

Ele apenas verifica o UID do processo / usr / sbin / sendmail, que é o usuário do domínio infectado.

Adicionando:

authorized_submit_users = !unknown, static:all

não resolve o problema.

Editar 3

Trabalhando com

#/etc/postfix/main.cf
header_checks = regexp:/etc/postfix/header_checks

E as opções de filtragem regex, usando lookahead negativo :

#/etc/postfix/header_checks
/^From: ".*(?!user1|user2|user3).*@infected-domain.tld/ REJECT

Alguma ideia? Posso abrir outro tópico?

Resolvido!

Eu forneci uma solução personalizada para este caso específico, respondendo a mim mesmo abaixo. Obrigado a todos pela sua informação, colaboração e apoio!

    
por rellampec 13.02.2015 / 00:04

4 respostas

2

Por fim, encontrei uma solução para filtrar spam de saída com header_checks , embora eu não saiba o quanto ela pode ser eficiente e eficaz.

Aviso :

  • esta solução técnica de atenuação não limpa a infecção.
  • só é útil quando o ataque envia spam usando o nome de domínio real e nomes de usuário falsificados ou contas de email como remetentes ( From: ).
  • quando a infecção usa outros nomes de domínio como remetente ( From: ), essa expressão regex não pode ser eficaz.

Dado que /usr/sbin/sendmail é usado pelo script infectado para spam, sempre que ele usa contas de email inexistentes aleatoriamente (ou seja, [email protected]), em vez de contas reais como remetentes (por exemplo, user1 @ my-domain. tld), os cabeçalhos de correio podem ser verificados usando a inspeção de conteúdo interna de postfix header_checks como segue:

#/etc/postfix/main.cf
# add it for example before TLS paramaters
# Anti-SPAM options
header_checks = pcre:/etc/postfix/header_checks

A expressão regular no arquivo header_checks deve excluir qualquer usuário real do domínio (por exemplo, user1, user2, ...):

#/etc/postfix/header_checks
/^From:((?![^@]*?user1|[^@]*?user2|[^@]*?user3|[^@]*?webmaster)[^@]*?)@my-domain\.tld/ REJECT invalid sender

Explicação da expressão regular (para qualquer alteração, pode ser usado este testador de regex ):

  • [^@] de qualquer caractere, exceto @
  • [^@]*? qualquer caractere, exceto @ , zero ou mais vezes, preguiçoso não-ganancioso ( *? ).
  • (?!user1|user2|etc) lookahead negativo com alternativas: descartando usuários reais do domínio.
  • (?![^@]*?user1|[^@]*?user2|etc) permitindo caracteres antes do endereço de e-mail de cada usuário.

Antes de qualquer alteração, pode ser testado por (primeiro um passa, segundo rejeitado):

$ postmap -q "From: [email protected]" pcre:/etc/postfix/header_checks
$ postmap -q "From: [email protected]" pcre:/etc/postfix/header_checks
REJECT invalid sender
$

Ou até mesmo pode ser testado usando um arquivo com cabeçalhos de mensagens capturados durante a infecção (aviso: o traço é importante aqui):

$ postmap -q - pcre:/etc/postfix/check_headers < captured_headers.txt
From: "[email protected]      REJECT invalid sender
From: "[email protected]      REJECT invalid sender
$

Uma vez testado, se atingir o resultado desejado, basta reiniciar o Postfix:

# service postfix restart
 * Stopping Postfix Mail Transport Agent postfix                [ OK ]
 * Starting Postfix Mail Transport Agent postfix                [ OK ]

Para verificar como está acontecendo, um possível comando:

# tail -n 10000 /var/log/mail.log | grep reject
or
# tail -n 10000 /var/log/mail.log | grep 'invalid sender'

Espero que isso ajude alguém.

EDITAR

Algumas correções da expressão regular:

#/etc/postfix/header_checks
/^From:(?![^@]*?user1@|[^@]*?user2@|[^@]*?user3@|[^@]*?webmaster@)([^@]*?@my-domain\.tld)/
REJECT invalid sender $1

A verificação do postmap funciona bem, mas o postfix não está filtrando usuários de email forjados para o domínio (a última infecção que ele não filtrou). Eu não sei porque.

    
por 02.07.2015 / 07:56
2

Olhe para este diagrama , existem três entradas independentes onde o email pode digite postfix, sendmail (via pickup), smtpd e qmqpd. A última entrada raramente foi usada aqui.

Quando o email é enviado por meio de smtpd , a fonte de e-mail provavelmente é proveniente de fora (a exceção quando a conexão é de 127.0.0.1). E-mail externo foi considerado não confiável de maneira óbvia. Portanto, o postfix possui um recurso padrão para bloqueá-lo, como o verificador de RBL, o Open Relay Checker, o blaclisting / whitelisting e outros. Consulte o Retransmissão SMTP do Postfix e o controle de acesso .

Por padrão, o endereço IP do servidor e o 127.0.0.1 foram considerados confiáveis porque qualquer pessoa pode conectar-se a partir desse host do que eles podem causar mais destruição além do spam. Por exemplo: se um script foi enviado para o servidor da web, eles podem causar a ação de excluir raiz da web, plantar backdoor e outros.

Outra entrada de correio trusted foi através do programa sendmail / mail . Basicamente, quando a função de correio de chamada do php ou você invoca o correio do terminal, você instrui o sendmail a colocar o email na fila do postfix. O Sendmail não pode ser chamado a menos que algumas pessoas tenham algum acesso à sua caixa, como o script enviado.

Agora, estamos prontos para responder à sua pergunta principal: como posso verificar o remetente no banco de dados?

Para a conexão smtpd, você pode usar o recurso postfix Retransmissão SMTP do Postfix e controle de acesso check_sender_access para verificar novamente o banco de dados do usuário. Eu não posso te dar detalhes como nunca usei o Plesk. Para o comando sendmail / mail, você precisa da inspeção de conteúdo do postfix (filtro de conteúdo milter ou after queue), pois os filtros acima não são afetados por fonte do email.

    
por 18.02.2015 / 10:02
0

Eu faço isso no amavisd-new. Eu tenho o programa de instalação do amavis para verificar todos os emails, independentemente de onde eles vieram (local ou externo). Esses tipos de mensagens de spam têm muitos cabeçalhos ruins que podem ser facilmente capturados no amavisd. Você terá que desabilitar algumas verificações de cabeçalho que muitos clientes de e-mail (como o Outlook) não fazem corretamente.

Esta postagem também pode ser útil se se aplicar aos métodos de autenticação do plesk. verifique o cabeçalho do remetente autenticado no postfix

Nesta pergunta, eles verificam se há um remetente autenticado, mas tudo o que você precisa adicionar é uma regra para corresponder esse cabeçalho de usuário autenticado ao cabeçalho do remetente.

    
por 29.06.2015 / 08:17
-1

O recurso sobre o qual você está falando já existe, pronto para uso no Plesk 12

link

    
por 14.02.2015 / 15:10