diana katherine prieto restrepo nelly...
TRANSCRIPT
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
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
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
1
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
2
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.
3
TABLA DE CONTENIDO
RESUMEN ........................................................................................................................... 7
ABSTRACT .......................................................................................................................... 8
INTRODUCCIÓN ............................................................................................................... 9
1. ORGANIZACIÓN, DEFINICIÓN Y ANÁLISIS ................................................... 11
1.1. TEMA ......................................................................................................................11
1.2. TITULO ....................................................................................................................11
1.3. OBJETIVOS ..............................................................................................................11
1.3.1. Objetivo general ..............................................................................................11
1.3.2. Objetivos específicos ......................................................................................11
1.4. DESCRIPCIÓN DEL PROBLEMA................................................................................. 12
1.5. PREGUNTA DE INVESTIGACIÓN ............................................................................... 13
1.6. JUSTIFICACIÓN ....................................................................................................... 13
1.7. MARCO TEÓRICO .................................................................................................... 16
1.7.1. Programación orientada a objetos .................................................................. 16
1.7.1.1. Diseño orientado a objetos ......................................................................... 17
1.7.2. Listas de control de acceso (ACL) ................................................................. 19
1.7.3. Métodos de conexión Remota RPCs y RMI .................................................. 20
1.7.4. TELNET (Tele Network - Tele Red) ............................................................. 21
1.8. MARCO CONCEPTUAL ............................................................................................. 21
1.8.1. Java ................................................................................................................ 21
1.8.1.1. Java Standard Edition ................................................................................. 22
1.8.2. Cisco .............................................................................................................. 23
1.8.3. Framework ..................................................................................................... 24
1.8.4. Middleware .................................................................................................... 24
1.8.5. Firewall .......................................................................................................... 25
1.9. MARCO LEGAL ....................................................................................................... 26
1.9.1. Ley 29 de 1990 .............................................................................................. 26
1.9.2. Ley 1273 de 2009, Ley de delitos informáticos en Colombia ....................... 27
1.9.3. Ley 603 de 2000 ............................................................................................ 27
1.10. METODOLOGÍA ....................................................................................................... 28
1.10.1. Características metodología RUP. .................................................................. 28
1.10.2. Ciclo de Vida.................................................................................................. 29
1.10.3. Fases ............................................................................................................... 29
1.10.4. Implementación del RUP para el proyecto .................................................... 31
1.11. ALCANCES Y LIMITACIONES .................................................................................... 32
1.11.1. Alcances ......................................................................................................... 32
1.11.2. Limitaciones ................................................................................................... 32
4
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. FASE DE ANÁLISIS ................................................................................................ 36
2.1. REQUERIMIENTOS .................................................................................................. 36
2.1.1. Requerimientos funcionales ........................................................................... 37
2.2. DEFINICIÓN DE ACTORES ....................................................................................... 39
2.3. DEFINICIÓN DE CASOS DE USO ............................................................................... 39
2.3.1. Listado de casos de uso .................................................................................. 39
2.3.2. Documentación de Casos de uso ................................................................... 40
2.3.3. Diagramas de casos de uso ............................................................................ 44
2.3.4. Modelo de Casos de Uso ............................................................................... 45
3. FASE DE DISEÑO ................................................................................................... 46
3.1. DEFINICIÓN DE CLASES .......................................................................................... 46
3.1.1. Definición de Clases Capa Vista .................................................................... 46
3.1.2. Definición de Clases Capa Controlador ......................................................... 47
3.1.3. Definición de Clases Capa Modelo ............................................................... 47
3.2. DIAGRAMAS DE SECUENCIA ................................................................................... 48
3.3. EJECUTAR OPERACIÓN ........................................................................................... 49
3.4. DIAGRAMAS DE COLABORACIÓN ........................................................................... 50
3.5. DIAGRAMA DE PAQUETES ....................................................................................... 52
3.6. MODELO DE BASE DE DATOS ................................................................................... 54
3.7. DIAGRAMA DE COMPONENTES ............................................................................... 55
3.8. DIAGRAMA EL DOMINIO ......................................................................................... 56
3.9. DIAGRAMA DE CLASES ........................................................................................... 57
4. FASE DE PRUEBAS ................................................................................................ 58
4.1. PROTOCOLO FTP .................................................................................................... 58
4.2. PROTOCOLO TFTP ................................................................................................. 59
4.3. PROTOCOLO TELNET .............................................................................................. 63
4.4. PROTOCOLO HTTP ................................................................................................. 65
CONCLUSIONES ............................................................................................................. 68
RECOMENDACIONES ................................................................................................... 69
REFERENCIAS ................................................................................................................. 70
5
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
6
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
7
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.
8
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.
9
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.
10
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.
11
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.
12
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
13
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:
14
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.
15
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.
16
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.
17
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.
18
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
19
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 DEITEL, Paul y Harvey. Java Como programar. México: Prentice Hall, 2008. pág. 20.
9 ACL: http://cesarcabrera.info/blog/%C2%BFcomo-funcionan-las-acl-en-cisco-i-conceptos/
20
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 little-
endian. 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
21
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.
22
“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. 12
BROSE, Gerald. Java Programming with CORBA. Advanced Techniques for Building Distributed
Applications. USA: Wiley Publishing, 2001. pág 13.
23
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
24
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
25
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
Definición de Middleware. Recuperado de: http://www.alegsa.com.ar/Dic/middleware.php 16
Que es un firewall. Recuperado de: http://www.desarrolloweb.com/articulos/513.php
26
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
27
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/autores-
invitados/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-dian-
software-colombia
28
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.
29
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.
30
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.
31
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
32
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:
33
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
J2ME, J2SE Especificación del lenguaje de
programación
Tabla 2. Factibilidad Técnica. Software
EQUIPO MOVIL
Tri-banda; EGSM 900 GSM
1800/1900 y EGSM 850
1800/1900
Memoria Combinada con 32 MB de
memoria flash y 16 MB de memoria
RAM.
- Aproximadamente 8 MB de memoria
disponible para el usuario.
Bluetooth Ranura de expansión para tarjeta de
memoria microSD (hasta 2 GB)
34
Soporta Juegos y aplicaciones
Java MIDP 2.0, CLCD 1.0
Pantalla Principal: QVGA 320 x 240,
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:
35
Tabla 5. Factibilidad Economica
1.13. Cronograma
Figure 1. Cronograma I
36
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.
37
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
38
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
39
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
40
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
Asociados
Enviar operación y plataforma
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
Denegar protocolo Telnet
Permitir protocolo Telnet
Denegar protocolo Http
Permitir protocolo Http
Denegar protocolo TFTP
Permitir Protocolo TFTP
Denegar protocolo FTP
Permitir protocolo FTP
Complejidad: Fácil
Tabla 11. Caso de uso: Elegir plataforma CISCO
41
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
Asociados
Elegir plataforma y operación, reenviar operación a framework
Flujo Principal: El Sistema móvil realiza la conexión al sistema web
Propósito Enviar los datos seleccionados desde la aplicación móvil.
Precondiciones: 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
42
Framework Networking.
Casos de Uso
Asociados
Enviar operación y plataforma
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
Asociados
Ejecutar operación en dispositivo
Flujo Principal: El Sistema realiza la conexión al Framework vía Telnet.
Propósito Lograr conectividad con el Framework Networking
Precondiciones: EL sistema web debe haber reenviado operaciones.
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 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
43
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.
Complejidad: Alta
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
Asociados
Conectar Framework
Flujo Principal: Ejecución de comandos en el dispositivo CISCO.
Propósito Ejecutar la función seleccionada en el dispositivo
Precondiciones: Debe haber conectividad Ip con el dispositivo móvil
Excepciones: 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
44
2.3.3. Diagramas de casos de uso
Definir Operación
Figure 3. Definir Operación
El administrador de la red primero debe elegir plataforma y operación en la aplicación
móvil, para que posteriormente ésta envíe los datos
Conectar Framework
Figure 4. Conectar Framework
El sistema web sólo puede reenviar la operación al framework networking, hasta que reciba
la operación desde el sistema móvil
Ejecutar Operación
Figure 5. Ejecutar Operación
45
Para que el Framework Networking ejecute la operación en el dispositivo, el sistema web
debe conectar primero el Framework
2.3.4. Modelo de Casos de Uso
Figure 6. Modelo de casos de uso
Inicialmente el administrador de la red elije plataforma y operación desde la aplicación
móvil, esto es prerrequisito para que los datos sean enviados del dispositivo móvil, hacia la
aplicación web. El sistema web una vez tiene los datos, realiza la conexión al Framework
Networking y le reenvía los datos, para que finalmente, él ejecute la operación en el
dispositivo señalado.
46
3. Fase de diseño
3.1. Definición de Clases
3.1.1. Definición de Clases Capa Vista
Clase MainActivity.
Descripción Colaboradores Representación
Clase Principal de la aplicación
Android, se encarga de realizar la
autenticación de usuario en el
servicio web. Y desplegar la
interfaz de operaciones.
Actividad2
Tabla 15. Clase MainActivity.
Clase Actividad2
Descripción Colaboradores Representación
Tiene toda la funcionalidad de
plataformas y operaciones.
MainActivityl
Tabla 16. Clase Actividad2
47
Clase Cisco
Descripción Colaboradores Representación
Se encarga de definir las
operaciones que puede realizar el
Servidor.
Usuario
Tabla 17. Clase Cisco
3.1.2. Definición de Clases Capa Controlador
Clase Usuario
Descripción Colaboradores Representación
Recibe los parámetros de
autenticación desde la aplicación
móvil.
UsuarioDAO
Tabla 18. Clase Usuario
3.1.3. Definición de Clases Capa Modelo
Clase UsuarioDAO
Descripción Colaboradores Representación
Define la consulta de autenticación
en la base de datos.
ConexionDAO
Tabla 19. Clase UsuarioDAO
48
Clase ConexionDAO
Descripción Colaboradores Representación
Realiza la conexión con la base de
datos y ejecuta la consulta.
UsuarioDAO
Tabla 20. Clase ConexiónDAO
3.2. Diagramas de Secuencia
Autenticación de Usuario
Figure 7. Secuencia: Autenticación de Usuario
El proceso de validación de usuario, inicia cuando el administrador de la red, ejecuta la
aplicación Spinner.apk y despliega el sistema móvil. La primera operación que realiza el
administrador de la red en el sistema móvil, es diligenciar los datos de usuario y contraseña
y al pulsar un botón de la interfaz gráfica, llama al método onClick, que toma un
49
argumento de tipo View, para procesar el evento. El sistema móvil instancia un objeto de
tipo SoapObject, para lograr el acceso remoto al sistema web. El objeto SoapObject tiene
dos argumentos; namespace y método. Así consigue invocar el método validacion_Usuario
del sistema web. Primero se instancia un objeto de tipo usuario, con el método
validar_User de la clase Usuario. Después, la clase Usuario, instancia los objetos de
persistencia ConexionDAO y UsuarioDAO y realiza la verificación de usuario, por medio
del método validar. Si el usuario existe, al sistema móvil es retornado un valor entero
positivo. Y a través del método startActivity es desplegada la actividad2, con las opciones
de configuración.
3.3. Ejecutar Operación
Figure 8. Secuencia: Ejecutar Operación
El sistema móvil despliega la interfaz de opciones de configuración, a partir del método
onCreate de la clase Actividad2. Lo primero que el administrador de red hace es elegir la
plataforma del dispositivo en la que quiere ejecutar operaciones. Esto lo logra por medio
del método onItemSelected, que toma los argumentos de tipo AdapterView y View. Los
adaptadores se utilizan para implementar listas desplegables. Después de elegir la
plataforma, el siguiente paso es seleccionar la operación a ejecutar. Se realiza el llamado a
la función onCheckedChanged de Actividad2, con un argumento int y otro RadioGroup.
50
Seleccionadas la plataforma y la operación, el envío de la orden de ejecución hacia el
servicio web, se consigue a través del evento onClickView. Un objeto SoapObject,
envuelve los datos de plataforma y operación, para posteriormente hacer el llamado al
método operation de la clase Cisco. La conexión del dispositivo de red, la realiza el
Framework Networking, a través de la llamada al método Input_Output; primero conecta la
dirección ip que llega como primer argumento string y después ejecuta la operación
establecida en el segundo argumento.
3.4. Diagramas de Colaboración
Validación de Usuario
Figure 9. Colaboración: Validación de Usuario
Descripción
1. El Administrador de la Red invoca la actividad principal del sistema móvil, la
actividad MainActivity, por medio de un botón que activa un evento de tipo View.
2. Un objeto de tipo SoapObject envuelve los datos de usuario y password en la clase
MainActivity.
3. MainActivity invoca el método validacion_Usuario del sistema web, el servicio
web Cisco. Los parámetros de la llamada son dos valores string, que corresponden a
usuario y password.
51
4. El servicio web Cisco, invoca el método validar_User de la clase Usuario, sin
argumentos.
5. La clase Usuario instancia un objeto de persistencia; ConexionDAO para acceder a
la base de datos.
6. La clase Usuario instancia el objeto de persistencia UsuarioDAO, para definir la
consulta a la base de datos.
7. UsuarioDAO invoca el método validar.
8. ConexionDAO invoca el método validar, con la consulta como parámetro string.
9. Si la consulta coincide con algún registro de la base de datos, devuelve un valor
entero positivo, el id del usuario. El valor entero es devuelto a la aplicación móvil.
10. Si el valor entero retornado, es positivo, una nueva actividad, Activity2, es
desplegada al administrador de la red, con todas las opciones de configuración para
plataforma y comando.
Ejecutar Operaciones
Figure 10. Colaboración: Ejecutar Operaciones
52
Descripción
1. El sistema móvil a través del método onCreate, con el parámetro Bundle, despliega
la Actividad2, con las opciones de plataforma y comando.
2. El administrador de red, elige la plataforma con el método onItemSelected, que
funciona como una lista desplegable y utiliza adaptadores de vista, controles
necesarios en éste tipo de objetos, para procesar eventos android.
3. Después de elegir la plataforma, se selecciona la operación a realizar. Para esto el
administrador de la red, elije una opción, invocando el método onCheckedChanged,
que tiene un argumento de tipo RadioGroup y otro entero.
4. El envío de los datos hacia el sistema web, tiene lugar en el evento onClickView
5. Actividad2 crea un objeto de tipo SoapObject para envolver los datos de plataforma
y comando, en valores string.
6. Los valores son enviados al sistema web, la clase Cisco, invocando el método
operation.
7. El sistema web conecta el Framework Networking, por medio de la clase
Input_Output y los valores string; dirección ip de alcance y comando de operación,
como argumentos.
8. El Framework Networking, accede a sus clases empaquetadas Cisco2600 o
Cisco3600, para ejecutar la operación en el dispositivo seleccionado.
3.5. Diagrama de paquetes
El proyecto integra dos aplicaciones que funcionan en conjunto; una aplicación servidor y
una aplicación móvil. La aplicación servidor está compuesta por tres paquetes de clases;
Presentacion, Logica y Persistencia. En la capa de presentación está el servicio Web, la
clase Cisco, desde el cual un Framework de configuración gráfico es invocado. La
aplicación móvil consta de un único paquete; com.example.spinner, con las clases
MainActivity y Actividad2.
53
Figure 11. Diagrama de paquetes
Descripción
1. La clase MainActivity de la aplicación móvil invoca el método validar_Usuario de
la clase Cisco, con dos argumentos de tipo string; el usuario y el password.
2. Se realiza un llamado a la clase Usuario del paquete Logica.
3. La clase Usuario instancia a UsuarioDAO, una clase de persistencia para establecer
consultas.
4. La clase Usuario instancia a ConexionDAO, una clase de persistencia para realizar
la conexión a la base de datos.
54
5. Después de la autenticación, la clase Actividad2 del sistema móvil invoca el
método operation, con dos argumentos string; la dirección ip de alcance y el
comando.
6. La clase Cisco realiza la conexión al Framework Networking, para ejecutar
operaciones en los dispositivos.
3.6. Modelo de base de datos
La aplicación tiene una base de datos Mysql, llamada proyecto, con una sola tabla;
autenticación. La tabla tiene tres campos; id de tipo entero, como clave primaria, user de
tipo varchar(40) y password de tipo varchar(40), para registrar los datos del administrador
de la red.
Figure 12. Modelo de BD
55
3.7. Diagrama de Componentes
Figure 13. Diagrama de Componentes
Inicialmente la aplicación móvil invoca métodos de la aplicación servidor. La aplicación
servidor recibe las solicitudes y se comunica con el Framework de redes, con el objetivo de
enviarle las operaciones solicitadas desde la aplicación móvil. Finalmente el Framework de
redes, conecta los dispositivos de enrutamiento y ejecuta las operaciones solicitadas desde
la aplicación web, y las despliega paso a paso en su interfaz gráfica
56
3.8. Diagrama el Dominio
Figure 14. Diagrama el Dominio
La aplicación móvil consta de dos actividades, una actividad principal; MainActivity y una
actividad secundaria Actividad2. La actividad principal interactúa con la clase Cisco, el
servicio Web, por medio de la intervención del administrador de la red. La clase Cisco en
el proceso de autenticación se relaciona con usuario, que a su vez llama a la clase
UsuarioDAO y a ConexionDAO. Toda la funcionalidad de operaciones, la realiza la clase
CISCO, en el método operation, para conectar el Framework y ejecutar los comandos.
57
3.9. Diagrama de Clases
Figure 15. Diagrama de Clases
La aplicación móvil está compuesta por MainActivity y Actividad2. La clase MainActivity
se encarga de realizar la autenticación en el servidor. La aplicación Actividad2 tiene las
opciones de configuración u operaciones a ejecutar en el dispositivo de red. También tiene
una lista desplegable para seleccionar la plataforma de dispositivos. La aplicación servidor
tiene el servicio web, la clase Cisco, con dos métodos; Validar_Usuario y Operation. La
primera interacción es del administrador de la red con la aplicación móvil, la cual invoca el
método validar_usuario del servicio web, donde se instancia la clase usuario, para realizar
la conexión a la base de datos por medio de las clases UsuarioDAO y ConexionDAO. Si la
autenticación es exitosa, se activa la clase Actividad2 en el dispositivo móvil, con las
diferentes opciones de configuración. La Actividad2 se comunica con el método operation
de la clase Cisco, que recibe dos parámetros de tipo string; ip_scope y command.
58
4. Fase de pruebas
4.1. Protocolo FTP
Pruebas ejecutar servicios
Autor: Rocío Linares Marca del router 2600
Protocolo: FTP
Descripción: Se pretende permitir y denegar el protocolo FTP desde la aplicación móvil
a la topología de red montada en GNS3.
Acción: Resultado Estado
Seleccionar la
opción permitir
FTP
En el computador real se podrá visualizar que podrá
conectarse por consola al FTP de la máquina virtual. Con
ello se podrá realizar el correcto traspaso de archivos entre
ambos equipos.
OK
Seleccionar la
opción denegar
FTP
No se pudo conectar por medio de la consola al servidor ftp
de la máquina virtual. OK
Errores: No se encontraron
Correcciones No se hacen.
Figure 16. Pruebas Protocolo FTP
59
Procedimiento:
El metodo que se empleo para verificar si existia conexión ftp, es desde el equipo real con
dirección IP 192.168.43.1 por medio de la consola conectarse al equipo de la maquina
virtual que posee la dirección 10.0.0.10, ejecutando el comando
ftp 10.0.0.10
De esta forma se retornó un conectado a la dirección solicitada en este caso a la 10.0.0.10.
Luego se envía un archivo local y se envía por medio del protocolo ftp a la maquina
remota. Para verificar que podemos utilizar correctamente el servidor ftp.
Figure 17. Consola Servidor ftp
4.2. Protocolo TFTP
Pruebas ejecutar servicios
Autor: Rocío Linares Marca del router 2600
Protocolo: TFTP
Descripción: Se pretende permitir y denegar el protocolo TFTP desde la aplicación
móvil a la topología de red montada en GNS3.
60
Acción: Resultado Estado
Seleccionar la
opción permitir
TFTP
Por medio del router conectado a la red del equipo real,
nos conectamos al servidor tftp y este nos abrió la
conexión.
OK
Seleccionar la
opción denegar
TFTP
Al realizar la conexión por medio del router este nos
retornó un error por lo cual no permite realizar la
conexión.
OK
Errores: No se encontraron
Correcciones No se hacen.
Figure 18. Pruebas Protocolo TFTP
Procedimiento:
El método que se utilizo para verificar si se tiene permiso sobre el protocolo tftp es por
medio del router conectado al equipo real, desde este se realizó una copia de la
configuración actual del router al servidor tftp, con ello se ejecutó el comando:
copy startup-config tftp
Si la conexión falla nos presentará el mensaje:
61
Figure 19: Consola Router Real
Si la conexión la realiza correctamente nos enviará el mensaje que fue copiado:
Figure 20: Consola Router Real
Al abrir el servidor tftp este también se pudo visualizar cada uno de los procesos que se
hace sobre el servidor.
62
Figure 21. Cisco TFTP
De esta forma encontramos el archivo generado sobre la carpeta del servidor tftp:
Figure 22. Carpeta Servidor TFTP
63
4.3. Protocolo Telnet
Pruebas ejecutar servicios
Autor: Diana Prieto Marca del router 3600
Protocolo: Telnet
Descripción: Se pretende permitir y denegar el protocolo Telnet desde la aplicación
móvil a la topología de red montada en GNS3.
Acción: Resultado Estado
Seleccionar la
opción permitir
Telnet
Al entrar por medio de la consola se visualiza que se
puede conectar al servidor Telnet. OK
Seleccionar la
opción denegar
Telnet
Al entrar en la consola se puede visualizar que mostrará
un error de conexión. OK
Errores: No se encontraron
Correcciones No se hacen.
Figure 23. Pruebas Protocolo Telnet
Procedimiento:
El método que se empleo para verificar que pudiéramos acceder al servidor Telnet, fue por
medio de la consola cmd, con ello se colocó el comando:
telnet 10.0.0.10
De esta forma accedemos al servidor telnet del equipo de la maquina virtual que posee la
dirección ip 10.0.0.10.
Al denegar el protocolo este indica que hubo error al conectar:
64
Figure 24. Consola, servidor telnet
Si al contrario se ha permitido utilizar el protocolo Telnet, este nos permitirá el acceso a la
conexión al servidor telnet, posteriormente se debe ingresar los datos del usuario con su
contraseña:
Figure 25. Consola, acceso al servidor telnet
Si se tiene conocimiento de la contraseña así podremos entrar correctamente al servidor
telnet:
65
Figure 26. Servidor Telnet
4.4. Protocolo HTTP
Pruebas ejecutar servicios
Autor: Diana Prieto Marca del router 3600
Protocolo: HTTP
Descripción: Se pretende permitir y denegar el protocolo HTTP desde la aplicación
móvil a la topología de red montada en GNS3.
Acción: Resultado Estado
Seleccionar la
opción permitir
HTTP
Al entrar por medio del explorador del equipo real se
conectó a la dirección sobre una página propia de la
máquina virtual de esta forma se visualizó aquella pagina
OK
Seleccionar la
opción denegar
HTTP
Al entrar por medio del explorador del equipo real se
conectó a la dirección sobre una página propia de la
máquina virtual se visualizó que la pagina no existe.
OK
Errores: No se encontraron
66
Correcciones No se hacen.
Figure 27. Pruebas Protocolo HTTP
Procedimiento:
Se ingresó al explorador del equipo real y se accedió a la dirección 10.0.0.10/index.php
esta página propia del equipo virtual con ello si el servicio se deniega este mostrara que la
pagina no carga o no está disponible:
Figure 28. Explorador, sin acceso HTTP
En el caso que se permita el protocolo http este nos permitirá la conexión a la página y se
visualizará ya como tal el contenido de la página que se seleccionó:
67
Figure 29. Explorador, acceso a HTTP
68
Conclusiones
Al analizar los procesos que llevan a cabo la mayoría de administradores de redes
en las organizaciones se detectaron algunas inconsistencias tal y como los errores
de sintaxis en las configuraciones de los enrutadores, lo cual hacia que en ocasiones
tuvieran que hacer un retrabajo. Esta inconsistencia se solucionó implementando el
framework de configuración de listas de acceso extendidas, permitiendo la
automatización de tareas, reducción de tiempos y recursos.
El uso de GNS3 permite que se pueda trabajar con IOS de routers cisco reales,
agregando todas las características y potencialidades de un router real, sin tener
problema de comandos no reconocidos o no funcionales, es una buena herramienta
para los administradores de red ya que es de open source y puede ser utilizado en
múltiples sistemas operativos.
A través de GNS3, se logró virtualizar de la forma más real posible la red
planteada, debido a que utiliza los recursos que manejaría una red real, en este caso
se logró evidenciar el uso del router, permitiendo así acceder a su configuración sin
necesidad de uno en físico, ya que proporciona la mejor forma para realizar
simulaciones muy cercanas a la realidad, por ello es una muy buena herramienta,
que ante todo reduce el costo de implementación que constituye una red. Además es
libre, fácil de instalar y de usar, que en ámbito educativo apoyaría bastante ya que
es un gran acercamiento para conocer los diferentes elementos y su forma de
configuración de una red.
Con el uso del dispositivo móvil se ofrece un método de acceso, de fácil transporte
por su tamaño, que al acceder por medio de éste para configurar una red, facilita en:
cuestiones de movilidad, de acceso rápido a los elementos de la red sin necesidad
de estar físicamente frente a estos, flexibilidad de la configuración, acceso desde
cualquier lugar, entre otros, ya que como bien sabemos, una red debe permanecer
inmóvil en el sitio donde se encuentra.
69
Recomendaciones
Se recomienda profundizar en los aspectos y conceptos que abarcan las ACL’s con
ello conocer en que ámbito y de qué forma actualmente se utilizan, de esta manera
así entender el objetivo del proyecto, y poder aplicar más del uso de las ACL’s ya
que existen más funcionalidades de ellas en otros protocolos, y en las
configuraciones en general de la red.
Se recomienda investigar métodos para extender la distancia para la conexión entre
la aplicación móvil y el servidor web, ya que actualmente solo se puede manejar al
nivel de una intranet.
Se recomienda averiguar aspectos relacionados con la seguridad, antes de realizar la
conexión con el router, ya que actualmente se realiza un manejo básico, que es un
usuario y contraseña, pero es importante no dejar tan vulnerable una aplicación que
configura una red completa. Junto con ello también construir un sistema de
autenticación que permita la creación de usuarios y permisos a los administradores
de la red, para que cada uno pueda acceder a ciertas configuraciones que poseen los
router actualmente, y no dejar el manejo a un solo tipo de usuario
70
Referencias
CCNA Exploration 4.0. Acceso a la WAN. 2008. Módulo 4. Cap 5.
Amin, M; Ho, KH; Pavlou, G; Howarth, M; (2009) .A Closed-Loop Control Traffic
Engineering System for the Dynamic Load Balancing of Inter-AS Traffic JOURNAL OF
NETWORK AND SYSTEMS MANAGEMENT
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
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
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.
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
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.
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.
71
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/
RUSTY, Harold. Java Network Programming. USA: O’Reilly Media ,2000. pág. 520
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.
Cisco Systems. Recuperado de: http://es.wikipedia.org/wiki/Cisco_Systems
Definición de Framework. Recuperado de: http://www.alegsa.com.ar/Dic/framework.php
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
Ley 29 de 1990 Nivel Nacional, Recuperado de:
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=254
Ley de delitos informáticos en Colombia, Recuperado de:
http://www.deltaasesores.com/articulos/autores-invitados/otros/3576-ley-de-delitos-
informaticos-en-colombia
Ley 603 de 2000, Disponible en: http://www.corventasdecolombia.com.co/ley-603-
derechos-de-autor-dian-software-colombia
72
Metodología RUP, en línea http://ftp.itmerida.mx/Mario/Gestiondeproyectos.pdf
73
ANEXOS
74
MANUAL DEL PROGRAMADOR
MANUAL DE USUARIO FRAMEWORK PARA CONFIGURAR LISTAS DE ACCESO EXTENDIDAS EN ROUTERS CISCO DESDE UN DISPOSITIVO MOVIL FRAMEWORK PARA CONFIGURAR LISTAS DE ACCESO EXTENDIDAS EN ROUTERS CISCO DESDE UN DISPOSITIVO MÓVIL
2015
NELLY ROCIO LINARES CARDENAS
DIANA KATHERINE PRIETO RESTREPO
75
INTRODUCCIÓN
Este manual le permitirá aprender de forma fácil y sencilla el manejo de
la aplicación de dispositivo móvil ACLs, basada en la funcionalidad
implementada en el “FRAMEWORK PARA CONFIGURAR LISTAS DE
ACCESO EXTENDIDAS EN ROUTERS CISCO DESDE UN DISPOSITIVO
MOVIL”. Contiene el paso a paso de cómo se debe instalar y configurar
para el correcto funcionamiento.
76
REQUISITOS MINIMOS DE SOFTWARE Y HARDWARE
A continuación se presentan los requerimientos mínimos de software y
hardware que el usuario debe tener en cuenta para el correcto
funcionamiento de la aplicación móvil.
Requisitos mínimos del equipo móvil:
EQUIPO MOVIL
Tri-banda; EGSM 900 GSM
1800/1900 y EGSM 850 1800/1900
Memoria Combinada con 32 MB de
memoria flash y 16 MB de memoria RAM.
- Aproximadamente 8 MB de memoria
disponible para el usuario.
Bluetooth Ranura de expansión para tarjeta de
memoria microSD (hasta 2 GB)
Soporta Juegos y aplicaciones
Java MIDP 2.0, CLCD 1.0
Pantalla Principal: QVGA 320 x 240,
hasta 16,7 millones de colores.
Requisitos mínimos de Hardware
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
77
Requisitos mínimos de Software:
SOFTWARE
PROGRAMA DESCRIPCION
Windows Server 2008 Plataforma o sistema operativo
Mysql Sistema manejador de base de datos
Glassfish Servidor de Aplicaciones
Eclipse Interfaz de desarrollo
J2ME, J2SE Especificación del lenguaje de
programación
PASOS A SEGUIR:
1. Se debe descargar el archivo ACLs.apk suministrado por el
administrador de red en el dispositivo móvil.
78
2. Se debe abrir el archivo en el dispositivo móvil (Nota: Se debe
tener en cuenta que el sistema operativo debe ser Android 2.2 o
superior)
79
3. Una vez se ha seleccionado la opción de abrir, se procede a
instalar la aplicación móvil.
80
4. Se espera unos segundos hasta completar la instalación de la
aplicación en el dispositivo móvil.
81
5. Para verificar la instalación se puede buscar en el dispositivo móvil
en las aplicaciones instaladas ya sea por fecha o por nombre.
82
6. Al abrir la aplicaciòn, lo primero que se visualiza es un medio de
autenticación de usuarios para el acceso al control de listas de
acceso sobre los routers y protocolos definidos.
83
7. Se ingresan los datos de usuario y contraseña suministradas por
el administrador de red.
84
8. Una vez validada la información de usuario, se despliega un menú
el cual contiene dos plataformas (routers) para configuración y
manejo de listas de acceso.
La plataforma 2600 habilita los servicios de Permitir y Denegar los
protocolos FTP y TFTP.
La plataforma 3600 habilita los servicios de permitir y denegar los
protocolos TELNET y HTTP.
85
Según la plataforma y servicio que se escoja, se procede a
seleccionar el botón Enviar y se inicia lo configuración automática
de listas de acceso sobre el protocolo seleccionado.
Si la comunicación es exitosa, en pantalla se empezará a ejecutar
la configuración por protocolo establecidas de forma automática
teniendo en cuenta la lista de acceso habilitada para cada servicio.
86
MANUAL DEL PROGRAMADOR FRAMEWORK PARA CONFIGURAR LISTAS DE ACCESO EXTENDIDAS EN ROUTERS CISCO DESDE UN DISPOSITIVO MOVIL
Diana Katherine Prieto Restrepo Nelly Rocío Linares Cárdenas 12/08/2015
87
INTRODUCCIÓN
El presente manual se hace con el objetivo de dar a conocer al
interesado la estructura del proyecto titulado “Framework para
configurar listas de acceso extendidas en routers Cisco desde un
dispositivo móvil”, revisando su la configuración de la topología de red y
las clases empleadas.
1. Usuarios
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. Configuración Topología de Red
Para que la aplicación móvil se pueda ejecutar, es necesario disponer de
una topología de red y un servidor. Para hacer dicha comunicación se
simula tener un equipo local en un host que se encuentra dentro de la
misma área de cubrimiento, por esto, es necesario tener una máquina
virtual con un sistema operativo como por ejemplo lo es Windows XP.
88
Figura 1. Máquina virtual
Al instalar la máquina virtual, ésta por defecto nos crea dos conexiones
de red las cuales se deben configurar para establecer la comunicación
entre el servidor, la topología y la aplicación móvil.
Figura 2. Conexiones de Red Virtuales y Real
Se procede a configurar la conexión de Red inalámbrica, así como
también las conexiones de red que han sido creadas por la máquina
89
virtual, cabe resaltar que se deben asignar direcciones IP válidas y
según esto, se podrá definir mascar de subred y puerta de enlace
predeterminada en caso de ser necesario.
Figura 3. Configuración Red Inalámbrica
90
Figura 4. Configuración de Red VMnet1
91
Figura 5. Configuración de Red VMnet8
Es necesario instalar GNS3 para realizar la simulación de la topología de
red a implementar teniendo en cuenta que las plataformas con las que
se van a trabajar son Router Cisco 2600 y Router Cisco 3600. La
topología se realiza de manera sencilla en donde se simula el equipo
real y el virtual.
92
Figura 6. Topología de Red en GNS3
En cada router cisco se debe realizar la configuración de las direcciones
IP asignadas previamente, así como también definir la interface por el
cual trabajara.
Figura 7. Configuración Router GNS3
93
Figura 8. Configuración de plataformas en GNS3
3. Definición de Clases
Clases Capa Vista
Clase MainActivity: Clase Principal de la aplicación Android, se
encarga de realizar la autenticación de usuario en el servicio web.
Y desplegar la interfaz de operaciones.
Clase Actividad2: Tiene toda la funcionalidad de plataformas y
operaciones.
Clase Cisco: Se encarga de definir las operaciones que puede
realizar el Servidor.
Clases Capa Controlador
Clase Usuario: Recibe los parámetros de autenticación desde la
aplicación móvil.
94
Clases Capa Modelo
Clase UsuarioDAO: Define la consulta de autenticación en la base
de datos.
Clase ConexionDAO: Realiza la conexión con la base de datos y
ejecuta la consulta.
4. Descripción General de Procesos en Clases
Autenticación de Usuario
El Administrador de la Red invoca la actividad principal del sistema
móvil, la actividad MainActivity, por medio de un botón que activa
un evento de tipo View.
Un objeto de tipo SoapObject envuelve los datos de usuario y
password en la clase MainActivity.
MainActivity invoca el método validacion_Usuario del sistema web,
el servicio web Cisco. Los parámetros de la llamada son dos
valores string, que corresponden a usuario y password.
El servicio web Cisco, invoca el método validar_User de la clase
Usuario, sin argumentos.
La clase Usuario instancia un objeto de persistencia; ConexionDAO
para acceder a la base de datos.
La clase Usuario instancia el objeto de persistencia UsuarioDAO,
para definir la consulta a la base de datos.
UsuarioDAO invoca el método validar.
ConexionDAO invoca el método validar, con la consulta como
parámetro string.
Si la consulta coincide con algún registro de la base de datos,
devuelve un valor entero positivo, el id del usuario. El valor entero
es devuelto a la aplicación móvil.
Si el valor entero retornado, es positivo, una nueva actividad,
Activity2, es desplegada al administrador de la red, con todas las
opciones de configuración para plataforma y comando.
95
Ejecutar Operación
El sistema móvil a través del método onCreate, con el parámetro
Bundle, despliega la Actividad2, con las opciones de plataforma y
comando.
El administrador de red, elige la plataforma con el método
onItemSelected, que funciona como una lista desplegable y utiliza
adaptadores de vista, controles necesarios en éste tipo de objetos,
para procesar eventos android.
Después de elegir la plataforma, se selecciona la operación a
realizar. Para esto el administrador de la red, elije una opción,
invocando el método onCheckedChanged, que tiene un argumento
de tipo RadioGroup y otro entero.
El envío de los datos hacia el sistema web, tiene lugar en el
evento onClickView
Actividad2 crea un objeto de tipo SoapObject para envolver los
datos de plataforma y comando, en valores string.
Los valores son enviados al sistema web, la clase Cisco, invocando
el método operation.
El sistema web conecta el Framework Networking, por medio de la
clase Input_Output y los valores string; dirección ip de alcance y
comando de operación, como argumentos.
El Framework Networking, accede a sus clases empaquetadas
Cisco2600 o Cisco3600, para ejecutar la operación en el
dispositivo seleccionado.
La aplicación móvil está compuesta por MainActivity y Actividad2. La
clase MainActivity se encarga de realizar la autenticación en el servidor.
La aplicación Actividad2 tiene las opciones de configuración u
operaciones a ejecutar en el dispositivo de red. También tiene una lista
desplegable para seleccionar la plataforma de dispositivos. La aplicación
servidor tiene el servicio web, la clase Cisco, con dos métodos;
Validar_Usuario y Operation. La primera interacción es del
administrador de la red con la aplicación móvil, la cual invoca el método
validar_usuario del servicio web, donde se instancia la clase usuario,
para realizar la conexión a la base de datos por medio de las clases
UsuarioDAO y ConexionDAO. Si la autenticación es exitosa, se activa la
clase Actividad2 en el dispositivo móvil, con las diferentes opciones de
configuración. La Actividad2 se comunica con el método operation de la
96
clase Cisco, que recibe dos parámetros de tipo string; ip_scope y
command.
5. Modelo de Base de Datos
La aplicación tiene una base de datos Mysql, llamada proyecto, con una
sola tabla; autenticación. La tabla tiene tres campos; id de tipo entero,
como clave primaria, user de tipo varchar(40) y password de tipo
varchar(40), para registrar los datos del administrador de la red.