Dando pelea al SPAM: Sender Policy Framework (SPF)
Cuando realicé mi anterior artículo sobre técnicas antispam no conocía una técnica muy interesante y bastante usada actualmente, la cual es Sender Policy Framework (SPF).
SPF es un sistema de validación de e-mail que permite lidiar contra los e-mails que falsifican la dirección de origen, algo muy común entre los spammers. Esto es, con esta técnica podemos verificar que un e-mail que dice venir de @gmail.com, viene realmente de un servidor de gmail y no de un falsificador.


Algo de Background (SMTP)

Para entender cómo es posible que alguien falsifique una dirección de e-mail, necesito que conozcan un poco del protocolo SMTP. SMTP (Simple Mail Transfer Protocol) es el protocolo encargado de transmitir los e-mails entre servidores. Cuando un usuario desea enviar un e-mail, éste se conecta, ya sea directamente o por interfaz web, a un servidor SMTP y provee sus datos así como el cuerpo del mail.
El protocolo SMTP es simple (le queda bien su nombre) y al estar basado en texto podemos utilizarlo con telnet o netcat conectándonos directamente.
Los datos básicos para enviar un e-mail son la dirección electrónica de origen, la de destino, y el cuerpo del e-mail. Debido a que todos estos campos pueden ser entrados a mano, uno puede enviar un mail colocando cualquier dirección de correo como el origen.
Un ejemplo de conexión SMTP es la siguiente:

root@bt:~# telnet mail.ejemplo.com 25
<<< 220 mail.ejemplo.com ESMTP Postfix
>>> HELO mail.ejemplo.com
<<< 250 mail.ejemplo.com
>>> MAIL FROM: godzilla@ejemplo.com
<<< 250 Ok
>>> RCPT TO: kingkong@ejemplo.com
<<< 250 Ok
>>> DATA
<<< 354 End data with .
>>> gorilon inutil, te aplasto como cucaracha
>>> .
<<< 250 Ok: queued as 12345
>>> QUIT
<<< 221 Bye

Las entradas marcadas con <<< son las respuestas del servidor, y las marcadas con >>> son los comandos ingresados por el cliente. Como se ve, primero saludamos educadamente al servidor con un HELO, luego decimos quién es el emisor del mail (MAIL FROM), a continuación entregamos la dirección del receptor (RCPT TO) y luego ponemos el cuerpo del mail, comenzando con el comando DATA y terminando con un "."
En un servidor sin configurar o mal configurado, o configurado especialmente para enviar SPAM, no existe ninguna restricción a la hora de escribir la dirección de orígen. Tranquilamente podría haber puesto support@microsoft.com o admin@gmail.com.


Cómo funciona?

Ahora si, con la pequeña introducción al protocolo SMTP ya tienen una idea de qué trata el spoofing de direcciones de e-mail, es hora de hablar sobre cómo funciona SPF.
SPF utiliza un principio muy simple para verificar direcciones, el cual es consultar al dominio de donde supuestamente viene el e-mail preguntando si la dirección IP desde donde nos llegó el mail pertenece a sus servidores.

Para aclarar un poco más las cosas, pensemos en los datos que tenemos al recibir un mail. Por un lado tenemos el "from", el "to" y los datos, todo falsificable como pudieron observar en el ejemplo anterior, pero a su vez contamos con la dirección IP del servidor que nos envía el e-mail.
Supongamos que recibimos un mail de admin@gmail.com, con IP de orígen 192.168.1.1 (dirección de ejemplo, nunca recibiremos un mail con esa direccion, al menos no de un servidor externo). El servidor que recibe el e-mail consulta al servidor de DNS de google y le pregunta "cuáles son las IPs de los servidores autorizados a enviar mails a nombre de google.com?", a lo cual google.com responderá con las IPs autorizadas. Si entre las IPs entregadas por google no figura 192.168.1.1 entonces sabremos que el mail ha sido falsificado.

En la imagen puede verse mejor cómo funciona SPF. En el paso 1 el emisor (bueno o malo) envía un e-mail a nuestro servidor. Cuando el servidor recibe el mail, éste consulta al servidor DNS del dominio al cual "supuestamente" pertenece el mail (paso 2). En el paso 3 el servidor DNS contesta con los IPs autorizados a enviar mails a nombre de su dominio. Cuando el servidor de mail recibe la respuesta del DNS, éste decide si el mail es válido o no. Si no es válido puede optar por rechazarlo o simplemente informarselo al usuario que recibe el mail.


Cómo usamos SPF?

Para poder utilizar SPF necesitamos un servidor de mails que soporte esta tecnología. Actualmente todos los servidores más conocidos traen soporte, ya sea de forma nativa o implementada como plug-in. En la página de openspf pueden encontrar una lista de los servidores que soportan SPF.
Como siempre, a Microsoft le gusta ser distinto y pasarse los estándares por las bol*s, así que decidió crear una versión propia de SPF la cual llamó Sender ID, pero el principio es exactamente el mismo.

Además del servidor con soporte SPF, si queremos que otros no puedan falsificar e-mails con nuestro nombre de dominio, necesitamos configurar una entrada en el/los servidor/es DNS autoritarios para nuestro dominio con un formato predefinido. Para no andar con problemas, se decidió utilizar el registro de tipo texto (TXT) del sistema DNS e incluir ahí los datos necesarios para el funcionamiento SPF.
Este registro contiene la versión de SPF y las IPs que tienen permitido enviar e-mails a nombre del dominio. El protocolo permite cierta flexibilidad y podemos especificar que todos los registros MX del dominio tienen permitido enviar mails, o incluir otros dominios en la lista de posibles emisores.
Para ver un ejemplo, podemos usar a google. Si hacemos un "nslookup -q=TXT google.com" veremos que nos responde con la siguiente entrada:
google.com text = "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
Este registro es bastante completo y contiene los siguientes datos:
- v=spf1 indica que utiliza la version 1 de SPF.
- include:_netblocks.google.com indica que los servidores del dominio _netblocks.google.com tienen permitido enviar e-mails a nombre de google.com
- ip4:216.73.93.70/31 ip4:216.73.93.72/31 indica que los rangos de IPv4 216.73.93.70/31 y 216.73.93.72/31 son emisores válidos para google.
- ~all nos dice que ningún servidor que no esté listado en los datos anteriores es un emisor válido.

Hay varios registros más que podemos utilizar para describir servidores válidos para el dominio, los cuales pueden ver en la página del proyecto SPF.

Si tienen problemas creando las entradas SPF en el servidor DNS no desesperen! existen wizards en páginas web diseñados para solucionarnos la vida. Por un lado contamos con el wizard de openspf y por si no les alcanza, también pueden utilizar el de Microsoft
Seguramente existen varios más, pero estos son los que primero encontre =P


Reflexión final

SPF puede ayudarnos muchísimo a limitar el SPAM que entra a nuestros servidores utilizando un mecanismo simple y ya implementado en los servidores de mails más importantes.
El mecanismo utilizado es muy similar a otros, como el de resolución inversa de IP, donde al recibir un mail de una dada IP el servidor realiza una consulta inversa (registro PTR en DNS) y resuelve si la IP pertenece al dominio de donde dice venir. Lo bueno de SPF es que es mucho más flexible, permitiendo definir distintos registros y dominios válidos.

La peor desventaja que le veo a SPF es el overhead de red. Utilizando este mecanismo tendremos que hacer una consulta DNS por cada e-mail que recibimos, lo cual, si recibimos cientos o miles de mails por día, puede resultar en alto consumo de ancho de banda y delays en la entrega de los mails.

Algo a tener en cuenta es que este sistema no elimina la posibilidad de enviar mails falsificados dentro de un mismo dominio. Si por ejemplo pepe envía un e-mail a nombre de jose@empresa.com utilizando el servidor de empresa.com, el e-mail será perfectamente válido desde el punto de vista de SPF.


Algunas Referencias
Sender Policy Framework Introduction
Sender Policy Framework (wiki)

0 comentarios:

Publicar un comentario