Configurar o Sophos Firewall MTA com o Microsoft 365

O Sophos Firewall pode funcionar em MTA mode como gateway de email separado à frente do Microsoft 365. As mensagens de entrada chegam primeiro à firewall e são depois entregues ao Exchange Online Protection. O Exchange Online envia as mensagens de saída de volta à firewall através de um conector, para serem analisadas e encaminhadas para a Internet.

Este design é possível, mas não é automaticamente a melhor arquitetura. Sophos Central Email, Microsoft Defender for Office 365 e Mail Protection na firewall sobrepõem-se parcialmente. Antes da alteração deve ficar claro qual sistema é responsável por spam, malware, quarentena, TLS, DKIM e diagnóstico.

⚠️ Uma autorização de relay demasiado ampla pode transformar a firewall num open relay. Antes de alterar o MX mantêm-se disponíveis uma sessão de administração local, o fluxo atual e um caminho de recuperação testado. A mudança produtiva só ocorre quando uma tentativa de relay não autorizada é rejeitada de forma fiável.

Desenhar primeiro o fluxo bidirecional

O caminho de entrada é Internet → Sophos Firewall MTA → Exchange Online Protection → caixa Microsoft 365. O registo MX público aponta, por isso, para o endereço SMTP público da firewall. A política SMTP route and scan entrega depois ao destino Microsoft específico do tenant, por exemplo example-com.mail.protection.outlook.com.

O caminho de saída é Exchange Online → conector Microsoft 365 → Sophos Firewall MTA → Internet. A firewall só deve aceitar relay das redes Exchange Online Protection atuais. HELO, certificado, IP de origem público, PTR/rDNS, SPF, DKIM e DMARC têm de corresponder a este caminho.

Configurar Mail Protection em MTA mode explica os fundamentos MTA, os campos da política, a quarentena e os logs. Este artigo concentra-se na ligação ao Microsoft 365.

Valores de exemplo e requisitos

O exemplo usa o domínio example.com, o FQDN da firewall mail.example.com, o endereço de documentação 192.0.2.25 e o destino do tenant example-com.mail.protection.outlook.com. Devem ser substituídos pelo domínio real, um endereço público fixo e o destino Microsoft efetivo. 192.0.2.25 pertence a TEST-NET e não pode ser usado em produção.

TCP 25 tem de funcionar da Internet para a firewall, da firewall para o Microsoft 365 e da firewall para servidores de email externos. São ainda necessários uma licença Email Protection adequada, suporte MTA no modelo, um certificado de confiança pública, acesso DNS controlado e permissões no Exchange Admin Center e no DNS autoritativo.

As redes Exchange Online Protection mudam. Não são copiadas de um exemplo estático, mas mantidas a partir da lista atual de endpoints Microsoft 365 indicada pela Sophos. Os endpoints SMTP em TCP 25 são especialmente relevantes. Documentam-se o responsável e o intervalo de revisão dos objetos host.

Ligar o Microsoft 365 ao SFOS em oito passos

1. Registar MX, SPF, conectores, headers, IP de origem público e caminho de recuperação atuais.
2. Preparar MTA mode, regra MTA automática, certificado e análise de saída no SFOS.
3. Criar objetos IP host separados para os intervalos EOP atuais.
4. Permitir SMTP Relay a partir de WAN, limitar Host-based relay aos objetos EOP e bloquear as restantes origens.
5. Criar uma política SMTP route and scan para o domínio protegido e o destino Microsoft do tenant.
6. Criar no Exchange Online um conector do Microsoft 365 para o endereço público da firewall.
7. Alterar MX e SPF numa janela de manutenção.
8. Validar mensagens de entrada, saída e tentativas de relay rejeitadas com headers, Mail logs, spool e traces Microsoft.

Preparar o Sophos Firewall

MTA mode, regra automática e certificado

Ativar MTA mode em Email > General settings. O SFOS cria Auto added firewall policy for MTA para SMTP e SMTPS. A regra não é editada e permanece no topo, conforme a recomendação Sophos. Se faltar apesar de MTA mode estar ativo, não se cria uma substituição Any-to-Any; verificam-se primeiro o modo, a configuração e o caminho de suporte.

Em SMTP settings, definir SMTP hostname com o domínio previsto. Em SMTP TLS configuration, selecionar um certificado de confiança pública e manter Allow invalid certificate desativado. Scan outgoing mails tem de estar ativo se as mensagens provenientes do Exchange Online também forem analisadas.

Permitir relay a partir das origens EOP

Em Hosts and services > IP host, criar um objeto com nome claro para cada intervalo IPv4 EOP atual, por exemplo com o prefixo O365_EOP_. Não agregar os intervalos numa rede maior. Após uma alteração Microsoft, as redes são adicionadas ou removidas de forma controlada e novamente testadas.

Ativar SMTP Relay para WAN em Administration > Device access. Este seletor de zona é demasiado amplo por si só e é, por isso, restringido em Email > Relay settings > Host-based relay:

• Allow relay from hosts/networks: apenas os objetos EOP mantidos;
• Block relay from hosts/networks: Any.

A Sophos avalia uma correspondência Allow antes do Block sobreposto. Por isso, a lista Allow não pode conter redes amplas de operador, cloud nem Any. Upstream host controla uma relação de destino separada e não substitui esta verificação da origem.

Para o email normal recebido da Internet, o procedimento Sophos define Upstream host > Allow relay from hosts/networks como Any. Isto permite que hosts SMTP externos entreguem aos domínios protegidos e não é a mesma autorização que o Host-based relay de saída. Se já existir um gateway externo definido à frente do SFOS, a lista Upstream é limitada às respetivas redes de origem reais.

Política route and scan para entrega ao Microsoft

Criar o domínio protegido como Email address/domain em Email > Address group. Depois adicionar em Email > Policies and exceptions > Add a policy > SMTP route and scan uma política com:

• o Address Group em Protected domain;
• Global action: Accept;
• Route by: DNS host e o destino Microsoft específico do tenant;
• opções de proteção contra spam, malware, ficheiros e dados escolhidas conscientemente.

O host de routing não é o MX público de example.com depois de este apontar para a firewall. Caso contrário, a firewall entrega a si própria e cria um ciclo. O destino Microsoft real é registado antes da alteração do MX e a sua resolução correta pelo SFOS é verificada.

Criar o conector do Exchange Online

No Exchange Admin Center, criar em Mail flow > Connectors um conector From: Office 365 e To: Partner organization. Para encaminhar todo o email de saída pelo SFOS, a condição de destino aplica-se a todos os domínios destinatários (*). Um subconjunto limitado deve corresponder ao design documentado. Usar o IP público ou o FQDN mail.example.com da firewall como smarthost.

Exigir TLS no conector. A ajuda Sophos também mostra uma opção compatível que aceita qualquer certificado digital, incluindo certificados autoassinados. Em produção é mais robusto um certificado de confiança pública cuja identidade corresponda ao FQDN, validado com um teste real do conector.

A validação do conector pode falhar antes da alteração DNS. Não substitui, portanto, o teste end-to-end posterior nem o teste negativo de relay. Depois de guardar, o Microsoft Message Trace deve confirmar que as mensagens de saída usam realmente o conector e a firewall previstos.

Alterar MX e SPF de forma controlada

O MX público só aponta para mail.example.com quando a política, o relay EOP, o destino Microsoft interno e o conector estiverem prontos. O TTL é reduzido antes da janela. O destino MX anterior mantém-se disponível para o rollback documentado, mas não em paralelo se os remetentes puderem contornar aleatoriamente a nova proteção.

O SPF deve autorizar o Exchange Online e a identidade de envio pública da firewall. A Sophos mostra v=spf1 include:spf.protection.outlook.com mx -all como exemplo simples. O registo existente não é substituído sem análise: primeiro inventariam-se outros remetentes, subdomínios, cadeias include e o limite de consultas DNS. DKIM e DMARC são novamente verificados em headers reais.

Validar o caminho completo

A partir de um sistema de teste externo ajudam estas verificações de leitura:

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 nomes de exemplo são substituídos pelos valores reais. DNS, TCP e TLS não comprovam entrega. Testam-se pelo menos uma mensagem externa para o Microsoft 365, uma mensagem de saída do Microsoft 365, um destinatário inválido e uma tentativa de relay a partir de um IP não autorizado.

No SFOS, correlacionar Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log e smtpd_error.log com o mesmo momento. No Microsoft, Message Trace e o estado do conector mostram se o EOP aceitou ou enviou a mensagem. Serviços e logs do Sophos Firewall classifica os ficheiros de log.

Delimitar erros por sintoma

O email externo não chega ao Microsoft 365

Verificar primeiro MX, endereço público, TCP 25, SMTP Relay a partir de WAN, regra MTA automática e Mail logs. Se o SFOS aceitar mas não entregar, verificar DNS do destino tenant, política route and scan, TLS e spool.

O email de saída evita a firewall

Verificar âmbito, prioridade e Message Trace do conector no Exchange Admin Center. Só quando o trace mostra a firewall como smarthost se avaliam o relay, a política e o endereço de origem público do SFOS. Com vários WAN, consultar a secção correspondente em Mail Protection em MTA mode.

O relay é rejeitado ou estaria permitido de forma demasiado ampla

Comparar o IP EOP real com a lista Microsoft atual e os objetos SFOS. Uma rede EOP permitida tem de constar em Allow relay from hosts/networks; todas as restantes origens chegam a Block relay from hosts/networks: Any. Uma autorização cloud ou WAN ampla não é uma correção.

TLS ou a validação do conector falha

Verificar separadamente FQDN, DNS público, nome do certificado, cadeia completa, validade e STARTTLS. Um openssl s_client bem-sucedido confirma o endpoint da firewall, mas não o âmbito do conector nem a entrega completa. Allow invalid certificate não é um workaround permanente.

Surge um ciclo de email

Comparar o MX público com o destino da política SMTP route and scan. Se ambos apontarem para mail.example.com, corrigir a política para o destino Microsoft do tenant. Restaurar o caminho anterior documentado até o routing ser inequívoco.

Efetuar um rollback seguro

Primeiro desativar o conector Exchange Online ou restaurar o seu estado anterior. Depois repor MX e SPF e verificar a resolução pública. Remover a política piloto, os objetos EOP e as entradas relay do SFOS apenas quando os testes de entrada e saída voltarem a funcionar pelo caminho antigo.

As mensagens no spool ou na quarentena não são eliminadas sem análise. Fazem parte da transição e só são tratadas após verificar remetente, destinatário e caminho pretendido.

Checklist de operação

• As responsabilidades de SFOS, Microsoft 365 e outros gateways estão definidas.
• MX, SPF, conector e fluxo anteriores estão documentados como recuperação.
• Os objetos EOP provêm da lista Microsoft atual e têm responsável.
• SMTP Relay só é utilizável através de entradas Host-based relay restritas; origens não autorizadas são rejeitadas.
• A política route and scan aponta para o destino Microsoft do tenant e não para o MX público.
• Conector, certificado, DNS, MX, SPF, DKIM e DMARC foram validados com mensagens reais.
• Foram aprovados os testes de entrada, saída, destinatário inválido e relay não autorizado.
• Mail logs, spool, quarentena e Microsoft Message Trace podem ser correlacionados no tempo.
• As redes EOP e a validade do certificado são revistas regularmente.

FAQ