@isitreallysafe
Con mucha frecuencia todos recibimos correos no deseados o spam. El spam no es un fin en sí mismo, es decir, los spammers no envían grandes cantidades de email solamente por enviarlas. Los grandes riesgos que representa el spam no se deben a que se trate de correos que le sean enviados a uno sin su permiso o que puedan llegar a ser muchos y consuman recursos de procesamiento, ancho de banda y memoria (que lo hacen, obviamente).
El spam es un medio para un fin. Un medio para una variedad de cosas malas. Como decimos los abogados, el spam es parte del íter criminis que los delincuentes siguen para llevar a término sus fechorías. ¿Para qué enviar mensajes de spam? Depende de la campaña que los delincuentes estén adelantando (espere una próxima nota sobre actividades delictivas asociadas al envío de spam): para inyectarle código malicioso a su dispositivo y reclutarlo en una botnet, para intentar defraudarlo a usted, para robar su información personal, en fin, posibilidades hay en cantidades.
En el post anterior, en el que describí un ataque hipotético de spear phishing, indiqué algunas medidas que, de ser bien implementadas, ayudan a reducir el spam y el phishing. Una de estas medidas consiste en la creación de un récord de Sender Policy Framework -o SPF- en el archivo de zona del nombre de dominio de su compañía.
Incluir registros de SPF en los archivos de zona de los dominios es un acto de buena ciudadanía digital. Hacerlo no va a protegerlo a usted ni a su empresa, pero sí al resto de la humanidad. Cuando yo recibo un email que fue aparentemente enviado por mi banco (cualquier_nombre@mibancoejemplo.com), mi aplicación de correo electrónico (o el servicio de correo que utilizo, como Gmail o Outlook) busca en el archivo de zona de mi banco las direcciones IP autorizadas para enviar email usando el dominio mibancoejemplo.com . Es decir, gracias a la utilización de recursos del Sistema de Nombres de Dominio (DNS, por sus siglas en inglés), SPF es capaz de prevenir la recepción de emails potencialmente dañinos.
Si el email vino efectivamente de una de las direcciones IP incluidas en el registro de SPF del dominio de mi banco, entonces el mensaje pasará el test de SPF. Si no vino de una de esas direcciones, se considerará entonces que es spam.
Si mi banco tiene interés por disminuir el riesgo de que sus clientes y los demás usuarios de Internet caigan víctimas de campañas de phishing que usen sus nombres de dominio, debe incluir un registro de SPF en el archivo de zona de los dominios que use para enviar email, de manera que todo el DNS sepa cuáles son las únicas direcciones IP autorizadas para enviar email a su nombre.
Adicionalmente, el banco deberá incluir el registro de forma correcta. Con frecuencia se pueden ver registros que son demasiado extensos, que incluyen cientos o incluso miles de direcciones IP de servidores administrados por terceros que también ofrecen servicios de email a muchas otras personas y empresas en muchos países. Registros de SPF como estos son inútiles en la práctica porque cualquier tercero que use legítimamente esas mismas direcciones IP para enviar email puede decidir enviar mensajes usando el dominio del banco. Si lo hace, esos emails pasarán el test de SPF a pesar de no haber sido enviados por el banco directamente.
Las organizaciones grandes que deciden incluir un registro de SPF para sus dominios, buscando disminuir el riesgo que enfrentan sus clientes y los usuarios en general, deben –cuando menos– pensar seriamente en estos dos aspectos:
– Limitar la cantidad de proveedores que pueden enviar email usando su dominio. En las empresas grandes con frecuencia cada departamento puede contratar a un proveedor diferente para el envío de newsletters o comunicaciones corporativas o realización de encuestas, todo a través del envío de mensajes que aparentan haber sido enviados por la compañía misma. Si son muchos proveedores, el registro de SPF será muy extenso y perderá su utilidad por la razón explicada arriba.
– Exigir contractualmente a esos proveedores que pueden enviar email usando el dominio de la compañía, que limiten la cantidad de direcciones IP autorizadas para hacerlo. En un mundo ideal debería ser una sola dirección IP por proveedor.
Como conclusión, recuerde que los protocolos técnicos sobre los que funciona Internet no fueron diseñados pensando en la seguridad. SMTP no fue la excepción. Incluir registros de SPF para los dominios es casi un acto de responsabilidad social, especialmente si se trata de entidades del sector público, del sector financiero o de cualquier otro sector que sea utilizado como cubierta por los delincuentes para dirigir campañas contra los usuarios de buena fe.
Piénselo por un momento y tome la decisión de incluir registros de SPF para su nombre de dominio. Así ayudará a que su nombre no sea utilizado por los delincuentes para dañar a los demás.
Saludos desde California,
Carlos S. Álvarez
blogladooscuro @ gmail.com
@isitreallysafe
Información adicional
Sobre los archivos de zona
El archivo de zona de un nombre de dominio es un archivo de texto que describe los recursos asociados al nombre y los mapea hacia los servidores correspondientes.
El archivo de zona está compuesto por ‘resource records’ (o RRs), que son los elementos básicos del archivo y que indican, por ejemplo, la dirección IP del servidor de DNS o del servidor de correo y el tiempo de validez (ttl o tiempo de vida) de cada uno de los RRs. Existen varias clases de RRs: por ejemplo, ‘A’ para direcciones IPv4, ‘AAAA’ para direcciones IPv6 y ‘MX’ para servidores de correo, entre otras.
Ejemplos de RRs en un archivo de zona
El A record de www.icann.org es hoy el siguiente:
www.icann.org. 21591 IN CNAME www.vip.icann.org.
www.vip.icann.org. 21 IN A 192.0.32.7
Es decir, la dirección IP a la que mi navegador debe apuntar para conectarse con el servidor en el que está alojado www.icann.org es 192.0.32.7 (el valor CNAME indica que es la misma dirección de www.vip.icann.org).
Uno de los MX records asociados a icann.org es hoy el siguiente:
icann.org. 599 IN MX 10 pechora1.icann.org.
Es decir, pechora1.icann.org es el nombre de uno de los servidores de correo electrónico asociados al dominio.
Existe otra clase de RRs denominada TXT. A diferencia de los demás RRs, los registros TXT no tienen que seguir un formato predefinido y pueden contener información arbitraria. Estos son usados para incluir los registros del SPF. Lo que estos hacen es informarle al mundo cuáles son los únicos servidores de correo autorizados para enviar email usando su nombre de dominio.
Para entender un poco mejor esto vaya a este link, escriba un dominio cualquiera y presione la tecla verde que dice ‘Survey the Domain’. Para facilitarle las cosas, en este link encontrará de forma directa el registro de SPF de eltiempo.com y en este otro link encontrará de forma directa el registro de SPF de semana.com .
SMTP, campos falsificados
En un email que sea spam, los campos MAIL FROM:, RCPT TO: y FROM: se falsifican para que parezca que los mensajes han sido enviados por alguien más. Los dos primeros no son visibles al usuario y corresponden más al diálogo entre cliente y servidor que a información inmediatamente útil a las personas. El campo FROM: del encabezado sí es visible para el usuario. Esta gráfica lo explica un poco mejor. Los tres campos resaltados en rosado son los usualmente falsificados:
Esta es una muestra visual muy simple de la conversación entre el cliente de correo y el servidor.
– En el primer paso (1), el cliente (que puede ser un servidor actuando como cliente al ofrecer un mensaje a otro servidor) le dice al servidor que quiere enviar un mensaje desde el usuario ‘abcde’ que está en el dominio ‘qwerty.com’.
– El servidor le responde (2) diciéndole “adelante, bien pueda enviar el mensaje”.
– El cliente continúa entonces (3): “Si alguien va a responder a este mensaje por favor envíe las respuestas al usuario ‘ladron’, que está en el dominio ‘dametuclave.com’. El servidor responde con un ‘OK’ (4).
– El cliente añade (5): “estoy listo para mandarle todo el mensaje”.
– El servidor pide al cliente que envíe el mensaje como tal (6).
– El cliente empieza la transmisión del mensaje, iniciando con el encabezado.
– Después de enviar la totalidad del mensaje, el cliente envía al servidor una línea solamente con un punto, que indica el final de la transmisión (15).
Comentarios