SPF (Sender Policy Framework) es una especificación experimental publicada por la IETF en la RFC 4408 (abril 2006), y describe un conjunto de técnicas para evitar la utilización de dircciones de email falsas en los mensajes que circulan por la red.
Aunque creo que esto ya lo he comentado en otras ocasiones, uno de los principales problemas que hacen florecer el spam, scam, phishing, y alguna que otra atrocidad más, es la inocencia con la que fue creado el protocolo SMTP, utilizado para los envíos de mensajes de correo electrónico entre servidores. En este estándar no se establece ninguna técnica para asegurar la veracidad del remitente, por lo que cualquiera puede escribir en nombre de otro, hacerse pasar por quien desee, o simplemente inventar sobre la marcha un emisor, existente o no.
Por eso los mensajes de spam que recibimos pueden provenir incluso de personas que conocemos, pertenecientes a nuestro propio dominio, compañeros que tenemos sentados justo a nuestro lado, etc.
El SPF pretende acabar con esto, pues define un sistema de comprobación en tiempo real de la veracidad del remitente, así como del servidor desde el que se envía un mensaje, consistente, por una parte, en incluir en los registros MX de cada dominio emisor de correos una línea donde se indique la dirección IP desde la que pueden ser enviados. De esta forma, cuando otro servidor SMTP recibe un mensaje con un remitente del dominio anterior, puede consultar esos registros y comprobar si la IP desde la que está recibiendo el email está autorizada para enviarlo.
Lo vemos con un ejemplo real, por suerte (?) tengo bastantes para elegir. Hoy he recibido un correo desde la dirección finkenhoferqov0@hotmail.com aconsejándome soluciones para mis terribles problemas de erección (¿cómo se habrán enterado? :-D). Por suerte, según me indican, la mitad de los varones los sufren, el que no se consuela es porque no quiere.
Si rastreo el mensaje, veo que ha llegado a mi servidor desde la dirección IP 71.186.100.38, cuyo nombre parece ser pool-71-186-100-38.chi01.dsl-w.verizon.net. Si seguimos escarbando, podemos obtener la siguiente información de esta IP:
OrgName: Verizon Internet Services Inc.
OrgID: VRIS
Address: 1880 Campus Commons Dr
City: Reston
StateProv: VA
PostalCode: 20191
Country: US
NetRange: 71.160.0.0 - 71.191.255.255
CIDR: 71.160.0.0/11
NetName: VIS-BLOCK
Y aunque las herramientas de geoposicionamiento de direcciones IP no son el colmo de la precisión, podríamos incluso atrevernos a conjeturar dónde se encuentra el spammer, en Washington.
A la vista de estos datos, se trata de un equipo que utiliza una dirección IP dinámica, conectado a través de una DSL que, de forma voluntaria o no, está enviando spam, cual poseso, al resto del mundo. Está claro que ningún spammer decente dejaría ver todos sus datos así, por lo que, o bien se trata de un PC secuestrado (zombie), o bien toda la información que deja ver es falsa.
En cualquier caso, está claro que no se trata de Hotmail, de donde era, como recordaréis, el remitente del mensaje.
Si tanto mi servidor como Hotmail utilizaran SPF, se habría rechazado el mensaje de forma directa. Al recibir la dirección del remitente, habría acudido a los registros MX de Hotmail para averiguar si la IP desde la que se ha producido la conexión es válida para envíos @hotmail.com, y, obviamente, de esta comprobación siempre se determinaría que el emisor es inválido.
Todo esto está muy bien, personalmente creo bastante en este tipo de soluciones colaborativas y de consenso para luchar contra el spam, más incluso que en las de análisis de contenido que, como ya he comentado en posts anteriores, tienen bastantes dificultades para garantizar el filtrado correcto dada la gran variedad de trucos utilizados.
El problema es precisamente su implementación en la práctica, y eso que en el caso del SPF no es especialmente compleja, todo lo contrario. Está claro que si todos los ISP del mundo utilizaran este método, el spam, fishing y en general cualquier historia basada en la utilización de remitentes falsos tendrían los días contados... al menos en la forma en que hoy los conocemos, claro.
Hace poco, en casa de un familiar, convocado al grito de "ven a ver el ordenador que le pasa algo raro", me encontré con un panorama genial. Se trataba de un troyano (una pena, no recuerdo el nombre) descargado de algún sitio web de oscuras intenciones que se le había colado hasta el mismísimo tuétano.
"Estos malditos troyanos han secuestrado a Helena.
Visto el panorama, puse a funcionar la artillería que muy prudentemente tenía instalada la máquina: Ad-Aware, Microsoft Antispyware (beta por entonces), Norton Antivirus, y Spybot.
Nada, como si le hubiera leído algo de Homero, ni puñetera cuenta. "¡Enhorabuena, tienes un último modelo", le dije a mi pariente.
"Los griegos reunieron cien mil hombres,
Era el momento de ponerse el casco, agarrar el escudo y lanzarse al campo de batalla cual griego micénico furibundo, contra todo troyano viviente. Aunque no hay que precipitarse: lo primero, observar al enemigo.
Lo que me llamó la atención en primer lugar era que estaba bastante bien hecho, lo que que me hizo reflexionar sobre el desperdicio de habilidades de determinados individuos. Deberían dedicar su tiempo y conocimientos a creaciones más útiles y menos nocivas.
El bichillo, como es habitual, se escondía en el registro de aplicaciones de arranque, es decir, se cargaba con el sistema operativo y consistía en tres ejecutables, con nombres similares a los procesos propios de Windows (como svchost.exe, winlogon.exe, spoolsv.exe...) a los que cambiaba la denominación levemente (scvhost.exe, winlogon.dll, spoolsvc.exe...) para que pasaran desapercibidos.
Estos tres ejecutables se encontraban en el disco duro, en el directorio Windows\System32, lo cual dificultaba aún más su localización, pero lo peor de todo es que no se podían eliminar: al estar cargados en memoria, los archivos siempre se encontraban en uso. Además, funcionaban de la siguiente forma:
- se protegían entre sí: si alguno de ellos dejaba de funcionar (por ejemplo, matando el proceso), uno de los otros dos volvía a lanzarlo. Supongo que cada proceso vigilaba a los otros dos, formando así una cadena difícil de romper.
- protegían las entradas el registro del sistema mediante las cuales se lanzaban al iniciar Windows. Era curioso: tal y como las cambiaba en el registro, ellos volvían a dejarlas como estaban en pocos segundos.
- protegían la página de inicio del navegador, así como la de búsqueda. Al modificarlas ocurría como en el caso anterior, raudos acudían a restituir los valores oportunos.
- protegían la desinstalación de complementos del navegador. La criatura también se instalaba aquí, tomando el control en el momento de abrir el Internet Explorer.
"Troya tenía unos muros inexpugnables"
Durante la primera fase, realicé varios intentos de anulación básicos, que más que nada fueron útiles para poder conocer mejor a mi contendiente. De hecho, todas las características que he comentado en la lista anterior las fui descubriendo conforme intentaba anular sus funcionalidades. Digamos que durante esta fase, siempre ganó él.
"Durante el tiempo del asedio, los bandos rivales
se hostigaban continua y salvajemente"
Estaba claro que había que recurrir a herramientas más sofisticadas. Dado que que era imposible utilizar software de eliminación de engendros de este tipo puesto que era demasiado reciente y aún no existían soluciones (vacunas) específicas, opté por descargar dos magníficas herramientas de Sysinternals: Process Explorer y Autoruns. La primera de ellas permite visualizar los procesos activos en la máquina con un nivel de detalle muy superior al provisto por el Administrador de Tareas de Windows. La segunda, permite acceder de forma muy sencilla a las zonas del registro del sistema donde se definen las aplicaciones que cargan de forma automática al iniciar el sistema operativo.
Después llegué a la obvia conclusión de que la clave estaba en anular los tres procesos centrales. Si conseguía pararlos, podría quitarlos tranquilamente del registro e incluso eliminar los archivos del disco duro. Pero claro, debía parar los procesos, tarea difícil por la protección a tres bandas que tenían implementada.
Dado que el programador del invento detectaba cuándo determinado módulo dejaba de estar en memoria para volver a lanzarlo, pensé que sería una buena idea probar a suspenderlos, es decir, paralizar su ejecución. Efectivamente, era el camino hacia la solución: al suspender el proceso, éste seguía estando en memoria, y por tanto los otros dos no detectaban nada anormal. Así, una vez estaban los dos primeros congelados, el tercer módulo pudo ser matado sin oponer resistencia alguna. Y después, a matar los otros dos. Ya tenía la memoria limpia.
"Ulises tuvo una gran idea. Construir un caballo de madera,
en cuyo interior se escondían varias decenas de soldados griegos"
A partir de ahí, todo fue mucho más sencillo. Con ayuda del software Autoruns limpié el registro de entradas en las secciones oportunas, haciendo que no se intentara ejecutar nada al arrancar, eliminé el complemento cargado en Internet Explorer y, por último, hice desaparecer para siempre los archivos del disco duro.
"Una vez llegó la noche, los soldados salieron del caballo y
abrieron las puertas a sus tropas, que invadieron y saquearon la ciudad"