DISEÑO Y PROGRAMACIÓN DE HERRAMIENTA INFORMÁTICA

PARA LA ASIGNACIÓN DEL ANCHO DE BANDA EN TIEMPO REAL

BASADO EN POLÍTICAS QOS.

DANNY ALEXANDER QUINTERO POSSO

UNIVERSIDAD NACIONAL DE COLOMBIA

FACULTAD DE INGENIERIA DE MINAS

ESCUELA DE INGENIERIA DE SISTEMAS

MEDELLÍN

2009

DISEÑO Y PROGRAMACIÓN DE HERRAMIENTA INFORMÁTICA

PARA LA ASIGNACIÓN DEL ANCHO DE BANDA EN TIEMPO REAL

BASADO EN POLÍTICAS QOS.

DANNY ALEXANDER QUINTERO POSSO

TRABAJO DIRIGIDO DE GRADO PRESENTADO COMO REQUISITO

PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS E INFORMÁTICA

DIRECTOR: GERMAN ZAPATA MADRIGAL

UNIVERSIDAD NACIONAL DE COLOMBIA

FACULTAD DE INGENIERIA DE MINAS

ESCUELA DE INGENIERIA DE SISTEMAS

MEDELLÍN

2009

TABLA DE CONTENIDO

1. INTRODUCCIÓN ........................................................................................................... 4

2. OBJETIVOS ................................................................................................................... 5

2.1. OBJETIVO GENERAL .................................................................................................. 5

2.2. OBJETIVOS ESPECÍFICOS ........................................................................................... 5

3. MARCO TEÓRICO ......................................................................................................... 6

3.1. SNMP ........................................................................................................................ 6

3.1.1. SNMPv1 ............................................................................................................ 7

3.1.2. SNMPv2 ............................................................................................................ 7

3.1.3. SNMPv3 ............................................................................................................ 8

3.2. CALIDAD DE SERVICIO (QOS – QUALITY OF SERVICE) ..................................................... 9

3.3. PROTOCOLO SSH .................................................................................................... 10

3.3.1. Características de SSH .................................................................................... 11

3.3.2. ¿Por qué usar SSH? ......................................................................................... 11

3.3.3. Versiones del protocolo SSH .......................................................................... 12

3.3.4. Secuencia de eventos de una conexión SSH .................................................. 12

3.3.5. Capa de transporte ......................................................................................... 12

3.3.6. Autenticación .................................................................................................. 13

3.3.7. Canales ............................................................................................................ 14

4. HERRAMIENTA PROPUESTA ...................................................................................... 15

4.1. MÓDULO DE CONEXIÓN SSH .................................................................................. 15

4.2. MÓDULO DE PROCESAMIENTO DEL ARCHIVO DE COMANDOS ............................. 15

4.3. MÓDULO DE EJECUCIÓN......................................................................................... 16

5. CASO DE ESTUDIO ...................................................................................................... 17

5.1. TOPOLOGÍA PROPUESTA ........................................................................................ 17

5.2. DESCRIPCIÓN ......................................................................................................... 17

6. ANÁLISIS DE RESULTADOS ......................................................................................... 19

7. CONCLUSIONES .......................................................................................................... 21

8. ANEXOS ...................................................................................................................... 22

8.1. SSH.JAVA ................................................................................................................... 22

8.2. SSHBASE.JAVA ............................................................................................................ 24

8.3. CONFIGURACION TRAFGEN...................................................................................... 28

8.4. CONFIGURACION R1 .............................................................................................. 29

9. GLOSARIO .................................................................................................................. 30

10. BIBLIOGRAFIA ............................................................................................................ 33

1. INTRODUCCIÓN

El manejo adecuado de los sistemas de telecomunicaciones, resulta ser de gran

importancia para las organizaciones en la actualidad. Teniendo en cuenta lo anterior, los

sistemas convergentes de dichas organizaciones requieren de un trato especial para

garantizar su adecuado y eficaz funcionamiento en el procesamiento de información sobre

redes de área local (LAN) y redes de área amplia (WAN).

Diferencias inherentes a las características del tráfico como tiempos de retardo, consumo

mínimo de ancho de banda, unidad máxima de transferencia, entre otros además de la

prioridades que la organización establezca para el tratamiento los diferentes tipos de

tráfico, se convierten un componentes determinantes para el manejo procesos

fundamentales como administración de procesos contables, proveedores, clientes, entre

otros que obligan al sistema de transporte de datos a manejar los diferentes tráficos con

niveles de prioridad acorde a las necesidades organizacionales.

Los modelos y técnicas de QoS (Quality of Service) ayudan a definir reglas de asignación de

recursos en los equipos de conectividad (ancho de banda, ciclos de CPU, entre otros), para

ayudar al funcionamiento y la flexibilidad de la red, y que éstas sean capaces de soportar

los nuevos y emergentes servicios y aplicaciones.

El monitoreo y posterior análisis de los diferentes tipos de tráfico de una red se pueden

utilizar como una herramienta de gestión que facilite la optimización de los recursos y el

funcionamiento adecuado de una red, logrando así mejorar los procesos de transporte de

información para la organización.

2. OBJETIVOS

2.1. OBJETIVO GENERAL

Diseñar y desarrollar una herramienta informática que permita la asignación automática

de ancho de banda en tiempo real, monitorear y modificar los dispositivos de red

conectados al sistema.

2.2. OBJETIVOS ESPECÍFICOS

Implementar la programación de scripts que envíen los datos de configuración del ancho de banda a las interfaces del dispositivo de red a través del protocolo SSH. Verificación de cambio de estado para el archivo de configuración, para determinar la actualización de la configuración en los dispositivos de red. Validar el sistema propuesto en topologías que simulen el comportamiento de una red

utilizando simuladores de red y generadores de tráfico.

3. MARCO TEÓRICO Para facilitar la interoperabilidad de la administración en las distintas plataformas de red, se han definido estándares para la administración de redes que sirvan como base fundamental los desarrollos que los diferentes proveedores puedan implementarlos. Los dos estándares principales: El Protocolo simple de administración de red (SNMP) – Comunidad IETF (Internet Engineering Task Force), el cual será una parte fundamental en el desarrollo del presente trabajo. El Protocolo de información de administración común CMIP – Comunidad de las telecomunicaciones. 3.1. SNMP El Protocolo Simple de Administración de Redes –SNMP- (Simple Network Management Protocol), se refiere a un conjunto de estándares para la administración de redes el cual incluye un protocolo, una especificación de la estructura de la base de datos y un conjunto de objetos de datos. [CCNA07]. SNMP está basado en el modelo de cliente-servidor y consta de tres componentes: Agentes: componentes software que se ejecutan en los dispositivos a gestionar Gestores: componentes software que se ejecutan en los sistemas de gestión de red MIB: (Management Information Base) es una base de datos jerárquica de objetos y

sus valores, almacenados en un agente SNMP. [Said08] El servidor de SNMP consiste en un software SNMP gestor, responsable del sondeo de los agentes SNMP para la obtención de información específica y del envío de peticiones a dichos agentes solicitando la modificación de un determinado valor relativo a su configuración. [Millán03] El cliente de SNMP consiste en un software SNMP agente y una base de datos con información de gestión o MIB (Management Information Base). Los agentes SNMP reciben peticiones y reportan información a los gestores SNMP para la comunidad a la que pertenecen; siendo una comunidad, un dominio administrativo de agentes y gestores SNMP. Es decir, son los elementos del sistema de gestión ubicados en cada uno de los dispositivos a gestionar, e invocados por el gestor de la red. El gestor SNMP puede lanzar cualquiera de estos tres comandos sobre un agente SNMP:

Get. Una petición por el valor específico de un objeto en la MIB del agente. Este comando es utilizado por el gestor para monitorizar los dispositivos a gestionar.

Get-next. Una petición por un valor en el siguiente objeto en la MIB del agente. Este comando es utilizado para obtener cada valor sucesivo en un subconjunto o rama de la MIB.

Set. Utilizado para cambiar el valor de un objeto en la MIB de un agente, en el caso de que el objeto tenga habilitada la lectura y escritura de su valor. Este comando es utilizado por el gestor para controlar los dispositivos a gestionar.

Por otro lado, un agente SNMP podría también mandar un mensaje a un gestor SNMP sin el envío previo de una solicitud por parte de éste. Este tipo de mensaje es conocido como Trap. Los Traps son generalmente enviados para reportar eventos, como por ejemplo el fallo repentino de una tarjeta del dispositivo gestionado. El SNMP actualmente cuenta con tres versiones, descritas a continuación. 3.1.1. SNMPv1

Constituye la primera definición e implementación del protocolo SNMP, estando descrito en las RFC 1155, 1157 y 1212 del IETF (Internet Engineering Task Force). Los tipos de mensajes SNMP que emite la NMS son tres. Ellos son GetRequest, GetNextRequest y SetRequest. El agente responde con un acuse de recibo los tres mensajes en forma de un mensaje GetResponse. Un agente puede emitir un mensaje Trap en respuesta a un incidente que afecte a la MIB y a los recursos subyacentes. Dado el creciente uso de SNMP desde su aparición en 1988, rápidamente se puso en evidencia sus debilidades, las cuales eran las dificultades para transferir de forma sencilla grandes bloques de datos y la ausencia de mecanismos de seguridad. [Case90] 3.1.2. SNMPv2

Apareció en 1993, estando definido en las RFC 1441-1452. SNMPv1 y SNMPv2 tienen muchas características en común, siendo la principal mejora la introducción de tres nuevas operaciones de protocolo: GetBulk para que el gestor recupere de una forma eficiente grandes bloques de datos, tales como las columnas de una tabla; Inform para que un agente envíe información espontánea al gestor y reciba una confirmación; y Report para que el agente envíe de forma espontánea excepciones y errores de protocolo. SNMPv2 también incorpora un conjunto mayor de códigos de error y más colecciones de datos. En 1995 apareció una revisión de SNMPv2, denominada SNMPv2c y descrita en las RFC 1901-1910, añadiendo como mejoras una configuración más sencilla y una mayor modularidad; pero manteniendo el sencillo e inseguro mecanismo de autentificación de SNMPv1 y SNMPv2 basado en la correspondencia del denominado nombre de comunidad. [Case93]

3.1.3. SNMPv3 La nueva y última versión de SNMP, SNMPv3, refuerza las prestaciones de seguridad, incluyendo autenticación, privacidad y control de acceso; y de administración de protocolo, con una mayor modularidad y la posibilidad de configuración remota. SNMPv3 apareció en 1997, estando descrito en las RFC 1902-1908 y 2271-2275. Es importante destacar que SNMPv3 no se trata de un estándar que reemplaza a SNMPv1 y/o SNMPv2, sino que define una serie de capacidades adicionales de seguridad y administración a ser utilizadas en conjunción con SNMPv2 (preferiblemente) o SNMPv1. El modelo de seguridad basado en usuario o USM (User-Based Security Model) [Blumenthal02] proporciona los servicios de autenticación y privacidad en SNMPv3. El mecanismo de autentificación en USM asegura que un mensaje recibido fue, de hecho, trasmitido por la entidad indicada en el campo correspondiente a la fuente en la cabecera del mensaje; y además, que el mensaje no fue alterado durante su tránsito y que no fue artificialmente retardado o repetido. El Sistema Administrador de Red (NMS, por su sigla en inglés) es generalmente una sola estación de trabajo independiente, pero puede implementarse entre varios sistemas. Incluye un conjunto de programas los cuales se denominan la Aplicación de administración de redes (NMA). La NMA incluye una interfaz de usuario que permite a los administradores autorizados la administración de la red. Éste responde a los comandos del usuario y emite comandos a los agentes de administración en toda la red. Estos últimos son plataformas y dispositivos claves de la red, otros hosts, enrutadores, switchs y concentradores, equipados con SNMP a fin de que puedan ser administrados. Responden a peticiones de información y a peticiones de acción o parte de la NMS, tales como peticiones de sondeo, y pueden proporcionar a la NMS información importante pero no solicitada tales como las notificaciones de incidentes conocidas como traps. Toda la información de administración de un agente en particular se guarda en la base de datos de información de administración de dicho agente. Un agente puede realizar el seguimiento de:

Cantidad y estado de sus circuitos virtuales.

Cantidad recibida de ciertos tipos de mensajes de error.

Cantidad de bytes y de paquetes que entran y salen del dispositivo.

Longitud máxima de la cola de entrada para los enrutadores y otros dispositivos de internetworking.

Mensajes de broadcast enviados y recibidos.

Interfaces de red que se desactivan y que se activan.

La NMS realiza la función de monitoreo mediante la recuperación de los datos de la MIB. La NMS puede hacer que se inicie una acción en un agente. La comunicación entre el administrador y el agente se realiza mediante un protocolo de administración de la red de la capa de aplicaciones. El SNMP utiliza el Protocolo de datagrama de usuario (UDP) y se comunica mediante los puertos 161 y 162, actuando mediante un intercambio de mensajes. Puede llevarse un registro de la información recuperada para su análisis posterior, puede mostrarse mediante un programa de graficación o puede compararse con valores preconfigurados para comprobar si se ha cumplido con alguna condición en particular. No todas las funciones de administración se basan en la recuperación de datos. También está la capacidad de efectuar cambios en un valor en el dispositivo administrado. Esta característica le permite al administrador configurar un dispositivo administrado mediante SNMP. 3.2. CALIDAD DE SERVICIO (QOS – QUALITY OF SERVICE) “QoS es la habilidad de una red de proveer servicios mejores o “especiales” a usuarios y aplicaciones seleccionadas, pero con un costo para otros usuarios o aplicaciones.” [CCNP09]. QoS es un término genérico que se refiere a los algoritmos que proveen diferentes niveles de calidad a diferentes tipos de tráfico de red. QoS maneja las siguientes características de red:

Ancho de Banda (Bandwidth): Tasa de transferencia de tráfico en la red.

Latencia (Latency): El retardo en los datos transmitidos desde el origen hasta el destino.

Jitter: Variación de la latencia.

Confiabilidad (Reliability): Porcentaje de paquetes descartados durante la transmisión.

Dado el ancho de banda, implementar políticas adecuadas de QoS permitirá reducir la latencia y el jitter, con el fin de mejorar la confiabilidad en la red.

Los modelos QoS para Internet son estándares abiertos definidos por IETF. Existen dos modelos QoS de Internet que actualmente se están estandarizando en IETF: servicios integrados y servicios diferenciados. Estos dos modelos QoS de Internet amplían el modelo de servicio tradicional de máximo esfuerzo descrito en [Baker95].

IntServ (Integrated Services - Servicios integrados) es un modelo de reserva de recurso dinámico para Internet que se describe en [Braden94]. Los sistemas principales utilizan un protocolo de señalización denominado Resource ReSerVation Protocol (RSVP) para solicitar dinámicamente una calidad de servicio específica de la red. Los parámetros de QoS se transportan en estos mensajes RSVP y cada nodo de red junto con la vía de acceso instala los parámetros para obtener la calidad de servicio solicitada. Estos parámetros QoS describen uno de dos servicios definidos actualmente, el servicio garantizado y el servicio de carga controlada. Una característica importante de IS es que esta señalización se realiza para cada flujo de tráfico y las reservas se instalan en cada salto a lo largo de la ruta. Los Servicios diferenciados (DifServ) [Nichols98, Blake98] eliminan los problemas de escalabilidad por flujo y por salto, sustituyéndolos por un mecanismo simplificado de clasificación de paquetes. En lugar de utilizar una propuesta de señalización dinámica, DifServ utiliza los bits del byte de tipo de servicio (TOS, por si sigla en inglés) IP para separar los paquetes en clases. El patrón de bit particular del byte TOS de IP se denomina punto de código DS (DSCP) y lo utilizan los enrutadores para definir la calidad de servicio proporcionado en ese determinado salto, de la misma forma que los enrutadores realizan el reenvío de IP utilizando búsquedas de tabla de direccionamiento. El trato dado a un paquete con un DSCP determinado se denomina comportamiento por salto (PHB) y se administra independientemente en cada nodo de red. Cuando se concatenan los efectos de estos PHB individuales independientes, se produce un servicio de extremo a extremo. Los Servicios diferenciados están siendo estandarizados por un grupo de trabajo de IETF, que ha definido tres PHB: el PHB de EF (Expedited Forwarding - Reenvío urgente), el grupo de PHB de AF (Assured Forwarding - Reenvío asegurado) y el PHB de DE (Default - Valor predeterminado). El PHB de EF se puede utilizar para implementar una frecuencia baja, una fluctuación baja, una pérdida baja, un servicio de extremo a extremo, por ejemplo una línea alquilada virtual (VLL). AF es una familia de PHB, denominada grupo de PHB, que se utiliza para clasificar paquetes en diversos niveles de prioridad para soltarlos. La prioridad asignada a un paquete para soltarlo determina la importancia relativa del paquete en la clase AF. 3.3. PROTOCOLO SSH SSH (Secure SHell) es un protocolo que facilita las comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor y que permite a los usuarios conectarse

a un host remotamente. A diferencia de otros protocolos de comunicación remota tales como FTP o Telnet, SSH encripta la sesión de conexión, haciendo imposible que alguien pueda obtener contraseñas no encriptadas. [Ylonen06] SSH está diseñado para reemplazar los métodos más viejos y menos seguros para registrarse remotamente en otro sistema a través de la shell de comando, tales como TELNET o RSH. Un programa relacionado, el SCP, reemplaza otros programas diseñados para copiar archivos entre hosts como RCP. Ya que estas aplicaciones antiguas no encriptan contraseñas entre el cliente y el servidor, evite usarlas mientras le sea posible. El uso de métodos seguros para registrarse remotamente a otros sistemas reduce los riesgos de seguridad tanto para el sistema cliente como para el sistema remoto. 3.3.1. Características de SSH El protocolo SSH proporciona los siguientes tipos de protección:

Después de la conexión inicial, el cliente puede verificar que se está conectando al mismo servidor al que se conectó anteriormente.

El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits.

Todos los datos enviados y recibidos durante la sesión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremamente difícil de descifrar y leer.

Ya que el protocolo SSH encripta todo lo que envía y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede convertirse en un conducto para convertir en seguros los protocolos inseguros mediante el uso de una técnica llamada reenvío por puerto, como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos. 3.3.2. ¿Por qué usar SSH? Los usuarios tipo ‘hackers’ tienen a su disposición una variedad de herramientas que les permiten interceptar y redirigir el tráfico de la red para ganar acceso al sistema. En términos generales, estas amenazas se pueden catalogar del siguiente modo: Intercepción de la comunicación entre dos sistemas — En este escenario, existe un

tercero en algún lugar de la red entre entidades en comunicación que hace una copia de la información que pasa entre ellas. La parte interceptora puede interceptar y conservar la información, o puede modificar la información y luego enviarla al recipiente al cual estaba destinada. Este ataque se puede montar a través del uso de un paquete sniffer — una utilidad de red muy común.

Personificación de un determinado host — Con esta estrategia, un sistema interceptor finge ser el recipiente a quien está destinado un mensaje. Si funciona la estrategia, el sistema del usuario no se da cuenta del engaño y continúa la comunicación con el host incorrecto.

Ambas técnicas interceptan información potencialmente confidencial y si esta intercepción se realiza con propósitos hostiles, el resultado puede ser catastrófico. Si se utiliza SSH para inicios de sesión de consola remota y para copiar archivos, se pueden disminuir estas amenazas a la seguridad notablemente. Esto es porque el cliente SSH y el servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la comunicación entre los sistemas cliente y servidor es encriptada. No servirán de nada los intentos de falsificar la identidad de cualquiera de los dos lados de la comunicación ya que cada paquete está cifrado por medio de una llave conocida sólo por el sistema local y el remoto. 3.3.3. Versiones del protocolo SSH El protocolo SSH permite a cualquier programa cliente y servidor construido a las especificaciones del protocolo, comunicarse de forma segura y ser usado de intercambiable. Existen dos variedades de SSH actualmente (versión 1 y versión 2). La versión 1 de SSH hace uso de muchos algoritmos de encriptación patentados (sin embargo, algunas de estas patentes han expirado) y es vulnerable a un hueco de seguridad que potencialmente permite a un intruso insertar datos en la corriente de comunicación. 3.3.4. Secuencia de eventos de una conexión SSH La siguiente serie de eventos lo ayudan a proteger la integridad de la comunicación SSH entre dos host:

Se lleva a cabo un 'handshake' (apretón de manos) encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto.

La capa de transporte de la conexión entre el cliente y la máquina remota es encriptada mediante un código simétrico.

El cliente se autentica ante el servidor.

El cliente remoto interactúa con la máquina remota sobre la conexión encriptada. 3.3.5. Capa de transporte El papel principal de la capa de transporte es facilitar una comunicación segura entre los dos hosts durante la autenticación y la subsecuente comunicación. La capa de transporte lleva esto a cabo manejando la codificación y decodificación de datos y proporcionando protección de integridad de los paquetes de datos mientras son enviados y recibidos.

Además, la capa de transporte proporciona compresión de datos, lo que acelera la transmisión de información. Al contactar un cliente a un servidor por medio del protocolo SSH, se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Durante el intercambio se producen los siguientes pasos:

Intercambio de claves

Se determina el algoritmo de encriptación de la clave pública

Se determina el algoritmo de la encriptación simétrica

Se determina el algoritmo autenticación de mensajes

Se determina el algoritmo de hash que hay que usar El servidor se identifica ante el cliente con una llave de host única durante el intercambio de llaves. Obviamente si este cliente nunca se había comunicado antes con este determinado servidor, la llave del servidor le resultará desconocida al cliente y no lo conectará. La mayoría de las implementaciones de SSH evita este problema permitiendo que el cliente acepte la llave del host del servidor después que el usuario es notificado y verifica la aceptación de la nueva llave del host. Para las conexiones posteriores, la llave del host del servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza de que el cliente se está realmente comunicando con el servidor deseado. Si en el futuro, la llave del host ya no coincide, el usuario debe eliminar la versión guardada antes de que una conexión pueda ocurrir. SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de clave pública o formato de codificación. Después del intercambio de claves inicial se crea un valor hash usado para el intercambio y un valor compartido secreto, los dos sistemas empiezan inmediatamente a calcular claves y algoritmos nuevos para proteger la autenticación y los datos que se enviarán a través de la conexión en el futuro. Después que una cierta cantidad de datos haya sido transmitida con un determinado algoritmo y clave (la cantidad exacta depende de la implementación de SSH), ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y un nuevo valor secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un período de tiempo limitado. 3.3.6. Autenticación Cuando la capa de transporte haya construido un túnel seguro para transmitir información entre los dos sistemas, el servidor le dirá al cliente de los diferentes métodos de autenticación soportados, tales como el uso de firmas privadas codificadas con claves o la

inserción de una contraseña. El cliente entonces intentará autenticarse ante el servidor mediante el uso de cualquiera de los métodos soportados. Los servidores y clientes SSH se pueden configurar para que permitan varios tipos de autenticación, lo cual le concede a cada lado la cantidad óptima de control. Luego el servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad, y el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición. Gracias a la naturaleza segura de la capa de transporte de SSH, hasta métodos de autenticación que parecen inseguros, como la autenticación basada en contraseñas, son en realidad seguros para usar. 3.3.7. Canales Luego de una autenticación exitosa sobre la capa de transporte SSH, se abren múltiples canales a través de la técnica llamada multiplexación. Cada uno de estos canales maneja la conexión para diferentes sesiones de terminal y para sesiones de reenvío X11. Ambos clientes y servidores pueden crear un canal nuevo. Luego se le asigna un número diferente a cada canal en cada punta de la conexión. Cuando el cliente intenta abrir un nuevo canal, los clientes envían el número del canal junto con la petición. Esta información es almacenada por el servidor y usada para dirigir la comunicación a ese canal. Esto es hecho para que diferentes tipos de sesión no afecten una a la otra y así cuando una sesión termine, su canal pueda ser cerrado sin interrumpir la conexión SSH primaria. Los canales también soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envían a través del canal sino hasta que el host haya recibido un mensaje avisando que el canal está abierto y puede recibirlos. El cliente y el servidor negocian las características de cada canal automáticamente, dependiendo del tipo de servicio que el cliente solicita y la forma en que el usuario está conectado a la red. Esto otorga una gran flexibilidad en el manejo de diferentes tipos de conexiones remotas sin tener que cambiar la infraestructura básica del protocolo.

4. HERRAMIENTA PROPUESTA El desarrollo realizado para la logar la consecución del objetivo propuesto, se centra en la implementación de una aplicación basada en el lenguaje de programación JAVA. La elección del lenguaje JAVA se realizó bajo la premisa de realizar desarrollos adicionales que en complemento con la aplicación actual se constituyan en un aplicativo de mayor alcance para lograr una mayor optimización del transporte de tráfico a través de las redes de área local y redes de área ancha. La aplicación consta de tres componentes principales:

Módulo de conexión SSH

Módulo de procesamiento del archivo de comandos

Módulo de ejecución 4.1. MÓDULO DE CONEXIÓN SSH Para la implementación del módulo de conexión SSH, se tomó como base la librería SshFactory.jar, desarrollada por la empresa JSCAPE para el producto Secure FTP Factory. Esencialmente la librería mencionada dispone de los elementos básicos de una conexión SSH en los niveles de seguridad requeridos para el establecimiento de la conexión entre el computador de administración y el dispositivo de red a configurar. La librería contiene los métodos necesarios para llevar a cabo el proceso de negociación, encriptación, autenticación, establecimiento y cierre de la sesión SSH. 4.2. MÓDULO DE PROCESAMIENTO DEL ARCHIVO DE COMANDOS Es el encargado de realizar el proceso de lectura del archivo de comandos, para almacenar cada una de las líneas de comandos en una variable tipo arreglo en java para posteriormente enviarla al módulo de ejecución. El archivo de comandos se construye a partir de los resultados arrojados por el análisis de los diferentes tipos de tráfico de la red existentes en la red. Dichos resultados sirven para definir los parámetros adecuados y su aplicación en las políticas de calidad de servicio QoS, con el propósito de mejorar el rendimiento de la red analizada.

4.3. MÓDULO DE EJECUCIÓN Es el encargado de establecer la comunicación con el dispositivo de la red a configurar. Los procedimientos que se ejecutan provienen del módulo de conexión SSH y del modulo de procesamiento del archivo de comandos. En éste proceso se obtiene la información de acceso al dispositivo de red, como son el usuario, la contraseña y la dirección de red asociada al mismo. Posteriormente se recuperan los comandos provenientes del archivo de configuración y se envían al dispositivo de red para ser ejecutados y cerrar la conexión SSH. Finalmente se realiza una revisión del archivo de comandos para detectar si se han realizado cambios en las configuraciones allí existentes. Al detectarse cambios, el proceso de ejecución se inicia de nuevo; en caso contrario la aplicación realiza una verificación periódica del archivo para la detección de cambios en el mismo e iniciar el proceso mencionado anteriormente.

5. CASO DE ESTUDIO

5.1. TOPOLOGÍA PROPUESTA

Figura 1. Topología de red de caso de estudio

5.2. DESCRIPCIÓN La topología de red propuesta para el caso de estudio consta de dos enrutadores y computador de administración. El enrutador denominado TrafGen (CISCO 2800), el cual será el encargado de generar tráfico de red de diferentes tipos, para enviarlo a través de un enlace FastEthernet hacia el enrutador R1. El enrutador TrafGen recibe a través del enlace serial los datos enviados por R1. El enrutador R1 (CISCO 2800), es el que recibe el tráfico proveniente de TrafGen y los enruta a través del enlace serial, en éste enlace se aplica la política QoS, encargada de optimizar la carga de tráfico enviada a través de dicho enlace.

El PC-Admin es el computador a través del cual se monitorea el archivo de configuración y realiza su envío mediante una conexión segura SSH al enrutador R1, con el fin de modificar las políticas QoS para ajustarlas a los diversos requerimientos de la red. Por cuestiones prácticas el enlace serial entre R1 y TrafGen se configuró a una velocidad de 128000 bps, con el fin de percibir de mejor manera la saturación del enlace por flujo de tráfico sobre el mismo. Para la realización de la simulación se configuró en el enrutador TrafGen, el generador de tráfico PAGENT propiedad de CISCO. Éste genera tráfico real y “cuellos de botella” para probar las características QoS como Clasificación IP, marcado IP, y encolamiento. La configuración de PAGENT en TrafGen (ver anexo 8.3) se realizó para generar tráfico HTTP y FTP cuyas tramas tienen un tamaño aleatorio en 1200 y 1500 bytes. Este tamaño en la trama se configuró intencionalmente para lograr una saturación más rápida del enlace serial. El enrutador R1 posee la configuración apropiada para permitir conexiones SSH desde el PC-Admin, para recibir el archivo de configuración. Para las configuraciones generales de los enrutadores referirse a los anexos 6.3 y 6.4.

6. ANÁLISIS DE RESULTADOS Para la topología propuesta, inicialmente se realiza una configuración de QoS en el enrutador R1, asignando el 5% del ancho de banda del enlace serial para los flujos de tráfico de HTTP y FTP. El tráfico generado desde TrafGen, comienza a enviar los paquetes HTTP y FTP hacia el enrutador R1, dichos paquetes se reenvían a través del enlace serial y rápidamente se detecta una saturación en el enlace y por ende pérdida de paquetes, como se observa en la tabla a continuación, obtenida a partir del informe de la política QoS sobre el enlace serial.

Clase Protocolo Ancho de banda

asignado Paquetes Porcentaje de

pérdida Total Perdidos

Web http 5% 496878 119554 29%

ftp ftp 5% 397542 61028 15%

Tabla 1. Resultados de la política 1

Dado que los porcentajes de pérdida con el ancho de banda de 5% para los tipos de tráfico es muy elevado, se debe realizar un ajuste en los parámetros de la política QoS para reducir el porcentaje de pérdida de paquetes y mejorar el flujo de paquetes a través del enlace. En el archivo de configuración se cambian los porcentajes correspondientes al ancho de banda para cada tipo de tráfico por 15%. Una vez que la aplicación detecta los cambios en el archivo de configuración procede a ejecutar el procedimiento de envío de la nueva configuración al enrutador R1. Transcurrido un tiempo de ejecución se observan los siguientes resultados:

Clase Protocolo Ancho de banda

asignado Paquetes Porcentaje de

pérdida Total Perdidos

Web http 15% 426590 72297 17%

ftp ftp 15% 402686 53893 13%

Tabla 2. Resultados de la política 2

A partir de estos resultados se observa una disminución en los porcentajes de pérdida, debido a la ampliación en el ancho de banda asignado para los tipos de tráfico en

cuestión. A medida que transcurre el tiempo el porcentaje de pérdida va disminuyendo lentamente. Para lograr una disminución mayor en los porcentajes de pérdida de los paquetes, se modifica el archivo de comandos por porcentajes para el ancho de banda que sean superiores a los anteriores. Nuevamente ante la detección de cambios en el archivo de configuración procede a ejecutar el procedimiento de envío de la nueva configuración al enrutador R1. Transcurrido un tiempo de ejecución se observan los siguientes resultados:

Clase Protocolo Ancho de banda

asignado Paquetes Porcentaje de

pérdida Total Perdidos

Web http 35% 412264 42374 10%

ftp ftp 40% 414552 30659 7%

Tabla 3. Resultados de la política 3

Ante las configuraciones de 35% para el tráfico HTTP y 40% para el tráfico FTP, se observa una notoria reducción en los porcentajes de pérdida de paquetes; dicho porcentaje continúa disminuyendo progresivamente y a mayor velocidad hasta llegar a valores mínimos y que no afectan el adecuado funcionamiento de la red. Lo cual despeja el “cuello de botella” que existía en el enlace serial desde R1 hasta TrafGen. Es importante destacar que la configuración enviada desde el PC-Admin, tiene un impacto imperceptible para la red y el tiempo de ejecución de los comandos en el dispositivo tardan en promedio 3 segundos, lo cual es despreciable dado que los cambios en el tráfico de la red y la saturación de los enlaces no se dan de manera espontánea.

7. CONCLUSIONES Inicialmente se intentó realizar el envió de los comandos mediante el protocolo de comunicación SNMP, pero la implementación con éste protocolo se salió del alcance del presente desarrollo, dado que dicho protocolo es utilizado principalmente para labores de monitoreo de los dispositivos de la red y alterar sólo algunos de los atributos disponibles en tales dispositivos. Por éste motivo se optó por el protocolo de comunicación SSH. La utilización de un protocolo de comunicación como SSH para realizar la administración de los dispositivos de red, representa una opción con considerables beneficios dado que la información que enviada sobre la red viaja de manera segura y poco propensa a ataques malintencionados. La comunicación que se establece mediante el aplicativo desarrollado en JAVA para el envío de las configuraciones, ofrece una alta confiabilidad dado que el envío se realiza en unos pocos segundos y hay una revisión permanente del archivo de configuración con el fin de detectar cambios en el mismo para enviar los comandos al dispositivo de red especificado. Los resultados obtenidos en el caso de estudio muestran el comportamiento esperado para alcanzar los objetivos del presente trabajo, logrando disminuir considerablemente los porcentajes de pérdida de paquetes y por ende optimizando el funcionamiento de la topología de red propuesta.

8. ANEXOS

8.1. Ssh.java // Librerias para el procesamiento de archivos import java.io.BufferedReader; import java.io.File; import java.io.FileReader; import java.io.IOException; import java.io.InputStreamReader; import java.util.StringTokenizer; public class ssh { private String[] comands; public static long modif = 0; public ssh() throws IOException { String strDatos= leerArchivo(); StringTokenizer tokens=new StringTokenizer(strDatos, "\n"); // separa los comandos por lineas int cantidad = tokens.countTokens(); comands = new String[cantidad]; int i = 0; while(tokens.hasMoreTokens()){ String str=tokens.nextToken(); comands[i] = str; i++; } } public String[] getComand() { //funcion de retorno de los comandos return this.comands; } public String leerArchivo()throws IOException { String data = ""; int lineas = 1; String datos = "" ; try { //ruta del archivo con los comandos a ejecutar BufferedReader sarchivo = new BufferedReader( new FileReader(SshBase.rutaArchivo)); while (( data = sarchivo.readLine()) != null)

{ datos += "\n" + data; lineas++; } } catch (IOException exc) { } finally { } return datos; } public static void main(String[] arg) throws IOException { new ssh(); } }

8.2. SshBase.java

import com.jscape.inet.ssh.*; import java.io.*; import java.util.Date; import java.util.logging.Level; import java.util.logging.Logger; import javax.swing.JFileChooser; import javax.swing.JFrame; import javax.swing.JOptionPane; public class SshBase implements SshListener { // estado de la conexión SSH private boolean connected = false; public static String rutaArchivo = ""; // Crea una nueva instancia SshBase. */ public SshBase() { String hostname = null; String username = null; String password = null; Ssh ssh = null; String line = null; try { ssh sh = new ssh(); // toma las lineas del archivo y las almacena en un arreglo para ser tratadas individualmente String[] comands = sh.getComand(); username=comands[0]; hostname=comands[1]; password=comands[2]; // crea una nueva instancia Ssh ssh = new Ssh(hostname, username, password); // registra la captura de eventos ssh.addSshListener(this); System.out.println("Conectando, por favor espere..."); // conexión ssh.connect(); // toma el stream de salida para escribir en los datos en el servidor SSH OutputStream out = ssh.getOutputStream();

// Almacena en un vector para ser ejecutados for(int i=3; i<comands.length; i++) { line += comands[i]+"\n"; } //elimina la cadema NULL del string, proveniente de la inicialización //de la variable. line = line.substring(4, line.length()); System.out.println(line); // lea mientras existan datos while (connected && line != null) { try { out.write(line.getBytes()); out.flush(); } catch(Exception ioe){ connected = false; } } } catch (Exception e) { e.printStackTrace(); } finally { try { if(connected) { ssh.disconnect(); } } catch(Exception e) { } } } // Captura los eventos SshConnectedEvent public void connected(SshConnectedEvent ev) { System.out.println("Connected: " + ev.getHost()); connected = true; } // Captura los eventos SshDataReceivedEvent public void dataReceived(SshDataReceivedEvent ev) { // envía los datos recibidos de la consola System.out.print(ev.getData()); }

// Captura los eventos SshDisconnectedEvent public void disconnected(SshDisconnectedEvent ev) { System.out.println("Disconnected: " + ev.getHost() + ". Press Enter to exit"); connected = false; } // Método Main para SshBase @SuppressWarnings("static-access") public static void main(String[] args) { int tiempo=0; JFrame frame = new JFrame(); JFileChooser fc = new JFileChooser(); JOptionPane.showMessageDialog(frame, "A continuacion seleccione la " + "ruta del archivo de comandos "); if(fc.showOpenDialog( frame ) == JFileChooser.APPROVE_OPTION ){ rutaArchivo = fc.getSelectedFile().getPath(); } tiempo=(Integer.parseInt(JOptionPane.showInputDialog("Digite intervalo de" + " tiempo para enviar configuracion al dispositivo (minutos)","60"))); for(;;){ try { File f2 = new File(rutaArchivo); ssh ssh1 = new ssh(); if (ssh1.modif != f2.lastModified()) { SshBase test = new SshBase(); ssh1.modif = f2.lastModified(); System.out.println(" ------------------------------------- "); java.util.Date hoy = new Date(); System.out.println("La configuracion fue moficada: "); System.out.println(hoy); System.out.println(" ------------------------------------- "); } else { System.out.println(" ------------------------------------- "); System.out.println(" El archivo no ha cambiado"); System.out.println(" ------------------------------------- "); } } catch (IOException ex) { Logger.getLogger(SshBase.class.getName()).log(Level.SEVERE, null, ex);

} try { Thread.sleep(tiempo*60*1000); } catch(InterruptedException e) { } } } }

8.3. CONFIGURACION TrafGen interface FastEthernet0/0 ip address 172.16.10.4 255.255.255.0 no shutdown ! interface Serial0/0/0 ip address 172.16.20.4 255.255.255.0 no shutdown ! tgn ! ! PAGENT EN TrafGen sobre fast Ethernet ! fastethernet0/0 add tcp rate 1000 l2-dest 0023.3324.3588 l3-src 172.16.10.4 l3-dest 172.16.20.4 l4-dest 23 length random 1200 to 1500 burst on burst duration off 1000 to 2000 burst duration on 1000 to 3000 add fastethernet0/0 1 l4-dest 80 data ascii 0 GET /index.html HTTP/1.1 add fastethernet0/0 1 l4-dest 21 ! end

8.4. CONFIGURACION R1 ! Configuración SSH ! aaa new-model username cisco password 0 cisco ip domain-name cisco.com cry key generate rsa ! ! key 1024 ! ip ssh time-out 60 ip ssh authentication-retries 3 line vty 0 15 transport input SSH no login authentication privilege level 15 ! hostname R1 ! no ip domain lookup ip domain name cisco.com ! username cisco password 0 cisco ! ip ssh time-out 60 ! interface FastEthernet0/0 ip address 172.16.10.1 255.255.255.0 no shutdown ! interface FastEthernet0/1 ip address 172.16.30.1 255.255.255.0 no shutdown ! interface Serial0/3/0 ip address 172.16.20.1 255.255.255.0 clock rate 128000 no shutdown !

9. GLOSARIO ALGORITMO DE HASH Hash se refiere a una función o método para generar claves o llaves que representen de manera casi unívoca a un documento, registro, archivo, etc., resumir o identificar un dato a través de la probabilidad, utilizando una función hash o algoritmo hash. Un hash es el resultado de dicha función o algoritmo. ENCRIPTACION Es el arte o ciencia de cifrar y descifrar información mediante técnicas especiales y se emplea frecuentemente para permitir un intercambio de mensajes que sólo puedan ser leídos por personas a las que van dirigidos y que poseen los medios para descifrarlos. FTP - File Transfer Protocol Protocolo de Transferencia de Archivos, es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP, basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. HACKERS Hacker es el término utilizado para referirse a un experto en varias o alguna rama técnica relacionada con la informática: programación, redes de computadoras, sistemas operativos, hardware de red/voz, etc. HTTP - HyperText Transfer Protocol El protocolo de transferencia de hipertexto es el protocolo usado en cada transacción de la Web (WWW). IETF -Internet Engineering Task Force El Grupo de Trabajo en Ingeniería de Internet es una organización internacional abierta de normalización, que tiene como objetivos el contribuir a la ingeniería de Internet, actuando en diversas áreas, tales como transporte, encaminamiento, seguridad.

JAVA Es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a principios de los años 90. MIB - Management Information Base La Base de Información Gestionada (Management Information Base o MIB) es un tipo de base de datos que contiene información jerárquica, estructurada en forma de árbol, de todos los dispositivos gestionados en una red de comunicaciones. Es parte de la gestión de red definida en el modelo OSI. Define las variables usadas por el protocolo SNMP para supervisar y controlar los componentes de una red. Está compuesta por una serie de objetos que representan los dispositivos (como enrutadores y conmutadores) en la red. Cada objeto manejado en un MIB tiene un identificador de objeto único e incluye el tipo de objeto (tal como contador, secuencia o gauge), el nivel de acceso (tal como lectura y escritura), restricciones de tamaño, y la información del rango del objeto. MULTIPLEXACIÓN Una conexión multiplexada consiste de muchas señales siendo enviadas sobre un medio común, compartido. Con SSH, canales diferentes son enviados sobre una conexión común segura. RCP Permite copiar archivos o directorios de su servidor web a un sistema remoto o entre dos sistemas remotos. RCP utiliza RSH se comunica con el demonio en el sistema remoto y, como tal, debe realizar una conexión mediante un número de puerto en el rango de puertos reservados. RFC Las Request For Comments —petición de comentarios— son una serie de notas sobre Internet que comenzaron a publicarse en 1969. Se abrevian como RFC. Cada una de ellas individualmente es un documento cuyo contenido es una propuesta oficial para un nuevo protocolo de la red Internet (originalmente de ARPANET), que se explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambigüedades.

RSH Es un programa de consola para ejecutar comandos en ordenadores remotos. La información que envía sobre la red es insegura, dado que se transmite sin cifrar. SCP Secure Copy o SCP es un medio de transferencia segura de archivos informáticos entre un host local y otro remoto o entre dos hosts remotos, usando el protocolo Secure Shell (SSH). SNIFFER Aplicación de monitorización y de análisis para el tráfico de una red para detectar problemas, lo hace buscando cadenas numéricas o de caracteres en los paquetes. Se usa especialmente para detectar problemas de congestionamiento (cuellos de botella o bottlenecks) Puede usarse ilegalmente para recibir datos privados en una red, además son difíciles de detectar. TCP/IP Conjunto de protocolos TCP/IP, en referencia a los dos protocolos de red más importantes en los que se basa Internet y que permiten la transmisión de datos entre redes de computadoras. Protocolo de Control de Transmisión (TCP) y Protocolo de Internet (IP), que fueron los dos primeros en definirse, y que son los más utilizados de la familia. TELNET TELecommunication NETwork es el nombre de un protocolo de red (y del programa informático que implementa el cliente), que sirve para acceder mediante una red a otra máquina, para manejarla remotamente como si estuviéramos sentados delante de ella.

10. BIBLIOGRAFIA [Baker95] Baker, F. RFC 1812. Requirements for IP Version 4 Routers. IETF. June 1995. [Online: http://tools.ietf.org/html/rfc1812] [Blake98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. & Weiss, W. RFC 2475 - An Architecture for Differentiated Services. IETF. December 1998. [Online: http://www.ietf.org/rfc/rfc2475.txt] [Blumenthal02] Blumenthal, U., Wijnen, B. RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). Diciembre 2002. [Online: http://tools.ietf.org/html/rfc3414 ] [Braden94] Braden, R., Clark, D., Shenker, S. RFC 1633 - Integrated Services in the Internet Architecture: an Overview. IETF. June 1994 [Online: http://www.ietf.org/rfc/rfc1633.txt] [Case02] Case, J., Partain, D., Mundy, R. & B. Stewart. RFC 3410 - Introduction and Applicability Statements for Internet Standard Management Framework. SNMP Research, Inc. Network Associates Laboratories. Deciembre 2002. [Online: http://tools.ietf.org/html/rfc3410 ] [Case90] Case, J., Fedor. M., Schoffstall, M., Davin, J. RFC 1157 - A Simple Network Management Protocol (SNMP). SNMP Research, Inc. Mayo 1990. [Online: http://tools.ietf.org/html/rfc1157 ] [Case93] Case, J., McCloghrie, K., Rose, M., Waldbusser, S. RFC 1141 - Introduction to version 2 of the Internet-standard Network Management Framework. SNMP Research, Inc. Abril 1993. [Online: http://tools.ietf.org/html/rfc1441 ] [CCNA07] Cisco CCNA Exploration curriculum. Versión 3.1. Cisco 2007. [CCNP09] Cisco CCNP curriculum. Version 5. Cisco 2009. [Millán03] Millán T., R. SNMPv3 (Simple Network Management Protocol version 3). BIT 139 JUN.-JUL. 45. ISSN 0210-3923. 2003. [Nichols98] Nichols, K., Blake, S., Baker, F. & Black, D. RFC 2474 - Definition of the Differentiated Services Field (DifServ Field) in the IPv4 and IPv6 Headers. IETF. December 1998. [Online: http://www.ietf.org/rfc/rfc2474.txt]

[Said08] Said, O. A Novel Technique for SNMP Bandwidth Reduction: Simulation and Evaluation. IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008. [Shin07] Kwang Sik Shin, Jin Ha Jung, Jin Young Cheon, Sang Bang Choi. Real-time network monitoring scheme based on SNMP for dynamic information. Department of Electronic Engineering, Inha University, Yonghyun-dong, Nam-gu, Journal of Network and Computer Applications 30 (2007) 331–353, Republic of Korea. 2007. [SSH09] SSH Communications Security. 2009. [Online: http://www.ssh.com] [Ylonen06] Ylonen, T., Lonvick, C.The Secure Shell (SSH) Protocol Architecture. RFC 4251. Ed. Cisco Systems, Inc. Enero 2006. Disponible en: http://www.ietf.org/rfc/rfc4251.txt