Configurar Sophos Firewall Mail Protection em modo MTA

A Sophos Firewall pode não só permitir tráfego de email como uma ligação normal de firewall, mas também trabalhar em modo MTA como Mail Transfer Agent entre a Internet e o servidor de email interno. A firewall aceita ligações SMTP, verifica as mensagens com Mail Protection e entrega-as depois ao servidor de email definido.

Hoje recomendamos Mail Protection na firewall apenas para casos especiais planeados conscientemente, por exemplo quando um Exchange local ou outro servidor de email interno deve ser protegido diretamente através da firewall. Para Microsoft 365, Google Workspace e a maioria dos ambientes modernos de email na cloud, Sophos Central Email é normalmente a melhor solução. Central Email está mais perto do serviço de email real, integra-se de forma mais limpa com caixas de correio cloud, reduz a complexidade no conjunto de regras da firewall e evita muitos temas clássicos de MTA, como alterações MX, spools locais, questões de relay e análise de erros na firewall.

Outro ponto prático: em comparação com Sophos Central Email, Email Protection na firewall parece há já algum tempo uma função de ambientes existentes, que continua relevante sobretudo para servidores de email on-premises já instalados. Quem planeia hoje um projeto novo deve, por isso, verificar primeiro se um cloud mail gateway é a arquitetura mais limpa.

A solução é tecnicamente forte, mas também propensa a erros se DNS, registo MX, TLS, relay, verificação de utilizadores, policies e logs não forem planeados de forma cuidada. Um MTA mal configurado pode bloquear emails legítimos, atrasar o mailflow ou, no pior caso, ser entendido como relay.

Este artigo explica a configuração prática de Sophos Firewall Mail Protection em modo MTA. Não substitui um planeamento de Sophos Central Email. Para muitos ambientes Microsoft 365 ou Google Workspace, um cloud mail gateway é frequentemente mais adequado. Mas quando se opera um Exchange local, um servidor de email híbrido ou um caminho SMTP deliberadamente baseado na firewall, é necessário um plano operacional claro.

Quando Mail Protection na firewall faz sentido

Mail Protection na Sophos Firewall faz sentido sobretudo quando o tráfego SMTP deve passar deliberadamente pela firewall e a firewall deve fazer mais do que apenas encaminhar a porta 25.

Cenários típicos:

• Emails recebidos devem ser primeiro aceites e verificados na firewall.
• Um servidor de email interno não deve estar diretamente acessível a partir da Internet.
• A verificação de spam, malware, tipos de ficheiro ou conteúdo deve atuar antes da entrega.
• Emails enviados devem ser enviados de forma controlada através da firewall ou de um smarthost.
• Quarentena, mail spool e logs SMTP devem ser rastreáveis na firewall.

Nem todas as configurações de email devem passar pela firewall. Se Sophos Central Email, Microsoft Defender for Office 365 ou outro cloud mail gateway já trata todo o mailflow, Mail Protection na firewall não deve ser colocado adicionalmente no caminho sem documentar exatamente o fluxo de email. Gateways duplicados levam rapidamente a responsabilidades pouco claras em quarentena, cabeçalhos, SPF/DKIM/DMARC, TLS e troubleshooting.

Distinguir modo MTA, Legacy mode e SMTP Relay

Na Sophos Firewall é preciso separar claramente três coisas:

O MTA mode é o modo-alvo normal para cenários modernos de Mail Protection na firewall. O serviço local SMTP Relay, por outro lado, é um tema de Device Access. Deve estar acessível apenas a partir de redes internas definidas. Uma autorização demasiado ampla pode favorecer abuso de relay. O reforço de serviços locais está descrito em Proteger o acesso à Sophos Firewall: configurar Device Access corretamente.

Requisitos

Antes da configuração, estes pontos devem estar esclarecidos:

• Sophos Firewall com Email Protection válida ou bundle adequado.
• Nem todos os modelos suportam MTA mode. XGS 87 e XGS 88 são appliances sem suporte de MTA mode.
• Zona DNS pública e registo MX são conhecidos.
• Servidor de email interno, porta de destino e caminho de entrega estão documentados.
• Endereço IP público ou endereço WAN para tráfego SMTP recebido está definido.
• A firewall consegue encaminhar e alcançar o servidor de email interno.
• O acesso DNS de saída da firewall funciona.
• A estratégia TLS e de certificados pretendida está esclarecida.
• O processo de quarentena e libertação está definido a nível organizacional.

Antes de alterações ao mailflow, deve ser planeada uma janela de manutenção. Um teste em registos MX produtivos sem plano de fallback é arriscado, porque emails recebidos podem ser rapidamente atrasados ou rejeitados dependendo do remetente.

Definir a arquitetura-alvo

Primeiro deve decidir-se que direção a firewall deve processar.

Mailflow recebido

No mailflow recebido, os registos MX externos apontam para o endereço público no qual a Sophos Firewall aceita SMTP. A firewall verifica a mensagem e encaminha-a para o servidor de email interno.

Fluxo típico:

1. O remetente externo liga-se por SMTP ao endereço MX público.
2. A Sophos Firewall aceita a ligação em MTA mode.
3. Mail Protection verifica remetente, destinatário, spam, malware, anexos e policy.
4. A firewall entrega o email ao servidor de email interno.
5. O servidor de email interno entrega na caixa de correio ou processa a mensagem.

É importante que o servidor de email interno não continue também acessível sem filtragem a partir da Internet. Se em paralelo ainda existir uma regra DNAT diretamente para o servidor de email, uma parte do tráfego pode contornar Mail Protection. Para publicações normais de servidores, Publicar servidor por DNAT é a base adequada, mas em MTA mode a própria firewall é o ponto de aceitação SMTP.

Mailflow enviado

No mailflow enviado, o servidor de email interno envia através da Sophos Firewall. A firewall pode verificar mensagens, encaminhá-las para um smarthost ou entregá-las diretamente, consoante a configuração.

Esclarecer previamente:

• O IP público da firewall pode enviar emails diretamente?
• SPF, DKIM e DMARC estão corretos para o caminho de envio escolhido?
• É necessário um smarthost do provider?
• O tráfego SMTP enviado deve ser limitado a determinados sistemas internos?
• Onde são monitorizadas mensagens rejeitadas ou atrasadas?

Para tráfego de email enviado deve ser usada uma estrutura própria e rastreável de regras e policies. Uma regra geral LAN to WAN sem restrição clara é normalmente demasiado ampla para servidores de email. Os fundamentos de ordem de regras e perfis de segurança estão em Compreender e construir corretamente regras da Sophos Firewall.

Preparar alteração MX e testes externos

Uma alteração de Mail Protection só se torna crítica quando remetentes externos usam realmente o novo caminho. Por isso, registo MX, DNS TTL, acessibilidade externa e rollback devem ser verificados antes da alteração produtiva.

Antes da alteração:

• Documentar registo MX atual, prioridade e TTL.
• Reduzir cedo o DNS TTL se puder ser necessário um fallback rápido.
• Distinguir claramente o caminho de email antigo e o novo endereço da Sophos Firewall.
• Identificar regras DNAT antigas diretas para o servidor de email.
• Definir destinatários e remetentes de teste.
• Definir plano de fallback: MX antigo, regra DNAT antiga ou smarthost temporário.
• Preparar monitoring de spool, quarentena e queue do servidor de email.

Verificações externas úteis a partir de um sistema fora da própria rede:

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Os comandos não substituem um teste completo de mailflow, mas mostram rapidamente se DNS, porta 25 e STARTTLS estão basicamente acessíveis. example.com e mail.example.com devem ser substituídos pelo domínio real e pelo mailhost real.

Depois da mudança, deve enviar-se imediatamente um email de teste recebido e documentar todo o caminho:

• Ligação visível no Log Viewer?
• Entrada presente em smtpd_main.log?
• Verificação do destinatário bem-sucedida?
• Entrega ao servidor de email interno efetuada?
• Mensagem chegou à caixa de correio?
• Sem entrega direta paralela a contornar o MTA?

Se a firewall aceita emails mas não os entrega, o MX não deve ser reposto de imediato. Primeiro é preciso esclarecer se existe um problema interno de routing, DNS, TLS ou servidor de email. Mas se remetentes externos não conseguem estabelecer ligação à firewall ou emails legítimos são rejeitados em grande escala, um fallback rápido para o caminho de email anterior é muitas vezes mais sensato do que experiências prolongadas no caminho MX produtivo.

Ativar MTA mode

As definições básicas encontram-se na Sophos Firewall em:

Email > General settings

É aí que o modo de email é definido. Para este guia, MTA mode é relevante. Depois da mudança, deve verificar-se se as policies, objetos host e domínios de email existentes ainda correspondem à operação pretendida.

Em ambientes existentes, não alternar simplesmente entre Legacy mode e MTA mode sem testar o mailflow. O processamento, os logs e a lógica de policy diferem. Antes de uma migração, devem ser documentados a configuração atual da firewall, os registos MX, conectores do servidor de email e definições de relay.

Configurar routing SMTP e domínios

Para emails recebidos, a firewall tem de saber que domínios deve aceitar e para onde deve entregá-los.

Fluxo típico:

1. Em Email > Policies and exceptions ou nas áreas de Mail Protection, planear os domínios e servidores de destino afetados.
2. Introduzir domínio de email, por exemplo example.com.
3. Definir servidor de email interno ou objeto host como destino de entrega.
4. Verificar se a firewall alcança o servidor de email na porta de destino.
5. Verificar requisitos TLS e certificados.
6. Enviar email de teste do exterior para um destinatário conhecido.

Para servidores de email internos, DNS é especialmente importante. A firewall deve conseguir resolver corretamente destinos internos, e remetentes externos devem alcançar a entrada MX pública. Se a resolução DNS interna tiver relevância, Configurar DNS Request Routes na Sophos Firewall ajuda.

Planear policies para spam, malware e anexos

Mail Protection é tão boa quanto as policies que efetivamente se aplicam. Uma policy não deve apenas ser criada, mas nomeada com um objetivo claro.

Questões importantes sobre policies:

• Que domínios ou grupos de destinatários são afetados?
• É processado tráfego de email recebido, enviado ou bidirecional?
• O que acontece com spam, malware, anexos suspeitos ou tipos de ficheiro indesejados?
• Os emails são bloqueados, colocados em quarentena, entregues ou marcados com cabeçalhos?
• Quem pode verificar a quarentena e libertar emails?
• Que processos de falsos positivos existem?

Se Zero-Day Protection for usado, anexos de email suspeitos podem ser analisados adicionalmente. Os limites, relatórios e decisão de libertação são explicados em Compreender e operar Sophos Firewall Zero-Day Protection.

Proteger relay e Device Access

Um erro frequente é confundir mailflow MTA com um SMTP Relay aberto. A firewall não pode ser usada como relay a partir de redes arbitrárias.

Verificar:

• Em Administration > Device access, SMTP Relay está acessível apenas a partir das zonas internas necessárias.
• Se forem usadas ACL Exception Rules, as origens estão definidas de forma restrita.
• Apenas servidores de email internos, scanners ou servidores aplicacionais definidos podem fazer relay através da firewall.
• A partir de WAN, redes guest e zonas untrusted, SMTP Relay não está genericamente autorizado.
• Logging está ativo para que abusos ou configurações incorretas sejam visíveis.

Se impressoras, scanners ou aplicações precisarem de enviar emails, deve ser documentado um caminho de relay interno próprio para isso. Esses sistemas não devem comunicar diretamente com destinos SMTP externos arbitrários quando o ambiente o puder evitar.

Testar o mailflow

Depois da configuração, um único envio bem-sucedido não basta. Devem ser realizados vários testes e os resultados documentados.

Testar recebido

Verificar pelo menos:

• O registo MX externo aponta para o endereço esperado.
• A porta 25 está acessível a partir do exterior.
• A firewall aceita a ligação em MTA mode.
• O email é encaminhado para o servidor de email interno.
• O destinatário existe e recebe a mensagem.
• O teste de spam ou malware é tratado como esperado.
• A entrada de quarentena ou log é rastreável.

Testar enviado

Verificar pelo menos:

• O servidor de email interno envia pela rota esperada.
• A regra de firewall e a mail policy aplicam-se.
• SPF, DKIM e DMARC correspondem ao caminho de envio.
• O servidor de destino aceita a mensagem.
• Bounces ou mensagens Deferred são monitorizados.
• Nenhum outro sistema interno envia diretamente para fora sem planeamento.

Verificar logs

Para uma verificação visual rápida, Log Viewer ajuda. Para análise mais profunda, os ficheiros de log de email são importantes. A correspondência está em Troubleshooting Sophos Firewall: serviços e logs.

Ficheiros de log relevantes:

Em troubleshooting urgente, deve anotar-se o momento do teste, recolher remetente, destinatário, assunto, IP de origem e Message-ID, e depois correlacionar Log Viewer e ficheiros de log temporalmente.

Quarentena, spool e armazenamento

Mail Protection gera dados locais. Consoante o volume, mensagens acabam em quarentena, spool ou áreas temporárias. Por isso, espaço de armazenamento, estado do SSD e plano de recovery tornam-se mais relevantes do que numa regra de firewall pura.

Questões operacionais práticas:

• Quem verifica a quarentena e com que frequência?
• Como são libertados os falsos positivos?
• Quando é que uma mensagem é eliminada em vez de libertada?
• Como é detetado um mail spool crescente?
• Existe monitoring para espaço de armazenamento e System Health?
• Depois de firmware updates é planeado um curto teste de mailflow?

Para temas de armazenamento e reporting, são adequados Limpar armazenamento e reports da Sophos Firewall e Verificar Sophos Firewall SSD Health. Em ambientes HA deve ainda considerar-se que a quarentena de email e dados de email processados podem ser dados operacionais específicos de um nó. As bases HA estão em Variantes de cluster HA Sophos Firewall.

Troubleshooting

Emails externos não chegam

Primeiro verificar DNS e acessibilidade: registo MX, IP público, porta 25, restos de NAT, MTA mode e domínio de email responsável. Depois verificar no Log Viewer e em smtpd_main.log se a ligação chega à firewall. Se nenhuma ligação for visível, o problema provavelmente está antes de Mail Protection.

A firewall aceita emails, mas não os entrega

Então são mais prováveis servidor de email interno, routing, DNS, porta de destino, TLS, verificação de destinatário ou policy. Verifica-se se a firewall consegue alcançar o servidor de email e se o servidor aceita a ligação. Reject logs e logs do servidor de email devem ser avaliados em conjunto no tempo.

Muitos emails ficam no spool

Um spool crescente aponta frequentemente para problemas de entrega: servidor de email interno não acessível, requisito TLS não corresponde, resolução DNS falha ou servidor de destino rejeita a mensagem. Neste caso, não se devem apenas reenviar mensagens individuais, mas procurar a causa no caminho de routing e SMTP.

Um caso importante de ordem de regras é facilmente ignorado: se uma regra de firewall criada automática ou manualmente estiver acima da regra MTA e fizer match com tráfego SMTP, a regra MTA real deixa de ser avaliada. Emails podem então ficar presos no mail spool, embora DNS, porta 25 e servidor de email pareçam basicamente corretos.

Verificar:

1. Abrir Rules and policies > Firewall rules.
2. Verificar regras acima da regra MTA ou SMTP.
3. Controlar novas regras criadas automaticamente, regras IPsec, regras hotspot ou regras colocadas manualmente em Top.
4. Repetir o teste SMTP e comparar Log Viewer, mail spool e smtpd_main.log.

A regra não deve ser movida cegamente para baixo se cumprir outros objetivos produtivos. O ponto decisivo é se ela interceta inesperadamente tráfego SMTP antes da regra MTA.

Falta digest de quarentena para endereços alias

Se os utilizadores usam endereços alias, as definições de quarentena não devem ser verificadas apenas para o endereço de email principal. Segundo a Sophos, as definições de quarentena não são aplicadas automaticamente por defeito a endereços alias. Se faltarem emails digest ou libertações para destinatários alias, os endereços alias têm de ser considerados juntamente com o endereço principal no contexto de quarentena ou de utilizador.

Remetente legítimo é detetado como spam

Falsos positivos não devem ser respondidos de imediato com exceções amplas. Primeiro verificar domínio do remetente, SPF/DKIM/DMARC, cabeçalhos, reputação, policy match e destinatários afetados. Se uma exceção for necessária, deve ser estritamente limitada e documentada com data de revisão.

Sistemas internos não conseguem fazer relay

Verificar se SMTP Relay em Administration > Device access está permitido a partir da zona correta e se a origem corresponde à ACL. Depois verificar os logs de email. Se um scanner ou uma aplicação deve fazer relay, a origem deve ser documentada como objeto host e não deve ser permitido desnecessariamente um segmento inteiro de rede.

Depois de firmware update o email comporta-se de forma diferente

Depois de firmware updates devem ser verificados MTA mode, policies, certificados, mail spool, quarentena e logs relevantes. Para updates maiores, também é adequado Verificar Sophos Firewall antes do upgrade para SFOS 22.

Checklist operacional

• Licença Mail Protection e suporte da appliance verificados.
• MTA mode escolhido conscientemente e documentado.
• Registo MX, IP público e servidor interno de destino corretos.
• Alteração MX, testes externos e rollback preparados.
• Nenhuma regra DNAT paralela sem filtragem contorna o MTA.
• Policies recebidas e enviadas nomeadas de forma compreensível.
• A ordem das regras da firewall não impede que a regra MTA se aplique.
• SMTP Relay permitido apenas a partir de origens internas definidas.
• Processo de quarentena e falsos positivos definido.
• Endereços alias considerados no processo de quarentena e digest.
• Mail spool, espaço de armazenamento e System Health monitorizados.
• Logs mantidos localmente, no Sophos Central ou via Syslog durante tempo suficiente.
• Depois de firmware updates é realizado um teste de mailflow.

Para retenção mais longa e correlação com outros eventos de segurança, deve verificar-se Central Firewall Reporting ou Enviar Sophos Firewall Syslog para SIEM.

FAQ