Correo Seguro

Modelo de Conectividad para Redes Humanas

1


ANEXO E IMPLEMENTACION DE UN SERVICIO DE CORREO ELECTRNICO SEGURO

1. DEFINICIN DEL PROBLEMA

Como parte de las necesidades de comunicacin y trabajo en red identificadas enel grupo objetivo, se consider esencial que la Red de Investigacin Educativacontara con un servicio institucional de correo electrnico. Esto le permitira acada miembro, adems de intercambiar mensajes con otras personas dentro yfuera de ieRed, hacer uso de una cuenta que le diera un respaldo y una presenciaoficial en Internet, que lo vincularan a esa comunidad acadmica institucional.

Por otro lado, la cuenta ofrece la posibilidad de albergar mensajes en un espaciode 50MB compartidos con el disco virtual (servicio cuya implementacin seexplicar en el Anexo F), que representan una cantidad de almacenamientosuperior a la que ofrecen la mayora de las cuentas de correo gratuitas (de 3MB a5MB) y algunas institucionales (de 7MB a 14MB).

Una vez identificada la necesidad de implementar un servicio de correoelectrnico para la Red de Investigacin Educativa, se empezaron a examinar unconjunto de alternativas para su prestacin, y se determin que era necesario eimperativo que, independientemente de la seleccin que se hiciera, se ofreciera elservicio bajo unas condiciones mnimas de seguridad.

Como el concepto de Servicio de Correo Electrnico Seguro puede resultar muyambiguo dependiendo de las consideraciones de seguridad que se tengan encuenta, ms adelante se explicar el conjunto de caractersticas mnimas ydeseadas de seguridad que a juicio de los autores, deba tener este servicio.

Junto a la World Wide Web, el correo electrnico es quiz uno de los serviciosms utilizados por las personas que acceden a Internet, y uno de los msantiguos. El correo electrnico surgi hacia el final de la dcada de los setentascomo un intento de convertir las comunicaciones electrnicas en una nueva formade intercambiar informacin entre los centros universitarios ms rpida que elcorreo fsico convencional.

Su estructura ha cambiado muy poco desde entonces: el sistema funcionareplicando muchos de los elementos del correo ordinario tales como el buzn decorreo o direccin postal para recibir mensajes, las agencias postales para elintercambio de correspondencia, las personas encargadas de su entrega final ocarteros, un formato estandarizado para el envo de cartas que se compone de los

61


datos del remitente y los del destinatario escritos en un sobre, y finalmente elmensaje (o carta).

Los primeros (y an ampliamente utilizados) sistemas para el tratamiento delcorreo electrnico se concibieron para una Red donde lo que interesaba eracompartir, y haba poco o ningn espacio para las aplicaciones maliciosas, losvirus, los delincuentes o esas indeseables prcticas de publicidad que saturan lasbuzones electrnicos de las personas. En ese entonces, Internet era un lugarmucho ms agradable.

Ante la presencia de stas y otras amenazas hoy en da, se deben buscarmecanismos para asegurar las comunicaciones y garantizar su privacidad por unlado, y proteger los recursos de las mquinas que soportan el servicio evitandoque se haga un mal uso de l, por otro.

Configurar un servicio de una forma completamente segura es quiz algo utpico.No obstante, un sistema se puede considerar relativamente seguro en la medidaen que considere un conjunto de primitivas de la seguridad computacional y deredes que se describen a continuacin:

Aceptacin: Entendida como la facilidad de brindarle a las personas el acceso ala informacin. De nada sirve un sistema seguro si nadie puede hacer uso de lainformacin que reside en l.

Identificacin: Se refiere al reconocimiento de un usuario del sistema.Usualmente esto se consigue con un nombre (login) o un nmero deidentificacin (id).

Autenticacin: Se refiere a la verificacin que se hace de la identidad de unusuario. Incluye desde mecanismos complejos como los sistemas de accesobimtricos1, hasta los ms simples como el uso de contraseas. En sistemasinformticos, no slo se refiere al reconocimiento de usuarios, sino tambin alde procesos que deban comunicarse entre s en el interior de una mquina.

Autorizacin: Consiste en permitirle determinados privilegios y restringirle otros,tanto a un usuario como a un proceso corriendo en un sistema.

Confidencialidad: Se refiere a una cualidad de la informacin que la protege deser accedida por personas, procesos y recursos que no han sido expresamenteautorizados para ello.

1 El acceso bimetrico hace referencia a la identificacin de una persona a partir de algunamedida fsica de su cuerpo, como por ejemplo la huella dactilar, el iris, el peso, entre otras.

62


Integridad: Consiste en la conservacin de la informacin tanto en trnsito poruna red, como la que se encuentra alojada en una localidad de memoria, contramodificaciones de personas no autorizadas para ello o distintas al propietario.

En este orden de Ideas, se concibi un servicio de correo electrnico que tuvieseen cuenta aspectos de seguridad tales como:

Identificacin y Autenticacin de los usuarios para permitir el envo de correoelectrnico slo aquellos que tuvieran una cuenta vlida en el sistema.

Cifrado de las conexiones entre el cliente y el servidor para evitar que lainformacin que intercambien, incluyendo el contenido del mensaje, pero muyespecialmente: el nombre de usuario y la contrasea, se transmitan en textoplano hasta el servidor. Con ello se garantiza la integridad y la confidencialidadde la informacin en un gran porcentaje, pero hay que aclarar que si el mensajede correo se enviaba a un servidor externo, la comunicacin entre servidoresno cuenta con ningn mecanismo de la confidencialidad. Para esta clase derequerimientos, se deben implementar mecanismos que soporten criptografaasimtrica2 del lado de los clientes.

Estos dos aspectos se deban tener en cuenta tanto en el correo a travs de laWeb, como a travs de un cliente remoto.

Estas caractersticas permiten asegurar la disponibilidad del servidor en lo querespecta a fallas debido a exceso de carga en el envo de correo electrnico,evitando que se malgasten los recursos de la mquina y que sea utilizada paraenviar correo electrnico no deseado (SPAM).

2. CONCEPTOS BSICOS

2.1 Funcionamiento general de un servidor de Correo Electrnico

Un servidor de correo electrnico funciona de forma similar a un enrutador, sloque en lugar de paquetes, se ocupa exclusivamente del trfico SMTP (Simple MailTransfer Protocol, Protocolo Simple de Transferencia de Correo). El siguiente esel conjunto de reglas que rige el comportamiento de un servidor SMTP:

2 Un criptosistema asimtrico es aquel en el que cada usuario crea un par de claves, unaprivada y otra pblica. El envo de un mensaje se cifra con la clave pblica, y la recepcin deun mensaje de descifra con la clave privada. La seguridad del sistema reside en la dificultadcomputacional de descubrir la clave privada a partir de la pblica.(Aguirre 2004).

63


1. Acepta un mensaje entrante.

2. Comprueba las direcciones del mensaje.

3. Si son direcciones locales, almacena el mensaje para recuperarlo.

4. Si son direcciones remotas, enva el mensaje.

5. Si encuentra que el mensaje no se puede enviar (la cuenta ha excedido sucuota o el usuario ya no existe), devuelve un mensaje de error al remitente queexplica el problema.

2.2 Protocolos para el intercambio de Correo Electrnico

Para el intercambio de mensajes entre personas (y archivos adjuntos comoimgenes, documentos, de texto, etc.), el servicio de correo electrnico se sirve dediversos protocolos. Estos protocolos permiten que mquinas distintas, que seejecutan con frecuencia en sistemas operativos y con programas de correoelectrnico diferentes, se comuniquen entre s e intercambien mensajes para quelleguen a los destinatarios adecuados (Red Hat Linux 2002).

Podemos hablar de dos tipos de protocolos: los que le van a permitir a un usuarioacceder a su buzn de mensajes en un servidor, y los que le van a permitir enviarmensajes a otros usuarios.

En el primer grupo, los dos protocolos ms populares son IMAP (InternetMessage Access Protocol, Protocolo de Acceso a Mensajes de Internet) y POP(Post Office Protocol, Protocolo de Oficina de Correo). La principal diferenciareside en que el protocolo IMAP permite el acceso a los mensajes alojados en elservidor y POP los descarga en la mquina local, borrndolos o dejndo una copiaen el servidor, segn se indique.

POP fue diseado inicialmente para leer correos sin conexin. El usuario seconectaba y descargaba los correos a su mquina local despus de lo cual stoseran borrados del servidor. La principal desventaja de esta forma de operacin eraque no era compatible con el acceso desde mltiples servidores, porque tenda adispersar el correo por todas las mquinas desde las cuales se revisara. As, elmodo de acceso sin conexin ataba a los usuarios a usar un equipo para elalmacenamiento y manipulacin de mensajes.

IMAP en cambio, fue pensado para permitir el acceso y la gestin de los mensajesdesde ms de un computador. Adems soportaba modos de acceso en lnea,sin conexin y desconectado; accesos concurrentes a buzones de correocompartidos; y fue pensado para ser completamente compatible con estndares

64


de mensajera en Internet como MIME (Multipurpose Internet Mail Extensions,Extensiones Multipropsito de Correo en Internet).

En cuanto al segundo grupo, tenemos en l al protocolo SMTP (Simple MailTransfer Protocol, Protocolo simple de transferencia de correo), descrito en elRFC 821.

2.3 Aplicaciones necesarias para el funcionamiento del servicio de correoelectrnico

Los sistemas de correo electrnico se componen de varias partes denominadasagentes. Cada agente se responsabiliza de una porcin lgica del sistema.Existen cinco agentes: el MUA (Mail User Agent, Agente de Usuario de Correo), elMTA (Mail Transfer Agent, Agente de Transferencia de Correo), el MDA (MailDelivery Agent, Agente de Entrega de Correo), el MSA (Mail Submission Agent,Agente de Registro de Correo), y el MAA (Mail Access Agent, Agente de Accesoal Correo).

El MUA o cliente de correo, es el programa que le va a permitir a un usuario(como mnimo) leer y escribir mensajes de correo electrnico. Tpicamente, estose hace a travs de una interfaz que puede ser grfica (Ximina Evolution, Outlook,Webmail, etc) o en texto (Pine, Mutt, etc). Debe tener funcionalidades de agentede acceso a correo para permitir la recuperacin de correo a travs de POP oIMAP y debe tener funcionalidad MIME (Multipurpose Internet Mail Extensions,Extensiones de Correo de Internet Multipropsito).

La funcionalidad MIME es la habilidad para leer o incluir texto no ASCII (textoplano) en el cuerpo de un mensaje. MIME especifica formas de incluir otra clasede documentos incluyendo imgenes y otros archivos binarios. Esta habilidaddepende tanto del MUA como de la existencia de otras aplicaciones capaces deentender el formato del archivo y que puedan ser llamadas o cargadas por el MUApara su visualizacin.

El MTA se encarga de la transferencia de los mensajes de correo electrnicoentre las mquinas que usan el protocolo SMTP. Un mensaje puede pasar porvarios MTA hasta llegar al destino final. Los MTA escuchan en los puertos 25 y587. Tpicamente se contactan el uno al otro usando el puerto 25. Los agentes deregistro usan el puerto 587. A la transferencia de correo electrnico para uncliente se denomina reenvo (o envo).

Los agentes MTA utilizan programas MDA (Mail Delivery Agent, Agente deEntrega de Correo) para entregar el correo electrnico al buzn de un usuarioconcreto. En muchos casos, el agente MDA es realmente un LDA (Local DeliveryAgent, Agente de entrega local), como bin/mail o Procmail. Cualquier programa

65


que gestione realmente un mensaje para entregarlo al punto donde lo leer unagente MUA se puede considerar un agente MDA. Tenga en cuenta que losagentes MDA no transportan mensajes entre sistemas ni actan como interfazpara el usuario final.

Muchos usuarios no utilizan directamente agentes MDA, porque slo se necesitanagentes MTA y MUA para enviar y recibir correo. Sin embargo, algunos agentesMDA se pueden utilizar para ordenar los mensajes antes de que los lea el usuario,lo cual es de gran ayuda si recibe una gran cantidad de correo.

El MSA o Agente de Registro de Correo es un agente nuevo que divide la cargade trabajo del MTA en servicios con muchos usuarios y mejora el desempeo. Laidea es que el agente de servicio se preocupe de las tareas relativas aldireccionamiento, tomando cierta parte de la carga de trabajo del MTA primario.ste simplemente puede confiar la validez de las direcciones cuando recibe uncorreo de agentes de registro conocidos. El MSA corrige direcciones, y arregla yreescribe encabezados. Procesa el correo de su propia cola y lo enva a unagente de transferencia local.

El MAA o Agente de Acceso al Correo es usado para recuperar la el buzn demensajes de un servidor de correo electrnico. Ejemplos de MAAs son elprotocolo IMAP y POP.

En nuestro caso, el MTA que se utiliz en la primera versin del servicio de correoelectrnico implementado con el Cliente Web de correo Squirrelmail fue Sendmail.Sendmail desempea el papel de los agentes de registro y transferencia decorreo. Las razones iniciales por las cuales se eligi a este programa son entreotras su gran trayectoria y probada funcionalidad.

No obstante, cuando el rea de currculo de RUDECOLOMBIA adquiri el servidorpara el soporte de los servicios tecnolgicos para la comunicacin y el trabajo enieRed, se cambi a Exim, cuya seleccin se justificar ms adelante.

2.3 El SPAM o correo no deseado

El correo no deseado o SPAM3 es una de las mayores molestias que debenenfrenar hoy en da tanto los usuarios como los administradores del servicio decorreo electrnico. La cantidad de correo basura que puede inundar los buzonesde correo puede causar desde improductividad por el tiempo que consumen laspersonas tratando de descriminar qu es SPAM y qu no lo es, hasta congestinen los servidores de correo electrnico por la cantidad de mensajes que deben

3 El origen de la palabra an es incierto, pero varios autores arguyen que significa: SalesPromotional/Advertising Mail, Correo Promocional/Publicitario para Ventas

66


procesar. La mayor parte del SPAM se transmite de forma masiva, lo queaumenta el nivel de congestin en las redes que emplea para su transporte. Esteltimo es el caso que ms preocupaba a los autores.

2.4 Mecanismos de Autenticacin

Dentro de los mecanismos de autenticacin disponibles, los ms comunes son:PLAIN, LOGIN, CRAM-MD54, DIGEST-MD5, y NTLM (NT LAN Manager). Destos, PLAIN, CRAM-MD5, y DIGEST-MD5 son mecanismos de autenticacinestandarizados, mientras que LOGIN y NTLM son mecanismos propietarios deMicrosoft. Slo PLAIN y LOGIN puede utilizar la contrasea de usuarios ensistemas Unix o Linux.

Como se puede observar en la documentacin existente para SASL 0.15: el usode los diferentes mecanismos de autenticacin, depende de los requerimientos dela aplicacin que los est usando. Mecanismos simples como LOGIN y PLAIN,estn dirigidos a anclarse en mecanismos de autenticacin existentes tales como /etc/passwd a travs de PAM (Pluggable Authentication Module, Mdulo deAutenticacin Conectable). La respuesta del cliente a estos mecanismos essencilla de implementar: al usuario slo se le pide su nombre de usuario y sucontrasea, y luego las llamadas al servidor pasan el nombre de usuario y lacontrasea a las polticas de decisin definidas por el sistema de autenticacin.

En otros mecanismos como CRAM-MD5 y su sucesor, DIGEST-MD5, laautenticacin se basa en secuencias de desafo-respuesta y reposa en laposesin de un secreto de cierto tipo para efectuar la autenticacin. El servidorgenera un desafo y el cliente le responde probando que el conoce el secreto, esdecir, la respuesta al desafo. Tpicamente este secreto, es una contraseagenerada a partir de algoritmos de resumen (hash). La respuesta del cliente es lamisma que para PLAIN o LOGIN. Como sea, el servidor no recibe la contraseaen texto plano a travs de la red sino un resumen de sta. Dado que los sistemasde autenticacin de polticas de decisin como PAM no los pueden manipular, larespuesta del servidor para estos mecanismos es ms complicada.

A continuacin se describen en forma breve los mecanismos de autenticacinms usados:

4 MD5 (Message-Digest Algorithm 5, Algoritmo de Resumen de Mensaje 5) es un tipo dealgoritmo de resumen de mensajes (y una funcin hash criptogrfica) con un valor hash de 128bits. Fue diseado por Ronald Rivest del MIT (Massachusetts Institute of Technology, InstitutoTecnolgico de Massachusetts). Generalmente las sumas de MD5 se codifican como unnmero hexadecimal de 32 dgitos.

5 Disponible en Internet en: http://www.gnu.org/software/gsasl/manual/gsasl.html#Mechanisms

67


PLAIN emplea un nombre de usuario (identidad de autenticacin e identidad deautorizacin) y una contrasea para autenticarlos. Proporciona dos formas devalidar al usuario, bien sea recuperando la contrasea bruta de la aplicacincon el mecanismo SASL, o llamando a la aplicacin con la identidad deautenticacin, la identidad de autorizacin y la contrasea, y permitindoledecidir entre stas.

LOGIN utiliza el nombre de usuario (nicamente la identidad de autorizacin) yla contrasea para autenticarlos. Se proporcionan dos formas de validar elusuario, bien sea haciendo que el mecanismo SASL recupere la contrasea enbruto de la aplicacin y efecte la validacin internamente, o llamando a laaplicacin, y permitindole decidir entre la identidad y la contrasea deautorizacin. Si la aplicacin especifica tanto las llamadas de validacin comode recuperacin de contraseas, se usar la de validacin.

CRAM-MD5 utiliza el nombre del usuario (Slo la identidad de autorizacin) y lacontrasea para autenticar a los usuarios. nicamente transfiere la contrasearesumida, lo que significa que no se pueden usar sistemas convencionales deautenticacin de polticas como PAM, porque ste no soporta la extraccin decontraseas. CRAM-MD5 proporciona dos formas de validar al usuario: biensea haciendo que el mecanismo SASL recupere la contrasea en bruto de laaplicacin y efecte la validacin internamente, o llamando a la aplicacin conel desafo y la respuesta CRAM-MD5, y permitindole decidir. Si se especificatanto la validacin como la llamada para recuperar contraseas, se usar laprimera.

El mecanismo DIGEST-MD5 se basa en la misma operacin criptogrfica deCRAM-MD5, pero soporta otras caractersticas como la identidad deautorizacin (autenticacin proxy) y la proteccin criptogrfica de los datos. Aligual que CRAM-MD5, slo transfiere la contrasea resumida, lo que implicaque no se pueda usar, por ejemplo, PAM como plataforma de transporte, dadoque sta no soporta la extraccin de contraseas. DIGEST-MD5 proporcionados formas de validar al usuario: una haciendo que el mecanismo SASLrecupere la contrasea en bruto de la aplicacin y efecte la validacininternamente, y la otra, haciendo que el mecanismo SASL recupere la laversin resumida de la contrasea. La ventaja de usar esta ltima es que no esnecesario guardar las contraseas de usuario en texto plano en el servidor, sinoun resumen unidireccional de stas, con el nombre de usuario y el dominio.An as, el resumen unidireccional del secreto debera manejarse de la mismaforma que una contrasea en texto plano. La ventaja est en que si alguienroba el resumen unidireccional, no podr leer la contrasea del usuarioinmediatamente. Si la aplicacin especifica ambas llamadas, se usar la querecupera el resumen secreto.

68


NTLM emplea el nombre de usuario (la identidad de autorizacin solamente) yla contrasea para autenticar a los usuarios. Slo el lado del cliente esimplementado.

3. ALTERNATIVAS DE SOLUCIN CONSIDERADAS Y JUSTIFICACIN DELAS SOLUCIN ESCOGIDA

Dentro de las alternativas consideradas para la implementacin de un servidor decorreo electrnico seguro, se deban examinar varios aspectos, que se podranresumir de la siguiente manera: seleccin del MTA, seleccin del mecanismo deautenticacin de los usuarios para el control del reenvo de correo, y finalmente,seleccin del cliente Web de correo electrnico.

3.1 Seleccin del MTA

Se consideraron tres alternativas de forma terica: Sendmail, Qmail y Exim; y dosen forma prctica: Sendmail y Exim; que fueron instalados, configurados ypuestos en funcionamiento durante un tiempo, bajo condiciones reales deoperacin, aunque eso s, con una carga y una exigencia muy bajas en el servicio,debido a la poca cantidad de mensajes que tuvieron que procesar.

El trabajo terico consisti esencialmente en una exploracin sobre el nivel deutilizacin de cada MTA en Internet, la cantidad de proyectos vinculados, unalectura de sus caractersticas, forma de operacin, extensiones de seguridad,historial de seguridad, madurez de sus proyectos, y modo de configuracin, etc.

En esta exploracin se encontr que Sendmail segua siendo el MTA mspopular, y el preferido a la hora de buscar caractersticas avanzadas en eltratamiento del servicio de correo. El principal problema del plenoaprovechamiento de todo su potencial, era el profundo conocimiento que habaque tener de la estructura del programa y de su lenguaje de configuracin, parasacar provecho de ellas, lo que haca relativamente tedioso y demorado suproceso de configuracin. Por otro lado, la estructura de Sendmail es monoltica ycualquier nueva funcionalidad que se desease agregar, requera su recompilacin.Sendmail tiene un historial de seguridad bastante conocido, pero la complejidadde su configuracin a menudo lo hacen complicado de asegurar.

La siguiente alternativa considerada fue Qmail, el MTA de Dan Bernstein,desarrollado con los problemas de seguridad ms graves de Sendmail en mente ycon la idea de que la seguridad no fuese la meta, sino el punto de partida. Qmailes famoso por este enfoque, por su modularidad y porque el autor ofrece $1000U.S. a quien encuentre un fallo de seguridad en su cdigo. En varios lugares del

69


sitio Web oficial6, se le promociona como el segundo MTA ms usado delmundo. Existe abundante documentacin a su alrededor y aparentemente esms fcil de configurar y ms flexible que Sendmail.

Finalmente se encuentra Exim, el MTA desarrollado por Philip Hazel de laUniversidad de Cambridge, para ser usado en sistemas Unix/Linux conectados aInternet, y con una fuerte preocupacin por lograr una codificacin impecable ensu construccin. Su diseo original era Similar al de Smail 3, pero con msfuncionalidades. Exim proporciona mecanismos para el control de la proliferacinde SPAM, y proteccin contra los bombardeos de correo electrnico (mailbombing). Es adems un MTA completamente libre7, a diferencia de Qmail, queen el mejor de los casos, son slo de Cdigo Abierto (Open Source).

Existan otras alternativas tales como Smail, que fue descartado por considerarseun proyecto con poco avance, a pesar de haber sido el primer intento serio deconstruir un reemplazo para Sendmail; y Postfix, porque a pesar de ser uno de losprincipales contendientes de Qmail, no presentaba ventajas claras frente a ste.

En diferentes estudios sobre la utilizacin de MTAs en Internet, se encontr quede las alternativas consideradas, efectivamente Sendmail era el que tena unamayor acogida, seguido de Qmail y Exim, intercalndose con Postfix dependiendode la fuente consultada.

Despus de examinar la alternativas existentes, el MTA seleccionado por variasrazones, entre las que sobresalen su fuerte orientacin a la proteccin y el controldel envo de correo no deseado, y su fuerte vinculacin al Proyecto Debian, fueExim. Exim es el MTA de facto para la distribucin Debian GNU / Linux, sugeridoen la instalacin y configuracin del sistema operativo y sus aplicaciones. En estemomento, Exim es un proyecto maduro, con muchos logros y soporte paradiversas extensiones, tales como SMTP STARTTLS/AUTH, esenciales en elservicio de correo electrnico a implementar y que se explicarn ms adelante. Laversin de Exim implementada, fue la 4.30-4 disponible para Debian Sarge.

3.2 Seleccin del mecanismo de autenticacin para el control del envo de correo

Para controlar el envo de correo electrnico desde un servidor, el problema sepuede abordar desde dos perspectivas. La primera de ellas es ejercer un controlsobre las direcciones de los destinatarios del mensaje, que puede ser de pocautilidad porque se restringe la libertad de los usuarios de enviar mensajes a donde

6 http://www.qmail.org/top.html

7 Se distribuye bajo la GNU GPL (GNU General Public License, Licencia Pblica General de GNU)

70


quieran, a un conjunto limitado de destinos; la segunda es filtrar el correoelectrnico segn su origen.

Mientras la primera forma es fcil de controlar, la segunda se puede convertir enun problema: Cul es el origen de una direccin de correo? Es posible basarseen la direccin IP o nombre del host, pero si se quiere determinar el origen de unasolicitud para envo de correo a nivel de usuario, las cosas se complican.

Con la restriccin a direcciones de correo locales para el envo de mensajes, seevita que el servidor sea usado para enviar SPAM a otros destinos, pero no seevita que los usuarios locales lo reciban (en el caso de que el SPAMMER seencuentre dentro de la red local).

Adems, esta alternativa deja por fuera la posibilidad de que un usuario, que seconecte desde un cliente de correo remoto que no le permita acceso directo a lamquina, pueda enviar mensajes. Es decir que si se tienen usuarios empleandoprogramas como el Ximian Evolution o el Microsoft Outlook, a travs de unaconexin por MODEM a un ISP (Internet Service Provider, Proveedor de Serviciode Internet), no van a poder enviar mensajes desde el servidor, a menos que sehabilite el reenvo abierto, con lo que se abre la puerta para que cualquiera use elservidor como fuente de SPAM, contribuyendo al crecimiento de este flagelo, ycomprometiendo los valiosos recursos de la mquina.

Si se usa Sendmail como MTA, este tipo de control se logra modificando elarchivo de control de transmisiones (generalmente /etc/mail/access) de modo quepermita nicamente las transmisiones de los hosts o grupos de hosts autorizadosy rechace cualquier otra peticin. En Exim 4, se consigue definiendo listas decontrol de acceso en /etc/exim4/conf.d/acl

Existe la posibilidad de personalizar el mensaje de error que emite el servidorcuando se rechazan las peticiones de envo, e incluso no emitir ningn mensaje.Con esto se evita que los eventuales spammers reciban alguna informacin sobreel motivo por el cual no fue exitosa su peticin de conexin al puerto 25 alservidor.

De esta forma, se definieron un conjunto de criterios para enfrentar el problemade permitirle un envo controlado a los usuarios que se conectaran en formaremota a travs de clientes de correo y se definieron el siguiente conjunto decriterios para su implementacin:

La aplicacin escogida deba ser fcil de implementar en el servidor de correo,fcil de configurar y sobre todo, deba ser compatible el MTA que seseleccionase para operar en el servidor SMTP.

71


Debido a la escasa experiencia en el uso de programas computacionales de lamayora de los usuarios del servicio de correo electrnico a implementar, laaplicacin escogida debe ser fcil de configurar en el cliente de correoelectrnico (MUA).

As, se encontr que existan esencialmente dos formas de autenticar usuarioscon cuenta de correo en una mquina para permitirles el envo de correo:Mediante tcnicas alternativas o hacks, o implementando SMTPSTARTTLS/AUTH.

Las tcnicas alternativas o hacks, proveen formas menos sofisticadas deautenticacin que no utilizan autenticacin SMTP. La mejor de estas tcnicas esPOP antes de SMTP.

El envo autorizado de correo basado en la autenticacin provista por un demonioPOP modificado (Pop antes de SMTP), permite que usuarios con una cuentavlida en el sistema puedan enviar mensajes desde un servidor de correoelectrnico, si este permite recuperacin de los mensajes en el servidor a travsde los protocolos POP o IMAP.

Con el fin de que la autenticacin de los usuarios se haga en forma segura, losdemonios POP o IMAP que corran en el servidor deben ser preferiblemente POPSe IMAPS (POP e IMAP seguro o sobre SSL/TLS8).

El procedimiento que sigue esta tcnica es sencillo: para enviar mensajes, elusuario primero debe proporcionar su contrasea de acceso al buzn de correoen el servidor y una vez validado, se le permitir el reenvo por un espacio detiempo determinado (se recomienda que ste no sea inferior a 5 minutos nisuperior a 1 hora), despus del cual tendr que revalidarse si quiere seguirenviando mensajes. Esto se consigue obteniendo la direccin IP del usuario atravs de la validacin que realiza POP, permitiendo el envo de correo desde esaIP por un tiempo limitado.

Pop antes de SMTP es una idea de John Levine descrita por Scott Hazen Muellere implementada por Neil Harkins y John Levine. Para implementarlo, se requierenalgunas modificaciones al demonio POP, algunas utilidades, y una adicin sencillaa la configuracin del MTA.

En la primera implementacin que se hizo del servicio de correo electrnico parala Red de Investigacin Educativa, y en la cual se utiliz Squirrelmail como clienteWeb de correo, se utiliz esta tcnica debido a su facilidad de instalacin y

8 TLS (Transport Layer Security, Seguridad de la capa de Transporte) y SSL (Secure SocketsLayer, Capa de Conectores Seguros).

72


configuracin, en comparacin con el trabajo que supona implementar SMTPAUTH/STARTTLS con Sendmail9. La utilidad empleada fue Poprelay10.

SMTP STARTTLS (Extensin de inicio de TLS/SSL para SMTP) es el comandopara iniciar la seguridad de la capa de transporte (Start Transport Layer Security)o en otras palabras, activar SSL.

Segn el RFC 2487, la extensin STARTTLS para SMTP se conforma de lasiguiente manera:

El nombre del servicio SMTP definido es STARTTLS;

la valor de la clave EHLO asociada con la extensin es STARTTLS;

esta clave no tiene parmetros;

se define un nuevo verbo SMTP: "STARTTLS";

no se suman parmetros adicionales a ningn comando SMTP.

La clave STARTTLS es usada para decirle al cliente SMTP que el servidor SMTPpermite el uso de TLS.

El comando STARTTLS es: STARTTLS, sin ningn parmetro. Despus de que elcliente proporcione el comando STARTTLS, el servidor le responder con algunode los siguientes cdigos de respuesta:

220 Listo para iniciar TLS

501 Error de sintaxis (no se permite ningn parmetro)

454 TLS no se encuentra disponible debido a una razn temporal

Un servidor SMTP referenciado pblicamente no debe solicitar el uso de laextensin STARTTLS para distribuir el correo localmente. Esta regla previene quela extensin SMTP dae la interoperabilidad de la infraestructura SMTP deInternet. Un servidor SMTP referenciado pblicamente es un servidor SMTP quecorre en el puerto 25 de un host de Internet listado en un registro MX (MaileXchange, Intercambio de Correo), o un registro A, si no hay registros MX

9 Para mayor informacin se puede visitar: http://www.sendmail.org/~ca/email/auth.html yhttp://www.sendmail.org/~ca/email/starttls.html

10 La sitio Web de este proyecto es: http://poprelay.sourceforge.net/

73


presentes, para el nombre de dominio a la derecha de la direccin de Correo deInternet.

TLS puede proporcionar autenticacin (identificacin de las partes participantesen la comunicacin), privacidad/confidencialidad (la comunicacin no esinterceptada o husmeada), e integridad (el mensaje no ha sido modificado).Emplea diferentes algoritmos para la encripcin, firma, autenticacin de mensajes,etc.

STARTTLS puede ser usado para permitir el envo de correo basado encertificados, y para restringir conexiones entrantes o salientes. Para estepropsito, hay disponibles diversos conjuntos de reglas que requieren algunosmacros nuevos (tales como el tramitador del certificado, el asunto del certificado,la versin de TLS/SSL usada, etc) y el mapa de acceso (que permite definir elacceso al sistema mediante la verificacin de dominios y direcciones de correoelectrnico para aceptar, rechazar y enviar mensajes).

Para usar un MTA con STARTTLS como servidor y como cliente, se necesitaobtener e instalar uno o varios certificados de una CA (CA Certificate Autorithy,Autoridad de Certificado) y modificar el archivo de configuracin que competapara ello.

Estos certificados de una Autoridad de Certificado se necesitan para autenticarsatisfactoriamente a otra entidad. La firma del certificado presentado por lacontraparte es verificada a travs de estas Autoridades de Certificados. Si una deellas emiti el certificado, la autenticacin es considerada exitosa. Es ms,durante el apretn de manos (handshake), los DN (Distinguished Names,Nombres Distinguidos) de estos certificados son enviados al cliente de tal formaque pueda seleccionar apropiadamente el certificado que est firmado por una delas CA.

Ventajas de STARTTLS

Autenticacin: el cliente y el servidor de una conexin SMTP pueden seridentificados.

Privacidad/confidencialidad: la transmisin de un correo electrnico entre uncliente y el servidor utilizando STARTTLS no puede ser leda y retraducida si seha provisto y negociado un paquete de cifrado lo suficientemente seguro.

Integridad: El texto plano de un correo electrnico entre un cliente y un servidorutilizando STARTTLS no puede ser modificado por un adversario si se haprovisto y negociado un paquete de cifrado lo suficientemente seguro.

74


Limitaciones de STARTTLS

Todas estas ventajas son provistas transparentemente por los MTAs sininteraccin con los usuarios. Estos no necesitan tener un software especialinstalado en sus MUAs que sea adicionalmente compatible con el software delrecipiente. Esta es al tiempo, la razn de varias limitaciones:

No proporciona una encripcin punto a punto, por lo que usualmente, unusuario no podr controlar la transmisin completa. Esto contrasta con el usode TLS por HTTP (HiperText Transfer Protocol, Protocolo de Transferencia deHiper Texto): aqu el cliente del usuario (un navegador Web) se conectadirectamente al servidor que provee los datos. El correo electrnico puede sertransferido a travs de mltiples saltos de los que el remitente puede controlaral menos el primero.

No proporciona autenticacin de mensajes, a menos que el email haya sidoenviado directamente desde el MUA del cliente (con soporte para STARTTLS)a los MTA receptores que deben grabar el certificado del cliente. An entoncesel mensaje podra ser falsificado durante el reparto local.

En suma, para obtener privacidad, integridad y autenticacin punto a punto entrelos usuarios se debe usar un software como PGP (Pretty Good Privacy, Privacidadmuy buena) o S/MIME (Secure / Multipurpose Internet Mail Extensions,Extensiones Multipropsito de Correo de Internet Seguras). Esto requiere por lomenos de cierto conocimiento de tal software y un uso responsable de losusuarios finales.

SMTP AUTH (SMTP AUTHentication, Autenticacin SMTP) es una extensin parael servicio de autenticacin del protocolo SMTP.

Consultando el RFC 2554, se encontr lo siguiente:

El nombre de la extensin del servicio SMTP es "Autenticacin";

el valor de la clave EHLO asociada con la extensin es "AUTH".

La clave AUTH EHLO contiene como parmetro una lista de los nombres de losmecanismos SASL (Simple Authentication and Security Layer, Capa deAutenticacin y Seguridad Simple) soportados, separados por espacios.

Se define un nuevo verbo SMTP: "AUTH";

se adiciona un parmetro adicional empleando la clave "AUTH" al comandoMAIL FROM, y se extiende el nmero mximo de lneas del comando MAILFROM en 500 caracteres.

75


esta extensin es apropiada para el protocolo de registro (sumisin o envo)[SUBMIT].

El comando AUTH indica un mecanismo de autenticacin al servidor. Si elservidor soporta el mecanismo de autenticacin solicitado, efecta un protocolo deintercambio de autenticacin para autenticar e identificar al usuario.Opcionalmente, tambin negocia una capa de seguridad para interacciones deprotocolo subsecuentes. Si el mecanismo de autenticacin no se encuentrasoportado, el servidor rechaza el comando AUTH con una respuesta 504.

El protocolo de intercambio de autenticacin consiste en una serie de desafos delservidor y respuestas del cliente que son especficas del mecanismo deautenticacin.

Al servidor no se le pide que soporte un mecanismo de autenticacin especfico,ni se le pide a los mecanismos de autenticacin que soporten ninguna capa deseguridad. Si un comando AUTH falla, el cliente puede intentar otro mecanismode autenticacin empleando otro comando AUTH.

Si un cliente emplea esta extensin para obtener un tnel encriptado hacia unservidor a travs de una red insegura, necesita configurarse para nunca enviarcorreo al servidor cuando la conexin no est mutuamente autenticada y cifrada.De otra parte, un atacante podra robar el correo del cliente suplantando laconexin SMTP, o pretendiendo que el servidor no soporta la extensin deautenticacin, o causando que todos los comandos AUTH fallen.

Antes de que la negociacin SASL haya comenzado, cualquier interaccin delprotocolo es realizada en forma desprotegida y podra ser modificada por unatacante activo. Por esta razn, los clientes y los servidores deben descartarcualquier conocimiento obtenido previamente del otro antes del inicio de lanegociacin SASL en cumplimiento de la negociacin (SASL), que resultar enuna capa de seguridad.

Este mecanismo no protege el puerto TCP, as que un atacante activo puederedirigir un intento de conexin de envo al puerto al protocolo de registro[SUBMIT]. El parmetro AUTH= previene un ataque as de causar el envo deun mensaje sin un envoltorio de identificacin para recoger la autenticacin delcliente de envo.

Un cliente de registro de mensaje puede solicitar al usuario que se autentiquecuando quiera que se informe sobre la disponibilidad de un mecanismocompatible con SASL. Por ello, puede no ser deseable para un servidor deregistro [SUBMIT] informar de la existencia de un mecanismo SASL cuando el usode ese mecanismo no le garantice ningn beneficio al cliente sobre un registroannimo.

76


Esta extensin no pretende reemplazar o ser usada en el lugar de los sistemas defirma y cifrado de mensajes punto a punto tales como S/MIME o PGP. Estaextensin aborda un problema diferente a los sistemas punto a punto; tiene lassiguientes diferencias claves:

Es til generalmente slo dentro de un enclave confiable;

Protege todo el envoltorio del mensaje, no slo el cuerpo del mensaje;

Autentica el registro del mensaje, no la autora del contenido del mensaje;

Puede darle al remitente cierta seguridad de que el mensaje fue enviado alsiguiente salto en los casos en que el remitente se autentica mutuamente conel siguiente salto y negocia una capa de seguridad apropiada.

SASL define dos trminos que son importantes en este contexto: identificador deautorizacin (userid), que es utilizado por las aplicaciones para verificar quoperaciones estn permitidas (autorizadas), y el identificador de autenticacin(authid), que se utiliza para autenticar al cliente, es decir que las credenciales deautenticacin para el cliente contienen el identificador de autenticacin. Estepuede ser utilizado por un servidor proxy para actuar como otro usuario.

SMTP AUTH permite el envo de remitentes que se hayan autenticadosatisfactoriamente. Por defecto, el reenvo est permitido para cualquier usuarioque se haya autenticado a travs de un mecanismo confiable, esto es, uno queest definido a travs de TRUST_AUTH_MECH (lista de mecanismosconfiables). Este mecanismo es til para usuarios mviles y puede reemplazar latcnica alternativa POP antes de SMTP si el MUA soporta SMTP AUTH.

No se recomienda la utilizacin de PLAIN ni LOGIN como mecanismos deautenticacin, a menos que tenga activa una fuerte capa de encripcin, comoSTARTTLS o un tnel SSL externo. Esta es la razn por la que se habla de SMTPSTATTLS/AUTH. Son mecanismos que se complementan para permitir opcionestanto de autenticacin como de encriptacon en un servicio de correo electrnico.

En resumen: cierto nivel de solapamiento entre los dos estndares permitirautenticar clientes TLS mediante certificados, utilizar estos certificados paraautenticar mquinas, renegociar un enlace seguro mediante SASL, y controlar elpermiso de envo a los usuarios (mediante la solicitud de nombres de usuarios ycontraseas).

77


3.3 Seleccin del software para el soporte del protocolo IMAP

El protocolo IMAP (cuya especificacin figura en el RFC 3501) es esencial parasoportar un servicio de correo electrnico completo que permita que clientesremotos se conecten a travs de un MUA. Para su implementacin, existenmltiples alternativas como Courier IMAP, Cyrus IMAP, UW-IMAP, entre otras11.

De las opciones posibles, se escogi UW-IMAP (University of Washington IMAPToolkit). Esta alternativa era conocida debido al trabajo realizado en la primeraimplementacin del servicio de correo electrnico con Sendmail sobre un Red HatLinux 9.0, y haba dado excelentes resultados.

Esta implementacin del protocolo utiliza mbox, que es el formato dealmacenamiento tradicional en mquinas Unix/Linux. En la documentacinexistente sobre UW-IMAP, se explica que no utiliza el formato maildir debido a lasdificultades tcnicas que encierra soportarlo, mientras se mantiene undesempeo, una robustez y se siguen tanto los requerimientos del protocolo IMAPcomo del formato maildir, de manera simultnea.

Por otro lado, aunque existen mltiples estudios sobre el desempeo de ambostipos de formato, todos tienden a mostrar una ligera superioridad en el desempeousando el formato mbox que el maildir para volmenes elevados de mensajes(ms de 10000).

La versin de UW-IMAP implementada fue la 2001a-debian-6, disponible paraDebian Woody 3.0r2. Esta permite tanto conexiones de IMAP seguro (puerto 993),como de IMAP inseguro (puerto 143).

La razn por las que se requera una conexin al puerto no seguro del servicio, esporque el cliente web de correo electrnico (Openwebmail), as lo requera. Noobstante, dado que el servicio de acceso al correo web se implement empleandoSSL, la transferencia de correo y el intercambio del nombre de usuario y lacontrasea con el servidor se hacan de manera segura.

De esta forma, se tenan conexiones inseguras entre la aplicacin Openwebmail yUW-IMAP localmente en el servidor, y conexiones IMAP seguras para los clientesque se conectaran a travs de clientes de correo como Ximian Evolution, Kmail oMicrosoft Outlook.

11 Para conocer una lista ms completa de las implementaciones de este protocolo, puedevisitarse: http://www.imap.org/products/showall.php

78


3.3 Seleccin del cliente Web de correo electrnico

Para la seleccin del cliente Web de correo electrnico, se tuvieron en cuenta unconjunto de criterios, que se pueden resumir a continuacin:

Compatibilidad con el MTA seleccionado.

Soporte para cambio de la contrasea sin necesidad de incluir componentesadicionales.

La aplicacin deba ser software libre.

La aplicacin deba ser usable, en especial en aspectos relacionados con lasfuncionalidades bsicas (ingresar al correo, enviar y recibir mensajes, adjuntararchivos, cambiar la contrasea, etc.)

La aplicacin deba ser compatible con una implementacin segura del ServidorWeb.

La aplicacin deba proporcionar un mecanismo de acceso va Web al serviciode Disco Virtual, que se explicar con mayor detalle en el anexo F.

Estas y otras caractersticas, se evaluaron a travs de un anlisis heurstico deUsabilidad, es decir, guiado por un conjunto de principios que se consideranpautas muy acostumbradas a seguir en el diseo de interfaces Web.

En general, el examen de la aplicacin gir en torno a un conjunto de criteriosderivados de principios bien conocidos en el diseo Web, que los autoresagruparon en:

Diseo Grfico: Claridad en el lenguaje visual, representaciones grficascomprensibles, colores y enlaces estndar, y distribucin adecuada de loselementos.

Percepcin: La percepcin de la interfaz se refiere al nivel de contextualizaciny conciencia que sta es capaz de transmitirle al usuario. Rene elementoscomo: esquemas adecuados de navegacin y bsqueda, ubicacin dentro de laaplicacin, e informacin sobre el estado del sistema y sobre los errores.

Funcionalidad: Se refiere a la capacidad de distinguir y utilizar las opciones dela aplicacin. La interfaz debe facilitar la ubicacin, identificacin ydisponibilidad de las funciones del sistema; as como el pleno control sobre lasoperaciones.

79


Las aplicaciones tenidas en cuenta a lo largo del proyecto para la implementacindel cliente Web de correo electrnico fueron bsicamente: Ilohamail(http://ilohamail.org/), Horde IMP (http://horde.org/imp/), Squirrelmail(http://squirrelmail.org/), y Openwebmail (http://openwebmail.org/). Aparte destas, se examinaron otras que fueron descartadas por la poca madurez de susproyectos, la falta de caractersticas claves, y la ausencia de una interfaz atractivay fcil de usar. Las tres primeras fueron instaladas, configuradas y sometidas apruebas de usabilidad con usuarios reales. En esta primera seleccin, la msopcionada fue fue Squirrelmail, y se mont con Sendmail como MTA.

Efectuando una segunda exploracin para los servicios que deban migrarse deRed Hat Linux 9.0 a Debian 3.1, se confront mediante anlisis heurstico aSquirrelmail con Openwebmail, y finalmente se opt por sta ltima. Las razonespara esta eleccin se debieron en parte a su soporte del Disco Virtual, la sencillezde la interfaz, la calidad de los textos y contenidos que traa para el idiomaespaol, la claridad en los mensajes de error que generaba el programa sisuceda algo, la facilidad con que poda realizarse su configuracin, entre otras.

Openwebmail est orientado al soporte del acceso Web a archivos de correo degran tamao, de una manera eficiente. Est escrito en Perl (Practical Extractionand Report Language, Lenguaje Prctico de Extraccin y Reporte)12, un lenguajeestable, independiente de la plataforma, usado en proyectos de misin crtica y enaplicaciones Web multipropsito.

Dentro de las caractersticas encontradas en la documentacin de ste clienteWeb de correo, sobresalen:

Acceso rpido a las carpetas de mensajes.

Traslado eficiente de mensajes

Menor memoria utilizada que otros clientes Web de correo

Interfaz grfica agradable

Permite el envo SMTP remoto

Soporte para hosts virtuales

Soporte para alias de los usuarios

Amplias opciones de configuracin para el usuario

12 http://www.perl.org/

80


Soporte para varios mtodos de autenticacin

Soporte para PAM

Opcin de bsqueda en todo el contenido

Fuerte soporte para MIME (en presentacin y composicin)

Soporte para carpeta de borradores

Respuesta a correos a travs de utilidades en la interfaz

Incluye una opcin muy completa para hacer correccin ortogrfica

Soporte para filtros de mensajes

Previsualizacin de cantidad de mensajes existentes y procesados

Conversin de codificacin de caracteres automtica

Soporte para Disco Web (Virtual)

Corre en forma persistente a travs de SpeedyCGI (Una utilidad paraincrementar la velocidad de scripts en perl corrindolos de manera persistente).

Soporte para compresin HTTP

4. IMPLEMENTACIN DE LA SOLUCIN

Para implementar el servicio de Correo Electrnico Seguro para la Red deInvestigacin Educativa, con las caractersticas ya explicadas en este Anexo, setrabaj en dos frentes: configuracin del servicio de correo electrnico paraacceso a travs de un cliente Web y de un Cliente Remoto.

El servicio se implemento con la versin de Openwebmail 2.21-3, sobre unservidor Web Apache 1.3.29.0.2-4, con OpenSSL 0.9.7c-5 y libapache-mod2.8.16-7 (soporte HTTPS para Apache); UW-IMAP 2001a-debian-6 para el accesoremoto a los mensajes; y Exim 4.30-4, como MTA.

El nico inconveniente serio que se tuvo en la implementacin de esta parte delservicio, fue la necesidad de recurrir a una versin de UW-IMAP (2001a-debian-6), que permitiera tanto conexiones inseguras (a travs del puerto 143), comoseguras (a travs del puerto 993), pues Openwebmail adoleca de soporte paraconexiones con SSL; no obstante, dado que ambas aplicaciones residan en la

81


misma mquina, no haba ningn problema en que los procesos que corrieran secomunicaran en el interior del servidor de forma insegura. No haba ningnproblema con las conexiones seguras de los clientes a travs de los navegadores,porque el soporte SSL en stos, corra por cuenta de Apache.

La otra parte del servicio de Correo Electrnico, tuvo otros inconvenientes, lamayora de ellos debidos a la necesidad de soportar mltiples agentes de correode usuario diferentes y a menudo incompatibles entre s.

La primera versin de Exim instalada, fue la 3.35-1woody2 (stable). Dado que elproblema que se tena, era que se quera permitir que los usuarios remotospudieran enviar correo desde sus programas cliente, pero no se quera permitirhabilitar esta opcin de forma insegura (por ejemplo, permitiendo el reenvoabierto desde el servidor), lo que se hizo fue instalar y configurar SMTPSTARTTLS/AUTH para permitir el envo controlado.

Con esto en mente, para configurar Exim con soporte TLS, slo se deba instalarun paquete adicional: exim-tls. La versin que a la fecha instala el sistema esexim-tls 3.35-3woody1 (stable).

Para adicionar esta funcionalidad, lo que se debe hacer es generar un certificadoy una llave privada para permitir la creacin de un capa segura a travs de la cualse intercambie la informacin de autenticacin, hacer esta llave nicamente leiblepor Exim, indicarle en el archivo de configuracin la ubicacin de la misma,exigirle a cualquier mquina que solicite envo que se autentique primero, avisarsobre la disponibilidad de TLS a cualquier equipo que haga una solicitud de envode correo, y finalmente proporcionar un mecanismo de autenticacin.

Con esta configuracin se le permite a cualquier MUA que soporte tanto TLS (oSSL) como uno de los tipos de autenticacin disponibles, el reenvo de correo,una vez fuera proporcionado el nombre de usuario y la contrasea de usuario.

La idea inicial, era que los usuarios no tuviesen que recurrir a una nuevacontrasea para autenticarse y enviar correos a travs del servidor, sino que seusara la misma que el usuario empleaba para acceder a su cuenta a travs delcliente Web de correo.Con esto en mente, inicialmente se implement como mecanismo deautenticacin CRAM-MD5, pero se tuvo dificultades a la hora de confrontar lacontrasea resumida enviada por el cliente, con la que se recuperaba del archivocon los datos de los usuarios del servicio de correo. Este archivo era generado a partir del /etc/shadow, por lo que se haca necesariodesencriptar (unshadow) las contraseas en el mismo, para aplicarles luego unafuncin de resumen (hash), y poder hacer la comparacin de la contraseagenerada con la enviada por el cliente.

82


Con el esquema anterior, se realizaron pruebas con el cliente de Correo Kmail1.5.4 (disponible con el entorno de escritorio KDE 3.1.5), con resultadossatisfactorios. No obstante, dado que el MUA que existe por defecto en ms del90% de los computadores de escritorio del mundo es Microsoft Outlook Express,se hicieron pruebas con la versin 6.0 de este programa, y el mecanismo deautenticacin fall. Outlook Express 6.0 es el cliente de correo ms popular entre computadores quefuncionen con el sistema operativo Windows 98/2000/XP, pues se actualiza juntoal Internet Explorer 6.0, que es a su vez el navegador ms utilizado del mundo. Enesta versin, Outlook adolece de opciones para implementar mecanismos deautenticacin como CRAM-MD5 o DIGEST-MD5, aunque permite dos opciones ensu configuracin: iniciar sesin con o sin contrasea de autenticacin segura. Con la intencin de que el mecanismo PLAIN pudiese funcionar con la ltimaopcin (sin contrasea de autenticacin segura), se implement este mecanismo,que tena como principal desventaja el hecho de que ahora las contraseas sedeban almacenar en un archivo en texto plano en el servidor. De nuevo, elsistema no funcion. En la bsqueda del origen de este problema y su eventual solucin, se encontren mltiples listas de discusiones, que la raz del problema se hallaba en que MSOutlook slo era compatible con los mecanismos de autenticacin LOGIN ySPA/NTLM (Secure Password Authentication / NT LAN Manager, Autenticacin deContrasea Segura / Administrador LAN NT) sobre SMTP. Si bien llegados a este punto, lo ideal hubiese sido emplear servicios de directorioo bases de datos para solucionar el problema, estas alternativas se descartaronpor el tiempo de implementacin que supondran, en la medida que habra queentrar a evaluar diferentes alternativas, estudiarlas y probarlas con cierto grado deprofundidad.Se opt por seguir buscando una solucin pronta al problema, y se encontr conque, a pesar de tener un desarrollo orientado a estndares, la version 4 de Exim,inclua un soporte para esta forma de autenticacin propietaria. El lanzamiento de Exim 4, supuso un cambio en varios de los elementos queconstituan al MTA, el ms significativo de los cuales, fue la disgregacin delarchivo de configuracin (/etc/exim/exim.conf) en un conjunto de archivos, quefacilitaba la modularizacin de las tareas de administracin del servicio de correoelectrnico. As que se instalo Exim 4.3 (testing) y exim4-daemon-heavy (y noexim4-daemon-light), porque este era el paquete que proporcionaba el soportepara la autenticacin SPA.Para que la autenticacin SPA funcione, del lado del cliente, y segn pruebasefectuadas con MS Outlook 6.0, se debe tener inactiva la opcin Iniciar sesinusando autenticacin de contrasea segura" en la seccin de configuracin decuentas. En el lado del servidor, el archivo que contiene las contraseas debeestar en el formato: usuario contrasea (separados por un espacio). Este archivodebe estar en texto plano, y su propietario y grupo, deben ser Exim (Debian-exim,

83


en nuestro caso). Por razones de seguridad, se recomienda que los permisossobre este archivo estn ajustados a 400. En realidad lo que importa es que elMTA, tenga permisos de lectura sobre este archivo, bien sea como usuario ocomo grupo.Observacin: Cada vez que se desee modificar la seccin /etc/exim4/conf.d/auth,se debe detener el servicio de SMTP y correr el script: /usr/sbin/update-exim4.confpara hacer efectivos los cambios.

5. RECOMENDACIONES Y TRABAJO FUTURO

A pesar de que el Servicio de Correo Electrnico satisface el conjunto mnimo derequisitos de seguridad con los que debera contar cualquier servidor destinadopara este fin: conexiones exclusivamente a travs de SSL para los clientes delservicio Web de correo, conexiones IMAP seguras y autenticacin SMTP conTLS, para evitar que sea utilizado como fuente de SPAM hacia Internet, ygarantizar que la informacin entre el servidor y el cliente vaya cifrada, esto no essuficiente para tener un servicio lo ms seguro posible.

Se recomienda la inclusin de mecanismos que prevengan que a los usuarios delsistema les llegue SPAM, bien sea instalando y configurado una utilidad con talfin, o empleando los esquemas de suscripcin a listas negras que maneja Exim(una opcin menos efectiva).

A pesar de que el servicio implementado no tendra problemas en sufuncionamiento debido a ataques de virus y gusanos (a menos, claro est, que setrate de una denegacin de servicio y se saturen los recursos de la mquina), sedebe implementar un servicio de antivirus que opere en el servidor, y que impidaque los clientes enven y reciban mensajes de correo electrnico infectados.

84

Correo Seguro

Documents

Transcript of Correo Seguro