|
||||||||||||
|
|
|
|||||||||||
|
|
 |
|||||||||
Autor: Jesus Sanz de las Heras
Fecha: 20/10/97
1. Introducción
El uso de las Estafetas de correo (servidores SMTP) para encaminar correo basura por parte de indeseables esta aumentando de forma considerable. Se intenta en este documento hacer un descripción de problema ( Punto 2.) y la repercusión que tienen (Punto 3.). En el apartado 4 se ofrece una serie de medidas para actuar y/o denuciar casos de los abusos descritos en este documentos. En el Punto.5 se intenta ofrecer algunas medidas para evitar estos abusos en Estafetas como Sendmail y PMDF.
El objetivo fundamental de este documento es la concienciación del problema por parte de las organizaciones y desde RedIRIS se aconseja, dentro de las posibilidades de cada Organización, de la implementación de estas medidas.
2. Descripción del Problema
Primero debemos de identificar a qué se llama correo basura o spam. Lo que delimita a este tipo de mensajes no es en sí el tipo de información que contienen sino que la información recibida y/o distribuida no ha sido solicitada. El contenido de estos mensajes suele ser comercial, falsas solidaridades, cartas encadenadas y en general de tipo publicitario.
La distribución de este tipo de información se hace fundamentalmente a través de correo-e (listas de dsitribución) y grupos de news.
Evidentemente el problema afecta al usuario final que recibe el correo y a la máquina que debe de distribuirlo. El tema no es sólo un problema de molestia y perdida de tiempo sino que tiene repercusiones económicas de utilización de recursos de red y de sistemas. Puede llegar a deteriorar de forma considerable el propio rendimiento de Internet.
El problema grave es el uso de Estafetas para distribuir mensajes no deseados a un numero indeterminado de destinatarios. Esto es a veces usado por estos indeseables para evitar los filtros tecnicos de otras máquinas y cumplir sus objetivos.
Existe un problema adicional que si bien no es considerado correo basura es una mala utilización de los recursos. Es el tema del encaminamiento de correo-e a traves de máquinas que no tienen relación con la organización del emisor del mensaje. Es el caso de PC que tienen definido de forma incorrecta el valor de "Default gateway" o Estafeta responsable de encaminar el correo.
3. Repercusiones del problema
a. Los mensajes de spam distribuidos a través de Estafetas víctimas aparecen como distribuidos desde el dominio de esta Estafeta. Esto produce que los usuarios finales encaucen las quejas a través del postmaster de la Estafeta "víctima".
b. Disminución del rendimiento de la Estafeta "víctima", provocando retrasos y bloqueo en el encaminamiento del correo real hacia y desde esa Estafeta. Debido a que la carga de la máquina aumenta al tener que distribuir los mensajes no deseados a una larga lista de destinatarios, ademas de absorver los correspondientes mensajes de error, pues muchos destinatarios serán incorrectos.
c. Perdida de tiempo respondiendo las quejas de los usuarios y enviar quejas al responsable real del abuso desde donde se originó el spam. Generalmente con pocas garantias de éxito en que el proveedor responsable tome acciones.
d. Hay casos conocidos de máquinas bloqueadas por el uso de Estafetas como encaminadoras de correo-e spam.
4. Actuación
La primera actuacion es la implementación de medidas técnicas en la Estafeta para que estos casos sucedan la menor cantidad de veces posible. En el siguiente apartado encontrarás algunas de estas medidas. Existen otra serie medidas no tan efectivas y que pueden aplicarse en paralelo como es, la habilitación de ficheros de log.
Si a pesar de los filtros definidos recibes correo no deseado o tu máquina ha sido usada de forma fraudulenta se debería de disponer de un plantilla de mensajes para enviar al emisor del mensaje, al proveedor responsable del buzón del emisor y/o al responsable de la red IP del emisor.
Es muy util la creación de buzones normalizados internacionalmente como:
abuse@dominio.es
Es necesario que la comunidad RedIRIS se coordine frente ante ataques de correo no deseado en cualquiera de sus facetas. La listas a través de la cuales se intenta coordinar este problema son:
ACE-L@listserv.rediris.es
Es una lista pública y abierta a los proveedores españoles, a través de la cual se intenta informar, coordinación de acciones, distribución de incidentes etc.para suscribirtse:
To: listserv@listserv.rediris.es Subject: ------------------- subscribe ace-l Nombre Apellidos
o tambien:Suscripcion en ACE-L
IRIS-MAIL@listserv.rediris.es
Es una lista exclusiva de los administradores del servicio de correo electrónico en los Centros y organizaciones ligadas a la Comunidad RedIRIS. En esta lista además de otros temas se coordinará todo lo referente al Abuso en el Correo Electrónico en RedIRIS.para suscribirtse:
To: listserv@listserv.rediris.es Subject: ------------------- subscribe iris-mail Nombre Apellidos
o tambien:
Suscripcion en IRIS-MAIL 5. Solucciones.
Lo primero para la implementación de solucciones es la concienciación del problema y no esperar a que se produzca el ataque. En segundo lugar las solucciones deben de ser técnicas y luego los correspondientes mensajes de denuncia a quien sea oportuno.
Para implementar medidas técnicas hay que tener cuidado y definir qué se quiere permitir y qué se quiere rechazar. La regla mas básica seria:
"La Estafeta sólo debe conmutar correo con origen y destino dentro del o de los dominios de la organización".
El tema de las Estafetas con listas de distribución habria que tratarlo aparte por lo excepcional.
Cualquier solución implementada debe de ser probada con cuidado antes de ponerla en operatividad. Para ello:
- Repasar la configuración.
- Utilizar cuentas externas para hacer pruebas.
- Tener cuidado si se da acceso a dominios virtuales para incluirlo y permitirles el acceso
- Tener en cuenta a los usuarios locales que están fuera (congreso etc) y necesitan utilizar la Estafeta (forward automaticas etc) . Se les pueda dar acceso temporales.
A continuación se expondrán las soluciones técnicas para los dos paquetes de correo electrónico mas usados: Sendmail de Berkeley y el PMDF. Para otros tipo de paquetes como Netscape Server, Windows NT, Microsoft Exchange Internet Mail etc se desconocen las soluciones y estariamo encantados de poder incluirlas en este documento.
Medidas para Sendmail contra el uso incorrecto por terceras partes
Nota: La implementación de estas medidas estan detalladamente documentadas en el las páginas Web de RedIRIS, su implementación a base de una serie de FEATURES de sendmail fue realizada por Diego Lopez del CICA a través de un grupo de trabajo en RedIRIS durante 1996-97.
La información y configuración de estas medidas está disponible en:
http://www.rediris.es/mail/generador/ Estas directivas definen mecanismos que permiten el control de acceso a las funciones que sendmail ofrece como manejador de mensajes a los demás nodos de la Red. Este control es configurable por medio de un conjunto de ficheros especificos, que detallan el modo de acceso permitido en cada caso.
En particular, es posible:
- Denegar la ejecución de cualquier comando SMTP a los nodos a partir de su nombre DNS o su dirección IP, mediante FEATURE(rejrelay).
- Aceptar o rechazar comandos SMTP MAIL a partir de la dirección de correo proporcionada en el comando o del dominio al que pertenezca la dirección, mediante FEATURE(authfrom).
- Aceptar o rechazar comandos SMTP RCPT a partir de la dirección de correo proporcionada en el comando o del dominio al que pertenezca la dirección, mediante FEATURE(authto).
- Aceptar o rechazar el reenvio de un mensaje en función de las direcciones o los dominios a los que pertenezcan las direcciones del remitente y del destinatario, mediante FEATURE(authcompat).
Estos mecanismos pueden utilizarse y combinarse de manera absolutamente independiente, de acuerdo con las políticas de control de acceso que cada Organización desee seguir. En cualquier caso, hay ciertas reglas de precedencia obvias que son consecuencia del funcionamiento del protocolo SMTP. El orden en que se han incluido aqui los mecanismos de control de acceso es de mayor a menor precedencia. Por ejemplo, si se rechazan conexiones desde un nodo utilizando FEATURE(rejrelay) no tendrá sentido autorizar conexiones desde el con FEATURE(authfrom) o FEATURE (authcompat). Del mismo modo, si no se acepta correo para un determinado dominio por medio de FEATURE(authto), no tiene sentido autorizarlo con FEATURE(authcompat).
Medidas para PMDF contra el uso incorrecto por terceras partes
Nota:Esta reseña ha sido incluida gracias a la colaboración de Juan Carlos Blanco de la Facultad Informatica de la UPM.
Antes de nada, la referencia exacta de como prevenir que se utilice un sistema PMDF como relay desde fuera de una organización, puede encontrarse en el Web de Innosoft, autores del PMDF.
http://www.innosoft.com/iii/app-notes/relay.html En cualquier caso a continuación se presenta un breve resumen de como llevarlo a cabo.
Distinción entre tráfico externo e interno a la organización
Como primera tarea es necesario diferenciar el tráfico SMTP sobre TCP/IP que proviene desde dentro o fuera de la organización. Esto se logra definiendo dos canales tcp/ip, uno puede ser el habitual "tcp_local", que se utilizará para el trafico externo, al ser el canal por defecto. Y otro al que se le puede denominar "tcp_interno".
Además de la definición, se deben establecer reglas de reescritura adecuadas para dirigir los mensajes hacia los canales correspondientes. Esto proporciona la diferenciación de los mensajes que salen de PMDF. Normalmente todo el tráfico entrante por TCP/IP se asocia (como canal de origen) al canal "tcp_local". Para lograr que ese tráfico se asigne a otro canal, hay que utilizar la opción "switchchannel" de la definición de "tcp_local", esto hace que se utilice la dirección IP de la máquina que se conecta, junto con las reglas de reescritura del PMDF, para asignar el mensaje al canal "tcp_*" adecuado. El fichero PMDF.CNF quedaria como sigue:
default noswitchchannel ! ! Incluir también todas las otras opciones que afecten a todos los ! canales. ! tcp_local smtp single_sys mx switchchannel remotehost TCP-DAEMON ! ! Se añade el nuevo canal tcp_interno, la opcion "switchchannel remotehost" ! indica que los mensajes entrantes deben ser analizados para asignarlos ! (posiblemente) a otro canal ! tcp_interno smtp single_sys mx allowswitchchannel TCP-INTERNO ! ! Finalmente se añadirán (al principio del fichero) las reglas de reescritura ! que permitiran asignar las direciones IP del dominio interno al canal ! "tcp_interno", por ejemplo, si el dominio es EJEMPLO.DOM y la red asignada ! a la organización A.B.subred ! .ejemplo.dom $U%$H$D@TCP-INTERNO [a.b.] $U%[a.b.$L]@TCP-INTERNO$E$R Con esta configuración todos los mensajes recibidos por TCP/IP del dominio procederán del canal "tcp_interno" y el resto del canal "tcp_local". Ahora ya se esta en una situación donde se pueden aplicar restricciones a los mensajes de uno y otro entorno.
El funcionamiento de la nueva configuracion es el que sigue. La opción "switchchannel" afecta al canal "tcp_local", esto implica que el servidor SMTP analiza la dirección IP origen asociada a la conexión entrante, y realiza una busqueda inversa en el DNS para obtener el nombre de HOST. Si existe el servidor utiliza este nombre (y en otro caso la direción IP literal) para realizar una búsqueda en las reglas de reescritura inversas (las que afectan a la dirección de sobre origen) para localizar el canal correspondiente.
Si el nombre (o la dirección IP) corresponden a un HOST local, las reglas de reescritura añadidas en la configuración, indicarán que el canal asociado es "tcp_interno", y dado que este canal tiene la opcion "allowswitchchannel", el mensaje es transferido a dicho canal. Si el mensaje viene de un origen externo (el HOST o dirección IP no son locales). Las reglas de reescritura lo dirigirán al canal "tcp_local" (o a cualquier otro que no disponga de la opción "allowswitchchannel"), en este caso el mensaje seguirá asociado al canal "tcp_local".
Habra que tener en cuenta el cambio en los nombres de los canales si estos son referenciados en algun otro fichero de configuración de PMDF.
Bloqueo del sistema PMDF como relay de origen no autorizado
Una vez diferenciado el tráfico local del externo ya se esta en situación de poder abordar la misión que se pretendía, como impedir la utilización del sistema PMDF como relay por sistemas no autorizados. Para realizarlo se utiliza una de las tablas de MAPPING de PMDF, la SEND_ACCESS. Esta tabla permite establecer restricciones de paso de mensajes basados en las direcciones origen y destino. Por ejemplo, para bloquear cualquier tráfico que proceda del canal "tcp_local" y vaya dirigido tambien a "tcp_local" se puede realizar la siguiente tabla:
SEND_ACCESS tcp_local|*|*|*$%*.ejemplo.dom@* tcp_local|$0|$1|$2@$4$R tcp_local|*|*|*$%ejemplo.dom@* tcp_local|$0|$1|$2@$3$R tcp_local|*|*|*$%*.ejemplo.dom$%*@* tcp_local|$0|$1|$2@$5$R tcp_local|*|*|*$%ejemplo.dom$%*@* tcp_local|$0|$1|$2@$4$R tcp_local|*|*|*$%*.*@* $NRelaying$ not$ permitted tcp_local|*|*|"*@*"@ejemplo.dom $NRelaying$ not$ permitted tcp_local|*|*|"*@*"@*.ejemplo.dom $NRelaying$ not$ permitted tcp_local|*|*|@*:"*@*"@ejemplo.dom $NRelaying$ not$ permitted tcp_local|*|*|@*:"*@*"@*.ejemplo.dom $NRelaying$ not$ permitted tcp_local|*|*|@*:*@*.ejemplo.dom $Y tcp_local|*|*|@*:*@ejemplo.dom $Y tcp_local|*|*|@*:*@* $NRelaying$ not$ permitted tcp_local|*|tcp_local|* $NRelaying$ not$ permitted
Las primera entradas reconvierten los diferentes formatos de dirección "source route" que utilicen el sistema PMDF como destino intermedio, al formato habitual para analizar su viabilidad. La última es la que bloquea cualquier tráfico de una dirección externa a otra externa.
El fichero de MAPPINGS se encuentra en PMDF_TABLE:MAPPINGS. o /pmdf/table/mappings en sistemas VMS o UNIX. Si se utiliza una configuracion compilada debera recompilarse despues de alterar este fichero.
Una vez realizados estos cambios de configuración hay que tener en cuenta que esto puede afectar a listas de distribución gestionadas por PMDF con usuarios origen y destino fuera del dominio local. Igualmente puede afectar a alias definidos en PMDF y redirigidos a direcciones externas. Si se esta en este caso conviene consultar el documento al que se hacia referencia al principio.
 |
| Actualizado el 20/11/2000 |
| RedIRIS © 1994-2003 |
