|
|
|
=?ISO-8859-1?Q?[Seguridad]_Configu?= |
|---|
| message from Ille Corvus on 17 Jul 2004 |
Configura SPF en tus servidores DNS
El protocolo SPF (Sender Policy Framework) es la última iniciativa
para combatir el spam. Se trata de un protocolo que mediante dos
técnicas intenta averiguar si existe una suplantación de identidad en
los mensajes recibidos, con sólo examinar sus cabeceras.
Este protocolo de seguridad abierto compara la dirección de correo
electrónico de un mensaje con una lista de todos los ordenadores
autorizados para enviar mensajes a esa dirección. Conociendo los
resultados, el servidor de correo con soporte SPF actúa de una forma u
otra, adoptando las medidas correspondientes.
El problema que radica con este protocolo es que los administradores
de sistemas han oído hablar de él, en mayor o menor medida, pero pocos
saben implementarlo, ya no tanto en sus servidores de correo, que es
la simple activación de una casilla, sino en la configuración en los
servidores de nombres de dominio, el DNS. Y todo ello es lo que vamos
a esclarecer en este artículo.
Quien más, quien menos, ha sufrido una suplantación de identidad en el
e-mail. Es muy fácil enviar un mensaje con cabecera
georgebush@whitehouse.gov y el receptor no tiene forma alguna de
verificar las credenciales, salvo si examina las propiedades de la
cabecera u obliga a sus amigos a enviar sus mensajes cifrados y
firmados. Los últimos gusanos de Internet, se apoderan de la Libreta
de direcciones de un usuario infectado y se reenvían, suplantando la
identidad del origen, de tal manera que los receptores del virus creen
estar recibiendo un mensaje de un conocido cuando se trata de una
clara suplantación de identidad.
Es así como ha nacido SPF, un protocolo abierto como lo pueda ser SMTP
y HTTP. Por su parte Microsoft está intentando imponer su norma, el
protocolo Caller-ID, muy similar al SPF, salvo en que usa para el
almacenamiento de información en los DNS código XML. El inconveniente
es que Microsoft parece haberse olvidado que los registros DNS tienen
un límite de 512 bytes en los datos almacenados. Y todos sabemos que
para escribir un simple "Hola mundo" en una página web XML se
requieren bastantes líneas de código, demasiados caracteres que hacen
de este tipo de páginas algo muy pesado.
Al margen del peso de XML en HTTP, Microsoft consciente de las
limitaciones del DNS en UDP, propone que las entradas DNS se hagan
sobre TCP, teniendo así un límite de 2.000 bytes para los datos.
Para complicar la balanza de métodos a adoptar contra el spam, se han
propuesto alternativas como el hash-cash, el cobro por recursos de
microprocesador; las listas grises de Evan Harri, relaciones de
confianza cuyo método de actuación se puede ver en
http://projects.puremagic.com/greylisting/whitepaper.html; y
DomainKeys, de Yahoo, basado en el uso de claves asimétricas, lo que
obligaría a los servidores de correo a usar claves muy similares a PGP
para validar mensajes.
Por el momento, parece que los dos frentes más popularizados son SPF y
Caller-ID. Pero como decimos, Caller-ID cuenta con más desventajas,
aparte del propio uso de XML. Por ejemplo, Caller-ID descarga un
mensaje por completo antes de decidir si es spam. SPF sólo lee la
cabecera. Esto se traduce en que con Caller-ID hay todavía más consumo
de ancho de banda y CPU, muy propio de todos los productos de
Microsoft. Además, el gigante de Redmond asegura que XML es más
adecuado para registrar la información de los DNS. Teniendo en cuenta
que las etiquetas XML ocupan más espacio que la propia información, es
absurdo pensar en que los registros MX, A, PTR y CNAME deban
codificarse a partir de ahora en XML.
Por si fuera poco, Caller-ID implica que se han de codificar las
rutinas de búsquedas DNS para la ejecución de múltiples búsquedas
recursivas. O sea, un nuevo gasto inaceptable en velocidad.
Personalmente creo que Microsoft se empeña en implantar Caller-ID,
simplemente porque contiene XML, directamente relacionado con el uso
de varias patentes de la compañía. Y aunque por el momento dice que no
cobrará a nadie por utilizar Caller-ID, la desconfianza de los
fabricantes es grande. Así que Microsoft sólo ha implementado
Caller-ID en Exchange, y ha impuesto una fórmula para compatibilizar
Caller-ID con SPF.
Registros SPF
El concepto de SPF se creó a finales de los años noventa. SPF es una
versión simplificada de la propuesta RMX de Hadmut Danisch. RMX se
basa en el artículo de Paul Vixie, Repudiating Mail-From. El artículo
de Vixie fue el resultado de una sugerencia de Jim Miller en 1998.
Para trabajar con SPF se requieren dos cosas. Primera de ellas, que el
servidor de correo desde el que se envía disponga de un registro TXT
en el servidor DNS. Y dos, que tanto el servidor de correo entrante
como el saliente operen con SPF para saber cómo actuar.
Veamos, un registro TXT en el servidor DNS:
"v=spf1 +a +mx +ptr include: ejemplo.net exp=spf-err ~all"
Y ésta es la explicación para cada uno de los parámetros de la línea
de texto anterior:
v=spf1 Es el número de versión. Hay una.
a, mx, ptr y include
Son registros. Pueden existir uno o más registros.
+ y ~ Son prefijos. Los prefijos preceden a los registros -si no se
especifican + se implica
exp Es un modificador. Pueden ser cero, uno o dos modificadores.
all Todas las IP, locales y remotas.
include Dominios externos utilizados por los remitentes de e-mails
locales, habituales cuando viajan.
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 Uno o más dominios especificados que utilizan Ip IPv4.
exists Uno o más dominios especificados que se identifican como
excepciones de las definiciones SPF.
+ La dirección ha superado el test. Ejemplo: +all
- La dirección ha suspendido el test. Ejemplo: -all
~ La dirección ha suspendido el test pero el resultado no es
definitivo. Ejemplo: ~all
? La dirección no ha superado o ha suspendido el test.
Ejemplo: ?all
Es fácil averiguar si un servidor de correo usa o no registro SPF en
su servidor DNS. Para ello basta con abrir una ventana DOS y desde el
indicador de comandos teclear:
nslookup -type=txt dominio.com
Veamos un ejemplo con un fabricante de servidores de correo que ya
implementa SPF:
nslookup -type=txt alt.com
Invito a que se haga la prueba para comprobar los resultados. Se
apreciará una línea como la de más arriba, la entrecomillada con el
registro TXT de ejemplo. Ahora invito a hacer lo mismo con el dominio
de cada uno. El resultado es probable que no incluya registro SPF y sí
los resultados del SOA, con tiempos de expiración antes del refresco
de registros y demás.
La segunda parte implica activar SPF en el servidor de correo. Tomando
como ejemplo al fabricante Alt-N y su servidor de correo MDaemon, la
activación de SPF en uno de sus menús involucra examinar los
encabezados SPF de todos los mensajes entrantes. Un encabezado típico
sería:
Received-SPF: pass (ejemplo.mail: domain of pepe@altn.com
designates 65.240.66.16 as permitted sender)
x-spf-client=MDaemon.PRO.v7.1.0.R
receiver=ejemplo.net
client-ip=65.240.66.16
envelope-from=<pepe@altn.com>
helo=smtp.altn.com
Este servidor de correo si obtiene un error 500 bloquea el mensaje
para siempre, cerrando la conexión y colocando al remitente en lista
negra. Además, añade un filtro heurístico de correo basura, por el
cual según provenga de un servidor con registro SPF en sus DNS o no, o
de un servidor de correo preparado para SPF, adoptará unos
condicionales de puntuación para SpamAssassin
http://www.spamassassin.org/index.html .
Configurando los registros SPF
¿Pero cómo se configura un registro SPF en el servidor SPF? ¿Cómo debo
hacerlo?
Pues es tan sencillo como usar la tabla de más arriba para generar una
entrada TXT. Previamente, eso sí, hay que conocer las direcciones
listadas en los registros A, las direcciones listadas en los registros
MX, las direcciones listadas en los registros PTR, direcciones IP
públicas desde las que se envíen correos SMTP, e inclusive las
direcciones IP usadas por la red del servidor de correo.
Un inciso. SPF está muy bien cuando el servidor de correo es uno
siempre, pero representa un problema añadido para aquellos que usen un
servidor de correo como gateway de otro servidor de correo, ya que
para SPF un gateway es un suplantador de identidad.
La forma más fácil de generar esta entrada TXT es utilizar el
asistente de este sitio:
http://spf.pobox.com/wizard.html
Se coloca entonces el nombre de nuestro dominio y se pulsa sobre Begin
(comenzar). Se introduce entonces la información necesaria sobre
registros A y MX. A medida que se van introduciendo datos se va
comprobando que en la parte inferior se genera la entrada TXT. En todo
momento se puede conocer lo que estamos haciendo pulsando sobre el
botón Explain (explicar). Al finalizar, la cadena resultante es la que
habrá que introducir como registro IN TXT.
Un problema añadido para la mayoría es que sus servidores DNS deberán
soportar SPF o estar preparados para introducir un registro TXT. Para
quienes utilicen su propio ISP se encontrarán con que la entrada de su
DNS apunta a un lugar como
ns.miisp.com
Si el ISP no opera con este tipo de registros todavía o representa un
problema la introducción de los mismos, podemos montar nuestro propio
servidor DNS o si no queremos malgastar una máquina, contratar los
servicios DNS. En este último caso recomiendo Securityspace
http://www.securityspace.com/dns/index.html . El registro DNS de un
dominio cuesta 10 dólares, disponiendo de 366 créditos equivalentes a
366 días para introducir el primer dominio de forma gratuita durante
el primer año. Lo mejor es que sus servidores DNS se encuentran
esparcidos por toda América y Europa.
Una vez creado el dominio, con sus correspondientes registros A, MX,
PTR y otros, aparte del correspondiente TXT para los valores SPF,
bastará con acceder a la cuenta para tu dominio (póngase como ejemplo
Nominalia, Network Solutions, Directnic, y otros) y desde allí apuntar
el DNS del dominio a:
ns1.securityspace.net
Hay un total de 7 servidores DNS en Securityspace, pudiéndose utilizar
cualquiera de ellos como respaldo (normalmente hasta tres).
Propagado el DNS en Internet, al cabo de 24 horas ya se tiene el
dominio configurado para que los servidores de correo comprueben
cabeceras SPF provenientes de nuestro servidor de correo.
Es más sencillo de lo que parece. Propongo que se comience cuanto
antes para que los administradores de sistemas pueden ir adaptando sus
sistemas para combatir el spam.
Carlos Mesa
http://www.seguridad0.com
© copyright 2004 Carlos Mesa
Este artículo puede copiarse y reproducirse libremente siempre que se
haga de forma literal, sin fines lucrativos y se adjunte esta nota.
Publicado bajo licencia libre Creative Commons
Reconocimiento-NoComercial- CompartirIgual, cuya traducción libre
puede encontrarse en la página
http://www.bufetalmeida.com/ccd.htm
|
|
