Open Relay en Servidores de Correo: Estudio de la realidad chilena

Open Relay en Servidores de Correo: Estudio de la realidad chilena
(Informe Técnico CLCERT-2002-01)
Marcos Kiwi
Sebastián Peña†
Eduardo Rodrı́guez S.‡
Resumen
Este informe tiene por objeto monitorear y cuantificar aspectos que directa o indirectamente conciernen la seguridad y disponibilidad de los sistemas en el dominio .cl. Especı́ficamente la permeabilidad que presentan los
servidores de correo del dominio .cl a ser usados como medio de transporte para correo indeseado (open relay)
Del total de servidores que se estableció estaban operando, un 9.5% permiten relay.
1 Introducción
Hoy en dı́a, el correo no solicitado circula por Internet provocando una serie de problemas en los servidores que
transmiten esta información, y en los que la reciben. Muchas personas que combaten esta práctica señalan que ella
se reducirı́a con una configuración apropiada de los servidores de correo electrónico que entre otras cosas no permita
enviar e-mails que no estén relacionados a la propia organización (relay).
Para despachar un correo electrónico, se usa un programa de servidor de correo que implementa el protocolo
SMTP[1]. Sin embargo, algunos están configurados para permitir el envı́o de correo electrónico desde cualquier
origen y hacia cualquier destino, lo que puede ser usado para despachar correos en forma no autorizada.
Bases de datos existentes [2] identifican, a Febrero del 2002, 273 servidores SMTP en el dominio .cl que permiten relay. Sin embargo, no se indica el universo de servidores considerado. Un estudio basado en una muestra
aleatoria de servidores obtenidos de las listas de correo del Internet Mail Consortium señala que, a Enero del 2001,
aproximadamente un 6.4% de servidores SMTP permiten relay [3]. El estudio no indica la composición de la lista de
servidores de la que se extrajo la muestra.
Hasta ahora, no existı́an datos conocidos de la cantidad de servidores de correo electrónico que brindan servicios
a los computadores bajo el dominio .cl, que permiten hacer relay. A este respecto, es oportuno señalar que algunos
dominios en Chile usan servidores de correo ubicados geográficamente en otros paı́ses, sin embargo, serán considerados en este estudio. Asimismo, existen en Chile servidores bajo dominios diferentes a .cl (por ejemplo .com o .net),
ellos no han sido considerados en este estudio
No es el propósito de este documento discutir la legitimidad, conveniencia y/o aspectos éticos asociados a este tipo
de estudios. Al lector interesado en estos aspectos le recomendamos leer las respuestas a las preguntas frecuentes [4]
y el anuncio público de la eventual realización de este estudio [5].
2 Metodologı́a usada para la confección de lista de hosts revisados
Para construir la lista de servidores de correo, se recolectó el listado total de dominios .cl a través de una consulta al
DNS (Domain Name System) primario del dominio .cl, ubicado en NIC Chile. Esta organización tiene a su cargo la
asignación de estos dominios en Chile.
A continuación, se utilizó un programa, que a través de consultas al DNS, recorrı́a cada dominio en forma descendente por sus subdominios, consultando los records MX (mail exchangers) definidos para cada dominio o subdominio
definido en ese servidor.
Dept. Ing. Matemática, Ctr. de Modelamiento Matemático, UMR 2071 U. Chile–CNRS, [email protected] . Agradece el apoyo de Fondap
en Matemáticas Aplicadas, 2000–2005.
† Rezebra Technologies, [email protected] .
‡ Laboratorio de Criptografı́a Aplicada y Seguridad, U. Chile, [email protected] .
1
Cada dominio tiene la posibilidad de definir uno o más records MX, que serán los servidores que recibirán el
correo para ese dominio, y lo distribuirán internamente. Un servidor DNS admite como record MX válido el nombre
de un host[6] y no su dirección IP.
Por lo tanto, el listado de servidores ya obtenido, se depuró a través de dos procesos consecutivos, primero se
eliminaron los hosts duplicados (un record MX puede servir a varios dominios). En segundo lugar, se validó la
existencia de un número IP para cada uno de ellos, eliminándose a quienes no lo tenı́an.
3 Pruebas
Las pruebas se realizaron durante Enero del 2002. El programa usado para las pruebas intenta reproducir el diálogo
que usarı́a un generador de correo indeseado para enviar mensajes a través del servidor que se está testeando.
Este recoge la información de las respuestas generadas por el servidor SMTP ante ciertos requerimientos simples
de correo electrónico. Especı́ficamente, el programa intenta enviar un correo de prueba con el siguiente formato:
From: [email protected]
To: [email protected]
Subject: [marca][servidor SMTP] - Prueba de relay
Esta es una prueba de la seguridad del servidor de correos
Host:[servidor SMTP].
Si este mensaje llega a destino significa que [servidor SMTP] es inseguro
Timestamp:[timestamp]
El dominio PRUEBA.com.cl es ficticio, y se utiliza sólo para indicar el servidor usado para realizar las pruebas. La
dirección electrónica [email protected] también ha sido cambiada en este texto, pero en las pruebas se usó
una dirección válida.
La lı́nea Timestamp:[timestamp] coloca una marca de tiempo en el correo despachado, que puede usarse tanto
como identificación como para determinar el tiempo que tarda el correo en hacer su camino.[servidor SMTP] es el
nombre del servidor que se está probando, y [marca] es una marca interna usada para identificación.
A continuación, describiremos la transacción realizada para despachar este correo, y la forma en que los resultados
son recolectados.
1. El primer paso del programa es abrir una conexión TCP al puerto 25 (TCP port 25) del servidor. Si el servidor
no responde, entonces se registra un ”CONNECT” en la bitácora de resultados — 752 servidores no pudieron ser
contactados.
2. A continuación, el programa envı́a un comando ”EHLO mail.PRUEBA.com.cl”. Si el comando EHLO es rechazado, entonces el programa envı́a un comando ”HELO mail.PRUEBA.com.cl”. Si ambos son rechazados, el
programa registra un ”EHLO” en su bitácora de resultados — 22 servidores registraron un ”EHLO”.
3. El tercer paso es enviar el comando ”MAIL FROM:”. Si se rechaza, el programa registra ”MAIL” en su bitácora
— 164 servidores rechazaron este comando.
4. El siguiente paso es enviar el comando ”RCPT TO:”, si se rechaza, el programa registra un ”TO”. En este paso,
la mayorı́a de los servidores de correo reconocı́a un intento de hacer relay y devolvı́an un código de error (del
estilo 4xx o 5xx).
5. El programa, a continuación, entrega el comando ”DATA” y envı́a la información del correo tal como ya fue
descrita. Si este comando es rechazado, el programa registra un ”DATA” en la bitácora.
6. Por último, para finalizar la comunicación, el programa envı́a el comando ”QUIT” y escribe ”OK” en su bitácora
de resultados.
2
CONNECT
EHLO
MAIL
TO
DATA
OK
752
22
164
2648
56
567
17.87%
0.52%
3.90%
62.91%
1.33%
13.47%
No se pudo establecer comunicación
Error en el comando EHLO, HELO
Error en el comando MAIL FROM:
El correo se rechaza, no hace relay
Error en el comando DATA
El correo es aceptado por el servidor
Tabla 1: Total de hosts revisados 4209.
4 Resultados
El resultado global de esta prueba arrojó los valores indicados en la Tabla 1. Del total de sitios revisados (4209), un
17,9% no pudo ser contactado. Esto se puede atribuir a servidores de correo que no están activos, y cuyas referencias
en el DNS no han sido actualizadas. Es necesario notar en este punto, que un dominio normalmente tiene más de un
record MX, por lo que la no operatibilidad de uno, no implica que el correo electrónico dirigido a ese dominio no sea
recibido.
Algunos de estos servidores que no pudieron ser contactados, podrı́an haber estado activos, pero por problemas
atribuibles a fallas en la conexión de la red resultaron inubicables. Sin embargo, el efecto de esto en los resultados
de este estudio es menor, debido a que se hicieron varios intentos por contactar a estos servidores (a distintas horas
y dı́as). Estas repeticiones se detuvieron cuando el número de servidores que se lograban contactar (en un nuevo
intento) fue inferior al 5% del total de sitios que faltaba por contactar. Por todo lo anterior estimamos que el error de
los resultados a continuación exhibidos es despreciable.
Despacharon el relay
Respondieron un mensaje de error
Aceptaron el mensaje pero nunca lo despacharon
327
171
69
7.77%
4.06%
1.64%
Tabla 2: Total de hosts que aceptaron el relay: 567 (13.47%).
Un 62,9% (2648) de los servidores rechazó el relay y un 13,5% (567) aceptó el correo. De los 567 servidores que
aceptaron el correo, según podemos ver en la Tabla 2, 327 (7,8% del total) enviaron el relay efectivamente. En tanto,
171 (4,1% del total) devolvieron el correo con un mensaje de su servidor de correo (mailer-daemon) indicando que no
era posible despachar ese e-mail. En tanto, otros 69 (1,6%) servidores nunca despacharon correo alguno (ni el relay,
ni un mensaje de error).
Del total de servidores revisados (4209) y de los que se estableció estaban operando (3457), un 7,8% y 9.5%
respectivamente efectivamente permiten relay.
5 Discusión
La lista más completa que conocemos de servidores SMTP que aceptan relay es aquella mantenida por ORDB.org. Esta
contiene, a Enero del 2001, un total de 273 servidores en el dominio .cl[2]. Como contraste, éste estudio identificó
327 tales servidores, es decir 54 (16.5%) más. Estos 54 servidores representan el 1.3% del universo de los 4209
servidores involucrados en este estudio y el 1.6% de los que se comprob ó estaban operando. Esto indica por un lado la
precisión de análisis generales como los conducidos por ORDB.org y los beneficios de contar con estudios especı́ficos
sólo del dominio .cl.
Estudios como éste (aunque no tan exhaustivos en la confección de la lista de servidores SMTP) realizados por el
Internet Mail Consortium, indicaban que a Julio de 1999 y Enero del 2001 aproximadamente 17.2% y 6.4% respectivamente de los servidores SMTP permitı́an relay. Aunque ellos no precisan la manera en que recolectan el listado de
servidores de correo, ni el ámbito en el cual circunscriben este listado.
Nuestro estudio pareciera indicar que en el dominio .cl hay un rezago de más de un año en comparación con
prácticas internacionales — aunque es prematuro asegurarlo.
3
Por último, cabe señalar que los datos obtenidos en este estudio permiten cuantificar otras prácticas que inciden en
la seguridad de los servidores de correo que comprende el dominio .cl. Entre ellas, tipo de software SMTP utilizado,
antigüedad de la versión utilizada, etc. Este análisis será objeto de trabajo futuro.
Agradecimientos
Los autores desean agradecer a Tomás Barros por haber construido una primera lista de servidores SMTP sobre la cual
se corrieron las primeras pruebas de Relay.
Referencias
[1] J. Postel. Simple Mail Transfer Protocol, STD 10, RFC 821, USC/Information Sciences Institute, Agosto 1982.
[2] ORDB.org. Number of relays per TLD (www.ordb.org/tld/), Enero 2002.
[3] P. Hoffman. Allowing relaying in SMTP: A series of surveys. Technical Report IMCR-015, Internet Mail Consortium, Enero 2001 (www.imc.org/ube-relay.html).
[4] J. Abley. NZ promiscuous mail relay survey (www.patho.gen.nz/ jabley/survey.html#FAQ), Abril 1999.
[5] CLCERT. Open relay en SMTP: Primera encuesta. Disponible bajo editorial en www.clcert.cl, Diciembre 2001.
[6] C. Partridge Mail Routing and the domain system, RFC 974, CSNET CIC BBN Labs, January 1986.
4