Seguridad en el correo electrónico (SPF)
Quien más y quien menos ha sufrido en algún momento los problemas de la inseguridad del correo electrónico: mail spoofing, SPAM, phishing, malware, troyanos, etc.
El correo electrónico, pensado originalmente como sistema de comunicación, no tenía contemplados aspectos de seguridad en su funcionamiento ni debía verificar que el origen del mensaje fuera correcto, es por eso, que se ha convertido en uno de los mayores quebraderos de cabeza para las empresas y un punto débil para la seguridad.
Desde hace algún tiempo, se creó Sender Policy Framework (SPF), o lo que es lo mismo, un sistema de protección a implementar en los servidores de correo electrónico, contra la falsificación de las direcciones de envío. Normalmente, los creadores de SPAM, Phising y malware, intentan esconder y ocultar la dirección de correo con la que envían sus ataques para simular que provienen de una fuente confiable para la víctima y conseguir que el ataque tenga más probabilidades de éxito.
SPF se encarga de identificar, por su dirección IP, a través de los registros del DNS, a los servidores de correo SMTP autorizados para el envío de los mensajes de un dominio concreto. Esta comprobación la hace el sistema que recibe el mensaje de correo electrónico en cuestión. Actualmente, la mayoría de empresas, como se verá posteriormente, no tienen el registro SPF habilitado en sus servidores de correo o, simplemente, no lo validan y ni se mira que la dirección IP inversa de quien envía el mensaje sea realmente del servidor de correo legítimo que dice ser.
El funcionamiento de SPF es relativamente sencillo, teniendo en cuenta que ambos sistemas, el que envía correo y el que lo recibe (MTA), deben tener implementado SPF para saber cómo operar:
1) El propietario del nombre de dominio, debe modificar la configuración del DNS del dominio para añadir las direcciones IP de las máquinas utilizadas para enviar correo.
Para añadir el registro SPF con un servidor de nombres (DNS) BIND es necesario modificar el fichero de zonas de la siguiente forma:hacktimes.com. IN TXT "v=spf1 mx:hacktimes.com -all"
En tinydns (djbdns) el cambio sería de la siguiente manera:'hacktimes.com:v=spf1 mx\072hacktimes.com -all:3600
Y con un servidor de DNS de Windows ser haría tal y como se indica en la siguiente dirección:
http://www.michaelbrumm.com/spfwindowsdns/
En el ejemplo, se indica un registro de texto (IN TXT) para el dominio hacktimes.com con la siguiente descripción SPF:
v= define la versión usada de SPF (versión 1). Sólo existe una hasta este momento.
mx hacktimes.com tiene un servidor MX y se permite enviar correo electrónico desde hacktimes.com
~all indica que no hay más servidores a los que se les permite enviar correo para el dominio hacktimes.com en este caso.
2) El servidor que recibe el correo o sistema destinatario, es el que realiza el proceso de verificación y comprueba los registros DNS del remitente. Si la dirección IP del servidor con el que ha conectado para recibir el correo encaja con la especificación de direcciones que se han permitido en el registro SPF, se añade una cabecera al mensaje con el nombre "Received-SPF" que indica el resultado correcto de la comprobación, por ejemplo:Received-SPF: pass (domain of hacktimes@gmail.com designates 64.233.182.193 as permitted sender)
Existen asistentes para configurar correctamente los registros SPF de cualquier servidor de correo a modo de plantilla en las siguientes direcciones:
http://old.openspf.org/wizard.html
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx
En la siguiente página se puede comprobar la configuración de los registros SPF:
http://tools.bevhost.com/cgi-bin/dnslookup
aunque también es fácil hacerlo manualmente tal y como se verá a continuación con herramientas como nslookup, dig y demás.
Yahoo y Microsoft no utilizan SPF, han tirado por soluciones propietarias que es preciso licenciar y presentan ciertas incompatibilidades con la licencia GPL, además, son más complejas que el uso de SPF. En concreto Yahoo utiliza DomainKeys basado en el uso de claves asimétricas en los servidores de correo al estilo del tan famoso PGP, Microsoft por su parte, utiliza Sender ID (anteriormente llamado Caller ID) que utiliza código XML en los DNS para almacenar información.
CASO PRÁCTICO
a) GMAIL: la configuración SPF es la siguiente, que indica que el este registro SPF substituye al actual:
nslookup
Servidor predeterminado: 33.Red-196-58-0.staticIP.rima-tde.net
Address: 196.58.0.33
> set type=txt
> gmail.com
Respuesta no autoritativa:
gmail.com text =
"v=spf1 redirect=_spf.google.com"
b) CAJAMADRID: únicamente se permite enviar correo desde cualquier sistema cuya dirección IP esté comprendida entre el rango 213.164.164.1-254
> cajamadrid.es
cajamadrid.es text =
"v=spf1 ip4:213.164.164.0/24 -all"
c) HOTMAIL: Microsoft al final utiliza también SPF configurando diversas opciones para que, si la primera vez no se obtiene un mensaje de error o de éxito (PASS), se pasa a la siguiente directiva implementada así hasta el cuarto servidor (spf-d.hotmail.com). Esto puede suponer un riesgo ya que si por cualquier motivo no se dispone de un registro SPF válido o se produce cualquier error en los servidores origen, el resultado de error es permanente y no se recibe correo alguno con origen dichos servidores de Hotmail.
hotmail.com text =
"v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all"
d) YAHOO, como se ha visto no utilizan SPF sino su tecnología DomainKeys para luchar contra el SPAM:
yahoo.com
primary name server = ns1.yahoo.com
responsible mail addr = hostmaster.yahoo-inc.com
serial = 2010022607
refresh = 3600 (1 hour)
retry = 300 (5 mins)
expire = 1814400 (21 days)
default TTL = 600 (10 mins)
e) BSCH, DB, BANESTO: ni Banco Santander, ni Banesto, ni el Deutsche Bank implementan SPF:
bancosantander.es has no TXT record
santander.com has no TXT record
db.com has no TXT record
banesto.es has no TXT record
A pesar de las mejoras que supone la extensión SPF para un servidor de correo, aún hay numerosas entidades bancarias y empresas que se supone que tienen que luchar contra el fraude y el phising y que ni siquiera tienen activado el registro SPF en sus DNS. SPF no elimina el SPAM pero ayuda a tener perfectamente identificado su origen lo que, combinado con listas negras, sí que puede reducir sensiblemente la recepción de basura en los buzones.
Para más información acerca de SPF, Sender ID y su funcionamiento:
http://www.openspf.org
http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx
Comentarios
d3m4s1@d0v1v0, acabo de ver tu artículo y tu blog, no lo conocía, muy interesante, me lo guardo en los bookmarks. Estoy contigo, no entiendo como sobretodo los bancos, no tienen ya implementado SPF ya que podría ayudar enormemente a reducir el SPAM.
Muy completo el artículo. En mi blog hablé hace un tiempo sobre SPF (http://itfreekzone.blogspot.com/2009/11/dando-pelea-al-spam-sender-policy.html). Me parece una solución interesante, creo que podría filtrar mucho SPAM si lo implementasen todos los servers.
Añadir comentario