poolacko
Miembro
Haciendo el hardening de mi servidor web me tope con esto, que puede servirle a todos los que tengan su propio servidor web, a la hora de enviar correos.
Espero que les sirva
Configurando SPF en tus 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:
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.
Fuente: Seguridad0
Espero que les sirva
Configurando SPF en tus 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:
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.
Fuente: Seguridad0
