Reforzar la seguridad de tu correo electrónico es un proceso que lleva varios pasos, desde hace un tiempo hemos estado hablando sobre diversos temas relacionados a la seguridad de los mensajes de correo salientes, para lo cual es necesario aplicar políticas DMARC; sin embargo, muchos propietarios de dominios todavía se preocupan por la seguridad del flujo de correo entrante.
En el año 2019, Google adoptó la nueva política MTA-STS la cual garantiza que todos los correos electrónicos entrantes deben pasar por una capa de seguridad de transporte (TLS, según sus siglas en inglés). Este protocolo criptográfico cifra las comunicaciones y las protege durante el tránsito; dicha política surgió para cubrir las debilidades de su sistema predecesor, STARTTLS.
STARTTLS como tal es un comando que solicita al servidor de correo que encripte la conexión, pero tiene una debilidad persistente: es una medida de protección opcional que no permite enviar alguna forma de autenticación del servidor, lo que hace que el comando en cuestión sea susceptible a ataques de intermediarios.
Ya que ha quedado claro que la necesidad de un cambio de política es necesaria, podemos profundizar en lo que es MTA-STS y cómo funciona.
¿Qué es MTA-STS?
La denominación de esta política en inglés se conoce como “Mail Transfer Agent-Strict Transport Security” (MTA-STS), en español lo conocemos como “Agente de transferencia de correo de seguridad estricta de transporte”, este es un protocolo que encripta los correos electrónicos entrantes a un servidor con una capa segura, lo cual permite la comunicación encriptada TLS entre los servidores SMTP, lo que a su vez evita los ataques de intermediarios.
La política de MTA-STS tiene como objetivo evitar que los atacantes o piratas informáticos alteren el contenido de un correo electrónico o envíe el contenido de este a otra dirección; a diferencia de STARTTLS, MTA-STS mantiene el TLS activo y le indica a los servidores de envío que tu servidor de correo solo acepta la entrega de mensajes a través de una conexión segura.
¿Por qué necesitas los informes que generan MTA-STS y TLS?
Es probable que tengas la idea de que no existe tal cosa como la seguridad en línea 100% garantizada, ya que la red está plagada de actores maliciosos que siempre están buscando mejorar y expandir sus métodos de ataques en función a cualquier nueva política o protocolo que surja para bloquear sus ataques, estos nunca se detienen y siempre están innovando.
Es por eso que los nuevos protocolos siempre traen algo nuevo a la mesa, las políticas de DNS de MTA-STS junto a los informes TLS es una forma confiable de hacer que tus comunicaciones por correo sean un poco más seguras siguiendo este procedimiento:
- Dificultando ataques de degradación
- Eliminando el riesgo de ataques de intermediario
- Resolviendo el problema de los certificados TLS caducados
TLS está ahí para mantenerte actualizado sobre los informes de fallas y las correcciones que puedes implementar.
¿Qué son los informes SMTP TLS?
Hace algún tiempo publicamos un artículo detanllado todos los aspectos necesarios del Protocolo simple de transferencia de correo (SMTP) y la capa de seguridad de transporte (TLS), por lo que es probable que estés familiarizado con su funcionamiento y con los informes TLS.
Ahora es el momento de aprender más acerca de lo que significan los informes TLS para los servidores con MTA-STS; básicamente lo que necesitas saber es que, si la política está configurada para «aplicar» y la conexión TLS falla, tus mensajes no serán enviados a tu bandeja de entrada, después de algunos intentos adicionales, el correo rebotará (es decir, volverá al remitente).
Pero, ¿cómo podemos saber cuántas conexiones fallaron? Es aquí donde los informes TLS entran al juego, ya que su función es informarte sobre los correos que pasaron y fallaron la conexión.
Al igual que los informes de DMARC, TLS informa sobre conexiones fallidas y señala por qué sucedieron estas incidencias; generalmente las fallas pueden ocurrir por tres razones específicas:
- Negociación fallida del TSL
- Problemas con el DNS
- Problemas con la política MTA-STS
- Al igual que los informes de DMARC, los informes de TLS se entregan a un URI (identificador uniforme de recursos) el cual está configurado a través de un registro TXT en el DNS.
La cadena contiene:
- La versión del TLS en uso (“v=”)
- El URI que va a recibir los informes (“rua=”). Esta línea puede tomar más de un valor separado por una coma.
Aquí puedes ver un ejemplo de una cadena de registro DNS:
“v=TLSRPTv1; rua=mailto:[email protected],https://tlsrpt.example.com/v1”
La estructura del informe TLS
A diferencia de los informes XML de DMARC, los informes SMTP TLS son fáciles de leer y comprender; los informes están presentados como archivos en formato JSON y generalmente muestran los siguientes componentes:
- report-id: El identificador del informe.
- date-range: el período de tiempo para la recopilación de resultados que contienen las fechas de inicio y finalización como subcategorías.
- organization-name: El nombre de la parte informante.
- contact-info: La información de contacto.
- policies: esta sección puede contener información sobre las políticas activas para un dominio especifico (STARTTLS, DANE, DNSSEC, MTA-STS); en el caso de MTA-STS, por ejemplo, esta sección repite la cadena del archivo de la política aplicada (te ofrecemos más información sobre los archivos y sus sintaxis a continuación).
- summary: esta sección te ofrece un recuento de sesiones exitosas y fallidas de la política.
- faillure-details: la parte final es donde se menciona lo que salió mal en el proceso de aplicación; el «tipo de resultado» puede tomar uno de los 10 valores establecidos, según sea la causa raíz de la falla, esta línea también incluye información sobre el servidor de envío, la IP de recepción y su nombre de host MX, también podrás confirmar el recuento de ser necesario.
A pesar de la sencillez de los reportes, sigue siendo preferible leerlo en un formato legible y fácil de comprender, tal como lo hace EasyDMARC.
¿Cómo funciona el MTA-STS?
MTA-STS es una política que verifica la conexión TLS en cada mensaje de correo que es enviado a tu ecosistema, que le indica al servidor SMTP de envío que la comunicación con tu servidor de correo debe estar encriptada y que el nombre del dominio en el certificado TLS y la política deben coincidir; tal como describimos anteriormente, este proceso garantiza que todas las comunicaciones enviadas a tu bandeja de entrada estén debidamente encriptadas.
La política contiene un mecanismo que se divide en dos partes: el archivo MTA-STS publicado en un servidor web habilitado para HTTPS y un registro DNS .TXT que informa a los remitentes que su dominio es compatible con tu política MTA-STS.
Una vez que todo esté configurado debidamente, recibirás informes a través de TLS-RPT indicando todos los fallos y problemas que puedan tener tus comunicaciones; es importante tener presente que los servidores de envío almacenan en caché el archivo MTA-STS y lo usan repetidamente durante un período determinado en los documentos; una vez que estos expiran, los servidores solicitan el archivo nuevamente.
Llegado a este punto, probablemente comprendes mejor los principios básicos de MTA-STS, por lo que ahora podemos profundizar en los dos componentes de la política.|
El archivo MTA-STS
Ya hemos discutido que MTA-STS es un archivo .TXT ejecutado a través de HTTPS, ahora vamos a ver qué es lo que contiene; es probable que supongas (correctamente) que al estar lidiando con un archivo .TXT simple, este debe tener una sintaxis específica para que el servidor de envío pueda leerlo e interpretarlo debidamente, dicho archivo debe contener los siguientes componentes:
- versión: qué versión del archivo de la política estás viendo; la sintaxis correcta debe incluir esta línea primero, el resto de los componentes pueden seguir en cualquier orden.
- mode: este es el modo en que se aplica la política, la cual puede tomar los siguientes valores:
- testing: los mensajes que no superen el TLS no serán bloqueados, pero podrás recopilar datos de estos, por lo que toca habilitar TLS-RPT para comenzar a recibir los informes. (este valor es bastante similar a la política de cuarentena que aplica DMARC)
- enforce: en este modo, si un mensaje falla el TLS, significa que los correos no serán entregados (similar a la política de rechazo de DMARC), sin embargo, seguirás recibiendo informes.
- none: si bien los modos anteriores son comparables a las políticas DMARC, este es muy distinto; la política none de tu archivo MTA-STS significa deshabilitar completamente la política.
- mx: para completar esta parte, debes extraer tus registros MX del DNS, por lo que toca mencionar cada host de correo en una línea separada para definir la sintaxis de cada archivo.
- max_age: este componente indica por cuánto tiempo el remitente debe almacenar en su caché la política, el número siempre es expresado en segundos y debe estar entre 604.800 y 1.209.600 (de 1 a 2 semanas) para el modo de prueba; y entre 24 horas (86.400 segundos) y 31.557.600 (un año) para el modo de cumplimiento.
El registro de DNS de MTA-STS
Para que un remitente «sepa» que debe hacer uso de la política MTA-STS, es necesario configurar el registro del DNS; si te diriges a los archivos de políticas podrás apreciar que contienen los siguientes componentes:
- “v=:” es el número de versión de la política en uso.
- “id=:” es el número de identificación de la política y esta debe cambiar una vez que sea actualizada.
¿Cuáles son los requisitos para aplicar MTA-STS?
No todos los servidores pueden manejar la política de seguridad de transporte estricta de MTA, ya que es necesario seguir algunos requisitos que deben ser verificados antes de comenzar la configuración:
- Puedes aceptar transferencias de correo a través de una conexión TLS
- Puedes usar la versión 1.2 de TLS como mínimo
- Los certificados TLS deben:
- Estar actualizados
- Tener los mismos servidores mencionados en sus registros MX
- Contar con la confianza de una autoridad certificadora de raíz
Implementando la política MTA-STS
Configurar la política MTA-STS para tu DNS es un proceso relativamente sencillo, debes tener en cuenta que sin importar que tan deseable sea alcanzar la codiciada política de «enforce», realizar avances progresivos en el modo de «prueba» requiere de mucha atención y cuidado (de lo contrario, es posible que se pierdan un montón de correos cruciales de remitentes importantes).
A continuación, te describimos un par de pasos a seguir antes de crear el registro para el DNS y el archivo MTA-STS:
- Enumera todos los dominios y subdominios que planeas proteger.
- Utiliza un comprobador de TLS para descubrir cualquier problema con su configuración.
- Asegúrate de que los certificados estén actualizados y que el TLS sea la versión 1.2 o superior.
- Asegúrate de que tu servidor admita el Certificado de capa de conexión segura (SSL), recuerda que HTTP no es suficiente, necesitas que tu URL sea HTTPS.
- Utiliza una solución holística para facilitar el camino al cumplimiento de las políticas.
Ahora que está todo listo, puedes comenzar el proceso de implementación de tres pasos:
Paso 1. Crea el archivo de la política
En primer lugar, debes crear el archivo de las políticas de MTA-STS, siguiendo la sintaxis que discutimos anteriormente, recuerda establecer el modo en «prueba» primero para apreciar el funcionamiento de la política.
Paso 2. Sube el archivo .TXT a la WEB
Asegúrate de poder acceder al archivo en la WEB cuando este sea solicitado, para que los remitentes puedan encontrarlo una vez que el registro del DNS los dirija a este. Ten presente que la URL debe seguir esta sintaxis:
https://mta-sts.example.com/.well-known/mta-sts.txt
Esto significa que debe crear una carpeta «.well known» y colocar el documento en esta.
Paso 3. Pública el registro del DNS
Ya hemos discutido este simple comando para el DNS anteriormente, aquí solo necesitas publicarlo, confirmarlo y pasar a la siguiente fase, la configuración de TLS.
Paso 4. Configura el TLS-RPT
A continuación, te toca crear la entrada DNS TLS, tal como se mencionó anteriormente para que puedas empezar a recibir los informes; no olvides que esta es una prueba del MTA-STS, una vez que veas que todo funciona correctamente, puedes pasar al siguiente paso.
Paso 5. Cambie el modo a «Aplicar»
Después de la prueba inicial del MTA-STS, puedes configurar el «modo:» en el archivo MTA-STS para «aplicar» lo cual filtrará los correos electrónicos que no estén encriptados.
Paso 6. Actualiza la ID para la versión de tu registro del DNS
El último paso es no olvidar actualizar el DNS con la nueva ID de la versión de la política que tienes en uso.
Resumen
EasyDMARC es una empresa que siempre se ha enfocado en la protección; la política DMARC protege tu empresa interna y externamente, pero, aun así, la seguridad de las comunicaciones entrantes son un problema constante. La política MTA-STS es solo un paso más para detener la piratería informática y el espionaje cibernético, también es una forma eficaz de enfrentar la manipulación de comunicaciones y los ataques de degradación.
Como ya hemos discutido cómo funciona MTA-STS, te invitamos a explorar las nuevas herramientas y procesos incluidos en esta política. La aplicación de esta medida de seguridad requiere de harta paciencia y minuciosidad.
El camino a la consolidación de un correo electrónico seguro en ocasiones se vuelve abrumador, por las demandas a nivel técnico, sin embargo, nada supera la tranquilidad de un buzón de correo seguro una vez que aprecias estos mecanismos trabajando para tu empresa u organización.