Sophos Email: configure a autenticação do remetente e Smart Banners

O Sophos Email verifica as mensagens recebidas com DMARC, SPF e DKIM e também pode detetar anomalias nos cabeçalhos e domínios. Estas verificações não determinam, por si só, como uma mensagem é tratada: a Email Security policy aplicável define os tipos de falha, a respetiva ordem e as ações a executar. Os Smart Banners apresentam o resultado aos destinatários e podem disponibilizar-lhes ações seguras.

Procedimento rápido recomendado: Em My Products > Email Security > Policies, abra a Email Security policy afetada e configure, em Settings > Inbound > Authentication, as ações para falhas de DMARC, SPF e DKIM. Numa primeira fase, defina Quarantine para as falhas críticas em vez de Reject, ordene as condições de cima para baixo e, depois, reveja Header anomaly, Domain anomaly e End-user message settings. Compare mensagens de teste legítimas e mensagens com falhas em Message History antes de adicionar exceções ou ativar ações mais rigorosas.

Preparar o âmbito, os testes e a reversão

Antes de efetuar alterações, identifique os domínios e as caixas de correio protegidos, os serviços de envio legítimos conhecidos e um grupo de teste restrito. Registe:

a política afetada, a respetiva posição e se está definida como Enforced;
a direção Inbound e os utilizadores, grupos e domínios atribuídos;
as regras atuais de DMARC, SPF, DKIM e verificação do remetente, pela ordem em que se encontram;
as entradas existentes na lista de permissões e as exceções aprovadas pela empresa;
as ações originais, o texto dos banners e as opções dos utilizadores finais;
os remetentes e destinatários de teste, bem como os resultados esperados.

Para reverter as alterações, restaure a ordem das regras, as ações e as opções dos banners que registou ou defina uma nova política piloto como Policy Bypassed. Durante o piloto, altere apenas um conjunto relacionado de regras de cada vez, para que qualquer resultado inesperado possa ser atribuído com clareza.

Aviso: Nunca utilize uma exceção de autenticação como motivo para desativar a análise de malware. Mesmo um remetente permitido ou corretamente autenticado pode utilizar uma conta comprometida ou enviar conteúdo malicioso. Limite cada exceção ao problema de autenticação comprovado e ao menor âmbito necessário, mantendo todas as restantes verificações de proteção ativas.

Compreender corretamente DMARC, SPF e DKIM

Os três métodos respondem a perguntas diferentes:

SPF compara o servidor de correio que envia a mensagem com os hosts, endereços IP e redes autorizados no DNS pelo proprietário do domínio do remetente do envelope.
DKIM valida a assinatura digital de uma mensagem através da chave pública publicada no DNS pelo domínio que a assinou.
DMARC avalia se SPF ou DKIM é validado e se o respetivo domínio está alinhado com o domínio visível no cabeçalho From. Sem um registo DMARC válido e uma verificação SPF ou DKIM que possa ser avaliada, o Sophos não consegue concluir a avaliação DMARC.

O seletor apresentado na política controla a ação em caso de falha; as próprias verificações de autenticação são sempre executadas. Este artigo abrange apenas a avaliação das mensagens recebidas. Não cria nem aloja registos DNS para os seus domínios de envio e não ativa a assinatura DKIM das mensagens enviadas.

Configurar Message Authentication

Abra My Products > Email Security > Policies, selecione a política Email Security correta e confirme o respetivo grupo-alvo e posição.
Abra Settings > Inbound > Authentication.
Ative as ações necessárias para falhas de DMARC, SPF e DKIM.
Para cada verificação, clique em Add Rule e selecione um tipo de falha e a ação correspondente.
Ordene as condições do caso mais específico para o mais geral. O Sophos verifica-as de cima para baixo e aplica a primeira correspondência.
Guarde a política e confirme que está definida como Enforced para os destinatários de teste.

A Sophos recomenda Quarantine para cada categoria de Message Authentication. É também uma definição adequada para um piloto, porque a mensagem permanece disponível para análise e libertação controlada. Reject recusa a mensagem durante o processamento; no Sophos, os cabeçalhos em bruto não ficam disponíveis para mensagens rejeitadas. Tag subject line marca a mensagem e encaminha-a para as fases de processamento seguintes. Deliver também significa que a mensagem passa à camada de análise seguinte, não que seja necessariamente entregue na caixa de correio. Include In End User Quarantine disponibiliza uma mensagem em quarentena na quarentena do utilizador.

Avaliar deliberadamente os tipos de falha

Para DMARC, Hard failure significa que nem SPF nem DKIM são validados com o alinhamento necessário. A predefinição é Conform to sender policy, pelo que o tratamento segue a política DMARC do remetente. Também estão disponíveis p=none, Unsupported, Temporary failure e Permanent failure. Neste contexto, Unsupported aplica-se apenas ao Gateway mode, enquanto M365 bestguesspass se aplica apenas ao M365 Mailflow mode. Uma regra p=none separada é particularmente útil quando Hard failure permanece definido como Conform to sender policy.

Para SPF, além de Hard failure, estão disponíveis Soft failure, Neutral, Unsupported, Temporary failure e Permanent failure. Para DKIM, além de Hard failure, estão disponíveis Unsupported, Temporary failure e Permanent failure. Um erro temporário de DNS pode desaparecer sem intervenção; uma falha permanente indica que o registo publicado não pode ser interpretado. Nenhum destes resultados deve ser automaticamente considerado uma prova de falsificação do remetente.

Ordem de processamento e Sender check

As verificações de Message Authentication são executadas pela ordem apresentada na política. Para avaliar DMARC, o Sophos efetua as verificações SPF e DKIM necessárias, independentemente das ações configuradas para as respetivas falhas. DMARC falha se nem SPF nem DKIM forem validados com o alinhamento necessário. Quando existem várias regras de falha, é sempre aplicada a primeira regra correspondente, de cima para baixo.

Se uma regra DMARC, SPF ou DKIM corresponder a Quarantine ou Reject, o processamento desse ramo é interrompido. Se as três verificações forem aprovadas numa configuração que utilize estas ações, as verificações de anomalias dos cabeçalhos deixam de ser processadas e a mensagem é entregue. A ordem afeta, portanto, o comportamento de segurança; não é apenas uma disposição visual no portal.

Em Sender check, o Sophos acrescenta duas verificações de anomalias:

Header anomaly protege os seus próprios domínios contra falsificação externa. É acionada apenas quando o domínio no cabeçalho From visível corresponde a qualquer domínio configurado na conta Sophos Fusion (anteriormente Sophos Central) e esse endereço do cabeçalho é diferente do endereço MAIL FROM no envelope SMTP. São verificados todos os domínios da conta, e não apenas o domínio do destinatário.
Domain anomaly deteta domínios de remetentes que não têm um registo MX nem um registo A.

Para ambas as verificações, pode selecionar Tag subject line, Quarantine, Reject ou Deliver; Tag subject line é a predefinição documentada. Durante o piloto, utilize a marcação ou a quarentena e analise reencaminhamentos legítimos, sistemas CRM, plataformas de gestão de pedidos e serviços de envio externos antes de ativar Reject.

Configurar Smart Banners

Em End-user message settings, ative separadamente cada tipo de banner, adapte o texto predefinido e selecione as ações a disponibilizar aos utilizadores. As definições aplicam-se a mensagens externas recebidas em HTML e em texto simples. As mensagens da Sophos, como os resumos de quarentena, não recebem um Smart Banner.

A cor e o texto do banner dependem da lista de permissões e do resultado DMARC:

Trusted é verde: o remetente consta da lista de permissões e a mensagem passou a verificação DMARC.
External é amarelo: o remetente passou a verificação DMARC, mas não consta da lista de permissões; consta da lista, mas Trusted está desativado; ou não tem um registo DMARC, pelo que não é possível determinar um resultado positivo ou negativo.
Untrusted é laranja: existe uma política DMARC, mas a mensagem não passou a verificação DMARC.

Um banner ajuda a tomar uma decisão, mas não prova que a mensagem é inofensiva. Mesmo um banner verde não substitui a análise de conteúdo nem a prudência ao abrir ligações e anexos.

Ativar ações dos utilizadores em segurança

Em cada banner, pode disponibilizar Allow sender, Block sender e Report Spam messages to Sophos. Allow e Block abrem uma página de confirmação e atualizam a lista pessoal do utilizador; Report envia a mensagem para o SophosLabs como spam.

O guia de exceções Inbound Allow/Block explica como as entradas pessoais e globais interagem e como as proteger com autenticação, exportação, importação e reversão.

Para que Allow sender e Block sender funcionem no banner HTML, abra Global Settings > Products and Services > Email > User Settings, ative primeiro Release/Delete, depois Allow/Block List, e guarde. As ligações Allow e Block não estão disponíveis nos banners em texto simples.

Quando são utilizadas ligações nos Smart Banners, o correio enviado tem de ser encaminhado através do Sophos Fusion. A Sophos recomenda que configure este encaminhamento antes de ativar End-user message settings; caso contrário, os destinatários externos poderão ver o banner em respostas ou mensagens reencaminhadas. Em HTML, o banner aparece a cores na parte superior; em texto simples, aparece como texto no início do corpo. Um banner existente pode continuar visível quando alguém responde a uma mensagem ou a reencaminha internamente.

Validar o resultado em Message History

Para cada âmbito de política relevante, envie mensagens recebidas controladas para um destinatário piloto:

uma mensagem legítima que deverá ser autenticada com êxito;
uma mensagem legítima enviada através de um serviço de reencaminhamento ou envio conhecido;
quando for possível fazê-lo em segurança, uma mensagem do seu próprio domínio de teste com uma falha de autenticação provocada e documentada intencionalmente.

Não falsifique correio de produção nem altere os registos DNS de terceiros para efetuar um teste. Em Message History, pesquise por remetente, destinatário e intervalo de tempo, abra a mensagem e compare a política aplicada, a categoria, os detalhes da autenticação ou da verificação do remetente e a ação efetivamente executada. Nas mensagens entregues, confirme também o tipo, o texto, a cor e as ações visíveis do banner em HTML e em texto simples. O resultado é correto quando as mensagens legítimas chegam à fase de análise seguinte ou à caixa de correio esperada, as falhas acionam a primeira ação configurada correspondente e não são apresentadas ações de utilizador imprevistas.

Resolver problemas metodicamente

Falha inesperada de DMARC ou DKIM: Preserve os cabeçalhos em bruto e os detalhes da verificação do remetente. Verifique se um gateway a montante, uma declaração de exoneração de responsabilidade, uma lista de distribuição ou um percurso de reencaminhamento alterou o corpo ou os cabeçalhos assinados. Sobretudo quando o Sophos EMS se encontra atrás de outro sistema principal de segurança de correio eletrónico, essas alterações podem invalidar DKIM e o alinhamento DMARC; a falha, por si só, não prova a existência de risco.
Ação incorreta apesar de uma regra correspondente: Verifique primeiro o âmbito, a aplicação e a ordem das políticas e, depois, leia as regras de falha de cima para baixo. Uma correspondência geral anterior pode ocultar uma regra específica posterior.
Header anomaly num serviço legítimo: Compare o cabeçalho From visível com o MAIL FROM do envelope e identifique qual dos seus domínios correspondeu. Corrija primeiro a configuração de envio ou o alinhamento. Considere uma exceção de autenticação com um âmbito muito restrito apenas se a correção não for possível e o serviço estiver inequivocamente identificado.
Domain anomaly em correio legítimo: Teste separadamente a resolução dos registos MX e A do domínio do remetente. Não resolva um problema temporário de DNS com uma regra de permissão global e permanente.
Banner em falta: Verifique se a política e o tipo de banner corretos estão ativos, se a mensagem era externa e recebida e se não é uma mensagem de sistema do Sophos.
Allow/Block em falta ou sem funcionar: Verifique Release/Delete e Allow/Block List em User Settings, o formato HTML e o encaminhamento do correio enviado através do Sophos. Estas ligações não estão disponíveis em texto simples.

Só depois desta análise deve alterar a ordem, a ação ou a entrada estritamente necessária e mais restrita na lista de permissões e repetir o mesmo teste. Se o resultado continuar pouco claro, recolha o Message-ID, o carimbo de data e hora, o remetente, o destinatário, o nome da política, a ação efetiva e os cabeçalhos em bruto completos para encaminhar o caso, em vez de ignorar de forma generalizada a autenticação ou a proteção contra malware.