Configurar o Mail Protection da Sophos Firewall no Legacy mode

No Legacy mode, a Sophos Firewall funciona como proxy de email transparente. O servidor de email interno continua a ser o endpoint SMTP real; a firewall encaminha o tráfego através das regras de firewall e NAT existentes e, simultaneamente, verifica spam, malware, tipos de ficheiro ou correspondências de Data Control.

Este funcionamento é fundamentalmente diferente do MTA mode. A firewall não se torna num Mail Transfer Agent, não assume a entrega de email através de domínios protegidos e não disponibiliza um MTA mail spool para este caminho. Um teste bem-sucedido à porta SMTP não comprova, portanto, nem a análise pelo proxy nem a aplicação da política correta.

⚠️ Alterar o SMTP Deployment Mode é uma mudança global do caminho de proteção de email. Antes da mudança, devem estar documentados o backup, as políticas existentes, as regras de firewall e NAT e um caminho de recuperação testado. Um problema no MTA não justifica mudar para o Legacy mode sem planeamento.

Legacy mode em nove passos

1. Documentar o caminho SMTP de entrada e de saída existente com endereços IP, portas, NAT e Firewall Rule IDs.
2. Verificar se o proxy transparente é realmente mais adequado do que o MTA mode.
3. Garantir um backup da configuração e um acesso de gestão independente.
4. Em Email > General settings, selecionar Switch to legacy mode.
5. Definir o limite de tamanho SMTP, a ação para mensagens de tamanho excessivo, IP Reputation, os limites DoS e o comportamento TLS.
6. Criar apenas as políticas SMTP malware e SMTP spam necessárias ou verificar a sua ordem.
7. Restringir os caminhos DNAT de entrada e SNAT de saída ao servidor de email real.
8. Ativar Scan SMTP ou Scan SMTPS nas regras de firewall que efetivamente correspondem.
9. Validar as mensagens de teste de entrada e saída com Rule ID, resultado da política, certificado e logs do proxy Legacy.

Escolher entre Legacy mode e MTA mode

O Legacy mode é especialmente adequado para ambientes existentes onde o servidor de email interno já está publicado diretamente através de NAT e este caminho deve ser mantido. O SFOS posiciona-se de forma transparente entre o peer remoto e o servidor. O destino MX, a aceitação SMTP e a lógica de entrega continuam a fazer parte do design existente do servidor de email.

O MTA mode é a opção mais adequada quando a firewall deve aceitar as mensagens, encaminhá-las por domínio protegido, fazer relay e mantê-las num spool durante falhas temporárias de entrega. Mail logs e mail spool pertencem expressamente a este modelo de operação. A configuração completa está em Configurar o Mail Protection em MTA mode.

Segundo a ajuda do SFOS 22, o MTA mode não está disponível nos XGS 87/87w e XGS 88/88w. No entanto, isto não transforma automaticamente o Legacy mode numa boa arquitetura de email na cloud. Microsoft 365, Google Workspace e serviços alojados modernos utilizam requisitos próprios de TLS, autenticação e proteção contra abusos. O suporte de um proxy transparente deve ser confirmado previamente.

Em resumo: o MTA mode possui um fluxo de email próprio. O Legacy mode protege um caminho SMTP que já funciona. Misturar estes modelos leva a procurar no log errado, no destino NAT errado ou num spool que não existe.

Topologia de exemplo e caminho de recuperação

O exemplo seguinte utiliza valores de documentação e deve ser adaptado ao ambiente real antes da implementação:

• servidor de email interno 10.20.30.25 na zona DMZ
• endereço SMTP público 192.0.2.25 no caminho WAN
• serviço SMTP de entrada TCP 25
• SMTPS opcional em TCP 465, apenas se os peers e o servidor utilizarem realmente esta variante
• regras de firewall SMTP_In_Legacy e SMTP_Out_Legacy

192.0.2.25 pertence ao intervalo TEST-NET e não é um valor de produção. Antes da alteração, executam-se um teste externo de entrada e um teste de saída com timestamp. Guardam-se as Rule IDs que correspondem atualmente, o endereço de origem público utilizado pelo servidor de saída e a cadeia de certificados.

O caminho de recuperação não consiste apenas em voltar a mudar o modo. Também deve ser possível repor no estado anterior documentado as novas opções de análise, a ordem das políticas, o DNAT, as regras SNAT reflexive ou manuais e os testes temporários.

Definir as configurações SMTP globais

Limite de tamanho, ação para mensagens grandes e proteção DoS

Em Email > General settings > SMTP settings, Don’t scan emails greater than define o tamanho máximo das mensagens que são analisadas. No caminho SMTP, o valor 0 significa 51,200 KB segundo a ajuda do SFOS 22, e não ilimitado. Para mensagens maiores estão disponíveis Accept, Reject e Drop.

Accept entrega uma mensagem de tamanho excessivo sem a analisar. Reject recusa-a e informa o remetente, enquanto Drop a elimina sem notificação. Esta escolha é uma decisão consciente de risco e operação. Um Drop não testado dificulta o diagnóstico; um Accept não avaliado cria uma lacuna de análise que deve ser documentada.

Verify sender’s IP reputation verifica o IP do remetente antes dos critérios de spam da política SMTP. Os valores SMTP DoS limitam ligações, mensagens e destinatários. Os limites de produção derivam do volume real de email e de uma baseline, não de um exemplo genérico da internet.

Bypass spam check for SMTP/S authenticated connections ignora globalmente a verificação de spam nas ligações que o servidor de email identifica como autenticadas. Isto só é aceitável depois de se validarem a autenticação, as origens permitidas e a proteção contra abusos neste caminho. Um início de sessão bem-sucedido não substitui a análise de malware nem um teste negativo com uma ligação não autenticada. Os domínios em Spam check exceptions também constituem um bypass global e não são utilizados como substituto rápido de uma exceção com âmbito restrito.

O banner global de email oferece Inline, no conversion, MIME part e Off. Só aparece quando a análise SMTP ou SMTPS está ativa na regra de firewall correspondente. Como a alteração do corpo da mensagem pode invalidar uma assinatura DKIM existente, o caminho de saída real é validado através da verificação dos headers no destinatário.

Não sobrevalorizar o TLS por causa de uma caixa de seleção

Em SMTP TLS configuration, seleciona-se o certificado CA ou de servidor previsto para a análise. Allow invalid certificate permanece desativado. Segundo a ajuda, Disable legacy TLS protocols apenas desativa protocolos anteriores ao TLS 1.1 e não comprova uma sessão TLS 1.2 ou TLS 1.3 concreta.

A Sophos indica ainda uma limitação importante do Legacy mode: a firewall estabelece a ligação TLS através do endereço IP do domínio, em vez do nome de domínio. Se vários domínios partilharem um endereço IP, a validação do certificado pode falhar. Neste caso, a Sophos recomenda outro caminho de proteção, como o Sophos Email Security. A verificação não é contornada com Allow invalid certificate.

Require TLS negotiation impõe TLS aos Remote Hosts ou redes selecionados; Require sender email domains impõe-no aos domínios remetentes. Se a ligação TLS não puder ser estabelecida, o SFOS elimina as mensagens afetadas. Skip TLS negotiation permite intencionalmente ligações SMTP não cifradas aos peers selecionados e só deve ser usado em exceções documentadas.

Utilizar as políticas de análise de forma consciente

Após a ativação da subscrição Email Protection, a Sophos Firewall aplica automaticamente a política predefinida default-smtp-av ao tráfego SMTP no Legacy mode. As políticas próprias são criadas em Email > Policies e processadas pela ordem da lista. Por isso, verifica-se primeiro qual política existente corresponde ao remetente e ao destinatário concretos.

SMTP malware scan

Uma política SMTP malware scan controla os tipos de ficheiro bloqueados, as exceções MIME, a análise antivírus e as ações de entrega. Com Single antivirus, segundo a ajuda, o motor selecionado só se aplica a mensagens de entrada; as mensagens de saída são analisadas por ambos os motores. Dual antivirus executa os motores primário e secundário sequencialmente.

A ação Quarantine é combinada com as ações para o destinatário e o administrador. Don’t deliver, Deliver original e Remove and deliver têm consequências muito diferentes. Um anexo protegido ou que não possa ser analisado não deve ser automaticamente equiparado a malware. Cada ação necessita, por isso, de uma mensagem de teste, de um estado esperado no destinatário e de um caminho de libertação documentado.

Quarantine não significa automaticamente que o destinatário não receba nenhuma mensagem; a Delivery option for recipient continua a ser decisiva. Segundo a Sophos, Notify sender só funciona em conjunto com Don’t deliver. Os anexos protegidos não são analisados, mas podem continuar a gerar uma notificação. A ação separada para o administrador determina se os administradores não recebem qualquer cópia, recebem o original ou uma mensagem sem o anexo. Estes quatro resultados não são inferidos a partir de uma única mensagem de teste bem-sucedida.

SMTP spam scan

Uma política SMTP spam scan pode corresponder à classificação de spam, à origem ou destino, a uma RBL, ao tamanho da mensagem, aos headers ou a uma Data Control List. Dependendo do caminho, estão disponíveis as ações Reject, Accept, Change recipient, Prefix subject, Drop e Quarantine.

O critério Data control list e a atribuição SPX nesta política aplicam-se apenas a mensagens de saída. None, por outro lado, aplica a ação escolhida a todas as mensagens entre os grupos de remetentes e destinatários especificados. Change recipient não entrega também ao destinatário original, mas substitui-o pelo destino configurado. Estes três âmbitos são testados com um caso de destinatário positivo e outro negativo antes de se colocar a política na ordem de produção.

Preparar tipos de ficheiro próprios e Data Control

No Legacy mode, os tipos de ficheiro próprios são criados em Email > Policies > File type > Add a partir de um modelo, de extensões ou de tipos MIME. As extensões são introduzidas sem ponto inicial e apenas os tipos próprios podem ser editados. Um novo tipo não é adicionado automaticamente às policies existentes. É necessário abrir a scan policy afetada, adicionar o tipo e voltar a guardá-la. Um teste positivo com anexo e um teste negativo semelhante mostram se a ação prevista é realmente aplicada.

Uma Data Control List é criada em Email > Data control list > Add a partir das Content Control Lists necessárias. Os filtros Type e Region ajudam a selecionar apenas padrões adequados de dados financeiros, de identidade ou outros dados sensíveis. O match da lista ainda não define uma ação; esta é configurada na scan policy associada. Uma pequena lista piloto com um teste positivo e outro negativo é mais segura do que uma coleção ampla de CCLs não verificadas.

No Legacy mode, o SPX pode ser selecionado nesta política para mensagens de saída. Contudo, o modelo de palavra-passe, o portal e a validação constituem um processo de segurança separado; ver Configurar a encriptação de email SPX. Não se adiciona uma Data Control List nem uma atribuição SPX ao primeiro teste básico do proxy.

Uma classificação incorreta confirmada não se corrige desativando uma política abrangente. Criar e testar exceções de email em segurança explica como ignorar verificações individuais para uma combinação exata de origem, remetente e destinatário e como testar depois o tráfego que não deve corresponder.

Utilizar o email journaling opcional respeitando a proteção de dados

Em Email > General settings > Email journaling > Add, o SFOS pode enviar cópias das mensagens SMTP/S recebidas para destinatários ou grupos de endereços selecionados para um endereço de journaling separado. A seleção Any inclui todas as mensagens recebidas. A função aplica-se apenas a SMTP/S e não regista tráfego POP ou IMAP.

O journaling cria uma cópia adicional do email. Não constitui automaticamente um arquivo inviolável nem comprova o cumprimento das obrigações legais de retenção. Antes da ativação definem-se a finalidade, os destinatários autorizados, o acesso à caixa de journaling, a encriptação, o período de retenção, o armazenamento necessário e o responsável.

Para o primeiro teste seleciona-se uma única caixa de teste em vez de Any. Uma mensagem recebida para essa caixa deve aparecer no destino normal e na caixa de journaling; uma mensagem para um destinatário não selecionado não deve gerar uma cópia. O endereço de journaling não pode iniciar um fluxo que devolva a cópia ao SFOS e crie um ciclo.

A seleção de destinatários só é ampliada após os testes positivo e negativo. Para o rollback, remove-se a entrada de journaling ou repõe-se o estado anterior documentado. As cópias já entregues permanecem na caixa de journaling e devem ser tratadas de acordo com as respetivas regras de retenção.

Combinar NAT e regras de firewall

Publicar o caminho SMTP de entrada

Para mensagens de entrada, uma regra DNAT traduz o endereço WAN público para o servidor de email interno. Original Source é limitado tanto quanto o design de email permitir; Original Destination é o endereço público previsto; Translated Destination é 10.20.30.25 ou o servidor de email real. Original service e translated service permanecem limitados às portas SMTP efetivamente disponibilizadas.

Uma regra reflexive também cria SNAT para a direção oposta. Só é selecionada se esta identidade de origem pública exata estiver prevista para o caminho de saída. Várias ligações WAN, smarthosts ou rotas de operador diferentes exigem um design próprio de routing e SNAT. A ordem geral e a zona de destino após NAT são explicadas em Publicar um servidor através de DNAT.

Utilizar duas regras de firewall restritas

Para a validação, regras separadas são mais claras do que uma regra bidirecional com várias zonas e objetos Any:

• Entrada: WAN para a zona do servidor de email interno, host de destino 10.20.30.25, apenas os serviços SMTP necessários, logging ativado
• Saída: zona e host do servidor de email interno para WAN ou para o smarthost específico, apenas os serviços SMTP necessários, logging ativado

Em Scan email content, ativa-se Scan SMTP nas duas direções necessárias e Scan SMTPS apenas quando SMTPS é realmente utilizado. Uma caixa de seleção ativa não adiciona automaticamente um serviço em falta a um design de segurança correto. Serviço, NAT, listener do servidor e opção de análise devem descrever o mesmo caminho de porta.

As regras são colocadas acima de regras mais gerais que já correspondam ao mesmo tráfego. Depois de guardar, a Firewall Rule ID registada é decisiva. A estrutura das regras, a zona NAT e a ordem são explicadas em Configurar regras da Sophos Firewall em segurança.

Validar o fluxo de email e a análise pelo proxy

Primeiro envia-se uma pequena mensagem externa para uma caixa de correio de teste. Depois, o servidor de email interno envia uma segunda mensagem para um destinatário externo controlado. Ambos os testes recebem assuntos únicos e timestamps UTC.

Para STARTTLS na porta 25 e uma ligação TLS direta na porta 465, podem ajudar as seguintes verificações apenas de leitura a partir de um sistema de teste autorizado:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

mail.example.net é substituído pelo FQDN real e apenas são testadas portas efetivamente disponibilizadas. O OpenSSL confirma acessibilidade, cadeia de certificados e parâmetros TLS negociados. Não comprova a entrega bem-sucedida nem a análise de malware, spam ou Data Control.

No Log Viewer, a origem, o destino, o serviço, a ação e a Firewall Rule ID devem corresponder às novas regras. Para o proxy SMTP/S Legacy, awarrensmtp.log e awarrenmta.log são correlacionados com o mesmo timestamp. Os ficheiros de log são explicados em Serviços e logs da Sophos Firewall.

Em seguida, realiza-se um teste negativo. Uma origem não prevista, uma porta não autorizada ou uma mensagem de teste sem o critério da política não devem receber acidentalmente o mesmo caminho de proteção. Não se utiliza malware real nos testes de produção; para validar a análise utilizam-se padrões de teste inofensivos estabelecidos e uma caixa de correio controlada.

Delimitar erros por sintoma

O SMTP funciona, mas a política não é aplicada

Primeiro verifica-se a Firewall Rule ID. Se outra regra corresponder, corrigem-se a ordem, a origem, o destino, o destino NAT e o serviço. Se a regra esperada corresponder, Scan SMTP ou Scan SMTPS, a ordem das políticas e os grupos de remetentes e destinatários devem ajustar-se ao teste. Uma política isolada não ativa o proxy transparente.

O email de entrada não chega ao servidor

Verificam-se separadamente o endereço de destino público, o hit DNAT, o translated destination, a zona de destino, o listener do servidor e o caminho de retorno. Uma ligação TCP aberta até à firewall não comprova que o DNAT e a regra de firewall alcançam o servidor interno. Packet Capture e Rule ID devem mostrar a entrada e o encaminhamento.

O email de saída utiliza o endereço IP público errado

Verificam-se o SNAT, a regra reflexive, o gateway WAN, a rota SD-WAN e o comportamento dos reply packets. O proxy Legacy não seleciona automaticamente o endereço de origem público necessário para SPF, RDNS ou autorização do operador. Antes de uma alteração global de Route Precedence, é necessário comprovar o caminho concreto.

O TLS falha depois de ativar a análise

Registam-se o FQDN, o IP de destino, o certificado, o emissor, a cadeia e a versão negociada. Com vários domínios num endereço IP, a verificação de certificado baseada em IP documentada pode ser a causa. Allow invalid certificate não é ativado como solução rápida.

Falta uma mensagem e não aparece nada no MTA mail spool

Isto não é um critério de sucesso útil no Legacy mode, porque mail spool e os mail logs específicos do MTA pertencem ao MTA mode. A cadeia relevante é composta pela regra de firewall, NAT, logs do servidor SMTP, Log Viewer, awarrensmtp.log e awarrenmta.log. As mensagens em quarentena são verificadas separadamente em Email > SMTP quarantine.

Efetuar um rollback seguro

Para o rollback, repõem-se primeiro as regras piloto e as opções de análise no estado anterior documentado. Depois removem-se novas atribuições de políticas ou repõe-se a sua ordem. As alterações temporárias a DNAT, SNAT ou certificados só são removidas se nenhum outro serviço depender delas.

Só depois se repõe o SMTP Deployment Mode, caso a alteração tenha incluído essa mudança. O fluxo de email de entrada e de saída original deve voltar a funcionar com as Rule IDs, os endereços públicos e os logs de servidor esperados. Mensagens, conteúdo da quarentena ou logs do proxy não são eliminados como rollback padrão.

Checklist de operação

• O proxy transparente foi escolhido de forma consciente e os requisitos de MTA foram excluídos.
• O backup, o acesso de gestão e as Rule IDs originais estão documentados.
• O limite de tamanho SMTP, a ação para mensagens grandes, IP Reputation e os limites DoS estão justificados.
• O certificado, as exceções TLS e os domínios afetados foram verificados.
• DNAT, SNAT, zona de destino e portas reais do servidor coincidem.
• As regras de firewall de entrada e saída são restritas, têm logging e a sua correspondência foi comprovada.
• As políticas predefinidas e próprias possuem uma ordem rastreável.
• O journaling opcional está limitado aos destinatários necessários e tem uma finalidade documentada de proteção e retenção de dados.
• Os testes positivo, negativo, TLS e de entrega foram concluídos com sucesso.
• Os logs do proxy Legacy e do servidor de email podem ser correlacionados por tempo.
• O responsável, a data de revisão e o caminho de recuperação completo estão registados.

FAQ