logo-IRIS
  
> Inicio
> Sitemap
> Contacto
> Buscador
  



< Servicios < Correo electr�nico

Sobre el abuso de Estafetas de correo electr�nico
Consejos para evitar el uso de Estafetas con objetivos no deseados (spaming y otros)

 Servicio Correo Electr�nico RedIRIS

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:

postmaster@dominio.es
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:

  1. 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


  2. 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:

    1. Repasar la configuraci�n.
    2. Utilizar cuentas externas para hacer pruebas.
    3. Tener cuidado si se da acceso a dominios virtuales para incluirlo y permitirles el acceso
    4. 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.
webbered
Actualizado el 20/11/2000
RedIRIS � 1994-2003
 ^