24 de fevereiro de 2022

Usando o Sender Policy Framework para mitigar a falsificação

Por Tulsie Narine
Spoofing

O que é o Sender Policy Framework (SPF)?

O Sender Policy Framework (SPF) é um sistema de verificação de e-mail. Introduzido pela primeira vez pela Internet Engineering Task Force (IETF) em 2014, ele ajuda a determinar se o remetente de uma mensagem tem permissão para usar o domínio especificado.

Como funciona o protocolo SPF?

Um registro SPF - um registro DNS que identifica os hosts autorizados a enviar e-mails em nome de um domínio específico - é um registro de banco de dados que pode ser publicado e consultado pelo protocolo SPF. A adição de um registro SPF ao Sistema de Nomes de Domínios (DNS) também ajuda a proteger os destinatários e remetentes contra spam, falsificação e phishing; os remetentes podem estabelecer uma lista de servidores aprovados para enviar e-mails de seu domínio.

O e-mail é então verificado pelos servidores receptores para garantir que tenha sido originado de um servidor que tenha recebido permissão para enviar em nome do domínio específico do remetente. Se for determinado que o remetente não tem permissão para enviar o e-mail a partir desse domínio, a política de spam do servidor determinará o que fazer com a mensagem.

Embora o padrão SPF já exista há muitos anos, ele não foi totalmente adotado em todos os lugares, principalmente nas pequenas empresas e em algumas organizações de médio porte. Os atacantes têm como alvo as pequenas empresas, pois elas geralmente não possuem o conhecimento técnico para configurar o SPF.

Ao realizar ataques, um adversário disfarça o endereço de e-mail do qual está enviando os e-mails, uma técnica conhecida como spoofing. Como resultado, o e-mail parece ao destinatário como vindo de um endereço de e-mail conhecido e confiável.

Exemplo de e-mail falsificado: documento compartilhado do Google Drive contendo macro documento projetado para estabelecer a persistência da conectividade no end-point.

O processo Sender Policy Framework (SPF):

O diagrama abaixo ilustra as ações do servidor de e-mail receptor ao receber um e-mail.

1. O registro SPF é criado pelo administrador de domínio da organização e publicado em seus registros DNS.

2. O e-mail é escrito por alguém da organização remetente e enviado aos destinatários.

3. O e-mail é então transferido do servidor de e-mail da organização remetente para o servidor de entrada.

4. Ao receber o e-mail, o servidor de entrada lê o domínio do caminho de retorno indicado no cabeçalho do e-mail para consultar os registros DNS do domínio.

5. Em seguida, o servidor de entrada de e-mail pegará o endereço IP do remetente do e-mail e o comparará com os endereços IP que foram pré-autorizados no registro SPF.

6. Assim que o endereço IP do remetente do e-mail for confirmado como correspondente a um dos endereços IP no registro SPF, o e-mail será entregue ao destinatário pretendido. No entanto, se o endereço IP não corresponder a nenhum dos registros SPF, o servidor de e-mail de entrada utilizará as regras especificadas no registro SPF do domínio e bloqueará ou sinalizará a mensagem.

Como o Datto SaaS Defense usa SPF para evitar ataques de spoofing

O Datto SaaS Defense trabalha para evitar ataques de phishing e spam na primeira vez em que são encontrados. Primeiro, ele verifica se o e-mail recebido tem o domínio de toda a organização em seu endereço de caminho de retorno. Em seguida, o SaaS Defense acessa o registro SPF do domínio para verificar se o servidor de envio está autorizado. O SaaS Defense considera qualquer discrepância como um sinal definitivo de falsificação de e-mail.

 

O Datto SaaS Defense bloqueia e-mails enviados entre clientes em sua organização cujos registros SPF não estejam configurados corretamente. Embora o remetente não tenha nenhuma intenção maliciosa, um registro SPF impreciso resulta no bloqueio do e-mail.

Por que as organizações devem adicionar um registro SPF ao seu domínio

O SPF não é necessário para enviar e-mails, mas com a política em vigor, você fornece um sinal de confiança adicional ao servidor de e-mail receptor, aumentando a chance de os e-mails chegarem à caixa de entrada do destinatário.

Embora o SPF não erradique todos os problemas causados ​​pela falsificação de endereços IP, ele oferece uma camada adicional de proteção que, combinada com padrões como DKIM e DMARC , pode melhorar as taxas de entrega e prevenir abusos.

Limitações do Sender Policy Framework (SPF)

O Protocolo Simples de Transferência de Correio (SMTP) não oferece proteção ao conteúdo do campo " De " em um e-mail: o único requisito é um endereço de e-mail válido. Isso possibilita que agentes maliciosos se façam passar por uma instituição financeira, local de trabalho ou qualquer indivíduo – o que levou à criação do SPF (Proteção contra Falsificação de Endereço).

O SPF não verifica nem valida o domínio associado ao endereço de e-mail. Em vez disso, examina o Return-Path – o endereço usado pelo servidor de recebimento para notificar o servidor de envio sobre problemas de entrega. Por exemplo, o endereço de e-mail pode não existir no servidor de recebimento. Assim, um e-mail pode passar pela verificação SPF independentemente de o endereço " De " ser falso ou não.

Qual é a estrutura de um registro SPF?

Embora o processo de adição ou atualização de um registro SPF de cada provedor de e-mail possa variar um pouco, a sintaxe e os atributos do registro são universais.

Um registro SPF inclui os seguintes elementos (identificados na imagem abaixo). Embora pareça complicado, há três partes distintas.

  • Versão (prefixo) : Os domínios podem ter vários registros TXT, que contêm informações de propriedade do domínio, descoberta de serviço DNS e DKIM. O SPF1 é lido pelos analisadores e informa o registro usado para a verificação SPF.
  • Mecanismos : O mecanismo identifica um ou mais servidores de e-mail específicos a serem incluídos no registro SPF. O servidor de entrada de e-mail procura o mecanismo que corresponde ao endereço IP do remetente. Um registro SPF pode consistir em vários mecanismos, cada um separado por um espaço.
  • Regra de aplicação: Esta regra de qualificação identifica como o servidor de e-mail de entrada deve processar os e-mails enviados por um servidor caso este não esteja definido no SPF do domínio (ou seja, um e-mail de um servidor que não passa na verificação SPF).

Tipo de registro SPF Qualificadores

Há quatro qualificadores para indicar o rigor com que o servidor de entrada deve processar um e-mail de um servidor não autorizado.

Qualificador de falha: Menos (-tudo)

O qualificador menos significa falha - os e-mails de servidores não autorizados devem ser bloqueados, não entregues.

Qualificador de falha suave: Tilde (~todos)

O qualificador til significa falha suave - os e-mails de servidores não autorizados devem ser entregues, mas sinalizados como suspeitos (por exemplo, lixo eletrônico).

Qualificador de passagem: Mais (+todos)

O qualificador plus significa que os e-mails de qualquer servidor devem ser entregues. Não é recomendável usar esse qualificador.

Qualificador neutro: Ponto de interrogação (?todos)

O qualificador de ponto de interrogação significa neutro, não há política. Não é recomendável usar esse qualificador.

Quando um e-mail não passa nas verificações de SPF, ele não fica visível na maioria dos clientes de e-mail. Infelizmente, os agentes de ameaças perceberam isso e disfarçam os e-mails para que sejam originados de uma fonte confiável ou familiar para o destinatário. A neutralização dessas ameaças nos primeiros segundos de chegada mantém a caixa de correio do usuário protegida contra spam, phishing e e-mails falsos. A Proteção Avançada contra Ameaças, como o Datto SaaS Defense, é essencial em uma estratégia de defesa cibernética do cliente para identificar os e-mails em que o SPF falha e outras ameaças encontradas pela primeira vez com SPF válido.

Não deixe sua empresa vulnerável a ransomware e outros ataques cibernéticos. Participe do MSP Technology Day e aprenda como aproveitar o Datto SaaS Protection e o Datto SaaS Defence para fortalecer sua segurança.

Sugestões para as próximas leituras