Mejorar la seguridad del correo electrónico: Detenga el fraude de los remitentes con SPF, DKIM y DMARC

No hay que filtrar la verdad: necesita proteger el correo electrónico de su empresa.

En 2013, se enviaron y recibieron más de 100.000 millones de correos electrónicos empresariales cada día. Sólo uno de cada cinco de todos los correos electrónicos enviados en 2013 eran legítimos, y el 92% de todos los correos electrónicos ilegítimos incluían enlaces a contenido potencialmente malicioso.

Sin embargo, hay signos de mejora; este mes es el primero en los últimos 12 años en el que menos de la mitad de los correos electrónicos de los clientes de Symantec eran spam.

Puede agradecer a tres estándares de seguridad del correo electrónico (y otras iniciativas) la reducción del spam: SPF, DKIM y DMARC. Aun así, los riesgos de seguridad son frecuentes. Hace poco me contaron la historia de un director financiero que fue objeto de un intento de phishing. El intento fracasó, pero si hubiera tenido éxito, habría costado a la organización 50.000 dólares.

En cuanto a estas normas de correo electrónico, todavía hay mucha confusión en torno a ellas. Espero poder proporcionar algo de claridad con este post, así como guiarle a través de cómo implementar SPF, DKIM y DMARC.

Marco de Políticas del Remitente (RFC 4408)

El Marco de Políticas del Remitente, o SPF, es el viejo en la fiesta de la autenticación del correo electrónico. SPF es un estándar abierto que especifica un método para evitar la falsificación de direcciones de remitentes, según openspf.org. No se trata de detener el spam; se trata de controlar y detener los intentos de falsificación de remitentes.

SPF le permite identificar las fuentes de correo legítimas de su dominio y evita que las fuentes no autorizadas envíen miles -o incluso millones- de correos electrónicos ilícitos desde su dominio.

Hay cuatro tipos de abuso de correo electrónico comúnmente asociados con la falsificación de remitentes de correo electrónico:

• Spam (correo masivo no solicitado &correo comercial no solicitado)
• Fraudadores (estafas 419)
• Malware (adware, zero days, virus, troyanos, etc.))
• Phishers (spear-phishing)

No quiere que el dominio de su organización se asocie con ninguno de ellos por razones obvias. SPF le ayudará a asegurarse de que los correos electrónicos de su organización proceden realmente de usted.

DomainKeys Identified Mail (RFC 6376, sustituye al RFC 4871 y al RFC 5672 que ya están obsoletos)

DKIM, o DomainKeys Identified Mail, es un registro TXT publicado en su sistema de nombres de dominio (DNS). Implica algo que todos los administradores de TI deberían aprender a amar: las claves, las claves públicas para ser específicos.

Antes de sumergirnos en DKIM, es importante que entendamos qué son las claves y cómo funcionan. Las claves, en este caso, la criptografía de clave pública, consiste en una clave pública (conocida por todo el mundo) y una privada (a menudo denominada secreta). Las claves públicas y privadas están vinculadas matemáticamente entre sí, haciendo posible la comunicación segura a través de canales públicos.

Estas claves son como un sello a prueba de manipulaciones en un sobre transparente. No necesariamente se está ocultando el mensaje; sólo se está autenticando con un 100% de certeza tanto al remitente como al mensaje.

Ahora, volvamos a DKIM.

«Técnicamente, DKIM proporciona un método para validar la identidad de un nombre de dominio que está asociado a un mensaje a través de la autenticación criptográfica», según dkim.org. En otras palabras, DKIM utiliza claves para asegurarse de que un remitente de correo electrónico es quien dice ser.

Con DKIM, se generan pares de claves públicas y privadas para mantener autenticados los servidores de correo y las comunicaciones. Cada servidor de Protocolo Simple de Transferencia de Correo (SMTP) saliente necesita la clave privada y el prefijo correctos para coincidir con un registro DNS público que el servidor de correo receptor verifica a continuación.

¿Te has preguntado alguna vez por qué aparece el icono del candado en Gmail cuando recibes mensajes de eBay, Paypal o tu banco? Eso es DKIM y un poco de DMARC (del que hablaremos en breve). A continuación, mailed-by muestra la coincidencia SPF y signed-by muestra la coincidencia DKIM. DKIM y DMARC aún no son esenciales, pero, al igual que IPv6, están pasando rápidamente del laboratorio de pruebas a ser una realidad.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, o Domain-based Message Authentication, Reporting, and Conformance, ayuda a los remitentes y receptores a trabajar juntos para crear comunicaciones de correo electrónico más seguras. DMARC fue creado por un grupo de organizaciones para limitar el abuso basado en el correo electrónico «solucionando un par de problemas operativos, de despliegue y de información relacionados con los protocolos de autenticación del correo electrónico, que vienen de lejos», según dmarc.org.

DMARC permite al remitente del mensaje indicar que sus mensajes están protegidos con SPF y/o DKIM. Una política DMARC aplica instrucciones claras para que el receptor del mensaje siga si un correo electrónico no pasa la autenticación SPF o DKIM, por ejemplo, rechazarlo o enviarlo a la basura.

Además, DMARC envía un informe al remitente sobre los mensajes que PASAN y/o NO PASAN la evaluación DMARC.

Cómo implementar SPF, DKIM y DMARC

Ahora que entendemos mejor cada uno de estos tres estándares (y por qué son importantes), veamos cómo puede mejorar la seguridad de su correo electrónico implementándolos.

Nota: Para este recorrido paso a paso, vamos a suponer que eres el responsable de TI de 301 Moved, una pequeña empresa de diseño web que utiliza Google Apps.

Recientemente, has tenido algunos problemas con los robots de spam rusos. Sus usuarios finales se han quejado de recibir notificaciones de rebote de correo electrónico de direcciones que nunca han visto o a las que han enviado mensajes. Te das cuenta de que alguien está enviando claramente correos electrónicos fraudulentos desde tu dominio.

Así que, ¿cómo los detienes?

Nota: Estoy incluyendo el formato estándar de BIND en texto plano y una captura de pantalla de cómo se ve el registro en GoDaddy DNS. En GoDaddy, todos los registros para el dominio de nivel superior 301Moved.com utilizan el host «@», su host probablemente será diferente. A los efectos de este ejercicio, sólo hablaré del correo saliente, no de cómo tratamos estas normas en relación con el correo entrante de remitentes externos.

Implementación de SPF

Primer paso: La guía de Google para configurar los registros SPF para que funcionen con Google Apps es un buen punto de partida. Siguiendo esas instrucciones, añadimos un nuevo registro TXT a nuestro DNS público.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved también utiliza Zendesk, un sistema de tickets que envía correos electrónicos directamente desde su dominio. Debe asegurarse de que tampoco se envía spam desde allí.

Segundo paso: Buscar y añadir el registro SPF de Zendesk.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Es importante tener en cuenta que no estamos añadiendo un segundo registro SPF, eso rompería las cosas; en su lugar, los estamos combinando en un único registro, haciéndolo más largo a medida que se añaden más remitentes.

Nota: Sólo puedes añadir un registro SPF por dominio o subdominio.

También sabes que 301 Moved tiene una antigua pasarela de correo electrónico en las instalaciones que maneja algunas cosas heredadas, así que vamos a añadir su bloque de IP también. 301 Moved utiliza el mecanismo «IP4» para definir el bloque IP que posee-198.51.100.0/24 (192.51.100.0-254).

Utilice SPF Surveyor de Dmarcian para ver sus registros SPF.

Paso tres: Agregue direcciones IPv4 individuales por sí solas y bloques de red en notación de enrutamiento entre dominios sin clase (CIDR). 198.51.100.0 para una única dirección IP (no necesita un /32) y 198.51.100.0/24 para subredes.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Añadir la antigua puerta de enlace de correo electrónico garantizará que el correo electrónico saliente de la puerta de enlace esté autorizado por SPF.

Los mecanismos anteriores son los más utilizados, pero hay ocho en total -incluyendo los raros y los obsoletos. Estos mecanismos sólo definen el ámbito de la coincidencia, no las acciones en sí.

Los calificadores de la siguiente sección son donde se pueden definir PASS, SOFTFAIL y FAIL-una coincidencia resultaría en una de las tres acciones (PASS, SOFTFAIL y FAIL) que se activan.

• ALL: Coincide con cualquier cosa que no esté ya definida por otro mecanismo, coincidirá con el mecanismo all
• A: Si el nombre de dominio tiene un registro de dirección (A o AAAA) que puede resolverse a la dirección del remitente, coincidirá.
• IP4: Si el remitente está en un rango de direcciones IPv4 determinado, coincidirá.
• IP6: Si el remitente está en un rango de direcciones IPv6 determinado, coincidirá.
• MX: Si el nombre de dominio tiene un registro MX que resuelve a la dirección del remitente, coincidirá (es decir, el correo proviene de uno de los servidores de correo entrante del dominio).
• PTR: Si el nombre de dominio (registro PTR) para la dirección del cliente está en el dominio dado y ese nombre de dominio resuelve a la dirección del cliente (DNS inverso confirmado hacia adelante), coincidirá. Este mecanismo es obsoleto y ya no debería utilizarse.
• EXISTE: Si el nombre de dominio dado resuelve a cualquier dirección, coincidirá (sin importar la dirección a la que resuelva). Esto se utiliza raramente. Junto con el lenguaje de macros SPF, ofrece coincidencias más complejas como las consultas DNSBL.
• INCLUDE: Si la política incluida (un nombre inapropiado) pasa la prueba este mecanismo coincide. Esto se utiliza normalmente para incluir políticas de más de un ISP.

Los siguientes son los calificadores. Hay un millón de maneras de combinarlos con una lista negra y/o un modelo de lista blanca, pero para nuestros propósitos aquí, vamos a incluir sólo los tres mecanismos de búsqueda que mencionamos anteriormente con un único calificador al final para hacer una lista blanca. Nuestros cuatro calificadores son:

• + para un resultado PASS. Esto puede omitirse; por ejemplo, +mx es lo mismo que mx.
• ? para un resultado NEUTRAL interpretado como NONE (sin política).
• ~ (tilde) para SOFTFAIL, una ayuda de depuración entre NEUTRAL y FAIL. Normalmente, los mensajes que devuelven un SOFTFAIL se aceptan pero se etiquetan.
• – (menos) para FAIL, el correo debe ser rechazado (ver más abajo).

Paso cuatro: Aplicar la política SOFTFAIL.

Por ahora, 301 Moved utiliza la tilde para SOFTFAIL. Al utilizar la tilde, todo el correo que no coincida con Google, Zendesk o el bloque de IP mencionado sería SOFTFAIL. El correo se seguirá entregando, pero es probable que se envíe a la carpeta de Spam o Junk. Sin embargo, esto depende totalmente del servidor de correo del destinatario. No está definido por ningún estándar.

Un «-» (menos) en esta situación, fallaría (y probablemente rebotaría) el correo no coincidente por completo. Puede activar esto una vez que empiece a tener más visibilidad en su correo saliente (espere a DMARC), y una vez que se sienta más cómodo con su infraestructura de correo.

SPF es genial porque no hay ninguna modificación de los propios servidores de correo. Las cabeceras siguen siendo las mismas. Sólo un simple registro TXT (el tipo de registro SPF real, dedicado, nunca fue tan popular y ahora es obsoleto) y usted puede instruir a la mayoría de los servidores de correo en el mundo que debe estar mostrando su nombre alrededor.

Al final del día, el servidor SMTP receptor comprueba la IP del remitente contra su registro SPF que consultó, entonces aplica la política basada en sus instrucciones. En otras palabras, usted se autoriza a sí mismo, y a sus proveedores, a enviar correo (en su mayoría) de confianza porque está publicando una lista de control de acceso (ACL) al público.

Sin embargo, los mensajes aún pueden ser modificados en tránsito, y los falsificadores y phishers astutos pueden escabullirse del SPF de algunas maneras interesantes (tal vez un tema para otro día). Es SMTP: el TLS de extremo a extremo no está garantizado, por lo que siempre debemos asumir que se trata de texto claro. Los mensajes pueden ser manipulados o falsificados.

Pero entra en escena a la derecha…

Implementando el Correo Identificado con Clave de Dominio

Cuando se envía el correo, 301Moved.com firma (sin cifrar) el correo con la clave privada. A partir de ahora, cualquier modificación del mensaje, incluyendo el cuerpo, las cabeceras o los archivos adjuntos, romperá la firma y hará que el mensaje no sea válido. De nuevo, nos fijamos en Google, utilizando su artículo Autenticar el correo electrónico con DKIM

Paso cinco: Añade la clave pública a tu registro DNS.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Cada registro DKIM tiene un prefijo selector único, lo que significa que podemos publicar más de uno. En lugar de combinarlos en un solo registro, como hacíamos con SPF, podemos utilizar selectores únicos y publicar tantas claves públicas como necesitemos. Esto nos permite añadir un gran número de servidores autorizados DKIM sin ningún límite superior.

Verás que el prefijo anterior es «google», el predeterminado que utiliza Google Apps al generar un registro DKIM para que lo publiques. Puedes cambiar esto en Google, y en la mayoría de las otras configuraciones, así que si quisieras el prefijo «dkimawesome», no hay nada que te lo impida.

Algunos proveedores de la nube lo hacen de manera diferente. En lugar de generar pares de claves únicas para cada inquilino de la nube, firman todo el correo saliente para todos los dominios con la misma clave, mientras que te hacen publicar un nombre canónico (CNAME) en su lugar para su clave.

Zendesk hace esto, nosotros CNAME dos claves diferentes en nuestro DNS a su DNS. Zendesk tiene un gran artículo de ayuda- Firmar digitalmente su correo electrónico con DKIM o DMARC (Plus y Enterprise)

Paso seis (si es aplicable): CNAME las claves en su DNS a su DNS. Cualquier consulta DNS que busque zendesk1._domainkey.301Moved.com será redirigida por su DNS a zendesk1._domainkey.zendesk.com. Zendesk entonces sirve las claves DKIM directamente.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Podemos ver cómo se ve esto para otros servidores usando la herramienta nslookup (para Unix o Windows) localmente.

No todos los remitentes salientes soportan DKIM. Google Apps obviamente lo hace, pero sus servidores de correo heredados pueden no hacerlo.

Implementación de la autenticación, notificación y conformidad de mensajes basada en el dominio

DMARC, o autenticación, notificación y conformidad de mensajes basada en el dominio, es la última herramienta que tenemos para combatir el correo electrónico malicioso. Para los servidores de correo que escuchan, DMARC, retransmite cómo tratar SPF y DKIM, así como la forma de informar a usted, dándole una visibilidad muy necesaria en sus tasas de entrega y el cumplimiento de los registros.

Y sí, DMARC es otro registro TXT.

Paso siete: Configure una política DMARC, identifique la dirección mailto, configure el modo de alineación e identifique el porcentaje de mensajes a los que se debe aplicar la política (no se preocupe, esto es más sencillo de lo que parece).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

La política anterior se designa como p=none. No estamos modificando el flujo de correo en absoluto todavía-simplemente configurando la política y sus informes pertinentes. La dirección a la que se enviarán los informes XML del estado de DMARC se designa con rua=.

Los servidores de correo receptores enviarán archivos adjuntos XML que muestran cómo los mensajes de -y los que dicen ser de- su dominio se comparan con el guante de SPF, DKIM y DMARC que imponen la mayoría de los servidores de correo modernos.

Estos informes muestran, por sobre, si SPF pasó, falló o falló suavemente. Muestran si DKIM falló, falló la alineación o tuvo éxito, y cómo se aplicaron las políticas anteriores.

Por último, estos informes muestran la disposición final de entrega del mensaje. Existen excelentes herramientas que le ayudarán a analizarlos. Incluso si no está aplicando políticas a los mensajes, es como el cortafuegos, el DNS y los registros IDS/IPS: siempre es bueno tener algo que pueda revisar.

El adkim=r especifica el modo de alineación DKIM relajado, «r» es para relajado y «s» es para estricto. El modo relajado permite que los dominios DKIM d= autentificados dentro de un dominio organizativo común en la dirección de la cabecera de correo-From: PASEN la comprobación DMARC. El modo estricto requiere una coincidencia perfecta entre el dominio DKIM d= y la dirección del encabezado-From de un correo electrónico. Piense en subdominios, si los utiliza.

aspf=r hace exactamente lo mismo, excepto para las comprobaciones SPF.

El pct=100 es el porcentaje de mensajes que realmente se tratan según la política DKIM. Elegido al azar, el servidor de correo receptor aplicará la política a este porcentaje de mensajes de su dominio. Por ahora usamos 100 porque no estamos aplicando una política, todavía.

Antes de aplicar una política, la limitaremos a cinco para que sólo uno de cada 20 mensajes tenga política aplicada, ya que ponemos el indicador de política p= en cuarentena o rechazo. De esta forma, si la fastidiamos totalmente, el 95% de nuestro correo electrónico seguirá siendo entregado, en lugar del 0% entregado si empezamos con pct=100.

Los mensajes que fallan la comprobación DMARC, o sus modos de alineación adkim= y aspf= que configuramos arriba son entonces rebotados suavemente, como arriba, para una política de cuarentena, o rebotados completamente cuando se establece en rechazar.

Es muy importante tener en cuenta que DMARC PASARÁ el mensaje si SPF o DKIM pasan, y sólo FALLARÁ el mensaje si tanto SPF como DKIM FALLAN. De este modo, los mensajes con SPF y DKIM pueden pasar el DMARC, pero los mensajes sin SPF/DKIM siempre fallarán. Esto es una gran noticia si tiene sistemas de correo que sólo soportan SPF, o sólo DKIM.

Use el Inspector DMARC de Dmarcian para ver sus registros DMARC.

Dmarcian es una herramienta de pago que te permite gestionar tus informes DMARC fácilmente, hay muchas otras, pero Dmarcian resulta ser mi favorita.

Actualización: Hemos recibido unos cuantos correos electrónicos (¡que cumplen con DMARC!) preguntando por la política de subdominio sp=none. Con una política que incluya sp=none no estás especificando una política DMARC para ningún subdominio. Esto se hace manualmente configurando un registro DMARC apropiado para cada subdominio específico o incluido en el registro DMARC principal con un sp=quarantine o sp=reject.

Configuración mínima

Si quieres probar esto, te recomiendo que empieces muy abierto y te mantengas simple hasta que tengas suficientes informes DMARC para empezar a aplicar algo.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Define los grandes proveedores con un «include:» y cualquier bloque de IP desde el que puedas enviar correo con un «IP4 «o «IP6». Utilice «MX» para autorizar sus servidores de correo entrante. Y a menos que envíe el correo directamente desde el mismo buzón/servidor que aloja su sitio web (mala, mala práctica por cierto) puede omitir el mecanismo «A» que se mencionó anteriormente. El «?» no aplica ninguna política a tus mensajes, pero hace que tu registro SPF salga a la luz para que DMARC pueda reconocerlo.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Consigue el selector correcto, «google» en este caso, y la clave correcta. Recuerda que puedes publicar más de una.

Nota: Por favor, no publiques esta clave real o podré firmar tu correo con DKIM.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Para DMARC, no tenemos ninguna política aplicada, estamos en modo relajado, pero estamos pidiendo que los informes XML se envíen a un buzón al que podamos acceder. A partir de ahí, DMARC nos da una respuesta bastante rápida (no en tiempo real) sobre cómo podemos reforzar las diferentes políticas en los tres registros.

Pero espera, ¿qué pasa con TLS?

La seguridad de la capa de transporte, o TLS, no forma parte del estándar DMARC, y no es un registro DNS.

En cambio, TLS es sólo una capa de sockets seguros (SSL) adulta que los servidores de correo pueden utilizar para enviar mensajes entre sí a través de conexiones públicas. Es SMTP envuelto en TLS, al igual que se pueden hacer muchas otras cosas dentro/sobre TLS-SNMP sobre TLS y FTP sobre TLS son ejemplos comunes. TLS sólo encripta los mensajes en tránsito, no en reposo.

Si enviamos un mensaje firmado por DKIM a través de TLS, está firmado durante toda su vida, pero sólo encriptado mientras salta de tus Google Apps a su Cisco Ironport, o donde sea que tu correo transite. TLS ciertamente no protege los mensajes en reposo, aunque también se utiliza para su sesión HTTPS:// a webmail como usted está leyendo ese mismo mensaje, pero de nuevo, eso es en tránsito.

TLS es algo que usted debe utilizar siempre que sea posible, pero también estar listo para hablar en texto claro a otros sistemas de correo público. Incluso en 2015, algunos servidores de correo no admiten STARTTLS (jerga de los servidores para iniciar el apretón de manos TLS).

Puedes forzar el uso de TLS con ciertos dominios externos en Google Apps con un simple cambio de configuración. Es bueno activarlo para las empresas externas asociadas, los socios y otras organizaciones, pero sólo aplica TLS una vez que estés seguro de que es fiable y compatible con todos los servidores de correo de ese dominio específico.

La importancia de la seguridad del correo electrónico y de evitar el fraude del remitente

Independientemente de si eres un administrador de TI veterano o acabas de empezar, estos tres estándares tienen la misma importancia. Es cierto que lo que hace cada una de ellas y cómo funcionan juntas puede ser un poco confuso, pero su aplicación es relativamente sencilla y los beneficios merecen la pena.