Algum guru de postfix pode me ajudar a determinar como e-mails ainda estão sendo enviados através do meu servidor de fontes não autorizadas?

Question

Estou ficando um pouco preocupado ao administrar um pequeno servidor que hospeda vários sites e gerencia o e-mail para algumas dezenas de pessoas.

Recentemente, recebi algumas notificações do spamcop, alertando-me de que o spam foi enviado pelo meu servidor e, quando olho os logs de tempos em tempos, posso ver que há muitas tentativas repetidas. de e-mail enviado do meu servidor. Na maior parte do tempo, ele é repelido dos servidores de destino, mas às vezes está passando.

Infelizmente, não sou especialista em linux ou postfix, posso sobreviver, mas apesar de ter minha máquina bloqueada com bastante segurança, não permito a retransmissão, quando verifico as ferramentas DNS / MX on-line que elas tendem a relatar servidor como sendo OK, então não tenho certeza de onde levá-lo agora e espero que alguém possa me lançar algumas dicas.

Eu recebo muitas entradas como essa no meu log MAIL.INFO

Jan  2 08:39:34 Debian-50-lenny-64-LAMP postfix/qmgr[15993]: 66B88257C12F: from=<>, size=3116, nrcpt=1 (queue active)
Jan  2 08:39:34 Debian-50-lenny-64-LAMP postfix/qmgr[15993]: 614C2257C1BC: from=<[email protected]>, size=2490, nrcpt=3 (queue active)

e

Jan  7 16:09:37 Debian-50-lenny-64-LAMP postfix/error[6471]: 0A316257C204: to=<[email protected]>, relay=none, delay=384387, delays=384384/3/0/0.01, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mx.fakemx.net[46.4.35.23] refused to talk to me: 421 mx.fakemx.net Service Unavailable)
Jan  7 16:09:37 Debian-50-lenny-64-LAMP postfix/error[6470]: 5848C257C20D: to=<[email protected]>, relay=none, delay=384373, delays=384370/3/0/0.01, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mx.fakemx.net[46.4.35.23] refused to talk to me: 421 mx.fakemx.net Service Unavailable)

então tende a haver tempos limite de conexão, então pelo que eu vejo mesmo que eu tenha retransmitido desativado ... alguma coisa está passando e tentando enviar ...

Então, se você puder ajudar, isso será muito apreciado, e qualquer outra informação de registro / configuração que eu possa fornecer.

Algumas linhas do Main.CF que eu achei que eram suficientes, talvez eu esteja perdendo algo importante aqui:

# Requirements for the HELO statement
smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, permit
# Requirements for the sender details
smtpd_sender_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
# Requirements for the connecting server
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client dnsbl.njabl.org 
# Requirement for the recipient address
#smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit
smtpd_recipient_restrictions = reject_unauth_pipelining,reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,check_policy_service inet:127.0.0.1:60000,permit

# require proper helo at connections 
smtpd_helo_required = yes 
# waste spammers time before rejecting them 
smtpd_delay_reject = yes 
disable_vrfy_command = yes

Obrigado

    

Answer 1

Ter permit no final de suas restrições é a causa do problema. Se não for permitido inicialmente com permit_mynetworks , você não vai querer dar a volta com o que está sendo enviado para sua fila de mensagens. Remova as entradas permit do final das suas linhas *_restrictions e você verá uma melhora repentina. O que está acontecendo é que algumas das tentativas de retransmissão de spam estão "apenas em conformidade suficiente" para passar pela lista de restrições (aquelas entradas na frente de permit ), então quando percorre a lista de testes para passar na lista de restrições, ele atinge o permit que instrui o postfix a dar-lhe o "polegar para cima" e continua processando - e retransmitindo - o spam sendo enviado.

Assumo (?) que você tenha as instruções permit para evitar que o email seja bloqueado por clientes legítimos. Não se preocupe em desligar sua rede. É para isso que o mynetworks é: é a lista de endereços de rede "confiáveis" para os quais você aceitará e transmitirá mensagens automaticamente. A entrada permit_mynetworks no início diz ao postfix para permitir imediatamente qualquer coisa definida em mynetworks e, nesse ponto, interrompe o processamento das etapas listadas na sua lista *_restrictions . Isso ocorre porque a lista de testes é processada da esquerda para a direita, até que uma correspondência seja encontrada. Usar permit no final de cada linha instrui o sistema a permitir o e-mail sem restrição se ele tiver passado em todos os outros testes antes da configuração permit .

    

Answer 2

Você deve quase nunca usar permit . Use apenas as diretivas de permissão qualificadas (por exemplo, permit_mynetworks , permit_sasl_authenticated , etc).

    

Answer 3

Você achou que tinha desativado o revezamento, mas tem? Você teria que postar informações do seu arquivo de configuração ou do Google para algo como "desabilitar relé" e o nome do seu aplicativo MTA para encontrar informações de bloqueio de amostra para proteger seu sistema.

Caso contrário, alguém com quem você permite enviar e-mails através de seu sistema está infectado com algo e está usando seu servidor para enviar spam ou alguém entrou em seu servidor e o infectou com scripts para retransmitir spam.

Você verificou se há serviços incomuns em execução? Verificar rootkits ou algo incomum nos logs? Quais outros serviços você tem em execução no servidor? Você já verificou conexões TCP de entrada incomuns? Como você está bloqueando o sistema apenas para usuários autorizados, como em sua própria sub-rede, senhas específicas (que poderiam ter sido comprometidas), somente IPs autorizados ...?