Protegendo Emails De Falsificações com DMARC

O que é DMARC?

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é um sistema de autenticação de correio electrónico que protege os domínios da sua organização de ataques de spoofing, phishing e outros ataques cibernéticos. Baseia-se nas técnicas de verificação de correio electrónico amplamente utilizadas, SPF (Sender Policy Framework) e DKIM (Domain Keys Identified Mail).

Quais são os benefícios de configurar o DMARC

Nos artigos anteriores geramos, implementemos e configuramos o SPF e o DKIM, esses dois registro em nosso DNS já da um poder significativo de proteção para o envio de e-mails, com eles podemos assegurar que as chances de falsificação e rejeição dos seus e-mail vão cair bem próximas de zero, já que na informática nenhuma segurança pode ser 100% garantida. Agora daremos uma camada há mais de segurança com a implementação do DMARC.

As vantagem desse registro em nosso DNS são inúmeras, mas irei explanar as mais significativas. São elas:

• SPF + DKIM = DMARC
  • DMARC utiliza as tecnologias SPF e DKIM (DomainKeys Identified Mail) em conjunto para dar ao seu domínio uma proteção ainda melhor contra a falsificação.
• Relatórios e Feedback
  • Nem o SPF nem o DKIM dão ao proprietário do domínio feedback sobre e-mails que falham a autenticação. DMARC envia relatórios detalhados diretamente para si, com as ferramentas (Reporting Services), poderá gerar relatório em tempo real.
• Controlar o que acontece ao e-mail não autenticado
  • O DMARC permite-lhe, o proprietário do domínio, decidir se o e-mail que falhar a validação vai para a caixa de entrada, spam ou é rejeitado, isso só escolhendo as tag certas.

Agora que demos uma boa explanada nos recursos e vantagens do DMARC, vamos tratar de criar e registrar em nosso DNS.

Criando a instrução DMARC

Seguindo o exemplo dos artigos anteriores, vamos realizar um teste em nosso domínio para averiguar se já temos a implementação DMARC em nosso registro DNS. Eu uso um provedor de hospedagem para o domínio bidela.com.br, e a verificação online é um ótimo recurso ao invés de ficar perdendo tempo vasculhando registro de DNS do provedor que deve ter varias entradas para serem analisada.

Averiguando DMARC do Domínio

Mais uma vez vamos utilizar o MXToolBox para realizar nossa consulta DMARC.

Como era de se esperar não temos a instrução configurada em nosso DNS. Então vamos resolver isso.

Criado o conjunto de instrução DMARC

Antes de prosseguir vamos criar um e-mail para receber os relatório gerados pelo DMARC, por padrão é utilizado dmarc@seudominio.com, porém, você poderá configurar qualquer e-mail que quiser.

Com seu e-mail devidamente confeccionado vamos dar inicio.

Gerando Instruções DMARC

Para isso vamos recorre ao auxilio da seguinte ferramenta online Kitterman

Preencha o formulário de acordo com usa necessidade, alterando as informações pertinente ao seu domínio.

1. [1] Vários endereços são suportados (pelo menos dois). Insira uma lista separada por vírgulas para mais de um. O limite de tamanho opcional não é compatível com todos os provedores e o uso causará problemas de interoperabilidade a partir de 03/08/2014;
2. [2] Pode ser um volume muito alto – o endereço ruf deve estar preparado para receber MUITA correspondência.

Antes de mostrar como ficou a minha instrução DMARC vamos falar um pouco sobre os campos. Se entendermos os campos seremos capazes de criar nossa instrução sem auxilio de ferramentas e de forma mais ajustada de acordo com cada necessidade.

Explanando as tags DMARC

Domain

domínio que o DMARC será registrado. É o domínio que se aplica as instruções.

Required: Requested type

Política a ser aplicada a e-mails reprovados no teste DMARC. Os valores válidos podem ser ‘nenhum’, ‘quarentena’ ou ‘rejeitar’.

Uma tag de política DMARC permite que um remetente de e-mail instrua o destinatário sobre o que fazer se enviar uma mensagem que não seja compatível com DMARC. Essas ações podem ser colocar a mensagem em quarentena, rejeitá-la ou permitir que a mensagem seja entregue.

A tag de política “p” em um registro DMARC fornece ao servidor de recebimento de e-mail (aquele que recebe os e-mails que você envia) com um comando sobre o que fazer com um e-mail reprovado nos testes de conformidade do DMARC. Esse comando pode ser tão poderoso quanto dizer para rejeitar a mensagem, colocá-la em quarentena (colocá-la na pasta de spam) ou simplesmente não fazer nada.

Valores de tag de política

• p=none: com esta diretiva, o DMARC não altera a forma como o e-mail é tratado pelo destinatário. Em outras palavras, nenhuma ação é realizada / as mensagens permanecem sem exame.
• p=quarantine: Esta política separa e-mails questionáveis ​​para processamento posterior, que geralmente são exilados na pasta “Lixo”.
• p=reject: Quando os e-mails não vêm de sua infraestrutura de e-mail, esta designação faz com que o destinatário rejeite totalmente as mensagens que falham na autenticação DMARC.

Destacado abaixo está um exemplo de tag de política em um registro DMARC com um valor de “quarantine”:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@bidela.com.br;

Políticas sobre subdomínios
Este mesmo conceito pode ser aplicado a todos os subdomínios (ou seja, você pode definir uma política em todos os subdomínios para colocar em quarentena / rejeitar / ou não fazer nada para enviar mensagens que falhem no DMARC). Para saber mais sobre a tag DMARC Subdomain Policy, clique aqui.

Importante!
Se for novo na definição de uma política DMARC, recomendamos definir uma política de p=nenhum para permitir a familiarização com o processo geral e relatórios DMARC, para que grandes erros de entrega de email possam ser corrigidos para evitar a quarentena ou rejeição de emails legítimos. Nossa equipe de especialistas terá o prazer em ajudá-lo a implantar parâmetros DMARC mais rígidos e agressivos que funcionam melhor para a entrega de e-mail da sua empresa quando ideal. Dessa forma, o fluxo de correio de sua empresa evita interrupções e você recebe a orientação necessária de especialistas do setor para corrigir quaisquer problemas de falsificação de e-mail. Entre em contato com o nosso Comercial T2Creative.com.br

Optional Aggregate Data Reporting Address:

A tag usada no DMARC é RUA. É usada para designar um endereço ou endereços de e-mail para os quais os relatórios de feedback agregado DMARC serão enviados. Esses relatórios são incrivelmente valiosos para qualquer empresa que envia e-mail, pois eles fornecem uma visão da entrega de e-mail quando os relatórios são combinados. Mesmo que uma empresa não use o domínio para enviar e-mail, configurar um registro DMARC e receber esses relatórios DMARC pode fornecer informações sobre falsificação de domínio ou ataques de phishing que se fazem passar pelo domínio, o que pode afetar seus negócios e sua reputação.

Esta tag é definida como uma lista separada por vírgulas de endereços de e-mail para os quais você deseja que os relatórios agregados DMARC sejam enviados. Cada endereço de e-mail para o qual você deseja enviar relatórios deve ser formatado com um prefixo de mailto:

Exemplo de registro DMARC com um (1) endereço de e-mail para relatórios DMARC

v=DMARC1; p=none; rua=mailto:email1@bidela.com.br;

Esteja avisado que ao configurar este endereço de e-mail para receber relatórios, você deve selecionar um que seja totalmente dedicado ao recebimento desses relatórios, já que pode haver centenas a milhares por dia, dependendo do seu volume de e-mails. Também recomendamos o uso de um serviço de processamento de relatórios DMARC para que você possa entender / tomar medidas com relação a esses relatórios sem ser sobrecarregado.

Um exemplo de um registro DMARC com vários endereços de e-mail especificados na tag RUA é ilustrado abaixo:

Exemplo de registro DMARC (formato para vários endereços RUA destacado)

v=DMARC1; p=none; rua=mailto:email1@bidela.com.br,mailto:email2@bidela.com.br;

Forensic Data Reporting Address

Mesmo que apenas alguns destinatários de e-mail os enviem, eles podem ser úteis quando combinados com DMARC Aggregate Reports para investigar uma amostra de um problema maior de entrega de e-mail, como um erro SPF ou DKIM. Eles também podem ser muito úteis na confirmação de ataques de spoofing e phishing em andamento.

Para receber relatórios de falha com DMARC, a tag “ruf” é usada. Essa tag atua de forma semelhante à tag “rua” (que envia relatórios agregados DMARC), pois especifica o endereço de e-mail ou endereços de e-mail para os quais os relatórios de falha devem ser enviados. Esta tag é formatada como uma lista separada por vírgulas de endereços “mailto:”. Por exemplo, se você deseja receber relatórios de falha na caixa de correio “dmarc-failures@bidela.com.br”, você deve definir a tag “ruf” como ruf=mailto: dmarc-failures@example.com; .

Se você quisesse que os relatórios fossem para vários e-mails ou para um processador de relatórios DMARC, a tag seria semelhante a:

v=DMARC1; p=quarantine; pct=25; ruf=mailto:dmarc@bidela.com.br,mailto:dmarc-failures@suporte.com,mailto:dmarc-failures@servicoreport.com;

No exemplo destacado abaixo, um registro DMARC é exibido com um endereço de e-mail definido para receber relatórios de falha DMARC:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@; ruf=mailto:dmarcfailurereports@bidela.com.br

A tag ruf Forensic Data Reporting Address vai receber relatórios dependendo das configurações das tag abaixo.

Failure reporting options

O(s) destino(s) e a natureza dos relatórios de falha são definidos pelas tags “ruf” e “fo”. A tag “ruf” trata de onde os relatórios de falha devem ser enviados e a tag “fo”, que significa opções de relatório de falha, determina o tipo de relatório que é enviado. A tag fo é uma tag DMARC opcional e determina que tipo de autenticação e/ou problemas de alinhamento são relatados ao proprietário do domínio de saída.

Existem quatro tipos de relatórios de falha DMARC que podem ser enviados usando a tag “fo”:

• fo=0: Gera um relatório de falha DMARC se todos os mecanismos de autenticação subjacentes (SPF e DKIM) falharem em produzir um resultado de “aprovação” alinhado. (Predefinição)
• fo=1: Gera um relatório de falha DMARC se qualquer mecanismo de autenticação subjacente (SPF ou DKIM) produziu algo diferente de um resultado de “aprovação” alinhado. (Recomendado)
• fo=d: Gera um relatório de falha DKIM se a mensagem teve uma assinatura que falhou na avaliação, independentemente de seu alinhamento.
• fo=s: Gera um relatório de falha de SPF se a mensagem falhou na avaliação de SPF, independentemente de seu alinhamento.

Se desejar receber vários tipos de relatórios, você pode especificá-los usando dois pontos entre cada tipo. Por exemplo, se você quiser relatórios para 0,1, s; você adicionaria uma tag “fo” ao seu registro DMARC como a seguinte:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@bidela.com.br.com; fo=0:1:s;

SPF identifier alignment

Essa opção tem a seguinte tag aspf, essa específica indica a parte de alinhamento do identificador SPF de sua política DMARC. Como a designação adkim, a tag aspf pode ser utilizada nos modos relaxado (r) ou estrito (s). O alinhamento bem-sucedido acontece quando os domínios de endereço “Mail-From” e “From” são idênticos. Além disso, o padrão é automaticamente para a configuração aspf=r.

Destacado abaixo está uma tag aspf usada em um registro DMARC:

v=DMARC1; p=quarentena; pct=25; rua=mailto: dmarcreports@bidela.com.br; aspf=strict;

Alinhamento SPF Relaxado

No Alinhamento SPF relaxado, o domínio MailFROM e o domínio Header From devem ser uma correspondência exata ou uma correspondência pai/filho (ou seja, example.com e child.example.com). O tipo de correspondência pai/filho permite que qualquer subdomínio e par de domínio pai gere um resultado PASS. Também vale a pena observar, no cenário de correspondência pai/filho, o domínio MailFROM ou o domínio Cabeçalho de pode ser o domínio pai ou filho. Quando a configuração relaxada é especificada em um registro DMARC, ela se parece com o exemplo abaixo:

Tag de alinhamento SPF relaxado em um registro DMARC (aspf=r)

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@bidela.com.br; ruf=mailto:dmarcfailurereports@bidela.com.br; aspf=r;

MailFrom Domain é	O cabeçalho do domínio é	O resultado é
mail.example.com	example.com	PASSAR
exemplo.mail.com	example.com	FALHOU

Alinhamento SPF Estrito

Em alinhamento estrito (s), um registro DMARC será expresso com a tag aspf=s publicada conforme ilustrado abaixo:

Tag de alinhamento SPF estrito no registro DMARC (aspf=s)

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@mxtoolbox.com; ruf=mailto:dmarcfailurereports@bidela.com.br; aspf=s;

Agora, com a tag aspf=s publicada, o domínio Mail FROM e o domínio Header From devem corresponder exatamente. Abaixo estão dois exemplos, um exibindo uma correspondência exata gerando um resultado PASSA e outro exibindo domínios pai / filho que geram um resultado FALHA.

Domínio MailFROM é	O cabeçalho do domínio é	O resultado é
mail.example.com	mail.example.com	PASSOU
mail.example.com	example.com	FALHOU

DKIM identifier alignment

A tag adkim opcional refere-se ao modo de alinhamento para o protocolo DKIM. O alinhamento bem-sucedido ocorre quando o domínio pai (raiz) do seu e-mail do domínio de assinatura DKIM corresponde ao domínio “Header From”. Este descritor pode ser definido no modo r (relaxado) ou s (estrito). Se omitido em sua política DMARC, o padrão da tag adkim é adkim=r (relaxado).

Alinhamento DKIM relaxado

No alinhamento relaxado (r), o domínio DKIM e o domínio Header From devem ser uma correspondência exata ou uma correspondência pai/filho (ou seja, example.com e child.example.com). O tipo de correspondência pai/filho permite que qualquer subdomínio e par de domínio pai gere um resultado PASSA. Também vale a pena observar, no cenário de correspondência pai/filho, o domínio DKIM ou o domínio Cabeçalho de pode ser o domínio pai ou filho. Quando a configuração relaxada é especificada em um registro DMARC, ela se parece com o exemplo abaixo:

Tag de alinhamento DKIM relaxada em um registro DMARC (adkim=r)

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@mxtoolbox.com; ruf=mailto:dmarcfailurereports@mxtoolbox.com; adkim=r;

Domínio DKIM é	O cabeçalho do domínio é	O resultado é
mail.example.com	example.com	PASSAR
exemplo.mail.com	example.com	FALHOU

Alinhamento DKIM estrito

Em alinhamento estrito (s), um registro DMARC será expresso com a tag adkim=s publicada conforme ilustrado abaixo:

Tag de alinhamento estrito DKIM no registro DMARC (adkim=s)

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@mxtoolbox.com; ruf=mailto:dmarcfailurereports@mxtoolbox.com; adkim=s;

Agora, com a tag adkim=s publicada, o domínio DKIM e o domínio Header From devem corresponder exatamente. Abaixo estão dois exemplos, um exibindo uma correspondência exata gerando um resultado PASSA e outro exibindo domínios pai/filho que geram um resultado FALHA.

Domínio DKIM é	O cabeçalho do domínio é	O resultado é
mail.example.com	mail.example.com	PASSAR
mail.example.com	example.com	FALHOU

Report Format

Esta tag de formato de relatório (rf) é uma tag DMARC opcional que faz referência ao formato para relatórios de falha específicos de mensagem recebidos. O padrão é “Authentication Failure Reporting Format” (afrf), que é o único valor atualmente suportado. Um destinatário de e-mail vendo um valor diferente deve ignorá-lo ou desconsiderar todo o registro DMARC.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@bidela.com.br; rf=afrf

Além disso, o valor dessa tag para o proprietário do domínio é a capacidade de especificar o tipo de relatório XML que é recebido. O relatório é então enviado ao dono do domínio, retransmitindo os detalhes da falha individual.

Apply Policy to this Percentage

A tag de porcentagem DMARC (pct) é usada em combinação com a tag de política DMARC (p) para informar aos servidores de recebimento de e-mail como aplicar o valor da política DMARC às mensagens recebidas que falham no DMARC. Basicamente, o valor na tag “pct” é um valor percentual (1-100) que informa ao servidor de e-mail de recebimento, por exemplo, “aplique uma política de quarentena a 25% de todas as mensagens que falham no DMARC”. Essa declaração expressa em um registro DMARC seria assim:

v=DMARC1; p=quarantine; pct=25;

O principal uso da tag “pct” é permitir que um proprietário de domínio teste gradualmente a mudança de uma política DMARC de uma política de p=none para uma política de quarentena ou rejeição ( p = quarentena ou rejeição ) testando uma pequena amostra de mensagens que falham no DMARC para que mensagens legítimas com problemas de entrega possam ser detectadas antes de afetar todos os e-mails legítimos desse domínio.

Para obter todos os benefícios do DMARC, uma política deve ser definida para quarentena ou rejeição, mas, em muitos casos, mudar para essas configurações muito rápido pode fazer com que e-mails legítimos sejam acidentalmente colocados em quarentena ou rejeitados. Por isso mesmo, a tag “pct” é utilizada para aumentar gradualmente a percentagem de mensagens submetidas a quarentena ou rejeição e desta forma quaisquer erros detectados terão um impacto menor.

Um exemplo de implantação de registro DMARC comum com as tags “p” e “pct” teria a seguinte aparência:

Implantação de quarentena

• Etapa 1: p=quarantine; pct = 10
• Etapa 2: p=quarantine; pct = 25
• Etapa 3: p=quarantine; pct = 50
• Etapa 4: p=quarantine; pct = 75
• Etapa 5: p=quarantine; pct = 100

Entre cada etapa, haveria um período de espera de vários dias (ou semanas ou meses, se preferível) durante o qual os relatórios DMARC Aggregate Feedback podem ser analisados ​​para garantir que nenhum problema de entrega de e-mail seja detectado. Depois que um domínio atinge 100% da quarentena, o processo começa novamente com a rejeição aumentando de 10% para 100%.

Reporting Interval (default=86400):

A tag de intervalo de relatório DMARC é uma tag opcional que pode ser adicionada a um registro DMARC. Essa tag é usada para definir o número de segundos decorridos entre o envio de relatórios agregados ao remetente para fins de feedback DMARC. Em outras palavras, ele define o intervalo de relatório entre quando os relatórios devem ser enviados. Se omitido em seu protocolo, o valor do intervalo de relatório padrão é 86.400 segundos, o que equivale a 24 horas. A configuração padrão é considerada a configuração mais curta possível para receber relatórios DMARC, mas estes podem ser configurados para serem enviados com maior frequência (48 horas, 72 horas, etc.).

Esta tag é expressa na seção destacada do exemplo abaixo:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarcreports@bidela.com.br; ri=86400 ;

Subdomain Policy: Defaults to same as domain

Ao criar um registro DMARC para um domínio organizacional (pense bidela.com.br), um proprietário de domínio pode adicionar uma tag “sp” ao registro DMARC. Esta tag especifica determina qual deve ser a política para TODOS os subdomínios desse domínio. Essa tag funciona exatamente como a tag “p” , pois informa ao servidor de recebimento de e-mail (pense no Gmail antes que o e-mail chegue à sua caixa de entrada) o que fazer com um e-mail que falhe no DMARC. Devo colocar a mensagem em quarentena? Rejeitar? Ou não faz nada e permite que a mensagem continue a ser enviada? Com a tag “sp” publicada, o proprietário do domínio informa aos servidores de recebimento de email o que deve ser feito para enviar mensagens de qualquer subdomínio do domínio organizacional. Em suma, essa tag atua como um mecanismo para aplicar uma política em massa a todos os subdomínios.

Verdade seja dita, o valor real e o caso de uso para usar essa tag é no caso de um proprietário de domínio desejar políticas diferentes aplicadas ao e-mail de seus subdomínios em comparação com seu domínio organizacional primário. Incluímos alguns casos de uso para isso a seguir.

Exemplo 1: o proprietário do domínio só envia e-mail de subdomínios. Eles definiram uma política de “rejeição” no domínio organizacional de “example.com” e uma política de subdomínio “nenhum” para seus subdomínios. Em um registro DMARC, isso seria expresso com marcas de p = rejeitar; sp = nenhum

Exemplo de registro DMARC com p=rejeitar e sp=nenhum

v=DMARC1; p=reject; sp=none; rua=mailto:email1@bidela.com.br;

Exemplo 2: o proprietário do domínio não envia e-mail por meio de subdomínios e deseja impedir que agentes mal-intencionados falsifiquem subdomínios e enviem mensagens de phishing. Eles definem uma política de “nenhum” em seu domínio organizacional e uma política de subdomínio de “rejeição” para todos os subdomínios. Em um registro DMARC, isso seria expresso com tags de p = nenhum; sp = rejeitar;

Exemplo de registro DMARC com p = nenhum e sp = rejeitar

v=DMARC1; p=none; sp=reject; rua=mailto:email1@bidela.com.br;

Caso ocorra alguma dúvida ou algo a acrescentar, por favor, deixe no comentário.

Retomando…. Vamos incluir a imagem do resultado da instruções do meu DMARK.

A saída acima, em destaque amarelo será o nome da nossa entrada no DNS, o restante em destaque azul são as informações que entrara no valor d nossa entra.

Veja um exemplo abaixo

Após clicar em salvar vamos testar outra vez nosso DMARC e ver se agora temos uma resposta favorável de nossa consulta.

Como pode ser visto agora nosso DMARC está ok. A exclamação em amarelo está avisando que não temos uma regra definida, pois nossa classe p=none. Caso algum destinatário recebe um e-mail de nosso domínio sem ter passado pelas etapas de verificação, o servidor destinatário irá toma a decisão do que fazer com esse e-mail, rejeitar, quarentena ou encaminha par caixa postal destinada.

Eu preferi deixar a tag p=none, pois assim eu teria com avaliar o que fazer exatamente com os e-mails, após analisar os relatório que a conta dmarc@bidela.com.br vai receber, assim poderia tomar as decisões mais assertivas no que fazer nos e-mail invalido e ter certeza de que eles são inválidos.