Implementación de un sistema de correo seguro para grandes organizaciones, con software libre, protocolos estándares, normas internacionales y firma digital (electrónica).
Introducción
El correo electrónico es, sin dudas, el servicio de Internet más utilizado y popular. Hoy existen más de mil millones de usuarios de Internet con una o más cuentas.
Es también el servicio más complejo, porque requiere de muchos componentes para que funcione. No me será fácil contar mi experiencia en este tema, porque en informática aparecen siglas y palabras nuevas todos los días y los glosarios son muy aburridos. Google puede dar una respuesta rápida a los lectores interesados.
Están ocurriendo una serie de acontecimientos con respecto al correo electrónico seguro. La NIST (National Institute of Standars and Technology) publicó la segunda versión de la guía para el correo electrónico seguro, la Jefatura de Gabinete de Ministros publicó las normas para la implementación de autoridades certificantes de firmas digitales, se venció el plazo para cumplir con la ley de firmas digitales en Argentina y gran cantidad de organizaciones están solicitando correo electrónico seguro con firma digital, grandes empresas involucradas en el correo electrónico (Microsoft, Google, Yahoo) implementaron una serie de políticas para la seguridad del correo y la lucha contra el spam... (la seguridad del correo electrónico es un tema caliente).
Por otra parte, el software libre ha alcanzado una madurez tal que es posible configurar sistemas potentes y seguros sin necesidad de comprarle nada a Billy, aunque debemos reconocer que el tío está un paso adelante y nos da la solución completa, a su precio.
En este artículo describiré cómo implementar un sistema de correo electrónico seguro usando software Open Source (gratuito y código fuente disponible en Internet), que además está siendo usado por muchos proveedores de Internet (y por las empresas que mencioné más arriba).
Lamentablemente no he encontrado en Internet un documento que lo cuente todo. La información está dispersa e incompleta, especialmente sobre LDAP (Lightweight Directory Access Protocol). Espero abarcar todos los detalles para que este documento sea una referencia útil para quienes tengan interés en el tema.
Conceptos
Para la mayoría de los usuarios, el email es creado con un editor y cuando se envía aparece mágicamente en el buzón del destinatario. Parece muy simple, pero como dije antes, lograrlo requiere que numerosos servicios estén disponibles. Todo comienza con el formato de correo, que está especificado en la RFC2822. Este es creado por una aplicación cliente (Outlook, por ejemplo) que se la llama MUA (Mail User Agent) y se envía el email al servidor de correo, llamado MTA (Mail Transfer Agent). Este servidor es el componente más importante del correo electrónico, porque debe almacenar ese mail, dejarlo en el buzón del usuario si éste pertenece a su dominio (para eso usa un servicio llamado LDA - Local Delivery Agent), enviar los mail que no son para su dominio (relay) a los MTAs correspondientes, resolver (mediante DNS) adonde están estos MTAs, autenticar usuarios autorizados para el relay... y otras tareas que se le agregan cada vez más, como tratar los spams, pasar antivirus, aplicar algunas políticas de filtrado... la verdad que los MTAs son incansables trabajadores. Existen propietarios, como MS Exchange y Lotus, y open source como Sendmail, Postfix, Exim y Qmail.
La comunicación entre cliente y MTA para enviar correo, y entre los MTAs, se realiza con el protocolo SMTP (Simple Mail Transfer Protocol). Consiste en una serie de comandos especificados en la RFC2821. Los MTAs modernos soportan ESMTP (Enhanced, o mejorado) que incorpora más comandos. SMTP es el lenguaje de los MTAs, y durante 15 años fue el único protocolo necesario para que funcione el correo electrónico.
El usuario tradicional de los sistemas Unix tenía acceso a su buzón para leer su correo. Pero se necesitaba que usuarios sin una cuenta en el sistema puedan acceder al buzón. Para esto se inventó el protocolo POP (Post Office Protocol), que permitía bajar el correo sin un login en el equipo. Después apareció IMAP (Internet Messaging Access Protocol) para acceder al buzón sin borrar del servidor, luego POP3 que permitía dejar copia en el buzón, e IMAP4 que puede hacer carpetas. Estos dos últimos son los utilizados en la actualidad. Los productos Pop/Imap de software libre son Courier, Cyrus o Dovecot.
Desde que apareció Hotmail se empezaron a utilizar los Webmails, que permiten acceder al buzón y crear los mails a través del explorador Web. El webmail necesita un servidor Web (obvio, no?) e IMAP (no tan obvio) para funcionar. Apache es el Web server más utilizado y se dice que el 80% de los servidores Web de Internet corre con ese software.
Está de moda en todos los sistemas el "login único" o "single sign on". El usuario inicia sesión una vez y ya está autorizado a acceder a varios servicios. La autenticación, administración de cuentas, libreta de direcciones y hasta repositorio de certificados digitales se hace posible a través de LDAP. La mayoría de los servicios de directorio están basados en este protocolo (Active Directory de Micro$oft es un ejemplo). Y en nuestra implementación de correo seguro LDAP se convierte en la columna vertebral del sistema: los servicios accederán a LDAP para obtener información de autenticación, dirección de mail, ruta del buzón, cuota de disco... y los clientes tendrán su libreta de direcciones compartida y certificado digital del destinatario para encriptar el correo. OpenLdap es el software en cuestión, pero una palabra de precaución: no se deja querer fácilmente. Es un protocolo difícil de comprender y un software complejo de configurar, pero una vez que nos hacemos amigos tiene mucho para dar. Las grandes ventajas son su estructura de árbol similar al DNS y la velocidad de lectura, unas 10 veces más rápido que las bases de datos relacionales.
¿En que consiste el correo seguro? No voy a hablar de confidencialidad, integridad... ni de todas esas palabras difíciles que solo entienden los especialistas informáticos. Si partimos de la base de que la seguridad física está controlada (y que no ocurren cosas como que algún usuario deja su oficina con la sesión abierta y el empleado de limpieza tiene tiempo hasta de chatear), el correo electrónico tendría que contar con las siguientes características:
1. Comunicaciones encriptadas. Gmail fue el innovador del servicio gratuito y encriptado. Todas las comunicaciones entre cliente y servidor deben estar encriptadas con TLS/SSL (Transport Security Layer /Secure Sockets Layer). Este mecanismo se basa en la criptografía de clave pública. El servidor envía un certificado al cliente, éste genera una clave al azar, llamada "clave de sesión", la encripta con la clave pública del servidor (que viene en el certificado) y se la envía al servidor, éste desencripta la clave de sesión con su clave privada, a partir de ahí tienen una clave conocida por los dos y utilizan criptografía simétrica (o de "clave secreta", mucho más rápida) para encriptar la comunicación. TLS/SSL está muy difundido, funciona bien y es MUY seguro. Los protocolos tradicionales que lo implementan tienen una "s" al final. Se usará SMTPS en puerto 465, IMAPS en 993, POP3S en 995, HTTPS en 443 y LDAPS en 636. Los números de puertos no se me ocurrieron a mí, son los puertos estándares para esos protocolos.
2. Autenticación SMTP. Hasta hace unos 5 años, tiempos en que todos usábamos la red para comunicarnos con sanas intenciones, no existía la autenticación SMTP (o SMTPAuth). Todos los MTAs aceptaban mails en el puerto 25, los que eran para ellos los dejaban en el buzón, y los otros los enviaban a otros MTAs. Pero aparecieron los spammers, personas que enviaban correo comercial no solicitado y saturaban de tráfico la red. Hoy un MTA en estas condiciones se denomina "Open Relay" y es atacado por los spammers para mandar su basura. Casi en forma automática esa IP (la dirección del MTA open relay) es denunciada por algún receptor que descubre ese comportamiento ante los "Servidores de Listas Negras" y todos los mails que manda ese MTA son marcados como SPAM. Así que ahora se usa la autenticación: sólo los usuarios autenticados pueden hacer relay (se configura en el cliente cuando se coloca "mi servidor de salida requiere autenticación").
3. MX secundarios. Fundamental para la confiabilidad. Cuando el MTA primario no contesta porque está el vínculo caído o porque está ocupado haciendo otra cosa, se produce un timeout (tiempo agotado) y el mail no es recibido. Todos los MTAs intentan varias veces, pero algunos, como Hotmail, no son tan pacientes y desechan los mails si nadie les contesta a tiempo (lo marcan como "bounced" y lo envían al emisor porque no pudo ser entregado por alguna causa). Por eso se deben colocar servidores de correo secundarios, los llamados MX Backup, que reciben el correo que el primario no puede recibir (le hacen el aguante), hasta que los acepte. La ventaja es que nosotros controlamos el timeout de nuestros servidores, y podemos configurar los MX secundarios para que intenten 5 días antes de rebotar algún mail. Si vemos que nuestro servidor de correo primario no recibe los mails durante ese tiempo, entonces tenemos un problema más complejo que la sobrecarga de trabajo.
4. Soportar S/MIME. Creo que conviene aclarar aquí algunos puntos sobre formatos de correo. El mail original es de texto y está especificado en la RFC que mencionamos anteriormente. Luego fue necesario incorporar archivos adjuntos, y se creó el formato MIME (Multipurpose Internet Mail Exchange), que empaquetaba el correo de texto con algún archivo de extensión conocida. O sea, Mime = adjuntos. En la actualidad se está implementando S/MIME v3 (Secure Mime), que especifica el formato de mail firmado y/o encriptado digitalmente. La extensión de un archivo smime es p7m o p7s, ya sea encriptado o firmado. Resumiendo, smime = mime firmado y/o encriptado. Ya todos los clientes de correo electrónico soportan smime. La gran limitación es smime vía Web y la configuración, que debe ser manual y mantenida por el usuario (instalar certificados, lista de revocación, etc). El correo seguro tiene que brindar al usuario la opción de encriptar y/o firmar digitalmente los mails, si lo desea. Esta parte es la más oscura del correo seguro, porque la industria está inmadura en este tema: los usuarios no conocen ni confían en la firma digital, no existen herramientas para el usuario común para la generación y manejo de claves, la administración de certificados en el servidor es una tarea manual y compleja, los certificados vencen, se revocan, se archivan, hay que registrar esas tareas, se complica utilizar S/MIME vía Web... todavía falta un tiempo para que esto se implemente a gran escala, pero sin dudas es lo que se viene.
5. Acceso seguro a certificados. Para completar el soporte S/MIME del punto anterior, será necesario que el usuario acceda a los certificados de los destinatarios en forma simple o casi transparente. Esto es posible con LDAP, agregando el certificado digital como un campo más de los datos del usuario en la libreta de direcciones. Ahora el acceso a esa libreta global debe ser con vínculo encriptado (LDAPS, como dijimos antes) y autenticada con usuario y password. Por supuesto, el mismo nombre de usuario y password que se utilizará para autenticar ante los servidores SMTP, IMAP, POP y Web.
6. Antivirus y antispam. Generalmente los filtros se aplican en tres niveles: Firewall, Servidor y/o Cliente. Muchas veces los filtros en los firewalls no dependen de nosotros, y la configuración en los clientes se diversifica mucho porque cada usuario tiene libertad para instalar cualquier software que encuentre en Internet o le recomiende algún amigo (puede haber políticas de dominio, pero no es muy común). Por eso instalaremos la solución antivirus y antispam en el servidor. Es el nivel en donde tenemos el mayor control. Con respecto al antispam, es un problema complejo que está siendo estudiado por las grandes empresas y por la comunidad académica, y los métodos se están acercando a la Inteligencia Artificial, pero las herramientas actuales permiten controlarlo en un 98% (es decir, solo el 2% de los spam no son reconocidos como tal). La complejidad aumenta porque también hay falsos positivos (un mail solicitado es marcado como spam). Es importante no borrar los mails, sólo marcarlos y que el programa cliente lo almacene en la carpeta de correo basura. Luego el usuario puede aplicar reglas personales si hay algún mail legítimo marcado como spam.
7. Cumplir los estándares (las reglas de la comunidad):
· Las IPs de los MTA deben tener zonas reversas en DNS.
· Deben crearse registros SPF (Sender Policy Framework) en DNS . Sólo las IP autorizadas pueden enviar mails.
· Se debe chequear la salud (salud?... si, salud) de la IP en listas negras, y removerla si se encuentra listada.
· Las cuentas postmaster@dominio.tld y abuse@dominio.tld deben existir en el MTA como especifican las RFC822 6.3, RFC1123 5.2.7, y RFC2821 4.5.1.
· La respuesta al comando HELO del MTA debe ser el nombre DNS del servidor, como especifican las RFC821 4.3 y RFC2821 4.3.1.
· El MTA debe aceptar mails con la forma usuario@[ip-del-servidor] requerido por RFC1123
Ahora que tenemos idea general de toda esta historia del email seguro, podemos elegir el software que cumplirá con los requerimientos.
Software
La siguiente lista de software libre es una buena combinación de aplicaciones para un sistema de correo seguro. Hablaré un poco de cada uno para fundamentar esta elección.
Sistema operativo: Ubuntu 6.10. Una excelente distribución Linux basada en Debian, la tradicional de los gurúes, reconocida por su solidez y el manejo de paquetes.
MTA: Postfix. He probado todos los mencionados anteriormente, pero Sendmail es difícil de configurar y está quedando obsoleto, Exim no es recomendado para muchas cuentas, y Qmail usa Mbox como formato de correo, no Maildir, y se complica la integración Imap. Postfix es el más seguro, confiable y fácil de configurar. Permite usuarios virtuales (que no tienen una cuenta para loguearse en la máquina) e integración con Ldap, además de una avanzada arquitectura de colas.
IMAP/POP: Courier-imap. Tiene el mismo formato de correo que postfix (Maildir) y también se puede integrar con Ldap.
Manejador de contenidos: Amavisd-new. Es un servicio que controla el antispam y el antivirus. Así no tendremos que configurar postfix para que pase antivirus y antispam por separado. Solo tenemos que decirle a Postfix que dialogue con Amavisd-new. Matamos dos pájaros de un tiro.
Antivirus: ClamAV. Creado para escanear buzones de correo. Tiene un servicio adicional llamado Freshclam para mantener actualizada la lista de definiciones de virus.
Antispam: Spamassassin. El mejor antispam Open Source de la actualidad. Tiene numerosos algoritmos para tratar el spam, uno de ellos muy avanzado: el de Bayes.
Autenticación: SASL. Postfix se basa en este servicio para autenticar usuarios que requieran relay de correos. Se puede configurar con Ldap y otros métodos.
Criptografía de vínculos: TLS. Trasport Layer Security versión 1.0 es equivalente a SSL 3.0. Es el candadito amarillo que aparece en los exploradores cuando entramos a un sitio seguro, al banco, por ejemplo.
Certificados: OpenSSL. Permite la generación de claves públicas y privadas, y la emisión de certificados.
Webmail: Squirrelmail. Es una aplicación PHP que se basa en Imap para acceder al correo. Existe una amplia comunidad de usuarios que desarrollan plugins para extender su funcionalidad, y hoy podemos cambiar el password del servidor Ldap, verificar firmas digitales, configurar antispam o filtros, y acceder a la libreta de direcciones global, entre otras cosas.
Libreta de direcciones, base de datos de cuentas y repositorio de certificados: OpenLdap. Es el software Ldap más difundido. Como dije antes, se convertirá en el servicio más sensible y tendremos que tener el administrador más calificado para su administración.
Cliente: Mozilla Thunderbird. Hermano menor de Firefox. Excelente cliente de correo electrónico, que incorpora XUL, Xml User Language, un lenguage que permite extender la interfaz de usuario (agregar toolbars, imágenes, plugins, etc) sin necesidad de recompilar.
De más está decir que si quisiéramos personalizar más estas aplicaciones está disponible el código fuente, pero no se justifica el esfuerzo cuando cumplen casi completamente las necesidades de correo electrónico de una organización.
También se requiere una serie de servicios para que el correo electrónico funcione y sea más eficiente: Bind 9 (DNS), aunque no es necesario que esté instalado en la maquina del MTA, tiene que haber uno en algún lugar porque la ubicación de los MTAs se resuelve con los registros MX en los DNS. Apache 2 (Web server) y PHP 5 (intérprete del lenguaje PHP), para el webmail. PhpLdapAdmin, una aplicación PHP muy intuitiva, para la administración LDAP. NFS (Network File Service) para administrar el espacio en disco (cuota de storage) y no depender de una ubicación física. SSH (Secure Shell, un telnet con vínculo encriptado) para que los administradores accedan remotamente con Putty (el cliente ssh para windows). Y finalmente las extensiones S/MIME de Squirrelmail. ¿Vieron? hacían falta muchos componentes y esto se está volviendo muy complicado. Para tranquilidad de ustedes, con un script se puede instalar y configurar todos estos servicios en 4 horas desde cero.
Esquema General
¿Cómo va a funcionar el correo seguro? El cliente (Thunderbird) envía el mail al MTA (Postfix) al puerto 465 con protocolo SMTPS. Postfix chequea si el email es para su dominio. Si es así, contacta a Ldap para obtener la ruta del buzón y utiliza el servicio Procmail para depositar el mail en el buzón del usuario, que puede estar físicamente en el equipo de Storage. Si no es para su dominio, debe hacer relay, pero antes autenticar al usuario mediante SASL. Este servicio también utiliza Ldap para validar el usuario.
Si el email viene de otro MTA y es para su dominio, se envía al servicio Amavisd-new para ser verificado: Antispam y Antivirus. Conviene, si las cuentas son más de 1000, que este servicio esté en otra máquina, por la intensidad de la carga. Una vez analizado, el mail vuelve a Postfix para que lo deposite en el buzón mediante Procmail.
El cliente también accede a su correo mediante IMAPS y/o POPS. Courier-imap se encarga de autenticar con Ldap.
Para el acceso Web, Apache es configurado con SSL, y finalmente, la conexión con la libreta de direcciones se hace con el protocolo LDAPS y autenticación.
El usuario que solicite un certificado al administrador podrá encriptar y firmar digitalmente sus correos. El procedimiento de instalación del certificado es bastante simple: obtiene un archivo con extensión .p12 (formato PKCS12, conteniendo clave secreta, certificado propio y certificado raíz) en forma manual (en un pendrive o CD), hace doble clic en ese archivo, sigue el asistente, y el sistema operativo ubicará las claves y certificados en los almacenes correspondientes. Se configura Thunderbird para que use su clave secreta, se obtiene el certificados del destinatario de la libreta de direcciones, y ya está: se puede firmar y encriptar todos los emails en forma transparente, sólo hay que activar una casilla que dice "firmar" o "encriptar".
Crecimiento
Los sistemas actuales incorporan el concepto de "escalabilidad". Se supone que todo debe ser concebido pensando en el crecimiento, teniendo en cuenta que el usuario no debe notarlo (debe ser como se dice hoy "transparente"). Inicialmente el prototipo puede ser implementado en una sola máquina, y para que funcione correctamente en Internet, un servidor más como MX Backup, pero se puede ir escalando y distribuyendo las cargas hasta llegar a un robusto sistema distribuido. El primer servicio que se puede separar es el servidor LDAP, contando con su administrador propio: el Ldapmaster (Ldap y certificados) por un lado y el postmaster (que se encarga del resto) por el otro. Van 3 equipos. Luego se pueden crear servidores para IMAP, POP y Web (y separarlos del MTA o SMTP server, que tiene bastante con el envío y recepción de mail en Internet y el manejo de contenidos). Ya tenemos 6 equipos trabajando. Cuando el crecimiento alcanza más de 1000 usuarios o tráfico de 1000 mails por hora, la cosa se pone picante y conviene ubicar el servidor de contenidos (antispam y antivirus) en otro equipo. Finalmente, el storage de los buzones de usuario (lo que nunca alcanza) iría a parar a un servidor NFS. Ocho servidores con sus respectivos administradores, aunque la mayor carga de administración estará en LDAP. De aquí en más es posible incorporar múltiples servidores, gracias a la técnica Round Robin DNS, que consiste en configurar convenientemente el servidor DNS para que responda con diferentes IPs al mismo nombre. Esto es escalabilidad!
Conclusiones
El correo electrónico seguro no es una cuestión simple o resuelta, es un complejo mecanismo en constante evolución bajo estrictas normas que impone la comunidad. Hoy es posible poner en funcionamiento sistemas con el óptimo nivel de confiabilidad y seguridad usando software libre, pero la implementación a gran escala tardará un tiempo. En primer lugar, los sistemas abiertos generan una carga de administración extra que las grandes organizaciones no están dispuestas a afrontar. Con respecto a los servicios de email, articular todos los componentes de los que hablamos requiere administradores capacitados, y en un entorno "microsoft-oriented" no es fácil encontrarlos. Ldap, por otro lado, es una tecnología que funciona, por algo Microsoft, Novell, Oracle y muchos otros se han basado en Ldap para integrar sus aplicaciones, pero no es tan directo de entender y configurar, ni el protocolo ni el software. Para la mayoría de los usuarios, si bien su entorno no va a cambiar demasiado, la firma digital es sólo una teoría que han leído en una revista de tecnología. Uno de los pilares fundamentales de la firma digital es la "confianza", y para confiar en algo, hay que conocerlo. Los usuarios quieren mandar mails, sin preocuparse cómo funciona. Hasta que no haya herramientas que faciliten la tarea y generen confianza en los usuarios, la firma digital será privilegio de pequeños grupos. Habiendo aclarado las posibles trabas en el camino, creo que un sistema de correo seguro con software libre debe ser considerado como una seria alternativa, por las innumerables ventajas que presenta. Para nombrar algunas, por ejemplo, los sistemas de software libre usan estándares consensuados públicamente, productos soportados por múltiples proveedores, aplicaciones interoperables, fáciles de actualizar y mejorar, y lo más importante, se puede confiar en ellos porque está disponible el código fuente, permitiendo conocer lo que hacen.
Referencias
Ubuntu Linux: www.ubuntu.com
Postfix: www.postfix.org
Courier IMAP: www.courier-mta.org/imap
Amavisd-new: www.ijs.si/software/amavisd
SpamAssassin: spamassassin.apache.org
ClamAV: www.clamav.net
SASL: www.imc.org/ietf-sasl
TLS: www.ietf.org/html.charters/tls-charter.html
SquirrelMail: www.squirrelmail.org
OpenLDAP: www.openldap.org
OpenSSL: www.openssl.org
Mozilla Thunderbird: www.mozilla.org
Guidelines for Electronic Mail Security, NIST 800-45v2: http://csrc.nist.gov/publications/nistpubs/800-45-version2/SP800-45v2.pdf
Fuente: Onsi
Saludos
Dr.White
No hay comentarios:
Publicar un comentario