Para limitar quais sistemas podem enviar e-mails de saída não autenticados por meio de um MTA Zimbra, defina o atributo desse servidor zimbraMtaMyNetworkspara uma lista curta de permissões contendo endereços IP ou redes CIDR confiáveis. Mantenha o loopback na lista, preserve quaisquer hosts confiáveis existentes que ainda precisem de retransmissão e remova intervalos amplos nos quais você não pretende mais confiar. Em seguida, reinicie o Postfix e teste com uma origem aprovada e uma não aprovada.
Essa configuração controla os clientes SMTP confiáveis que podem retransmitir mensagens sem autenticação SMTP. Ela não bloqueia todas as mensagens de saída de um usuário autenticado do Zimbra e não define o servidor de e-mail de próximo salto. Se o seu objetivo é exigir autenticação para clientes de e-mail em roaming ou restringir contas de usuário específicas, use os controles de autenticação ou política de e-mail apropriados.
O que controla a lista de permissões de IP?
O MTA do Zimbra usa o Postfix. No Postfix, um cliente cujo endereço de origem corresponde ao mynetworksendereço de retransmissão é tratado como confiável. O Zimbra expõe essa lista por meio de um zimbraMtaMyNetworkshost listado. Um host listado pode enviar e-mails para destinos externos sem autenticação, portanto, cada entrada representa uma decisão de confiança significativa.
Não confunda a lista de permissões com o servidor de retransmissão zimbraMtaRelayHost. A lista de permissões define quais clientes SMTP podem retransmitir mensagens por meio deste MTA. Um servidor de retransmissão é o servidor upstream para o qual o MTA encaminha mensagens não locais, por exemplo, quando um provedor de rede exige um servidor de retransmissão (smarthost). Alterar um não substitui a função do outro.
As páginas do Centro Técnico do Zimbra descrevem esse atributo e os comandos relevantes, mas alguns materiais estão marcados como em desenvolvimento ou documentação arquivada. Confirme o comportamento em relação à sua versão do Zimbra instalada e ao seu projeto de implantação antes de aplicar as alterações. Os exemplos abaixo usam as ferramentas de linha de comando do Zimbra como zimbraconta de serviço, em conformidade com as diretrizes do Zimbra para MTA (Acesso Multiponto).
Antes de alterar a configuração
- Identifique o host MTA que recebe os envios SMTP dos sistemas que você pretende permitir. Em um ambiente com múltiplos MTAs, determine quais MTAs gerenciam essas conexões e planeje a alteração em cada servidor relevante.
- Encontre o endereço IP de origem fixo que o MTA realmente vê. Se o aplicativo estiver atrás de um NAT, use seu endereço de saída público, não seu endereço LAN privado. Se o IP mudar com frequência, uma lista de permissões somente por IP precisará de manutenção constante.
- Registre o atributo Zimbra atual e o valor Postfix efetivo. Não substitua uma lista existente apenas pelo novo endereço até verificar quais serviços dependem das entradas atuais.
- Agende uma janela de manutenção ou de alteração adequada para o seu serviço de e-mail e mantenha uma cópia de segurança com o valor original exato.
Use um CIDR de host único, como /32para um endereço IPv4. Por exemplo, 198.51.100.25/32representa um host IPv4; este endereço, que serve apenas para documentação, é um exemplo e não deve ser copiado como um endereço de servidor real. Um intervalo mais amplo, como /24confia em todos os endereços dessa sub-rede. Não adicione redes públicas ou grandes intervalos de provedores apenas para que um teste seja bem-sucedido.
Como configurar a lista de permissões do relay Zimbra
1. Inspecione os valores configurados e efetivos.
Faça login no host do MTA e mude para a conta de serviço do Zimbra. Substitua `< mta.example.comserver name>` pelo nome exato do servidor retornado pelo zmhostnamecomando de instalação.
su - zimbra
zmhostname
zmprov gs mta.example.com zimbraMtaMyNetworks
postconf mynetworks
A primeira consulta lê o valor armazenado para o objeto do servidor Zimbra e postconfmostra a configuração efetiva do Postfix. Salve ambas as saídas. Se o atributo LDAP não estiver definido, o Postfix pode estar usando um valor padrão; portanto, não assuma que uma consulta vazia significa que não há redes confiáveis. Verifique o valor efetivo e o comportamento da configuração da sua versão antes de prosseguir.
2. Construa a lista completa mais curta possível.
Crie uma lista contendo o loopback e cada origem que realmente precise de retransmissão não autenticada. Para um servidor que deve aceitar retransmissão apenas do localhost e de um host de aplicação fixo, a estrutura seria:
127.0.0.0/8 198.51.100.25/32
Substitua o endereço de exemplo pelo endereço real visível para o MTA. Inclua as interfaces locais necessárias do servidor ou serviços confiáveis adicionais somente após confirmar sua necessidade. Evite manter uma sub-rede de escritório ampla se apenas um servidor precisar ser confiável; reduza-a a uma entrada de host sempre que possível.
3. Defina o valor no MTA correto.
Use zmprov mseste comando para definir o atributo em nível de servidor. Ele substitui o valor, portanto, inclua todas as entradas que você pretende manter, incluindo o loopback:
zmprov ms mta.example.com zimbraMtaMyNetworks '127.0.0.0/8 198.51.100.25/32'
Para vários IPs, coloque a lista completa de endereços IP aprovados dentro do valor entre aspas, separados por espaços. Não execute um comando de exemplo sem alterações. Se sua configuração depende de um valor global, configurações de servidor, IPv6, múltiplos MTAs ou comportamento específico da versão, verifique como a herança e a configuração do Postfix gerada funcionam nessa implementação antes de definir o atributo.
4. Recarregue o Postfix e confirme a configuração ativa.
Após alterar a configuração do Zimbra, recarregue o Postfix como a conta de serviço do Zimbra e, em seguida, consulte o valor efetivo novamente:
postfix reload
postconf mynetworks
zmprov gs mta.example.com zimbraMtaMyNetworks
A saída deve corresponder à lista de permissões desejada, incluindo o loopback. Se o Postfix reportar uma rede malformada ou se os valores forem diferentes, interrompa o teste e resolva o problema de configuração antes de testar o fluxo de e-mails. As entradas CIDR devem usar o limite de rede correto; para um único host, use o endereço do host com a /32máscara de rede, em vez de uma máscara que inclua hosts vizinhos.
Como verificar se a restrição funciona
Teste a partir de um sistema controlado e autorizado, usando o mesmo caminho de rede e servidor SMTP que a aplicação real. Envie uma mensagem para uma caixa de correio que você controla fora dos domínios do Zimbra. Confirme se o host autorizado pode enviá-la e se os logs do MTA mostram aceitação ou entrega bem-sucedida. A atividade do Zimbra MTA geralmente é registrada /var/log/zimbra.log; verifique o carimbo de data/hora e o endereço IP de origem relevantes, em vez de confiar apenas na mensagem de sucesso do cliente de e-mail.
Em seguida, teste a partir de um host que não esteja na lista de permissões e que não esteja autenticado. O resultado esperado é uma negação de retransmissão quando tentar enviar para um destinatário não local. Verifique o log do MTA para a conexão rejeitada e o endereço de origem observado pelo Postfix. Um cliente não autenticado ainda pode ter permissão para enviar para destinatários locais do Zimbra; isso é uma recepção normal de e-mail e não prova que ele possa retransmitir e-mails de saída.
Teste também qualquer aplicação legítima que estivesse na lista antiga. Uma falha no envio de uma aplicação geralmente significa que o endereço de origem errado foi adicionado à lista de permissões, que uma dependência confiável antiga foi removida ou que a aplicação precisa de autenticação SMTP. Se os clientes transitam entre redes ou se o IP de saída deles não for estável, a autenticação SMTP sobre TLS geralmente é mais fácil de gerenciar do que alterar repetidamente uma lista de permissões de IP.
Como reverter ou solucionar problemas
Se os aplicativos aprovados pararem de enviar dados, restaure o valor exato salvo em vez de adicionar uma sub-rede estimada. Aplique-o com ` zmprov mspostfix --help`, recarregue o Postfix e confirme o valor efetivo com ` postconf mynetworkspostfix --help`. Verifique se um balanceador de carga, gateway NAT, host de contêiner ou proxy de saída altera o endereço de origem antes que ele chegue ao MTA.
Uma Relay access deniedresposta negativa também pode significar que o cliente não está autenticado e seu endereço IP de origem não está na lista de confiáveis. Para usuários comuns de e-mail, configure o envio SMTP com autenticação em vez de adicionar todas as redes do usuário à lista de permissões zimbraMtaMyNetworks. Listas de permissões amplas criam uma superfície de retransmissão não autenticada maior e podem expor o servidor a abusos se uma rede confiável contiver dispositivos não gerenciados.
Se o valor do MTA parecer correto, mas o comportamento não mudar, confirme se você editou o servidor que aceitou a conexão, se a recarga foi bem-sucedida e se nenhuma outra instância do Postfix ou dispositivo de rede está processando SMTP. Não edite diretamente os arquivos do Postfix gerados pelo Zimbra como uma solução permanente; o gerenciamento de configuração pode regenerá-los. Consulte a documentação de administração do Zimbra da sua versão ou o canal de suporte para obter os procedimentos específicos da versão quando o valor do LDAP e a configuração de tempo de execução apresentarem divergências.
Como é um resultado bem-sucedido?
postconf mynetworksLista apenas os endereços de loopback e as redes ou endereços de origem confiáveis pretendidos.
- O aplicativo aprovado, mas não autenticado, pode enviar mensagens para uma caixa de correio de teste externa.
- Um host não autenticado e não aprovado recebe uma negação de retransmissão para um destinatário externo.
- Usuários autenticados e o recebimento de e-mails locais continuam funcionando conforme o esperado.
- O valor de reversão registrado e a lista de serviços dependentes são mantidos para alterações futuras.
Este método restringe o tráfego de retransmissão não autenticada por endereço IP de origem. Ele não substitui a autenticação SMTP, TLS, controles de taxa, segurança de contas ou monitoramento, e não consegue distinguir aplicações individuais que compartilham um mesmo endereço NAT público. Utilize-o como um controle específico e revise a lista de permissões sempre que houver alterações nas funções de saída de rede ou MTA.
Fontes