Framework para configurar listas de acceso extendidas en Routers Cisco desde un dispositivo móvil

Texto completo

(1)FRAMEWORK PARA CONFIGURAR LISTAS DE ACCESO EXTENDIDAS EN ROUTERS CISCO DESDE UN DISPOSITIVO MÓVIL. DIANA KATHERINE PRIETO RESTREPO NELLY ROCIO LINARES CÁRDENAS. UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA BOGOTÁ D.C. 2015.

(2) FRAMEWORK PARA CONFIGURAR LISTAS DE ACCESO EXTENDIDAS EN ROUTERS CISCO DESDE UN DISPOSITIVO MÓVIL. DIANA KATHERINE PRIETO RESTREPO CÓDIGO: 20132678009 NELLY ROCIO LINARES CÁRDENAS CÓDIGO 20132678010. TRABAJO DE GRADO PARA OPTAR POR EL TÍTULO DE INGENERÍA EN TELEMÁTICA. TUTOR: INGENIERO NORBERTO NOVOA TORRES. UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA BOGOTÁ D.C. 2015.

(3) Nota de aceptación. El proyecto de grado “Framework Para Configurar Listas De Acceso Extendidas En Routers Cisco Desde Un Dispositivo Móvil.” presentado para optar al título de Ingeniería en Telemática otorgado por la Universidad Distrital Francisco José de Caldas, cumple con los requisitos establecidos y recibe nota aprobatoria.. _______________________________ Firma de Jurado. _______________________________ Ing. NORBERTO NOVOA TORRES Director del proyecto. Bogotá D.C, Septiembre de 2015.

(4) DEDICATORIA A Dios por permitirme estar en este lugar y darme la fuerza necesaria para continuar. A mis padres y hermanos quienes han compartido conmigo momentos buenos y malos, por ser un apoyo incondicional no solo en mí proceso de formación académica, sino también en mi vida personal y por el amor que me brindan a diario. Finalmente, a todos aquellos que de alguna manera u otra han contribuido directa o indirectamente en el desarrollo de mi personalidad, vida académica y profesional, a ellos también Diana A Dios por brindarme la oportunidad de lograr mis metas y de seguir formando mi camino. A mis padres por su esfuerzo y apoyo incondicional que aportaron en mi formación personal, como también el ámbito de mi formación académica y profesional, con sus valores y enseñanzas constantes, contribuyeron para que me convirtiera en una persona emprendedora, con metas y capacidades para enfrentar cada una de las situaciones que se me presentan continuamente. Y a mis hermanas y demás personas que aportaron de forma directa o indirectamente para que esto fuera realidad. Rocío. 1.

(5) AGRADECIMIENTOS. Al Ingeniero Norberto Novoa Torres por brindarnos la confianza de poner en práctica nuestros conocimientos en el proyecto a continuación referenciado y por su buena disposición y trato.. 2.

(6) TABLA DE CONTENIDO RESUMEN ........................................................................................................................... 7 ABSTRACT.......................................................................................................................... 8 INTRODUCCIÓN ............................................................................................................... 9 1.. ORGANIZACIÓN, DEFINICIÓN Y ANÁLISIS ................................................... 11. 1.1. 1.2. 1.3. 1.3.1. 1.3.2. 1.4. 1.5. 1.6. 1.7. 1.7.1. 1.7.1.1. 1.7.2. 1.7.3. 1.7.4. 1.8. 1.8.1. 1.8.1.1. 1.8.2. 1.8.3. 1.8.4. 1.8.5. 1.9. 1.9.1. 1.9.2. 1.9.3. 1.10. 1.10.1. 1.10.2. 1.10.3. 1.10.4. 1.11. 1.11.1. 1.11.2.. TEMA ......................................................................................................................11 TITULO ....................................................................................................................11 OBJETIVOS ..............................................................................................................11 Objetivo general ..............................................................................................11 Objetivos específicos ......................................................................................11 DESCRIPCIÓN DEL PROBLEMA................................................................................. 12 PREGUNTA DE INVESTIGACIÓN ............................................................................... 13 JUSTIFICACIÓN ....................................................................................................... 13 MARCO TEÓRICO .................................................................................................... 16 Programación orientada a objetos .................................................................. 16 Diseño orientado a objetos ......................................................................... 17 Listas de control de acceso (ACL) ................................................................. 19 Métodos de conexión Remota RPCs y RMI .................................................. 20 TELNET (Tele Network - Tele Red) ............................................................. 21 MARCO CONCEPTUAL ............................................................................................. 21 Java ................................................................................................................ 21 Java Standard Edition ................................................................................. 22 Cisco .............................................................................................................. 23 Framework ..................................................................................................... 24 Middleware .................................................................................................... 24 Firewall .......................................................................................................... 25 MARCO LEGAL ....................................................................................................... 26 Ley 29 de 1990 .............................................................................................. 26 Ley 1273 de 2009, Ley de delitos informáticos en Colombia ....................... 27 Ley 603 de 2000 ............................................................................................ 27 METODOLOGÍA ....................................................................................................... 28 Características metodología RUP................................................................... 28 Ciclo de Vida.................................................................................................. 29 Fases............................................................................................................... 29 Implementación del RUP para el proyecto .................................................... 31 ALCANCES Y LIMITACIONES.................................................................................... 32 Alcances ......................................................................................................... 32 Limitaciones................................................................................................... 32 3.

(7) 1.12. FACTIBILIDAD ........................................................................................................ 32 1.12.1. Factibilidad de desarrollo............................................................................... 32 1.12.1.1. Factibilidad técnica .................................................................................... 32 1.12.1.2. Factibilidad operativa ................................................................................. 34 1.12.1.3. Factibilidad legal ........................................................................................ 34 1.12.1.4. Factibilidad económica .............................................................................. 34 1.13. CRONOGRAMA ....................................................................................................... 35 2. 2.1. 2.1.1. 2.2. 2.3. 2.3.1. 2.3.2. 2.3.3. 2.3.4. 3. 3.1. 3.1.1. 3.1.2. 3.1.3. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 4. 4.1. 4.2. 4.3. 4.4.. FASE DE ANÁLISIS ................................................................................................ 36 REQUERIMIENTOS .................................................................................................. 36 Requerimientos funcionales ........................................................................... 37 DEFINICIÓN DE ACTORES ....................................................................................... 39 DEFINICIÓN DE CASOS DE USO ............................................................................... 39 Listado de casos de uso .................................................................................. 39 Documentación de Casos de uso ................................................................... 40 Diagramas de casos de uso ............................................................................ 44 Modelo de Casos de Uso ............................................................................... 45 FASE DE DISEÑO ................................................................................................... 46 DEFINICIÓN DE CLASES .......................................................................................... 46 Definición de Clases Capa Vista .................................................................... 46 Definición de Clases Capa Controlador......................................................... 47 Definición de Clases Capa Modelo ............................................................... 47 DIAGRAMAS DE SECUENCIA ................................................................................... 48 EJECUTAR OPERACIÓN ........................................................................................... 49 DIAGRAMAS DE COLABORACIÓN ........................................................................... 50 DIAGRAMA DE PAQUETES ....................................................................................... 52 MODELO DE BASE DE DATOS ................................................................................... 54 DIAGRAMA DE COMPONENTES ............................................................................... 55 DIAGRAMA EL DOMINIO ......................................................................................... 56 DIAGRAMA DE CLASES ........................................................................................... 57 FASE DE PRUEBAS ................................................................................................ 58 PROTOCOLO FTP .................................................................................................... 58 PROTOCOLO TFTP ................................................................................................. 59 PROTOCOLO TELNET .............................................................................................. 63 PROTOCOLO HTTP................................................................................................. 65. CONCLUSIONES ............................................................................................................. 68 RECOMENDACIONES ................................................................................................... 69 REFERENCIAS ................................................................................................................. 70 4.

(8) LISTA DE TABLAS TABLA 1. FACTIBILIDAD TÉCNICA. EQUIPO DE DESARROLLO ............................................... 33 TABLA 2. FACTIBILIDAD TÉCNICA. SOFTWARE ..................................................................... 33 TABLA 3. FACTIBILIDAD TÉCNICA. EQUIPO MÓVIL............................................................... 34 TABLA 4. FACTIBILIDAD OPERATIVA ..................................................................................... 34 TABLA 5. FACTIBILIDAD ECONOMICA ................................................................................ 35 TABLA 6. REQUERIMIENTOS .................................................................................................. 37 TABLA 7. REQUERIMIENTO PERMITIR EL PROTOCOLO TFTP ................................................. 38 TABLA 8. REQUERIMIENTO DENEGAR PROTOCOLO HTTP .................................................... 38 TABLA 9. REQUERIMIENTO PERMITIR PROTOCOLO HTTP ..................................................... 38 TABLA 10. REQUERIMIENTO HABILITAR PROTOCOLO TELNET ............................................... 39 TABLA 11. CASO DE USO: ELEGIR PLATAFORMA CISCO ....................................................... 40 TABLA 12. CASO DE USO: ENVIAR PLATAFORMA Y OPERACIÓN ............................................. 41 TABLA 13. CASO DE USO: CONECTAR FRAMEWORK .............................................................. 43 TABLA 14. CASO DE USO: EJECUTAR OPERACIÓN EN DISPOSITIVO ......................................... 43 TABLA 15. CLASE MAINACTIVITY. ....................................................................................... 46 TABLA 16. CLASE ACTIVIDAD2 ............................................................................................ 46 TABLA 17. CLASE CISCO ....................................................................................................... 47 TABLA 18. CLASE USUARIO .................................................................................................. 47 TABLA 19. CLASE USUARIODAO ......................................................................................... 47 TABLA 20. CLASE CONEXIÓNDAO ....................................................................................... 48. 5.

(9) LISTA DE FIGURAS FIGURE 1. CRONOGRAMA I.................................................................................................... 35 FIGURE 2. CRONOGRAMA II .................................................................................................. 36 FIGURE 3. DEFINIR OPERACIÓN ............................................................................................ 44 FIGURE 4. CONECTAR FRAMEWORK ...................................................................................... 44 FIGURE 5. EJECUTAR OPERACIÓN ......................................................................................... 44 FIGURE 6. MODELO DE CASOS DE USO................................................................................... 45 FIGURE 7. SECUENCIA: AUTENTICACIÓN DE USUARIO .......................................................... 48 FIGURE 8. SECUENCIA: EJECUTAR OPERACIÓN ..................................................................... 49 FIGURE 9. COLABORACIÓN: VALIDACIÓN DE USUARIO ........................................................ 50 FIGURE 10. COLABORACIÓN: EJECUTAR OPERACIONES ........................................................ 51 FIGURE 11. DIAGRAMA DE PAQUETES.................................................................................... 53 FIGURE 12. MODELO DE BD ................................................................................................. 54 FIGURE 13. DIAGRAMA DE COMPONENTES ........................................................................... 55 FIGURE 14. DIAGRAMA EL DOMINIO ..................................................................................... 56 FIGURE 15. DIAGRAMA DE CLASES ....................................................................................... 57 FIGURE 16. PRUEBAS PROTOCOLO FTP ................................................................................ 58 FIGURE 17. CONSOLA SERVIDOR FTP..................................................................................... 59 FIGURE 18. PRUEBAS PROTOCOLO TFTP .............................................................................. 60 FIGURE 19: CONSOLA ROUTER REAL .................................................................................... 61 FIGURE 20: CONSOLA ROUTER REAL .................................................................................... 61 FIGURE 21. CISCO TFTP ....................................................................................................... 62 FIGURE 22. CARPETA SERVIDOR TFTP ................................................................................. 62 FIGURE 23. PRUEBAS PROTOCOLO TELNET ........................................................................... 63 FIGURE 24. CONSOLA, SERVIDOR TELNET ............................................................................. 64 FIGURE 25. CONSOLA, ACCESO AL SERVIDOR TELNET............................................................ 64 FIGURE 26. SERVIDOR TELNET .............................................................................................. 65 FIGURE 27. PRUEBAS PROTOCOLO HTTP ............................................................................. 66 FIGURE 28. EXPLORADOR, SIN ACCESO HTTP ...................................................................... 66 FIGURE 29. EXPLORADOR, ACCESO A HTTP.......................................................................... 67. 6.

(10) Resumen. En las organizaciones, el uso del telefono móvil se ha consolidado, de tal forma, que hace parte de las actividades cotidianas del hombre. La tecnologia móvil posibilita la integración de diversos servicios y la eficiencia en la prestación de los mismos, por lo que emprender la movilidad en procedimientos administrativos de red, ayuda a: la automatización de tareas, optimización de tiempos, recursos, adaptabilidad, entre otros.. En el presente documento se propone e implementa un Framework para la configuración de listas de acceso (ACLs) extendidas en routers CISCO desde un dispositvo móvil, el cual va dirigido especialmente hacia los administradores de redes, los cuales tienen que configurar hoy en día los enrutadores de forma manual haciendo del proceso algo tedioso y propenso a que a umente la probabilidad de error en la sintaxis implementada. el proyecto consta también de un sistema de autenticación de usuarios básica en el motor de base de datos MySQL, una topología de red virtualizada en GNS3 y un servicio Web SOAP.. El diseño y desarrollo permitió evidenciar que un sistema para la configuración de enrutadores cisco, permite inmediatez en la obtención de configuraciones, ahorro de tiempo y de desplazamientos innecesarios a las dependencias administrativas, además de que no se requieren componentes de sistemas operativos como terminales hyperterminal, consolas de símbolo del sistema o servidores tftp, para efectuar conectividad remota.. El Framework fue diseñado siguiendo la metodología RUP, basándose en el patrón de arquitectura multinivel, con el fin de que en un futuro se permita la posibilidad de expandir o implementar nuevas funcionalidades. De igual forma se muestran los diagramas UML que describen mejor la funcionalidad de cada uno de los componentes del aplicativo móvil y el framework, sus requerimientos técnicos y el manual de usuario.. 7.

(11) Abstract. In organizations, the use of the mobile phone has been consolidated in such a way, which is part of the daily activities of the man. Mobile technology enables the integration of different services and efficiency in the provision of the same, so take the administrative procedures of network mobility, helps to: the automation of tasks, optimization of time, resources, adaptability, among others.. In this paper is proposed and implemented a Framework for configuring access lists (ACLs) extended in routers CISCO from a mobile device, which is especially aimed toward network administrators, which must now configure routers manually doing somewhat tedious and error-prone process that implemented to umente the probability of error in the syntax. the project also consists of a set of basic user authentication in MySQL database engine, a topology of virtualized network in GNS3 and a SOAP Web service.. The design and development allowed to demonstrate that a system for the configuration of routers cisco, allows immediacy in the obtaining of configurations, saving time and unnecessary travel to the administrative offices, in addition to components of operating systems such as hyperterminal Terminal, symbol of tftp servers or system consoles, are not required to carry out remote connectivity.. The Framework was designed following the RUP methodology, based on the pattern of multi-tiered architecture, so that in the future be allowed the possibility to expand or implement new features. Similarly, UML diagrams that best describe the functionality of each of the components of the mobile application and the framework, its technical requirements and user manual are displayed.. 8.

(12) Introducción. La tecnología móvil constituye un nuevo cauce de comunicación del administrador de red con los dispositivos informáticos. Abordar la movilidad desde el punto de vista de los procedimientos administrativos; ayuda a delimitar mejor nuevas operaciones y su forma de prestación. La tecnología móvil ofrece una serie de oportunidades para la administración de redes y de beneficios para las organizaciones y sus empleados.. El uso del teléfono móvil se ha consolidado en las organizaciones, para la prestación de servicios y para ejecutar gestiones de red. En general, se entiende que la administración de redes resulta perfectamente aplicable a este nuevo fenómeno, al constituir el teléfono móvil un concreto canal de relación.. Algunos de los efectos benéficos que se pueden citar, para la administración de la red y para las personas que la integran, son: mayor eficiencia, por la reducción de tiempo de prestación de servicios, mejora de la calidad gracias a la ejecución automatizada de procesos, flexibilidad; al favorecer la independencia de los servicios prestados respecto de su prestación presencial, inmediatez en la obtención de configuraciones administrativas, y ahorro de tiempo y de traslados innecesarios a las dependencias administrativas.. “Los diseñadores de red utilizan firewalls para proteger las redes contra el uso no autorizado. Los firewalls son soluciones de hardware o software que hacen cumplir las políticas de seguridad de la red. Es como la cerradura de la puerta de la habitación de un edificio. La cerradura sólo permite que ingresen los usuarios autorizados con una llave o tarjeta de acceso. Del mismo modo, los firewalls filtran el ingreso a la red de los paquetes no autorizados o potencialmente peligrosos. En un router Cisco, se puede configurar un simple firewall que proporcione capacidades básicas de filtrado de tráfico mediante las ACL”1. 1.. CCNA Exploration 4.0. Acceso a la WAN. 2008. Módulo 4. Cap 5.. 9.

(13) Una ACL es una lista secuencial de sentencias de permiso o denegación que se aplican a direcciones o protocolos de capa superior. Las ACL brindan una manera poderosa de controlar el tráfico de entrada o de salida de la red. Es posible configurar las ACL para todos los protocolos de red enrutados.. El motivo más importante para configurar las ACL es brindar seguridad a la red. Las ACL le permiten controlar el tráfico de entrada y de salida de la red. Este control puede ser tan simple como permitir o denegar los hosts o direcciones de red. Sin embargo, las ACL también pueden configurarse para controlar el tráfico de red según el puerto TCP que se utiliza.. El filtrado de paquetes, a veces denominado filtrado estático de paquetes, controla el acceso a la red, analiza los paquetes de entrada y de salida, y permite o bloquea su ingreso según un criterio establecido.. Un router actúa como filtro de paquetes cuando reenvía o deniega paquetes según las reglas de filtrado. Cuando un paquete llega al router de filtrado de paquetes, éste extrae determinada información del encabezado del paquete y toma decisiones según las reglas de filtrado, ya sea autorizar el ingreso del paquete o descartarlo. El filtrado de paquetes actúa en la capa de red del modelo de interconexión de sistema abierto (OSI, Open Systems Interconnection) o en la capa Internet de TCP/IP.. Como dispositivo de Capa 3, un router de filtrado de paquetes utiliza reglas para determinar la autorización o denegación del tráfico según las direcciones IP de origen y de destino, el puerto origen y el puerto destino, y el protocolo del paquete.. Estas reglas se definen mediante las listas de control de acceso o ACL. Con el fin de implementar la arquitectura de framework, basada en objetos remotos, se pretende desarrollar una aplicación web para configurar listas de acceso extendidas, desde dispositivos móviles, que puede ejecutar operaciones a distancia, en enrutadores CISCO. 10.

(14) 1. Organización, definición y análisis. 1.1. Tema. Se plantea la implementación de un framework para configurar listas de acceso extendidas sobre routers cisco, para el manejo de permisos y privilegios de acceso, configuración de firewall, permitiendo o denegando el tráfico de red. De esta forma, por medio de la implementación desde un dispositivo móvil, el administrador de red podrá acceder desde cualquier sitio y así poder configurar de manera correcta el router.. 1.2. Titulo. Framework para configurar Listas de Acceso Extendidas en Routers CISCO desde un dispositivo móvil.. 1.3. Objetivos. 1.3.1. Objetivo general. Construir un framework para configurar Listas de Acceso Extendidas en routers CISCO desde un dispositivo móvil.. 1.3.2. Objetivos específicos. . Diseñar la arquitectura del Framework que contenga los mecanismos de comunicación entre usuarios finales y enrutadores.. . Diseñar e implementar un servicio de autenticación de usuarios para la configuración de los routers.. . Desarrollar servicios para el control de listas de acceso y ejecución de comandos vía telnet en routers CISCO. 11.

(15) . Implementar la arquitectura del Framework, que permita la configuración de los enrutadores virtualizados con GNS3.. . Acceder a la configuración de los routers por medio de un dispositivo móvil.. 1.4. Descripción del problema. Visualizar el estado de configuración de un enrutador es importante para cualquier administrador de red, independiente del lugar donde se encuentre y del tipo de tecnología empleada para acceder al dispositivo remoto. No tener acceso continuo a los enrutadores puede ocasionar problemas; impide supervisar periódicamente las configuraciones y produce un servicio de administración poco fiable.. Actualmente, la configuración de enrutadores se realiza desde terminales específicas y requiere un conocimiento detallado de la sintaxis de los comandos de configuración, lo que conlleva a demoras en el proceso, puesto que por ejemplo, los errores de formato de comandos retrasan el tiempo en el que se realiza una configuración en un enrutador, por parte de administradores de red.. Los fallos de seguridad de las redes actuales, pueden permitir a intrusos, acceder a la información que transita en la red. Aún peor, estos intrusos pueden llegar a bloquear o deshabilitar terminales, en consecuencia, surge la necesidad de implementar ACLS.. La configuración de enrutadores no es tan flexible, requiere conocimientos del orden y la sintaxis de los comandos. La falta de herramientas gráficas para realizar el proceso, hace que esté propenso a errores, los cuales pueden ser visualizados más fácilmente, mediante herramientas gráficas de configuración. Por consiguiente, han surgido aplicaciones de terceros para configurar enrutadores. Sin embargo, en algunos casos tienen que pasar a través de proveedores de servicios y en otros casos, son propietarias y se desconoce su funcionamiento interno, lo cual genera incertidumbre sobre los procedimientos que se. 12.

(16) ejecutan. Herramientas de software libre, conceden el beneficio de configurar enrutadores, pero no realizan más acciones.. Otro inconveniente en el desarrollo de estos sistemas de configuración, es que la llegada de nuevos enrutadores requiere modificar la estructura del sistema de configuración. Adicionalmente, la ausencia de frameworks, hace que se no se pueda manejar la ambigüedad en la ejecución de instrucciones de alto nivel; es decir, instrucciones que están precedidas por otras instrucciones, que no pueden ser identificadas.. De igual forma, procedimientos que requieren utilizar conjuntos de instrucciones complejas, con orden de precedencia lógica, y un alto conocimiento de protocolos, como las listas de acceso extendidas, hacen más tediosa la configuración manual, para los administradores de red.. 1.5. Pregunta de investigación. ¿Por qué implementar un framework, para configurar listas de control de acceso extendidas, en routers cisco desde dispositivos móviles?. 1.6. Justificación. Los sistemas de configuración requieren realizar operaciones sobre el enrutador manteniendo bajo acoplamiento con el mismo. Esto significa que un cambio en un enrutador no debe alterar el funcionamiento del software de configuración, tampoco dañar la arquitectura del mismo. Los frameworks proveen mecanismos basados en patrones de diseño que encapsulan peticiones al objeto que se configura y los desacopla de los objetos a configurar.. Los frameworks proveen las siguientes ventajas arquitectónicas en el desarrollo de sistemas: 13.

(17) a) Facilitar la parametrización de las acciones de configuración a realizar. b) Independizar el momento de petición de ejecución del comando de configuración. c) Implementar CallBacks, especificando que órdenes queremos que se ejecuten en ciertas situaciones de otras órdenes. Es decir, un parámetro de una orden, puede ser otra orden a ejecutar. d) Soportar el "deshacer". e) Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas.. Por lo anterior se puede observar que un sistema de configuración de enrutadores basado en frameworks, permite manejar las dependencias entre ejecución de órdenes, transparencia en el desarrollo y consistencia en su ejecución. Los anteriores aspectos permiten que el desarrollo basado en frameworks, brinde mayor eficiencia, por la reducción de tiempo de prestación de servicios, mejora de la calidad gracias a la ejecución automatizada de procesos y brinda mayor flexibilidad, al favorecer la independencia de los servicios prestados respecto de su prestación presencial.. Aunque la configuración de enrutadores se puede hacer por medio de consola, middleware y del uso del protocolo SNMP2, todas estas técnicas coexisten con el desarrollo de sistemas tipo framework. Incluso es posible usar frameworks3 para configurar servicios, o simplemente para construir aplicaciones web de configuración de enrutadores4. La relación entre los framework y los sistemas de enrutamiento es tan estrecha, que incluso los. 2. A novel Java RMI middleware design for active networks. Meng-Chun Wueng; Fu-Fang Yang; Cheng-Zen Yang;. TENCON 2004. 2004 IEEE Region 10 Conference. Volume: C. Publication Year: 2004 , Page(s): 68 71 Vol. 3 3 Dynamic dispersion framework for router load balancing. Yunhuai Liu; Ni, L.M.;. Parallel and Distributed Systems, 2005. Proceedings. 11th International Conference on. Volume: 1. Publication Year: 2005 , Page(s): 641 - 647 Vol. 1 4 SNMP Management in a Distributed Software Router Architecture. Bianco, A.; Birke, R.; Debele, F.G.; Giraudo, L.; Communications (ICC), 2011 IEEE International Conference on. Publication Year: 2011 , Page(s): 1 – 5.. 14.

(18) mismos sistemas distribuidos poseen algoritmos de enrutamiento5 y los framework apoyan la configuración de servicios.. Adicionalmente hay dos razones importantes para usar un framework como intermediario, entre el usuario final y el enrutador, para sistemas de configuración:. a) Los frameworks permiten que la configuración se pueda realizar por capas, en donde cada capa puede ser utilizada en otros ambientes, en tanto que los middleware están diseñados para ser intermediarios entre dos tipos de aplicaciones predeterminadas. b) Los frameworks permiten construir aplicaciones más unificadas que los middelware y el protocolo SNMP6.. Por lo anterior se concluye, que un sistema para la configuración de enrutadores cisco, permite inmediatez en la obtención de configuraciones, ahorro de tiempo y de desplazamientos innecesarios a las dependencias administrativas.. Otra ventaja de automatizar el proceso de listas de control de acceso, en enrutadores cisco, es que no se requieren componentes de sistemas operativos como terminales hyperterminal, consolas de símbolo del sistema o servidores tftp, para efectuar conectividad remota. La conexión se realiza a través del framework, utilizando invocación remota de métodos. Así se elimina el riesgo de tener sesiones abiertas y estar propenso a husmeadores de contraseñas. Sin necesidad de disponer de un sistema operativo robusto, y sin necesidad de disponer de navegadores web; como Explorer, Mozilla, Opera u otro, es posible configurar las ACLs desde la aplicación móvil.. 5. A Model-Driven Framework for Enabling Self-Service Configuration of Business Services. Xin Zhang; Pei Sun; Ying Huang; Wei Sun; Web Services, 2008. ICWS '08. IEEE International Conference on. Publication Year: 2008 , Page(s): 497 – 504 6 Stepwise framework design by application unification. Bouassida, N.; Ben-Abdallah, H.; Gargouri, F.; Hamadou, A.B.; Systems, Man and Cybernetics, 2002 IEEE International Conference on. Volume: 6. Publication Year: 2002.. 15.

(19) 1.7. Marco teórico. 1.7.1. Programación orientada a objetos. En cualquier parte del mundo real puede ver objetos: gente, animales, plantas, automóviles,. aviones, edificios, computadoras, etcétera. Los humanos pensamos en. términos de objetos. Los teléfonos, casas, semáforos, hornos de microondas y enfriadores de agua son sólo unos cuantos objetos más. Los programas de cómputo, como los programas de Java que leerá en este libro y los que usted mismo escriba, están compuestos por muchos objetos de software con capacidad de interacción.. Los objetos se dividen en dos categorías: animados e inanimados. Los objetos animados están “vivos” en cierto sentido; se mueven a su alrededor y hacen cosas. Por otro lado, los objetos inanimados no se mueven por su propia cuenta. Sin embargo, los objetos de ambos tipos tienen ciertas cosas en común. Todos ellos tienen atributos (como tamaño, forma, color y peso), y todos exhiben comportamientos (por ejemplo, una pelota rueda, rebota, se infla y desinfla; un bebé llora, duerme, gatea, camina y parpadea; un automóvil acelera, frena y da vuelta; una toalla absorbe agua). En programación se estudia los tipos de atributos y comportamientos que tienen los objetos de Software.. Los humanos aprenden acerca de los objetos existentes estudiando sus atributos y observando sus comportamientos. Distintos objetos pueden tener atributos similares y pueden exhibir comportamientos similares. Por ejemplo, pueden hacerse comparaciones entre los bebés y los adultos, y entre los humanos y los chimpancés. “Los lenguajes como Java son orientados a objetos. La programación en dichos lenguajes se llama programación orientada a objetos (POO), y permite a los programadores de computadoras implementar un diseño orientado a objetos como un sistema funcional.”7 Por otra parte, los lenguajes como C son por procedimientos, de manera que la programación tiende a ser orientada a la acción. En C, la unidad de programación es la función. 7. OJEDA, Pablo. Generación de una Plataforma Automatizada de Administración de Redes, orientado a las pequeñas y medianas Empresas. Chile: 2007. 325 p.. 16.

(20) Los grupos de acciones que realizan cierta tarea común se forman en funciones, y las funciones se agrupan para formar programas. En Java, la unidad de programación es la clase a partir de la cual se instancian (crean) los objetos en un momento dado. Las clases en Java contienen métodos (que implementan operaciones y son similares a las funciones en C) y campos (que implementan atributos).. En la programación orientada a objetos cada clase contiene campos, además del conjunto de métodos que manipulan esos campos y proporcionan servicios a clientes (es decir, otras clases que utilizan esa clase). El programador utiliza las clases existentes como bloques de construcción para crear nuevas clases. Las clases son para los objetos lo que los planos de construcción, para las casas. Así como podemos construir muchas casas a partir de un plano, podemos instanciar (crear) muchos objetos a partir de una clase. No puede cocinar alimentos en la cocina de un plano de construcción; puede cocinarlos en la cocina de una casa. Las clases pueden tener relaciones con otras clases. Por ejemplo, en un diseño orientado a objetos de un banco, la clase “cajero” necesita relacionarse con las clases “cliente”, “cajón de efectivo”, “bóveda”, etcétera. A estas relaciones se les llama asociaciones.. 1.7.1.1.. Diseño orientado a objetos. El diseño orientado a objetos (DOO) modela el software en términos similares a los que utilizan las personas para describir objetos del mundo real. Este diseño aprovecha las relaciones entre las clases, en donde los objetos de cierta clase (como una clase de vehículos) tienen las mismas características; los automóviles, camiones, pequeños vagones rojos y patines tienen mucho en común. El DOO también aprovecha las relaciones de herencia, en donde las nuevas clases de objetos se derivan absorbiendo las características de las clases existentes y agregando sus propias características únicas. Un objeto de la clase “convertible” ciertamente tiene las características de la clase más general “automóvil” pero, de manera más específica, el techo de un convertible puede ponerse y quitarse.. 17.

(21) El diseño orientado a objetos proporciona una manera natural e intuitiva de ver el proceso de diseño de software: a saber, modelando los objetos por sus atributos y comportamientos, de igual forma que como describimos los objetos del mundo real.. El DOO también modela la comunicación entre los objetos. Así como las personas se envían mensajes unas a otras (por ejemplo, un sargento ordenando a un soldado que permanezca firme), los objetos también se comunican mediante mensajes. Un objeto cuenta de banco puede recibir un mensaje para reducir su saldo por cierta cantidad, debido a que el cliente ha retirado esa cantidad de dinero.. El DOO encapsula, envuelve los atributos y los comportamientos en los objetos; los atributos y las operaciones de un objeto se enlazan íntimamente entre sí. Los objetos tienen la propiedad de ocultamiento de información. Esto significa que los objetos pueden saber cómo comunicarse entre sí a través de interfaces bien definidas, pero por lo general no se les permite saber cómo se implementan otros objetos; los detalles de la implementación se ocultan dentro de los mismos objetos. “Por ejemplo, podemos conducir un automóvil con efectividad, sin necesidad de saber los detalles acerca de cómo funcionan internamente los motores, las transmisiones y los sistemas de escape; siempre y cuando sepamos cómo usar el pedal del acelerador, el pedal del freno, el volante, etcétera. Más adelante veremos por qué el ocultamiento de información es tan imprescindible para la buena ingeniería de software.”. Si un proceso implica analizar y diseñar un sistema desde el punto de vista orientado a objetos, se llama un proceso de análisis y diseño orientado a objetos (A/DOO). El análisis y diseño pueden ahorrar innumerables horas, evitan el fracaso de los sistemas y consecuentes pérdidas de tiempo, dinero y esfuerzo.. A/DOO es el término genérico para el proceso de analizar un problema y desarrollar un método para resolverlo. Los pequeños problemas no requieren de un proceso exhaustivo de A/DOO. Podría ser sufíciente con escribir pseudocódigo, el pseudocódigo es un medio. 18.

(22) informal para expresar la lógica de un programa. Se pude utilizar como guía, mientras se escribe el código.. A medida que los problemas y los grupos de personas que los resuelven aumentan en tamaño, los métodos de A/DOO se vuelven más apropiados que el pseudocódigo. Idealmente, un grupo debería acordar un proceso estrictamente definido para resolver su problema, y establecer también una manera uniforme para que los miembros del grupo se comuniquen los resultados de ese proceso entre sí.. Aunque existen diversos procesos de A/DOO, hay un lenguaje gráfico para comunicar los resultados de cualquier proceso A/DOO que se ha vuelto muy popular. “Este lenguaje, conocido como Lenguaje Unificado de Modelado (UML), se desarrolló a mediados de la década de los noventa, bajo la dirección inicial de tres metodologistas de software: Grady Booch, James Rumbaugh e Ivar Jacobson.”8. 1.7.2. Listas de control de acceso (ACL). Una Lista de Control de Acceso o ACL (del inglés, Access Control List) es un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido.. Las ACLs permiten controlar el flujo del tráfico en equipos de redes, tales como routers y switches. Su principal objetivo es filtrar tráfico, permitiendo o denegando el tráfico de red de acuerdo a alguna condición. Sin embargo, también tienen usos adicionales, como por ejemplo, distinguir “tráfico interesante” (tráfico suficientemente importante como para activar o mantener una conexión) en ISDN9.. 8 9. DEITEL, Paul y Harvey. Java Como programar. México: Prentice Hall, 2008. pág. 20. ACL: http://cesarcabrera.info/blog/%C2%BFcomo-funcionan-las-acl-en-cisco-i-conceptos/. 19.

(23) Existen dos tipos de ACL:. . ACL estándar, donde solo tenemos que especificar una dirección de origen;. . ACL extendida, en cuya sintaxis aparece el protocolo y una dirección de origen y de destino.. 1.7.3. Métodos de conexión Remota RPCs y RMI. Remote Procedurell Call (RPC), es una vieja tecnología que Sun desarrolló, hace lo mismo que RMI (Java Remote Method Invocation). RPC es independiente del lenguaje y del procesador; RMI es independiente del procesador y naturalmente está limitado a programas escritos en Java.. Para obtener la portabilidad a través de la plataforma que proporciona Java, los RPCs tienen mayor sobrecarga que RMI. Los RPCs tienen que convertir argumentos entre arquitecturas de forma que cada computador pueda utilizar sus tipos de datos nativos. Por ejemplo, los enteros tienen que ser convertidos a implementaciones big-endian y littleendian. Además, los RPC pueden enviar solo tipos de datos primitivos, mientras que RMI puede enviar objetos. Sun no soporta RPCs en Java, aunque hay algunas implementaciones de terceros. RMI es la solución más simple para la comunicación entre programas Java en diferentes hosts. Sin embargo, si es necesario conectar programas escritos en diferentes lenguajes, se debe optar por CORBA.. “Invocar métodos remotos en objetos locales trae muchos problemas de seguridad. Java proporciona la única suited para resolver estos problemas. Las actividades que un objeto remoto puede realizar son limitadas de la misma forma que un Applet es limitado. Un objeto SecurityManager verifica que todas las operaciones estén permitidas”10. 10. RUSTY, Harold. Java Network Programming. USA: O’Reilly Media ,2000. pág. 520. 20.

(24) 1.7.4. TELNET (Tele Network - Tele Red). Sistema que permite conectarse a un host o servidor en donde el ordenador cliente hace de terminal virtual del ordenador servidor.. Telnet es un protocolo que permite acceder mediante una red a otra máquina y manejarla, siempre en modo terminal (no hay gráficos). Se dejó de usar casi por completo por tener problemas de seguridad (no encriptaba la información) y comenzó a popularizarse el SSH.. Se refiere a la conexión remota a un ordenador, esto es posible en Internet gracias al TELNET protocol. Es habitual usar la expresión "hacer un TELNET", con ello estamos expresando que vamos a realizar una conexión en modo terminal remoto con una máquina en la que estamos autorizados. Sin embargo, muchas máquinas permiten que les hagamos un TELNET como invitados para que podamos acceder a la información pública de la que disponen, y para lo cual no necesitamos autorización.. 1.8. Marco conceptual. 1.8.1. Java. Java se ha convertido en el lenguaje de elección para implementar aplicaciones basadas en Red, y software para dispositivos que se comunican a través de una red. Ahora los estéreos y otros dispositivos en los hogares pueden conectarse entre sí mediante el uso de la tecnología Java. En el 2006 Sun anunció que había ml millones de teléfonos móviles y dispositivos portátiles habilitados para Java. Éste lenguaje ha evolucionado rápidamente en las aplicaciones de gran escala. Es el lenguaje preferido para satisfacer las necesidades de programación de muchas organizaciones.. 21.

(25) “Las librerías de red de Java, permiten fácilmente y rápidamente, escribir programas que cumplan muchas tareas de Red. Esto incluye; Convertir y reenviar HTML, Enviar mail con SMTP, recibir Mail con POP e IMAP, escribir servicios multihilo, instalar nuevos protocolos en navegadores, Encriptar comunicaciones para confidencialidad, autenticación y garantizar la integridad de mensajes. Diseñar aplicaciones gráficas para servicios de Red, conectar sockets y lograr comunicación de red a bajo nivel, hacer aplicaciones distribuidas a través de RMI.” 11. Java es el primer lenguaje de programación diseñado para proporcionar soluciones de Networking. Con el continuo crecimiento de internet, java es la única suited de construcción para aplicaciones de red. Proporciona soluciones a un gran número de problemas, plataformas independientes, seguridad. Juntas, estas y otras características de Java, permiten rápidamente ejecutar y desarrollar programas desde un sitio Web, sin preocuparse de que el programa pueda contener virus o de accidentes del sistema.. “Uno de los grandes secretos de Java es que permite escribir programas de Red fácilmente, más que cualquier otro lenguaje. Aplicaciones completamente funcionales son desarrolladas solo con un poco de código. La parte de los programas que trata con la Red, es casi siempre la más corta y simple.”12. 1.8.1.1.. Java Standard Edition. Java Standard Edition ( Java SE ) es el nombre oficial de la edición estándar a partir de la versión 6 de la plataforma. En versiones anteriores a ésta se le llama Java 2 Standard Edition ( J2SE ). Esta edición estándar define las características básicas para trabajar con la plataforma en ambientes desktop y servidores. Los componentes principales de esta edición son:. 11. RAPOSA, Richard. Java in 60 Minutes a Day. USA: Wiley Publishing, 2003. pág. 25. BROSE, Gerald. Java Programming with CORBA. Advanced Techniques for Building Distributed Applications. USA: Wiley Publishing, 2001. pág 13. 12. 22.

(26) . Compilador de código fuente en lenguaje de programación java a bytecode (código binario ejecutable en una máquina virtual).. . Máquina virtual de java (Java Virtual Machine - JVM), que proporciona el ambiente básico de ejecución de código java sobre sistemas operativos tradicionales (Linux, Windows, Unix, MacOS, etc).. . Librerías centrales y APIs de la plataforma, que permiten realizar las tareas de programación básicas sobre la plataforma.. 1.8.2. Cisco. Cisco Systems es una empresa global con sede en San José, (California, Estados Unidos), principalmente dedicada a la fabricación, venta, mantenimiento y consultoría de equipos de telecomunicaciones tales como:. . Dispositivos de conexión para redes informáticas: routers (enrutadores, encaminadores o ruteadores), switches (conmutadores) y hubs (concentradores);. . Dispositivos de seguridad como Cortafuegos y Concentradores para VPN;. . Productos de telefonía IP como teléfonos y el CallManager (una PBX IP);. . Software de gestión de red como CiscoWorks, y. . Equipos para redes de área de almacenamiento.. Además de desarrollar el hardware de sus equipos, Cisco Systems también se ocupa de desarrollar su propio software de gestión y configuración de los mismos. Dicho software es conocido como IOS de código actualmente cerrado y totalmente propietario.13. 13. Cisco Systems. Recuperado de: http://es.wikipedia.org/wiki/Cisco_Systems. 23.

(27) 1.8.3. Framework. Plataforma, entorno, marco de trabajo. Desde el punto de vista del desarrollo de software, un framework es una estructura de soporte definida, en la cual otro proyecto de software puede ser organizado y desarrollado.. Los frameworks suelen incluir:. . Soporte de programas.. . Bibliotecas.. . Lenguaje de scripting.Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de programas.. Los frameworks permiten:. . Facilitar el desarrollo de software.. . Evitar los detalles de bajo nivel, permitiendo concentrar más esfuerzo y tiempo en identificar los requerimientos 14. 1.8.4. Middleware. Middleware es un software de computadora que conecta componentes de software o aplicaciones para que puedan intercambiar datos entre éstas. Es utilizado a menudo para soportar aplicaciones distribuidas. Esto incluye servidores web, servidores de aplicaciones, sistemas de gestión de contenido y herramientas similares. Middleware es especialmente esencial para tecnologías como XML, SOAP, servicios web y arquitecturas orientada a servicios. Middleware es una incorporación relativamente reciente en la computación. Obtuvo popularidad en los 80 como una solución al problema de cómo conectar nuevas aplicaciones con viejos sistemas. De todas maneras el término ha sido usado desde 1968. 14. Definición de Framework. Recuperado de: http://www.alegsa.com.ar/Dic/framework.php. 24.

(28) También facilitaba el procesamiento distribuido: conexión de múltiples15 aplicaciones para crear una aplicación más grande, generalmente sobre una red.. 1.8.5. Firewall. Un firewall es un dispositivo que funciona como cortafuegos entre redes, permitiendo o denegando las transmisiones de una red a la otra. Un uso típico es situarlo entre una red local y la red Internet, como dispositivo de seguridad para evitar que los intrusos puedan acceder a información confidencial.. Un firewall es simplemente un filtro que controla todas las comunicaciones que pasan de una red a la otra y en función de lo que sean permite o deniega su paso. Para permitir o denegar una comunicación el firewal examina el tipo de servicio al que corresponde, como pueden ser el web, el correo o el IRC. Dependiendo del servicio el firewall decide si lo permite o no. Además, el firewall examina si la comunicación es entrante o saliente y dependiendo de su dirección puede permitirla o no.. Un firewall puede ser un dispositivo software o hardware, es decir, un aparatito que se conecta entre la red y el cable de la conexión a Internet, o bien un programa que se instala en la máquina que tiene el modem que conecta con Internet. Incluso podemos encontrar ordenadores computadores muy potentes y con softwares específicos que lo único que hacen es monitorizar las comunicaciones entre redes.16. 15 16. Definición de Middleware. Recuperado de: http://www.alegsa.com.ar/Dic/middleware.php Que es un firewall. Recuperado de: http://www.desarrolloweb.com/articulos/513.php. 25.

(29) 1.9. Marco legal. 1.9.1. Ley 29 de 1990. Por la cual se dictan disposiciones para el fomento de la investigación científica y el desarrollo tecnológico y se otorgan facultades extraordinarias. El Congreso de Colombia, en ejercicio de las facultades que le otorga el artículo 76 de la Constitución, DECRETA:. Artículo 1º.- Corresponde al Estado promover y orientar el adelanto científico y tecnológico y, por lo mismo, está obligado a incorporar la ciencia y la tecnología a los planes y programas de desarrollo económico y social del país y a formular planes de ciencia y tecnología tanto para el mediano como para el largo plazo. Así mismo, deberá establecer los mecanismos de relación entre sus actividades de desarrollo científico y tecnológico y las que, en los mismos campos, adelanten la universidad, la comunidad científica y el sector privado colombianos.. Artículo 2º.- La acción del Estado en esta materia se dirigirá a crear condiciones favorables para la generación de conocimiento científico y tecnología nacionales; a estimular la capacidad innovadora del sector productivo; a orientar la importación selectiva de tecnología aplicable a la producción nacional; a fortalecer los servicios de apoyo a la investigación científica y al desarrollo tecnológico; a organizar un sistema nacional de información científica y tecnológica; a consolidar el sistema institucional respectivo y, en general, a dar incentivos a la creatividad, aprovechando sus producciones en el mejoramiento de la vida y la cultura del pueblo17.. 17. Ley 29 de 1990 Nivel Nacional, Recuperado de: http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=254. 26.

(30) 1.9.2. Ley 1273 de 2009, Ley de delitos informáticos en Colombia. El 5 de enero de 2009, el Congreso de la República de Colombia promulgó la Ley 1273 “Por medio del cual se modifica el Código Penal, se crea un nuevo bien jurídico tutelado – denominado “De la Protección de la información y de los datos”- y se preservan integralmente los sistemas que utilicen las tecnologías de la información y las comunicaciones, entre otras disposiciones”.. Dicha ley tipificó como delitos una serie de conductas relacionadas con el manejo de datos personales, por lo que es de gran importancia que las empresas se blinden jurídicamente para evitar incurrir en alguno de estos tipos penales.18. 1.9.3. Ley 603 de 2000. El artículo 2º de la Ley 603 de 2000 señala que "las autoridades tributarias colombianas podrán verificar el estado de cumplimiento de las normas sobre Derechos de Autor por parte de las sociedades para impedir que, a través de su violación, también se evadan tributos".19. Para el caso específico del software, los responsables del Informe de Gestión deben asegurarse que por programa instalado exista la respectiva licencia. El proceso de verificación de la información consignada en el Informe de Gestión debe confrontarse con una auditoría de software, la misma que puede realizarse siguiendo las guías gratuitas desarrolladas por la BSA. El incumplimiento a esta obligación legal puede generar sanciones civiles y penales a los responsables de su elaboración.. 18. Ley de delitos informáticos en Colombia, Recuperado de: http://www.deltaasesores.com/articulos/autoresinvitados/otros/3576-ley-de-delitos-informaticos-en-colombia 19 Ley 603 de 2000, Disponible en: http://www.corventasdecolombia.com.co/ley-603-derechos-de-autor-diansoftware-colombia. 27.

(31) 1.10. Metodología. Para el desarrollo del proyecto se implementara la metodología de desarrollo RUP (Racional UnifiedProcess) Proceso Unificado Racional. Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización.. Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.. 1.10.1. Características metodología RUP.. El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo.. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodología de desarrollo iterativo enfocada hacia “los casos de uso, manejo de riesgos y el manejo de la arquitectura”.. El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad específica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visión y el mismo proceso acerca de cómo desarrollar software.. 28.

(32) 1.10.2. Ciclo de Vida. Figura 1. Fases de RUP. En el ciclo de vida RUP veremos una implementación del desarrollo en espiral. Con el ciclo de vida se establecen tareas en fases e iteraciones. El RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable. Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una base de inicio.. 1.10.3. Fases. a. Fase de Inicio. Durante esta fase de inicio las iteraciones se centran con mayor énfasis en las actividades de modelamiento de la empresa y en sus requerimientos.. 29.

(33) b. Fase de Elaboración. Durante esta fase de elaboración, las iteraciones se centran al desarrollo de la base de la diseño, encierran más los flujos de trabajo de requerimientos, modelo de la organización, análisis, diseño y una parte de implementación orientada a la base de la construcción. En esta fase se realiza la elaboración de los casos de uso.. c. Fase de Construcción. Durante esta fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se redefine su análisis y diseño y se procede a su implantación y pruebas. En esta fase se realiza una pequeña cascada para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva implementación del producto. En esta fase se trabaja con las siguientes vistas:. 1. Vista Lógica: . Diagrama de clases. . Modelo E-R (Si el sistema así lo requiere). 2. Vista de Implementación: . Diagrama de Secuencia. . Diagrama de estados. . Diagrama de Colaboración. 3. Vista Conceptual: . Modelo de dominio. 4. Vista física: . Mapa de comportamiento a nivel de hardware.. 30.

(34) d.. Fase de Transición. Durante esta fase de transición busca garantizar que se tiene un producto preparado para su entrega al usuario. Se realizan las siguientes actividades:. . Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo). . Pretende implementar las mejores prácticas en Ingeniería de Software. . Desarrollo iterativo. . Administración de requisitos. . Uso de arquitectura basada en componentes. . Control de cambios. . Modelado visual del software. . Verificación de la calidad del software. El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).. 1.10.4. Implementación del RUP para el proyecto. “La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.” 20. 20. Metodología RUP, en línea http://ftp.itmerida.mx/Mario/Gestiondeproyectos.pdf. 31.

(35) 1.11. Alcances y limitaciones. 1.11.1. Alcances. . La aplicación permitirá ejecutar una orden desde un dispositivo móvil, que soporte Wi-Fi, JAVA MIDP 2.0 y CLDC 1.0, para configurar listas de control de acceso extendidas, en routers cisco.. . El proceso de ejecución de ACLs es automático, no es necesaria la intervención manual del administrador de red.. . Una vez consumido el servicio web desde el dispositivo móvil, quedan habilitadas las ACLs configuradas.. . Las listas de control de acceso, impiden o deniegan tráfico ipv4, de los protocolos: http, ftp, telnet y tftp.. 1.11.2. Limitaciones. . La aplicación está orientada a topología de redes cisco, cuya seguridad está controlada por listas de control de acceso.. . Se utilizará routers de marca cisco de 2600 y 3600.. . La topología de red se virtualizará por medio GNS3.. . La aplicación solo funcionaría sobre una red intranet.. 1.12. Factibilidad. 1.12.1. Factibilidad de desarrollo. 1.12.1.1. Factibilidad técnica. La especificación de software y hardware que se manejara dentro del proyecto está definida por las siguientes herramientas: 32.

(36) COMPUTADOR DE DESARROLLO Portatil Core i3, Windows 7.. Unidad de CD. 4 GB de Memoria Ram. Mouse Teclado. Disco Duro de 250 GB. Monitor. Router Cisco plataforma 3600. Router Cisco, TL-WDR3600. Router Cisco plataforma 3600. Router Cisco. Tabla 1. Factibilidad Técnica. Equipo de Desarrollo. SOFTWARE PROGRAMA. DESCRIPCION. Fedora Core 6. Plataforma o sistema operativo. Mysql. Sistema manejador de base de datos. Glassfish. Servidor de Aplicaciones. Eclipse. Interfaz de desarrollo Especificación del lenguaje de. J2ME, J2SE. programación. Tabla 2. Factibilidad Técnica. Software. EQUIPO MOVIL Memoria Combinada con 32 MB de Tri-banda; EGSM 900 GSM. memoria flash y 16 MB de memoria. 1800/1900 y EGSM 850. RAM.. 1800/1900. - Aproximadamente 8 MB de memoria disponible para el usuario. Ranura de expansión para tarjeta de. Bluetooth. memoria microSD (hasta 2 GB). 33.

(37) Soporta Juegos y aplicaciones. Pantalla Principal: QVGA 320 x 240,. Java MIDP 2.0, CLCD 1.0. hasta 16,7 millones de colores.. Tabla 3. Factibilidad Técnica. Equipo Móvil. 1.12.1.2. Factibilidad operativa. Para realizar el proyecto se cuenta con los siguientes Recursos Humanos (Ver tabla 4). FUNCION. EJECUTOR. Director Proyecto. Norberto Novoa. Desarrollador. Diana Katherine Prieto Restrepo. Desarrollador. Nelly Rocío Linares Cárdenas Tabla 4. Factibilidad operativa. 1.12.1.3. Factibilidad legal. El equipo Servidor se encuentra licenciado y las herramientas de software como J2SE, J2ME, GLASSFISH, Eclipse y MySql son open source y se encuentran licenciadas para fines educativos o académicos.. 1.12.1.4. Factibilidad económica. A continuación se presenta una tabla en la que se muestran los diferentes gastos que se tienen en cuenta en el proyecto, y se entrega un presupuesto total para la elaboración del mismo:. 34.

(38) Tabla 5. Factibilidad Economica. 1.13. Cronograma. Figure 1. Cronograma I. 35.

(39) Figure 2. Cronograma II. 2. FASE DE ANÁLISIS. 2.1. Requerimientos. En esta etapa, se define los procesos y procedimientos que se tiene en el escenario para el cual se va a desarrollar la aplicación. Esto permite identificar los casos concretos que debe automatizar el sistema, con el fin de aclarar el enfoque que quiere tener el cliente con el software. Como en cualquier proceso de desarrollo de software, es necesario definir las especificaciones y requerimientos con las que la aplicación debe contar. El objetivo del análisis de requerimientos es determinar las condiciones o capacidades que debe cumplir el sistema que se quiere diseñar, para satisfacer las necesidades de un grupo de usuarios. Para lograr esto utilizaremos la definición de requerimientos. Un requerimiento se puede entender como una descripción informal de las necesidades y deseos que tiene el usuario final respecto a un producto de software.. 36.

(40) 2.1.1. Requerimientos funcionales. Los requisitos funcionales son características requeridas del sistema, que expresan una capacidad de acción del mismo; una funcionalidad, generalmente expresada en una declaración en forma verbal. Nombre:. Denegar el protocolo FTP. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Fácil. 1.0. Descripción. El sistema debe tener una opción para denegar el protocolo FTP. La aplicación despliega la lista de acceso en la interfaz gráfica.. Nombre:. Permitir el protocolo FTP. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Media. 1.0. Descripción. La aplicación debe permitir activar el protocolo FTP en el servidor. La aplicación despliega la lista de acceso en la interfaz gráfica.. Nombre:. Denegar el protocolo TFTP. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Alta. 1.0. Descripción. Esta opción permite denegar el protocolo TFTP, que sirve para guardar los archivos de configuración startup-config y running-config de los routers. La aplicación despliega la lista de acceso en la interfaz grafica Tabla 6. Requerimientos. 37.

(41) Nombre:. Permitir el protocolo TFTP. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Alta. 1.0. Descripción. Esta opción activa el protocolo TFTP, aplicación una lista de acceso extendida en el router de plataforma 2600. La aplicación despliega la lista de acceso en la interfaz grafica Tabla 7. Requerimiento Permitir el protocolo TFTP. Nombre:. Denegar protocolo HTTP. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Alta. 1.0. Descripción. Esta opción deniega el acceso al protocolo HTTP, por medio de una lista de acceso extendida aplicada en el router de plataforma 3600. La aplicación despliega la lista de acceso en la interfaz grafica Tabla 8. Requerimiento Denegar protocolo HTTP. Nombre:. Permitir protocolo HTTP. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Alta. 1.0. Descripción. Esta opción permite activar el protocolo HTTP, aplicación una ACL extendida en el router 3600. La aplicación despliega la lista de acceso en la interfaz grafica Tabla 9. Requerimiento Permitir protocolo HTTP. Nombre:. Habilitar protocolo Telnet. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Alta. 1.0. Descripción. 38.

(42) Esta opción permite activar el acceso al protocolo Telnet del servidor. La aplicación despliega la lista de acceso en la interfaz grafica. Nombre:. Denegar el protocolo Telnet. Tipo: Funcional. Estado:. Prioridad:. Dificultad:. Versión:. Implementado. Alta. Alta. 1.0. Descripción. Esta opción permite denegar el acceso al protocolo Telnet. La aplicación despliega la lista de acceso en la interfaz grafica Tabla 10. Requerimiento Habilitar protocolo telnet. 2.2. Definición de Actores. Administrador La aplicación está diseñada para ser utilizada solo por los administradores de red, debido a que sus funcionalidades solo contienen actividades propias de este perfil. Con ello se encarga de permitir y denegar los 4 protocolos especificados. 2.3. Definición de Casos de Uso. 2.3.1. Listado de casos de uso. . Elegir plataforma CISCO y operación. . Enviar plataforma y operación. . Reenviar datos al Framework. . Conectar Framework. . Ejecutar Operación en Dispositivo. 39.

(43) 2.3.2. Documentación de Casos de uso. . Elegir Plataforma CISCO y operación. Elegir Plataforma CISCO Caso de Uso:. Elegir Plataforma CISCO. Actores:. Administrador de la red. Descripción:. Permite seleccionar entre la arquitectura CISCO2600 y 3600 para la ejecución de tareas.. Casos. de. Uso Enviar operación y plataforma. Asociados Flujo Principal:. El sistema móvil muestra un cuadro de selección con las opciones CISCO 2600 y 3600 para elegir alguna.. Propósito. Permite habilitar la plataforma en la que se ejecutarán las operaciones de configuración del Sistema.. Precondiciones:. Pasar el proceso de autenticación.. Prioridad:. Alta. Post-Condición:. Luego de Elegir la plataforma CISCO, el administrador de la red, selecciona del dispositivo móvil una de las siguientes opciones. Complejidad:. . Denegar protocolo Telnet. . Permitir protocolo Telnet. . Denegar protocolo Http. . Permitir protocolo Http. . Denegar protocolo TFTP. . Permitir Protocolo TFTP. . Denegar protocolo FTP. . Permitir protocolo FTP. Fácil Tabla 11. Caso de uso: Elegir plataforma CISCO. 40.

(44) . Enviar plataforma y operación. Enviar plataforma y operación Caso de Uso:. Enviar plataforma y operación. Actores:. Sistema Móvil. Descripción:. Permite enviar los datos de plataforma y operación, desde la aplicación móvil hacia la aplicación web.. Casos. de. Uso Elegir plataforma y operación, reenviar operación a framework. Asociados Flujo Principal: Propósito Precondiciones:. . El Sistema móvil realiza la conexión al sistema web. Enviar los datos seleccionados desde la aplicación móvil. . El Administrador de la red debe haber elegido la plataforma del dispositivo.. Excepciones:. E1. No es posible Abrir el Socket de conexión Se presenta cuando no se puede establecerla conexión de socket con el dispositivo remoto. El Sistema para configurar dispositivos despliega el mensaje “No es posible establecer Socket”. E2. No se pueden Obtener Flujos de Entrada Salida Se presenta cuando no se puede obtener objetos de lectura escritura a partir del socket de Comunicación.. Prioridad:. Alta. Post-Condición:. Se debe reenviar la información al Framework Networking.. Complejidad:. Difícil Tabla 12. Caso de uso: Enviar plataforma y operación. . Reenviar datos a Framework. Reenviar datos al Framework Caso de Uso:. Reenviar Datos. Actores:. Sistema Web. Descripción:. El sistema web reenvía los datos de plataforma y operación al. 41.

(45) Framework Networking. Casos. de. Uso Enviar operación y plataforma. Asociados. Conectar Framework. Flujo Principal:. El sistema web se conecta con el Framework Networking.. Propósito. Lograr el envío de mensajes al Framework Networking. Precondiciones:. La topología de redes debe encontrase activa. Excepciones:. E1. No es posible efectuar la Invocación Remota de Métodos. Se presenta cuando no es posible acceder al Framework. Se despliega mensaje de no conexión.. Prioridad:. Alta. Post-Condición:. Ejecutar operación en el dispositivo.. Complejidad:. Alta. . Conectar Framework. Conectar Framework Caso de Uso:. Conectar Framework. Actores:. Sistema Web. Descripción:. Permite al sistema web acceder al framework de configuración.. Casos. de. Uso Ejecutar operación en dispositivo. Asociados Flujo Principal: Propósito Precondiciones: Excepciones:. . El Sistema realiza la conexión al Framework vía Telnet.. Lograr conectividad con el Framework Networking . EL sistema web debe haber reenviado operaciones.. E1. No es posible Abrir el Socket de conexión Se presenta cuando no se puede establecerla conexión de socket con el dispositivo remoto. El sistema despliega el mensaje “No es posible establecer Socket”. E2. No se pueden Obtener Flujos de Entrada Salida Se presenta cuando no se puede obtener objetos de lectura. 42.

(46) escritura a partir del socket de Comunicación. El Sistema despliega el mensaje “No es posible obtener flujos Input Output” Prioridad:. Alta. Post-Condición:. Se debe desplegar la información sobre el estado de interfaces en la interfaz gráfica. Alta. Complejidad:. Tabla 13. Caso de uso: Conectar framework. . Ejecutar operación en dispositivo. Ejecutar Operación en Dispositivo Caso de Uso:. Ejecutar Operación en dispositivo. Actores:. Framework Networking. Descripción:. Permite ejecutar en el dispositivo seleccionado la operación indicada.. Casos. de. Uso Conectar Framework. Asociados Flujo Principal:. Ejecución de comandos en el dispositivo CISCO.. Propósito. Ejecutar la función seleccionada en el dispositivo. Precondiciones: Excepciones:. . Debe haber conectividad Ip con el dispositivo móvil. E1. No es posible efectuar conexión. Se presenta cuando no se puede acceder al dispositivo.. Prioridad:. Alta. Post-Condición:. Despliegue del resultado de configuración en el Framework. Complejidad:. Media Tabla 14. Caso de uso: Ejecutar operación en dispositivo. 43.