Sophos Phish Threat: permitir remetentes, domínios e IPs

O Sophos Phish Threat só pode fornecer resultados de campanha realistas se as simulações forem entregues e os utilizadores conseguirem aceder às páginas de phishing e de formação associadas. Para tal, os domínios dos remetentes, endereços IP e destinos Web fornecidos pela Sophos têm de ser permitidos em todos os pontos de controlo efetivamente percorridos. No entanto, não é necessário nem aconselhável ignorar indiscriminadamente a segurança de e-mail ou Web.

Este processo é independente do fornecedor. Aplica-se a gateways de e-mail a montante, Mail Transfer Agents, Secure Web Gateways, proxies, firewalls, filtros DNS e de URL, bem como a produtos que analisam automaticamente links ou anexos. Os passos específicos dos produtos constam nos guias de entrega para Microsoft 365 e Google Workspace.

Obter os valores atuais no Sophos Fusion (anteriormente Sophos Central)

A lista vinculativa deve ser obtida no tenant Sophos Fusion afetado:

1. Clique no ícone Global Settings.
2. Abra Products and Services > Sophos Phish Threat.
3. Clique em Sending domains and IPs.
4. Documente todos os domínios de remetente, endereços IP e destinos Web apresentados, incluindo a data da consulta.

Os endereços IP do Sophos Mailflow regionais não devem ser adicionados indiscriminadamente à allowlist do Phish Threat. São utilizados apenas nos conectores Mailflow do Microsoft 365 configurados automaticamente ou para restaurar esses conectores após alterações à configuração. Por conseguinte, estas redes só devem ser introduzidas no âmbito da configuração documentada dos conectores Mailflow e apenas para a região utilizada, não preventivamente em gateways a montante, proxies ou filtros Web.

A lista pode conter valores para diferentes funções:

• endereços IP e domínios para o envio dos e-mails da campanha,
• domínios de remetente ou de Return-Path,
• destinos de monitorização e redirecionamento para a medição dos cliques,
• domínios para páginas simuladas de phishing ou de início de sessão,
• páginas de formação e outros destinos Web necessários ao fluxo da campanha.

Os links do Phish Threat podem redirecionar através do destino de monitorização AWS awstrack.me documentado pela Sophos. Este redirecionamento é esperado para a medição dos cliques. Antes do envio piloto, compare os hosts efetivamente necessários com a lista atual da Sophos e com os destinos da campanha específica. Não permita subdomínios adicionais, exceto se a sua necessidade estiver comprovada nessas fontes ou na documentação do produto.

Mapear o fluxo de dados antes da autorização

O allowlisting é efetuado em cada ponto de controlo, não apenas no último servidor de e-mail. Primeiro, documente o percurso real de uma mensagem e de um clique de teste:

1. O Sophos Phish Threat envia a simulação.
2. Um filtro na cloud a montante, um Secure Email Gateway ou um MTA aceita a mensagem.
3. Outros serviços antisspam, antiphishing, de sandbox ou de análise de links processam-na.
4. O sistema de destino entrega-a à caixa de correio.
5. Quando o utilizador clica, o pedido passa por filtros DNS, proxy, Secure Web Gateway, firewall e, se aplicável, proteção do browser ou do endpoint.
6. As páginas de monitorização, phishing e formação devolvem os eventos ao Phish Threat.

Para cada passo, registe o produto, o proprietário da regra, o valor necessário, a exceção pretendida, a data de expiração ou revisão e o método de reversão. Se existirem vários filtros em sequência, todos os filtros relevantes devem ser considerados. Permitir o tráfego apenas na caixa de correio de destino não resolve um bloqueio no gateway a montante.

Implementar a allowlist com o âmbito mais restrito possível

A regra deve ser tão abrangente quanto tecnicamente necessário para a simulação, mas não mais. Dê preferência a endereços IP ou nomes de host exatos, à lista atual do Phish Threat e aos destinatários de teste previstos. Utilize um domínio completo, um padrão wildcard ou uma exceção global do scanner apenas se a configuração da campanha ou o produto não permitirem uma regra mais restrita.

Alguns produtos distinguem entre entrega, avaliação de spam, reescrita de URLs, verificação Time-of-Click, Attachment Sandboxing e acesso Web. Uma única regra “Allow” não abrange automaticamente todas estas funções. Por outro lado, uma autorização para entrega de e-mail não deve excluir inadvertidamente de todas as verificações todos os ficheiros ou URLs do mesmo remetente.

Permitir hosts variáveis apenas quando a necessidade estiver comprovada

Inicialmente, adicione de forma individual apenas os hosts indicados no Sophos Fusion ou na documentação do produto e utilizados na campanha. Se um destino específico do produto ou da campanha utilizar comprovadamente hosts variáveis e a autorização não puder ser limitada tecnicamente a nomes de host exatos, poderá ser necessário um wildcard. Nesse caso, aplique controlos adicionais:

• defina o wildcard apenas abaixo do domínio de base indicado pela Sophos,
• não permita todo o domínio principal do fornecedor,
• limite a regra ao tráfego do Phish Threat e, se possível, aos destinatários piloto,
• documente o responsável e a data de revisão,
• antes de cada novo modelo de campanha, verifique se é utilizado um host adicional.

Uma autorização muito ampla, como uma plataforma partilhada completa de cloud ou de envio, aumenta o risco de admitir tráfego de terceiros. Se um produto não conseguir implementar o âmbito restrito necessário, este risco residual deve ser aceite antes da alteração ou deve ser escolhido outro percurso de entrega.

Evitar falsos cliques e a abertura automática de anexos

Os produtos de segurança de e-mail analisam frequentemente as mensagens acedendo aos URLs ou abrindo os anexos numa sandbox. O Phish Threat pode interpretar esse pedido como uma ação do utilizador. O resultado são aparentes cliques ou anexos abertos, mesmo que o destinatário ainda não tenha interagido com a mensagem.

Os indícios típicos de que um evento provém de um scanner e não de um utilizador incluem:

• os eventos ocorrem antes ou imediatamente no momento da entrega,
• muitos destinatários apresentam quase simultaneamente a mesma ação,
• os endereços de origem ou User-Agents pertencem ao serviço de segurança,
• vários links da mesma mensagem são abertos em rápida sucessão,
• o padrão pode ser reproduzido com uma mensagem piloto acabada de enviar.

A correção deve ser feita no scanner que causa o problema: adicione os endereços IP e domínios atuais do Phish Threat à respetiva lista destinada a simulações de phishing autorizadas ou a exceções de análise direcionadas. A exceção tem de corresponder tanto à origem identificada como à função de análise afetada. Permitir apenas um endereço de remetente não é suficiente se o serviço abrir cada URL de forma independente numa sandbox.

A ausência de eventos de clique tem frequentemente a causa oposta. Os destinos de monitorização podem ser bloqueados por Secure Web Gateways, filtros DNS ou extensões do browser, como bloqueadores de anúncios. Por isso, se faltar telemetria, não reinicie imediatamente a campanha; verifique primeiro a cadeia de redirecionamento no browser e os registos do proxy, DNS e endpoint.

Cabeçalhos de bypass do Microsoft 365 apenas como exceção legacy

Os guias mais antigos utilizam regras de transporte com os cabeçalhos X-MS-Exchange-Organization-SkipSafeLinksProcessing ou X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. Estas regras não são a baseline para uma nova implementação. Para a entrega baseada em SMTP através do pipeline de transporte do Microsoft 365, a Microsoft disponibiliza a Advanced Delivery Policy. No entanto, para novas implementações, a Sophos recomenda M365 Direct Delivery; este percurso de entrega ignora o pipeline de transporte, pelo que Advanced Delivery não se aplica. A configuração concreta do Microsoft 365 deve seguir as instruções atuais da Sophos para o percurso de entrega escolhido e não faz parte deste artigo.

Os cabeçalhos legacy só devem ser considerados se um ambiente existente ainda precisar deles de forma comprovada, o estado atual do suporte tiver sido verificado e existir uma alteração aprovada com um âmbito de IP/domínio restrito. A prioridade, o efeito e as consequências de segurança da regra devem ser testados separadamente. Não mantenha regras de cabeçalhos antigas “por precaução” juntamente com uma autorização de simulação atual.

Validar uma campanha piloto

Comece com um pequeno grupo piloto de contas de teste controladas. Deve incluir pelo menos uma caixa de correio para cada percurso de entrega, grupo de políticas e localização relevantes. O teste abrange uma mensagem com um link e, caso seja utilizada operacionalmente, uma campanha com anexo e formação.

Antes do envio, documente os carimbos de data/hora, ID da campanha, destinatários, remetente esperado, domínio utilizado e IDs das regras alteradas. Em seguida, verifique:

1. O gateway aceita a mensagem e entrega-a exatamente uma vez na caixa de correio esperada.
2. Os valores efetivamente utilizados para a correspondência de regras prevista coincidem com a lista atual da Sophos: o domínio From visível relevante ou o domínio Envelope Sender/Return-Path e, se a regra for baseada em IP, o IP de origem do sistema SMTP remetente que o gateway responsável pela verificação registou como peer da ligação. Verifique estes campos separadamente; o IP do servidor recetor não pode ser utilizado como IP de origem do remetente.
3. A mensagem não fica em quarentena nem, inesperadamente, na pasta de correio não solicitado.
4. Não aparece nenhum evento de clique ou anexo no Phish Threat antes de uma ação do utilizador.
5. Um clique controlado do utilizador abre a página esperada de redirecionamento, simulação ou formação.
6. Exatamente essa ação aparece no resultado da campanha a uma hora plausível.
7. Os registos do proxy, firewall, DNS e scanner mostram a regra esperada, mas nenhum bypass desnecessariamente amplo.
8. Uma mensagem de teste externa normal e um destino Web não autorizado continuam a ser verificados de acordo com as políticas de segurança existentes.

O sucesso não significa apenas que “o e-mail chegou”. A entrega, a medição correta da campanha, os destinos Web acessíveis e a continuidade da eficácia dos controlos de segurança têm de ser confirmados em conjunto. Só depois a regra deve ser alargada ao grupo de destinatários previsto.

Isolar erros sistematicamente

Se a entrega falhar, verifique do primeiro ponto de aceitação para dentro: registo SMTP, gateway a montante, quarentena, regra de transporte a jusante e caixa de correio de destino. O erro SMTP ou o veredito do produto indica onde a mensagem foi rejeitada. Adicionar exceções amplas sem esta prova dificulta a análise da causa.

No caso de falsos cliques, compare a cronologia desde o envio até à entrega. Utilize os registos do scanner, o IP de origem e o User-Agent para atribuir um pedido automático reproduzível ao produto que o causa. Se os cliques reais não forem registados, verifique a resolução DNS, a decisão do proxy, a ligação TLS, os redirecionamentos e as extensões do browser.

Se a causa permanecer incerta, pare a campanha piloto. Uma exceção não deve ser progressivamente alargada até que a entrega funcione por acaso.

Reverter alterações e efetuar manutenção contínua

Antes da implementação, defina uma reversão para cada regra: estado anterior, ID da regra, exportação ou captura de ecrã, pessoa responsável e ordem da reversão. Se mensagens de terceiros forem entregues inesperadamente, a segurança for ignorada de forma demasiado ampla, ocorrerem acessos suspeitos através do proxy ou os dados da campanha continuarem distorcidos, desative a alteração ou restaure o último estado validado. Em seguida, verifique novamente os registos de e-mail e Web.

Aplique, no mínimo, os seguintes controlos durante a operação contínua:

• comparar os valores atuais com o Sophos Fusion antes de cada campanha importante,
• testar novamente as regras após uma alteração de produto, encaminhamento ou fornecedor,
• rever regularmente os wildcards e as exceções globais para determinar se é possível restringir o âmbito,
• remover domínios, IPs e regras legacy que já não sejam necessários,
• registar uma data de revisão, um proprietário e uma justificação técnica em cada exceção,
• após alterações, executar sempre uma campanha piloto sem falsos cliques automáticos.

FAQ