Aprendizado e teste de DMARC

 (learndmarc.com)
2 pontos por GN⁺ 2023-10-02 | 1 comentários | Compartilhar no WhatsApp
  • O LearnDMARC permite aprender e testar SPF, DKIM e DMARC, os elementos centrais da autenticação de e-mail, em uma única tela, e a explicação visual completa pode ser vista no desktop
  • A tela de resultados mostra primeiro informações de conexão como Source IP address, Hostname e Sender, para verificar o ponto de partida da avaliação de autenticação
  • SPF e DKIM mostram, cada um, o domínio alvo da autenticação e o resultado, além de indicar se há Alignment, necessário para a avaliação de DMARC
  • A área de DMARC reúne RFC5322.From domain, Policy (p=), resultados de SPF e DKIM, conectando tudo ao resultado final de DMARC
  • Por fim, é possível verificar a avaliação geral em Final verdict, e também são oferecidos anonimização dos resultados e um link para aprender sobre DMARC

Objetivo do LearnDMARC

  • É uma página para aprender e testar SPF, DKIM e DMARC
  • A explicação visual completa de como o DMARC funciona só pode ser vista ao abrir o site no desktop

Itens verificados na tela de resultados

  • Connection parameters

    • Source IP address
    • Hostname
    • Sender

  • SPF

    • Domain
    • Identity
    • Auth Result
    • DMARC Alignment

  • DKIM

    • Domain
    • Selector
    • Algorithm
    • Auth Result
    • DMARC Alignment

  • DMARC

    • RFC5322.From domain
    • Policy(p=)
    • SPF
    • DKIM
    • DMARC Result

Julgamento final e recursos auxiliares

  • A tela de resultados mostra a avaliação geral em Final verdict
  • É possível anonimizar os resultados com Anonymize results
  • É fornecido o link Learn more about DMARC

Leituras relacionadas

1 comentários

 
GN⁺ 2023-10-02
Opiniões do Hacker News

  • É uma boa forma de impulsionar os serviços essenciais de e-mail necessários para reduzir spam. Sempre torci para que, nas empresas com que trabalhei, SPF, DKIM e DMARC por si só fossem motivação suficiente, mas muitas vezes só a reputação não bastava para colocar esse investimento como prioridade
    Felizmente, para empresas que querem se comunicar com os clientes de forma confiável, existe um padrão que os profissionais de marketing provavelmente vão gostar: Brand Indicators for Message Identification (BIMI). Agora você não ganha só segurança, ganha também um logotipo bonito: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    Em várias empresas, usei o BIMI sob a justificativa de “experiência do cliente” para fazê-las implementar DMARC corretamente, ou seja, com P=Reject

    • O DMARC ainda tem problemas. Material de alguns anos atrás: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      Nem SPF nem DKIM resolvem completamente a prevenção de spoofing de e-mail. O SPF autentica os identificadores HELO/MAIL FROM, e o DKIM autentica o campo d= no cabeçalho DKIM-Signature, mas nenhum dos dois autentica o cabeçalho From exibido ao usuário final. Por isso, mesmo passando nas verificações de SPF e DKIM, o endereço From ainda pode ser falsificado
      É claramente um problema um domínio de e-mail não ter DMARC+, mas só DMARC+ também não resolve a questão de “quem é o remetente real”
    • Do ponto de vista de um atacante, fico curioso sobre o que impediria alguém de criar um domínio de phishing usando o mesmo logotipo e configurar BIMI
    • BIMI não custa algo como US$ 1.000 por ano?

  • Material relacionado: veja de forma interativa como DMARC, SPF e DKIM funcionam - https://news.ycombinator.com/item?id=29869266 - janeiro de 2022, 108 comentários

  • Fico curioso se alguém conhece uma forma open source, ou pelo menos gratuita, de processar relatórios DMARC
    Tenho alguns domínios de e-mail com SPF, DKIM e DMARC ativados, e eles funcionam, mas há dois problemas irritantes com DMARC
    (1) Alguns sites enviam relatórios DMARC do tipo “você enviou 3 mensagens, todas estavam corretas e passaram em todas as verificações”
    (2) Às vezes há tentativas de enviar spam usando meu domínio por outros servidores, e recebo relatórios dizendo “alguém colocou seu domínio em HELO/FROM e tentou enviar spam, mas as verificações falharam e a mensagem foi bloqueada”
    Nenhum dos dois é útil para mim. Não quero saber que meu usuário enviou e-mail para @gmail.com ou @mail.ru e, no segundo caso, como não é o IP do meu servidor, não há nada que eu possa fazer
    Descompactar e verificar o XML manualmente é trabalhoso demais, então um filtro ou dashboard seria muito útil

  • A explicação de que “para o DMARC passar, as verificações DKIM e/ou SPF precisam passar e os domínios precisam estar alinhados” está errada, até onde sei
    Não é “and/or”, é or. Basta passar em DKIM ou SPF; não há como exigir ambos

    • Houve um problema recente relacionado a isso na parceria entre Cloudflare e MailChannels, e era possível fazer spoofing de e-mail
      O problema básico era que a MailChannels não exigia autenticação. Cloudflare Workers podia chamar o endpoint de API da MailChannels para enviar e-mails, e a MailChannels exigia adicionar um registro include: à política SPF. Como resultado, a MailChannels se tornava um remetente válido para todos os domínios, permitindo que qualquer pessoa se passasse por qualquer outra
      Entre os 2 milhões de domínios hospedados, apenas cerca de 400 tinham DKIM configurado, mas, mesmo que houvesse DKIM, apenas passar no SPF já fazia o DMARC passar
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • Acho que você interpretou mal a sintaxe. Aqui, and/or significa OR inclusivo. “and” não quer dizer necessariamente que seja uma opção possível
    • Não sei por que estão dando downvote, mas dizer que só or está correto é exato
    • Se você usar um literal de endereço IP sem pagar por um domínio, consegue SPF de graça
      Basta ter um endereço de e-mail com literal de endereço IP nos campos From:/Reply-To: para obter “SPF”, e você ganha uma pontuação muito melhor para evitar greylisting na primeira transação. Melhor ainda se o corpo não tiver URL
      Mas isso é senso comum

  • Gosto muito da forma como o processo permite seguir os passos de maneira iterativa. Alguns anos atrás, quando na empresa anterior tentávamos migrar para envio de e-mail auto-hospedado com medidas de segurança adequadas, algo assim teria ajudado muito

  • Ao enviar um e-mail pelo serviço “Hide My Email” da Apple, ocorreu um erro: https://support.apple.com/en-us/HT210425
    Unhandled Promise Rejection:
    TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)
    dist.min.js:3:32767
    Isso aconteceu depois que a interface começou a exibir “Here are the message headers and message body:” e DKIM-Signature: d=icloud.com s=1a1hai
    Já faz mais de um ano desde que este site foi apresentado no Hacker News, então parece que o código JavaScript ficou antigo e parou de funcionar. Talvez ele nunca tenha dado suporte ao Safari desde o início, ou talvez as duas coisas. Ainda assim, aprendi bastante na primeira e na segunda parte do teste de DMARC, e deu para ter uma ideia do que aconteceria nas etapas seguintes
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • Ao testar e-mails falsificados, o mesmo erro também ocorre no Chrome
      telnet learndmarc.com 25
      Trying 87.239.13.42...
      Connected to learndmarc.com.
      Escape character is '^]'.
      220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000
      HELO there
      250 allspark.uriports.com Hello []
      MAIL From: me@example.com
      250 OK
      RCPT To: ld-49101f55f6@learndmarc.com
      250 Accepted
      DATA
      354 Enter message, ending with "." on a line by itself
      .
      250 OK id=1qn4QF-00CUhd-5j
      Achei engraçado que, enquanto digitava, parecia algo como “não precisa escrever uma carta de amor”. Posso estar enganado, mas parece que, na seção de dados, é preciso repetir os cabeçalhos From: e To:
      Ainda acho engraçado pensar em quantos e-mails enviei ao longo dos anos usando HELO there em vez de um hostname. Também fico curioso sobre qual proporção do tráfego da internet é composta por Enter message, ending with . on a line by itself
    • Quebrou porque o e-mail foi enviado sem o campo from. O programador simplesmente não pensou em testar o caso de um usuário mal-intencionado fazendo coisas maliciosas; não há nenhuma conspiração especial
    • O DMARC depende do endereço RFC5322.From, então ocorre um erro quando esse endereço está ausente. Para evitar esse tipo de erro, atualmente e-mails sem esse endereço estão sendo ignorados

  • É realmente surpreendente que, para manter no século 21 uma tecnologia que fazia sentido há uns 30 anos em um contexto de boa-fé e idealismo, dependamos de camadas e mais camadas de camadas de compatibilidade e hacks
    O mesmo vale para VOIP/telecomunicações
    A Microsoft também teve problemas recentes de entregabilidade de e-mail, e apareceu um aviso na maioria dos nossos tenants O365 pedindo para verificar SPF, DKIM e DMARC. Nós já tínhamos tudo configurado corretamente, mas alguns tenants tiveram problemas ao enviar e-mails para pequenos provedores de e-mail (no nível de ISP). Isso acontecia porque, como havia spam saindo do mesmo endereço IP ou servidor de e-mail, os pequenos provedores estavam bloqueando o IP e faixas inteiras de IP

  • Fato curioso: sns.amazonaws.com ainda não tem um registro DMARC. Se você não usa um domínio customizado, as mensagens do AWS SNS vêm daqui, e todos os alertas do CloudWatch também vêm de no-reply@sns.amazonaws.com

  • O e-mail deveria funcionar assim por padrão, mas, no mundo real, existem listas de permissão

    • E também existem listas de bloqueio. Há listas de bloqueio predatórias, e há listas de bloqueio que são praticamente extorsão organizada
    • Não sei para que seria uma lista de permissão nesse caso. Não é comum definir previamente uma lista de domínios autorizados a enviar para o meu domínio. Fazer isso derruba o propósito do e-mail

  • Também não se deve esquecer de configurar corretamente essas verificações no failover de DNS
    Vi uma empresa ser vítima de fraude usando as configurações padrão do Exchange Online
    Quando o invasor deixou o DNS temporariamente “indisponível”, todos os e-mails de phishing passaram. Isso porque os servidores da MS responderam com temp error de DNS e deixaram todos os e-mails passarem como se não fossem spam
    Mais especificamente, era received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout), e o DKIM era verificado no domínio do servidor SMTP do remetente, que nesse caso era o servidor do invasor usado no phishing
    Depois disso, passei momentos excelentes com o suporte de TI/segurança da MS, mas as pessoas de lá nem entendiam como e-mail funciona. Foi uma experiência muito engraçada e triste ao mesmo tempo, e espero que a terceirização funcione bem para eles