DMARC: Domain-based Message Authentication, Reporting & Conformance

Cuando se recibe un correo electrónico que no viene firmado digitalmente, siempre es complicado para el destinatario saber si es auténtico o no. Si todos los mensajes llegaran firmados con PGP o S/MIME y las herramientas que utilizamos habitualmente fueran sencillas a la hora de utilizar estas tecnologías no habría que buscar otras alternativas. Por desgracia esto no es así y se han buscado soluciones como SPF (Sender Policy Framework) / SenderID o DKIM (DomainKeys Identified Mail) para paliar esta solución. Pero la situación es aún un poco confusa ya que las configuraciones que hacen muchos dominios de ellos no son correctas y las limitaciones que tienen las tecnologías SPF/SenderID o DKIM hacen que los proveedores de correo electrónico no se atrevan a confiar ciegamente en ellos.

Figura 1: DMARC - Domain-based Message Authentication, Reporting & Conformance

Esta situación ha llevado a que grandes proveedores como Gmail han llegado a obviar completamente SPF o que la firma DKIM de un mensaje de correo electrónico no genere ninguna alerta positiva de verificación en Hotmail, a diferencia de lo que ocurre, por ejemplo, en Gmail con las cuentas de Ebay o Paypal.

Figura 2: Icono de llave en mensajes de Ebay firmados con DKIM

Viendo este ecosistema hacía falta una solución de análisis de los mensajes de correo electrónico que verifique todos los patrones para poder determinar si un mensaje es correcto o no, evaluando las firmas SPF/SenderID y DKIM y tomando una decisión en función de las configuraciones globales. Nosotros en Informática64, tiempo atrás, creamos un plugin para el navegador que hacía estas verificaciones y lo llamamos el Proyecto Apolo. Con él, analizando SPF y la configuración del dominio que lo enviaba, mostrábamos un icono al lado de cada mensaje de correo electrónico en Gmail.

Figura 3: El plugin del Proyecto Apolo mostraba información con las validaciones SPF

En aquel proyecto nosotros no analizábamos DKIM y basábamos todo nuestro trabajo en las configuraciones de SPF y SenderID. Con esta misma idea, hace ya unos años se comenzó a trabajar en un estándar que siguiera las mismas ideas que nuestro proyecto Apolo, pero usando ahora SPF/SenderID y DKIM en la lógica de la validación. Este estándar se llama DMARC: "Domain-Based Message Authentication, Reporting & Conformance" y tiene, además de la validación, la posibilidad de establecer un sistema de reporte para enviar información de los correos que están incumpliendo las políticas y una forma de forzar que las políticas se cumplan en todos los posibles subdominios de una organización.

DMARC: Domain-based Authentication, Reporting & Conformance

El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 4: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -.

En el caso de Hotmail u Outlook.com, los mensajes de algunas grandes compañías que han implantado DMARC y cumplen DKIM y SPF correctamente, reciben un escudo verde en el cliente web, similar a la llave que pone Gmail a los mensajes de Ebay o Paypal que vienen firmados por DKIM. En el caso de DMARC, las verificaciones son SPF y DKIM, por lo que son mucho más estrictas. 

Figura 5: mensajes en Outlook.com de Apple

En la imagen podéis ver cuatro mensajes de correo electrónico provenientes de Apple.com. Los cuatro pasan la política SPF y los cuatro vienen firmados correctamente por DKIM, pero Hotmail/Outlook.com ha puesto el escudo verde solo en uno de ellos porque es lo que han decidido hacer por acuerdo, no porque unos tengan más medidas de seguridad que otros. 

Verificando un política DMARC

Vamos a ver con el cuarto mensaje cómo se comprueban todas las comprobaciones con DMARC para que al final Outlook.com ponga el escudo verde al mensaje de correo. Si miramos el código fuente del mensaje, podemos ver que el dominio del remitente es id.apple.com. Este es el dominio que se ha elegido para verificar los mensajes de correo electrónico que lleguen y ponerle el escudo verde. Todos los mensajes que lleguen de ese dominio serán validados por DMARC a ver si son merecedores del escudo verde o no.

a) Paso 1: Verificación SPF

Primero tenemos que comprobar el registro SPF en el servidor DNS para ver qué direcciones IP son las autorizadas por id.apple.com para enviar mensajes de correo electrónico con su dominio. Como se puede ver la lista está compuesta por 6 segmentos de direcciones IP. Además, la política que se ha elegido para el protocolo de Sender Policy Framework - ya que es un registro spfv1 - es de softfail.  

Figura 6: Configuración SPF de id.apple.com

Si miramos el código fuente del mensaje de correo electrónico podemos observar que ha sido entregado desde un servidor con la dirección 17.151.1.33, que pertenece a uno de los rangos marcados en el registro SPF. 

Figura 7: Verificación de SPF en el correo electrónico recibido 

Por tanto, como se marca en el código fuente del mensaje, aparece como que el correo electrónico ha pasado correctamente la validación SPF.

b) Paso 2: Verificación DKIM

Si miramos el código fuente de mensaje enviado desde id.apple.com, podemos ver cómo viene firmado digitalmente por el servidor que envía el mensaje usando una clave llamada id2048 que el servidor de correo entrante debe poder obtener en el servidor DNS de id.apple.com. 

Figura 8: Firma DKIM del mensaje de id.apple.com

Si nos conectamos al servidor DNS de id.apple.com y buscamos el registro que debe contener la clave, es decir, id2048._domainkeys.apple.com, podemos ver cuál es el valor de la parte pública de esta clave.  

Figura 9: Clave pública id2048 en el DNS de id.apple.com

Además, la política DKIM para Apple.com está configurada con un softfail (o=~) también. En este caso, aún la mantiene en modo test (t=y). 

Figura 10: política DKIM de Apple.com

Para este correo en concreto no hay ningún problema porque el servidor de correo electrónico entrante, es decir, Outlook.com, se ha conectado al servidor DNS, ha recogido la clave pública de id2048 y ha verificado que el mensaje de correo electrónico está correctamente firmado.

c) Paso 3: Política DMARC

Llegados a este punto, debemos revisar la política DMARC de id.apple.com. Esta se encuentra en el registro DNS llamado _dmarc.id.apple.com y tiene una configuración bastante sencilla en la que indica cuáles son las direcciones de correo electrónico a las que se debe enviar información de los correos que no cumplan las políticas SPF y DKIM anteriores. 

Figura 11: Configuración del registro DMARC de id.apple.com

La configuración del registro DMARC en el servidor DNS se hace con un registro TXT en el que hay que configurar una serie de valores. En primer lugar la versión, que a día de hoy es DMARC1, luego las direcciones de e-mail en las que se quiere reportar aquellos mensajes que incumplan las políticas para hacer un análisis forense y en las que se van a enviar los reportes agregados con estadísticas.

Figura 12: Valores de configuración de registro DMARC

Luego, se configuran valores como la política a aplicar, que en el caso de id.apple.com es la de rechazar cualquier correo electrónico que no cumpla con la política SPF y la política DKIM. 

Políticas para subdominos y alineamiento con DKIM & SPF

Una de las cosas interesantes del protocolo DMARC es que tiene en cuenta los ataques que realizan los suplantadores de identidad inventando subdominios con sp. En este caso, muchos servidores de correo electrónico no verifican que los registros SPF de los dominios padres prohiben el envío de mensajes desde una determinada dirección IP y buscan ser entregados al buzón de la víctima como si el subdominio no tuviera configurado el registro SPF. Además, tiene configuraciones para que la política que se aplique sea la configurada en DKIM o SPF, con los valores de alineamiento (adkim & aspf).

DMARC es un paso más para intentar evitar la suplantación de direcciones de remitente en mensajes de correo electrónico que, si es posible, merece la pena que configures en tu organización.

Saludos Malignos!