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. Isto aplica-se tanto ao modo MTA como ao modo Legacy; o caminho de menu para a política POP-IMAP opcional é diferente. Uma política isolada não basta: 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 uma política POP-IMAP scan para remetentes, destinatários ou características da mensagem: em Email > Policies and exceptions no modo MTA ou em Email > Policies no modo Legacy.
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, em Email > General settings > POP and IMAP TLS configuration, selecionar em TLS certificate a CA que emitiu o certificado do servidor de email, previamente verificada e importada. Manter Allow invalid certificate desativado. Desativar a validação não corrige uma contraparte inválida, expirada ou não fidedigna.

Selecionar a caixa Disable legacy TLS protocols para desativar protocolos anteriores a TLS 1.1, conforme a ajuda do SFOS. 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. No modo MTA, o caminho é Email > Policies and exceptions > Add policy > POP-IMAP scan; no modo Legacy, é Email > Policies > Add 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.

Para remetentes e destinatários, selecionar grupos de endereços de email ou de domínios e uma correspondência exata ou por palavra-chave. Endereços de teste individuais com correspondência exata permitem um âmbito piloto preciso; grupos de domínios ou palavras-chave podem alargar o âmbito previsto. Verificar o âmbito real com mensagens correspondentes e não correspondentes, sem assumir regras adicionais de caracteres universais ou de distinção entre maiúsculas e minúsculas.

• Inbound email is: selecionar spam, probable spam, virus outbreak ou probable virus outbreak como classificação.
• Source IP/network address: indicar o endereço IP ou de rede do remetente.
• Message size: definir um limite superior ou inferior do tamanho da mensagem. Este critério da política não substitui o limite global Don’t scan emails greater than.
• Message header: escolher o cabeçalho; para Other, introduzir os respetivos detalhes. Depois, selecionar correspondência exata ou por palavra-chave e indicar o valor da palavra-chave a comparar.

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.

Um exemplo piloto inofensivo utiliza os próprios grupos de endereços de teste com correspondência exata e o critério Message header: Other, detalhes Subject, correspondência exata, valor da palavra-chave Test email. Configurar Prefix subject com o prefixo livremente escolhido Pilot e guardar a política. Para a mensagem correspondente, espera-se que o assunto passe de Test email para Pilot: Test email. Uma segunda mensagem entre os mesmos endereços de teste com assunto Control email não corresponde ao critério do cabeçalho e não deve receber este prefixo. Adaptar os endereços e o prefixo ao próprio piloto; testar ambas as mensagens novas pelo mesmo caminho de receção previsto. Outras políticas ativas não devem distorcer a comparação.

Para uma política POP-IMAP scan existente, abrir Email > Policies and exceptions no modo MTA ou Email > Policies no modo Legacy. Selecionar Edit na política em causa, alterar as definições necessárias e guardar a política. Em seguida, voltar a verificar a receção de email e o efeito da política no caminho previsto para o cliente.

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.

Hierarquia XML e limites da automatização

Para a automatização, o objeto de política chama-se POPIMAPScanningPolicy. O enquadramento seguinte descreve a estrutura documentada para SFOS 22/23, não um pedido POST testado ou pronto a enviar. Proteger o acesso à XML API explica o acesso protegido e a interpretação das respostas XML. As opções de análise da regra de firewall que corresponde efetivamente continuam a ser necessárias mesmo quando a política é gerida através da API.

O exemplo documentado distingue três níveis:

• POPIMAPScanningPolicy/Name identifica a política a gerir. Por sua vez, POPIMAPScanningPolicy/After/Name identifica a outra política após a qual esta é posicionada no exemplo. O nome da política de destino e a referência para a ordem não devem ser confundidos. O exemplo demonstra esta estrutura de posicionamento, mas não uma ordem geral de avaliação nem o comportamento quando a referência está ausente ou quando se omite After.
• Em POPIMAPScanningPolicy/EmailAddress encontram-se SenderEmail, SenderAction, RecipientEmail e RecipientAction. Os valores de endereço e os operadores de correspondência pertencem, portanto, ao nó pai comum EmailAddress, não diretamente ao objeto de política. A descrição dos parâmetros trata ambos os valores de endereço como strings individuais; a seleção de grupos na interface não implica um nó de lista XML adicional.
• No exemplo, FilterCriteria, Action, To e MatchIs encontram-se diretamente em POPIMAPScanningPolicy, fora de EmailAddress e de After. Aqui, To contém o prefixo do assunto para a ação de prefixo, não um endereço de destinatário. Consoante o critério, MatchIs descreve a classificação dos emails recebidos ou o valor do cabeçalho a comparar.

A tabela de parâmetros identifica Name, SenderEmail, SenderAction, RecipientEmail, RecipientAction, FilterCriteria e Action como obrigatórios. Indica para Name um máximo de 255 caracteres, para To um máximo de 300 e para MatchIs um máximo de 750 caracteres. Estes limites descrevem campos, não o âmbito permitido da política; por exemplo, o valor de endereço Any apresentado no exemplo não é uma opção adequada para um piloto restrito.

Outros parâmetros específicos dos critérios são Address para o IP ou a rede de origem (array de strings, vários valores), MessageSizeOperator com MessageSize (número inteiro), bem como MessageHeaderString (máximo de 765 caracteres) com MessageHeaderOperator para comparações de cabeçalhos. A tabela de parâmetros indica estes campos, mas o exemplo apresentado para emails recebidos não os inclui. Por isso, não constitui um modelo XML completo para filtros de IP de origem, tamanho ou cabeçalho; não se deduzem dele nós pais em falta, unidades de tamanho ou dependências de obrigatoriedade.

⚠️ Na descrição dos parâmetros, alguns valores permitidos são indicados apenas como símbolos não resolvidos, como $POPIMAP{SENDER_MATCHTYPE_CONTAINS}, $POPIMAP{RULETYPE_INBOUND_EMAIL} e $POPIMAP{POP_IMAP_ACTION_PREFIX_SUBJECT}. Estes símbolos não são valores literais confirmados para um POST. Embora o exemplo apresente Contains, InboundEmailIs e Prefix Subject, não fornece uma correspondência completa para todas as constantes. Para MessageHeaderOperator, a coluna Default indica inclusivamente GreaterThan, enquanto a descrição prevê Contains/Equals. Não resolver esta contradição com um operador adivinhado nem enviar designações da interface ou nomes de símbolos como valores da API sem os verificar.

Enquanto os valores concretos e a estrutura de filtro necessária para o build utilizado não estiverem esclarecidos, a configuração através da interface descrita acima continua a ser o caminho seguro e documentado. Antes de uma alteração pela API posteriormente aprovada, preservar os nomes, a ordem, o âmbito dos endereços, o critério e a ação; depois, voltar a ler o estado guardado ou verificá-lo na interface e repetir a receção do par de mensagens de teste correspondente e não correspondente. A referência lista os valores de estado XML 200, 500 e 502 para Add e Edit, mas não apresenta mensagens explicativas. Por isso, um resultado HTTP bem-sucedido, por si só, não confirma a política guardada nem o seu efeito. Não foi executada qualquer chamada de escrita numa appliance neste contexto.

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

Criar a regra em Rules and policies > Firewall rules. No modo MTA, também é possível complementar a regra de firewall MTA criada automaticamente; para um piloto claramente delimitado, uma regra própria e restrita é mais fácil de avaliar. No modo Legacy, deve ser criada uma nova regra de firewall. 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.

A receção, a Firewall Rule ID, os parâmetros TLS e a correlação com warren.log demonstram em conjunto o caminho de receção e TLS previsto, não a eficácia do antivírus. Se estiver configurada uma política própria Prefix subject, testar também o par de mensagens descrito acima: Pilot: Test email para a mensagem correspondente e nenhum prefixo Pilot para Control email. Documentar os assuntos efetivamente entregues; mesmo um prefixo correto demonstra apenas a ação da política, não a eficácia do antivírus. Se o resultado for diferente, verificar grupos, tipo de correspondência, cabeçalhos e outras políticas ativas, e repetir o teste das duas mensagens.

O teste do caminho também inclui um caso negativo. Para um host piloto não autorizado ou uma porta não selecionada, definir previamente o tratamento esperado pelas regras e depois verificar a Rule ID real e as opções de análise. Corrigir uma segunda regra de análise involuntariamente ampla; uma proteção alternativa deliberadamente planeada não é um defeito. O teste não exige nem ausência global de proteção nem bloqueio indiscriminado. Se estiver disponível uma contraparte de teste especialmente preparada com uma cadeia de certificados inválida, a tentativa de ligação ou receção deve falhar devido à validação dessa cadeia enquanto Allow invalid certificate estiver desativado na firewall; 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