Borja Pérez Oñate, Pascual Pérez Sánchez
Resumen
En este artículo se muestran tres ventajas que aporta LDAP al servicio de correo electrónico y que son las siguientes:
- Sistema de autenticación centralizada para el envío de mensajes
- Sistema de autenticación centralizada para el acceso al buzón de usuario
- Gestión sencilla del mapa de encaminamiento de mensajes dentro de la organización.
Palabras clave: Autenticación, encaminamiento, SASL, LDAP, PAM, SIA
Summary
This article shows the contribution of three improvements made by LDAP to mail service. These are the following:
- Centralized authentication system for sending mail
- Centralized authentication system for retrieving mail
- Easy management for the definition of inside mail routing map
Keywords: Authentication, mail routing, SASL, LDAP, PAM, SIA
1.- Introducción
El correo electrónico está pasando de ser una herramienta de intercambio de información basada en el respeto de los usuarios a las normas de buena conducta, a ser cada vez más, el medio que se utiliza para acciones no deseadas: envíos masivos de mensajes no solicitados (SPAM), vehículo de mensajes anónimos o con el remitente falsificado, etc. Estas acciones degradan el servicio y afectan negativamente a la imagen de la organización de la que parten dichos mensajes.
Los usuarios del correo electrónico demandan un servicio de calidad en el que esas acciones no deseadas se reduzcan al mínimo posible. Por ello han surgido los servidores de "listas negras" que señalan aquellos servidores de correo cuya configuración no cumple determinadas normas. Cada vez se emplean más estas listas como medio de rechazar mensajes provenientes de lugares "sospechosos".
Estas normas mínimas podrían ampliarse con nuevas condiciones en un futuro próximo. En este articulo queremos explicar como se pueden aprovechar las nuevas opciones que los servidores de correo (Sendmail) ofrecen de cara a identificar a las personas que generan los mensajes y por lo tanto minimizar el uso abusivo de este servicio de comunicación.
Vamos a presentar un modelo genérico de estructura de servidores de correo electrónico en una institución y posteriormente analizaremos los elementos constitutivos de la estafeta principal de correo.
2.- Modelo de organización
Suponemos que existe una estafeta principal de correo que canaliza todos los mensajes que llegan a la organización y los traslada a los servidores internos. Los usuarios accederán a estos servidores, generalmente vía protocolo POP o IMAP, para recoger su mensajería.
La estafeta principal también canalizará todo el correo de salida. Estos mensajes pueden ir directamente desde las aplicaciones de usuario, como Outlook, Netscape o Eudora, hasta la estafeta principal, o ir primero a un servidor interno y desde este a la estafeta principal. Teniendo en cuenta que las soluciones de autenticación son similares en ambos casos, y que es más sencilla la conexión directa entre aplicación de usuario y estafeta principal usaremos este modelo como ejemplo.
3.- Autenticación de usuarios en la estafeta principal
La política de encaminamiento que se define en la pasarela principal se resume en estas condiciones:
* Todos los mensajes dirigidos a los servidores de correo interno a la organización se aceptan y se entregan a los servidores. Se rechazan los mensajes cuyo origen sea un servidor "sospechoso".
* Todos los mensajes dirigidos hacia el exterior de la organización se aceptan y encaminan en caso de que la autenticación del emisor sea correcta.
Los datos que las estafetas utilizan para validar la identificación del usuario pueden estar en distintos servidores y formatos: los datos del fichero /etc/passwd, los de un servidor NIS, los que están en una base de datos especifica (sasldb), los de un servidor LDAP, etc.. Nos centraremos en el caso LDAP ya que los otros se pueden obtenerse por simplificación de este.
En la estafeta principal usaremos Sendmail como servidor SMTP. En el gráfico podemos ver los elementos que entran en juego cuando se envía un mensaje de correo electrónico.
En este proceso podemos ver que el cliente SMTP (cualquier cliente de correo como Eudora, Outlook o Netscape) establece
una conexión con el servidor (Sendmail) y envía los datos de identificación y el mensaje. El servidor compara estos datos con los almacenados en el servidor LDAP y, si la autenticación es satisfactoria,
envía el mensaje a su destino. En caso contrario rechazan el mensaje.
Los elementos que participan en este proceso son:
* Sendmail, versión 8.10 o posterior, compilado con las librerías SASL.
* Las librerías SASL que utiliza Sendmail para acceder al sistema de autenticación.
* El módulo de autenticación propio del sistema. En el caso de Solaris, Linux y HP el módulo es PAM (Plugable Autentication Module) y en el caso de DIGITAL-UNIX el módulo es SIA (Security Integration Architecture).
* EL servidor LDAP. A continuación explicamos en detalle las características de cada uno de estos elementos.
Librerías desarrolladas en el proyecto Cyrus de la Universidad Carnegie Mellon. Es necesario tener instaladas las librerías SASL en el sistema antes de compilar Sendmail.
Su función es independizar a la aplicación, en este caso Sendmail, del proceso de autenticación. Permite usar distintos mecanismos de autenticación como los clásicos de login y password o más sofisticados como CRAM-MD5. Además puede buscar los datos de identificación en diferentes ubicaciones: /etc/passwd, NIS, LDAP, etc. La librería SASL dispone también de un sistema propio para gestionar los datos de usuario, incluso admite la posibilidad de crear aplicaciones específicas para validar la identificación del usuario.
Cada aplicación que utilice SASL debe tener un fichero de configuración dónde se indica el modelo de autenticación que se utilizará.
Los sistemas operativos tienen servicios de autenticación que están a disposición de las aplicaciones que los necesitan. Cada servicio está asociado a una librería que recibe peticiones de la aplicación y, después de las comprobaciones necesarias, responde a la aplicación si la autenticación ha sido satisfactoria o no.
El módulo PAM (o SIA) está situado entre las aplicaciones y los servicios de autenticación independizando unas de otros. Cuando se utiliza el módulo PAM, las aplicaciones se comunican con el módulo y este con los servicios de autenticación que tenga asignados en la configuración. Para que una aplicación cambie de sistema de autenticación solamente deberemos cambiar la configuración del módulo PAM, que está definida en el fichero /etc/pam.conf.
);)
Por el nombre de las librerías vemos que se puede realizar la función de autenticación basándose en los datos almacenados en los ficheros /etc/passwd (y si es el caso en /etc/shadow) con la librería pam_unix.so.1, o en los datos almacenados en un servidor ldap con la librería pam_ldap.so.1, etc.
Es el sistema de almacenamiento de la información de autenticación que usaremos en este planteamiento. Los datos de los usuarios residirán en el servidor LDAP que deberá tener definidos los objetos necesarios para recoger esta información. El cliente es la máquina en la que está Sendmail y que necesita conocer los datos relativos al servidor LDAP, usuario y password de acceso, así como el nivel de búsqueda en el árbol LDAP.
Los objetos y atributos necesarios en el servidor LDAP que permitan almacenar los datos de autenticación están definidos en el RFC 2307 y básicamente son:
);)
La secuencia de pasos que se deben seguir para activar este sistema de autenticación en la estafeta principal es:
1.- Definir los objetos y atributos en el servidor LDAP.
2.- Incorporar los datos de identificación de usuarios en el servidor LDAP. 3.- Configurar la máquina donde reside Sendmail como cliente LDAP.
4.- Configurar el módulo PAM (SIA) de esta máquina para que use la librería LDAP correspondiente.
5- Compilar e instalar la librería SASL. 6.- Compilar e instalar Sendmail versión 8.10 o superior.
7.- Configurar SASL y Sendmail modificando los ficheros oportunos. En la dirección: http://www.rediris.es/gti-smail hay documentación de ayuda para todos estos procesos.
4.- Autenticación en el acceso al buzón
Los protocolos de acceso al buzón como POP o IMAP siempre han utilizado autenticación de usuario para mantener la confidencialidad de los mensajes del usuario. Originalmente los datos de identificación usados por los servidores POP e IMAP coinciden con los que usa el sistema para autenticar a sus usuarios, normalmente los datos de /etc/passwd. También pueden usar los de alguna base de datos específica del servidor.
Las nuevas versiones ya están incluyendo otras opciones, por ejemplo el servidor cyrus IMAP utiliza el conjunto SASL y PAM o el servidor qpopper 3.1 que acepta el uso directo de PAM.
Con estas opciones los datos de identificación de los usuarios de correo pueden estar alojados en un servidor LDAP centralizado, y servir tanto para autenticar los envíos de correo como para el acceso al buzón del usuario.
5.- Mail-Routing de sendmail basado en LDAP
LDAP, además de usarse como almacén de datos para los procesos de autenticación, puede también utilizarse como almacén de datos de encaminamiento de correo. Desde la versión 8.10 de sendmail se puede utilizar la información contenida en un servidor LDAP para generar tablas del tipo de las que aparecen en el cuadro siguiente y que permiten que los mensajes enviados a una dirección (mailLocalAddress) se encaminen a otra (mailRoutingAddress). Para almacenar esta información es necesario definir el objeto inetLocalMailRecipient en el servidor LDAP, que debe contener el atributo mailLocalAddress para la dirección original del mensaje y el atributo mailRoutingAddress con la dirección a la que habrá que dirigir el mensaje.
);)
Este objeto puede albergar otro atributo: mailHost, que junto con los anteriores aumenta las posibilidades de encaminamiento para los mensajes de la organización Si este atributo existe puede tener dos valores: "local" o la dirección de un host.
Cuando un mensaje es enviado a la dirección mailLocalAddress y el servidor LDAP tiene una entrada para esta dirección, sendmail puede actuar, en función del valor de los otros atributos, de estas formas:
a) Si existe mailRoutingAddress el mensaje se envía directamente a esa dirección si mailHost es "local" o no existe.
b) Si mailHost tiene una dirección de host el mensaje se envía a mailRoutingAddress través de ese host.
c) En caso de que mailRoutingAddress no exista, el mensaje se envía a la dirección original y, como en el caso anterior a través de mailHost si está definido.
Sendmail debe ser compilado con la opción -DLDAPMAP y el fichero de configuración deberá contener los datos básicos de acceso al servidor LDAP.
Ejemplo de configuración usando el fichero ".mc":
);)
6.- Notas finales
El modelo de organización empleado en el cual todos los usuarios utilizan la estafeta principal como servidor SMTP para enviar su mensajería, puede ampliarse a una organización con servidores SMTP internos que recojan los mensajes de los usuarios y después los envíen a la estafeta principal. En este caso las tareas de autenticación del remitente las realizaría cada uno de los servidores. Cada uno de estos servidores almacenará los datos de sus usuarios en una rama del árbol LDAP y las consultas se harán indicando dicha rama como base de la búsqueda.
Una organización donde el envío de mensajes, el acceso al buzón y el encaminamiento de mensajes dependa de un servidor LDAP convierte a este servidor en un punto crítico del servicio de correo electrónico. Una parada del servidor LDAP impediría enviar mensajes, leer los que tenemos en el servidor y lo que es más grave, se rechazarían como usuario desconocido los mensajes que llegasen a la organización.
Referencias
* Sendmail: http://www.sendmail.org
* Qpopper3.1: http://www.eudora.com/qpopper/31.html
* RFC2307 LDAP as a Network Information Service: ftp://sunsite.org.uk/rfc/rfc2307.txt
* RFC2554 SMTP Service Extension for Authentication: ftp://sunsite.org.uk/rfc/rfc2554.txt
* SASL/IMAP/POP CYRUS-IMAP: http://asg.web.cmu.edu/cyrus
* draft-lachman-laser-ldap-mail-routing-02.txt: http://playground.sun.com/pub/laser/
Borja Pérez Oñate
borja [at] posta [dot] unizar.esPascual Pérez Sánchez
pascual [dot] perez [at] posta.unizar.esCentro de Cálculo
Universidad de Zaragoza