Falsificação de e-mail é uma das técnicas que os malfeitores usam para te convencer de que seus e-mails de spam/phishing são legítimos. Em resumo, a falsificação de e-mail é utilizada por esses agentes maliciosos para fazer parecer que seus e-mails vêm de fontes confiáveis, como seu banco, seu produto favorito ou seu chefe.

Os protocolos de e-mail existem há muito tempo. Protocolo Simples de Transferência de Correio (SMTP), o principal protocolo em que as comunicações por e-mail se baseiam, é de 1981. A internet mudou bastante, mas, infelizmente, o e-mail não. Quando o e-mail foi criado, havia apenas uma fração dos usuários de hoje. Naquela época, enviar um e-mail falso não causava muito dano. Agora, os e-mails são usados para quase todos os serviços digitais que você pode imaginar, e a tecnologia tem demorado a acompanhar.

Vamos começar falando sobre como os e-mails funcionam para que todos estejam na mesma página. Tenha paciência, esta é uma simplificação extrema de como o e-mail funciona, mas ajudará a explicar os mecanismos para tornar esse processo seguro. De forma geral, quando alguém envia um e-mail, acontece assim:

1. Alice (hi@alice.com) escreve um e-mail para Bob (hi@bob.com).
2. Alice envia o e-mail para seu servidor de e-mail para entrega.
3. O servidor de e-mail de Alice localiza o servidor de e-mail de Bob e transmite o e-mail.
4. Quando Bob se conecta ao seu servidor de e-mail, ele solicita novas mensagens e um novo e-mail aparece na caixa de entrada de Bob.

Simples! No entanto, muitas coisas podem dar errado no processo de envio de um e-mail. Vamos nos aprofundar!

Sender Policy Framework (SPF)

Ah, mas a Internet está cheia de horrores. Vamos imaginar que há um ator malicioso, vamos chamá-lo de Chuck, que quer enganar Bob para que ele lhe envie sua senha do Harvest.

Isso mesmo, o SMTP simples não nos diz se quem está enviando um e-mail é realmente quem diz ser.

Para proteger nossos e-mails desse tipo de ataque, podemos usar Sender Policy Framework (SPF). Quando um servidor de e-mail recebe um novo e-mail, ele pergunta ao domínio de origem se o remetente está autorizado a enviar e-mails em seu nome. É isso que o SPF faz; quando o servidor de e-mail de Bob recebe um e-mail que supostamente vem de alice.com, ele primeiro pergunta a alice.com se o verdadeiro remetente, chuck.com, pode enviar algo em seu nome.

Na imagem acima, você pode ver que o servidor de Bob realiza uma requisição DNS. Essa técnica e todas as outras mencionadas neste post são baseadas nesse protocolo. Quando falo sobre o servidor de e-mail de Bob perguntando a alice.com por algumas informações, isso significa apenas enviar uma requisição DNS para alice.com em busca de registros específicos.

Se alice.com não listou chuck.com como um de seus remetentes permitidos, então o servidor de e-mail de Bob pode marcar o e-mail como spam. Você ouviu certo, ele pode fazer isso ou pode não fazer. O servidor de Bob sempre tem a palavra final e há outras verificações a serem feitas antes de tomar uma decisão final.

DomainKeys Identified Mail (DKIM)

Os e-mails devem estar seguros agora, certo? Bem... nem tanto. Impedimos Chuck de enviar e-mails falsos de seus próprios servidores, mas o que aconteceria se ele encontrasse uma maneira de interceptar e-mails em trânsito? E se ele conseguisse alterar o conteúdo das mensagens de Alice? Lembre-se, o SPF apenas verifica se o remetente está autorizado a enviar e-mails em seu nome, mas não diz nada sobre o que acontece no caminho até o destinatário.

Esse é o cenário perfeito para usar assinaturas. No mundo digital, uma assinatura é um mecanismo para garantir e verificar que o conteúdo do que está sendo entregue não foi alterado. Quando Alice envia um e-mail para Bob, agora o servidor de e-mail de Alice adicionará uma assinatura ao conteúdo do e-mail. Se alguém alterar apenas um único bit dessa mensagem, Bob saberá. Além disso, o servidor de e-mail de Alice é o único que sabe como criar essas assinaturas. Ninguém mais pode fazê-lo sem que o destinatário perceba.

Isso é exatamente o que DomainKeys Identified Mail (DKIM) faz. Na prática, a configuração do DKIM começa no servidor de e-mail de Alice:

• Geralmente, há uma maneira de "começar a autenticar" os e-mails enviados. Isso geralmente significa apenas habilitar o DKIM.
• O servidor de e-mail pedirá que você publique algumas palavras criptografadas em seu DNS; essa é a chave pública da sua assinatura. Em linguagem simples, a chave pública permite que outros verifiquem se uma assinatura que receberam é válida e que a mensagem não foi modificada em trânsito. O servidor mantém a chave privada para que seja o único capaz de criar assinaturas.
• Uma vez que a chave pública é publicada, o servidor de e-mail começará a enviar uma assinatura com cada novo e-mail.

Como a assinatura é útil? Quando o servidor de e-mail de Bob recebe um e-mail com uma assinatura anexada, ele pode validar se a assinatura está correta. Para isso, o servidor precisa recuperar a chave pública e o conteúdo do e-mail. Com apenas essas duas coisas, o servidor pode detectar se houve alguma modificação indesejada.

Domain-based Message Authentication Reporting and Conformance (DMARC)

Agora Bob pode ter certeza de que os e-mails estão vindo de uma fonte confiável e que não foram adulterados, certo? CERTO?... Se fosse tão fácil... Chuck, nosso personagem malvado, ainda pode modificar o conteúdo do e-mail e simplesmente se livrar da assinatura DKIM. Quem precisa disso, afinal? É melhor ter uma verificação neutra do que uma negativa.

Mas nem tudo está perdido. Precisamos apenas de uma maneira de informar ao servidor de e-mail de Bob quais medidas de segurança foram configuradas e uma política que defina o que fazer se alguma delas falhar. Vamos para nosso último acrônimo: Domain-based Message Authentication, Reporting and Conformance (DMARC).

Com o DMARC, o servidor de e-mail de Bob tem um ponto público de informação que define o que fazer com os e-mails que recebe. Mais especificamente, um registro DMARC descreve:

• Se SPF ou DKIM são aplicados no e-mail recebido
• Um endereço de e-mail para relatórios de monitoramento
• Uma política para decidir o que fazer quando há uma verificação falha. Existem 3 políticas diferentes:
• Sem política - Os resultados da verificação DMARC serão ignorados. No entanto, os servidores de e-mail enviarão relatórios para análise posterior. Isso é frequentemente usado enquanto se configura o DMARC para ver se está funcionando como esperado.
• Quarentena - E-mails que falharem em qualquer verificação DMARC serão enviados para a pasta de spam do destinatário.
• Rejeitar - E-mails que falharem em qualquer verificação DMARC não chegarão ao destinatário.

O DMARC é a última peça em nossa caixa de ferramentas, e é o único que diz especificamente aos servidores de e-mail para descartar e-mails não conformes e sob quais circunstâncias isso acontece.

Conclusões

Estamos felizes em dizer que o Harvest está usando essas técnicas para proteger nossos e-mails. Levou meses de aprendizado e coleta de dados até chegarmos onde estamos agora. Tornamos muito difícil para outros nos impersonarem e minarem a reputação do Harvest. Essa foi uma conquista incrível que impactará nossos clientes para melhor.