Actualidad boletín número 45

(octubre 1998)

Sumario


- Jornadas Técnicas RedIRIS 98
- Cambios en RedIRIS
- Partes de avería e informes mensuales
- Servicio RedIRISdial
- Medidas de prevención contra los abusos en el correo electrónico
- Servicio piloto a Comunidades Virtuales de Usuarios
- Proyecto piloto NameFLOW LDAP
- Nuevas versiones de software (INN) en el servidor primario de News de RedIRIS
- Próximas Reuniones de Trabajo relacionadas con seguridad
- Proyecto para nuevo servicio: análisis de seguridad bajo demanda
- La nueva red TEN-155 derivada del proyecto Quantum
- Grupo de trabajo sobre routing de RIPE
- Grupo de trabajo de Netnews de RIPE

Jornadas Técnicas RedIRIS 98

Nuevamente estamos próximos a la celebración de las Jornadas Técnicas de RedIRIS, que esta vez tendrán lugar en Barcelona, los días 23 y 24 de noviembre de 1998, y que contarán con la coordinación del Centre de Supercomputació de Catalunya (CESCA) y la colaboración de la Universitat Politècnica de Catalunya(UPC).

Las Jornadas representan la oportunidad anual para un contacto más directo entre todas las personas implicadas en el desarrollo de la red, tanto técnicos como gestores de comunicaciones de universidades y centros de investigación.

Durante el mes de julio se envió una "Solicitud de Contribuciones" para la presentación de ponencias y en el mes de octubre se enviará a los PERs de las organizaciones (Personas de Enlace con RedIRIS) los formularios de inscripción para las personas interesadas en la asistencia a las Jornadas.

La información pública actualizada irá apareciendo en la siguiente dirección:

http://www.rediris.es/rediris/difusion/JT/JT98/

Los días posteriores a la celebración de las Jornadas se celebrarán las Reuniones de los Grupos de Trabajo para el tratamiento técnico más específico de los grupos que se encuentren en marcha.

http://www.rediris.es/gt/


dirección de correo victor [dot] castelo [at] rediris.es


Cambios en RedIRIS

Nuevamente se producen cambios en nuestra plantilla. Esta vez tenemos dos bajas, por un lado Miguel Ángel Sanz y por otro Juan Antonio García. Miguel Ángel participó en el diseño y puesta en funcionamiento de RedIRIS desde que se comenzaron las primeras experiencias con el IP, poniendo siempre todo su trabajo y esfuerzo personal en el mejor desarrollo de la red. También estuvo muy directamente implicado en el desarrollo del ES-NIC y en la implantación en nuestro país del Punto Neutro. Juan Antonio, estuvo dedicado a las News, MBone y al servicio de tiempo (NTP) hasta conseguir, no solamente servicios plenamente operativos, sino llegando a producir y automatizar todo un sistema de información asociado a los mismos. A ambos nuestro agradecimiento por los magníficos servicios prestados a la red y nuestro más sincero deseo de una nueva brillante trayectoria profesional.

También informamos sobre las cuatro nuevas incorporaciones que se han producido y que nos permiten reforzar algunos de los servicios: una nueva persona en red (Esther Robles), una en aplicaciones (Ángel Luis Mateo), otra en temas de seguridad y sistemas (Consuelo Malagón), y una nueva persona en el ES-NIC (Julia González). Manuel Rincón que estuvo durante un año en la CICYT, aunque no dejó de tener una relación con la red, vuelve al CSIC colaborando con RedIRIS, a tiempo parcial, en temas internacionales. Celestino Tomás actualmente asume la coordinación tanto del Área de Red como del de Aplicaciones. De esta manera la plantilla de RedIRIS y la del ES-NIC quedan de la siguiente manera:

DIRECCIÓN: Víctor Castelo
SECRETARÍA: Mónica Núñez
GERENCIA Y ADMON.:Ana Mª Dotor
Eduardo Funcia
DIFUSIÓN: María Bolado
REL. INTERNACIONALES:Manuel Rincón
ÁREA DE APLICACIÓN:Celestino Tomás
Jesús Sanz
Javier Masa
Javier Puche
Clara Alvarez
Angel Luis Mateo
Daniel Díaz
ÁREA DE RED:Celestino Tomás
Susana Gayo *
María Isabel Cosín
Antonio Marquez
Esther Robles
SEGURIDAD Y SISTEMAS:Rubén Martínez
Consuelo Malagón
OFIMÁTICA Y OPERACIÓN:Eva Prieto
ES-NIC:Susana Gayo *
Carolina Manzano
Lourdes Montero
Miguel Ángel Ponce
Begoña Prieto
Alejandro Oliver
Julia González
CONSERJERÍA: Mª Paz Patiño
Bárbara Oliver
* Dedicación compartida

dirección de correo victor [dot] castelo [at] rediris.es


Partes de avería e informes mensuales

Se ha puesto en marcha a partir del 1 de agosto un sistema de avisos sobre problemas de conectividad dentro de RedIRIS y en sus conexiones externas. El formato que estamos usando es similar al utilizado en el Proyecto TEN-34.

El parte de avería está formado por dos secciones: una cabecera que proporciona información abreviada sobre el aviso y el problema que lo ha originado, indicando el número de parte, estado y ámbito que se ve afectado; y una segunda sección que proporciona información más detallada del problema.

Esta información será proporcionada a las personas de contacto de cada centro, y se utilizará para tener un seguimiento más concreto de la disponibilidad real de la red.

A partir de septiembre, se pondrá a disposición de las personas de contacto de los centros, un informe mensual del estado de la red que se podrá consultar en dos formatos distintos: HTML y PostScript.

El primer informe mensual que se realice será el correspondiente al mes de agosto y todos ellos constarán de diferentes secciones: novedades en la red, cambios en líneas y equipamiento, mapas topológicos, estadísticas de tráfico y resumen de incidencias.


dirección de correo maribel [dot] cosin [at] rediris.es

Servicio RedIRISdial

La introducción de InfoVía en el Servicio RedIRISdial (ver la Sección de Actualidad del Boletín número 44) ha sido el primer paso para la mejora del resto de los servicios que se ofrecen a las organizaciones que utilizan este acceso. Estas mejoras, que se describen a continuación, se verán completadas con la nueva migración de la InfoVia de RedIRIS que tendrá lugar a principios del año que viene y que será convenientemente anunciada en su momento.

Durante el mes de agosto de 1998 se han llevado a cabo una serie de cambios en el Servicio RedIRISdial que mejorarán los siguientes aspectos:

  • el Servicio de correo electrónico

  • la recogida y envío

  • una ligera disminución de correo basura

  • los niveles de seguridad
Estos cambios han sido trasparentes al servicio y en principio nadie tiene que haber notado interrupción alguna en el mismo. Las organizaciones usuarias de este servicio deben conocer la siguiente información:

* Acceso a RedIRIS a través de InfoVía

Es URGENTE que todas las organizaciones de RedIRISdial migren al acceso a través de InfoVía que RedIRIS pone a vuestra disposición ya que a partir de enero de 1999, sólo se admitirá el acceso a los servicios de RedIRIS a través de InfoVia, denegando estos servicios a través de otro tipo de proveedor que no sea RedIRIS.

* Servicio Central de Buzones de RedIRIS

Como es bien sabido la seguridad en Internet es un tema crítico junto con el alarmante uso ilegal de servidores incorrectos. Lógicamente RedIRIS no está exenta de este problema, habiendo sufrido múltiples incidentes, lo que nos ha llevado a modificar algunos puntos de nuestra política de acceso a RedIRISdial en concreto al uso del correo electrónico.

Actualmente hay organizaciones afiliadas a RedIRIS que acceden a la red a través de proveedores comerciales, pero en cambio usan algunos de los servicios de RedIRIS, como es el correo electrónico. La dirección de RedIRIS considera que no tiene sentido esta situación y que si una organización accede a través de un proveedor comercial también puede solicitar de éste otros servicios. Por lo tanto a partir del 1 de octubre de 1998 ha entrado en vigor la siguiente política que se aplicará tanto al ENVIO de correo- electrónico usando la máquina oficial de RedIRIS: chico.rediris.es; como a la RECOGIDA de correo electrónico usando la máquina oficial de RedIRIS: dialmail.rediris.es

Sólo se permitirá utilizar estas máquinas para el envío y/o recogida de correo DESDE las siguientes direcciones IP:

  • las de InfoVia de RedIRIS

  • las asignadas por RedIRIS a organizaciones afiliadas conectadas vía línea dedicada o RDSI

  • alguna otra que previamente sea validada.
El resto de los accesos serán denegados.


dirección de correo jesus [dot] heras [at] rediris.es

Medidas de prevención contra los abusos en el correo electrónico

Existen dos medidas fundamentales para intentar prevenir uno de los tipos de Abuso de Correo Electrónico (ACE) más importantes como es la difusión a través de canales no autorizados y son:

  1. El correcto diseño del servicio de correo electrónico dentro de una organización.

  2. La configuración adecuada de los servidores de correo.

El correcto diseño del servicio de correo electrónico dentro de una organización

El diseño del servicio de correo debe estar íntimamente relacionado con la topología física de la red y acoplarse a ella. La estructuración idónea del servicio debe basarse en un encaminamiento de correo centralizado. Existe más información sobre el tema en:

http://www.rediris.es/mail/coord/sendmail/estafeta.html

Las coordenadas básicas para este diseño son:

  1. Definición de uno o varios servidores

    Uno de ellos será el principal y el resto secundarios de backup. La definición de estos servidores permitirá concentrar todos los esfuerzos y recursos en garantizar seguridad y calidad de servicio. Estarán claramente reflejados en los registros de tipo MX.

  2. Exclusivamente las máquinas gestionadas por el Servicio de Correo Electrónico de cada organización deberán disponer de procesos SMTP operativos accesibles desde el exterior. Aún así es necesario, por lo menos conocer qué máquinas locales disponen de servidores SMTP.

    Los responsables del servicio deberán estar completamente coordinados con los gestores del Domain Name Server (DNS). Al asignar una dirección IP a una máquina se debe informar al propietario de las implicaciones de habilitar procesos SMTP si fueran necesarios.

  3. Registros de tipo MX.
    Una vez definido el espacio de direcciones lógicas de correo electrónico sólo esas y nada más que esas deberán disponer de registros MX.
  4. Filtros de acceso en los routers.
    Para obtener beneficios con la implantación de una topología centralizada es necesario la utilización de medidas expeditivas como es el filtro del puerto 25 en el conmutador que da acceso a Internet. De tal forma que:

    "Sólo los servidores definidos en el punto 1 deberán ser accesibles desde el exterior de nuestra Red. Para ello habrá que definir "listas de acceso" en los routers para que sólo encaminen paquetes IP por el puerto 25 de los servidores definidos, el resto denegado"

Configuración adecuada de los Servidores de correo

Aquí se exponen los requisitos mínimos a tener en cuenta a la hora de configurar el servidor principal de correo electrónico que debe constituir el corazón del servicio y un bastión para la seguridad y contra los abusos del servicio. Éstos requisitos son:

  1. Definir el espacio de direcciones de correo lógicas de las que es responsable el servidor (reflejadas en los registros de tipo MX). No hay que olvidarse de los dominios virtuales de los que se responsabiliza en caso de que los hubiera.

  2. Definir claramente las direcciones IP de las redes a las que damos servicio de correo electrónico y que deben ser las únicas que deberán tener permiso de utilizar el servidor principal para encaminar correo. A cualquier otra se la debe denegar el servicio en la transacción SMTP.
    Es decir, hay que tener control de las direcciones IP que tienen permiso para establecer una sesión SMTP contra nuestro servidor, lógicamente se incluyen tanto Agentes de Usuarios desde PCs como servidores de correo electrónico secundarios internos de nuestra organización.

  3. No aceptar correo desde direcciones externas a nuestro dominio y destinadas a direcciones externas a nuestro dominio.
    Esta regla junto con la definida en el punto 2 debe denegar el encaminamiento de correo desde cualquier dirección IP fuera de nuestro dominio destinada a cualquier dirección (RCPT TO:) fuera de nuestro dominio, independientemente de cual sea la dirección origen del sobre (MAIL FROM:)
  4. .
  5. Rechazar correo en el que en la sesión SMTP aparezca un valor de MAIL FROM: sin dominio.

  6. Rechazar correo en el que durante la sesión SMTP aparezca un valor de MAIL FROM: con un dominio que no tenga resolución en el DNS.
Estos serían los requisitos mínimos que se deben definir en un servidor de correo electrónico correctamente configurado para evitar el uso ilegal de sus máquinas por parte de personas no autorizadas. Además se pueden implementar otras medidas restrictivas como pueden ser:

Listas de acceso con direcciones de dominios, usuarios y/o direcciones que se les deniega el servicio.

Si es posible se deberían implementar en la configuración del servidor las tablas de MAPS (Mail Abuse Protection System) RBL (Realtime Blackhole List) que denegarían el acceso a determinadas direcciones. Las MAPS RBL son una relación de direcciones IP de máquinas que no tienen protegido su servidor de correo, máquinas de ISPs que alquilan sus servicios para hacer spam, máquinas que hacen spam directamente, etc. Podréis encontrar más información en la siguiente dirección: http://maps.vix.com/rbl

El peligro de intentar solucionar el ACE con las listas de acceso (listas negras) es que si no se coordinan (MAPS RBL sí están coordinadas), el correo electrónico en Internet podría deteriorarse más que los problemas originados por el ACE. Podría llegarse a que sólo aceptaran correo determinados dominios en base a acuerdos de mutua confianza y el resto fuese denegado, cosa muy peligrosa.


dirección de correo jesus [dot] heras [at] rediris.es

Servicio piloto a Comunidades Virtuales de Usuarios

El equipo técnico de RedIRIS lleva tiempo trabajando para la puesta en marcha de este Servicio, el ritmo ha sido lento pero sin pausa. Se han ido añadiendo algunos nuevos servicios a los clásicos que RedIRIS ya viene ofreciendo tales como por ejemplo estadísticas de acceso Web, Cgis genéricos para tratamiento de formularios y páginas amarillas.... Hay algunos otros en fase experimental como puede ser el BSCW que se trata de una herramienta de trabajo en grupo para la edición de páginas HTML.

El objetivo principal del Servicio es la creación de contenidos y el eje principal sigue siendo la indexación y la posibilidad de realizar búsquedas de la información que se va almacenando.

Por muchos y diferentes motivos este tema está teniendo cierta complejidad técnica que está a punto de resolverse en esta primera fase con una serie de desarrollos propios del equipo técnico de RedIRIS. Todavía falta bastante por hacer y organizar, pero el servicio lleva ofreciéndose de forma parcial y provisional desde hace unos 4 meses aunque ya va encontrándose en una fase de consolidación.

Se ha abierto una página sobre este proyecto en la dirección: http://www.rediris.es/cvu donde aparecerá toda la información que se irá actualizando continuamente. En ella se puede obtener la relación de grupos que se han ido uniendo al Servicio, entre los que se encuentran:

Docencia de la Historia: http://clio.rediris.es
Cálculo Simbólico y aplicaciones: http://csimbolico.rediris.es
Organización de Empresas: http://empresa.rediris.es
Geología y Recursos Naturales: http://tierra.rediris.es
Astrofísica: http://astrored.rediris.es
Paleontología y Paleopatología Humana: http://paleopolis.rediris.es
Derecho Financiero y Tributario: http://derfintrib.rediris.es
Tecnologías Educativas: http://edutec.rediris.es
y otros ya divulgados en anteriores números de este boletín:
Neurociencias: http://neurociencias.rediris.es
Cirugía ortopédica y traumatología: http://ortopedia.rediris.es
Historia Contemporánea: http://hispanianova.rediris.es

Hasta ahora, la incorporación de estos grupos al proyecto piloto se ha llevado a cabo informalmente por la ausencia de mecanismos que lo articulasen de forma adecuada. Estos grupos han demostrado consistencia y disponen de suficientes avales y apoyos dentro de la comunidad académica española para haber sido aceptados y por tanto darles el máximo nivel de servicio y calidad que RedIRIS sea capaz. A medida que el Servicio vaya avanzando se irán creando y mejorando los procedimientos de adhesión.

La idea del equipo de RedIRIS es fomentar la coordinación con los representantes de estos grupos para intentar crear un canal fluido de intercambio de ideas respecto a nuevos servicios, aplicaciones y herramientas corporativas. Se puede encontrar más información en la siguiente dirección: http://www.rediris.es/cvu


dirección de correo jesus [dot] heras [at] rediris.es


Proyecto piloto NameFLOW LDAP

Debido al auge tan importante que están teniendo en la actualidad los servicios de búsqueda de información sobre personas en los directorios existentes, parece que el servicio NameFLOW-PARADISE basado en X.500 es una de las alternativas más importantes para el desarrollo de un servicio de directorio mundial.

Se han realizado pruebas de migración de la actual infraestructura del servicio NameFLOW-PARADISE existente, basado en servidores X.500 (88), a servidores X.500 (93). Se han encontrado numerosos problemas para la interoperabilidad de las diferentes implementaciones y no se ha llegado a realizar dicha migración.

Existen problemas adicionales para la continuidad de la actual infraestructura ya que la mayoría de los servidores están basados en QUIPU, una implementación de dominio público que tendrá problemas de funcionamiento tras el año 2.000.

DANTE ha propuesto la creación de un grupo de trabajo para la migración de la infraestructura de directorio actual basado en X.500 (88)/QUIPU a una basada en el protocolo LDAP.

Los principales objetivos que se han planteado en este grupo de trabajo son:

  • La evolución de la arquitectura actual a una basada en productos de libre distribución, baratos, abiertos, fáciles de usar, de modificar, de ampliar, etc.

  • Proporcionar índices con la información que contiene el directorio para facilitar y agilizar las consultas.

  • Proporcionar compatibilidad con las versiones QUIPU (88) en caso de que fuese necesario.

El grupo de trabajo creado tuvo una reunión en mayo donde se hablo de lo siguiente:

Estado actual de NameFLOW-Paradise

Las estadísticas han mostrado que existe un incremento en el número de organizaciones y de DSAs. El número de consultas desde los clientes Web va creciendo al mismo tiempo que el número de DSAs que se encuentran no operativos decrece.

Se analizaron los resultados del piloto X.500 (93). Aunque los protocolos DAP, LDAP y DSP funcionaron realmente bien, se encontraron varios problemas con el protocolo DISP en términos de interoperabilidad entre los diferentes fabricantes, además de que el mecanismo de listas de control de acceso es bastante complejo de administrar.

Se comentó el problema que tendrán todos los servidores QUIPU en el año 2.000, especialmente en términos de replica. Para solucionar este problema habría que reescribir parte del software QUIPU y el esfuerzo necesario parece no ser rentable.

La infraestructura general del servicio de directorio en la mayoría de lo países consta de un conjunto interconectado de servidores basados en QUIPU y en X.500 (93). Existen servidores LDAP independientes alcanzables vía un producto comercial llamado "X.500 enabler".

En Suecia han realizado una pasarela Web-LDAP llamada WIXI ( http://wixi.umu.se:1400/c=es). Su objetivo es crear un índice de referencias independiente del protocolo de uso (X.500, whois++, LDAP, etc.) y se empezará un piloto en septiembre.

Presentación del Consorcio de Directorio Internet (IDC)

Se presentó una iniciativa para crear un nuevo grupo sobre un directorio Global después de la finalización del grupo EuroSInet y de la retirada del Consorcio Internet Mail (IMC) del trabajo de directorios.

El grupo IDC ( http://www.opengroup.org/idc/) está pensado para desarrolladores, distribuidores y otras partes interesadas en los directorios. Los principales objetivos son:

  • Representar las necesidades de la industria de directorios.

  • Desarrollo de programas para realizar testeos

  • Creación de tests de interoperatibilidad entre diferentes fabricantes

  • Registro de esquemas de objetos

Presentación del Piloto LDAP

Este piloto se crea para el testeo de un servicio de directorio distribuido basado en un conjunto de servidores LDAP. LDAP cumple con los requerimientos que DANTE se propone al comenzar el proyecto, ya que LDAP es abierto, de dominio público, fácil de mantener, extensible,...

El proyecto incluye una infraestructura para la interconexión de servidores LDAP mediante un backbone de un servidor LDAP gestionado por DANTE. Este servidor obtiene información de los servidores LDAP nuevos en la red mediante el uso de robots especializados.

Habrá servidores de índice nacionales con referencias a las entradas del país. Estos servidores serán proporcionados por las respectivas organizaciones o por DANTE. Este servicio debería soportar tanto el nombrado geográfico actual (X.521) como el nombrado basado en dominios (RFC-2247). NameFLOW no actuará como una autoridad de registro de nombres aunque pueda actuar a la hora de la resolución de conflictos.

Se proponen los requisitos mínimos necesarios para los clientes LDAP así como para el backbone y los servidores nacionales LDAP. La reunión se centró en tres puntos fundamentales:

a) Consideraciones generales

Se adelantó dónde la tecnología LDAP no está madura aún para un servicio en producción. Se dejó claro que el proyecto propuesto es piloto, un trabajo de investigación y sólo si funciona será difundido y usado. Se necesitaría, por lo tanto, una tecnología alternativa para el caso en que este piloto LDAP fallase y antes de que el problema ocasionado por el año 2.000 hiciera que los servidores basados en X.500 públicos no pudiesen utilizarse correctamente.

Se optaría por crear un servicio híbrido en el que se combinase un backbone de servidores X.500 para la raíz y para los servidores raíz de cada país y servidores LDAP para todas las organizaciones.

b) Indexado

Se comentó la posibilidad de que la utilidad de los índices no fuera la esperada argumentando que el resultado podría ser similar al producido por AltaVista. Por ejemplo, una búsqueda de "José García" en "el mundo" podría devolver miles de referencias. También existen problemas de escalabilidad y tienen tenerse en cuenta. El piloto propuesto incluirá inicialmente sólo un índice de organizaciones.

El grupo también está de acuerdo en diseñar los interfaces de búsqueda para los usuarios de forma que las búsquedas por defecto no correspondan a búsquedas por todo el mundo.

c) Esquema de nombres

Ya se ha comentado que han de soportarse el esquema geográfico y el esquema de nombres por componentes, incluyendo los problemas de mapeo y la decisión de dónde colocar el árbol de información del directorio actual (DIT). En cualquier caso, este mapeo sería una contribución de gran valor para toda la Internet independientemente de su uso en este proyecto.

El grupo acordó los puntos que se enumeran a continuación:

  • El indexado estará basado en la parte de índices del proyecto DESIRE II

  • Se investigará en un servicio híbrido X.500-LDAP en lugar de la actual infraestructura basada en QUIPU

  • Se continuará con el piloto LDAP

Para ello se van a formar dos grupos, uno para los temas de índices como parte del trabajo de DESIRE II y otro para el piloto LDAP NameFLOW. Se investigará en un servicio híbrido X.500-LDAP NameFLOW hasta junio 1999 como una posibilidad de retirada y se reeditará el plan del proyecto piloto.

http://www.dante.net/np/LDAP-Pilot-Plan-01.txt
http://www.dante.net/np/mtg/98may.html


dirección de correo javier [dot] masa [at] rediris.es

Nuevas versiones de software (INN) en el servidor primario de News de RedIRIS

Las nuevas versiones (2.x) del software de NetNews INN, están haciendo mucho más fácil tanto la instalación del nuevo servidor como su mantenimiento y al mismo tiempo permiten un funcionamiento mucho más eficaz. Lejos quedan ya cosas como: tener que modificar los ficheros config.data, los errores de compilación, problemas de configuración, el tener que recompilar el software cada vez que se quisiera modificar alguna opción de funcionamiento del servidor, etc.

Con la versión 2.0 se consiguió facilitar:

  1. El procedimiento de instalación:
    • Configuración automática adaptada al sistema. (Gnu configure)

    • Compilación e instalación no problemáticas gracias a la configuración automática.
  2. La posibilidad de configurar más parámetros del servidor.
    • Se permite gracias a un completo `inn.conf' configurar numerosos parámetros que antes sólo era posible modificando determinados ficheros como el `config.data' y recompilando de nuevo el software para que se tuvieran en cuenta las modificaciones efectuadas.
    Nuevos métodos de almacenamiento:

    CNFS

    Este nuevo método de almacenamiento en esencia consiste en un buffer circular en el que se almacenan los artículos secuencialmente, de modo que cuando se alcanza el fin del buffer se sobreescriben. Este método tiene ventajas e inconvenientes, no requiere la ejecución de procesos de expiración, pero por el contrario también se hace difícil el control de los tiempos de expiración de cada grupo/jerarquía.

    Timehash

    Consiste en almacenar cada artículo recibido en directorios basados en el tiempo de llegada, de modo que ningún directorio contenga tantos ficheros (artículos) como para constituir un cuello de botella por mucho tráfico que tenga, pero como consecuencia se degrada la velocidad del servicio debido a la sobrecarga de entrada/salida sobre el filesystem.

La versión dónde realmente se ha mejorado este software es la 2.1 y aún lo hará más en la 2.2 cuya primera revisión fue en principio anunciada para principios de año pero parece que será publicada a lo largo de este mes de octubre.

Estas versiones incorporan una mejora real en lo que a `autoconfigure' y `automake' se refiere, resolviendo los problemas que en este aspecto tenía la primera de las versiones `2' (la 2.0).

Se ha instalado la versión 2.1 de INN tanto en el servidor primario como el terciario de RedIRIS, eligiendo el método de almacenamiento clásico, ya que:

  • Es necesario poder ejercer una política de expiración manual.(razón por la que no se configura CNFS)

  • Es necesario aprovechar al máximo la velocidad de los discos. (por lo que se rechaza el método basado en Timehash)

Esperemos que desde el Internet Software Consortium se siga apoyando este tipo de software, a pesar de los últimos rumores. Asimismo cabe esperar la aparición de nuevas versiones, posteriores a la versión 2.2 (quizás a principios del 99) que incluyan las nuevas herramientas de control (groupsync) que desde el Newsbone se están desarrollando y que evitan todos los problemas que el procesamiento de mensajes de control está provocando.


dirección de correo daniel [dot] diaz [at] rediris.es

Próximas Reuniones de Trabajo relacionadas con seguridad

Como viene siendo habitual, los Grupos de Trabajo de Seguridad se reunirán aprovechando las próximas Jornadas Técnicas de RedIRIS. Todas las Instituciones afiliadas están invitadas a participar en lo que esperamos sea una sesión productiva para esta comunidad. Oportunamente se distribuirá toda la información relevante sobre plazos, inscripción, etc., a través de los PERs de cada Institución.

A diferencia de ediciones anteriores en las que sólo se presentaron proyectos de certificación (grupo IRIS-PCA), en esta ocasión la reunión tendrá tres partes con motivo de la reestructuración del Servicio de Seguridad:

  • V Reunión IRIS-PCA, en la que se analizará el funcionamiento de los pilotos propuestos en la última reunión, y posiblemente se abrirán a la participación de toda la comunidad.
  • III Reunión IRIS-CERT, donde expondremos nuevos servicios y procedimientos relacionados con el Servicio de Seguridad.
  • Informe de actividades de IRIS-CERT, en el que además de publicar por primera vez estadísticas sobre el funcionamiento de este servicio, se revisarán algunos de los problemas de seguridad más importantes de este año, y se ofrecerán soluciones para los mismos.

dirección de correo ruben [dot] martinez [at] rediris.es

Proyecto para nuevo servicio: análisis de seguridad bajo demanda

El análisis de redes desde el exterior de las mismas es una parte importante de toda auditoría informática, y cada vez con más frecuencia se realizan análisis `ad-hoc' como parte integral del servicio de atención de incidentes.

La demanda creciente de este tipo de análisis nos ha movido a considerar la implantación de un servicio semi-automatizado de auditoría externa. Las características de este servicio, a discutir en profundidad en la próxima reunión IRIS-CERT-3, son las siguientes:

  • Ofrecido exclusivamente a Instituciones afiliadas, según solicitud rigurosa de un representante debidamente acreditado de las mismas. RedIRIS definirá oportunamente qué requisitos son suficientes para considerar a un representante debidamente acreditado.
  • RedIRIS se compromete a no iniciar el análisis de ninguna red sin mediar solicitud válida según el apartado previo.
  • RedIRIS se compromete a no almacenar, difundir ni utilizar de ninguna forma la información descubierta acerca de posibles vulnerabilidades de la red analizada.
  • El solicitante acepta que RedIRIS no incurre en responsabilidad alguna en relación al uso inadecuado de la información descubierta, una vez ésta ha sido transmitida a su solicitante por medios que RedIRIS considere razonablemente seguros.
  • El proceso de aceptación de una solicitud no será automatizable, por diseño. La identidad del solicitante deberá ser validada por un operador humano, al menos en la fase piloto.
  • Una vez validada la solicitud, el resto del proceso será automático. Por razones de operatividad del servicio y de disponibilidad de personal, el proceso de análisis se aplicará por igual a todo solicitante, no se adaptará a circunstancias específicas, y no se garantiza atención personalizada sobre los resultados del mismo.
  • El proceso de análisis será modular. Inicialmente constará de un módulo básico de barrido de puertos, y posteriormente, en base a prioridades basadas tanto en la demanda existente como en la disponibilidad de recursos, se extenderá mediante módulos adicionales.

dirección de correo ruben [dot] martinez [at] rediris.es

La nueva red TEN-155 derivada del proyecto Quantum

El proyecto Quantum (http://www.dante.net/quantum/) coordinado por DANTE y en el que participa RedIRIS junto con todas las redes de investigación europeas, siendo el signatario por parte española la Oficina de Ciencia y Tecnología de Presidencia de Gobierno, está cumpliendo su fase de puesta en funcionamiento de una red operativa denominada, al menos por el momento, TEN-155 (http://www.dante.net/ten-155.html). La red dispondrá de troncales de 155 Mbps, utilizando ATM para la gestión de anchos de banda y el acceso programado para RedIRIS en su fase inicial es de 34 Mbps.

Después de la invitación pública realizada a finales de 1997 para la participación de los operadores, las propuestas recibidas fueron estudiadas por DANTE, por encargo del "Policy Comitee", llegándose finalmente a la decisión, hecha pública el 17 de septiembre de 1998, de que la solución propuesta por Unisource Bélgica fue la ganadora del concurso para la provisión de la nueva red TEN-155.

Se estima que la red entre en funcionamiento en los últimos meses de 1998, lamentablemente por problemas de disponibilidad de infraestructura el acceso español se espera que esté operativo alrededor del 1 de abril de 1999.


dirección de correo victor [dot] castelo [at] rediris.es

Grupo de trabajo sobre routing de RIPE

El tema principal del grupo de trabajo de routing que tuvo lugar en Edimburgo el 23 de septiembre ha sido la creación de nuevos objetos de la base de datos de RIPE. Estos objetos facilitarán la generación de código de configuración de routers, mediante el uso de herramientas desarrolladas por el ISI (Information Science Institute) de la Universidad del Sur de California .

Para más información consultar:

http://www.isi.edu/ra/rps/training/
ó
http://www.isi.edu/~cengiz/talks


dirección de correo maribel [dot] cosin [at] rediris.es

Grupo de trabajo de Netnews de RIPE

La última reunión del Grupo de Trabajo (WG) de NetNews de RIPE tuvo lugar el día 23 de septiembre en Edimburgo (Escocia) dirigida por Felix Kluger (SWITCH).

Se pusieron en común proyectos que se están desarrollando, políticas de uso, filosofía del servicio, recomendaciones,.... que se describen a continuación.

Herramientas de monitorización

En primer lugar Felix Kluger, enumeró cada una de ellas. Como novedad se destacó la labor desarrollada por Jonas Luster (IPF) al adaptar el útil Software para la obtención de estadísticas sobre el tráfico de entrada (Inflow) para poder emplearlo en servidores cuyo Software de News sea DIABLO. Para mayor información consultar: http://www.switch.ch/netnews/wg/newstools.html.

Calidad de Servicio

Asimismo Felix Kluger hizo un análisis estadístico (ver http://merapi.switch.ch/news/status/xpost/arc/index.html) durante un periodo de 10 días para poder así decidir sobre el límite de envío de artículos a múltiples grupos (límite ECP) para utilizar en los filtros de los servidores de NetNews del Newsbone. La conclusión práctica a la que se llega tras la observación de los resultados es que más del 95% del total de artículos recibidos por un servidor al día son enviados de forma cruzada a menos de 5 grupos, por esta razón se puede concluir que hoy en día el envío cruzado de artículos no supone una causa de SPAM. Aún así, en RedIRIS este límite en el envío de mensajes está limitado a 10 grupos.

¿Qué aprender del reciente `newgroup attack' y Groupsync como herramienta de sincronización?

Hace una semanas, tuvo lugar un ataque en USENET. El problema real que produjo fue debido al envío de multitud de mensajes de control falsificados cuyo tratamiento y verificación es costosa en tiempo de ejecución y en recursos. El software de News `INN' y otros servidores son vulnerables ante este tipo de `fork bombs' es decir, el innd lanza numerosos procesos a ejecución reservando recursos, de modo que la contención en CPU crece hasta límites que impiden el correcto funcionamiento de la máquina.

Jonas Luster (IPF) describió el ataque e hizo las siguientes observaciones :

  1. Los servidores de NetNews, que se limitan a transferir todo lo recibido a los nodos que alimentan, como los servidores basados en sw de NetNews `DIABLO', no se ven afectados por este tipo de ataques, ya que no procesan los mensajes de control.
  2. Aquellos servidores con mayor rapidez de Entrada/Salida son más vulnerables, ya que lanzan a ejecución más rápidamente los procesos anteriormente descritos.
  3. Se debe emplear verificación PGP de los mensajes de control (herramientas como pgpverify de `INN'), esto previene el proceso de mensajes de control falsificados.

Se concluye que el tratamiento tradicional de mensajes de control NO es fiable, es necesario pensar en alternativas además de disponer de mejores medios de comunicación para situaciones de emergencia como la que ocurrió en esta ocasión. Como mecanismo alternativo se está trabajando en el proyecto `groupsync', para la creación de una nueva herramienta que permita sincronizar un servidor de news sin los actuales problemas de seguridad. Dicha herramienta trabaja con listas oficiales (en URLs FTP, HTTP, Newsgroups) donde se especifican todos los grupos creados en una jerarquía (alt, comp, rec, es, de, ...). Este es el principal problema del `groupsync' ya que no existen listas oficiales de todas las jerarquías existentes. Sobre esta herramienta se va a trabajar y a probar su eficacia, en concreto desde la `moderación de la jerarquía es' se está ofreciendo apoyo a este proyecto tanto para probar el software como para la publicación de un listado oficial de grupos creados en la misma.

Proyecto `Newsflow maps'

Kai Siering (IS Internet Services GmbH & Co) informó sobre el proyecto de mapas de tráfico de News, comentando los problemas con que encontraba para el correcto desarrollo del mismo. Este proyecto trata de obtener mapas en los que se muestre gráficamente el caudal de tráfico cursado por un servidor de News, así como las dependencias geográficas de modo que se pueda optimizar tanto el consumo de recursos como el uso del ancho de banda. Es estrictamente necesario recalcó Siering, la inclusión de registros tipo LOC de los servidores de News que quieran ser incluidos en dichos mapas, de no ser así es imposible localizarlos y por tanto tener una información gráfica útil.

Usenet II

Jonas Luster describió la emergente USENET-II (U2). En la actualidad está formada por una veintena de servidores que cumplen una serie de requisitos entre ellos disponer de `INN' como software de News, no se admiten servidores con software DNEWS ó CYCLONE, ya que no disponen de un fichero de active (lista de todos los grupos que maneja el servidor). U2 es más una nueva filosofía de uso del servicio de News que un nuevo desarrollo. Se trata de garantizar la calidad del servicio ofrecido cumpliendo una serie de requisitos e imponiendo un comportamiento de `buen uso'. Los clientes de un servidor de U2 deben disponer de clientes que permitan incluir una cabecera `Distribution' de modo que sea posible bloquear aquellos `postings' con un valor en esta cabecera distinto a los reconocidos en U2, se acaba además con los `html-postings', etc.. Dispone de jerarquías distintas a las actualmente distribuidas, es un retorno a la antigua Fidonet, en lo que a filosofía se refiere. Existe información relativa a U2 en el siguiente URL: http://www.usenet.org

Estado del Newsbone

Finalmente, respecto al Newsbone, Felix Kluger ha redactado el nuevo draft de documentación (http://www.switch.ch/netnews/wg/newsbone-doc-v2.html). Actualmente participan en el Newsbone (News Backbone) 45 ISPs, sólo 8 de ellos disponen de servidores cualificados (ACONET, BELNET, SWITCH, DFN, RedIRIS, IOL, GARR y SURFNET), otros 3 ISPs más disponen de servidores cuya cualificación ya ha sido anunciada (ver documento del Newsbone). Cabe destacar la presencia de 3 servidores más de RedIRIS en el Newsbone: UV (Universidad de Valencia), USC (Universidad de Santiago de Compostela) y UNIOVI, (Universidad de Oviedo).


dirección de correo daniel [dot] diaz [at] rediris.es


Indice General [Índice General]