Configurar Sophos Firewall Mail Protection em modo MTA

Em MTA mode, a Sophos Firewall aceita os emails, analisa-os e entrega-os ao servidor de correio interno ou ao mail hop seguinte. O mailflow só funciona quando o registo MX, a regra MTA automática, a SMTP route and scan Policy, o relay, TLS e a verificação de destinatários estão coordenados.

A configuração tem seis passos: definir o mailflow e o caminho de fallback, ativar MTA mode, adicionar o domínio, criar a route and scan Policy, proteger o relay e alterar o registo MX. Depois, validam-se os fluxos de entrada e saída com comandos externos, quarentena, spool e logs.

Quando utilizar MTA mode

Mail Protection na firewall é sobretudo adequada a ambientes on-premises e híbridos planeados, nos quais é necessário proteger um Exchange local ou outro servidor de correio. Para Microsoft 365, Google Workspace e muitos ambientes exclusivamente cloud, Sophos Central Email ou outro gateway de email cloud é normalmente uma arquitetura mais clara. Dois gateways em sequência complicam quarentena, headers, TLS, SPF/DKIM/DMARC e troubleshooting.

É necessário distinguir três funções da Sophos Firewall:

• MTA mode: a firewall aceita, analisa e encaminha o email.
• Legacy mode: processamento proxy transparente antigo para ambientes existentes.
• SMTP Relay em Device Access: controla as zonas a partir das quais o MTA está acessível. O email recebido da Internet requer WAN; o relay de saída é ainda limitado a servidores internos específicos.

São necessários uma licença Email Protection válida, routing e DNS funcionais, um IP público conhecido, o servidor interno com a porta de destino e estratégias definidas de TLS, quarentena e fallback. Segundo a visão geral atual da Sophos, MTA mode não está disponível em XGS 87/87w e XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation e SXL2 Live Protection requerem acesso à Internet. Routing de email, análise de malware, filtragem MIME e SPX podem continuar a funcionar com a licença adequada num ambiente airgap, mas um MTA ativo não significa que todos os controlos de proteção estejam disponíveis.

Configurar MTA mode de ponta a ponta

1. Definir o mailflow e o caminho de fallback

No fluxo de entrada, o registo MX público aponta para o endereço em que a Sophos Firewall aceita TCP 25. A firewall analisa a mensagem e entrega-a ao servidor interno. Uma regra DNAT antiga não pode deixar esse servidor diretamente acessível da Internet sem análise, pois permitiria contornar o MTA. Publicar um servidor com DNAT explica a lógica geral de DNAT.

No fluxo de saída, apenas o servidor previsto envia através da firewall. O caminho, smarthost, PTR/rDNS, HELO, SPF, DKIM e DMARC devem corresponder à identidade pública do remetente. Uma regra geral LAN to WAN é demasiado ampla; a base de regras deve identificar claramente o remetente SMTP autorizado. Compreender as regras da Sophos Firewall aborda a ordem das regras.

Antes da migração, documentar:

• registo MX atual, prioridade e TTL;
• novo endereço público da firewall e servidor de destino interno;
• regras DNAT e SMTP existentes e conectores do servidor;
• remetentes de teste de entrada e saída;
• MX ou caminho de correio anterior como fallback;
• monitorização da fila do servidor, spool da firewall e quarentena.

Reduzir o TTL antecipadamente se puder ser necessário um rollback rápido. As alterações ao MX de produção pertencem a uma janela de manutenção.

2. Configurar MTA mode e as definições SMTP básicas

Em Email > General settings, selecionar Switch to MTA mode se necessário. A Sophos Firewall cria a regra Any-to-Any Auto added firewall policy for MTA para SMTP e SMTPS. Não editar esta regra e mantê-la no topo da lista. A mudança para Legacy mode elimina-a; o regresso a MTA mode volta a criá-la.

Configurar as definições básicas:

1. Em SMTP hostname, introduzir o domínio, por exemplo example.com, e não o hostname do servidor interno. O valor aparece em HELO e no banner SMTP das notificações geradas pelo sistema.
2. Ativar Reject based on IP reputation para rejeitar remetentes com má reputação.
3. Em SMTP TLS configuration, escolher um certificado publicamente fidedigno e permitir Allow invalid certificate apenas em exceções documentadas.
4. Ativar Disable legacy TLS protocols, salvo necessidade documentada de sistemas antigos. A opção desativa protocolos anteriores a TLS 1.1, mas não impõe automaticamente apenas versões TLS atuais.
5. Ativar Scan outgoing mails se as mensagens de saída também forem analisadas.

Utilizar Require TLS negotiation com cuidado: se o SFOS não conseguir estabelecer o TLS exigido, elimina email para o destino afetado ou proveniente do domínio remetente configurado. A firewall valida SMTP TLS pelo IP do domínio, não pelo nome; vários domínios no mesmo IP podem provocar erros de certificado.

3. Adicionar o domínio como Address Group

1. Abrir Email > Address group > Add.
2. Definir Group type como Email address/domain e Type como Manual.
3. Adicionar o domínio protegido, por exemplo example.com.
4. Guardar o grupo.

As novas SMTP route and scan Policies são planeadas para domínios, não para endereços individuais. Endereços migrados podem continuar ativos, mas não podem ser adicionados ou editados nas policies atuais.

4. Criar uma SMTP route and scan Policy

Abrir Email > Policies and exceptions > Add a policy > SMTP route and scan:

1. Introduzir um nome claro, por exemplo Inbound example.com to Exchange.
2. Em Protected domain, selecionar a Address Group.
3. Escolher Route by:
   • Static host: IP fixo do servidor interno; em caso de falha, a firewall tenta o host seguinte.
   • DNS host: nome DNS como mailserver.example.com; vários registos A são usados entre entregas e servidores indisponíveis são ignorados.
   • MX: entrega baseada num registo MX.
4. Para Static host, selecionar o servidor em Host list. Se necessário, criar o IP host em Hosts and services > IP host.
5. Definir Global action como Accept.
6. Ativar Spam protection e Malware protection conforme o conceito operacional.
7. Ativar File protection e Data protection apenas depois de compreender o impacto em anexos, mensagens grandes, SPX e DKIM.
8. Guardar a policy.

Com Route by MX, o MX resolvido pela firewall não pode apontar para a mesma firewall, caso contrário cria um loop de routing. A firewall tem de resolver corretamente destinos internos; para split DNS são úteis as DNS Request Routes.

Route inbound mail through gateway só é necessária em designs especiais, como servidores na zona WAN, aplicação da regra original a destinos LAN/DMZ ou escolha de gateway com várias ligações. Não a ativar sem uma necessidade concreta de routing.

5. Proteger o acesso de entrada e o relay de saída

Em Administration > Device access, permitir SMTP Relay de todas as zonas que precisam de alcançar o MTA. O email da Internet requer WAN; o email de saída requer também a zona do servidor interno, normalmente LAN ou DMZ. Depois, em Email > Relay settings > Host-based relay, limitar o acesso a servidores, scanners ou aplicações específicos.

Permissões amplas de hosts ou redes criam risco de open relay. Impressoras e aplicações que enviam email devem ser documentadas como host objects específicos. Proteger o acesso à Sophos Firewall explica Device Access.

A SMTP route and scan Policy não suporta SMTP AUTH. Para dispositivos, Host-based relay é portanto a opção fiável. Existem Authenticated relay settings separados para utilizadores e grupos; a Sophos indica, porém, que não suportam um standard SMTP Authentication conforme às RFC, pelo que a compatibilidade do cliente deve ser testada. Isto difere da autenticação da firewall num upstream smarthost, para a qual o SFOS suporta PLAIN e LOGIN. Nunca utilizar um IP de interface da própria firewall como smarthost, pois cria um loop de routing.

6. Alterar o registo MX

Alterar o MX público para o endereço da firewall apenas quando regra MTA, domínio, policy, relay e caminho interno estiverem prontos. Enviar imediatamente uma mensagem externa de teste e confirmar que aparece em Log Viewer ou Mail logs, é entregue ao servidor interno e chega à caixa de correio.

Se remetentes externos não alcançarem a firewall ou mensagens legítimas forem rejeitadas em massa, restaurar o caminho anterior documentado. Se a firewall aceitar mas não entregar, verificar primeiro routing, DNS, TLS, recipient verification e logs do servidor.

Escolher conscientemente as proteções

Spam protection é mais do que a ação aplicada ao spam. Falhas SPF e RBL são rejeitadas diretamente e não seguem as ações normais para spam ou probable spam. Greylisting rejeita temporariamente uma mensagem de forma intencional e exige nova tentativa do servidor remetente.

Recipient verification impede mensagens para destinatários desconhecidos:

• With callout: consulta o servidor de destino. Se estiver temporariamente indisponível, o SFOS aceita destinatários após um período definido em vez de bloquear permanentemente todo o mailflow.
• In Active Directory: verifica por Simple, SSL ou STARTTLS com timeout de 30 segundos.

Malware Protection pode usar análise antivírus simples ou dupla. Para Zero-Day Protection com análise simples, a Sophos deve ser o motor primário. Sophos Firewall Zero-Day Protection explica limites e decisões de libertação.

Nas mensagens de saída, a ordem de processamento é importante. Encriptação SPX, prefixos do assunto, File ou Data Protection e banners podem alterar header ou body depois de aplicada uma assinatura DKIM. A validação DKIM falha então no destinatário. Deve decidir-se se assina o servidor interno, a Sophos Firewall ou um gateway posterior.

Configurar e testar a encriptação de email SPX explica como o modelo, a prioridade dos acionadores, o modelo de palavra-passe e o Reply Portal funcionam em conjunto.

Validar o mailflow

Executar os seguintes comandos num sistema fora da rede:

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

Substituir example.com e mail.example.com pelos valores reais. Os comandos testam DNS, TCP 25 e STARTTLS, mas não autorização de relay nem entrega completa. openssl s_client permanece interativo após o handshake; terminar com Ctrl+C.

Testar pelo menos:

• mensagem externa para destinatário válido;
• mensagem externa para destinatário inválido;
• mensagem de saída pelo servidor previsto;
• teste de spam ou malware adequado à policy;
• STARTTLS e cadeia de certificados apresentada;
• ação de quarentena e entrega após libertação;
• tentativa de relay bloqueada a partir de origem não autorizada;
• inexistência de entrega direta que contorne o MTA através de DNAT antigo.

Para a primeira verificação utilizar Email > Mail logs, Email > Mail spool, Email > SMTP quarantine e Log Viewer. Para análise aprofundada, anotar hora do teste, remetente, destinatário, assunto, IP de origem e Message-ID e correlacionar:

• MTA: smtpd_main.log
• rejeições: smtpd_reject.log
• erros de análise: smtpd_error.log
• erros MTA internos: smtpd_panic.log
• anti-spam: sasi.log
• proxy SMTP legacy: awarrensmtp.log
• proxy POP/IMAP: warren.log

Serviços e logs da Sophos Firewall explica a correspondência e o acesso por Advanced Shell.

Operar a quarentena e o Mail spool

Em Email > SMTP quarantine, filtrar por período, remetente, destinatário, assunto e motivo:

• Release: entregar a mensagem.
• Delete: eliminar a mensagem.
• Release and report: libertar e comunicar à SophosLabs apenas falsos positivos classificados como Spam ou Probable spam.

Mensagens com vírus ou classificadas como maliciosas por Zero-Day Protection não podem ser libertadas. A eliminação de entradas Zero-Day Protection exige permissão de escrita no perfil de administrador. Quando a quarentena está cheia, são removidas mensagens antigas.

Só recebem resumos de quarentena os utilizadores autenticados pelo menos uma vez na firewall. Os aliases devem ser verificados separadamente; mensagens para aliases não aparecem no User Portal.

Email > Mail spool contém mensagens ainda não entregues ou com falha. O SFOS tenta entregar durante três dias e elimina-as após mais quatro; continuam visíveis em Mail logs. Um spool crescente alerta para problemas de routing, DNS, TLS, policy ou servidor e não é motivo para repetir Retry sem diagnóstico.

Quarentena e spool usam armazenamento local. Monitorizar espaço livre, estado SSD e System Health; ver Limpar armazenamento e reports e Verificar SSD Health. Em HA, logs e reports são separados por node e não sincronizados; verificar ambos. Clusters HA da Sophos Firewall explica os fundamentos.

Troubleshooting

O email externo não chega

Verificar MX, A/AAAA, IP público, TCP 25 e SMTP Relay de WAN. Confirmar MTA mode, correspondência do domínio protegido com a policy e ausência de DNAT antigo ou regra prioritária que altere o caminho. Se smtpd_main.log não mostrar ligação, o problema está provavelmente antes de Mail Protection.

A firewall aceita mas não entrega

Verificar servidor interno, route, DNS, porta, TLS e recipient verification. Static host, DNS host e MX usam caminhos diferentes de resolução e failover. Correlacionar logs reject e error com os logs do servidor.

Muitas mensagens ficam no spool

Verificar primeiro Email > Mail spool e os logs MTA. Uma causa comum é uma regra acima da regra MTA automática que já faz match de SMTP. Em Rules and policies > Firewall rules, verificar regras novas na posição Top, regras IPsec ou hotspot automáticas e outras sobreposições. Não mover regras sem análise; o match SMTP real é decisivo.

O SFOS 22.0 MR2 também corrige NC-177930, em que mensagens ficavam no spool após crash de mailpoller. Em versões anteriores, incluir o firmware no diagnóstico.

Central apresenta Invalid API request

No SFOS 22.0 MR1, Release e Delete podiam falhar quando a firewall era aberta pelo Sophos Central. O workaround seguro é iniciar sessão diretamente no WebAdmin local e executar a ação em Email > SMTP quarantine. O SFOS 22.0 MR2 Build 546 corrigiu o problema. Se persistir, verificar separadamente perfil de administrador, acesso Central e permissões locais.

Não é possível ativar Reject based on RBL

A Sophos lista em NC-144563 um caso específico da versão SFOS 20.0.2 MR2 Build 378: se os grupos RBL predefinidos em Email > Address group tiverem sido renomeados, não é possível ativar Reject based on RBL ao criar uma política SMTP route and scan. Numa política existente, a opção não pode voltar a ser ativada depois de ser desativada. A Known Issues List atual não indica uma versão corrigida.

Os grupos predefinidos chamam-se Premium RBL services e Standard RBL services. Primeiro, documentar o build exato e os nomes atuais dos grupos. Se ambas as condições se verificarem, restaurar os nomes originais das RBL predefinidas, reabrir a política e verificar a opção. Não confundir RBL personalizadas com estes dois grupos do sistema.

Noutros builds, ou quando os nomes predefinidos não foram alterados, uma opção a cinzento não comprova NC-144563. Verificar separadamente o tipo de política, Spam protection, a licença Email Protection e a restante configuração.

Um remetente legítimo é classificado como spam

Verificar domínio remetente, SPF/DKIM/DMARC, headers, reputação, policy match e destinatários. Só depois criar uma exceção restrita com data de revisão.

Sistemas internos não conseguem usar relay

Verificar zona de origem em Administration > Device access, host object em Email > Relay settings > Host-based relay e logs MTA. Se um scanner espera SMTP AUTH standard, Host-based relay é normalmente mais fiável. O Authenticated relay separado e não conforme às RFC deve ser testado com o cliente.

Checklist operacional

• Licença, suporte do modelo, DNS e serviços Internet necessários verificados.
• MX, TTL, caminhos público e interno e fallback documentados.
• Regra MTA automática inalterada e no topo.
• Nenhuma regra DNAT antiga contorna Mail Protection.
• Address Group, destino de routing e policy match testados.
• SMTP Relay de entrada de WAN e permissões de hosts de saída separados corretamente.
• Efeitos de SPF/RBL, recipient verification, TLS, DKIM, SPX e banners compreendidos.
• Testes externos positivos e negativos realizados.
• Quarentena, spool, armazenamento e logs monitorizados.
• Mailflow testado novamente após atualizações de firmware.

Para retenção e correlação mais longas, utilizar Central Firewall Reporting ou enviar logs da Sophos Firewall para um SIEM.

FAQ