SenderID, SPF, DKIM y DMARC en Exchange 2016 – Parte II

En la publicación de blog anterior, analicé cómo funciona SPF y cómo utiliza DNS público para validar la autenticidad de los servidores SMTP de envío. Cuando SPF se implementa correctamente, un servidor de correo receptor puede validar si el servidor de correo emisor tiene permiso para enviar correo electrónico en nombre del remitente o de su organización.

En esta entrada de blog, analizaré la firma DKIM como un paso adicional (y más complicado y más difícil de falsificar) en la validación del correo electrónico.

Como recordatorio rápido, así es como se ve el entorno de mi laboratorio:

Hay un servidor de buzones de correo CU2 de Exchange 2016 que aloja varios buzones de correo y hay un servidor de transporte perimetral CU2 de Exchange 2016. Una sincronización perimetral garantizará que todo el tráfico SMTP entrante y saliente sea manejado por el servidor de transporte perimetral.

En mi publicación de blog anterior se creó e implementó un registro SPF con el siguiente valor:

v=spf1 a:smtphost.exchangelabs.nl ~todos

por lo tanto, los servidores de correo receptores pueden validar que mi servidor de transporte perimetral tiene permiso para enviar correo electrónico en mi nombre, y cuando el correo se origina en otro servidor de correo, bien podría ser un mensaje falsificado.

Pero de momento sigamos con DKIM.

Claves de dominio Correo identificado

DKIM, que significa Domain Keys Identified Mail, es otra solución. No es una verdadera solución antispam, sino más bien una solución de validación legítima. Y cuando se valida un mensaje de correo electrónico, lo más probable es que no sea spam (es decir, siempre y cuando el entorno del remitente no esté comprometido o, por supuesto).

DKIM tiene que ver con firmar y verificar mensajes de correo electrónico. Como tal, puede compararlo con las capacidades de firma de S/MIME, donde S/MIME está basado en el cliente y DKIM está basado en el servidor.

DKIM consta de dos operaciones:

• Firma del mensaje. Esto lo puede lograr el propio host de envío o puede hacerlo mediante una aplicación o servicio de terceros. Al firmar un mensaje, el módulo de firma inserta un encabezado DKIM-Signature en el mensaje con la información adecuada. Este módulo de firma utiliza una clave privada para crear una firma, garantizando así que solo este servidor (u organización) pueda firmar mensajes.
• Verificación del mensaje. Al igual que la firma, esto lo puede realizar el host receptor o una aplicación o servicio de terceros. El módulo de verificación lee la información en el campo DKM-Signature y verifica la firma utilizando la clave pública de la organización de envío.

La clave pública y privada forman un par de claves. La clave privada sólo se conoce en los servidores de correo emisor, la clave pública se publica en el servidor DNS público del remitente y, como tal, está disponible para todos los que necesiten validar el mensaje firmado.

Entonces, el encabezado DKIM-Signature juega un papel importante en DKIM, y un encabezado DKM-Signature típico puede verse así:

Firma DKIM: v=1; a=rsa-sha256; d=ejemplo.net; s=brisbane;
c=relajado/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;
h=de:a:asunto:fecha:palabras clave:palabras clave;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR

Las siguientes etiquetas se pueden identificar en un encabezado de firma DKIM:

• v=versión
• a=algoritmo de firma
• d=Dominio
• s=Selector
• c=Algoritmo de canonicalización para cuerpo y encabezado
• q=método de consulta
• l=longitud de la parte del cuerpo de canonicalización
• t=firma de marca de tiempo
• x=tiempo de vencimiento
• h=lista de campos de encabezado firmados
• b=hash de los encabezados de los mensajes seleccionados
• bh=hash del cuerpo del mensaje

Para firmar un mensaje, el módulo de firma primero crea un hash del cuerpo del mensaje, almacenado con la etiqueta bh. Lo siguiente es que los encabezados seleccionados en el mensaje están codificados, estos se almacenan en la etiqueta b. Entonces, se están creando dos hashes. Ambos hashes se almacenan en el encabezado DKIM del mensaje. Ambos son claramente visibles en el ejemplo anterior del encabezado de firma DKIM.

Para firmar un mensaje, necesita un par de claves. El servidor de correo utiliza la clave privada para firmar el mensaje, la clave pública se almacena en DNS y el servidor receptor puede recuperarla para descifrar la firma. ¿Cómo se obtiene un par de claves?

Puede utilizar el sitio http://dkimcore.org para generar un par de claves. Esto debe usarse solo con fines de prueba, ya que el par de claves se genera y almacena (bueno, tal vez temporalmente) en este sitio web.

La clave privada generada debe ingresarse en el módulo de firma en el servidor de correo de envío, esto se parece a esto:

—-COMENZAR LA CLAVE PRIVADA RSA—-
MIICXAIBAAKBgQCy9cx399ZJ3xhCDcVmHOFkFWw5XAuWls0npBNO1hiMeUr0qI/c
+Abmjma2O/VB5oCPGHzRT3f78BlGryJKjEAyZKBE7U+GkaCGEVEjQqGEWnsF7tql
OkWW99Lx1VOEJItO9yMrRpmA6Ml01jH6rkBeADhUpgKAUD0fN+ZCnlVv1QIDAQAB
AoGAa4BLuyUdjHJ/V+59zcE7g6t6v1oTe/pKcq2VC56AUKHr7Nv0z4AOZSDVglKy
GUwlnc/P6swZ/zVTeapqpu1pAdtPiglf70GMDPA1YUqxaKXnH/jZz8g7o5L2F1pw
6CZoPDzXnCx0BAFuAyByonOIolFf9iPnMkm809d9La/Y0wECQQDZxkgPeRbHmySW
USfq19vqH5Kz3YYjW+E/rMXMBE9qtfYaiQJBAJ+sVmGh8yXfhu/iAcYZi/R9Y/ug
Tu6mky+8HzIhc8kG1G8c4Xo4Y3Oj/RyG/00iB5JgIkZgaMjaPN9pCwBkdfECQBjd
UWgNymikJWe9PmZviQ6VtH3Eyw3dk2+fo5odTZ/wA0tdetXBf2poL2eoBHoK2tt5
+T/o1Z/UGRMBV/l9xxECQEyUnkqkX+2YEkxotCyVKt+whxdshZFAoPqGzIyN4Spq
w4j2w3xiPYSzpyXDx+6Dgpyb/Ru8MhNhakNRYIMjK64=
—-FIN DE CLAVE PRIVADA RSA—-

La clave pública generada (en formato DNS BIND 9) se parece a esto:

1471253148.exchangelabs._domainkey.exchangelabs.nl. EN TXT (

“v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmutszXoY6C8/xlzy/Hrz954Gy”
“5zf0O8q/+brIO9o
+WyYeoMkNjs2NEy9z20Ur7t1lP64KH7dx/BKK6hlwRKxTw70D”
“MU5HC5ZJtvLYuiiUz3KGuEMDSwsBpY4aAtDhVG7CjYheSoIQ5kD2EcvnZJaQTPTa”
“tKLxEwImU2tYwPmqyQIDAQAB”)

El selector en este ejemplo es "1471253148.exchangelabs" y el selector es el registro DNS donde se almacena la clave pública.

Nota. En este ejemplo, la clave pública real (codificada en Base64) es
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmutszXoY6C8/xlzy/Hrz954Gy5zf0O8q/+brIO9o+WyYeoMkNjs2NEy9z20Ur7t1lP 64KH7dx/BKK6hlwRK xTw70D MU5HC5ZJtvLYuiiUz3KGuEMDSwsBpY4aAtDhVG7CjYheSoIQ5kD2EcvnZJaQTPTatKLxEwImU2tYwPmqyQIDAQAB

Una vez agregado al DNS, puede usar el sitio http://dkimcore.org/tools para probar la clave pública DKIM Core. Puede ingresar el selector y el nombre de dominio, o puede ingresar el registro que se encontró en el paso anterior. Supongo que ingresar el selector y el nombre de dominio tiene más sentido:

Haga clic en Verificar para verificar los registros DKIM en DNS y verá algo como esto:

También puedes usar el sitio http://mxtoolbox.com/dkim.aspx para probar tu registro DKIM, simplemente ingresa el nombre de dominio y el selector:

Nota. Puede utilizar el par de claves creado por DKIMCORE.ORG con fines de prueba y, si elimina el par de claves de este sitio, también debería poder utilizarlo en producción. Sin embargo, esto puede suponer un riesgo para la seguridad. Dado que el par de claves se creó en Internet, nunca se sabe qué sucede con el par de claves. Una mejor solución es generar un par de claves utilizando una herramienta como OPENSSL o PUTTYGEN.

Entonces, en este punto todo está en su lugar. Hay una clave privada para firmar mensajes, hay una clave pública almacenada en DNS y ya está listo. Los mensajes se envían a su servidor (de envío), el servidor receptor leerá el encabezado del mensaje y, según la clave selectora, el servidor puede recuperar la clave pública para validar la firma.

Servidor Exchange y DKIM

Aunque hay una cosa más importante…. Es posible que hayas notado que no he usado el nombre "servidor Exchange" en la sección anterior, y eso se debe a que Exchange no admite la firma y verificación DKIM de forma inmediata. Necesitas usar un tercer software para esto, pero en GitHub también puedes descargar algún software de firma DKIM.

Cuando se descarga, extrae e instala (en Exchange 2016 Edge Transport Server), puede configurar el módulo de firma DKIM (que es básicamente una regla de transporte). La pestaña más importante es Configuración de dominio, donde puede configurar ajustes específicos del dominio:

Cuando se envía un mensaje, el firmante DKIM procesará el mensaje, lo firmará y agregará el encabezado de información DKIM. Envíe un mensaje de correo electrónico a otro buzón externo (usé un buzón en Office 365 porque Office 365 puede verificar mensajes DKIM firmados) y verá la siguiente información similar en el encabezado del mensaje:

Firma DKIM: v=1; a=rsa-sha256; d=Exchangelabs.nl;
s=1471253148.exchangelabs; c=sencillo/sencillo; t=1471374160;
h=de:asunto:a:fecha:id-mensaje;
bh=b7KyI3BYV0CyZpQwBxNaF6lgrZQOwdY+ZRYmUTfcxNE=;
b=hWLVh5I4SMMqmFkXlem1wjj+WT2hrNkduciEAJmbQ9nrkugPFv9LFYl9ray1bKhIN0wIdMA0jnr
9FRtaSeMaAht0yM83hPTSy6OcZ89Bapdl6NGycyTaGCwea5iwJKH9/ZTt2cUtCh9hrZyINBT5uvKA
bp9YhzXU6Ks9uWExQ7g=

La firma DKIM parece legítima y hay más información en el encabezado del mensaje, información sobre la autenticación en sí:

Resultados de autenticación: spf=pass (la IP del remitente es 176.62.196.244)
smtp.mailfrom=Exchangelabs.nl; wesselius.info; dkim=contraseña (la firma era
verificado) header.d=Exchangelabs.nl;wesselius.info; dmarc=mejorcontraseña
acción=ninguna header.from=Exchangelabs.nl;wesselius.info; dkim=contraseña (firma
fue verificado) header.d=Exchangelabs.nl;
Recibido-SPF: Pasar (protection.outlook.com: dominio de Exchangelabs.nl
designa 176.62.196.244 como remitente permitido)
receptor=proteccion.outlook.com; ip-cliente=176.62.196.244;
helo=smtphost.exchangelabs.nl;

En este punto, tanto SPF como DKIM funcionan correctamente para mi entorno Exchange 2016 y el servidor de transporte perimetral firma correctamente los mensajes de correo electrónico mediante DKIM.

Desafortunadamente, en este momento solo tengo un módulo de firma DKIM en mi servidor Exchange y no pude encontrar un módulo de verificación DKIM.

Resumen

DKIM tiene que ver con firmar y verificar la información del encabezado en los mensajes SMTP. Dado que la firma se realiza con una clave privada que solo está disponible para su servidor de correo, un servidor de correo receptor puede estar seguro de que el mensaje realmente se origina en su organización y que no es un mensaje falsificado.

DKIM utiliza un par de claves, donde el servidor de correo emisor utiliza la clave privada y donde la clave pública se almacena en un registro DNS en el DNS público. Parece un poco complejo y la mayoría de los administradores de Exchange piensan que es complejo, pero cuando juegas con DKIM en un entorno de laboratorio, aprendes rápidamente que no es tan malo.

Esta publicación de blog trata sobre la instalación y configuración de DKIM en un servidor Exchange 2016, y el software que descargué de GitHub también está disponible para Exchange 2013 y Exchange 2010. Si no quiere la molestia de instalar y configurar, también puede optar por utilizando un dispositivo o servicio de terceros como IronPort, Exchange Online Protection (EOP) o MessageLabs que también ofrecen servicios DKIM.

En mi próximo blog hablaré de DMARC, ya que DMARC está construido sobre SPF y DKIM.

Más información

• Correo identificado de DomainKeys: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
• Desarrollo, implementación y operaciones de correo identificado de DomainKeys (DKIM): http://dkim.org/specs/draft-ietf-dkim-deployment-11.html
• Exchange Online está implementando la firma DKIM predeterminada para todos: https://blogs.msdn.microsoft.com/tzink/2015/12/16/exchange-online-is-rolling-out-default-dkim-signing-to- todos/
• Habilite la firma DKIM explícita en Office 365: https://supertekboy.com/2016/06/27/enable-dkim-signing-office-365/
• Foro de soporte de EmailArchitect: https://www.emailarchitect.net/forum/yaf_postst357_Set-up-DKIM-in-Exchange-2007-2010-2013.aspx
• Agente de firma DKIM para Microsoft Exchange Server: https://github.com/Pro/dkim-exchange
• Protección de correo electrónico mejorada con DKIM y DMARC en Office 365: https://blogs.office.com/2015/01/20/enhanced-email-protection-dkim-dmarc-office-365/
• Conexión manual de la firma DKIM en Office 365: https://blogs.msdn.microsoft.com/tzink/2015/10/08/manually-hooking-up-dkim-signing-in-office-365/
• Correo identificado con claves de dominio (DKIM.ORG) - http://dkim.org/`