DMARC
Domain-based Message Authentication, Reporting & Conformance
História
O E-mail é um dos serviços mais utilizados para comunicação na Internet mas não foi projetado com qualquer privacidade ou segurança em mente. O e-mail não é seguro porque nunca foi concebido para ser o centro das nossas vidas digitais. Ele foi desenvolvido quando a Internet era um lugar muito menor com objetivo de padronizar o simples armazenamento e encaminhamento de mensagens entre pessoas usando diferentes tipos de computadores.
Várias tentativas foram feitas ao longo dos anos para validar que a pessoa que enviou um e-mail é quem eles dizem que são.
Para mudar esse panorama de insegurança, em 2012 formou-se uma iniciativa global que criou o protocolo DMARC. Grandes empresas como PayPal, Facebook, Yahoo, Google, linkedin e Microsoft criaram esse robusto mas complexo protocolo de segurança.
O DMARC (Domain-based Message Authentication, Reporting & Conformance) usa dois protocolos previamente definidos SPF e DKIM e permite que os proprietários de domínio digam explicitamente ao servidor de e-mail de recebimento o que fazer
com um e-mail que falha em uma tentativa de autenticação.
SPF (Sender Policy Framework)
O SPF é uma das primeiras tentativas de validação de comunicações por e-mail. Baseia-se em um registro publicado no DNS do remetente e contém os domínios e os IPs dos serviços autorizados a enviar e-mails em nome de um determinado domínio. O servidor de e-mail de recebimento examina o domínio no endereço indicado no campo do caminho de retorno do e-mail e, em seguida, passa para o DNS desse domínio e examina o registro SPF, se o endereço IP de origem corresponder a um dos endereços IP dentro do DNS Grave então o SPF passa.
O principal problema com o SPF é que ele valida o domínio no caminho de retorno que não é visível para o usuário através dos clientes de email mais comuns. Um usuário poderia estar vendo um e-mail válido SPF com um endereço “De” de uma fonte
confiável, que não era originário dessa fonte.
Se o SPF for implementado por conta própria, sem DMARC, ele só fornece um sinal para o servidor receptor e não bloqueia os e-mails de serem entregues ao usuário final. No máximo, aumenta o escore de spam de um e-mail. Isso não é suficiente se o email for um ataque de fraude.
DKIM (DomainKeys Identify Mail)
O DKIM é um padrão mais recente e mais complexo que o SPF. A funcionalidade é baseada em uma assinatura criptográfica de partes do e-mail com uma chave de duas partes, uma parte é armazenada nos metadados do e-mail e a outra parte é publicada no registro DNS do domínio do remetente.
O principal problema com o DKIM é que o domínio de assinatura indicado na chave dentro do e-mail pode ser diferente da do cabeçalho from. Um usuário pode ver um email com assinatura válida com um endereço “De” de uma fonte confiável, que não foi assinada por essa fonte.
Da mesma forma que no SPF, a validação da DKIM pode passar ou falhar e o servidor de e-mail de recebimento decide o que fazer, uma vez que o DKIM é bem usado, mas não é obrigatório em todos os emails, os servidores receptores não bloqueiam os e-mails não assinados ou DKIM não validados. Isso não é suficiente se o email for um ataque de fraude.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
O DMARC usa os resultados de validação de SPF e DKIM e verifica os nomes de domínio em relação ao endereço FROM no e-mail. Se a validação for bem-sucedida e o nome do domínio alinhar, o resultado da validação do DMARC será aprovado.
Além disso, o DMARC pode dizer explicitamente ao servidor receptor o que fazer com um e-mail se falhar o SPF e o DKIM. Esta política está indicada no registro DMARC DNS:
- Nada. Isso é indicado no parâmetro p = none. Isso significa que o servidor de e-mail de recebimento não é instruído a agir em relação a um e-mail que falha no DMARC. Esta política é regularmente o estado inicial de qualquer domínio que deseja implementar sua política de DMARC e, mesmo que não bloqueie emails fraudulentos, permite que os proprietários de domínio permitam o relatório, o que é útil para entender o tráfego de e-mail de um domínio e verificar se a sua configuração inclui todos os serviços de e-mail válidos.
- Quarentena. Avisa o servidor de e-mail de recebimento para enviar qualquer e-mail que falhe na validação do DMARC para a pasta SPAM do usuário.
- Rejeitar. Indica ao servidor de e-mail de recebimento que rejeite ativamente os e-mails que falham na validação do DMARC. Tais e-mails são rejeitados e nunca chegam à conta de e-mail do destinatário pretendido. Esta política é recomendada para efetivamente bloquear ataques cibernéticos que começam com a personificação de e-mail.
Finalmente, o DMARC também fornece uma provisão para relatar todas as tentativas de validação. Um endereço de e-mail pode ser especificado no registro DMARC e o servidor receptor pode enviar relatórios que incluem informações como o endereço IP da origem de um e-mail. Isso é particularmente útil para entender a frequência e quantidade de e-mail não autorizados.
Implementação
Implementar o DMARC pode ser um pouco complexo por várias razões:
- A maioria das organizações usa serviços adicionais para enviar e-mails em seu nome. Se esses serviços não estiverem devidamente identificados em sua configuração, eles podem falhar.
- Os relatórios DMARC contêm uma quantidade vasta de dados que precisam ser convertidos em insights e ações.
- Pode ser difícil implementar sua política de bloqueio p = reject sem bloquear nenhum serviço de e-mail válido.
Existe ferramenta para implementar o DMARC: OnDMARC, que é um serviço em nuvem que entende seu tráfego atual e fornece recomendações passo a passo para implementar e manter sua política de DMARC, fornecendo um caminho claro e rápido para a rejeição total do e-mail inválido.
O sistema de relatórios OnDMARC destaca o tráfego específico que os proprietários de domínio podem verificar como válidos ou não. Os pontos no tráfego de uma fonte específica são destacados e podem ser identificados como provenientes de uma fonte fraudulenta ou de um novo sistema de mensagens, permitindo aos usuários atualizar facilmente sua configuração.
A rejeição total de e-mails não validados é fundamental para garantir que mensagens fraudulentas não cheguem aos usuários finais. Chegar à rejeição total é uma viagem por conta própria e o OnDMARC está com você em cada etapa, ajudando você a garantir que todas as suas fontes de e-mail válidas estejam incluídas na sua configuração. Quando isso é claro, ele ajuda você a implementar sua política para p = reject o que efetivamente bloqueia e-mails não validados.
F.A.Q
O que é spoofing?
No contexto de Spoofing , especialmente quando falamos sobre segurança de rede , é um ataque de falsificação. É o ataque em que uma pessoa ou programa se disfarça com sucesso por falsificar dados, para obter uma vantagem ilegítima.
O que é phishing?
O termo Phishing é o ato de obter informações de usuários como senhas, dados de cartões de crédito, dados pessoais, etc. Estes criminosos se passam por uma determinada pessoa ou empresa, que muitas vezes são de fontes conhecidas, para ganhar a confiança e enviar mensagens de fraude.
Os criminosos utilizam serviços de e-mail, aplicativos e sites que tem como objetivo roubar essas informações pessoais.
O que é spear phishing?
O termo Spear phishing diz respeito a um golpe realizado através do serviço de e-mail que tem como objetivo obter acesso não autorizado a dados sigilosos da empresa. Diferente dos golpes de phishing, que tem o foco em ataques amplos e genéricos, o spear phishing foca em um grupo ou organização específicos. A intenção deste tipo de ataque é roubar propriedade intelectual, dados financeiros, e outros dados confidenciais.
O que é o protocolo SPF?
O protocolo SPF (Sender Policy Framework) foi desenvolvido para combater a falsificação do endereço do remetente. É um protocolo de autenticação que verifica as identidades MAIL FROM ou HELO/EHLO durante a transmissão de e-mail. O SPF faz isso comparando o endereço IP do servidor de envio a uma lista de remetentes autorizados. Os remetentes autorizados são os endereços IP que podem ser enviados em nome do domínio de envio. Eles são especificados em um registro TXT publicado no DNS do proprietário do domínio.
Se a extremidade receptora suportar SPF, então, após o recebimento de um email, ele verifica se o endereço IP de envio está autorizado a enviar em nome do domínio e, se não estiver nessa lista, a autenticação SPF falhará.
O que é o protocolo DKIM?
O protocolo DKIM (Domain Keys Identified Mail) é usado para assinar diferentes campos de cabeçalho e corpo de um email para autenticar o domínio de envio e impedir a modificação da mensagem durante o trânsito.
Ele consegue isso usando criptografia assimétrica, que consiste em chaves públicas e privadas. A chave privada é utilizada para o domínio do remetente e usada para assinar os e-mails. A chave pública é publicada no DNS do remetente para que possa ser recuperada por qualquer pessoa que receba mensagens do remetente.
De forma geral, quando um email é composto, seus cabeçalhos e corpo são assinados usando a chave privada do remetente para criar uma assinatura digital, que também é enviada como um campo de cabeçalho junto com o email. No lado do receptor (se o DKIM estiver ativado), o servidor recupera a chave pública e verifica se o email foi de fato assinado pelo domínio de envio. Se a assinatura for validada com sucesso, isso prova que o domínio de envio enviou a mensagem e também que os cabeçalhos e o corpo da mensagem não foram modificados durante a transmissão.
O que é o protocolo DMARC?
O DMARC (Domain-based Message Authentication, Reporting & Conformance) é um protocolo que foi construído sobre os protocolos existentes SPF e DKIM. O DMARC faz algumas coisas:
- Leva em conta os resultados do SPF e do DKIM para realizar a autenticação;
- Requer não apenas que o SPF ou o DKIM passem, mas que o domínio usado por qualquer um também se alinhe com o domínio encontrado no endereço DE para que o DMARC seja aprovado.
- Relatórios SPF, DKIM e DMARC retornam ao domínio encontrado no endereço DE (ou seja, remetente).
- Finalmente, diz aos destinatários como tratar os emails que falharam na validação do DMARC, especificando uma política no DNS.
O que é o protocolo ARC?
O SPF tende a falhar durante o encaminhamento devido à alteração do endereço IP durante o encaminhamento. O DKIM também pode falhar se o conteúdo do email for alterado em trânsito, se algo for adicionado ou removido, fará com que a assinatura do DKIM falhe.
O ARC foi desenvolvido para preservar os resultados de autenticação de emails ao viajar por vários saltos e inserir seus próprios cabeçalhos. Se o DMARC falhar durante o trânsito, o destinatário poderá optar por examinar os resultados do ARC, substituir os resultados do DMARC e aceitar os emails. Alguns exemplos de onde o SPF, o DKIM e o DMARC podem falhar são mostrados na figura abaixo.
| Case | SPF | DKIM | DMARC |
| Direct mail flow | ✔️ | ✔️ | ✔️ |
| Alias forwarding | ❌ | ✔️ | ✔️ |
| Mailing Lists | ❌ | ❌ | ❌ |
| Recipient forward service | ❌ | ✔️ | ✔️ |
| Filtering device forwarding | ❌ | ❌ | ❌ |
Exemplos quando o SPF, o DKIM e o DMARC podem passar ou falhar.
Alguns dispositivos de filtragem podem modificar as mensagens à medida que são encaminhadas e, portanto, é mostrado que o DKIM pode quebrar.
O ARC não foi projetado para indicar se os intermediários do fluxo de mensagens indireto podem ser confiáveis ou não, ou se o conteúdo adicionado por eles pode ser confiável. O ARC ainda está em seus estágios iniciais, mas alguns ESPs e ISPs já implementaram e outros estão a caminho.
Eu já tenho configurado SPF, eu realmente preciso de DMARC para proteger meu domínio? O que o DMARC faz que o SPF não faz?
Para responder este questionamento, vamos primeiro explicar o que o protocolo SPF faz e o que ele não faz:
O que Faz:
- O SPF autentica o servidor de envio do email com base no endereço IPv4 / IPv6 de envio.
- O SPF concentra-se em um cabeçalho que não é visível para o usuário final (Return-Path, MAIL FROM, Envelope-De, endereço de retorno, HELO/EHLO).
O que NÃO faz:
- O SPF não requer nenhum alinhamento entre o domínio visível do usuário final e o Return-Path normalmente invisível que ele realmente verifica.
- O SPF não fornece nenhuma funcionalidade de relatório para o destinatário enviar de volta ao remetente com os resultados da autenticação de email.
- O SPF não sobrevive ao encaminhamento e aos fluxos de mensagens indiretas.
- O SPF não informa ao servidor de recebimento o que deve fazer com um email que falhou no SPF. Por exemplo, os remetentes podem publicar “todos”, mas isso nunca foi respeitado pelos destinatários, pois o SPF falha com facilidade e isso faria com que e-mails legítimos fossem rejeitados. Este é o equívoco mais comum considerado em relação ao SPF.
Isso levou à introdução de um padrão adicional de autenticação de e-mail. Esse padrão precisava resolver as deficiências do protocolo SPF autônomo, explicando aos receptores o que fazer e fornecendo relatórios de autenticação. Esses relatórios permitiram que o remetente tomasse as ações necessárias para corrigir fluxos de mensagens legítimos. Este padrão foi finalmente formalizado como o protocolo DMARC.
O DMARC utiliza o SPF como uma de suas fundações, mas também adiciona recursos adicionais, como:
- Concentra-se no cabeçalho “De” que é visível para o usuário final (cabeçalho de).
- O DMARC requer que o domínio usado pelo SPF se alinhe (uma correspondência exata ou um subdomínio) com o domínio encontrado no endereço “De” visível do email.
- O DMARC ignora as nuances da falha branda e da falha branda na sua configuração SPF, ou seja, all e all são tratadas de maneira equivalente quando ocorre falha no SPF.
- O DMARC fornece a funcionalidade de geração de relatórios para enviar os resultados da autenticação de e-mail de volta para o proprietário do domínio “De”, para que eles possam descobrir se seu domínio está sendo usado incorretamente. Ele também ajuda na solução de problemas de sua capacidade de entrega, pois o relatório ajudará a descobrir qualquer configuração incorreta com seus remetentes de e-mail legítimos.
- O DMARC fornece uma política que informa aos destinatários o que fazer com um email que falha na autenticação de email. Esta política é aplicada pelos destinatários. Não há aplicação quando o SPF é usado sem o DMARC.
Agora que o DMARC está aqui para fornecer as peças que faltam, ele está sendo amplamente adotado e usado como um requisito de autenticação, que vem com o bônus adicional de melhorar a capacidade de entrega de e-mail. Outro protocolo do qual o DMARC se baseia é o DKIM, que serve como um fail-safe nos casos em que o SPF falha.
Já possuo anti-spam. Estou protegido?
Existe um certo equívoco tanto de usuários como de empresas, de que a ferramenta anti-spam protege contra ataques de phishing. As ferramentas anti-spam apenas redirecionam, ou não, os e-mails fraudulentos para a caixa de spam. Mas mesmo utilizando uma ferramenta anti-spam, um criminoso ainda conseguirá realizar um ataque de phishing utilizando seu domínio. Por exemplo, com esta fragilidade, o criminoso poderá enviar e-mails para clientes ou fornecedores se passando por alguém de sua empresa.
Já com a implantação do protocolo DMARC além de garantir a proteção interna de sua empresa, você garante a autenticidade de seus e-mails enviados para clientes, fornecedores e demais contatos de sua confiança.
Como faço para me proteger?
A correta implantação do protocolo DMARC fornece diversos níveis de segurança ao seu domínio de e-mail. Mas por ser um protocolo complexo e robusto, a implantação pode tornar-se complexa para a correta identificação de todos os serviços utilizados. Caso o protocolo DMARC seja colocado em modo de rejeição, e um ou mais serviços não forem corretamente configurados, o protocolo poderá falhar e os e-mails não serem entregues.
No mercado existem diversas soluções que oferecem serviços para auxiliar no processo de implantação do protocolo DMARC. A principal solução existe no mercado e com certificação ISO 27001, é o OnDMARC. O OnDMARC é um serviço em nuvem que entende seu tráfego atual e fornece recomendações passo a passo para implementar e manter sua política de DMARC, fornecendo um caminho claro e rápido para a rejeição total do e-mail inválido.