Analisar e testar POP3 e IMAP na Sophos Firewall

A Sophos Firewall pode analisar emails quando os clientes os obtêm através de POP3, POP3S, IMAP e IMAPS. Não basta criar uma política POP-IMAP. Só uma regra de firewall correspondente encaminha o tráfego de email pelo proxy e ativa as definições configuradas de análise e TLS.

Por isso, o teste de aceitação mais importante não é um interruptor verde, mas uma receção real desde o cliente previsto até ao servidor de email previsto. A Firewall Rule ID, a porta, a cadeia de certificados, a versão TLS negociada e o warren.log têm de corresponder ao caminho planeado.

⚠️ Sem Scan email content na regra de firewall que corresponde efetivamente, o SFOS não aplica as definições nem as políticas POP/IMAP. Uma política isolada não oferece proteção.

Análise POP/IMAP em oito passos

1. Documentar a rede cliente, o servidor de email, os protocolos e as portas efetivamente utilizados.
2. Selecionar uma única origem piloto e testar a receção de email existente.
3. Importar em Certificates > Certificate authorities a CA que emitiu o certificado do servidor de email, caso ainda não seja considerada fidedigna.
4. Definir POP/S and IMAP/S settings e POP and IMAP TLS configuration em Email > General settings.
5. Apenas se necessário, criar em Email > Policies and exceptions uma política POP-IMAP scan para remetentes, destinatários ou características da mensagem.
6. Criar uma regra de firewall restrita e com registo para o cliente piloto e o servidor de email e ativar os protocolos necessários em Scan email content.
7. Verificar a receção, a ligação TLS, a Firewall Rule ID e o warren.log com uma pequena mensagem de teste.
8. Adicionar mais clientes apenas depois dos testes positivo e negativo e documentar o caminho de reversão.

O que o proxy POP/IMAP protege

POP3 e IMAP servem para receber e gerir mensagens numa caixa de correio. Não são SMTP, que transporta mensagens entre um remetente, um MTA e um servidor de email. O guia do modo MTA explica, por isso, MX, encaminhamento SMTP, relay, spool e quarentena SMTP; este guia concentra-se na receção de email por um cliente.

O SFOS distingue as portas não cifradas ou atualizadas através de STARTTLS das variantes que utilizam TLS desde o início:

• POP3: TCP 110, com atualização opcional para TLS através de STARTTLS
• POP3S: TCP 995, TLS desde o início da ligação
• IMAP: TCP 143, com atualização opcional para TLS através de STARTTLS
• IMAPS: TCP 993, TLS desde o início da ligação

Os novos desenhos deveriam usar ligações cifradas para os clientes de email. No entanto, selecionar um protocolo no SFOS não altera a configuração do cliente. Se o cliente utilizar outra porta ou contornar a regra planeada, esse tráfego não fica automaticamente protegido pela opção standard selecionada.

A análise POP/IMAP requer uma licença válida de Email Protection. Não substitui a proteção do servidor de email nem a análise quando uma mensagem chega por SMTP. Sobretudo com serviços de email na cloud, é necessário confirmar primeiro se o fornecedor ainda permite a receção POP/IMAP convencional e se um proxy transparente é compatível com os respetivos requisitos de TLS e autenticação.

Definir o exemplo e o limite do teste

Um piloto controlado evita que uma configuração incorreta de certificado ou regra afete todos os clientes de email ao mesmo tempo. Este exemplo utiliza valores de documentação:

• cliente piloto 10.20.30.50 na zona LAN
• servidor de email mail.example.net
• endereço de destino 192.0.2.25
• protocolo utilizado IMAPS em TCP 993
• regra de firewall Pilot_POP_IMAP_Scan

Substituir 10.20.30.50, mail.example.net e 192.0.2.25 pelos valores reais. O endereço de destino pertence ao intervalo de documentação TEST-NET e não deve ser utilizado como endereço de servidor de produção. O piloto deve utilizar uma caixa de correio de teste própria, não a única conta de um administrador.

Antes da alteração, obter uma mensagem e registar o emissor atual do certificado. Preservar também a regra de firewall existente, o respetivo contador e a configuração do cliente. Isto permite distinguir posteriormente um problema de encaminhamento, TLS, análise do proxy ou servidor de email.

Preparar TLS e os limites de análise

CA e validação de certificados

Em Certificates > Certificate authorities, adicionar a CA que emitiu o certificado do servidor de email se a firewall ainda não confiar nela. Os ficheiros de CA privada só podem vir da PKI da própria organização ou de outra origem verificada. Importar certificados na Sophos Firewall explica a importação geral e a verificação da cadeia.

Em seguida, selecionar o TLS certificate previsto em Email > General settings > POP and IMAP TLS configuration. Manter Allow invalid certificate desativado. Desativar a validação não corrige uma contraparte inválida, expirada ou não fidedigna.

Segundo a ajuda do SFOS, Disable legacy TLS protocols desativa protocolos anteriores a TLS 1.1. A opção não prova que uma sessão concreta utiliza TLS 1.2 ou TLS 1.3. Se a norma de segurança exigir pelo menos TLS 1.2, é necessário verificar a versão negociada no caminho real do cliente. Se a combinação implementada não conseguir cumprir esse requisito, interromper o rollout e avaliar outra arquitetura de proteção.

Como a firewall processa tráfego de email cifrado para o analisar, pode surgir um aviso de certificado no cliente. Um novo aviso não deve ser ignorado. Verificar o nome apresentado, o emissor, a cadeia e a confiança do cliente e corrigir a causa antes de um rollout alargado.

Tamanho das mensagens e cabeçalhos de destinatário

Em POP/S and IMAP/S settings, Don’t scan emails greater than define o tamanho máximo de mensagem para análise. Para POP/IMAP, 0 não significa ilimitado; segundo a ajuda do SFOS, define o limite como 10,240 KB. As mensagens maiores não são analisadas. O limite deve refletir os anexos típicos, o desempenho disponível e o risco residual aceite.

Os Recipient headers ajudam o SFOS a identificar destinatários para as políticas POP/IMAP. Por predefinição, a firewall utiliza Delivered-To, Received e X-RCPT-TO. Só deve ser acrescentado outro cabeçalho se o servidor de email real o definir de forma fiável. Caso contrário, um cabeçalho inventado ou removido posteriormente cria correspondências de política difíceis de compreender.

Criar uma política POP-IMAP opcional

Com uma subscrição Email Protection ativa, o SFOS aplica automaticamente a política predefinida default-pop-av ao tráfego POP3/S e IMAP/S. Esta remove anexos infetados por vírus e substitui o corpo da mensagem por uma notificação. Esta política base automática deve ser considerada durante os testes e o diagnóstico antes de atribuir o comportamento a uma política própria.

Uma política POP-IMAP acrescenta critérios e avisos para os utilizadores. Em Email > Policies and exceptions > Add a policy > POP-IMAP scan, definir primeiro um nome e os grupos de remetentes e destinatários. Depois, a política pode reagir, entre outros critérios, a uma classificação de spam, IP ou rede de origem, tamanho da mensagem ou cabeçalho.

As ações documentadas são Accept e Prefix subject. Prefix subject entrega a mensagem e acrescenta um aviso ao assunto. Por isso, a política não é uma regra geral de quarentena ou bloqueio. Se for selecionado None como critério, a ação aplica-se a todas as mensagens entre os remetentes e destinatários indicados. Este âmbito deve ser verificado conscientemente antes de guardar.

A política adicional pode ser omitida no primeiro teste técnico do proxy. Assim fica claro se a cadeia básica composta por TLS, regra de firewall e análise já funciona. Só deve ser adicionada uma política quando for realmente necessária lógica de remetente, destinatário ou cabeçalho.

Criar a regra de firewall para a receção de email

Criar a regra em Rules and policies > Firewall rules. Deve conter apenas a rede cliente ou o host piloto previsto, o destino do servidor de email e as portas de email efetivamente necessárias. Uma regra geral de LAN para WAN com muitas funções de segurança dificulta a validação.

Para o exemplo Pilot_POP_IMAP_Scan, são adequados estes valores:

• Source zones: LAN
• Source networks and devices: host 10.20.30.50
• Destination zones: zona do caminho para o servidor de email, normalmente WAN para um servidor externo
• Destination networks: objeto host para 192.0.2.25 ou para o servidor de email real
• Services: IMAPS
• Log firewall traffic: ativado

Em Scan email content, ativar Scan IMAPS. Se o ambiente utilizar efetivamente outros protocolos, selecionar também Scan IMAP, Scan POP3 ou Scan POP3S. Add ports adiciona os serviços correspondentes; depois têm de aparecer em Services na regra.

Colocar a regra acima de uma regra mais geral que já corresponda ao mesmo cliente e servidor de email. Depois de guardar, a Firewall Rule ID real no Log Viewer é determinante, não a posição esperada na tabela. Configurar regras da Sophos Firewall em segurança explica a estrutura, a ordem e a validação da Rule ID.

Testar o caminho completo

Primeiro, colocar uma mensagem pequena e inofensiva na caixa de correio de teste privada. O cliente piloto obtém-na através do FQDN e da porta previstos. No Log Viewer, IP de origem, IP de destino, serviço, ação e Firewall Rule ID têm de corresponder à nova regra. O aumento do contador de outra regra é uma condição de paragem.

Para verificar o certificado e o TLS, podem ser executados, por exemplo, estes testes de ligação que não alteram a configuração, a partir de um cliente na mesma rede:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Testar apenas os protocolos que o servidor de email oferece realmente. Substituir mail.example.net pelo FQDN real. A saída confirma o certificado, a cadeia e os parâmetros TLS, mas não um login bem-sucedido nem a análise do conteúdo. Terminar a ligação interativa com Ctrl+C após a verificação.

Em seguida, repetir a receção com o cliente de email real. Utilizar warren.log para a análise do proxy; o Log Viewer e o Packet Capture mostram adicionalmente a correspondência da regra e o caminho de rede. Registar em conjunto o timestamp, IP do cliente, IP do servidor, porta e assunto de teste. Serviços e logs da Sophos Firewall classifica o ficheiro e explica o acesso seguro.

Um teste de aceitação fiável também inclui um caso negativo. Um host piloto não autorizado ou uma porta não selecionada não pode receber acidentalmente o mesmo estado de proteção através de outra regra de análise ampla. Se estiver disponível uma contraparte de teste especialmente preparada com uma cadeia de certificados inválida, esta deve falhar enquanto Allow invalid certificate estiver desativado; não criar uma falha de certificado na contraparte de produção para este teste.

Delimitar erros por sintoma

A receção funciona, mas o proxy não analisa

Verificar primeiro a Firewall Rule ID. Se corresponder uma regra superior ou mais geral, corrigir a ordem, origem, destino e serviço. Se corresponder a regra prevista, a opção adequada Scan IMAP/IMAPS/POP3/POP3S e a porta têm de estar ativas em Services. Uma política POP-IMAP isolada não ativa o proxy.

O cliente de email comunica um erro de certificado após a ativação

Registar o FQDN apresentado, o emissor, a validade e a cadeia completa. Depois, verificar a CA selecionada em POP and IMAP TLS configuration e a confiança do cliente. Não ativar Allow invalid certificate como solução permanente. Se continuar a não ser claro qual certificado o proxy ou o servidor apresenta, reverter o piloto antes de afetar mais clientes.

STARTTLS funciona, mas POP3S ou IMAPS não

Verificar separadamente as portas e os modos de ligação. POP3 em 110 e IMAP em 143 só mudam para uma sessão cifrada através de STARTTLS; POP3S em 995 e IMAPS em 993 começam com TLS. Cliente de email, listener do servidor, serviço da firewall e opção de análise ativada têm de utilizar a mesma variante.

Uma mensagem grande é entregue, mas não analisada

Comparar Don’t scan emails greater than com o tamanho real da mensagem. Mesmo 0 limita a análise POP/IMAP a 10,240 KB. Não aumentar o limite sem critério para um único teste sem avaliar o efeito no desempenho e no risco aceite.

Falta o prefixo do assunto

Verificar os grupos de remetentes e destinatários, o tipo de correspondência, o critério e os Recipient headers. A mensagem pode ter sido analisada tecnicamente mesmo que a política opcional não tenha correspondido. Por isso, avaliar separadamente o funcionamento do proxy e a ação da política.

Operação e reversão

Depois de um piloto bem-sucedido, adicionar gradualmente outros clientes. Durante o rollout, monitorizar os contadores das regras, warren.log, erros TLS e pedidos ao helpdesk. Alterações ao certificado do servidor de email, FQDN, porta ou perfil de cliente devem posteriormente seguir o mesmo processo de mudança, pois alteram o caminho validado.

Para reverter, remover primeiro o piloto da regra restrita ou desativar a opção de análise correspondente. Em seguida, confirmar que a receção original de email volta a funcionar e que corresponde a regra anterior prevista. Remover uma CA importada ou uma definição POP/IMAP global apenas se nenhum outro serviço a utilizar. Não eliminar mensagens, logs ou certificados como passo standard de reversão.

FAQ