¿Qué es DMARC? La necesidad de la protección del correo electrónico

DMARC es un protocolo que nos brinda la posibilidad de autenticar al emisor del correo electrónico, es decir, garantizar que el correo viene del dominio que indica, por ejemplo, seguridad@empresa.com.

La aparición de DMARC se remonta a 2015 ante la apremiante necesidad de autenticar el remitente, los principales proveedores a nivel mundial desarrollaron de forma conjunta este protocolo, de ahí nace el RFC7489 https://tools.ietf.org/html/rfc7489 documento que define el estandar DMARC.

¿Qué es DMARC?

«Domain-based Message Authentication, Reporting and Conformance» son las siglas en inglés de Autenticación de mensajes basada en dominio informes y conformidad.

Es un protocolo de autenticación de correo electrónico. Permite proteger un determinado dominio de usos no autorizados relacionados con la suplantación del correo electrónico de su organización. Así, gracias a DMARC podrá evitar que sus clientes reciban correos electrónicos de phishing, scam u otras ciberamenazas en su nombre.
DMARC tiene dos principales funciones:

  • Verificar la autenticidad de un correo electrónico. 
  • Impedir que los correos falsos lleguen a su destino.

¿Cómo funciona DMARC?

DMARC se apoya en dos protocolos, SPF (Sender Policy Framework) y DKIM (Domain Keys Identified Mail).

SPF comprueba que el email es enviado desde una direccion IP válida.

En este parámetro debemos recopilar todas las IPs de proveedores, propias y de terceros que queramos permitir que envíen correos en nombre de la entidad, la mayoria de proveedores de correo facilitan esta labor.
Ejemplo de SPF: «v=spf1 include:gmail.com +ip4:10.10.10.1 -all«

EtiquetaDescripción y valores permitidos
vVersión de SPF. Esta etiqueta es obligatoria y tiene que ser la primera del registro. Debe tener este valor:
v=spf1
ip4Autoriza a servidores de correo mediante una dirección o un intervalo de direcciones IPv4. El valor debe ser una dirección o un intervalo de direcciones IPv4 en formato estándar. Por ejemplo:
ip4:192.168.0.1
o
ip4:192.0.2.0/24
ip6Una lista de URI para enviar reportes XML. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc@receptor-del-reporte.com”. Autoriza a servidores de correo mediante una dirección o un intervalo de direcciones IPv6. El valor debe ser una dirección o un intervalo de direcciones IPv6 en formato estándar. Por ejemplo:
ip6:3FFE:0000:0000:0001:0200:F8FF:FE75:50DF
o
ip6:2001:db8:1234::/48 lista de URI para enviar reportes XML. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc@receptor-del-reporte.com”.
aAutoriza a servidores de correo por su nombre de dominio. Por ejemplo:
a:tuproveedor.com
mxAutoriza a uno o varios servidores de correo por el registro MX del dominio. Por ejemplo:
mx:mail.solarmora.com
Si no incluyes este mecanismo en tu registro SPF, el valor predeterminado son los registros MX del dominio en el que se usa el registro SPF.
includeAutoriza a remitentes de correo externos por su dominio. Por ejemplo:
include:servers.mail.net
allIndica que todos los mensajes entrantes coinciden. Te recomendamos que siempre incluyas este mecanismo en tu registro SPF.
Tiene que ser el último mecanismo del registro SPF. Todos los mecanismos que haya después de all se ignorarán.
¿Debo usar ~all o -all?
Cuando un registro SPF incluye ~all (calificador de que se supera la autenticación con reservas), los servidores que reciben correo suelen aceptar los mensajes de remitentes que no figuran en el registro SPF, pero los marcan como sospechosos.
Cuando un registro SPF incluye -all (calificador de fallo), puede que los servidores que reciben correo rechacen los mensajes de remitentes que no figuren en el registro SPF. Si tu registro SPF no está bien configurado y usas el calificador de fallo, puede que se marquen como spam más mensajes de tu dominio.
Para evitar el spoofing de dominios que no envían correo, usa este registro SPF en el dominio: vspf1 ~all

Ejemplo de configuración DMARC en el DNS:

DKIM verifica que el correo está firmado digitalmente por el dominio original.

Para este parametro debemos generar una clave DKIM, nuestro proveedor de correo nos facilitará esta información que debemos reflejar en el DNS.

ejemplo de DKIM: v=DKIM1;k=rsa;t=s;s=email;p=XXXXXXXXXXXXXXXXXX

Impacto

Tengamos en cuenta que en caso de que tu organización no implemente DMARC o no esté correctamente implementado un atacante podría enviar un email suplantando la identidad de un compañero de trabajo solicitando acceso a algún servicio interno por ejemplo. No se queda solo ahí, un atacante podría solicitar cobrar una factura desde un correo aparentemente legitimo de un proveedor a suplantar y conseguir no solo información confidencial sino incluso lograr que se realicen transferencias a la cuenta del atacante mientras la victima piensa que está pagando una factura legítima al proveedor.

Si nuestra entidad tiene correctamente alineado DMARC, automáticamente estos correos maliciosos serían bloqueados o llevados a spam.
Estos ataques son mucho más comunes de lo que parece dentro del sector empresarial e implementar DMARC correctamente evitaría la mayoria de ellos

Esto también puede suceder fuera de entorno laboral, suplantando el atacante a páginas de venta bancos, falsas promociones, y una larga lista de eventos conocidos.

¿Que parámetros tiene en cuenta la configuración de DMARC?

La configuración se define mediante etiquetas, estas son:

EtiquetaDescripción y valores permitidos
vVersión del protocolo DMARC (actualmente DMARC1).
pPolítica para aplicar al correo electrónico que falla la verificación de DMARC. Puede ser “none”, “quarantine” o “reject”. “none” se utiliza para recopilar los reportes de DMARC y obtener información sobre el alineamiento y configuración de proveedores de correo.
ruaUna lista de URI para enviar reportes XML. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc@receptor-del-reporte.com”.
rufUna lista de URI para enviar informes forenses. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc-forense@receptor-del-reporte.com”.
rfEl formato de reporte para informes forenses. Esto puede ser “afrf” (Authentication Failure Reporting Formats) o “iodef” (Incident Object Description Exchange Format ).
pctLa etiqueta de porcentaje indica que solo apliquen la política de DMARC a un porcentaje de los correo electrónico fallidos. “pct=50” indicará a los receptores apliquen solo la política al 50% de los correos electrónicos que no superen la verificación DMARC. La etiqueta pct se diseñó como una forma de aplicar gradualmente las políticas DMARC para acortar el período de implementación para las empresas en línea. 
adkimEl modo de alineación adkim se refiere a la precisión con la que se comparan los registros del remitente con las firmas DKIM, con dos posibles valores:
«r» (relajado) permite coincidencias parciales, como subdominios de un dominio dado.
«s» (estricto) requiere una coincidencia exacta.
aspfEl modo de alineación aspf se refiere a la precisión con la que se comparan los registros del remitente con las firmas SPF, con dos posibles valores:
«r» (relajado) permite coincidencias parciales, como subdominios de un dominio dado.
«s» (estricto) requiere una coincidencia exacta.
spEsta política se debe aplicar a los correos electrónicos de un subdominio que no pasan la verificación de DMARC. Al usar esta etiqueta, los propietarios del dominio pueden publicar una política de comodín para todos los subdominios.
foOpciones forenses Valores permitidos: “0” para generar informes si tanto DKIM como SPF fallan, “1” para generar informes si DKIM o SPF fallan, por último “d” y «s» para generar un informe si DKIM(d) ha fallado o si SPF(s) falló. Este campo puede tener múltiples opciones combinadas.
riEl intervalo de informe de la frecuencia con la que desea recibir informes XML agregados. Esta es una preferencia y los proveedores comúnmente enviar el informe en diferentes intervalos ignorando esta preferencia.

Ejemplo de configuración DMARC en el DNS:

v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:analizador-dmarc@receptor-del-reporte.com,mailto:analizador-dmarc@otro-receptor-del-reporte-diferente.com; ruf=mailto:analizador-dmarc@receptor-del-reporte.com,mailto:analizador-dmarc@otro-receptor-del-reporte-diferente.com; pct=100; fo=1;

Esta configuración como hemos visto define:

  • Versión: DMARC1
  • Política: Cuarentena
  • Alineamiento dkim: estricto
  • Alineamiento spf: estricto
  • Porcentaje: 100%
  • Opciones forenses si DKIM o SPF fallan

Ejemplo de reporte

Los reportes vienen en formato XML. Saber léerlos es importante para comprender mejor el flujo de correo. Los informes ayudan a los administradores a tomar medidas rápidamente cuando detectan un proveedor de correo legitimo mal configurado, que ha añadido nuevas IPs y no están reflejadas en el SPF o que no tiene correctamente configurado dkim. Aquí hay un extracto de un informe inventado que muestra los resultados de los mensajes enviados desde un par de direcciones IP, uno enviado directamente y el otro reenviado. Ambos mensajes pasaron la validación.

<record>
    <row>
        <source_ip>192.168.1.101</source_ip>
        <count>1</count>
        <policy_evaluated>
            <disposition>none</disposition>
        </policy_evaluated>
    </row>
    <identities>
        <header_from>tudominio.com</header_from>
    </identities>
    <auth_results>
        <dkim>
            <domain>tudominio.com</domain>
            <result>pass</result>
            <human_result></human_result>
        </dkim>
        <spf>
            <domain>tudominio.com</domain>
            <result>pass</result>
        </spf>
    </auth_results>
</record>
<record>
<row>
    <source_ip>192.168.1.102</source_ip>
    <count>1</count>
    <policy_evaluated>
        <disposition>none</disposition>
        <reason>
            <type>forwarded</type>
            <comment></comment>
        </reason>
    </policy_evaluated>
</row>
<identities>
    <header_from>tudominio.com</header_from>
</identities>
<auth_results>
    <dkim>
        <domain>tudominio.com</domain>
        <result>pass</result>
        <human_result></human_result>
    </dkim>
    <spf>
        <domain>tudominio.com</domain>
        <result>pass</result>
    </spf>
</auth_results>
</record>

Recomendaciones

Despliegue lento, no pasar de politica none a reject sin pasar el suficiente tiempo en quarantine, aplicar a un porcentaje de correos pequeños la validación e ir aumentando lentamente en funcion de los datos obtenidos en los reportes. Depende del número de proveedores y del volumen de correos las velocidades pueden ser muy diferente.

Tratándolo de la forma más genérica los pasos los podriamos resumir en:

Aplicamos Política Nada para analizar durante al menos dos meses el alineamiento, en función de los datos obtenidos, si son favorables, avanzamos a política Cuarentena al 5%, si los resultados son favorables avanzamos el porcentaje lentamente hasta el 100%, si queremos ir un paso más allá, aplicaremos la política Rechazar al 5% y vuelta a empezar con la subida del porcentaje paulatinamente.
Si los datos no son favorables, debemos analizar que IPs no están alineadas con el SPF y de que proveedor son, revisar que porcentajes de correos están pasando SPF, cuantos DKIM y cuantos DMARC.

Más información:

Fuente: UnaAlDia

Comentarios

Publicar un comentario

Entradas populares de este blog

Presuntos narcotraficantes liberados por un ransomware

Imagen
Los fiscales estadounidenses se vieron obligados a dejar caer 11 casos de narcotráfico contra seis presuntos delincuentes, después de que se perdieron archivos de casos cruciales en una infección de ransomware en un departamento de policía de Florida. Es al menos séptimo incidente conocido de este tipo: investigaciones policiales se ven afectadas por una infección de ransomware que elimina la evidencia de las fuerzas del orden. La evidencia en los 11 casos no se pudo recuperar después de un ataque de ransomware que golpeó al departamento de policía de Stuart en abril de 2019. Si bien la policía de Stuart recuperó algunos datos de las copias de seguridad, algunos archivos no se pudieron recuperar. Los archivos perdidos incluyeron evidencia en fotos y videos , dijo el sargento detective Mike Gerwan del Departamento de Policía de Stuart a WPTV en una entrevista la semana pasada. Gerwan dijo que los casos retirados incluyen cargos por posesión de metanfetamina, posesión de
Leer más

Metasploit y Windows 10: Creando un payload indetectable (Evadiendo software antivirus)

Imagen
Anteriormente escribimos un artículo donde mostramos la manera de acceder a un sistema operativo Windows 10 usando metasploit de manera local o remotamente, puedes leer el artículo aquí:  Accediendo remotamente a Windows 10 con Metasploit . Hoy les vamos a mostrar cómo ofuscar el código malicioso para que sea indetectable a los antivirus. Los entusiastas de seguridad siempre buscan exploits de día cero que pueden eludir con éxito las características de seguridad de sistemas cómo Windows 10. Se han llevado a cabo numerosas investigaciones para crear malware indetectable y proyectos completos de GitHub dedicados a automatizar la creación de payloads indetectables como WinPayloads , Veil v3 y TheFatRat . Todo lo que se explicará en esta guía se hace con fines explícitamente educativos y bajo un laboratorio propiedad de Security Hack Labs , los usos que se le puedan dar a este tutorial depende del usuario y es absolutamente responsabilidad del él los daños que
Leer más

Diferencias entre mapa de calor, mapa de riesgos y matriz de riesgos

Imagen
4.5 / 5 ( 6 votos ) El mapa de riesgos, el mapa de calor y la matriz de riesgos son herramientas útiles en Risk Management. Si bien, en ocasiones los profesionales en Risk Management confunden estos conceptos y lo tratan como si fueran una única herramienta. En este artículo vamos a aclarar las principales diferencias y similitudes entre mapa de calor y matriz de riesgos, así como con mapa de riesgos. ¿Qué son los mapas de riesgos? Un mapa de riesgos es una tabla de 2×2, normalmente una tabla cruzada, que se organiza en columnas. En la primera se colocan los posibles eventos que pueden aportar incertidumbre al objetivo de la empresa u organización. Y, en las siguientes columnas, se colocarán las probabilidades, consecuencias o variables que puedan explicar dichos eventos. Por lo tanto, esta tabla viene a considerarse un mapa de riesgos.
Leer más