Actualizado el 22/11/2007

RedIRIS © 1994-2008

• Publicaciones
• Boletín

Sumario

• Novedades en las listas de RedIRIS
• Plataforma de RedIRIS para el desarrollo de Redes Temáticas Científicas
• Acuerdo entre RedIRIS y Trend Micro
• Foro ISPES
• DIFUCIEN: Iniciativa para coordinar y potenciar la difusión científica
• El spam prohibido por Ley
• PUAS: Plataforma Unificada Anti Spam
• Reunión extraordinaria de IRIS-MAIL en Madrid
• III Feria Madrid por la Ciencia
• Servicio Multimedia en RedIRIS
• Salas de videoconferencia en la Comunidad RedIRIS
• Actualidad de Red
• Migración del Servidor de Claves
• IV y V Reunión del TF-CSIRT de TERENA
• Grupo de Trabajo IODEF de TERENA
• Reunión Técnica del FIRST 2002
• Nuevo equipo español en FIRST
• Novedades PAPI
• IV Reunión del TF de TERENA sobre directorios LDAP (TF-LSD)
• Proyectos en el programa ALIS y CAESAR

Novedades en las listas de RedIRIS

Hace ahora aproximadamente dos años se puso en funcionamiento el foro mixto IRIS-ATG que se creó para canalizar el intercambio de experiencias e información acerca de herramientas y desarrollos para teledocencia y trabajo colaborativo. A principio de este año se ha hecho una profunda reestructuración dado que los dos entornos a los que iba enfocado eran similares pero con objetivos significativamene distintos. La teledocencia está más enfocada a los docentes como su nombre indica mientras que el trabajo colaborativo está más dirigido al personal investigador. Viendo que la línea de teledocencia era mucho más activa se decidió eliminar IRIS-ATG y escindirlo en tres nuevos foros:

• ELEARNING (Foro sobre sistemas de teleformación). El objetivo de esta lista es ofrecer un espacio común a todas aquellas personas interesadas en aplicaciones y herramientas de trabajo en red (Internet e Intranet).
• WEBCT-ES (Coordinación de administradores de WebCT-ES). WebCT es en la actualidad una de las aplicaciones de teledocencia más implantadas en la Comunidad RedIRIS y existía una necesidad grande de disponer de un foro de coordinación para abordar cualquier tema relacionado con esta aplicación desde el punto de vista de diseñadores y operadores del servicio. La lista está dirigida a usuarios y administradores de WebCT pero al mismo tiempo a cualquier persona que desee conocer la herramienta.
• BSCW-ES (Foro sobre BSCW). BSCW es actualmente la herramienta de trabajo en grupo más ampliamente utilizada. Desde hace 3 años RedIRIS suministra un servicio de BSCW a redes temáticas, grupos de investigación, apoyo a proyectos... y existía ya una demanda importante que nos va a permitir mejorar el servicio y con ello el intercambio de experiencias, diseños del servicio, solicitud de zonas de trabajo, preguntas, etc.. La lista está dirigida a cualquier usuario o administrador interesado en conocer el BSCW.

A finales de enero de este año RedIRIS participó en las "I Jornadas de Usuarios de BSCW" en la Universidad de Barcelona. Dichas sesiones motivaron la reunión de personas que trabajan con BSCW y tienen diferentes perspectivas entre ellas se compartieron las experiencias de la UOC y UB para docencia. También se trató la gestión de proyectos europeos y las herramienta de trabajo para el colectivo científico que suministra RedIRIS.

Referencias:

• ELEARNING: http://www.rediris.es/list/info/elearning.html
• WEBCT-ES: http://www.rediris.es/list/info/webct-es.html
• BSCW-ES: http://www.rediris.es/list/info/bscw-es.html

Plataforma de RedIRIS para el desarrollo de Redes Temáticas Científicas

Desde hace unos años RedIRIS viene trabajando de forma lenta y constante en la formación y desarrollo de Redes Temáticas de carácter científico. Se han ido desarrollando, integrando y poniendo en funcionamiento una serie de herramientas cuya única finalidad es facilitar el trabajo colaborativo entre investigadores de la comunidad RedIRIS. El conjunto de todas estas herramientas es lo que se denomina plataforma para Redes Temática y tanto el soporte que ofrece RedIRIS como la sencillez de su utilización la convierten en una ayuda de trabajo muy atractiva.

La descripción de esta plataforma se encuentra recogida de forma clara y sencilla en el siguiente documento: http://www.rediris.es/ cvu/rtr.pdf. En él se describe desde lo que es RedIRIS como entidad, el estado reciente de la red y las conexiones internacionales, el concepto de Redes Temáticas, hasta la solicitud de servicios en RedIRIS. El bloque fundamental describe las diferentes herramientas ofrecidas: listas de distribución, servidor de ficheros, BSCW (herramienta vía web de trabajo colaborativo) y se hace un repaso también a servicios tan novedosos como KnowCat, la videoconferencia (VRVS), .... También se describen brevemente los proyectos que han ido surgiendo alrededor de la idea de Redes Temáticas en RedIRIS como son: SARAC (Servicio de Acceso a Recursos de Alta Calidad), Guía de Expertos (canal periodistas/científicos) y la futura RedIRIS-TV.

Se trata de un documento divulgativo como escalón intermedio al nuevo portal de RedIRIS sobre este tema y en el que se está actualmente trabajando donde se ofrecerán aspectos específicamente enfocados a los usuarios de la comunidad científica RedIRIS.

Referencias:

• http://www.vrvs.org
• http://expertos.rediris.es
• http://www.rediris.es/cvu/plataforma.htm

Acuerdo entre RedIRIS y Trend Micro

Desde que los desarrolladores de virus informáticos descubrieron la posibilidad de tener un efecto mucho más destructor enviándolos por correo electrónico esto ha venido suponiendo un problema que ha ido incrementándose de forma exponencial. El usuario por lo general asocia la falta de seguridad en Internet con los virus y este tema en lo que respecta al correo electrónico ya ha sido abordado en muchos grupos de trabajo IRIS-MAIL, aunque de forma muy ligera.

Evidentemente era un tema que lastraba al Grupo e impedía trabajar, debatir y avanzar en otros aspectos del mundo del correo electrónico hasta que a finales de 2000 los responsables de IRIS-MAIL se propusieron dar una solución definitiva a este problema.

Las tres premisas básicas sobre las que se cimentó la búsqueda de soluciones al problema fueron:

• a) Una solución que pasara obligatoriamente por el escaneo del correo al entrar en los servidores (estafetas).
• b)Una solución que fuera capaz de soportar una alta carga de tráfico entrada-salida y no ralentizara el servicio.
• c) Una solución que estuviera disponible para entornos Unix y Sendmail.

En esa época, la mejor y casi única solución que se ajustaba a estas premisas era un producto de Trend Micro llamado InterScan Virus Wall el cual tenía como mérito el llevar algún tiempo en el mercado lo que transmitía confianza. Se consideró que un problema de esta importancia no podía esperar a un desarrollo a medida en un grupo de trabajo. Se necesitaba una solución rápida y la mejor posible por lo que en este caso una alternativa comercial no sería malinterpretada si realmente solucionaba el problema y no plantearía problemas a la hora de que las instituciones adquirieran el producto.

Una vez tomada la decisión sobre la elección se diseñaron cuatro líneas de actuación estratégicas:

• 1ª.- La fase de pruebas. Se negoció una licencia anual para RedIRIS.
• 2ª.- El valor añadido. Diseñar algo que enmascarara una simple solución comercial individual y aislada de cada institución en un modelo para el grupo IRIS-MAIL
• 3ª.- La economía de escala. En lugar de comprar el producto de forma individual hacerlo de forma conjunta tras una negociación de RedIRIS con la empresa para obtener ventajas económicas en la adquisición.
• 4ª.- El soporte técnico al producto. La unión de los responsables técnicos de la empresa y de las instituciones sería el mejor marco de apoyo técnico al producto.

La primera fase fue obtener una licencia de Trend Micro para un proyecto piloto que nos permitiera probar el producto durante 8 meses (año 2001). La licencia debería ser para 8 instituciones de gran tamaño con unos objetivos muy claros de evaluación de posibles diseños con carga de tráfico real. Se seleccionaron 8 universidades y a lo largo del año se unieron a la iniciativa otras 10 instituciones. El producto funcionaba bastante bien y el mayor problema fue seleccionar el diseño que mejor se adecuara al esquema de Servicio de cada institución debido a la flexibilidad que presentaba en ese aspecto.

Al final del periodo de pruebas (Jornadas Técnicas 2001 de Pamplona) cada institución debería tomar su propia decisión en la compra de este o cualquier otro producto. RedIRIS se limitó a constatar que funcionaba muy bien y que negociaría un acuerdo para obtener ventajas económicas en la compra.

En paralelo a la fase de pruebas se desarrolló y montó la REd de Sensores de Alerta AntiVirus de la Comunidad Académica (RESACA Ver Boletín de RedIRIS Nº 57 http://www.rediris.es/ rediris/boletin/57/actualidad.html#resaca) basado en la extracción y procesamiento diario de estadísticas del InterScan Virus Wall que tuvo bastante aceptación y al que se unieron muchas universidades en muy breve período de tiempo. En próximos boletines seguiremos informando sobre el estado y perspectivas de RESACA.

Respecto al tercer punto RedIRIS firmó en octubre pasado un acuerdo de colaboración con Trend Micro que además definía un marco económico preferencial para la compra del producto por parte de sus Instituciones afiliadas. Dicho acuerdo se desglosó en tres bloques: Universidades Nivel A (grandes), Universidades Nivel B (pequeñas) y Centros de Investigación. Cuando alguna institución desee adquirir InterScan Virus Wall de Trend Micro a su proveedor habitual debe hacerle saber que los precios son los del acuerdo con RedIRIS.

Además de estos precios especiales dicho Acuerdo también incluía otros aspectos colaterales:

• La integración de RedIRIS en la red de Alerta de virus a nivel internacional.
• La disponibilidad inmediata de pattern para el Sistema AntiVirus
• La colaboración de Trend Micro en el proyecto RESACA de RedIRIS
• La Inclusión de RedIRIS en las pruebas de productos betas de Trend Micro que sean de interés para la Comunidad.

Referencias:

• Foros técnico de InterScan Virus Wall:
  http://www.rediris.es/list/info/iris-isvw.html
• RESACA:
  http://www.rediris.es/mail/resaca/
• Servicio de correo electrónico de RedIRIS:
  http://www.rediris.es/mail/iris-mail.html

Foro ISPES

El Foro ISPES es una iniciativa de RedIRIS que tiene como objetivo habilitar mecanismos de coordinación entre los técnicos de los diferentes proveedores de acceso a Internet españoles (ISPs). Se trata de crear un entorno de confianza entre los miembros integrantes del Foro que permita llevar a cabo actividades como la coordinación de incidentes de spam y seguridad, la definición de políticas comunes, el desarrollo y obtención de consenso en los códigos de conducta que faciliten la colaboración entre los diferente miembros y al mismo tiempo disponer de datos de contacto actualizados y fiables de los integrantes del Foro ISPES.

Actualmente en dicho Foro se encuentran los responsables del correo electrónico y seguridad de los siguientes proveedores: BT, TELEFÓNICA- DATA, TERRA, SARENET, INTELIDEAS, ARRAKIS, TISCALI, COLT-TELECOM, EUSKALTEL y RedIRIS. Ahora que RedIRIS forma parte de ESPANIX también se pretende exponer en dicha Asociación los objetivos de ISPES con el fin de integrar a nuevos proveedores.

El pasado 13 de diciembre se celebró la III Reunión del Foro ISPES en la Sede de Banesto y contó con la asistencia invitada de el Director Técnico de ESPANIX y representantes de AEPSI (Asociación Española de Proveedores de Servicios de Internet); Asociación de reciente creación que cuenta con la afiliación de importantes proveedores: Airtel, Eresmas, Ya.com, etc. La idea del Foro ISPES es entablar colaboración con estas dos asociaciones.

En dicha reunión se trató sobre las actividades que ISPES va a llevar a cabo a corto plazo :

• Acabar las páginas web del Foro ISPES. Cuyo contenido se decidió que fuera privado.
• Elaborar los mecanismos de aceptación de nuevos miembros.
• Definir el proceso de tratamiento de incidentes de spam entre los miembros del foro ISPES.
• Consensuar los documentos siguientes:
  • "Política común del foro ISPES frente al spam". Incluye aspectos como las buenas prácticas para evitar spam, procedimientos para gestionar incidentes externos e internos entre miembros y una serie de compromisos de información y gestión.
  • "Política común para gestionar incidentes de seguridad". Incluye aspectos sobre los recursos mínimos para la gestión de dichos incidentes y el registro y actuación en función de la gravedad de los mismos.

Se seguirá informando sobre esta iniciativa de RedIRIS que como hemos dicho anteriormente pretende crear vínculos de colaboración con otros proveedores para proteger y mejorar la coordinación en los Servicios de correo electrónico (IRIS-MAIL) y seguridad (IRIS-CERT) principalmente

DIFUCIEN: Iniciativa para coordinar y potenciar la difusión científica

Tanto la reciente participación de RedIRIS en los congresos de Málaga y Valencia sobre la labor de los medios de comunicación en la difusión científica como las iniciativas ya maduras de la Guía de Expertos (Boletín de RedIRIS nº 57), el Proyecto SARAC (Servicio de Acceso a Recursos de Alta Calidad) y las Redes Temáticas han dado como resultado el lanzamiento de algunas ideas para trabajar en aspectos relacionados con la difusión científica (DIFUCIEN). Las ideas en marcha para forjar esta iniciativa son:

• La creación de un foro permanente para conectar a periodistas científicos y científicos interesados en la difusión de la ciencia.
• El desarrollo de nuevas iniciativas.
• La creación de una lonja o zona de intercambio de material (fotografías, reseñas, material multimedia ­TvRedIRIS­, etc.) entre periodistas, científicos e instituciones para la difusión científica.
• La coordinación y aglutinamiento de las numerosas iniciativas (revistas, portales especializados, departamentos, etc.) sobre difusión científica que existen en la Comunidad RedIRIS.

Actualmente desde DIFUCIEN se están lanzando canales especializados de difusión científica. El primero y gracias a la colaboración del Gabinete de Difusión del IAC será DIFUCIEN-ASTRO a través del cual se distribuirá información de primera mano sobre el Gran Telescopio de Canarias (GTC) aunque a través de este canal se añadirán otras iniciativas relacionadas con la Astrofísica y Astronomía. Hay otro canal en fase de creación: DIFUCIEN-TIERRA sobre Ciencias de la Tierra con la colaboración de todas las instituciones agrupadas en la Red Temática Tierra (http://tierra.rediris.es).

Las iniciativas y posibilidades de trabajo alrededor de DIFUCIEN es elevado. La creación de la lonja de material de intercambio está en desarrollo, actualmente se hace por correo electrónico y de aquí surgió la idea de desarrollar las líneas maestras para lanzar un canal de emisión continua de TV a través de RedIRIS con material audiovisual exclusivamente científico (ver información en este Boletín).

Cualquier institución académica (Departa- mentos, Editores de revistas científicas, etc.) interesada en este tipo de iniciativas o servicios puede ponerse en contacto con RedIRIS.

Referencias

• Plataforma de RedIRIS para el desarrollo de Redes Temáticas Científicas:
  http://cvu.rediris.es/pub/bscw.cgi/0/131675
• Foro DIFUCIEN:
  http://www.rediris.es/list/info/difucien.html
• Guía de Expertos:
  http://expertos.rediris.es

El spam prohibido por Ley

Hace unos meses el Gobierno español aprobó el Anteproyecto de la polémica "Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico". Esta Ley incluye una serie de artículos referentes al spam en el Título III "Comunicaciones comerciales por vía electrónica", Art. 18, 19, 20 y 21, además de otros colaterales donde se cataloga el spam como falta leve (Art. 37), se estipulan las sanciones económicas (Art. 38) y se arbitra la competencia sancionadora (Art. 42).

En el caso de que este Anteproyecto pasara los trámites parlamentarios pertinentes, el spam estaría prohibido y penado por Ley en el estado español tal y como reza el Articulo 20 de dicha Ley:

"Artículo 20. Prohibición de comunica- ciones comerciales realizadas a través de correo electrónico o medios de comunicación electrónica equivalentes. (Queda prohibido el envío de comunicaciones publicitarias o promocionales por correo electrónico u otro medio de comunicación electrónica equivalente que previa- mente no hubieran sido solicitadas o expresamente autorizadas por los destinatarios de las mismas)."

Realmente esto es una extraordinaria noticia para el Servicio de correo electrónico en general y el de la Comunidad RedIRIS en particular. Ahora debemos esperar no sólo al trámite parlamentario para su aprobación sino conocer los mecanismos que defina la Administración para canalizar las denuncias, análisis y veredictos de los cientos de casos de spam que ocurren diariamente. Para que esta Ley sea realmente efectiva deberán definirse unos canales de denuncia ágiles, asequibles a todos y técnicamente efectivos. La Ley en su Art. 42 define que las competencias sancionadoras corresponden al MCYT y en concreto: "las leves al Secretario de Estado de Telecomunicaciones y para la Sociedad de la Información".

Un Servicio que no se puede olvidar y al que le afecta esta Ley y el spam de forma muy importante son las News de Usenet. Las News están siendo presa fácil ya que técnicamente no se ha reaccionado ante el fenómeno del spam y están siendo devoradas por él. Desde hace muchos años las News se vieron desbancadas por el servicio de correo electrónico en su vertiente de listas de distribución que sí han sabido reaccionar de forma muy expeditiva frente a la distribución de información no deseada.

En el caso de las News los futuros canales de denuncia podrán ser mucho más complicados de definir que en el caso del correo electrónico.

Por último reincidir en que la prohibición legal del spam en España es una buena noticia y que paralelamente RedIRIS seguirá manteniendo los frentes abiertos en la lucha contra el spam, como lo estaba haciendo hasta ahora, y donde el Proyecto de la Plataforma Unificada AntiSpam (PUAS) puede ser una herramienta extraordinariamente útil para evitar el correo no deseado en nuestros buzones.

PUAS: Plataforma Unificada Anti Spam

Los mensajes de correo no solicitado (spam) constituyen uno de los principales problemas a los que se enfrenta el servicio de correo electrónico y por su importancia ha sido tratado en los grupos IRIS-MAIL durante años. La parte positiva del spam es que ha ayudado mucho a la Comunidad RedIRIS a la hora de estructurar servicios de correo electrónico centralizados y bien gestionados, algo impensable allá por 1995. Pero a pesar de que los Servicios de Correo de las Instituciones de RedIRIS han sido y son un referente en Internet y tienen una alta calidad, su gran problema aun sigue ahí: el spam. Todos sabemos que es fruto de la falta de visión de desarrolladores de estándares y protocolos como por ejemplo SMTP ­¡cómo iban a imaginar que 20 años después SMTP iba a ser usado como un medio de comunicación mundial!­, pero hay que intentar buscar las mejores alternativas técnicas para evitarlo paralelamente al aspecto legal (Artículo sobre spam y LSSI)

Las soluciones al spam durante los últimos años pasaban por iniciativas extranjeras con la creación, gestión y explotación de listas negras basadas en zonas DNS de resolución inversa. Dichas iniciativas o se hundían o las comercializaban contando con una política propia que nos obligaban a compartir. ¿Porqué RedIRIS no puede desarrollar una lista negra con nuestra propia política y cuyo fin sea defender del spam de forma unificada a nuestra Comunidad?. Nos pusimos manos a la obra y encontramos que el gran problema residía en cómo saber si un mismo mensaje de spam entraba en varias instituciones de RedIRIS y para detectar esto se decidió adoptar un modelo centralizado de denuncias.

En el marco de colaboración con la Comunidad Académica de RedIRIS, la Universitat Rovira i Virgili de Tarragona está desarrollando el Proyecto Unificado Anti Spam (PUAS). Se basa en un sistema de votaciones unificado, donde los postmasters mediante un entorno inicialmente web, podrán introducir los mensajes de spam que vayan recibiendo en sus organizaciones. Todas estas denuncias se guardarán y analizarán para obtener ­entre otras cosas­ una zona de DNS común.

Actualmente ya se pueden realizar estas consultas en servidores fuera del ámbito académico, pero en todos los casos se rigen por intereses económicos y privados, donde la discontinuidad del servicio es notable. La Plataforma Unificada Anti Spam permitirá ponderar los criterios de funcionamiento con toda la Comunidad Académica, además de garantizar su continuidad.

El proyecto se encuentra en una fase bastante avanzada, y se espera poder arrancar la prueba piloto en los Grupos de Trabajo de Mayo.

Reunión extraordinaria de IRIS-MAIL en Madrid

Debido a los problemas ocasionados tanto por la flexibilidad del protocolo SMTP como por la propia filosofía del servicio; por los problemas de seguridad y por los múltiples abusos que se producen actualmente en el correo electrónico, durante los últimos cuatro años los servicios de correo electrónico de las instituciones afiliadas a RedIRIS se han ido convirtiendo en verdaderos búnkeres inaccesibles desde el exterior.

Este diseño basado en la idea de que los recursos de la universidad son para la propia universidad, está provocando graves problemas cuando los usuarios se desplazan de su lugar habitual de trabajo y quieren leer su correo desde cualquier lugar del mundo conectado a la red. Tanto los accesos de líneas ADSL por parte de los usuarios de las universidades como la aparición de diversos dispositivos móviles (PDAs, portátiles, WAP, etc.) han experimentado un crecimiento extraordinario en los últimos tiempos y esto implica problemas de seguridad y encriptación del acceso a los buzones.

Rompiendo con la actual dinámica de convocatorias de Grupos de Trabajo de RedIRIS los pasados 14 y 15 de marzo de 2002 se celebró una reunión extraordinaria del Grupo de Coordinación IRIS-MAIL. Una especie de seminario de dos días de duración que ha tratado exclusivamente temas de correo electrónico. La idea ha sido abordar y dar soluciones a dos problemas de imperiosa actualidad en las instituciones de RedIRIS:

• Jueves 14 de marzo: Acceso remoto y seguro al correo electrónico
• Viernes 15 de marzo: Alta disponibilidad y balanceo de carga en el Servicio de correo electrónico

El primero es de interés general para todas las instituciones afiliadas, mientras que el segundo está más circunscrito a grandes instituciones, es decir, universidades. A medida que pasa el tiempo los temas de operación de servicio están menos parcelados y debe de existir una gran coordinación entre responsables de áreas tales como sistemas, correo electrónico, red, seguridad y micro-informática o aulas y así es como RedIRIS debe enfocarlo.

El objeto de esta convocatoria fue intentar extraer diversos modelos para cada uno de los temas abordados con la finalidad de que se oriente a las instituciones a la hora de diseñar sus propios servicios de correo electrónico para que puedan hacerlo de la mejor forma posible.

El desarrollo de las sesiones se realizó en tres formatos distintos: "tutoriales" para centrar los conceptos y los problemas, "exposición de experiencias", con el objeto de que todos conozcamos los avances o fracasos en diseños y soluciones que tienen otras instituciones y por último el "debate" sobre el resultado de esos diseños y soluciones.

A la reunión asistieron de forma presencial unas 80 personas en la primera sesión y 50 en la segunda. Por videoconferencia siguieron las sesiones una media de 15 personas via VRVS y 30 por Windows Media con un chat para hacer preguntas. La reunión fue muy fluida y contó con una importante participación.

Los objetivos se cumplieron con creces al quedar definidos los dos modelos para los temas de ambas sesiones. Más información en: http://www.rediris.es/mail/gt/mz02/

III Feria Madrid por la Ciencia

Durante los días 8, 9 y 10 de marzo se celebró en el recinto ferial Juan Carlos I de Madrid la III Feria Madrid por la Ciencia.

RedIRIS estuvo presente, colaborando en la emisión por Internet de lo que ocurría en la Feria como por ejemplo los experimentos en los stands de los centros y las conferencias.

La emisión ha sido realizado gracias a la estrecha colaboración de tres centros: Centro Técnico de Informática del CSIC, el Museo Nacional de Ciencias Naturales y RedIRIS.

Los objetivos de esta feria eran acercar la ciencia a la gente para que la perciban como algo propio mediante una acción festiva y motivadora abierta a todos los ciudadanos.

Como medios técnicos puestos por los centros colaboradores se usaron los siguientes elementos:

• Una línea de 2Mbps que unía el recinto ferial con la sede de RedIRIS en Madrid.
• Portátiles utilizados como codificadores en la feria.
• En las instalaciones de RedIRIS se usaron dos servidores de streaming con Windows Media Services. Como método básico de balanceo se utilizó DNS.
• Medios audivisuales diversos, cámaras, video, micrófonos, etc.

Servicio Multimedia en RedIRIS

Dentro del Área de coordinación multimedia de RedIRIS (IRIS-MMEDIA) existen varios apartados interrelacionados por tratarse de la transmisión de datos audiovisuales en tiempo real a través de la red. Tal y como aparece en la figura podemos dividir estos servicios en dos tipos:

• Síncronos: Son aquellos que cuentan con comunicación bidirecional en tiempo real como por ejemplo la videoconferencia.
• Asíncronos: Son aquellos con comunicación unidireccional, es decir todos los temas relacionados con el streaming.

Si bien es cierto que cualquiera de los servicios puede utilizarse desde el PC del usuario, se han considerado las salas de videoconferencia como un elemento aglutinador ya que desde las salas de reuniones hasta los salones de actos de actos de las instituciones se ofrecen más y mejores posibilidades a los servicios multimedia. Sobre el tema de las salas se elaboró un documento-guía para todas las instituciones de RedIRIS con el fin de que se dispusiera de cierta homogeneidad de criterios a la hora de abordar Proyectos Multimedia en las universidades. Las perspectivas plasmadas en dicho documento son:

• Audiovisuales: elemento básico del que no existe demasiada información y fundamental para el éxito de una transmisión.
• Tecnologías de red: utilizadas para la transmisión de videoconferencias vía IP o RDSI.

La idea es desarrollar un directorio de salas existentes en la comunidad RedIRIS con sus fichas de especificaciones técnicas y contactos correspondientes como paso previo a una futura red de Salas Priorizadas (SapNet) donde estén interconectadas estas salas a nivel de red. Este documento todavía está abierto a comentarios y sugerencias y se encuentra en: http://www.rediris.es/mmedia/modelo

Dentro de las herramientas síncronas bien las ubicadas en estas Salas de Videoconferencia o aquellas que utiliza el usuario desde un PC es donde situaríamos las tecnología de red: Red de MCUs para H.323 con un plan de numeración y gatekeepers tanto para videoconferencia como VoIP, directorios (ILS) o sistemas de video- conferencia tan potentes, sencillos y aconsejables como VRVS (http://www.vrvs.org), Mbone y aplicaciones comerciales como ISABEL entre otros

Desde el punto de vista asíncrono encontramos todos los temas relacionados con streaming, que consiste en un sistema optimizado que permite la visualización de video a la vez que se está recibiendo. Los contenidos de streaming pueden ser de tres tipos:

1. Video bajo demanda (VoD)
2. En vivo
3. Video programado

El video bajo demanda es el clásico repositorio de videos accesibles a petición del usuario. Los contenidos en vivo son actividades transmitidas en directo por la red a través de los servidores de streaming los cuales requieren un alto nivel de coordinación entre los servicios multimedia de las instituciones y que está aun por definir. En la gráfica está referenciado como "Solicitud de emisión de eventos". Los videos programados permiten hacer parrillas de programación con repositorios de vídeo.

Al conjunto de estos aspectos lo llamamos Servicio de streaming. Las instituciones de RedIRIS con estos servicios podrán formar una Red nacional de servidores streaming interconec- tados entre sí para formar una estructura de distribución de video de alta calidad.

Varias instituciones están montando o tienen montado ya, servicios de video streaming, y desde este Servicio en RedIRIS se realiza la coordinación con el fin de optimizar el ancho de banda disponible. Dentro de este servicio se ha empezado a trabajar en una interesante iniciativa llamada RedIRISTV. Tiene como objetivo la emisión continua y programada por la red tanto de una serie de eventos en directo como de videos programados de carácter científico. RedIRISTV incluye varios apartados:

• Eventos: Retransmisión de eventos en vivo
• BoDeCA: Bolsa De Contenidos científicos Audiovisuales. Inicialmente serán contenidos públicos y más adelante se hará de este sitio un lugar de intercambio de contenidos de acceso restringido.

RedIRISTV nos permitirá canalizar y coordinar contenidos de diferentes fuentes productoras de audiovisuales de carácter científico: universidades, museos, Redes Temáticas de RedIRIS (RTR), etc. se podrán codificar contenidos científicos para utilizarlos como video bajo demanda y programado.

Paralelamente se está trabajando en la elaboración de un directorio de servidores de videostreaming con accesos directos a aquellos que emitan video programado y en directo. Se proporcionará el servicio de redistribución desde nuestros servidores para aquellos centros que tengan servicios similares cuyos contenidos cumplan con la política del servicio (contenidos científicos, educativos y divulgativos)

Dentro de este complejo servicio de streaming de RedIRIS se está poniendo en marcha una sección con Windows Media, la razón de la elección es su gratuidad y su buena calidad. Más adelante pasaremos a formatos de alta calidad como: MPEG1, MPEG2 y MPEG4. Esto se irá desarrollando a medida que vayamos disponiendo de las herramientas necesarias, como por ejemplo un codificador en tiempo real.

Como se puede ver hay en la actualidad una amplia variedad de temas abiertos en el Servicio Multimedia (http://www.rediris.es/list/info/iris- mmedia.html) sobre los que se irá trabajando con el fin de poder ofrecer a los usuarios aspectos innovadores paralelamente al mantenimiento diario del servicio existente.

Salas de videoconferencia en la Comunidad RedIRIS

En la comunidad RedIRIS existen dos ámbitos diferenciados pero al mismo tiempo ligados: el docente y el científico o investigador. El ámbito docente está cada vez más enfocado a las tecnologías de teledocencia inter e intra universidades y cada universidad ofrece lo mejor a sus usuarios (estudiantes y profesores). El ámbito científico y el trabajo colaborativo es el que puede parecer que está más relegado y por eso requerirá una mayor potenciación y dedicación por parte de RedIRIS. Hay comunidades de investigadores muy especiales como por ejemplo la de altas energías que tanto por la temática científica como por sus conocimientos informáticos disponen de suficientes recursos de videoconferencia ajustadas a sus necesidades. El ejemplo de este colectivo es un modelo a seguir pero no es el caso de la mayor parte de la comunidad científica que dispone de pocas alternativas y conocimientos para poder realizar, por ejemplo, reuniones de trabajo usando videoconferencia o bien poder participar en congresos científicos que se retransmiten por la Red.

La solución pasa por modelos controlados que ofrezcan el servicio directamente al colectivo de investigadores. De esta forma se ofrece un servicio de calidad y alta disponibilidad, en definitiva un modelo basado en salas de videoconferencia con todas las tecnologías existentes en la actualidad de red y multimedia. Uno de los temas a los que hasta ahora no habíamos prestado atención era el del diseño e instalación de estas Salas. Aspectos como la luminiscencia, las mesas de control, etc. nunca habían sido evaluados tampoco lo había sido la dimensión de las salas en busca de la mejor funcionalidad de las mismas, no es lo mismo un Salón de Actos que un sala para impartir docencia o una para reuniones de trabajo.

Las salas de videoconferencia serán uno de los ejes que articulen los servicios multimedia en el futuro próximo. Se tratará de lugares diseñados y optimizados para eventos audiovisuales con las tecnologías de red que en cada momento nos ofrezcan más flexibilidad y funcionalidad. Serán los lugares adonde los usuarios accedan directa o indirectamente para hacer uso de los sistemas de videoconferencia. Las salas deberán disponer de operadores de sala que optimicen el uso de la misma. Sin recursos humanos para la operación diaria de las salas el desembolso económico no se verá amortizado. Este aspecto también se ha abordado en el documento.

A nivel de red las salas podrán disponer de cualquiera de las tres alternativas disponibles: RDSI, IP Intranet e IP Internet. Evidentemente con RDSI tenemos garantizado un buen servicio pero es mucho menos flexible que el uso de IP en Internet. La idea más ambiciosa en este sentido es poner en marcha una Red de Salas Priorizadas en la Comunidad RedIRIS (SAPnet). En esta red las salas de videoconferencia estarían conectadas con todos los parámetros necesarios para garantizar la calidad del servicio que se pretende y estaría coordinada en RedIRIS.

Para organizar y poner en marcha esta Red lo primero que hay que hacer es estimular la instalación de salas de videoconferencia en RedIRIS. Para ello habrá que definir y exigir unos perfiles mínimos para las salas a la hora de conectarlas a esta Red Priorizada.

La idea es hacer un directorio de salas de videoconferencia cada una con sus ficha de especificaciones técnicas que permita ver las posibilidades de llevar a cabo videoconferencias en la Comunidad RedIRIS. Cómo utopía ¿Qué opinarías de poder poner en marcha una servicio que permita hacer reservas de salas de la Comunidad RedIRIS? Un sistema que permita a un grupo de investigadores de una universidad reservar y alquilar la sala de otra universidad.

Para empezar con esta iniciativa las instituciones que no dispongan de salas de videoconferencia deberán ponerlas en marcha y para ello se ha desarrollado un documento que pueda servir de guía y que permita disponer de cierta homogeneidad de criterios a la hora de abordar Proyectos Multimedia en las universidades. Evidentemente será un documento vivo abierto a colaboraciones y posibles evoluciones tecnológicas. El documento se encuentra en la siguiente dirección: http://www.rediris.es/mmedia/salas

Actualidad de Red

En RedIRIS hemos comenzado la puesta en operación del nuevo nodo nacional y la migración de las conexiones nacionales a los nuevos equipos M20 y M40 de Juniper.

Tanto los equipos que forman el nodo nacional como los nuevos equipos de los nodos regionales, están preparados para recibir conexiones de hasta STM-16 (2,5 Gbps).

Además de la puesta en operación de los nuevos equipos migrando los enlaces, se está migrando el protocolo de routing dinámico que hasta ahora se estaba utilizando pasando de EIGRP a IS-IS.

Desde hace unos meses, en RedIRIS estamos trabajando en la elaboración del pliego de condiciones que debe cumplir la nueva infraestructura de red, es decir RedIRIS2 y que serán dadas a conocer a todos los proveedores interesados vía concurso público.

Recientemente la conexión de RedIRIS con la Internet global se ha actualizado a dos enlaces de 2,5 Gbps con KPNQwest y Global Crossing, comenzando con una capacidad máxima total de 622 Mbps. Estos enlaces se han puesto en operación durante los últimos días de marzo y primeros de abril. Con este cambio se sustituyen las conexiones existentes con anterioridad consistentes en un enlace STM-1 (155 Mbps) cuyo proveedor era Telefónica Internacional y 77 Mbps a través de GÉANT que se reservaban para tráfico de la red de proxies priorizada de RedIRIS.

GÉANT

La nueva red pan-europea GÉANT para la Investigación y Educación, entró en producción el pasado mes de noviembre sustituyendo a TEN-155. GÉANT es una red IP (equipos Juniper M-160) con un backbone a 10Gbps que se sitúa por delante del backbone de Internet2.

El punto de presencia de GÉANT en España tiene dos enlaces de 2.5Gbps con los puntos de presencia en Francia (París) e Italia (Milán). RedIRIS migró su conexión de TEN-155 a GÉANT a finales de octubre de 2001 y se conecta al nodo español con una lambda protegida de 2,5 Gbps.

Los gráficos recogen la topología de dicha red con las capacidades finales de cada uno de los nodos de GÉANT y las velocidades de acceso de cada una de las redes nacionales de investigación.

Internet2

RedIRIS se conecta con la red de Internet2 Abilene y con Esnet y Canarie a través de la red GÉANT. Durante la semana del 21 de enero se pusieron en operación dos enlaces de 2,5 Gbps entre GÉANT y dichas redes de investigación.En concreto la topología es la siguiente:

• Enlace 2,5 Gbps entre el PoP de GÉANT en Inglaterra y el PoP de GÉANT en Nueva York. Este router de NY tiene tres enlaces con las siguientes características:
  • 622 Mbps con Router Canarie (Red Canadiense de Investigación)
  • 622 Mbps con Router ESNET (Energy Science Network)
  • 1 GE con un router de Abilene
• Enlace 2,5 Gbps entre el PoP de GÉANT en Alemania y un router de Abilene en NY.

Más información sobre estas redes en:
http://www.ucaid.edu/abilene,
http://www.es.net, http://www.canarie.ca

ESPANIX

ESPANIX es un punto neutro español de intercambio de tráfico entre proveedores comerciales con presencia en España comercial de Telefónica Data, antes IBERNET y ahora NURIA, nos hacía tránsito hasta este punto. Desde el pasado mes de enero, RedIRIS se conecta con un enlace STM-1 PoS con el ESPANIX y ha comenzando a intercambiar tráfico con los principales proveedores nacionales con el objetivo final de llegar a tenerlo con todos los proveedores con presencia en este nodo.

El enlace actual con NURIA, un STM-1 PoS, de momento se mantendrá en operación.

Nueva conexión IPv6 con TF-NGN

Desde diciembre del año pasado, las redes nacionales participantes en el TF-NGN (Task Force Next Generation Network) de TERENA disponen de una conexión IPv6 con un router Juniper M5 situado en París. RedIRIS fue la primera red en conectarse a dicho router mediante un túnel, por el que corre una sesión BGP4+.

Asimismo, se estudiaron las incompatibilidades entre routers Juniper y Cisco a la hora de establecer túneles IPv6.

Migración del Servidor de Claves

El número de claves en el servidor de RedIRIS ha ido aumentando a lo largo de los años, estando el servidor actual (Sun Ultra Sparc 1, 256Mb y 4 MB de Disco duro) en el límite de su capacidad, por este motivo se ha procedido a realizar la migración a un nuevo equipo para asÍ asegurar el mantenimiento del servicio.

El nuevo servidor se encuentra ahora mismo operativo y se está procediendo a migrar la configuración de sincronización con los demás servidores de claves.

Se sigue empleando el mismo software, PSKD de Marc Horowitz, que emplea una base de datos basada en el motor de Berkeley (DBLIB), aunque en un futuro próximo esperamos poder realizar el cambio a un nuevo servidor basado en un sistema de base de datos relacional que se está desarrollando ahora mismo.

Se ha aprovechado la potencia del nuevo equipo para volver a poner en funcionamiento algunas de las estadísticas que cargaban demasiado la antigua máquina, de esta forma es posible acceder vía WWW a unas estadísticas sobre el número de claves asociados a cada dominio de primer nivel de Internet en: http://www.rediris.es/keyserver/domain .

Al estar basadas en el dominio de primer nivel no indican necesariamente el número de usuarios de PGP que tienen publicada su clave en los servidores, ya que muchos usuarios emplean direcciones de correo electrónico de dominios genéricos (".com", ".net").

En la gráfica que aparece a continuación se indica la evolución del número de claves PGP en el servidor desde diciembre de 1997. El tamaño de un anillo PGP que contuviera todos estos indicadores sería en la actualidad de 1.836M, y contendría más de 1.635.000 claves.

Los servidores de claves PGP se emplean como repositorio de claves, de forma que los usuarios puedan acceder de forma homogénea a las claves PGP de otros usuarios, sin tener que preocuparse de difundir las nuevas firmas o claves al resto. Las versiones recientes de PGP y GNU PGP incorporan mecanismos que permiten un acceso transparente al servidor de claves.

En la actualidad todos los servidores mantienen la misma base de datos con todas las claves, sincronizándose vía correo electrónico con otros servidores para de esta forma mantener el repositorio de claves actualizado. El servidor de RedIRIS se encuentra sincronizado ahora mismo con los servidores de claves de las siguientes organizaciones:

• Agencia de energía americana es.net
• Red académica holandesa, que a su vez actúa como servidor holandés de PGP.NET
• Keyserver.ch servidor de Suiza
• Servidor de claves de la UPC, que actúa como servidor de claves español de PGP.NET
• Universidad de la Laguna.
• escomplinux.org
• Servidor experimental de cryptonet.net

Se reciben unos 2.000 correos diarios de estos servidores, que permiten tener la base de datos actualizada.

Referencias:

• Servidor de claves PGP http://www.rediris.es/keyserver
• EstadÍsticas por dominios DNS http://www.rediris.es/domain

IV y V Reunión del TF-CSIRT de TERENA

La cuarta reunión del Task Force de TERENA, TF- CSIRT (CSIRT Coordination for Europe), para promover la colaboración y cooperación entre CERTs europeos, se celebró en Manchester (Reino Unido) los pasados días 27 y 28 de septiembre. Como viene siendo habitual, el primer día se dedicó a seminarios relacionados con el modo de operación de distintos CERTs (como UNIRAS, en el Reino Unido o CERTA, en Francia), el funcionamiento de diversas herramientas de gestión de incidentes utilizadas por los mismos (como MAGIC o REMEDY), y temas de interés general para los presentes como una descripción del proyecto EWIS (European Early Warning Information System) o de la Unidad Nacional de Crimen Tecnológico en el Reino Unido.

El día 28, se celebró la cuarta reunión del TF- CSIRT propiamente dicha. Los aspectos más importantes tratados fueron los siguientes:

• Como siempre se hace un repaso del estado actual del Servicio Piloto Trusted Introducer (TI), que a fecha de septiembre de 2001 cumplía más de 1 año de operación como piloto. En ese momento, el número de equipos de seguridad europeos de nivel 0 (aquellos de los que se conoce algún tipo de información) es de 63, hay 5 equipos que se encuentran en el nivel 1 (es decir, están en proceso de adquirir el nivel máximo de confiabilidad) y 14 equipos de nivel 2. Además, se dieron a conocer los 5 miembros elegidos por los equipos de nivel dos que componen el Review Board, que será el encargado de actuar en caso de disputas y de analizar la marcha del Piloto. Su opinión deberá ser tenida muy en cuenta a finales de septiembre del 2002 cuando se termine la fase piloto y haya que decidir si la experiencia obtenida es positiva y si se establece como servicio permanente.
• Se ultiman los detalles de los módulos que contendrán los cursos de formación dirigidos al nuevo personal de CSIRTs. Se decide que la primera edición de los cursos se realice junto a la siguiente reunión del Task Force en enero en Estocolmo. Estos cursos constan de los siguientes módulos relacionados con la operación ordinaria de un CERT:
  • Aspectos Legales
  • Aspectos Organizativos
  • Aspectos Técnicos
  • Aspectos de Mercado
  • Aspectos Operativos
• Relaciones con la CE (Comisión Europea). La Comisión actualmente está trabajando en dos líneas preferentes: hacer que los países miembros tengan CERTs a nivel nacional y financiar proyectos de investigación relacionados con seguridad. Tras las diferentes reuniones mantenidas entre representantes de la Comisión y una delegación del TF-CSIRT (un total de 4 desde febrero de 2000), se decidió presentar a la Comisión dos proyectos: uno para conseguir financiación para los cursos de formación de nuevo personal de CERTs, comentado anteriormente, y otro para hacer un Handbook para CSIRTs sobre crimen tecnológico en el ámbito europeo. Desgraciadamente, ambos proyectos fueron denegados. Además en mayo del 2001, hubo una reunión entre la CE y representantes de CERTs comerciales (BT, Telecom, Telia, Siemens, entre otros) para trabajar en una estructura de mejorar de la seguridad de Internet en Europa. Como resultado de esta reunión, se enviaron propuestas de dos proyectos de investigación para ser patrocinados por la CE (SABEM, relacionado con estándares PKI y EISPP relacionado con servicios de seguridad para dar confianza al comercio electrónico).
• Por primera vez, se invita a un equipo de atención de incidentes ruso (RU-CERT) a esta reunión para que se dé a conocer y, porque no, pueda enriquecerse de las experiencias y grupos de trabajo que se están desarrollando bajo el paraguas del TF-CSIRT. El RU-CERT es una organización sin ánimo de lucro a nivel nacional ruso. Está compuesto por 4 miembros y mantiene puntos de contacto en algunos países de la antigua Unión Soviética, dato de contacto éste muy importante para los presentes.

La quinta reunión del TF-CSIRT se celebró en enero de este año en Estocolmo (Suecia) y estuvo organizada por TELIA. Como en el caso anterior, el primer día se dedicó a seminarios, donde como es natural, tienen preferencia las presentaciones relacionadas con actividades y equipos del país que aloja la reunión, modo este de dar a conocer a los delegados de los equipos de seguridad presentes el estado del arte en temas de seguridad en los distintos países europeos. Se contó pues con presentaciones por parte de RB-CSIRT (Riskbank Securitry Incident Response Team. Swedish Central Bank), SESIC (Swedish Network Security Information System), Siemens CERT, Cisco PSIRT (CiscoProduct Security Incident Response Team) y del National Criminal Investigation Department of the Swedish Police Force.

Al día siguiente se celebró la reunión del TF propiamente dicha. Se comenzó haciendo una revisión del estado del Servicio TI (Trusted Introducer) donde la única nota digna de mención es que cada vez hay más CSIRTs de nivel dos que pertenecen al ámbito comercial, punto este pendiente e imprescindible para el éxito del servicio.

Como hemos mencionado antes, los dos días previos a la 5ª reunión del TF-CSIRT se celebró la primera edición de los cursos de formación de nuevo personal de CSIRTs. Se hizo una valoración muy positiva de los mismos aunque se vio una necesidad urgente de financiación para próximas ediciones, bien mediante dinero procedente de la Comisión Europea o mediante autofinanciación por tasas de asistencia.

En cuanto a las relaciones con la Comisión Europea, y puesto que, como ya hemos señalado, los dos proyectos presentados por parte de la delegación del Task Force fueron rechazados, se discutió si a partir de este momento seguía siendo interesante la colaboración con la Comisión y de qué forma. La respuesta a la primera pregunta fue unánimemente sí y en cuanto a la forma, se decidió seguir manteniendo reuniones periódicas entre la Comisión y representantes del TF-CSIRT y escribir una carta a altos cargos de la Comisión con una declaración de principios de todos los CERTs en Europa dando alternativas para fomentar la cooperación entre los mismos.

En cuanto a los Grupos de Trabajo asociados a este Task Force se anunció la terminación del IODEF WG (Incident Object Description and Exchange Format Working Group), para el establecimiento de una definición común y una taxonomía de alto nivel de incidentes de seguridad que permita el intercambio de información relativa a incidentes entre CERTs. Así mismo se anunció la creación de un nuevo Grupo de Trabajo para el desarrollo de las especificaciones de una herramienta para la gestión de incidentes. Este WG no se encargará de desarrollarla, sino simplemente de especificar los requisitos de la misma.

Quizá el aspecto más importante de la reunión fue una discusión sobre el futuro del Task Force. Éste, se estableció con dos años de duración (de mayo del 2000 a mayo del 2002) y se aproxima la fecha de su terminación. Todos los representantes de los CERTs que asistieron a la reunión, así como la propia TERENA, decidieron que era muy positivo ampliar el TF dos años más. Para ello será necesario revisar los "Términos de Referencia" asociados con el TF (incluir nuevos grupos de trabajo, terminación de aquellos de los que se habían obtenidos los objetivos marcados, ampliación de objetivos, etc.). La versión definitiva del nuevo "TF-CSIRT Terms of Rerefence" se anunciará en la próxima reunión del TF-CSIRT que se celebrará en Copenhague el próximo mes de mayo.

Referencias:

• http://www.terena.nl/task-forces/tf-csirt/
• http://www.rediris.es/rediris/boletin/52/actualidad.html#CERTs
• http://www.rediris.es/rediris/boletin/53/actualidad.html#CERT-COORD
• http://www.rediris.es/rediris/boletin/56/actualidad.html#csirt
• http://www.rediris.es/rediris/boletin/57/actualidad.html#tf-csirt

Grupo de Trabajo IODEF de TERENA

Uno de los objetivos más importantes contemplados en el Task Force TF-CSIRT de TERENA (http://www.terena.nl/task-forces/tf- csirt/tf-csirts-tor.html) es el de promover estándares comunes y procedimientos de respuesta a incidentes de seguridad. Éste es precisamente el propósito del Grupo de Trabajo IODEF (Incident Object Description and Ex- change Format) enmarcado dentro de dicho Task Force; el establecimiento de un formato de datos y de procedimientos de intercambio comunes para la compartición de información relativa a incidentes de seguridad entre los diferentes CSIRTs. El resultado de este Grupo de Trabajo no sólo beneficiará a los CERTs que colaboran en el TF-CSIRT, sino también a toda la comunidad integrante del FIRST (Forum of Incident Response and Security Teams). Además permitirá en un futuro, parece no muy lejano, un intercambio de información relativa a incidentes de seguridad más eficaz, la generación de estadísticas globales y el reconocimiento de tendencias o patrones de ataques.

Cuando empezó el TF-CSIRT, en mayo de 2000, comenzó también el trabajo relacionado con el IODEF, aunque el grupo de trabajo como tal no se creó hasta finales de 2000. Desde entonces se han celebrado dos reuniones, una en Manchester en septiembre de 2001 y otra en Estocolmo en enero 2002.

Los resultados de este Grupo de Trabajo hastaenero de 2002 cuando, en la quinta reunión del TF-CSIRT en Estocolmo, se decidió su disolución al haberse conseguido todos los objetivos marcados, han sido los siguientes:

• La definición de una taxonomía de alto nivel para la clasificación de incidentes.
• El desarrollo de un documento sobre clasificación de incidentes y la forma de operación que actualmente llevan a cabo los distintos equipos que colaboran en el TF- CSIRT. Este documento permitió comenzar a trabajar a partir de una imagen de la situación real en cuanto a gestión de incidentes en los distintos CERTs (http://www.terena.nl/task-forces/tf-csirt/iodef/docs/BCPreport1.rtf).
• El desarrollo de un documento que describe los requerimientos funcionales que ha de cumplir un Objeto Incidente. Este documento, terminado en febrero de 2001, dio lugar al RFC 3067 (http://www.ietf.org/rfc/rfc3067.txt).
• La elaboración de un documento que describe la relación entre el formato de intercambio de gestión de incidentes propuesto por el IODEF y el propuesto por el Grupo de Trabajo de la IETF IDMEF (Incident Description Message Exchange Format). El formato IDMEF es el que se utiliza para el intercambio de mensajes entre IDSs (Sistemas de Detección de Intrusos).
• El desarrollo de un documento, cuya última versión vio la luz en febrero de 2002 (http://www.terena.nl/task-forces/tf- csirt/iodef/docs/iodef-xmldtd-draft-005- final.dtd y http://www.terena.nl/task- forces/tf-csirt/iodef/docs/iodef-datamodel- draft-005-final.html), y que describe el Modelo de Datos del IODEF y la descripción como XML DTD (Extensible Markup Language Document Type Definition) del mismo. La idea es presentar este documento como un Internet draft para que lleque a ser un RFC.
• La elaboración de una batería de ejemplos de incidentes para poder contrastar el IODEF en el mundo real (http://www.terena.nl/task- forces/tf-csirt/iodef/docs/exampleset/ index.html)
• El desarrollo de una guía de recomenda- ciones de uso del IODEF.

El trabajo desarrollado en el Grupo de Trabajo IODEF ha estado coordinado con otros grupos. Por este motivo en diciembre de este año, se organizó en la IETF una sesión sobre el IODEF, llamado INCH BoF. La idea era presentar el trabajo realizado hasta el momento por el Grupo de TERENA y, si el tema se consideraba de interés, que la IETF formara otro grupo para continuar trabajando sobre este Objeto Incidente definido y así desarrollar un estándar a nivel mundial. La respuesta fue muy positiva y el grupo de trabajo se ha formalizado en la IETF (http://listserv.surfnet.nl/scripts/wa.exe?A2=ind02&L=inch&F=&S=&P=704).

Puesto que los objetivos del Grupo IODEF se habían cumplido, este Grupo se disolvió en la última reunión del TF-CSIRT en Estocolmo en enero de 2002, ya que lo más lógico era pasarle el relevo al nuevo Grupo de Trabajo de la IETF, que tiene más capacidad de acción e influencia a nivel mundial.

Aunque no es parte del IODEF WG, pero si una consecuencia directa del trabajo desarrollado por el mismo, TERENA ha aprobado un piloto para la implementación del IODEF en un entorno real de manejo y gestión de incidentes. Este piloto, que será implementado por CERT- NL (SURFnet) y JENET-CERT (UKERNA), permitirá definir los procesos de intercambio de los objetos incidentes entre CERTs y las APIs para que esos objetos sean entendidos por las herramientas de gestión de incidentes que se utilicen. Se puede encontrar más información sobre este Piloto en http://www.terena.nl/task-forces/tf-csirt/iodef/iodef-pilot-proposal.txt.

Reunión Técnica del FIRST 2002

Los días 11 y 12 de febrero se celebró en las Oficinas de CISCO en Londres la reunión técnica del FIRST, restringida a miembros de los Grupos de Seguridad.

Estas reuniones técnicas están organizadas en forma de sesiones en las que se van tratando diversos aspectos relacionados sobre todo con la gestión de incidentes de seguridad, y las soluciones ante nuevos incidentes.

Renault Bidou, de la compañía Francesa Intexxia realizó una presentación del sistema desarrollado por esta compañía para el tratamiento completo de los incidentes de seguridad, desde que se detecta un incidente en un sensor (router, IDS, logs de equipos, etc.), cómo se analiza y normaliza a un formato estándar toda la información y cómo después se emplea para llevar a cabo las acciones apropiadas (generar un incidente de seguridad, solucionar el problema, etc.)

Esta empresa ha implementado este esquema empleando software libre, para más información consultar las página WWW de la compañía: http://www.intexxia.com.

Jan Meijer del equipo de seguridad de la red holandesa, SURFnet, realizó una presentación sobre el Formato de Descripción de Objetos Incidentes de Seguridad (IODEF), sobre el cual hay más información en este mismo boletín.

Hubo después una demostración práctica de los problemas de seguridad que pueden plantear los sistemas de envío de mensajes de texto, los "pagers", que aunque están siendo sustituidos por el envío de mensajes SMS aún se utilizan mucho en ciertos sectores, como sistemas de alerta y monitorización. La seguridad de estos sistemas es muy limitada, siendo muy fácil acceder a los diversos componentes (receptor de onda corta, conector a un ordenador, software) y tener un decodificador de este tipo de mensajes.

Otro de los temas comentados fue un programa de rootkit existente en Internet que se puede emplear como rootkit en NT ( http://www.megasecurity.org/Tools/Nt_rootkit_all.html). Un rootkit es un conjunto de programas que suelen instalar los atacantes, una vez que han conseguido acceder al equipo, para ocultar su presencia a los administradores del equipo y obtener un acceso posterior al sistema más cómodamente.

NT rootkit permite instalar rootkit en NT, oculta procesos que empiecen por "_root_", también a nivel de registro y permite tener el Netcat escuchando en un puerto para lanzar un interprete de comandos (cmd.exe) al realizar la conexión.

La solución: "el rootkit no se oculta a los procesos que empiezan por "_root_", por lo que se puede emplear cualquier programa, como Regedit, renombrándolo a "_root_regedit" para consultar estas entradas del registro.

Este rootkit también permite el acceso remoto al equipo, empleando su propia pila TCP/IP, por lo que ninguna de las herramientas del sistema puede detectar si en ese momento hay establecida una conexión con la máquina del atacante.

A continuación se comentaron los programas que se pueden emplear para analizar los ataques en los sistemas NT y poder detectarlos, estas herramientas se pueden encontrar en: http://www.foundstone.com y http://www. sysinternals.com, así como en el Kit de Recursos que proporciona Microsoft, aunque no son completamente efectivas ante este rootkit, sí permiten detectar gran parte de los que se suelen encontrar ahora mismo en ataques contra servidores NT.

En una segunda sesión Renauld Deraison, uno de los autores del programa Nessus (http://www.nessus.org) realizó una presentación y demostración práctica sobre este programa.

Como muchos conocerán Nessus es un escáner de vulnerabilidades remoto desarrollado bajo licencia GPL. Este programa consta de dos partes, el servidor (disponible para gran parte los sistemas operativos Unix/Linux) y un programa cliente que se encuentra disponible también para Windows.

Este programa en su versión actual soporta más de 800 comprobaciones de seguridad, teniendo un lenguaje de programación llamado NASL (Lenguajes de Script de Ataques de Nessus), que permite definir nuevas comprobaciones de seguridad, empleando además funciones ya predefinidas: conexión a servidor WWW, acceso a CGI, etc. Este lenguaje no permite el acceso a ficheros locales para evitar así que la ejecución de estos scripts pueda ser usada por un atacante para acceder al equipo.

Por otro lado Nessus soporta la generación de los informes en diversos formatos, HTML, LaTeX, PDF, etc., incluyendo diversas opciones de visualización de las estadísticas que se han generado.

El autor nos comentó las nuevas características en las que están trabajando en la actualidad:

• La mejora del sistema de escaneo de equipos, para poder auditar grandes redes.
• La implementación de varios niveles de auditoria, que permitan evitar problemas con determinadas comprobaciones que pueden llegar a bloquear un servicio
• La creación de una base de datos de conocimiento, con la información previamente escaneada de la red, de forma que las nuevas comprobaciones tengan en cuenta la información que se conoce y se pueda hacer un inventario del sistema.
• La optimización de las comprobaciones, por ejemplo aplicar las pruebas sólo ante fallos de seguridad en el IIS cuando se compruebe que el servidor WWW es un servidor IIS.
• La posibilidad de actualización de plugins y aplicaciones solamente de los nuevos tests de seguridad, de forma que las comproba- ciones de nuevos problemas se puedan realizar rápidamente.

Asimismo se está pensando en las siguientes opciones para la próxima versión:

• La creación de un interfaz WWW, de forma que no se requiera una aplicación cliente para lanzar Nessus.
• Instalación de servidores de vulnerabilidades distribuidos, de forma que se pueda comprobar la red en menos tiempo todavía.

En las sesiones de la tarde hubo una interesante presentación de Rob Thomas (http://www.cymru.com/~robt), sobre problemas de seguridad en los equipos CISCO, aunque sea reiterativo decirlo, se detecta muchas veces que los routers no están protegidos contra accesos externos y que las passwords suelen ser triviales (Ej. Cisco/cisco), lo que hace que muchas veces los atacantes accedan a estos sistemas.

Además se está comprobando que los routers se emplean cada vez más como herramientas de denegación de servicio, y que suelen estar muy valorados en lo que se podría llamar el "mercado de cambio de equipos", es decir equipos a los que se tiene acceso.

Por otra parte en los routers atacados se ha comprobado que muchas veces los atacantes suelen, tras cambiar el password de acceso, aplicar ellos mismos filtros de acceso, deshabilitar Netflow (que podría desatarlos cuando se produce un ataque de denegación de servicio) y configurar un interfaz de loopback con la dirección que se pretende enviar falsificada en estos ataques.

Por último indicar que en la medida de lo posible no se deben configurar los routers para que descarten paquetes IP, sino que se deben enrutar a un dispositivo vacío ya que provoca un menor trabajo de la CPU.

La última sesión de este día consistió en un coloquio sobre la problemática de los incidentes de seguridad, la sobrecarga de trabajo en la gestión diaria de incidentes que ocasionan los últimos problemas de seguridad, como los gusanos CodeRed y NIMDA...

El segundo día se dio un tutorial sobre análisis forense, en el que se trabajó con una imagen forense obtenida de una máquina Linux atacada y se emplearon diversas herramientas para analizar el ataque.

Nuevo equipo español en FIRST

Tras la reunión técnica del FIRST hubo una reunión del Comité Ejecutivo donde se aprobó la incorporación del grupo de seguridad de la Universidad Politécnica de Cataluña (esCERT-UPC http://escert.upc.es) al FIRST, como miembro asociado.

EsCERT-UPC se creó hace bastante tiempo en la Universidad Politécnica de Cataluña y está participando en diversas iniciativas en Europa como el foro TF-CSIRT de TERENA (http://www.ti.terena.nl), teniendo el nivel 2 de "Trusted Introducer".

Durante el último año también se han incorporado diversos grupos de seguridad de Latinoamérica, existiendo en la actualidad los siguientes grupos:

• APSIRT, grupo de seguridad de ATT Latinoamérica con sede en Perú
• CAIS, grupo de seguridad de la red académica brasileña
• MxCERT, grupo de seguridad de Méjico
• UNAM-CERT, grupo de seguridad de la Universidad Autónoma de Méjico.

En la actualidad FIRST agrupa a más de 100 grupos de seguridad de redes y países de todo el mundo, en su servidor WWW se puede encontrar una lista de los grupos que lo integran (http://www.first.org/team-info)

Novedades PAPI

El pasado 6 de febrero tuvo lugar una nueva reunión sobre PAPI (Puntos de Acceso a Proveedores de Información) donde asistieron las organizaciones que, o ya están funcionando con este sistema de control de acceso o piensan hacerlo a corto-medio plazo. Los puntos más importantes de dicha reunión fueron:

• Nuevas características de la versión 1.1
  En este punto se presentaron las nuevas funcionalidades que incorpora el sistema. La principal es la posibilidad de los PoAs (Puntos de Acceso) de heredar políticas de acceso. En pocas palabras, podemos tener un PoA padre y dejar a éste la decisión de dejar pasar o no un acceso web que esté controlado por un PoA hijo. Supongamos que realizamos una consulta a una zona del web protegida por PAPI; esa zona tendrá un control de acceso (un PoA). Cuando la consulta llega al servidor el PoA comprueba si tiene las claves para entrar, si las tiene la deja pasar y la consulta sigue su camino normal, si no las tiene, este PoA redirige la decisión a su PoA padre y es este último el que decide. Por eficacia, este proceso sólo ocurre la primera vez, permitiendo (siempre que el PoA padre lo haya autorizado) el paso en sucesivas veces. ¿Qué aplicación práctica tiene esto?. Pensemos por ejemplo en un departamento donde hay zonas del web protegidas por PAPI y supongamos que la mayoría de los miembros de ese departamento tienen acceso a estas zonas. Podemos configurar a uno de los PoAs para que actúe como padre del resto y de esta forma repartiendo una sola llave (para el PoA padre) se puede dar acceso a todos los PoAs hijos.
• Desarrollos para plataformas no basadas en Apache
  Se ha desarrollado un módulo de control de acceso PAPI para servidores web Internet Information Server. Este podrá a partir de ahora tener zonas protegidas mediante PAPI. Aprovechando esta implementación del PoA, se está desarrollando toda una librería "C" para implementar PAPI en la mayoría de las plataformas, de una manera fácil.
• Nuevos servicios de autenticación
  Se presentaron nuevos servicios de autenticación. Uno de ellos, en concreto, está basado en la utilización del teléfono móvil para recibir la clave de autenticación.
• Escenarios de aplicación
  Se presentó una alternativa para los que quieran incorporar este sistema sin dedicar mucho tiempo a su instalación, configuración, pruebas, etc. Se trata de una iniciativa por la cual se instala el sistema PAPI en RedIRIS (Servidor de Autenticación o Punto de Acceso), se prueba y se trabaja sobre él, y cuando la organización decida, lo incorpora dentro de su sistema. Con esta iniciativa pretendemos potenciar el uso de PAPI, paliando en la medida que sea posible, los recursos dedicados a su instalación y prueba.
• Líneas de trabajo futuras
  La incorporación de nuevas funcionalidades de reautenticación para transacciones que así lo precisen (transacciones críticas), y la compatibilidad del modelo PAPI a su equivalente en Internet2 (Shibboleth).

Dentro de este número del boletín aparece un artículo que describe el sistema PAPI, en él se puede conocer con detalle su funcionamiento y arquitectura.

IV Reunión del TF de TERENA sobre directorio LDAP (TF-LSD)

El pasado 29 de octubre tuvo lugar en Amsterdam la cuarta reunión del grupo de trabajo sobre directorios basados en LDAP.

Se hizo un repaso al estado de las acciones emprendidas en anteriores reuniones y se discutió en particular sobre una de ellas, encaminada a la promoción del uso de directorios en los ámbitos académicos.

Nordunet informó sobre los contenidos del Simposio GNOMIS que tendrá lugar a comienzos de noviembre en Hurdal, cerca de Oslo, donde las redes académicas de los países escandinavos debatirán sobre la movilidad de estudiantes y profesores entre los distintos países. Se habló de PAPI como una buena solución para parte de los problemas comunes.

Otro de los puntos tratados en la reunión fue el asunto de la privacidad de los datos almacenados en servicios y directorios. Se debatió sobre la conveniencia de regirse por las directivas europeas al respecto, y se propuso el estudio de P3P 1.0, una especificación del W3C sobre preferencias de privacidad.

Asímismo se trató del proyecto emprendido por varias redes académicas, entre ellas RedIRIS, para dotar a OpenLDAP de un mecanismo para la adquisición de certificados digitales.

Finalmente, nos pareció de especial interés la propuesta para la Definición de una `European Education Person' (DEEP), con las características que habría de tener cualquier miembro de la comunidad académica a nivel europeo. Se debatió la posibilidad de aunar criterios en la definición de EduPerson con la propuesta de Internet2.

Referencias:

Proyectos en el programa ALIS y CAESAR

ALIS (http://europa.eu.int/comm/europeaid/ projects/alis) es la Alianza para la Sociedad de la Información con América Latina (@LIS). Sus objetivos fundamentales son reforzar la cooperación entre América Latina y la Unión Europea en materias esenciales de la Sociedad de la Información: telecomunicaciones, comercio electrónico y normalización y promover la interconexión de las redes académicas y de investigación de las dos regiones. Este programa ha abierto el periodo de recepción de proyectos, siempre dentro del marco de la Sociedad de la Información, cuyas actividades se desarrollarán fundamental- mente en cuatro áreas: Administración local, Educación y diversidad cultural, Sanidad pública e Integración social (http://europa.eu.int/comm/europeaid/projects/alis/ guidelines_en.pdf)

Se dispone de un fondo de la Comisión Europea (CE) para la financiación de proyectos con un cantidad total de 40 MEUR, con una aportación máxima en los proyectos de la Comisión de hasta el 80%. Los consorcios deberán estar compuestos por al menos ocho participantes de los que al menos tres serán de estados miembros de la Unión Europea y uno de un país de Latinoamérica.

La fecha límite para la presentación de proyectos es el 31 de octubre de 2002 a las 12:00 horas.

Por otro lado ya ha comenzado el proyecto CAESAR (Connecting All European and South American Researchers), financiado por la CE y en el que participan DANTE, RedIRIS y FCCN, la red de investigación portuguesa. El proyecto CAESAR tiene como principales objetivos:

• Analizar la evolución de las redes académicas y de investigación en América Latina.
• Analizar la demanda para una conexión directa entre las dos regiones.
• Analizar la solución técnica y los costes de la interconexión.
• Suministrar a la Comisión Europea un informe sobre la viabilidad, con recomenda- ciones para la conexión entre las dos regiones.

La Comisión Europea ha indicado que ­en base a los resultados de CAESAR­ se podría cofinanciar el 50% de una conexión directa entre las dos regiones por tres años, hasta un máximo de 10 MEUR.