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:
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.
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 | |
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.
maribel [dot] cosin [at] rediris.es
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.Servicio RedIRISdial
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
* 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.
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:
- El correcto diseño del servicio de correo electrónico dentro de una organización.
- 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:
Las coordenadas básicas para este diseño son:
- 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.
- 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.
- 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. - 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:
- 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.
- 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. - 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:) . - Rechazar correo en el que en la sesión SMTP aparezca un valor de MAIL FROM: sin dominio.
- 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.
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/rblEl 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.
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 |
| 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
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:
- 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
http://www.dante.net/np/mtg/98may.html
javier [dot] masa [at] rediris.es
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:
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:
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.
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:
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:
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.
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:
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.
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.
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.
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 :
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.
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.
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
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).
Nuevas versiones de software (INN) en el servidor primario de News de RedIRIS
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.
daniel [dot] diaz [at] rediris.es
Próximas Reuniones de Trabajo relacionadas con seguridad
ruben [dot] martinez [at] rediris.es
Proyecto para nuevo servicio: análisis de seguridad bajo demanda
ruben [dot] martinez [at] rediris.esLa nueva red TEN-155 derivada del proyecto Quantum
victor [dot] castelo [at] rediris.esGrupo de trabajo sobre routing de RIPE
ó
http://www.isi.edu/~cengiz/talks
maribel [dot] cosin [at] rediris.esGrupo de trabajo de Netnews de RIPEHerramientas de monitorización
Calidad de Servicio
¿Qué aprender del reciente `newgroup attack' y Groupsync
como herramienta de sincronización?
Proyecto `Newsflow maps'
Usenet II
Estado del Newsbone
daniel [dot] diaz [at] rediris.es
Indice General
![[Índice General]](../logopuente_boletin.gif){kind=small}