SPF, DKIM, DMARC.com
El proceso de "verificación del remitente" nos permite distinguir entre un remitente legítimo y un atacante que falsifica su identidad y prevenir un posible ataque de correo falso.
En el artículo actual, revisaremos en detalle tres estándares de verificación del remitente: SPF, DKIM, DMARC y también dos métodos de verificación del remitente que se pueden implementar en Exchange y en entornos basados en Exchange Online.
Protección SPF, DKIM DMARC, Exchange y Exchange Online de los cinco héroes
SPF, DKIM y DMARC son estándares de correo público creados con el fin de verificar la identidad del remitente.
Opciones adicionales que están disponibles para nosotros:
- Uso de la regla del servidor Exchange que identificará un evento en el que un elemento hostil utiliza la identidad de la organización para atacar a los usuarios de la organización alojados en Exchange.
- Usando la opción de protección Exchange Online del filtro Phish.
¿Cómo nos protege el estándar SPF del escenario de correo electrónico falso?
El estándar SPF se basa en un concepto en el que sacamos una conclusión sobre el remitente, verificando información sobre “su servidor de correo”.
Si queremos ser precisos, cuando utilizamos SPF, nos referimos a la "parte derecha" de la dirección de correo electrónico, es decir, el nombre de dominio.
El servidor de correo que representa al remitente debe considerarse como un “servidor de correo autorizado” para un nombre de dominio particular (el nombre de dominio que aparece en la dirección de correo electrónico del autor).
El proceso de verificación del remitente implementado por el servidor de correo de destino (el servidor de correo que representa al destinatario de destino) se realiza verificando la "integridad" del servidor de correo del remitente.
El servidor de correo que representa al "remitente" debe considerarse como un "servidor de correo autorizado" para el nombre de dominio en particular.
La información sobre el servidor de correo autorizado que puede enviar correo electrónico en nombre del dominio publicada en el registro SPF (un registro TXT), que incluye una lista de direcciones IP o nombres de host del servidor de correo que está autorizado para enviar correo electrónico. en nombre del dominio.
La identidad del remitente "tienda"
Cuando se utiliza SPF, la identidad del remitente que se verifica es la dirección de correo electrónico que aparece en el sobre del correo en el campo MAIL FROM.
Flujo de procesos de verificación del remitente SPF
El protocolo de verificación del remitente SPF utiliza el siguiente mecanismo para verificar la identidad del remitente:
Cuando el mensaje de correo electrónico llega al servidor de correo de destino, el servidor de correo "busca" del sobre de correo (campo MAIL FROM) la información sobre la dirección de correo electrónico del remitente.
El servidor de correo de destino se relaciona con el nombre de dominio de la dirección de correo electrónico (la parte derecha de la dirección de correo electrónico).
En nuestro ejemplo específico, el nombre de dominio del remitente es o365info.com
El servidor de correo se dirige al servidor DNS que aloja el nombre de dominio o365info.com y busca información en el registro SPF que está alojado "bajo" o365info.com nombre de dominio.
El registro SPF implementado como un registro TXT que incluye información relevante sobre el servidor de correo que está autorizado a enviar un correo electrónico en nombre del dominio o365info.com.
En nuestro ejemplo específico, el servidor de correo verifica si la dirección IP del "servidor de correo de origen" (el servidor de correo que representa al remitente) aparece en el registro SPF.
- Caso 1: en caso de que la dirección IP del servidor de correo de origen aparezca como figura en el registro SPF, el resultado de la prueba de verificación SPF es: “Pass”, que significa; el remitente es un remitente legítimo porque su servidor de correo se considera un servidor de correo legítimo.
- Caso 2: en caso de que la dirección IP del servidor de correo de origen no aparezca como figura en el registro SPF, el resultado de la prueba de verificación SPF es: “Falla”. significado; el remitente no es un remitente legítimo porque su servidor de correo no es un servidor de correo válido.
FPS | El escenario en el que el mensaje de correo electrónico se clasifica como correo electrónico falso
En el siguiente diagrama podemos ver la lógica del proceso de verificación SPF respecto al escenario de correo Spoof:
En caso de que la dirección IP del servidor de correo que envía el mensaje de correo electrónico en nombre del remitente no aparezca en el registro SPF para el dominio específico, la conclusión de que el mensaje de correo electrónico es un Correo falso (remitente falso).
La desventaja del estándar SPF
El método SPF tiene una desventaja importante relacionada con el campo de correo que se verifica en el proceso de verificación SPF.
- El proceso de verificación SPF "obtiene" la dirección de correo electrónico que aparece en el sobre del correo en el MAIL FROM
- El proceso de verificación SPF no se relaciona ni verifica la dirección de correo electrónico que aparece en el encabezado del correo en el DE
Este método puede ser fácilmente explotado por elementos hostiles, que pueden eludir el mecanismo de verificación SPF proporcionando dos identidades diferentes.
- La identidad que en el campo MAIL FROM será una identidad legítima.
- La identidad que en el campo DE será una identidad falsificada.
El proceso estándar SPF está configurado para verificar la información del remitente almacenada en el campo CORREO DE únicamente. En otras palabras, el proceso de verificación del remitente del SPF no se relacionará con la información del remitente almacenada en el campo DE. Se trata de una debilidad inherente que puede ser explotada por elementos hostiles. Si quieres leer más información sobre esta vulnerabilidad, puedes leer los artículos:
- ¿Cómo puede un elemento hostil ejecutar un ataque de correo electrónico falso y eludir la implementación SPF existente? | introducción | 1#2
- ¿Cómo simular un ataque de correo electrónico falso y evitar la verificación del remitente SPF? | 2#2
¿Cómo nos protege el estándar DKIM del escenario del correo Spoof?
El método DKIM para verificar la legitimidad de la identidad del remitente del correo se implementa mediante un método en el que una "entidad autorizada" firma digitalmente el mensaje de correo electrónico que envía el remitente.
La firma digital basada en PKI (infraestructura de clave pública) existente.
El uso de la opción de - Firma digital permite que el “otro lado” (el servidor de correo que representa al destinatario de destino en nuestro escenario) se asegure de que una autoridad confiable envió la información (el mensaje de correo electrónico).
Debido a que el correo electrónico fue enviado por una autoridad confiable (el servidor de correo, ellos representan al remitente), el servidor de correo de destino puede estar seguro de que el remitente es un remitente legítimo (el remitente es quien dice ser).
La “autoridad” que firma digitalmente el mensaje de correo electrónico del remitente suele ser el servidor de correo que entrega el correo electrónico en nombre del remitente.
En infraestructura DKIM, la entidad que firma el mensaje de correo electrónico se describe como selector DKIM.
La información firmada por el selector DKIM incluye un par de campos de correo. En el contexto de nuestro tema, lo principal que debemos saber es que el campo de correo denominado DE que contiene la identidad del remitente (la dirección de correo electrónico del remitente) está firmado digitalmente.
Si desea leer información más detallada sobre el estándar DKIM y la implementación de DKIM en un entorno basado en Office 365, puede leer la serie de artículos DKIM - Correo identificado con claves de dominio | Introducción básica | Parte 1#10.
Flujo de procesos de verificación del remitente DKIM.
El protocolo de verificación del remitente DKIM utiliza el siguiente mecanismo para verificar la identidad del remitente:
El correo electrónico que se envió desde el servidor de correo de origen incluye.
- La firma digital de los datos que incluye la dirección de correo electrónico del remitente.
- Información sobre el nombre (FQDN) del servidor de correo que firmó el correo electrónico, es decir, el selector DKIM.
Cuando el mensaje de correo electrónico llega al servidor de correo de destino, el servidor de correo "busca" del encabezado del correo (campo DE) la información sobre la dirección de correo electrónico del remitente.
Para poder obtener información sobre la "autoridad" que firmó digitalmente el mensaje de correo electrónico, el servidor de correo de destino se relaciona con el nombre de dominio de la dirección de correo electrónico (la parte derecha de la dirección de correo electrónico).
En nuestro ejemplo específico, el nombre de dominio del remitente es o365info.com
El servidor de correo "busca" del encabezado del correo el nombre de host del selector DKIM que firmó el mensaje de correo electrónico.
El servidor de correo de destino se dirige a un servidor DNS que aloja el nombre de dominio en particular y busca información en el registro DKIM alojado "bajo" el nombre de dominio o365info.com .
El registro DKIM implementado como un registro TXT, que incluye información relevante sobre el nombre de host del selector DKIM.
En un escenario DKIM, el servidor de correo buscará información sobre el nombre de host del selector DKIM.
En caso de que el registro DKIM incluya el nombre de host del selector DKIM que aparece en el
mensaje de correo electrónico, el servidor de correo “sabe” que es una autoridad autorizada y que se puede confiar en él.
Ahora, al servidor de correo de destino, pasa a la siguiente fase, en la que necesita verificar la firma digital que aparece en el mensaje de correo electrónico.
El proceso de verificación de firma digital implementado mediante un proceso bastante complicado. El servidor de correo de destino calcula por sí mismo el valor HASH del campo de correo (incluido el campo de correo DE que contiene la dirección de correo electrónico del remitente) y compara el valor HASH que obtuvo con el valor HASH. que aparece en el correo electrónico.
- Caso 1: en caso de que el valor HASH sea idéntico, el significado es que los datos no fueron alterados de ninguna manera y entonces podemos estar seguros de que el remitente es un remitente legítimo.
- Caso 2: en caso de que el valor HASH no sea idéntico, el significado es que los datos fueron alterados y, por este motivo, no podemos estar seguros de que el remitente sea legítimo. remitente.
DKIM | El escenario en el que el mensaje de correo electrónico se clasifica como correo electrónico falso.
Desde el punto de vista del proceso DKIM, la prueba de verificación incluye dos “pruebas” que deben completarse con éxito.
Prueba 1 - En caso de que el selector DKIM que aparece en el mensaje de correo electrónico no aparezca en el registro DKIM alojado bajo el nombre de dominio del remitente, el proceso de verificación considera como significado fallido, el E -mail se considera correo falso.
Prueba 2: en caso de que el valor HASH de la firma digital no sea válido (no idéntico), el proceso de verificación lo considera fallido, lo que significa que el correo electrónico se considera correo falso.
¿Cómo nos protege Exchange del escenario de correo electrónico falso?
Comencemos con una declaración - por defecto; Exchange no está configurado para “protegernos” de un escenario de correo falso (remitente falsificado).
Incluso podemos decir que el servidor Exchange es “indiferente” a los ataques de correo electrónico falso o a la identidad del remitente.
Aunque por defecto el servidor Exchange es “indiferente” a la legitimidad de la identidad del originador, podemos utilizar una poderosa opción de Exchange que nos ayudará a identificar remitentes legítimos. En un escenario particular en el que queremos verificar la identidad del remitente que utiliza el nombre de dominio alojado por la organización Exchange (el nombre de dominio específico para el que Exchange consideró autorizado).
La "Prueba de verificación de intercambio" se implementa mediante una combinación de "dos partes":
- Información que se guarda en el encabezado del mensaje de correo electrónico.
- Regla de cambio.
Usando una regla de Exchange, podemos definir una condición lógica que nos permitirá identificar un escenario de remitente falsificado (correo falso).
Cuando utilizamos el término "correo falso", nos referimos a un escenario particular: un escenario en el que un elemento hostil utiliza "nuestra identidad de usuario" e intenta atacar a uno de los usuarios de nuestra organización.
La condición de la regla de Exchange que definimos en base a la siguiente lógica:
Se supone que cada entidad que utiliza nuestra identidad organizacional (la dirección de correo electrónico que incluye nuestro nombre de dominio) es una entidad legítima, alojada en nuestro servidor Exchange.
Cada entidad legítima que se dirige al servidor Exchange debe proporcionar credenciales de usuario, de modo que el servidor Exchange pueda saber que se trata de una entidad legítima y confiable.
Por ejemplo, cuando abrimos nuestro Outlook y accedemos a los datos almacenados en nuestro buzón, nuestras credenciales de usuario se “transfieren” en segundo plano al servidor Exchange.
La información sobre si las “entidades” proporcionan o no credenciales de usuario se registra como parte del encabezado del correo.
- En caso de que la entidad proporcione credenciales de usuario, el estado de autenticación de la entidad es: interno.
- En caso de que la entidad no haya proporcionado credenciales de usuario, el estado de autenticación de la entidad es: Anónimo.
El “truco” que podemos utilizar se basa en un procedimiento en el que “obtenemos” la información sobre el estado de autenticación de los remitentes, que su mensaje de correo electrónico incluye nuestro nombre de dominio.
Por ejemplo, en nuestro ejemplo específico, el elemento hostil que se presenta utiliza la dirección de correo electrónico: John@o365info.com (una identidad falsa).
John es un destinatario de Exchange "real", que tiene un buzón de Exchange, etc.
El servidor de correo Exchange que considera autoritario para el nombre de dominio -o365info.com espera que el remitente proporcione las credenciales de usuario. Esta es la forma "correcta" que utiliza un destinatario legítimo para acceder a sus datos privados almacenados en el buzón de Exchange.
En nuestro escenario, el elemento es un elemento hostil que no tiene las credenciales de John (nombre de usuario + contraseña).
Por esta razón, su estado de autenticación es Anónimo pero, al mismo tiempo, utiliza la dirección de correo electrónico de "John".
Esta es nuestra señal de que se trata de un remitente falsificado (correo falso).
Poder "decirle" al servidor Exchange que queremos identificar eventos de correo falso en los que el estado de autenticación del remitente es anónimo y la dirección de correo electrónico del remitente incluye nuestro nombre de dominio; Podemos crear una regla de Exchange que monitoreará dichos eventos y "hará algo" cuando identifique dicho evento.
Es importante enfatizar que esta opción está disponible solo para una organización que utiliza la infraestructura de correo de Exchange y no es un estándar formal ni público. En lugar de ello, se trata de un “truco” que podemos utilizar a nuestro favor como mecanismo de deducción de correo falso o, como capa adicional para la implementación de estándares de verificación de remitentes de correo existentes, como SPF.
Regla de cambio | El escenario en el que el mensaje de correo electrónico se clasifica como correo electrónico falso
El evento de “correo falso” se describirá por una combinación de dos condiciones, que deberían ocurrir al mismo tiempo.
El remitente debe utilizar una dirección de correo electrónico que incluya el nombre de dominio de la organización y se considere un remitente anónimo (remitente que no proporcionó credenciales de usuario).
¿Cómo nos protege Exchange Online del escenario de correo electrónico falso?
La característica del filtro de phishing (y la política de filtro de phishing) es una característica relativamente nueva que está disponible para los clientes de Exchange Online, es decir, los clientes de Office 365.
La opción Phish Filter es una característica EOP (Exchange Online Protection). En un entorno basado en Office 365, EOP sirve como una "puerta de enlace de seguridad del correo".
El objetivo del filtro de phishing es permitir a los clientes de Office 365 detectar un escenario típico de correo falso, en el que el atacante proporciona dos identidades diferentes: la identidad del remitente que aparece en el campo MAIL FROM (el sobre de correo) + la identidad del remitente que se muestra en el campo DE (encabezado del correo).
Si desea leer más información sobre este método que utilizan elementos hostiles para eludir el mecanismo de verificación del remitente existente, como SPF, puede leer el artículo ¿Cómo puede un elemento hostil ejecutar un ataque de correo electrónico falso y evitar la implementación de SPF existente? | introducción | 1#2.
El filtro Phish detecta un evento de correo falso basándose en una prueba de verificación muy simple:
Cuando un remitente se dirige al servidor de correo de Exchange Online (si queremos ser más precisos, la Protección de Exchange Online) y utiliza dos conjuntos de identidades de remitente, la Política de filtro de phishing en línea de Exchange verificará si la información del remitente en el El campo CORREO DE es idéntico a la identidad del remitente en el campo de correo DE.
En el caso de que las identidades sean diferentes, esto es una señal de que algo anda “mal” con el mensaje de correo electrónico en particular.
Política de filtro de phishing en línea de Exchange | El escenario en el que el mensaje de correo electrónico se clasifica como correo electrónico falso
El evento de "Correo falso" se describirá como: una escena en la que la dirección de correo electrónico que aparece en mora en el campo MAIL FROM está "no alineada", es decir, es diferente de la dirección de correo electrónico que aparece en el campo DESDE.
En este caso, el correo electrónico se considerará un mensaje de correo electrónico de alto riesgo y se agregará una notificación de advertencia al mensaje de correo electrónico original.
¿Cómo nos protege DMARC del escenario de correo electrónico falso?
El estándar DMARC es especial porque no incluye un "mecanismo independiente" o protocolo para implementar la verificación del remitente, sino que se basa en otro protocolo de autenticación del remitente: SPF y DKIM.
El “trabajo” del estándar DMARC con respecto al proceso de verificación del remitente es
- Para comprobar si un mensaje de correo electrónico específico fue verificado por uno de los estándares de verificación del remitente: SPF o DKIM.
- Para comprobar si el resultado de la prueba de verificación es aprobado o no.
- Implementar una capa adicional de verificación del remitente descrita como alineación.
En caso de que utilicemos uno de estos protocolos de autenticación de remitente, el DKIM “expande” el proceso de verificación que implementa cada uno de estos protocolos.
En otras palabras, DMARC está realizando “pruebas de verificación del remitente más estrictas” en comparación con el estándar de verificación del remitente: SPF o DKIM.
El término técnico que utiliza DMARC para describir la “capa adicional” de verificación del remitente se describe como - alineación.
Por ejemplo, en caso de que usemos SPF o DKIM, desde el punto de vista de DMARC, no es suficiente que la prueba de verificación SPF o DKIM sea exitosa, sino también que DMARC "dicte" la condición adicional, que debe implementarse con éxito.
El estándar DMARC y la alineación SPF
En un escenario en el que nuestra infraestructura de correo utiliza el estándar SPF para implementar la verificación del remitente, la prueba de verificación SPF "marcará" cada uno de los correos entrantes como fallido o pase.
Nota: En realidad, el estándar SPF incluye un código de estado adicional, pero en este momento nos gustaría simplificar la descripción. Por este motivo, relacionaremos únicamente el código de estado fallo o aprobado.
Cuando utilizamos el estándar DMARC, la primera prueba que realizará DMARC es verificar si el estado del SPF es fallido o aprobado. .
En caso de que el estado del SPF sea aprobado, el DMARC continuará con la siguiente prueba, en la que el DMARC verifica la “alineación del SPF” requerida. "
La prueba de alineación SPF se implementa verificando si la dirección de correo electrónico del remitente que aparece en el campo MAIL FROM (la información que se muestra en el sobre del correo) es idéntica a la dirección de correo electrónico que se muestra en el campo DE (la información que aparece en el encabezado del correo).
Caso 1: aprobación de la prueba de alineación DMARC SPF
En el siguiente diagrama podemos ver un ejemplo en el que el mensaje de correo electrónico incluye 2 identidades de remitente. En nuestro ejemplo, la identidad del remitente que aparece en MAIL FROM es idéntica a la identidad del autor que se muestra en el campo DE.
En este caso, la prueba de alineación del SPF se completó con éxito y DMARC marca
el mensaje de correo electrónico con el código de estado: dmarc=pass
Caso 2: falla en la prueba de alineación DMARC SPF
En el siguiente diagrama podemos ver un ejemplo en el que el mensaje de correo electrónico incluye 2 identidades de remitente. En nuestro ejemplo, la identidad del remitente que aparece en MAIL FROM es diferente de la identidad del autor que se muestra en el campo DE.
En este caso, la prueba de alineación del SPF no se completó con éxito y el DMARC marca
el mensaje de correo electrónico con el código de estado - dmarc=fail
El estándar DMARC y la alineación DKIM
En un escenario en el que nuestra infraestructura de correo utiliza el estándar DKIM para implementar la verificación del remitente, la prueba de verificación DKIM “marcará” cada uno de los correos entrantes como fallido o pase.
Cuando utilizamos el estándar DMARC, la primera prueba que realizará DMARC es, para verificar si el estado de DKIM es, falla o pasa. .
En caso de que el estado DKIM sea aprobado, el DMARC continuará con la siguiente prueba, en la que el DMARC verifica la “alineación DKIM” requerida.
La prueba de alineación DKIM se implementa verificando si el nombre de dominio del selector DKIM es idéntico al nombre de dominio del remitente que aparece en el DE. (la información que se guarda en el encabezado del correo).
Caso 1: aprobación de la prueba de alineación DMARC DKIM
En el siguiente diagrama podemos ver un ejemplo de la información sobre el nombre del selector DKIM que firmó el mensaje de correo electrónico. La información sobre el nombre de host del selector DKIM guardada como parte del correo electrónico.
En nuestro escenario, el nombre del selector DKIM incluye el nombre de dominio: o365info.com
En el campo DE, podemos ver que la dirección de correo electrónico del remitente utiliza también el nombre de dominio: o365info.com
En este caso, la prueba de alineación DKIM se completó con éxito y DMARC sella
el mensaje de correo electrónico con el código de estado: dmarc=pass
Caso 2: falla en la prueba de alineación DMARC DKIM
En el siguiente diagrama podemos ver un ejemplo de la información sobre el nombre del selector DKIM que firmó el mensaje de correo electrónico. La información sobre el nombre de host del selector DKIM guardada como parte del correo electrónico.
En nuestro escenario, el nombre del selector DKIM incluye el nombre de dominio: outlook.com
En el campo DE, podemos ver que la dirección de correo electrónico del remitente utiliza también el nombre de dominio: o365info.com
En este caso, la prueba de alineación DKIM no se completó correctamente porque el nombre de dominio del selector DKIM no es idéntico al nombre de dominio del remitente.
El DMARC estampa el mensaje de correo electrónico con el código de estado - dmarc=fail
