Hermes I Mail Firewall Appliance

Transcripción

1 Hermes I Mail Firewall Appliance Solución para estafeta de correo electrónico con funciones de cortafuegos y control de virus y spam Universidad de Zaragoza Servicio de Informática y Comunicaciones Área de Sistemas Junio de 2004 El servicio de correo electrónico de las organizaciones (sean grandes instituciones o pequeñas empresas) se ha convertido en una infraestructura básica para su buen funcionamiento. No solo es un servicio imprescindible, sino también complejo. En este momento la instalación, configuración y mantenimiento de un servicio de correo de calidad requiere recursos dedicados y sobretodo personal especializado. En los últimos años hemos asistido a la conversión del correo electrónico en una puerta abierta a la entrada de virus, gusanos y basura en general en las organizaciones. Esta situación degrada el servicio de correo, hace perder tiempo y dinero, obliga a dedicar cada vez mas recursos y pone en entredicho la buena imagen de la organización. Un servicio de correo mal administrado se convertirá seguramente en un problema de seguridad para la organización Poner remedio a esta situación obliga a adoptar una arquitectura centralizada del servicio, que fuerce a encaminar todo el tráfico de correo de la organización a través de una o varias estafetas, que actúen de cortafuegos y centralicen todas las medidas de seguridad: autenticación de los envíos, control de acceso, encaminamiento, antivirus y antispam, etc. Hermes I es una solución software pensada y desarrollada para dar respuesta a la necesidad de poner en marcha un estafeta que actúe de pasarela y cortafuegos entre los servidores de correo de la organización y el resto de la Internet. Proyecto Hermes I 1

2 A) ANTECEDENTES, OBJETIVOS Y JUSTIFICACIÓN Problemática y arquitectura del Servicio de Correo. El nacimiento de SMTP (Simple Mail Transfer Protocol), allá por 1982, respondió a la necesidad de disponer de un mecanismo sencillo y eficaz de comunicación entre los usuarios de una o varias máquinas unix conectadas sin una organización jerarquizada. Esto explica la simplicidad de un protocolo caracterizado por el encaminamiento directo: en la dirección de correo se incluye la identificación de la máquina donde reside el destinatario y basta con hacer una conexión con esta máquina para entregar el mensaje. Además, para simplificar las configuraciones y en línea con el carácter colaborativo que caracterizó la internet de los primeros tiempos, todas las máquinas se configuraban por defecto para ser capaces de encaminar cualquier mensaje. Esta característica, conocida como open relaying, permitía por ejemplo que una máquina encaminara cualquier mensaje recibido, independientemente del origen y del destino del mismo. La progresiva masificación de los usuarios del servicio de correo y su dependencia creciente respecto al buen funcionamiento del mismo, la complejidad de los mensajes y la heterogeneidad de los sistemas implicados, así como la aparición de prácticas abusivas, han puesto de manifiesto la necesidad de una regulación del servicio cada vez más estricta por parte de las organizaciones y han obligado a la dedicación creciente de recursos materiales y humanos. Paralelamente, asistimos a la proliferación de máquinas (servidores departamentales, workstations, ordenadores personales, etc) con capacidad para manejar y encaminar correo SMTP pero sin una administración adecuada. Estas máquinas son el objetivo preferente de los spamers para encaminar sus envíos masivos y son presa fácil de los virus. Aunque en este momento todas las nuevas instalaciones vienen configuradas para impedir el encaminamiento indiscriminado de mensajes, quedan multitud de instalaciones antiguas configuradas como open relay que son fuente constante de problemas. Recientemente hemos asistido a la aparición de un fenómeno nuevo, fruto de la colaboración de los creadores de virus informáticos y de los spamers, que se conoce comúnmente como proxy relaying. Una máquina infectada se convierte en un encaminador de correo basura, abriendo puertas traseras, falsificando las direcciones de remite y enviando miles de mensajes sin que, ni el propietario de la máquina, ni los administradores de la red, sean conscientes o puedan evitarlo fácilmente. Como medio de protección frente a correo basura procedente de máquinas mal configuradas o infectadas nacieron las Blacklists (listas negras), accesibles vía DNS que permiten rechazar todos los mensajes procedentes de máquinas Open Relay, máquinas denunciadas reiteradamente o máquinas que no cumplen el estándar SMTP (Simple Mail Transfer Protocol). Muchas organizaciones se han visto implicadas en incidentes de spam que han llevado a su inclusión en una o varias listas negras con los consiguientes perjuicios: rechazo de su correo en muchos sitios, mala imagen corporativa, denuncias, etc Proyecto Hermes I 2

3 La incapacidad para controlar el mal uso de las máquinas de la organización, la aparición de virus, el interés por limitar la cantidad de correo basura llagada a los buzones locales, la necesidad de disponer de un mapa de direcciones de correo coherente, estable y racional, así como la obligación legal de conservar la información relativa a tráfico de correo (origen, destino, fecha, etc) por la Ley Orgánica de Protección de Datos de Carácter Personales, hace necesario la utilización de arquitecturas centralizadas del servicio de correo electrónico. En una arquitectura centralizada: Ninguna máquina interna a la organización puede recibir correo electrónico directamente desde máquinas externas Ninguna máquina interna puede enviar correo directamente al exterior Solamente se deja entrar y salir mensajes con direcciones reconocida El encaminamiento desde el origen al destino se hace indirectamente a través de una o varias máquinas (estafetas) que concentran todas las medidas de seguridad y control de acceso establecidas por la organización. La disposición de estafetas para canalizar el tráfico entre los servidores de correo internos y el exterior añade un grado de complejidad al servicio pero facilita la adopción de medidas de control de acceso y el uso de filtros de detección de virus y spam. En una arquitectura centralizada, todos los esfuerzos pueden concentrarse en la administración y mantenimiento de la estafeta principal, sin tener que preocuparse en exceso por la buena o mala configuración y/o administración de los servidores internos a la organización. Además, la separación de tareas entre las estafetas y los servidores permite descargar a los servidores internos de tareas costosas como la gestión de colas de mensajes y facilita la adopción de nuevas extensiones del estándar: uso de SSL (Secure Socket Layer) en el trasporte de correo, autenticación de los envíos, etc. Para una organización pequeña (unas pocas cuentas de correo, un único servidor de buzones) este desdoblamiento entre estafeta y de servidor puede parecer excesiva si se traduce en la necesidad de dos máquinas distintas y dedicadas. En estos casos, la separación entre estafeta y servidor debe entenderse a nivel funcional, pudiendo encomendar la dos funciones a una misma máquina. El correo electrónico en la Universidad de Zaragoza Aunque desde muy pronto, el servicio de correo electrónico de la Universidad de Zaragoza dispuso de una estafeta encargada del encaminamiento de los mensajes, diferenciada de los servidores de buzones aunque no dedicada, fue a partir de 1996 cuando se inicia un proceso de centralización de la arquitectura del correo electrónico, eliminando servidores unipersonales y haciendo que todos los servidores (centrales y departamentales) encaminaran su correo a través de las estafetas centrales. Este proceso culmina a mediados de 2003 con el cierre del puerto 25 (dedicado a la comunicación SMTP) tanto de entrada como de salida. De esta manera, toda la mensajería es procesada por la estafeta principal, permitiendo hacer un chequeo exhaustivo de los mensajes en busca de virus o spam. La criticidad de este servicio obligó a montar un sistema con hardware dedicado y dispuesto en alta disponibilidad. Proyecto Hermes I 3

4 Desde el principio, el personal responsable del servicio de correo de la Universidad ha participado en los foros de discusión coordinados por RedIris y desde 1998 se ha participado regularmente en las Jornadas Técnicas y Grupo de Trabajo llevando comunicaciones, proponiendo soluciones y coordinando grupos de trabajo sobre los problemas que han ido apareciendo en torno a este servicio: seguridad en el trasporte de correo electrónico (grupo GT-SMAIL), autenticación (SMTP AUTH y SASL), centralización y medidas antispam y antivirus, etc Zaragoza, junto con RedIris, la Universidad Rovira Virgili de Tarragona y otras, impulsó el lanzamiento del Proyecto PUAS (Plataforma Unificada Antispam) para la creación de listas negras de spamers denunciados en la comunidad académica española. En mayo de 2002, Zaragoza acogió una reunión de varias universidades para definir unos criterios de calidad para servicios de correo electrónico. Esta iniciativa se tradujo en el Proyecto RACE (Red Académica de Correo Electrónico) que emite unos certificados a las organizaciones que cumplen con los criterios de calidad establecidos. Para hacer frente a la amenaza de la propagación de virus a través del correo electrónico que comenzó a aparecer con fuerza en el verano de 2001 (aparición del virus Sircam), en unizar se desarrolló la utilizad Tamiz, que facilitaba el chequeo de mensajes en el momento de ser procesados por la MTA. Esta utilidad se incluyó en las páginas oficiales de Sendmail y esta siendo utilizada por varias organizaciones españolas y extranjeras. Entre diciembre de 2003 y marzo de 2004, el SICUZ desarrolla Criba, utilizad con una filosofía parecida a Tamiz pero especializada en el control de Spam. Este desarrollo dio respuesta a la política definida por la Universidad de Zaragoza frente al spam y en este momento esta siendo utilizada en 3 universidades españolas: Zaragoza, Vigo, Politécnica de Valencia y esta siendo estudiada en otras (Navarra, Valencia, Politécnica de Cataluña, etc). Los resultados satisfactorios obtenidos por la estrategia antiespam desplegada en la Universidad de Zaragoza ha atraído la atención de otras instituciones de nuestro entorno geográfico y de la Red Académica abriéndose la posibilidad de establecer acuerdos de cooperación entre ellas. En Mayo se presento Criba en el Foro AST de Seguridad Informática y se va a presentar en las Jornadas Zaralinux (17 de mayo de 2004) y en los XVII Grupos de Trabajo de RedIris que se celebran los días 17 y 18 de mayo de 2004 en Madrid. Muy ligado al uso de Criba en varias universidades y para cubrir uno de los aspectos de la política antispam adoptada aquí (publicar la información relativa al volumen y origen del spam detectado) nació SANET, proyecto liderado por la Universidad de Zaragoza y RedIris que tiene como objetivo centralizar en un portal especializado la información sobre el spam detectado y rechazado por las organizaciones participantes. En este momento esta en proceso de afianzamiento, pretende ser el observatorio del Spam en España y lleva camino de convertirse en un referente importante sobre el spam para la comunidad hispanohablante. Proyecto Hermes I 4

5 Experiencia Experiencia Aportaciones Interés Existencia Así pues, la presentación de la iniciativa Hermes I desde el Servicio Informático y de Comunicaciones de la Universidad de Zaragoza (SICUZ) esta justificada por: acumulada por el SICUZ en la administración de un Servicio de Correo complejo. en el desarrollo de soluciones antivirus y adopción de estrategias antispam. recibidas desde otras organizaciones de la red académica manifestado por otras instituciones aragonesas en adoptar estrategias similares a las nuestras. de un equipo de personas cohesionado y experimentado en proponer, coordinar y desarrollar soluciones a problemas relacionados con el correo electrónico. El grupo de administración del servicio de correo electrónico de la Universidad de Zaragoza ha demostrado repetidamente su experiencia en estos temas, ha liderado iniciativas relacionadas con el servicio y esta en disposición de ofrecer a la comunidad una solución completa, sencilla, ampliamente aceptada y utilizada en el entorno académico, pensada para adaptarse fácilmente a nuevos desafíos y basada en software libre. Soluciones existente y destinatarios de la solución propuesta La problemática que hemos ido viendo ha llevado al convencimiento de que es necesario dedicar esfuerzos a las tareas de control de acceso al servicio de correo de las organizaciones. La necesidad (física o lógica) de disponer de una estafeta de correo que centraliza todas las medidas de seguridad esta ampliamente aceptada. Para las tareas de encaminamiento de mensajes (Mail Trasnfer Agent) han existido desde siempre soluciones propietarias, aunque herramientas libres como Postfix o Sendmail siguen siendo las mas utilizadas. También hemos asistido a la proliferación de soluciones antivirus y antispam, siendo este un sector empresarial importante y en crecimiento constante. Aunque inicialmente escasearon, en este momento existen soluciones libres para la detección de virus y spam (ClamAV y SpamAssassin, por ejemplo) que están a la altura de cualquier software propietario. También han aparecido soluciones para su integración con el sistema de correo electrónico como Amavis, Tamiz, Criba o ScanMail que funcionan satisfactoriamente y en algunos casos incorporan funcionalidades (control de flujo, alertas condicionales, acciones personalizadas, etc) ausentes en las soluciones propietarias Sin embargo, la herramientas libres resultan en general complejas de instalar, configurar y administrar para un usuario no experto. Esto explica en buena medida la penetración en el mercado de soluciones comerciales, en base a su supuesta sencillez de manejo y configuración y a su presentación como una solución integrada y sencilla. Unas basadas en componentes libre y otras en propietarios, pero en todos los casos conocidos ofreciendo un conjunto final propietario, existen soluciones que tratan de dar una respuesta global al problema planteado aquí: MXtrem, SecureBox, -sss, IronPort, etc. combina software y hardware para ofrecer una solución tipo appliance, aunque, excepto IronPort, ninguna de ellas parece suficientemente implantada. Proyecto Hermes I 5

6 El proyecto que presentamos (Hermes I) pretende dar respuesta a la necesidad de disponer de una estafeta de correo que incorpore todos los mecanismos de control y protección necesarios mediante la combinación de productos libres de reconocido prestigio y probada eficacia, dispuestos de tal manera que sea fácil su configuración y manejo. Hace tiempo que la Universidad de Zaragoza, para su servicio de correo electrónico dispone de un despliegue similar al expuesto, basado en la misma filosofía, aunque sin la cohesión con la que pretendemos presentarlo aquí. Nuestro principal aportación es la selección, configuración y documentación de todas las herramientas necesarias, la creación de un entorno amigable para su utilización y su empaquetado en forma de distribución temática. Por esto, el primer destinatario del desarrollo de Hermes sería el propio Servicio de Correo de la Universidad de Zaragoza, que ganaría en robustez, simplicidad y manejabilidad. Como segundos destinatarios están las organizaciones públicas de nuestro entorno regional que ya se han interesado por ella como le Ayuntamiento de Zaragoza y Aragonesa de Servicios Telemáticos. Es de suponer que otras organizaciones similares también pudieran estar interesadas: diputaciones provinciales, otros ayuntamientos, etc. En el entorno académico, la solución global o al menos todo el paquete especializado en el filtrado de mensajes para la detección y rechazo de spam y virus, sería utilizado por las organizaciones que en este momento utilizan las herramientas antispam (Criba) y/o antivirus (Tamiz) desarrolladas por nosotros: Universidad de León, Universidad de Burgos, Universidad de Deusto, Universidad de Navarra, Universidad Politécnica de Valencia, Universidad de Valencia, Xarxa Telematica Educativa de Catalunya, University of Patras e Institute of Mathematics of Polish Academy od Sciences. En este mismo entorno, es de suponer que atraería la atención de organizaciones que estaban interesadas en las soluciones antispam y antivirus desarrolladas por la Universidad de Zaragoza pero que no podían compatibilizar con el software utilizado para MTA: PostFix, Qmail, etc Por sus características de sencillez e interoperabilidad y su filosofía de appliance, es la solución ideal para pequeñas y medianas empresas que disponen de su propio servicio de correo electrónico, pero no disponen de personal especializado. Proyecto Hermes I 6

7 Objetivos perseguidos En lo dicho hasta ahora ya hemos mencionado algunos de los objetivos perseguidos en este proyecto de desarrollo, posteriormente insistiremos y ampliaremos otros. Pero ahora vamos a hacer un repaso conciso de los mas importantes: 1) Ofrecer una solución de calidad para las tareas de estafeta de correo electrónico, con soporte para el encaminamiento de mensajes, dominios virtuales, control de virus y spam, generación de estadísticas sobre el servicio, etc. 2) Aportar la experiencia acumulada en el entorno universitario al diseño y ejecución de soluciones que faciliten el desarrollo de la sociedad de la información en nuestra comunidad autónoma y fuera de ella. 3) Materializar el desarrollo en una distribución temática, en soporte CD-ROM, cuya instalación y configuración en un hardware dimensionado adecuadamente, permita la puesta en servicio de un auténtico firewall de correo electrónico. 4) Ofrecer una solución, compatible con la infraestructura existente en las organizaciones para servidor de buzones y gestión de usuarios, que de respuesta a las necesidades de seguridad en el servicio de correo para organizaciones medianas y pequeñas que no disponen de personal especializado y capaz de escalar de forma razonable para poder responder también a las necesidades de una organización grande. 5) Favorecer de esta manera la difusión de las tecnologías de la información en unas condiciones de seguridad y calidad que sean base para el desarrollo e implantación de servicios telemáticos de muy variada índole: teleformación, teletrabajo, comercio electrónico y, en general, cualquier herramienta que favorezca la comunicación entre personas y organizaciones. 6) Integrar exclusivamente componentes software libre y desarrollando las utilidades necesarias bajo licencia GPL. 7) Liberar el resultado final bajo licencia GPL Proyecto Hermes I 7

8 B) DESCRIPCION: CARACTERISTICAS Y COMPONENTES Las características principales del sistema son: 1) Su instalación no debe requerir personal especializado en correo electrónico El sistema debe poder ser desplegado, configurado y administrado por personal informático no especializado en la problemática del correo electrónico. Debe contar con un instalador gráfico que incluya la parte de sistema operativo, así como cada uno de los módulos. La idea es la de ofrecer una solución tipo appliance ( caja negra ), preconfigurado y optimizado para realizar su cometido. En la práctica, el proyecto se concretará en un CD-ROM con todas las herramientas necesarias para su instalación en una plataforma tipo PC. 2) Todos los módulos deben ser implementados utilizando Software Libre En este momento el Software Libre dispone de productos de calidad que garantizan la seguridad y escalabilidad del sistema. Pretendemos ofrecer una solución integradora de los productos existentes, completada con desarrollos propios para aquellos aspectos que no cuentan con una solución satisfactoria. Entendemos que el desarrollo por la Universidad de Zaragoza de productos bajo el paradigma del software libre, supone revertir a la sociedad parte de la inversión realizada en educación y en investigación. 3) Ofrecer una solución completa pero abierta y estándar Aunque para la mayoría de los usuarios la solución empaquetada sera suficiente y satisfactoria, no queremos hipotecar la evolución del sistema para los que deseen utilizar la distribución como primer paso de su sistema. Todos los componentes incluidos pueden encontrarse documentados en la red y se incluyen en nuestra distribución ajustándose lo mas posible a las recomendaciones dadas por cada uno de ellos. La modificación manual de parámetros no incluidos en el interface gráfico debe ser compatible con la utilización del mismo. 4) Minimizar las tareas de administración y configuración del sistema Todas las tareas de configuración y administración necesarias para el funcionamiento del sistema están agrupadas en un interface web, simple, completo y autodocumentado. Nuestro objetivo es ofrecer una solución sencilla que sirva al 90% de las organizaciones, antes que una solución compleja que cubra las necesidades del 100% de los casos. Quedara abierta la posibilidad de que el sistema pueda ser configurado, administrado y monitorizado desde una empresa especializada, incluyendo el soporte necesario para ello. Proyecto Hermes I 8

9 5) Securizar completamente el sistema y cada uno de sus componentes. Uno de los requisitos mas importantes es el de la seguridad. El sistema debe ofrecer solución a un problema sin convertirse en un problema en sí mismo. El Sistema se ofrece totalmente cerrado y ajustado a su tarea de ser un firewall de correo electrónico. El acceso a la administración del sistema se permite exclusivamente utilizando protocolos seguros (ssh y https) y solamente desde los orígenes que se especifiquen en la instalación. Contará con scripts de chequeo automático y periódico de los mecanismos de seguridad, avisando de posibles cambios en la integridad del sistema. 6) Disponer de un sistema de monitorización completo y estándar Se dispondrá de un mecanismo de monitorización para todos los módulos empaquetados en el sistema, conectado con mecanismos de alarmas y accesible mediante protocolo SNMP (Simple Network Manager Protocol) El sistema no requerirá una atención directa y continuada. Esto obliga a ofrecer un sistema de alarmas flexible y completo. 7) Facilitar la escalabilidad del sistema con recursos proporcionados. El sistema esta pensado inicialmente para un funcionamiento atómico e independiente dentro de la infraestructura de correo de las organizaciones. Debemos primar la simplicidad en aras de la seguridad y manejabilidad del sistema. Aún así, somos consciente de la evolución creciente que sufre el correo electrónico y no debe hipotecarse la posibilidad de ampliar el sistema de acuerdo a las necesidades de cada momento. Para ello se deberá incluir soporte para la escalabilidad del sistema mediante la configuración de un sistema de alta disponibilidad con balanceo de carga. 8) Compatibilidad con la infraestructura de correo electrónico existente en la organización. Un problema que surge a la hora de instalar determinadas soluciones libres para el control de virus y spam en los servicios de correo es la de hacerlos compatibles con toda la infraestructura existente. La solución que se propone se basa en aislar la función de estafeta central de correo de los servidores encargados de mantener los buzones de los usuarios. De esta manera, cualquier organización, independientemente del sistema de correo utilizado, puede instalar el sistema sin tener que cambiar el restos de componentes del servicio. Esta solución ofrece una protección perimetral para el servicio de correo y para su explotación adecuada debe basarse en una topología centralizada del servicio, encaminando todo el tráfico a través de la estafeta principal. Proyecto Hermes I 9

10 Encaminamiento Gestión Comunicar Gestión Opcionalmente, Generación Los módulos que integran es sistema son: 1) Sistema Operativo Barajamos dos alternativas, basadas en GNU/Linux, que no son excluyentes: 1) Hacer una distribución que incluya un sistema operativo especialmente ensamblado para el cometido de firewall de correo electrónico. En esta distribución se incluirán todos los paquetes necesarios, así como los asistentes para la instalación y configuración. 2) Ofrecer el paquete de aplicación para instalar sobre la base de una distribución Linux conocida (Redhat, Debian, etc). En este caso la instalación, configuración y securización del sistema seria responsabilidad del usuario. Todos los componentes del sistema estarán configurados y ajustados para la tarea a desempeñar, sin que sean necesarios conocimientos especiales sobre el S.O. 2) Software de MTA (Mail Trnasfer Agent) La principal tarea a realizar por el sistema es la de encaminar el correo entre la organización y el exterior, así como entre los distinto servidores internos. Para esta tare hemos optado por Sendmail, software utilizado mayoritariamente, muy conocido y documentado y con un excelente soporte para su integración con sistemas de filtrado de mensajes. La utilización de Sendmail aquí es totalmente compatible con el uso de otra software de MTA en los servidores de correo internos. El software de MTA dará respuesta a las tareas de: de mensajes entre los servidores internos y entre estos y el exterior de colas de mensajes, descargando a los servidores internos. con los sistemas antivirus y antispam de dominios y direcciones virtuales autenticación de los mensajes enviados por los usuarios de la organizaciones del fichero de log La configuración inicial, los parámetros de funcionamiento y las tareas de administración (arranque y parada, monitorización, gestión de colas, etc) será, accesibles desde el entorno web de administración. El servidor SMTP incluirá autenticación mediante la extensión SMTP AUTH y soporte para acceso a LDAP. Proyecto Hermes I 10

11 Todos Para Permite Se Pueden Filtros Uso El Uso Se 3) Antivirus y Antispam Estas tareas se encomiendan a las utilidades Tamiz (con el antivirus Clamav) y Criba (con en analizador de contenidos SpamAssassin). Ambas utilidades han sido desarrolladas por la Universidad de Zaragoza y, como ya hemos comentado, se están utilizando de forma satisfactoria en varias universidades. Para incluir en la solución propuesta se optaría por una nueva versión de Tamiz (Tamiz+) simplificada (solamente con soporte a Clamav) y completada con las capacidades antispam incluidas en Criba. Esto facilitará su instalación y configuración, ganando en simplicidad y eficacia. Sus características principales son: los mensajes se chequea antes de ser aceptados. analizar los mensajes se utiliza el antivirus Clamav definir acciones (rechazar, avisar, eliminar, etc) según el virus hace un control de flujo por IP utilizarse una o varias Listas Negras para chequear la procedencia Bayesianos y Heurísticos para analizar el contenidos (SpamAssassin) de sistemas distribuidos de firmas de spam (Vipul's Razor) spam se marca o rechaza según destinatario y de diferentes modos de sistemas de cuarentena genera un completo fichero de log 4) Sistema de explotación de estadísticas Una de las herramientas mas importantes para administrar adecuadamente un servicio de correo electrónico es disponer de información en tiempo real sobre la evolución del tráfico, sobre los flujos de información, sobre el comportamiento del sistema en momento de carga máxima, etc. Solamente disponiendo de información estadística podremos dimensionar adecuadamente los recursos y prever las necesidades futuras. Como fuente de información para las estadísticas se utilizará combinadamente la información de log generada por el MTA y por los sistemas antivirus y antispam. Para la generación de estadísticas se utilizara el paquete SMA (Sendmail Log Analyzer) combinado con un sistemas de representación gráfica tipo RMTG y/o RRDBtool Se incluirá un procedimiento especial para extraer de los log la información necesaria para enviar a SANET ( y a RESACA ( Estos envíos se activarán y desactivarán voluntariamente. 5) Monitorización El funcionamiento global del sistema, así como el de cada uno de sus módulos debe estar monitorizado continuamente, estar accesible desde el entrono web de administración y ser compatibles con sistemas de gestión de red tipo OpenView Proyecto Hermes I 11

12 Además del sistema de monitorización interno se dispondrán mecanismos para poder comprobar el buen funcionamiento de las rutas externas de envío/recepción de mensajes. Para cumplir estos requisitos se utiliza una combinación de herramientas desarrolladas explícitamente, herramientas especializadas en la monitorización de sistemas (mon) y utilidades incluidas en los paquetes que dan soporte a la alta disponibilidad (ldirector de Ultra Monkey) La monitorización del sistema sera accesible vía SNMP. Para ello se utilizara las utilidades desarrolladas por el proyecto Net-SNMP (inicialmente conocido como ucd-snmp). 6) Interface de administración El principal componente para que el sistema cumpla las características de appliance que se pretende, es disponer de un interface simple, homogéneo y suficiente para configurar y administrar cada uno de los componentes. Se utilizará un interface web que permitirá el acceso a las tareas de administración, al sistema de monitorización y a las estadísticas. Para esto, el sistema incluirá un servidor web Apache. Para facilitar la administración del sistema, se incluirá soporte para que puedan repartirse las tareas de administración entre varias personas. También debe incluir soporte para la administración centralizada cuando la instalación cuente con varios sistemas trabajando en modo cluster Este modulo debe ser desarrollado íntegramente. Para ello se utilizará una combinación de HTML, Perl y PHP. Los CGI's actuarán, ajustando los ficheros de configuración propios de cada módulo y deberá ser compatible con la modificación manual de los mismos. 7) Soporte a la Alta Disponibilidad Uno de los requerimientos importantes del sistema es que pueda escalar hacia una arquitectura de alta disponibilidad y/o balanceo de carga a un costo razonable y sin la necesidad de utilizar elementos hardware externos al sistema (como Switch nivel 4, por ejemplo). El sistema incluirá soporte a la A.D. mediante la utilización de software de cluster utilizando las herramientas desarrolladas por el proyecto Ultra Monkey Todos los los sistemas de monitorización y gestión estarán preparados para manejar un sistema de estas características. 9) Copias de Seguridad Por su versatilidad se opta por utilizar rsync para mantener un sistema de copias de seguridad barato y eficiente del sistema, sin necesidad de utilizar hardware específico. Esto,además, facilitará las tareas de sincronización de archivos en caso de utilizar varios equipos en modo cluster. Proyecto Hermes I 12

13 8) Soporte a TLS y certificación Todos las comunicaciones entre el interior y el exterior (vía http, smtp, etc) deben estar securizadas mediante la utilización de TLS y certificados X509 Los certificados necesarios para ello deben ser proporcionados por la organización aunque inicialmente se proporcionaran unos certificados provisionales firmados por la CA del proyecto. Esto permitirá desde el primer momento utilizar las características de cifrado ofrecidas por el protocolo TLS, y permitirá al administrador comprender desde el principio el alcance de usar estas tecnologías. C) RECURSOS NECESARIOS Los componentes principales del sistema son conocidos y ampliamente utilizados y documentados. También conocemos suficientemente la problemática que se pretende abordar y tenemos experiencia en desarrollos similares al propuesto. Esto hace que una buena parte de la solución este avanzada, en unos casos en el desarrollo y en otros en el análisis. Sin embargo, la necesidad de ofrecer una solución compacta, sencilla de comprender y utilizar y completamente documentada y probada exigen la dedicación de recursos materiales y humanos específicos. Pensando en poder disponer de una versión operativa para finales de año, se requiere la contratación de dos programadores por un periodo de 6 meses. Uno de los programadores estará especializado en el desarrollo de interfaces web, con experiencia en lenguajes HTML, Perl, PHP, JavaScrip y con aptitudes para la documentación de servicios. El otro programador responderá a un perfil especializado en sistemas operativos, con experiencia en GNU/Linux, creación de distribuciones personalizadas, mecanismos de seguridad y sistemas de alta disponibilidad. Deberá aportar la documentación técnica necesaria. Al trabajo de estos dos programadores hay que añadir nuestra participación en tareas de coordinación del proyecto, así como la participación directa en el desarrollo e implantación de algunos de lo módulos. Estas aportaciones, quedarán enmarcadas dentro de nuestra dedicación a las tareas habituales de administración del servicio de correo electrónico dentro del SICUZ. En cuanto a los recursos materiales, es necesario contar con equipamiento informático para que puedan trabajar los dos programadores, más un equipo dedicado a las pruebas de instalación, configuración y puesta en servicio. Proyecto Hermes I 13

14 El cuadro general de gastos quedaría así: Origen Categoría Periodo y dedicación Costo en Euros Personal contratado Programador 6 mese Personal contratado Programador 6 meses Personal interno Analista 6 meses 20% dedicación 5800 Personal interno Analista 6 meses 10% dedicación 2900 Personal interno Programador 6 meses 13% dedicación 3300 Material Ordenador Estándar ofimática 1200 Material Ordenador Estándar ofimática 1200 Material Ordenador Servidor medio 3600 Total gastos estimados Este proyecto será cofinanciado por la Universidad de Zaragoza y el Gobierno de Aragón. La Universidad de Zaragoza asume el 33% de los gastos, que corresponden a la dedicación del personal interno en tareas de desarrollo y coordinación. El Gobierno de Aragón asumirá el 67% restante para cubrir la contratación de personal externo y adquisición de equipamiento, a través de la subvención solicitada al Departamento de Ciencia, Tecnología y Universidad. La tabla de gastos subvencionables sería: Origen Categoría Periodo y dedicación Costo en Euros Personal contratado Programador 6 mese Personal contratado Programador 6 meses Personal interno Analista 6 meses 20% dedicación 0 Personal interno Analista 6 meses 10% dedicación 0 Personal interno Programador 6 meses 13% dedicación 0 Material Ordenador Estándar ofimática 1200 Material Ordenador Estándar ofimática 1200 Material Ordenador Servidor medio 3600 Total gastos subvencionables En los gastos no se incluye el costo de publicación y difusión del paquete de software resultante, ni de su posterior mantenimiento, ya que depende de la aceptación que se consiga y de la difusión que quiera darse al desarrollo. Desde mediados de Junio hasta mediados de Septiembre contamos con la colaboración de un estudiante del Proyecto Erasmus que debe realizar una práctica para su centro de origen en Francia: ENSEIRB (Ecole nationale supérieure d'électronique, informatique et de radiocommunications de Bordeaux). Esta colaboración nos permitirá el desarrollo de una versión piloto que será el banco de pruebas ideal de los distintos módulos y alternativas, así como de su integración. Proyecto Hermes I 14

15 Un primer desglose de tareas puede verse en el cuadro siguiente: Módulos Tareas Coordin. Desarrollo Sistema Operativo Selección base S.O. BP Programador 1 (6 semanas) Instalador BP Programador 1 Módulos BP Programador 1 Securización BP Programador 1 Instalación BP Programador 1 MTA (2senamas) Compilación Sendmail PP Interno Configuración PP Interno Preinstalación PP Interno Tamiz+ (6 semanas) Integración PP Interno Nuevas opciones PP Interno Documentación PP Interno Estadísticas (3 semanas) Evaluación alternativas PP Interno Configuración PP Interno Gráficos BP Interno Envío Sanet/Resaca PP Interno Monitorización (5 semanas) Selección Software PP Programador 1 Implementación SNMP PP Programador 1 Desarrollo Utilidades PP Programador 1 Interface web (12 semanas) Preconfigurar Apache PS Interno Definir entorno gráfico PS Interno Asistente S.O PS Programador 2 Asistente MTA PS Programador 2 Gestión de Colas PS Programador 2 Asistente Tamiz+ PS Programador 2 Asistente Monitor PS Programador 2 Asistente Actualizaciones PS Programador 2 Asistente Backups PS Programador 2 Presentación Estadísticas PS Programador 2 Acceso documentación PS Programador 2 Proyecto Hermes I 15

16 Módulos Tareas Coordin. Desarrollo Alta Estudio alternativas PP Interno Disponibilidad Probar topologías PP Programador 1 (4 semanas) Incluir soporte PP Programador 1 Seguridad (4 semanas) Definir criterios BP Interno Configurar herramientas BP Programador 1 Soporte a SSL BP Programador 1 Auditoría Seguridad BP Programador 1 Documentación (9 semanas) Selección documentación PS Interno Documentación Tamiz+ PS Interno Documentación General PS Programador 2 Documentación Usuario PS Programador 2 Documentación Técnica PS Programador 2 Documentación S.O. PS Programador 2 Backup (2 semanas) Seleccionar sistema PP Interno Backup D&R PP Programador 1 Backup configuración PP Programador 1 Backup histórico datos PP Programador 1 Pruebas, implantación,etc (todo el periodo) Pruebas instalación Piloto en Unizar Piloto externo Difusión Interno Interno Interno Interno Desarrollo Piloto (8 semanas) Creación distribución Instalación Sendmail Instalación Tamiz y Criba Entorno web Pruebas cluster y monitorización Prácticas Erasmus Prácticas Erasmus Prácticas Erasmus Prácticas Erasmus Prácticas Erasmus Prácticas Erasmus Proyecto Hermes I 16

17 C) DESARROLLO TEMPORAL. FASES Aunque la problemática derivada de la proliferación de virus y spam viene de lejos, en este momento se esta haciendo insoportable para las organizaciones que disponen de su propio servicio de correo electrónico. Si en ahora el volumen de spam ronda el 45% de correo, se hacen estimaciones de que en el plazo de meses puede superar 70%. En estas condiciones pensamos que seria razonable contar con una solución satisfactoria para finales del Con esta perspectiva hemos calculado el desarrollo temporal del proyecto y los recursos humanos que deben dedicarse a su implementación. A modo orientativo podemos resaltar las siguientes fases: 1) Desde Junio a Septiembre: Las tareas se centran en la definición detallada del proyecto, sus características y sus módulos, así como en la selección del software a incluir. Además es necesario formar el equipo de trabajo, incorporar al personal específico y trasmitirle la idea, los métodos y los objetivos perseguidos. Se creara el sitio web para el proyecto y se colocarán las primeras informaciones sobre el mismo. Paralelamente, entre mediados de Junio y mediados de Septiembre se desarrollará una versión piloto para probar el comportamiento de los distintos módulos y los problemas derivados de su integración. 2) Septiembre y Octubre. Esta es la fase álgida del proyecto: desarrollo de todos los módulos relacionados con el sistema, desarrollo de la nueva versión de Tamiz+, terminar el entorno web, etc. Al final de este periodo tendremos una primera versión alfa que debe ser operativa en un entorno restringido y preparado para las pruebas. En la web del proyecto deberá presentarse ya una documentación suficiente para conocer el alcance del proyecto, que permita recibir sugerencias y que facilite la captación de voluntarios para la fase de pruebas posterior. 3) Noviembre. La nueva versión Tamiz+ estará terminada, documentada, probada y puesta en la red para su utilización independiente. Se completa la documentación de usuario y la integración de todos los módulos del sistema y se estudian y corrigen los errores descubiertos en las pruebas con la versión alfa. Se libera una versión beta para su puesta en explotación en los centros pilotos seleccionados. A finales de noviembre, aprovechando las Jornadas de RedIris 2004, se presenta en sociedad los resultados. 4) Diciembre. Se termina de documentar el sistema, se recogen las sugerencias de los centros piloto y se libera una versión 1.0 destinada a ser utilizada de manera estable. Se estudia la difusión del sistema y se planifica un seguimiento para conocer su aceptación. Proyecto Hermes I 17

18 D) REPERCUSION La primera repercusión de la ejecución del proyecto será el afianzamiento del servicio de correo de la Universidad de Zaragoza, a la vez que facilitará su exportación hacia otras organizaciones de la red académica que ya utilizan algunos componentes, así como hacia instituciones de nuestro entorno regional que se han interesado por ella. Es previsible que esta solución sea adoptada por las organizaciones que están utilizando Criba (Universidad de Zaragoza, Universidad de Vigo y Universidad Politécnica de Valencia) y con bastantes probabilidades en otras que están estudiando su uso (Universidad de Valencia, Universidad de Navarra, Universidad Politécnica de Cataluña). También por aquellas que tenemos conocimiento de que usan Tamiz: Universidad de Burgo, Universidad de León, Universidad de Deusto, Universidad de Navarra, Xarxa Telematica Educativa de Catalunya, University of Patras e Institute of Mathematics of Polish Academy od Sciences. La posibilidad de combinar la solución propuesta con cualquier infraestructura de correo preexistente permitirá que muchas organizaciones puedan utilizar las herramientas antispam y antivirus desarrolladas en la Universidad de Zaragoza. Hasta ahora muchas organizaciones se han interesado por estas soluciones pero no han podido adoptarlas por sus requerimientos respecto al software de MTA utilizado. Es previsible que ahora se replanteen su utilización. Concretamente, nos han trasmitido su interés Aragonesa de Servicios Telemáticos y Ayuntamiento de Zaragoza. Desde hace algún tiempo están proliferando las soluciones propietarias que tratan de dar respuesta a los problemas del correo electrónico, apreciándose una convergencia clara de las soluciones antivirus y antispam. También han comenzado a aparecer soluciones globales similares a las propuestas aquí. Aunque las soluciones antivirus propuestas por compañías como Panda, Trend Micro o Shopos (por citar algunos ejemplos) están muy afianzadas, la soluciones antispam ofrecidas por estas firmas u otras similares no son suficientemente estables. Esto se debe en gran medida, y a nuestro juicio, a su precipitación por ofertar soluciones y eliminar competencias mediante dudosas operaciones de compra de productos y alianzas, sin esperar el tiempo suficiente para su integración racional. Por otra parte, estas soluciones solamente están al alcance de organizaciones medianas o grandes ya que el pago de las licencias es considerable, además de requerir una administración cuidadosa. Caracterizados bajo el concepto genérico de Software Libre existen productos de calidad para hacer frente al spam y a los virus y existen soluciones ampliamente aceptadas para su integración en el sistema de correo electrónico. Estas herramientas son potentes y están al alcance de cualquier organización (libres de licencias) pero suelen requerir la participación de un experto para su configuración e integración. El proyecto Hermes I viene a solucionar este problema de integración y simplificación. Y si lo hace bien y en un plazo razonable es previsible que atraiga la atención de muchas organizaciones que no han adoptado aún una solución o no están satisfecho con la que tienen. Por otra parte, la aceptación e implantación de la solución propuesta en un número representativo de organizaciones facilitaría la incorporación a SANET de más y más variados sensores, facilitaría Proyecto Hermes I 18

19 la coordinación de políticas de seguridad y revertiría en prestigio para la Universidad de Zaragoza por su desarrollo y para el Gobierno de Aragón por su apoyo financiero. Para poder tener información sobre la aceptación de la solución, desde el primer momento se mantendrá una página web con la información sobre proyecto y su desarrollo. Esta será la primera forma de difusión y una fuente de información sobre su repercusión. Servirá también para recoger sugerencias, discutir alternativas y captar organizaciones que se presten a colaborar en la fase piloto y versiones alfa y beta. Como escaparate del proyecto, esta página contendrá información sobre las organizaciones y las personas participantes en el mimo. La presentación de la solución propuesta en los foros sobre temas de seguridad y correo electrónico son importantes para su difusión y para recabar información sobre el interés y grado de aceptación el mismo. Esta tarea comenzó en la presentación de una idea inicial en el Foro AST de Seguridad Informática de mayo de Próximamente se va a presentar en las Jornadas Zaralinux (17 de junio de 2004) y en los XVII Grupos de Trabajo de RedIris que se celebran los días 17 y 18 de junio de 2004 en Madrid. Las soluciones adoptadas en las organizaciones para las tareas de servidor de buzones y protocolos de acceso son muy variadas y dependientes de la infraestructura preexistente. Si Hermes I tiene una aceptación adecuada, la Universidad de Zaragoza estaría en disposición de lanzar un nuevo proyecto (Hermes II) para cubrir las funciones de servidor de correo. Basado en la misma filosofía y criterios de calidad que los expuestos aquí. Proyecto Hermes I 19

20 COORDINADORES DEL PROYECTO Las tareas de definición y coordinación del proyecto corresponden a personal del Área de Sistemas del Servicio de Informática y Comunicaciones de la Universidad de Zaragoza: Pascual Pérez Sánchez: Pilar Sancho Moreno: Borja Pérez Oñate: Analista Programadora Analista Proyecto Hermes I 20