Según mencionábamos en el anterior artículo de esta serie, actualmente una de las grandes amenazas en el correo electrónico son el phishing y el spoofing (suplantación de identidad), cuya identificación puede llegar a ser especialmente problemática.
Para mitigar este problema existen principalmente tres mecanismos:
- SPF, el convenio de remitentes. Permitirá a una organización definir desde qué servidores o IPs se puede mandar correo en su nombre.
- DKIM, que hace uso de una firma para garantizar la autenticidad del correo.
- DMARC, la combinación de SPF y DKIM, que permitirá realizar valoraciones cruzadas y, en base a sus resultados, determinar qué se hace con un correo (eliminarlo, dejarlo en cuarentena o entregarlo con normalidad).
SPF (Sender Policy Framework)
SPF es una técnica de autenticación de correo electrónico que sirve para validar si un correo recibido fue enviado desde un lugar autorizado y, de esta forma, dificultar que los ciberdelincuentes o spammers puedan enviar emails en nombre de un dominio manipulado.
En el artículo anterior veíamos un ejemplo real de un caso de “fraude del CEO”, en él un ciberdelincuente intenta hacerse pasar por otra persona modificando el campo “From” de la cabecera del correo, para que el receptor vea en su bandeja de entrada que el email viene de alguien conocido o confiable.
Sin embargo, el ciberdelincuente puede necesitar que el empleado responda a su email engañoso y le mande alguna información, por este motivo, el campo “Return-Path” de las cabeceras (que no es visible cuando simplemente leemos un correo) contendrá una dirección email al que el ciberdelincuente sí tiene acceso.
La buena noticia es que SPF puede identificar este correo engañoso desde el primer momento y de forma automática. SPF no consulta la dirección que aparece en el campo “From” de la cabecera del correo, pues es el dato que precisamente suele manipularse para hacer la suplantación de identidad; lo que SPF valida es la dirección que aparece en el campo “Return-Path”.
Veamos ahora un ejemplo genérico donde aplicar SPF:
Supongamos que Bob, trabajador en ACME, recibe un correo electrónico de su jefa, Alice, en su bandeja de entrada. En este email Alice aparece como remitente y su correo aparece perfectamente escrito: alice@acme.com. Bob no tiene motivos para sospechar de la autenticidad del mismo.
Sin embargo, un análisis de las cabeceras de dicho correo revelaría que en el campo oculto Return-Path hay una dirección desconocida: charlie@umbrellacorp.com. Es decir, que si Bob respondiera a ese correo, la respuesta no sería enviada a su jefa Alice sino al tal Charlie.
Para evitar este tipo de engaños, cada vez más frecuentes, la empresa ACME decide implementar SPF. Esta implementación es muy sencilla, pues SPF es simplemente un registro TXT que se añade a la zona DNS del dominio acme.com.
En este registro SPF se puede especificar qué direcciones IP o nombres de host están autorizados para enviar correo electrónico desde el dominio específico.
Una ventaja de distribuir los registros SPF a través de DNS es que los ISP irán almacenando en caché los registros más populares y esta comprobación de seguridad no supone una sobrecarga de tráfico en la red.
Un ejemplo de configuración de SPF sería:
v=spf1 ip4:111.222.33.44/28 include:spf.protection.outlook.com include:spf.example1.net ip4:222.111.170.0/26 ip4:66.22.77.248 ip4:88.111.55.51 include:spf.examplemails.com -all
donde:
- v=spf1 indica la versión a utilizar.
- Con ip4 o ip6 indicamos las IPs (en IPv4 o IPv6, respectivamente) de los servidores autorizados para mandar correo en nombre de nuestra organización.
- Con la etiqueta include añadimos las organizaciones o terceros que pueden mandar emails en nombre de nuestra empresa.
- Finalmente, con -all, ~all o +all podemos indicar al ISP qué debería hacer si hay un correo electrónico que aparentemente vienen de nuestro dominio pero que no ha sido originado en uno de los servidores autorizados:
- -all, se cataloga “fail SPF”.
- ~all, equivaldría a un “soft fail”, es decir, si el correo proviene de un servidor no autorizado se marcaría para ser aceptado con una advertencia.
- +all, no realizaría ningún etiquetado en los correos aunque provengan de servidores no autorizados, es decir, a efectos prácticos sería como deshabilitar el control SPF.
Además de estos, existen otros parámetros adicionales (mx, exists, a) con utilidades muy diversas, de modo que es posible adaptar bastante bien el control a nuestras necesidades.
Ahora, con SPF implantado, cuando Bob recibe un correo que aparentemente es de Alice, se hará una comprobación. La validación SPF cogerá el dominio del Reply-To, que no es acme.com sino umbrellacorp.com y consultará su registro SPF, si es que tiene. En cualquier caso, allí no aparecerá la IP del servidor de ACME, ya que es una dirección privada.
Por tanto, la validación SPF no ha sido superada y el correo podría gestionarse como malicioso.
Y si Alice manda un correo a Bob, SPF extrae el dominio que aparece en el campo “Return-Path”: acme.com y consulta el registro SPF asociado a dicho dominio. Se comprueba que el email fue enviado desde la IP 1.2.3.4 y que esta IP aparece en el registro SPF de acme.com, así que el mecanismo considerará que se ha superado la validación y que se trata de un correo seguro:
Este ejemplo era relativamente evidente porque tanto remitente como destinatario pertenecían a la misma organización, pero SPF también tiene sus limitaciones: por ejemplo, el hecho de reenviar un correo añade una nueva capa de cabeceras que provoca que SPF falle en su verificación.
Para ayudar a superar estos problemas, lo ideal es combinarlo con DKIM y DMARC.
DKIM (Domain Keys Identified Email)
El estándar DKIM consiste en “firmar” las cabeceras de los correos electrónicos, para garantizar que su origen es auténtico y que el mensaje no ha sido alterado por el camino. Está implementado de tal forma que es compatible incluso con servidores de correo que no lo soportan, de modo que estos no tienen problemas con la recepción. Es decir, es una capa de seguridad adicional y opcional.
DKIM se basa en un sistema de criptografía asimétrica o criptografía de clave pública, que consisten en tener dos claves: una privada, que sólo conoce la parte emisora, y una pública que, como su nombre indica, puede distribuirse públicamente.
Como vemos en el diagrama, DKIM añade a cada correo electrónico saliente una nueva cabecera llamada “DKIM-Signature”, con una firma digital del contenido del mensaje. Es decir, cada correo enviado llevará consigo mismo un resumen cifrado de su contenido.
La organización pone la llave pública en su registro DNS, para poder realizar el descifrado de esta cabecera especial.
Cuando el correo llega al servidor receptor, este lo analiza e identifica en la cadena “_domainkey” el registro DNS al que debe consultar para obtener la clave pública. La respuesta a esta consulta DNS incluye dicha clave pública del dominio, con la que se procede a descifrar la cadena.
Si el mensaje recibido (cuerpo y cabeceras) y el mensaje descifrado (cuerpo y cabeceras) coinciden completamente, querrá decir que ningún campo o característica del correo se ha modificado desde su envío.
Si hubiera alguna discrepancia y estos elementos no coincidieran, el mensaje no se rechaza automáticamente, pero se etiquetará como “dkim:fail” y esta etiqueta permitirá definir reglas de comportamiento más adelante.
Pese a que técnicamente DKIM conlleva más complejidad que SPF, su configuración puede llegar a ser mucho más sencilla. Por ejemplo, en Outlook 365 DKIM puede activarse a través de la consola de administración (Administración > Exchange > Protección > dkim), sin necesidad de tocar registros o ficheros de configuración (salvo que tengamos más de un dominio a proteger o prefiramos gestionar manualmente las claves de cifrado).
DKIM resulta especialmente interesante para prevenir la suplantación de identidad dentro de una misma organización donde se haya establecido que todos los correos usarán DKIM: si alguien manda un correo en nuestro nombre, al no disponer de nuestra clave privada, cuando el servidor receptor intente descifrar con la clave pública, no funcionará y saltará la alarma (dkim:fail).
Ha de quedar claro que esta forma de trabajar de DKIM busca asegurar la autenticidad e integridad del mensaje, pero no su confidencialidad. Como hemos explicado, no se cifra el mensaje propiamente dicho, si no una “copia” o “resumen” del mismo (la DKIM-Signature) que luego se usa solamente para comparar. Es decir, si alguien interceptara este correo, podría conocer su contenido, pero no podrá alterarlo para engañar al receptor porque no disponen de la clave privada.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
Aunque a menudo se cataloga a DMARC como un tercer mecanismo de protección ante phishing y spoofing, se trata en realidad de una unificación o combinación de SPF y DKIM, que da la posibilidad de definir un comportamiento más fino según los resultados obtenidos:
- SPF verifica que cada correo recibido procede de un host autorizado por el administrador del dominio correspondiente.
- DKIM verifica que cada correo recibido no ha sido cambiado de camino al destinatario y que fue originado por el remitente especificado.
- Los sistemas que reciben los correos evalúan los resultados de estas dos verificaciones (pass/fail) y actúan según se haya preestablecido (se entrega el correo, se rechaza, se pone en cuarentena).
Esta política de comportamiento se define en los registros TXT de DNS de la compañía (como SPF) siguiendo la siguiente estructura:
_dmarc.domain TTL IN TXT "v=DMARC1; p=[none|quarantine|reject]; pct=[0-100]"
donde:
- domain es el dominio a proteger.
- TTL debe equivaler a una hora (dependiendo del registrador de dominio varía la unidad que se toma -segundos, minutos-, pero siempre debe equivaler a una hora).
- p es la política que se usa en caso de no pasar la validación:
- none: el email se entrega
- quarantine: el email se entrega en la carpeta de spam
- reject: el email no se entrega
- pct representa el porcentaje de correo sobre el que queremos aplicar esta directiva. Por ejemplo, si se acaba de implantar DMARC y desconocemos el efecto que puede tener, puede ser interesante empezar a analizar un porcentaje bajo, pct=10, ir evaluando que el comportamiento es el deseado y, si es así, ir aumentándolo progresivamente hasta analizar llegar a pct=100 y analizar el 100%.
Un ejemplo de registro DMARC ya parametrizado sería:
_dmarc.acme.com 3600 IN TXT "v=DMARC1; p=reject; pct=100"
Además de estos que son los fundamentales, existen otros parámetros adicionales, como aquellos que permiten incluir una dirección de correo electrónico donde recibir informes de actividad (rua) o los informes forenses (ruf, disponible sólo en algunas plataformas de correo).
En resumen, con esta configuración, podría empezar a definirse un comportamiento a la hora de gestionar correos que no cumplen todos los controles de seguridad: si un correo pasa todas las validaciones, se entregará al destinatario; si no cumple ninguna, se bloqueará; y se definirá qué hacer si sólo cumple una parte de las validaciones.
Conclusiones
Como hemos visto, el correo electrónico es una puerta de entrada para muy distintos tipos de ataques externos. Para hacer frente, en concreto, a la suplantación de identidad y al phishing, existen mecanismos de protección específicos: SPF para establecer una asociación entre dominios y servidores seguros, DKIM para garantizar que un correo procede realmente del remitente que indica y, finalmente, DMARC para combinar los resultados de estas validaciones y establecer una política de actuación.
Si bien es un sistema que dista mucho de ser perfecto y que en el caso de DKIM puede entrañar un esfuerzo adicional (por la gestión de claves), en el campo de la ciberseguridad es importante desplegar distintas capas de protección que se complementen (lo que se conoce como “defense in depth”). En este sentido, no sólo se recomienda a las organizaciones la activación de estos mecanismos, sino también complementarlos con otras medidas como puedan ser la protección activa de los sistemas a través de actualizaciones de seguridad y búsqueda de vulnerabilidades o la formación y concienciación de los empleados.
Referencias
- Tripwire: “6 Common Phishing Attacks and How to Protect Against Them”
- Kaspersky: “The Human Factor in IT Security: How Employees are Making Businesses Vulnerable from Within”
- Outlook: SPF
- Outlook: DKIM
- Outlook: DMARC
Autor: Daniel Fuertes - CISSP, PCIP, ISO 27001 L.A.
Dpto. Consultoría
