Aprender y probar DMARC

 (learndmarc.com)
2 puntos por GN⁺ 2023-10-02 | 1 comentarios | Compartir por WhatsApp
  • LearnDMARC permite aprender y probar SPF, DKIM y DMARC, elementos clave de la autenticación de correo, en una sola pantalla; la explicación visual completa está disponible en escritorio
  • La pantalla de resultados muestra primero información de conexión como Source IP address, Hostname y Sender, para identificar el punto de partida de la decisión de autenticación
  • SPF y DKIM muestran, cada uno, el dominio sujeto a autenticación y el resultado, y también revelan si existe Alignment, necesario para la evaluación de DMARC
  • La sección de DMARC combina RFC5322.From domain, Policy(p=), los resultados de SPF y DKIM, y los conecta con el DMARC Result final
  • Al final se puede ver la evaluación general mediante Final verdict, y también se ofrecen anonimización de resultados y un enlace para aprender sobre DMARC

Propósito de LearnDMARC

  • Es una página para aprender y probar SPF, DKIM y DMARC
  • Para ver la explicación visual completa de cómo funciona DMARC, hay que abrir el sitio en escritorio

Elementos que se revisan en la pantalla 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

Veredicto final y funciones auxiliares

  • La pantalla de resultados muestra la evaluación general con Final verdict
  • Se pueden anonimizar los resultados con Anonymize results
  • Se ofrece el enlace Learn more about DMARC

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-02
Opiniones de Hacker News

  • Es una buena forma de impulsar servicios de correo esenciales para reducir el spam. Siempre esperé que SPF, DKIM y DMARC por sí solos fueran motivación suficiente para las empresas con las que trabajé, pero muchas veces la reputación por sí sola no alcanza para priorizar la inversión.
    Por suerte, para las empresas que quieren comunicarse con sus clientes de forma confiable existe un estándar que a los marketers les puede gustar: Brand Indicators for Message Identification(BIMI). Ahora no solo obtienes seguridad, sino también un logo bonito: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    En varias empresas he usado BIMI con el argumento de la “experiencia del cliente” para hacer que implementen DMARC correctamente, es decir, con P=Reject.

    • DMARC todavía tiene problemas. Material de hace unos años: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      Ni SPF ni DKIM resuelven por completo la prevención de spoofing de correo. SPF autentica los identificadores HELO/MAIL FROM y DKIM autentica el campo d= del encabezado DKIM-Signature, pero ninguno autentica el encabezado From que se muestra al usuario final. Por eso, aunque se pasen las verificaciones de SPF y DKIM, la dirección From todavía puede falsificarse.
      Que un dominio de correo no tenga DMARC+ es claramente un problema, pero DMARC+ por sí solo tampoco resuelve el problema de “¿es realmente el remitente?”.
    • Desde el punto de vista de un atacante, me pregunto qué impide crear un dominio de phishing que use el mismo logo y configurarle BIMI.
    • ¿BIMI no cuesta alrededor de 1000 dólares al año?

  • Material relacionado: ver de forma interactiva cómo funcionan DMARC, SPF y DKIM - https://news.ycombinator.com/item?id=29869266 - enero de 2022, 108 comentarios

  • Me pregunto si alguien conoce alguna forma open source, o al menos gratuita, de procesar reportes DMARC.
    Tengo algunos dominios de correo con SPF, DKIM y DMARC activados, y funcionan, pero DMARC tiene dos molestias:
    (1) Algunos sitios envían reportes DMARC del tipo “enviaste 3 mensajes, todos están bien y pasaron todas las verificaciones”.
    (2) De vez en cuando hay intentos de enviar spam con mi dominio a través de otros servidores, y recibo reportes que dicen “alguien intentó hacer spam poniendo tu dominio en HELO/FROM, pero las verificaciones fallaron y fue bloqueado”.
    Ninguna de las dos cosas me sirve. No quiero saber que mi usuario envió un correo a @gmail.com o @mail.ru, y en el segundo caso tampoco puedo hacer nada porque no es la IP de mi servidor.
    Descomprimir y revisar el XML a mano es demasiado engorroso, así que un filtro o dashboard sería muy útil.

  • Según tengo entendido, la explicación de que “para que DMARC pase, las verificaciones DKIM y/o SPF deben pasar y los dominios deben estar alineados” es incorrecta.
    No es “and/or”, sino or. Basta con que pase DKIM o SPF; no hay forma de exigir ambos.

    • En relación con esto, hubo un problema reciente con la alianza entre Cloudflare y MailChannels, y era posible hacer spoofing de correo.
      El problema de fondo era que MailChannels no exigía autenticación. Cloudflare Workers podía llamar al endpoint de API de MailChannels para enviar correos, y MailChannels pedía agregar un registro include: a la política SPF. Como resultado, MailChannels se convertía en un remitente válido para todos los dominios, y cualquiera podía hacerse pasar por cualquiera.
      Entre los 2 millones de dominios alojados, solo unos 400 tenían DKIM configurado, pero aun si hubiera DKIM, con solo pasar SPF DMARC pasaba.
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • Creo que se está interpretando mal la sintaxis. Aquí entiendo que and/or significa OR inclusivo. La “and” no necesariamente implica que sea una opción posible.
    • No sé por qué le dan downvote, pero la afirmación de que solo or es correcto es precisa.
    • Si usas un literal de dirección IP sin pagar por un dominio, puedes obtener SPF gratis.
      Con solo tener una dirección de correo con un literal de IP en los campos From:/Reply-To:, obtienes “SPF” y una puntuación mucho mejor para evitar el greylisting en la primera transacción. Mejor aún si no hay URL en el cuerpo.
      Pero esto es sentido común.

  • Me gusta mucho la forma en que te hace seguir el proceso de manera iterativa. Hace unos años, cuando en mi empresa anterior intentábamos pasar a envíos de correo autohosteados con medidas de seguridad adecuadas, algo así habría sido de gran ayuda.

  • Envié un correo con el servicio “Hide My Email” de Apple y apareció un error: 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
    Ocurrió después de que la interfaz empezó a mostrar “Here are the message headers and message body:” y DKIM-Signature: d=icloud.com s=1a1hai
    Como ya pasó más de un año desde que este sitio web apareció en Hacker News, parece que el código JavaScript quedó viejo y dejó de funcionar. Puede que desde el principio no soportara Safari, o ambas cosas. Aun así, aprendí mucho en la primera y segunda parte de la prueba de DMARC, y pude hacerme una idea de lo que ocurriría en las etapas posteriores
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • Al probar un correo falsificado, aparece el mismo error también en 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
      Me dio risa que, mientras escribía, parecía decir “tampoco hace falta escribir una carta de amor”. Puede que no sea así, pero parece que en la sección de datos hay que repetir los encabezados From: y To:
      Todavía me causa gracia pensar cuántos correos envié durante años con HELO there en lugar del nombre de host. También me pregunto qué proporción del tráfico de Internet corresponderá a Enter message, ending with . on a line by itself
    • Se rompió porque enviaron un correo sin el campo from. El programador simplemente no pensó en probar el caso en que un usuario malicioso hace cosas malas; no hay ninguna conspiración especial
    • DMARC depende de la dirección RFC5322.From, así que si falta esa dirección se produce un error. Para evitar este tipo de errores, ahora se ignoran los correos que no tienen esa dirección

  • Es realmente sorprendente que en pleno siglo XXI dependamos de capas y capas de compatibilidad y hacks para seguir usando una tecnología que hace unos 30 años encajaba con la buena fe y los ideales
    Lo mismo pasa con VOIP/telecomunicaciones
    Microsoft también tuvo recientemente problemas de entregabilidad de correo, y en la mayoría de nuestros tenants de O365 apareció una alerta para revisar SPF, DKIM y DMARC. Nosotros ya lo teníamos bien configurado, pero algunos tenants tenían problemas al enviar correo a proveedores pequeños (a nivel ISP). Era porque, como salía spam desde la misma dirección IP o el mismo servidor de correo, esos proveedores pequeños estaban bloqueando direcciones IP y rangos de IP completos

  • Dato curioso: sns.amazonaws.com todavía no tiene registro DMARC. Si no usas un dominio personalizado, los mensajes de AWS SNS vienen de ahí, y todas las alertas de CloudWatch también llegan desde no-reply@sns.amazonaws.com

  • El correo electrónico debería funcionar así por diseño, pero en la realidad existen listas de permitidos

    • Y también listas de bloqueo. Algunas son depredadoras, y otras equivalen prácticamente a extorsión organizada
    • No sé listas de permitidos para qué. No es común definir de antemano una lista de dominios autorizados a enviar a mi dominio. Si haces eso, se rompe el propósito del correo electrónico

  • Tampoco hay que olvidar configurar correctamente estas verificaciones en la conmutación por error de DNS
    Vi a una empresa ser estafada por usar la configuración predeterminada de Exchange Online
    El atacante hizo que el DNS quedara “no disponible” por un momento y todos los correos de phishing pasaron. Fue porque los servidores de MS respondieron con un temp error de DNS y dejaron pasar todos los correos como si no fueran spam
    En detalle, fue received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout), y DKIM se verifica contra el dominio del servidor SMTP del remitente, que en este caso era el servidor del atacante usado para el phishing
    Después pasé un rato excelente con soporte de TI/seguridad de MS, donde ni siquiera entendían cómo funciona el correo electrónico. Fue una experiencia muy graciosa y triste a la vez; espero que la tercerización les funcione bien