Buenas a todos, entre ofertas de viagra, alargamientos de pene, viajes a Cancún, cartas nigerianas y otras tantas variantes spamicas que surfean cada día por nuestros buzones de correo, parece más una tarde cualquiera de un programa de telecirco, que un buzón donde recibir los mensajes de correo cada día. Esta avalancha de SPAM, phising, etc. ha sido posible debido a que cuando se ideó el sistema de correo electrónico, éste no contemplaba la seguridad como una premisa, y se daba por supuesta la confianza de que los correos electrónicos llegarían de donde deberían llegar (ingenuos…)
Seguro que más de uno habréis recibido alguna vez un email en el que han suplantado la dirección del emisario. Es realmente sencillo enviar un e-mail simulando ser enviado desde por ejemplo una cuenta como jlrzapatero@lamoncloa.gob.es, y a menos que nuestro modo paranóico nos haga revisar la cabecera del email (que viendo el emisario yo al menos lo haría...), o de acostumbrarnos a enviar los mensajes firmados y cifrados, como ya os enseñamos en la cadena de artículos sobre GPG, podrían colarnos un fake por donde amargan los pepinos.
Para paliar este agujero de seguridad, hace unos años se creó el protocolo Sender Policy Framework, conocido como SPF y abierto como HTTP o SMTP. Su objetivo es identificar, a través de la dirección IP (por los registros DNS) a los servidores de correo SMTP que están autorizados para enviar correos desde un dominio concreto. Ahora hablaremos de él más en detalle, pero antes me gustaría comentar las alternativas propietarias por las que se han encaminado algunos fabricantes como Microsoft o Yahoo.
Microsoft propuso su propio protocolo para garantizar envíos seguros, al que denominó Caller-ID (implementado en Exchange). Es muy similar a SPF con la salvedad de que se basa en el estándar XML para el almacenamiento de los datos. Lo que a priori parece un pro, se convierte en un contra debido a que los registros DNS solo disponen de 512 bytes para almacenamiento, y todos sabemos que añadir etiquetas XML requiere de un mayor espacio, y por tanto en este caso, aumentan el peso de las peticiones. Por ello, Microsoft propone que las entradas DNS vayan sobre TCP.
Al otro lado del Ring tenemos a Yahoo, que propuso un sistema basado en claves asimétricas, muy semejante a PGP, al que denominó DomainKeys.
Hay algunas más, pero en este artículo no las analizaremos.
Volviendo al tema de los SPF, para que pueda funcionar este sistema son necesarias dos cosas, la primera es que el servidor emisario disponga del registro TXT en el servidor DNS y la segunda, lógicamente, que ambos servidores de correo, emisario y receptor, operen con registros SPF.
Vamos a ver un ejemplo de configuración SPF, por ejemplo, en el correo de Google. Para ello utilizaremos la herramienta nslookup (que tenéis disponible en Windows y Linux vía consola), de la que ya hemos hablado largo y tendido en nuestro libro La Biblia del Footprinting, y que integra Anubis v1.3:
C:\Users\Admin>nslookupServidor predeterminado: ***.***.216.87.static.******.esAddress: ***.***.1.65> set type=txt> google.comServidor: ***.***.216.87.static.******.esAddress: ***.***.1.65Respuesta no autoritativa:google.com text = "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
Fijaros en el registro TXT:
"v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
Como veis, se parece a lo siguiente:
"v=spf1 +a +mx +ptr include: flu-project.com exp=spf-err ~all"
Vamos a analizar cada una de las partes que podría contener:
| v=spf1 | Número de versión, que siempre será la misma ya que actualmente solo existe una. |
| a, mx, ptr y include | Los registros existentes (direcciones, correo, resolución inversa, etc.). |
| +, ~ | Prefijos que preceden a los registros |
| exp | Modificadores. |
| all | Indica todas las IPs. |
| include | Dominios externos usados por los emisores de e-mails locales. |
| a | Todas las IP del registro DNS A. |
| mx | Todos los registros A de cada registro host MX. |
| ptr | Todos los registros A de los registros host PTR. |
| ip4 | Dominios que utilizan IPv4. |
| exists | Excepciones. |
| redirect | Utiliza los registros SPF del dominio definido |
| + | La dirección ha superado el test (+all) |
| - | La dirección ha suspendido el test (-all) |
| ~ | La dirección ha suspendido el test pero el resultado no es definitivo (Digamos que aplica la política de que si no está seguro, se abra la puerta al correo, ~all) |
| ? | La dirección no ha superado el test. Ejemplo: ?all |
Como podéis ver, en el caso del correo de Google, tienen configurado SPF con ~All, lo que quiere decir que aunque suspenda un email el test, no es definitivo y puede que el correo sea aceptado (dependiendo de su contenido, como vamos a demostrar ahora). Veamos un par de ejemplos. Vamos a enviar un email a una cuenta de Gmail suplantando una cuenta de correo y añadiendo en el cuerpo del mensaje muchos enlaces y palabras como "Viagra" o "Porno", para intentar suspender el test, y por otro lado enviaremos un email suplantando una cuenta de correo, pero con un cuerpo de mensaje normal:
Mensaje con contenido poco agresivo con email suplantado, recibido correctamente en la bandeja de entrada:
Mensaje agresivo con email suplantado, recibido en la bandeja de SPAM:
Queda demostrado, que al menos en el caso de Gmail, el contenido importa ¿no?
Si analizamos el código fuente del mensaje, veremos como ambos han sido catalogados como "neutral":
Mientras que si analizamos el código fuente de un mensaje legítimo, veremos como ha sido catalogado como "pass":
En el próximo post hablaremos de como configurar el registro TXT.
Saludos!
No hay comentarios:
Publicar un comentario