Agente de software que facilite la administración de la red institucional de la ESIME Zacatenco

INSTITUTO POLIT ´

ECNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERIA MEC ´

ANICA Y EL´

ECTRICA

UNIDAD PROFESIONAL ADOLFO L ´

OPEZ MATEOS

AGENTE DE SOFTWARE QUE FACILITE LA

ADMINISTRACI ´

ON DE LA RED

INSTITUCIONAL DE LA ESIME

ZACATENCO.

TESIS

QUE PARA OBTENER EL T´ITULO DE:

INGENIER´IA EN COMUNICACIONES Y ELECTR ´

ONICA

P R E S E N T A N

NIEVES D´IAZ GERARDO

RIVERO PINEDA SA ´

UL

ASESOR METODOL ´

OGICO

M. EN C. GENARO ZAVALA MEJ´IA

ASESORES T´

ECNICOS

´Indice general

1.

DEFINICI ´

ON DEL PROYECTO.

9

1.1.

Definici´on del problema.

1.2.

Justificaci´on.

1.3.

Objetivos.

1.4.

Estado del arte.

1.4.1.

NAC (Network Access Control).

2.

AN ´

ALISIS.

13

Modelado del negocio.

2.1.1.

Modelo de casos de uso del negocio.

2.1.2.

Modelo de objetos del negocio.

2.2.

Captura de requisitos.

2.2.1.

Requerimientos del usuario.

2.2.2.

Especificaciones funcionales.

2.3.

Alternativas de soluci´on.

2.4.

Funcionamiento del sistema propuesto.

2.4.1.

Formas de accesar al conmutador.

2.5.

Plataformas de desarrollo.

3.

DISE ˜

NO.

28

Diagrama de componentes.

3.2.

Diagrama de paquetes.

3.3.

Diagrama de clases de “Base de datos”.

3.4.

Diagrama de clases de “Conmutador”.

4.2.1.

Clase Comandos.

4.2.2.

Clase Recupera.

4.3.

Interfaz.

4.3.1.

Diagrama de flujo del evento verificaActionPerformed.

4.3.2.

Diagrama de flujo del evento despliegaActionPerformed.

4.3.3.

Diagrama de flujo del evento analizaActionPerformed.

4.3.4.

Diagrama de flujo del evento desbloqueaActionPerformed.

Diagrama de flujo del m´etodo comparador.

5.

FASE DE PRUEBAS.

54

Interfaz.

5.2.

Verificaci´on de direcciones IP.

5.3.

Desplegar informaci´on actual del conmutador.

5.4.

Detecci´on de una computadora no registrada en la base de datos.

CONCLUSIONES.

59

TRABAJOS A FUTURO.

60

El Proceso Unificado de Rational (RUP).

A.2.

Redes.

A.2.1.

El modelo OSI.

A.2.2.

Dispositivo de red de la capa de enlace de datos: Switch o

conmutador.

A.2.3.

Protocolo IPv4.

A.2.4.

Protocolo ARP.

A.2.5.

Convertir direcciones IP en direcciones de capa de enlace

de datos.

A.3.

Sockets.

B. C´odigo fuente. 75 B.1.

Clase ConectDB.

B.2.

Clase Comandos.

B.3.

Clase Recupera.

B.4.

Clase GUI.

C. Tabla de Asignaciones de Direcciones IP est´aticas en la Red de ESIME

´Indice de figuras

1.1. Algunos virus informaticos, causa de la alteraci´on de nuestra informaci´on . . 11

1.2. E-mail, Internet y Wireless . . . 11

1.3. Diagrama del funcionamiento de sistema de seguridad NAC. . . 12

2.1. Modelo de caso de uso de negocio donde se visualizan los procesos que se llevan a cabo dentro de la red institucional. . . 14

2.2. Modelo de objeto del primer caso de uso de negocio donde se visualiza el proceso que lleva a cabo el usuario y el conmutador. . . 14

2.3. Modelo de objeto del segundo caso de uso de negocio donde se visualiza el proceso que lleva a cabo el agente cuando autentica a una computadora que intenta acceder a la red del instituto. . . 15

2.4. Diagrama general del sistema. . . 18

2.5. Diagrama espec´ıfico. . . 19

2.6. Nombre y selecci´on de la conexi´on. . . 20

2.7. Selecci´on de protocolo Telnet junto con la IP del conmutador y el puerto 23. 21 2.8. Par´ametros a configurar. . . 21

2.9. Login. Se introducen el usuario y contrase˜na. . . 22

2.10. L´ınea de comandos lista para administrar el switch. . . 22

2.11. Apertura del explorador. . . 23

2.12. Solicitud de nombre de usuario y contrase˜na. . . 24

2.13. Consola administrativa del switch. . . 24

2.14. Introducci´on de datos del sistema destino. . . 25

2.15. Nombre del usuario y contrase˜na. . . 26

2.16. Consola administrativa del switch. . . 26

3.1. Diagrama de componentes. . . 29

3.2. Diagrama de paquetes. . . 30

3.3. Diagrama de clases “Base de Datos”. . . 31

4.4. Diagrama de flujo correspondiente al evento verificaActionPerformed, de la

clase GUI. . . . 48

4.5. Diagrama de flujo correspondiente al evento despliegaActionPerformed, de la clase GUI. . . . 49

4.6. Diagrama de flujo correspondiente al evento analizaActionPerformed, de la clase GUI. . . . 51

4.7. Diagrama de flujo correspondiente al evento desbloqueaActionPerformed, de la clase GUI. . . . 52

4.8. Diagrama de flujo correspondiente al m´etodo comparador, de la claseGUI. . 53

5.1. Interfaz gr´afica de usuario. . . 54

5.2. Conmutador existente y funcionando. . . 55

5.3. El conmutador no se encuentra operando o la direcci´on IP no es v´alida. . . . 55

5.4. Informaci´on actual del conmutador. . . 56

5.5. Nueva computadora conectada al puertofe.1.7 . . . 56

5.6. Desconexi´on de una computadora conectada al puerto fe.1.1 . . . 57

5.7. Puerto fe.1.1 bloqueado. . . 58

5.8. Introducci´on del puerto a desbloquear. . . 58

5.9. Puerto fe.1.1 desbloqueado. . . 58

A.1. Dos host en una misma red envian una se˜nal al mismo lo cu´al provoca una colisi´on. . . 65

A.2. Switch de 24 puertos, por lo tanto tiene 24 dominos de colisi´on. . . 66

A.3. Conexi´on directa de un switch y cuatro host (acceso dedicado). . . 67

A.4. Modo de transmisi´on full-duplex (2 sentidos). . . 67

A.5. Encabezado del protocolo IPv4. . . 69

A.6. Tarjeta de red. . . 70

A.7. Solicitud enviada de un host 1 a un host 2 para conocer la direcci´on Ethernet del host 2 (destino) a trav´es de su direccion IP. . . 71

A.8. Tabla cach´e ARP se va llenando autom´aticamente a medida que se realizan nuevas peticiones. . . 71

A.9. Modelo Cliente-Servidor . . . 72

A.10.Proceso que se lleva a cabo en la comunicaci´on entre un cliente y un servidor usando sockets. . . 74

´Indice de cuadros

2.1. Comparaci´on de las posibles alternativas de soluci´on. . . 17

2.2. Comparaci´on de algunos lenguajes de programaci´on considerados a usar. . . 27

3.1. Descripci´on de los atributos de la clase ConectDB. . . 31

3.2. Descripci´on de los m´etodos de la clase ConectDB. . . 32

3.3. Descripci´on de las clases del paquete “Conmutador”. . . 33

3.4. Descripci´on de los atributos de la clase Comandos. . . 33

3.5. Descripci´on de los m´etodos de la clase Comandos. . . 34

3.6. Descripci´on de los atributos de la clase Recupera. . . 34

3.7. Descripci´on de los m´etodos de la clase Recupera. . . 35

3.8. Descripci´on de los atributos de la clase GUI. . . 37

3.9. Descripci´on de los atributos de la clase GUI (continuaci´on). . . 38

3.10. Descripci´on de los atributos de la clase GUI (continuaci´on). . . 39

3.11. Descripci´on de los m´etodos de la clase GUI. . . 39

Resumen del proyecto.

El agente de software desarrollado permite administrar conmutadores de la marca Enterasys de la Serie A con el fin de dar acceso o denegarlo a computadoras que quieran conectarse a una red Ethernet, verificando la existencia o ausencia de su direcci´on MAC en una base de datos. Si existe, se da acceso a la red a la computadora, en caso contrario se procede a bloquear el puerto del conmutador en donde se encuentra conectada, y se desbloquea cuando sea necesario.

Cap´ıtulo 1

DEFINICI ´

ON DEL PROYECTO.

1.1.

Definici´

on del problema.

En la actualidad, la red de la ESIME Zacatenco cuenta con diversos problemas, en particular el control de acceso a computadoras a nivel de la red cableada o ethernet, originando con-flictos entre hosts con IP designada y aquellos usuarios externos que intentan entrar a la red utilizando una IP ajena, d´ando lugar a conflictos de seguridad ya que una computadora no autorizada toma una direcci´on que no le pertenece. Por otra parte, en la universidad no hay forma de detectar el hosts en conflicto y en dado caso, bloquearle el acceso a la red ya que no se cuenta con ninguna herramienta que controle el acceso e identifique los que no est´an autorizados.

1.2.

Justificaci´

on.

Hoy en d´ıa, no se cuenta con una herramienta que permita una ´optima administraci´on de la red de datos institucional que permita una r´apida y confiable identificaci´on de los equipos conectados a la red y control de acceso. En este trabajo se desarrollar´a un agente de soft-ware programado en Java que estar´a monitoreando la red, con la caracter´ıstica principal de controlar el acceso a la red, aplicando pol´ıticas de seguridad como son bloqueo de puertos de las computadoras no identificadas y obtenci´on de datos de ´estas para validar cu´al es la autorizada.

1.3.

Objetivos.

Bloquear el puerto correspondiente a la computadora que no est´e autorizada para acceder a la red, comparando su direcci´on MAC con otra contenida en una base de datos ya establecida.

Desarrollar una interfaz gr´afica para que el administrador pueda obtener datos del con-mutador tales como puertos en uso, puertos habilitados o deshabilitados, direcciones MAC de las computadoras conectadas, determinar si un conmutador en particular est´a encendido y habilitar puertos manualmente.

1.4.

Estado del arte.

En esta parte se dar´a a conocer una de las tecnolog´ıas existentes en el mercado que tiene un comportamiento similar al que lleva a cabo el presente proyecto. Se trata de una soluci´on de seguridad que controla el acceso a una red en base al cumplimiento de ciertos requisitos que deben cumplir cada miembro perteneciente a la red.

1.4.1.

NAC (Network Access Control).

El Control de Acceso a la Red es una soluci´on de seguridad para sistemas que garantiza el acceso a usuarios ´o dispositivos que cumplan con las posturas de seguridad adecuadas, permitiendo a los usuarios finales auto remediar las violaciones detectadas y reducir las vulnerabilidades de la red, permitiendo el acceso a usuarios y dispositivos sanos.[1][2]

Posturas.

Las posturas m´as importantes consideradas en este sistema de seguridad se mencionan a continuaci´on[2]:

Software autorizado. Solamente estar´a disponible el software adecuado, esto es, depen-diendo del rol de trabajo y necesidades de cada usuario.

Antivirus Institucional. Se debe de contar con un antivirus instalado, actualizado y en ejecuci´on.

Sistema Operativo. El sistema con el que se cuente en la computadora debe estar actu-alizado.

Firewall personal. Se debe de tener el firewall activado.

Service Pack. Se debe de contar con el Service Pack de nuestro sistema autorizado y actualizado a la ultima versi´on.

Figura 1.1:Algunos virus informaticos, causa de la alteraci´on de nuestra informaci´on

Correo Institucional. Internet.

Red inal´ambrica. Sitios de colaboraci´on.

Figura 1.2:E-mail, Internet y Wireless

Procedimiento sobre el funcionamiento del sistema NAC.

3. Evaluar los riesgos de seguridad del dispositivo antes de permitir el acceso. Tipo de usuario ´o dispositivo, ubicaci´on y horario de conexi´on, sistema operativo, actualizaciones de seguridad del sistema operativo, antivirus de cualquier marca actualizado, software instalado, programas y servicios en ejecuci´on, etc.

4. Remediaci´on autom´atica asistida de los riesgos de seguridad encontrados. Habilitar actu-alizaciones autom´aticas del sistema operativo, ejecutar ´o detener programas y servicios, desinstalar software, permitir actualizaci´on de antivirus, etc.

5. Autorizaci´on. S´olo se tiene acceso a los recursos (aplicaciones, servidores, impresoras, etc.) espec´ıficos necesarios de acuerdo al rol de trabajo del usuario ´o dispositivo dentro de la instituci´on.

Importante: En el paso 2 es obligatorio contar con la identidad electr´onica institucional (cuenta de correo electr´onico institucional) para poder autenticarse sin ning´un problema.

Cap´ıtulo 2

AN ´

ALISIS.

El an´alisis proporciona una vista interna descrita en el lenguaje de los desarrolladores y se definen los elementos b´asicos del problema tal como lo expresa el cliente ´o usuario.[4][5]

2.1.

Modelado del negocio.

En el caso de que el cliente no presente una descripci´on detallada de requisitos para que el desarrollador tenga un punto de partida y pueda empezar a dise˜nar un programa, es necesario elaborar casos de uso del negocio en donde se visualicen los procesos que se llevan a cabo dentro de la organizaci´on. El modelado de negocio se divide en dos partes:[5]

1. Modelo de casos de uso del negocio. 2. Modelo de objetos.

Para el presente desarrollo, se despliegan los siguientes modelos y su explicaci´on correspondiente.[8]

2.1.1.

Modelo de casos de uso del negocio.

En la figura 2.1 se muestran dos casos de uso, mismos que se describen a continuaci´on: 1. Monitorear los conmutadores. Este caso de uso representa el poceso que hace el agente

cuando se dispone a verificar las computadoras que se conectan a la red.

Figura 2.1: Modelo de caso de uso de negocio donde se visualizan los procesos que se llevan a cabo dentro de la red institucional.

2.1.2.

Modelo de objetos del negocio.

En la figura 2.2, se aprecia el primer modelo cuando un usuario se conecta a un puerto en el conmutador correspondiente, se detecta, se autentica y entra a la red. Este proceso es el que se deber´ıa de llevar a cabo idealmente, en donde todos los usuarios que intentan acceder a la red son aut´enticos y no deber´ıa de haber alg´un problema de usuarios no autorizados.

Figura 2.3: Modelo de objeto del segundo caso de uso de negocio donde se visualiza el proceso que lleva a cabo el agente cuando autentica a una computadora que intenta acceder a la red del instituto.

En la figura 2.3, se aprecia el segundo modelo el proceso que lleva a cabo el agente cuando detecta un host conect´andose a un conmutador, y aqu´ı habr´a dos opciones: 1) cuando el host que intenta acceder a la red es aut´entico y, por lo tanto, se aprueba y accede; 2) cuando el host no es aut´entico, se desaprueba y se bloquea el puerto al cual se conect´o.

2.2.1.

Requerimientos del usuario.

En primer lugar, el agente tiene un fin en particular: evitar conflictos de duplicidad IP ad-ministrando los conmutadores presentes en la red institucional, esto es, permitir la entrada a la red a las computadoras que est´en autorizadas, de lo contrario, negarla. De esta forma se tiene por seguro que estar´an ´unicamente las autorizadas y registradas en la base de datos correspondiente dentro de la instituci´on ´unicamente usando su IP designada .

El agente estar´a trabajando desde una m´aquina administrada por una persona a cargo. El administrador deber´a tener conocimientos b´asicos en redes, esto es, tener presente algunos conceptos como: qu´e es una IP, MAC Address, switch o conmutador, segmento de una red, una red LAN, entre otros, para que no tenga ning´un problema en el momento de estar monitoreando los conmutadores presentes en cada uno de los segmentos contenidos dentro de la red institucional.

2.2.2.

Especificaciones funcionales.

A continuaci´on se especifican cu´ales son los requerimientos del sistema, es decir, los servicios y restricciones.

Las restricciones son:

1. El agente s´olo podr´a operar en redes ethernet.

2. S´olo se podr´an administrar conmutadores de la marca Enterasys, de las series A. 3. El agente se restringe solamente al control de acceso de computadoras a la red con el fin

de evitar problemas de duplicidad IP, ya que generalmente este problema es generado por computadoras ajenas, tales como las port´atiles, que necesitan acceder a internet y por lo tanto se conectan por medio de un cable a la red y necesitan configurar sus par´ametros de red asign´andole alguna IP dentro de alg´un segmento en la instituci´on. 4. Por otra parte, pensando que cada computadora autorizada ya tiene asignada una IP

´

unica e intrasferible, no habr´a la necesidad de configurar sus par´ametros de red, como la IP, m´ascara, puerta de enlace y servidores DNS, y por lo tanto, no existir´an problemas entre las computadoras autorizadas.

Posteriormente, una vez estando el software en producci´on, si se quiere mejorar, esta activi-dad estar´a considerada dentro de la fase de mantenimiento del software y ser´a trabajo de los desarrolladores u otra persona con los conocimientos necesarios en desarrollo de software. Por otra parte, el agente brinda cinco servicios fundamentales:

1. Detectar cuando una computadora se conecta a un puerto de alg´un conmutador. 2. Si una computadora no est´a dentro de la base de datos de las computadoras autorizadas,

3. Mostrar si un puerto se encuentra disponible, es decir, si a´un no se ha conectado una computadora a ´este, y bloqueado o desbloqueado.

4. Desbloquear un puerto manualmente.

5. Mostrar si alg´un conmutador no est´a operando.

2.3.

Alternativas de soluci´

on.

En base a un an´alisis y al estado del arte, existen otras alternativas de soluci´on que se despliegan a continuaci´on.[1][2][3]

Alternativa Ventajas Desventajas Adquirir una soluci´on de seguridad

provista por alg´un proveedor especialista en seguridad inform´atica.

Mejor administraci´on de IP’s. Recolecci´on de informaci´on en

varios segmentos. Aplicaci´on de pol´ıticas. Bloqueo de IP/MAC no

autorizadas.

Precio elevado de la soluci´on. Reestructuraci´on completa de la

red.

Proveer una persona que administre la red directamente, con ayuda de un

sniffer y una computadora que se conecte al conmutador.

No hay necesidad de la implementaci´on de un software.

Se har´ıan reportes m´as detallados debido al control por

una persona.

Llegar´ıa a ser ineficiente la administraci´on debido a que la

persona no estar´ıa las 24 hrs. disponible.

No se podr´ıa estar en la consola de administraci´on del switch y

en el sniffer al mismo tiempo. Desarrollar un agente de software

operado por un administrador.

Desarrollo e implementaci´on gratuita.

Cumple con los requisitos del usuario.

No hay cambios en la estructura de la red.

F´acil entendimiento para el administrador.

No es una soluci´on tan robusta como las comerciales.

Cuadro 2.1: Comparaci´on de las posibles alternativas de soluci´on.

En base a la comparaci´on de las alternativas, llegamos a la conclusi´on de que la soluci´on propuesta en el presente proyecto es la adecuada para los fines ya establecidos.

Figura 2.4: Diagrama general del sistema.

En la figura 2.4 se muestra la forma general de trabajar del sistema. Consta del agente de software operando en dentro de la red institucional, en particular, en un conmutador, en donde se ir´an conectando distintas computadoras que quieran tener acceso a la red; el agente verifica la conexi´on de la computadora al conmutador, se obtiene su direcci´on MAC y en base a ese dato se define si se trata de una computadora autorizada para accesar a la red; si es el caso, se le permite el acceso, de lo contrario, se bloquea el puerto al cual se conect´o, deneg´andole el acceso a la red institucional para evitar posteriores conflictos.

En la figura 2.5 se presenta el diagrama espec´ıfico del sistema, con el que se tendr´a una idea m´as clara del funcionamiento del sistema:

2.4.1.

Formas de accesar al conmutador.

Tomando en cuenta la necesidad de acceder al conmutador en base a los diagramas anteriores, a continuaci´on se presentan tres formas a trav´es de las cuales el administrador puede acceder a ´el para su administraci´on manual.

1.

Acceso al switch mediante el programa HyperTerminal.

HyperTerminal es un programa que establece la conexi´on con otros equipos, servicios en l´ınea, equipos host, sitios Telnet, por medio de un m´odem o un cable Ethernet. En nuestro caso, utilizamos un cable serial que nos permite conectarnos al conmutador para su administraci´on v´ıa remota por medio del protocolo Telnet. Los pasos son los siguientes:

a) Al abrir el programa, se necesita proporcionar un nombre a la conexi´on, al igual que elegir un ´ıcono que representa el tipo de conexi´on que se quiere establecer. Se elige el primer ´ıcono.

b) Se selecciona el tipo de conexi´on que se utilizar´a. En nuestro caso usamos Telnet, y escribimos la IP del sistema destino.

Figura 2.7: Selecci´on de protocolo Telnet junto con la IP del conmutador y el puerto 23.

c) A continuaci´on, se configuran algunos par´ametros para la conexi´on tales como los bit por segundos.

Figura 2.8: Par´ametros a configurar.

Figura 2.9: Login. Se introducen el usuario y contrase˜na.

e) Por ´ultimo, se despliega la pantalla de inicio con algunas descripciones del disposi-tivo, as´ı como la primer l´ınea para empezar a escribir comandos.

2.

Acceso mediante el protocolo HTTP.

El protocolo HTTP(Hypertext Transfer Protocol) es el protocolo responsable de todas las transacciones en la World Wide Web. Esta dise˜nado para permitir la transferencia de documentos HTML(Hypertext Markup Language).

El switch cuenta con una interfaz web nativa con la cual podemos administrarlo de forma gr´afica. Para utilizar dicha interfaz, es necesario comunicarnos con el switch por medio de un navegador de internet v´ıa HTTP. Para realizar dicha tarea, se muestran los pasos a seguir a continuaci´on:

a) Se abre el explorador de nuestra preferencia y escribimos la direcci´on a la cual queremos acceder, en este caso, la IP asignada al switch, por medio del protocolo HTTP.

b) A continuaci´on, se abre una ventana en la cual se pregunta por el nombre de un usuario y contrase˜na. En nuestro caso, se tiene el nombre del administrador del switch con su contrase˜na correspondiente.

Figura 2.12: Solicitud de nombre de usuario y contrase˜na.

c) Por ´ultimo, se abre la consola de administraci´on. Se observa que se trata de una consola en forma gr´afica, por lo que es m´as f´acil la administraci´on; no hay necesidad de escribir comandos, los comandos est´an incluidos en los diferentes botones, cajas de textos, etc., que incluye dicha consola.

Figura 2.13: Consola administrativa del switch.

3.

Acceso mediante la l´ınea de comando del sistema operativo v´ıa

el protocolo Telnet.

computadora y de esta forma invocarlo y escribir la direcci´on destino a la cual queremos entrar. A continuaci´on se explica brevemente dicho proceso:

a) Se accede a la terminal en el sistema operativo donde nos encontremos. Enseguida escribimos la siguiente sintaxis: telnethostname port, donde telnet sirve para ejecu-tar nuestro cliente,hostname contiene la direcci´on del host destino al cual queremos acceder yport el puerto por el cual nos conectaremos, que en este caso es el 23.

b) Se nos pregunta por el nombre de un usuario y contrase˜na. Se escribe el nombre del administrador del switch y su correspondiente contrase˜na.

Figura 2.15: Nombre del usuario y contrase˜na.

c) Por ´ultimo se despliega la pantalla de detalles del producto, as´ı como la l´ınea para comenzar a escribir comandos.

Figura 2.16: Consola administrativa del switch.

Con base al an´alisis anterior, se decide que el agente se conectar´a al conmutador v´ıa el protocolo Telnet.

2.5.

Plataformas de desarrollo.

En tabla 2.2 se muestra informaci´on en cuanto a lenguajes de programaci´on.

Java C# C++

Paradigma Orientado a objetos Orientado a objetos Orientado a objetos Multiplataforma S´ı No S´ı

Poco rebuscado y preciso S´ı S´ı No Cuadro 2.2: Comparaci´on de algunos lenguajes de programaci´on considerados a usar.

En base a la tabla 2.2, hemos decidido utilizar Java como lenguaje de programaci´on ya que se considera un lenguaje poco rebuscado, es decir, f´acil de entender, as´ı mismo es multiplatafor-ma, o sea, el agente de software ser´a capaz de operar en cualquier sistema operativo. Adem´as, gracias al manejo de datos, su simplicidad y los entornos de desarrollo que existen para Java nos ser´a muy f´acil la codificaci´on, de manera r´apida y precisa, permitiendo que la velocidad de desarrollo se agilice considerablemente.

Existen diversos IDE’s (del ingl´es Integrated Development Enviroment, en espa˜nol Entorno de Desarollo Integrado) que son programas que sirven para el desarollo de otros programas en un lenguaje de programaci´on en particular. Para la presente tesis se ha pensado en al menos tres IDE’s, que son:

NetBeans. Eclipse Galileo. Oracle JDeveloper.

Cap´ıtulo 3

DISE ˜

NO.

El dise˜no proporciona un modelo f´ısico a implementar, representado por los componentes de un sistema, que ser´a utilizado conjuntamente con el modelo de implementaci´on. Comprende estilos arquitect´onicos, estructura y propiedades del sistema a implementar desplegados en modelos de clases y de casos de uso.[6][7]

A continuaci´on vamos a desplegar algunos diagramas con base a lo que indica la metodolog´ıa RUP para describir nuestro proceso de dise˜no lo m´as claro y sencillo posible.[5][6]

3.1.

Diagrama de componentes.

En la figura 3.1 se muestra el diagrama de componentes, el cual deriva del an´alisis anterior-mente hecho. Se usaron las siguientes herramientas para el desarrollo del agente:

Java como lenguaje de programaci´on. NetBeans como plataforma de desarrollo.

MySQL como sistema de gesti´on de la base de datos.

3.2.

Diagrama de paquetes.

El diagrama de paquetes muestra la divisi´on de un sistema en agrupaciones l´ogicas que interact´uan entre ellas. Dado que los paquetes piensan como directorios, estos diagramas desglosan la jerarqu´ıa de un sistema.[8]

La figura 3.2 muestra el diagrama de paquetes del sistema, el cual se encuentra formado por tres paquetes: el de Base de Datos, Conmutador e Interfaz.

Figura 3.2: Diagrama de paquetes.

El paquete de “Base de Datos”se encarga de hacer las consultas en la base de datos correspon-diente para verificar si la direcci´on MAC de una computadora conectada a un conmutador dentro de la red existe y validar su autorizaci´on de acceso a la red. El paquete “Conmuta-dor”se encarga de mandar los comandos necesarios al conmutador para recuperar los datos necesarios y verificar la autenticidad de las computadoras, as´ı como la validaci´on de que un conmutador se encuentre activo.

Los dos paquetes anteriormente descritos interact´uan con el paquete “Interfaz”, el cual con-tiene la interfaz gr´afica, en donde el usuario escribir´a la direcci´on IP del conmutador al cual querr´a tener acceso, as´ı como desplegar su estado, es decir, los puertos que se encuentran ocupados, bloqueados y las direcciones MAC de la computadoras conectadas, as´ı como el aviso de la conexi´on de una de ellas y la generaci´on de archivos de registro donde se escriban los eventos ocurridos tales como los puertos que han sido bloqeuados.

3.3.

Diagrama de clases de “Base de datos”.

continuaci´on en la figura 3.3, as´ı como la descripci´on de sus atributos y m´etodos en las tablas 3.1 y 3.2.[8]

Figura 3.3: Diagrama de clases “Base de Datos”.

Atributo Descripci´on

dbUrl Contiene la cadena de conexi´on con la base de datos. Incluye la direcci´on IP de la m´aquina donde se encuentra la base de datos, el puerto con el que se comunica y su nombre. user Contiene el nombre de usuario que se requiere para accesar a la base de datos. psw Contiene la clave de acceso a la base de datos.

conn Crea la conexi´on con la base de datos.

statement Se encarga de ejecutar sentencias de SQL y regresar los resultados de la consulta. resultset Representa una tabla de datos que representa un conjunto de resultados de la base de

datos, que es generada ejecutando una sentencia que hace una consulta a la base de datos. MACUser Almacena la direcci´on MAC que se desea comparar.

IPUser Almacena la direcci´on IP que le pertenece a la computadora con la MAC recuperada. User Nombre completo del usuario, propietario de la computadora en cuesti´on.

M´etodo Descripci´on

queryMAC Se encarga de verificar la existencia de la direcci´on MAC de la computadora conectada al conmutador.

queryIP Si la direcci´on MAC mencionada existe, este m´etodo se encarga de recuperar la IP de la computadora.

queryUser Si la direcci´on MAC existe, este m´etodo se encarga de recuperar el nombre del usuario de la computadora.

Cuadro 3.2: Descripci´on de los m´etodos de la clase ConectDB.

3.4.

Diagrama de clases de “Conmutador”.

El paquete Conmutador contiene dos clases: la clase Comandos y la clase Recupera. Este paquete es el encargado de extraer la informaci´on necesaria referente al estado del conmutador para llevar a cabo la autenticaci´on de las computadoras conectadas.

A continucaci´on se muestra en la figura 3.4 el diagrama de clases, as´ı como la descripci´on de cada una de ellas, sus atributos y m´etodos.[8]

Clase Descripci´on

Comandos Es la encargada de recuperar toda la informaci´on que despliega la interfaz de l´ınea de comandos del conmutador y mandarla a un archivo de texto, as´ı como el bloqueo de puertos. Esta clase incluye los comandos necesarios, tales comoshow port status, show

mac, set port disable, set port enable yping.

Recupera Se encarga de generar los archivos de texto correspondientes a los estados de los puertos, es decir, se registra en tiempo real la conexi´on de una computadora a alg´un puerto del

conmutador y se generan dos archivos mostrando su estado anterior y el actual con referencia a dicha conexi´on.

Cuadro 3.3: Descripci´on de las clases del paquete “Conmutador”.

3.4.1.

Descripci´

on de los atributos y m´

etodos de la clase Comandos.

Atributo Descripci´on

port Contiene el n´umero de puerto por el cual se har´a la conexi´on al conmutador. Se usar´a el protocolo Telnet, por lo tanto el valor del puerto es 23.

host Contiene la direcci´on IP del conmutador al cual queremos tener acceso. respuesta Guarda cada l´ınea que recupera de la interfaz de l´ınea de comandos del conmutador.

rutaDest Contiene la ruta del sistema en el cual se almacenar´an los archivos de texto generados. ln Almacena un salto de l´ınea, el cual se incluye en cada l´ınea que se recupera de la interfaz

de l´ınea de comandos para que el texto recuperado no se acumule en una sola l´ınea del archivo de texto generado.

socket Es el encargado de crear la conexi´on entre el host origen y el destino, en este caso entre la computadora administrada y un conmutador. Cuando se inicializa toma dos par´ametros: lo

que contienen los atributos “host”y “port”.

tubo Se encarga de leer texto desde un flujo de caracteres de entrada.

salida Se encarga de representar en formato de impresi´on a objetos en un flujo de caracteres de salida.

fichero Representa de forma abstracta los nombres de un archivo o directorio. out Se encarga de escribir texto en un flujo de caracteres de salida. interfaz1 Se encarga de obtener la direcci´on IP introducida por el usuario.

mac Se encarga de recuperar las direcciones MAC de las diferentes computadoras que se encuentran conectadas al conmutador, as´ı como al puerto que se conectan.

portStatus Se encarga de recuperar el estado de los puertos del conmutador, esto es, si est´an ocupados por una computadora o no, o si se encuentan bloqueados.

M´etodo Descripci´on

portDisable Se encarga de bloquear un puerto. portEnable Se encarga de desbloquear un puerto.

ping Recibiendo la direcci´on IP del conmutador, este m´etodo se encarga de verificar su existencia de la red ´o el estado activo.

Cuadro 3.5: Descripci´on de los m´etodos de la clase Comandos.

3.4.2.

Descripci´

on de los atributos y m´

etodos de la clase Recupera.

Atributo Descripci´on

ActualStatus Es una variable tipo array que almacena el estado del conmutador antes de conectar o desconectar una computadora.

NuevoStatus Es una variable tipo array que almacena el estado del conmutador despu´es de haber conectado o desconectado una computadora.

MACStatus Es una variable tipo array que almacena todas las direcciones MAC junto con los puertos del conmutador.

interfaz2 Se encarga de recuperar la direcci´on IP del conmutador al cual se quiere tener acceso. pattern Se encarga de compilar una expresi´on regular a utilizar.

matcher Representa un mecanismo que lleva a cabo operaciones de igualaci´on en una secuencia de caracteres interpretando una expresi´on regular compilada.

ruta Almacena la ruta de acceso a los archivos de texto generados por medio de los comandos enviados al conmutador.

Linea Almacena cada l´ınea que se extrae de los archivos de texto.

archivo Obtiene bytes de entrada abriendo una conexi´on a un archivo existente por medio de un par´ametro tipo String que representa la ruta de acceso en el sistema.

dataInput Permite leer a una aplicaci´on tipos de datos primitivos Java desde un flujo de datos subyacente. Esto se logra junto con un objeto tipo FileInputStream. leerBuffer Se encarga de leer texto desde un flujo de caracteres de entrada.

comandos Se encarga de mandar comandos al conmutador por medio de su interfaz de l´ınea de comandos.

conta1 Es una variable de control que es manipulada por medio del n´umero de l´ıneas que contiene el archivo de texto generado por el comando “show port status”.

conta2 Es una variable de control que es manipulada por medio del n´umero de l´ıneas que contiene el archivo de texto generado por el comando “show port status”..

conta3 Es una variable de control que es manipulada por medio del n´umero de l´ıneas que contiene el archivo de texto generado por el comando “show mac”..

M´etodo Descripci´on

ActualDataStatus Devuelve toda la informaci´on contenida en un arreglo respecto al estado de los puertos en el conmutador antes de conectar o desconectar una computadora al mismo. NewDataStatus Devuelve toda la informaci´on contenida en un arreglo respecto al estado de los puertos en

el conmutador despu´es de conectar o desconectar una computadora al mismo. recMAC Devuelve toda la informaci´on contenida en un arreglo respecto a las direcciones MAC de las

computadoras conectadas en el conmutador antes o despues de conectar una computadora. recMAC2 Devuelve la direcci´on MAC de la computadora conectada a un puerto en particular.

recPing Devuelve un estado en falso si un conmutador se encuentra apagado o no existe la direcci´on IP proporcionada, de lo contrario devuelve true si se encuentra activo. Cuadro 3.7: Descripci´on de los m´etodos de la clase Recupera.

3.5.

Diagrama de clases de “Interfaz”.

El paquete Interfaz contiene s´olo la clase GUI. Esta clase es la encargada de desplegar la interfaz de usuario de forma gr´afica y es a partir de aqu´ı donde el agente empieza a operar con ayuda de los dem´as paquetes ya descritos anteriormente.

3.5.1.

Descripci´

on de los atributos y m´

etodos de la clase Recupera.

Atributo Descripci´on

recupera Es un objeto creado a partir de la clase Recupera que se encarga de recuperar toda la informaci´on necesaria acerca del estado del conmutador.

conectdb Es un objeto creado a partir de la clase ConectDB que se encarga de recuperar informaci´on de la base de datos.

RecuperaActual Se encarga de almacenar el estado actual del conmutador antes de conectar computadoras a ´este.

RecuperaNew Se encarga de almacenar el estado actual despu´es de haber conectado computadoras al conmutador.

RecuperaMAC Almacena las direcciones MAC de las computadoras conectadas al conmutador. recuperaPuertos Recupera los puertos del conmutador.

PuertoRes Almacena un puerto respecto a un cambio de estado de ´este originado por la conexi´on de una computadora.

MACRes Almacena un puerto respecto a un puerto dado. statusRes Almacena el estado de un puerto.

comandos Se encarga de mandar comandos al conmutador por medio de su interfaz de l´ınea de comandos.

pattern1 Se encarga de compilar una expresi´on regular a utilizar.

matcher1 Representa un mecanismo que lleva a cabo operaciones de igualaci´on en una secuencia de caracteres interpretando una expresi´on regular compilada.

patronIP Es una variable que se encarga de almacenar el formato de una direcci´on IP en forma de expresi´on regular.

IPSwitchAccess Es una variable que se encarga de almacenar la direcci´on IP que introduce el usuario. correctIP1 Es una variable que almacena una respuesta afirmativa o negativa respecto a la existencia

del conmutador comparando la cadena de confirmaci´on que entrega el m´etodoping de la clase Comandos.

connSuccess Es una variable que almacena una respuesta afirmativa o negativa respecto a la existencia del conmutador.

permite Almacena una respuesta afirmativa o negativa en base a si hubo cambios de estado en el conmutador.

bloqueado Almacena una respuesta afirmativa o negativa cuando se bloquean puertos. controla Se encarga de controlar el n´umero de filas vac´ıas a introducir en la tabla de informaci´on

tablaInfo.

acceso Almacena la cadena de la direcci´on IP introducida por el usuario.

modelo Define un objeto que se encarga de desplegar m´etodos para manipular la tabla de informaci´ontablaInfo.

datos Define un objeto que almacena el valor nulo para poder agregar l´ıneas vac´ıas a la tabla de informaci´ontablaInfo.

Atributo Descripci´on

acciones Es un objeto tipo JPanel que se encarga de dibujar un panel contenedor de ´ıconos en la interfaz gr´afica, as´ı como de invocar sus

m´etodos para manipularlo.

analiza Es un objeto tipo JButton que se encarga de dibujar un bot´on en la interfaz gr´afica y analizar el estado actual del conmutador, as´ı como de

invocar sus m´etodos para manipularlo.

avisoPuerto Es un objeto tipo JLabel que se encarga de desplegar un mensaje indicando si se ha introducido correctamente el nombre del puerto en la

interfaz gr´afica, as´ı como de invocar sus m´etodos para manipularlo. desbloquea Es un objeto tipo JButton que se encarga de dibujar un bot´on en la

interfaz gr´afica y desbloquear un puerto dado, as´ı como de invocar sus m´etodos para manipularlo.

despliega Es un objeto tipo JButton que se encarga de dibujar un bot´on en la interfaz gr´afica y desplegar el estado actual del conmutador, as´ı como

de invocar sus m´etodos para manipularlo.

estado Es un objeto tipo JLabel que se encarga de mostrar el estado del conmutador al cual se quiere accesar, as´ı como de invocar sus m´etodos

para manipularlo.

infoConmutador Es un objeto tipo JLabel que se encarga de mostrar la direcci´on IP del conmutador al cual se ha accesado, as´ı como de invocar sus m´etodos

para manipularlo.

ipSwitch Es un objeto tipo JTextField que se encarga de dibujar un campo de texto en la interfaz gr´afica y almacenar la direcci´on IP del conmutador

al cual se quiere tener acceso, as´ı como de invocar sus m´etodos para manipularlo.

jPanel1 Es un objeto tipo JPanel que se encarga de dibujar un panel contenedor de ´ıconos en la interfaz gr´afica, as´ı como de invocar sus

m´etodos para manipularlo.

jScrollPane1 Es un objeto tipo JScrollPane que se encarga de deslizar el contenido de la tabla de informaci´ontablaInfo de manera que se puedan visualizar toda la informaci´on almacenada, as´ı como de invocar sus

m´etodos para manipularlo.

msgDirIPConmutador Es un objeto tipo JLabel que se encarga de mostrar un mensaje en la interfaz gr´afica indicando el lugar donde se debe de introducir la direcci´on IP del conmutador, as´ı como de invocar sus m´etodos para

manipularlo.

puertoADesbCadena Es un objeto tipo JTextField que se encarga de almacenar el nombre del puerto que se quiere desbloquear, as´ı como de invocar sus m´etodos

para manipularlo.

Atributo Descripci´on

puertoADesb Es un objeto tipo JLabel que se encarga de mostrar un mensaje en la interfaz gr´afica indicando el lugar donde se debe de introducir el nombre del puerto a desbloquear, as´ı como de invocar sus m´etodos

para manipularlo.

tabla Info Es un objeto tipo JTable que se encarga de desplegar toda la informaci´on acerca del estado del conmutador en una tabla, as´ı como

de invocar sus m´etodos para manipularlo.

verifica Es un objeto tipo JButton que se encarga de de verificar la existencia de la direcci´on IP del conmutador, as´ı como de invocar sus m´etodos

para manipularlo.

Cuadro 3.10: Descripci´on de los atributos de la clase GUI (continuaci´on).

M´etodo Descripci´on

initComponents Es un m´etodo que se genera autom´aticamente para mostrar la interfaz gr´afica de usuario completa.

verificaActionPerformed Es un evento que se genera a partir del atributo verifica, tipo JButton, y contiene los m´etodos necesarios para validar la existencia de un

conmutador a partir de su direcci´on IP.

despliegaActionPerformed Es un evento que se genera a partir del atributo despliega, tipo JButton, contiene los m´etodos necesarios para desplegar la informaci´on

en la tabla de informaci´ontablaInfo acerca del estado del conmutador. analizaActionPerformed Es un evento que se genera a partir del atributo analiza, tipo JButton, y contiene los m´etodos necesarios para analizar el estado actual del

conmutador bloquear alg´un puerto si es el caso.

desbloqueaActionPerformed Es un evento que se genera a partir del atributo desbloquea, tipo JButton, y contiene los m´etodos necesarios desbloquear un puerto. comparador Es un m´etodo que se encarga de comparar los estados de los puertos

con los anteriores y decidir si se bloquea un puerto o no. Cuadro 3.11: Descripci´on de los m´etodos de la clase GUI.

3.6.

Diagrama de casos de uso.

En la figura 3.6 se muestra el diagrama de casos de uso que describe las actividades que se llevar´an a cabo dentro de la escuela con colaboraci´on del agente de software y los usuarios que intenten acceder a la red del instituto.[5][8]

Caso de uso: Acceso y monitoreo de un conmutador.

Caso de uso: Conexi´on de una computadora.

Descripci´on: Se conecta una computadora en alg´un punto de la red institucional.

Flujo de eventos:

1. Se conecta una computadora por medio de un cable Ethernet. 2. El conmutador detecta la conexi´on de dicha computadora. 3. El agente a su vez tambi´en detecta la conexi´on.

Caso de uso: Detecci´on de usuario no autorizado.

Descripci´on: Se detecta un usuario con acceso no autorizado a la red.

Flujo de eventos:

1. El agente recupera la direcci´on MAC de la computadora conectada. 2. Se busca la direcci´on MAC en la base de datos correspondiente. 3. No se encuentra la direcci´on MAC.

Caso de uso: Bloqueo de puerto del conmutador.

Descripci´on: Se bloquea un puerto del conmutador, evitando el acceso a la red de una computadora.

Flujo de eventos:

1. Al no existir la direcci´on MAC de la computadora conectada al conmutador, se procede a bloquear el puerto en donde se conect´o.

2. El agente notifica el bloqueo del puerto.

Caso de uso: Validaci´on de usuarios autorizados.

Descripci´on:Se valida la computadora como autorizada a tener acceso a la red institucional permitiendole dicho acceso.

Flujo de eventos:

Cap´ıtulo 4

IMPLEMENTACI ´

ON

Esta parte es la encargada de implementar el sistema en t´erminos de componentes, es de-cir, llevar a cabo la implementaci´on de las clases y subsistemas por partes, encontrados en la parte del dise˜no por medio de c´odigo fuente, probarlos individualmente e integrarlos al sistema.[5][4]

Para llevar a cabo la implementaci´on del agente se mostrar´an a continuaci´on los diagramas de flujos correspondientes a las clases contenidas en los distintos paquetes mostrados anteri-ormente (V´ease Figura 5.2), as´ı como la explicaci´on de c´omo se fueron formando cada parte de los diagramas.

4.1.

Base de datos.

Como ya se dijo, el paquete “Base de datos”contiene una clase, y cada uno de sus m´etodos se construyeron a partir de un diagrama de flujo que es com´un para todos. En cada m´etodo se agregaron algunos otros detalles independientemente del diagrama pero ´este es la “columna vertebral”para todos.

En la figura 4.1 se presenta el diagrama de flujo correspondiente a la clase ConectDB. Se puede apreciar el comportamiento general de cada uno de los m´etodos que comprende esta clase. B´asicamente, se comienza por definir los par´ametros de la conexi´on con la base de datos, tales como la URL de conexi´on, el usuario y contrase˜na. Posteriormente, se tiene que establecer una conexi´on a ´esta tomando en cuenta dichos par´ametros, lo cual se logra con la clase Class y la clase Connect. La clase Class se encarga de recuperar la clase Driver del controlador que ayuda a la conexi´on con la base de datos y la clase Connect la establece, y posteriormente, se crea un objeto Sentencia (del ingl´es Statement) con ayuda de la clase Statement, para poder hacer consultas a la base de datos y finalmente definirlas con la clase ResultSet, en base a los par´ametros que se quieran recuperar o visualizar.[10][15][19]

4.2.

Conmutador.

El paquete Conmutador est´a formado por dos clases: la clase Comandos y la clase Recupera. La clase que se toma como base es la de Comandos ya que es la que le hereda sus propiedades y atributos a Recupera.

En la figura 4.2 se observa el proceso siguiente: se define una direcci´on IP, correspondiente al conmutador, y un puerto de comunicaci´on. Enseguida, se crea un objeto tipo Socket, con ayuda de la clase Scocket, encargado de establecer la conexi´on entre la computadora ad-ministradora y el conmutador. Posteriormente, se crean los canales de lectura y escritura utilzando las clases BufferedReader y PrintWriter, para poder recibir las cadenas de car-acteres correspondientes y mandarlas a un archivo de texto creado con ayuda de la clase File.[10][15][19]

4.2.1.

Clase Comandos.

Una vez teniendo el archivo de texto se comienzan a enviar los comandos correspondientes a la interfaz de l´ınea de comandos del conmutador para que se obtengan las cadenas l´ınea por l´ınea y se escriban en el archivo. Cada que se recupera una cadena se pregunta si es igual a una cadena en particular, que es “A2(su)-¿exit”, ya que es la ´ultima que se recupera cuando se termina de recibir cadenas. Si se recupera la cadena mencionada, entonces se acabar´a de generar el archivo de texto por completo y se proceden a cerrar los canales de lectura y escritura, as´ı como el Socket; si no se ha recuperado a´un la cadena mencionada, se continuan obteniendo las cadenas que desliega la l´ınea de comandos y escribi´endolas en el archivo de texto hasta que se obtenga dicha cadena.[10][15][19][17]

4.2.2.

Clase Recupera.

de texto. Finalmente se regresa el valor almacenado con la informaci´on deseada en un array tipo String.[10][15][19]

4.3.

Interfaz.

El paquete Interfaz contiene la clase GUI. En esta clase no existe ning´un diagrama que sea la base para todos los m´etodos que pueda contener, ya que por ser el punto de partida del agente, realiza diferentes tareas utilizando los datos que son proporcionados por los dem´as paquetes. De esta forma, se despliegan a continuaci´on los diagramas de flujo correspondientes a los m´etodos que conforman a esta clase.

4.3.1.

Diagrama de flujo del evento verificaActionPerformed.

En la figura 4.4 se observa el siguiente proceso: se define una expresi´on regular tipo String, la cual ser´a compilada con ayuda de la clase Pattern, despu´es se proporciona una direcci´on IP en el campo de texto ipSwitch para posteriormente verificar el formato de esta direcci´on con ayuda de un objeto tipo Matcher. Despu´es se pregunta si el formato es el correcto y por ende que el campo de texto no est´e vac´ıo. Si lo anterior no se cumple, se tiene que volver a escribir la direcci´on IP hasta que el formato sea el correcto; por el contrario, si se cumple la condici´on entonces se ejecuta el m´etodo ping con ayuda de un objeto creado a partir de la clase Comandos para verificar la existencia de la direcci´on. Si la respuesta es exitosa se despliega un mensaje informando que el conmutador est´a encendido, de lo contrario se notifica su estado inactivo o que la direcci´on dada no existe.[10][15][19]

4.3.2.

Diagrama de flujo del evento despliegaActionPerformed.

4.3.3.

Diagrama de flujo del evento analizaActionPerformed.

Lo que describe el diagrama de la figura 4.6 es lo siguiente: se ejecuta el m´etodo comparador y enseguida se aplica un retardo de diez segundos, esto es debido a que la tabla que despliega el comando “show mac”tarda entre siete y diez segundos en actualizarse. Si hubo cambios en el estado del conmutador, se procede a ejecutar el evento despliegaActionPerformed para mostrar en la tabla de informaci´on el nuevo estado del conmutador; de lo contrario, dicha tabla se queda con los mismos valores ya que no se ha sufrido ning´un cambio.[10][15][19][18]

4.3.4.

Diagrama de flujo del evento desbloqueaActionPerformed.

En el diagrama de la figura 4.7 se lleva a cabo lo siguiente: se crea una expresi´on regular con el formato que tiene el nombre de un puerto y es almacenado en una variable tipo String, se compila con ayuda de la clase Pattern y se genera un comparador con ayuda de un objeto tipo Matcher. Posteriormente, se obtiene el nombre del puerto, se almacena para crear el comparador y se verifica si el formato es el correcto y por ende el campo de texto “puertoADesbCadena”donde se escribe el nombre no est´e vac´ıo. Si se cumple lo anterior se desbloquea el puerto dado, de lo contrario se tiene que volver a escribir el nombre del puerto.[10][15][19]

4.3.5.

Diagrama de flujo del m´

etodo comparador.

Cap´ıtulo 5

FASE DE PRUEBAS.

La fase de pruebas es un proceso que se lleva a cabo paralelamente a la implementaci´on. La idea es detectar errores, de tal forma que los datos de entrada se procesen de forma correcta y se obtengan los resultados requeridos.[5] [4]

En esta parte se hicieron diversas pruebas con base a los objetivos generales y particulares, as´ı como a los requerimientos del sistema que se presentaron anteriormente.

5.1.

Interfaz.

Primeramente se muestra la interfaz de usuario, que contiene las funciones de acuerdo a los requerimientos del sistema y los objetivos planteados (Figura 5.1).

Figura 5.1: Interfaz gr´afica de usuario.

5.2.

Verificaci´

on de direcciones IP.

informaci´on”y “Analizar ”que nos permitir´an desplegar la informaci´on respecto al estado ac-tual del conmutador y hacer un analisis para verificar si todas las computadoras conectadas son leg´ıtimas (Figura 5.2).

Figura 5.2: Conmutador existente y funcionando.

Por el contrario, si se introduce una direcci´on err´onea, observamos que el mensaje que nos despliega la etiqueta dice “Apagado o no existe”y los botones “Desplegar informaci´on”y “Analizar ”quedan deshabilitados hasta que se introduzca una direcci´on IP correcta (Figura 5.3).

Figura 5.3: El conmutador no se encuentra operando o la direcci´on IP no es v´alida.

Figura 5.4: Informaci´on actual del conmutador.

puerto. Esto es posible ya que la direcci´on MAC de la computadora est´a registrada en la base de datos correspondiente y por lo tanto se le autoriza el acceso al conmutador (Figura 5.5).

Figura 5.5: Nueva computadora conectada al puertofe.1.7

En otro caso, suponiendo que una computadora ya se encontraba conectada al puerto fe.1.1

Figura 5.6: Desconexi´on de una computadora conectada al puertofe.1.1

5.4.

Detecci´

on de una computadora no registrada en la base de

datos.

En esta parte, ponemos el caso en donde se conecta una computadora que no est´a registrada en la base de datos. Damos click en “Desplegar informaci´on ”y posteriormente, en “Analizar ”y visualizamos en el campo Disponibilidad el valor de Bloqueado, as´ı como el valor de No existe en el campo MAC Address (Figura 5.7).

Despu´es de tomar las medidas necesarias, se dispone a desbloquear el puerto en cuesti´on. Esto se logra introduciendo el puerto en el campo de texto correspondiente y se da click en el bot´on “Desbloquear ”(Figura 5.8).

Figura 5.7: Puertofe.1.1 bloqueado.

Figura 5.8: Introducci´on del puerto a desbloquear.

Cap´ıtulo 6

CONCLUSIONES.

La aportaci´on del presente trabajo radic´o en la necesidad de implementar una herramienta en la ESIME debido a los problemas que se presentaban dentro de la red. En principio no fue posible la implementaci´on del agente para que ´unicamente detectara duplicidad IP de-bido a que uno de los l´ımites de este proyecto fue detectar esos problemas administrando el conmutador A2H124-24 de la marca Enterasys, y este dispositivo pertenece al nivel dos o capa de enlace del modelo OSI y los problemas de IP s´olo se pueden resolver en el nivel tres o capa de red. Si se hubiese tomado la decisi´on de detectar el problema de duplicidad IP, un enrutador tomar´ıa el lugar del conmutador para su administraci´on y se tendr´ıa que recurrir al estudio de dicho dispositivo para poder manipularlo por medio del agente. Entonces se opt´o por recurrir a la administraci´on del conmutador tomando en cuenta la informaci´on que nos proporciona gracias a los comandos que se env´ıan a ´este a trav´es de su interfaz de l´ınea de comandos (del ingl´es Command Line Interface).

El presente proyecto no cubre por completo las espectativas de la instituci´on ya que no es to-talmente aut´onoma, no tiene las caracter´ısticas de una soluci´on completa que aportan algunas empresas dedicadas a la seguridad en inform´atica que incluyen desde un software especial-izado hasta una estructura completa para la red que contiene conmutadores y enrutadores especiales. Con el agente, se sienta una base muy fuerte que en principio servir´a de mucho ya que gracias a la administraci´on de los conmutadores la red del instituto contendr´a ´ unica-mente los equipos que est´an autorizados y no los ajenos que pueden causar conflictos, esto con base al registro de usuarios y computadoras con el que se cuenta, y de esta forma cada segmento ´unicamente tendr´a sus equipos autorizados.

A nivel t´ecnico podemos concluir lo siguiente:

Cap´ıtulo 7

TRABAJOS A FUTURO.

Dentro de los trabajos a futuro encontramos los siguientes:

Primordialmente se buscar´a la implementaci´on del agente para que opere en la capa de red administrando un enrutador y detectando las colisiones IP que se puedan generar dentro de la red institucional.

A parte de s´olo denegar el acceso a los usuarios no autorizados a accesar la red, imple-mentar un mecanismo que permita la recuperaci´on de los datos de las computadoras que no est´an autorizadas, tales como nombre del equipo, tipo de sistema operativo y de esta forma crear un registro en donde se almacenen dicha informaci´on y tener una referencia m´as amplia para posibles problemas futuros en donde se vean involucradas las mismas computadoras.

Ap´

endice A

Recopilaci´

on te´

orica.

A.1.

El Proceso Unificado de Rational (RUP).

El Proceso Unificado de Rational (del ingl´es Rational Unified Process) es un proceso mod-erno que proviene de la colaboraci´on entre UML y el Proceso Unificado de Desarrollo de Software.[6]

El RUP se puede describir en tres aspectos:[6]

1. Es un proceso que muestra sus fases a trav´es del tiempo.

2. Muestra tambi´en sus fases de forma est´atica, es decir, las actividades que se llevan a cabo cuando se dispone a trabajar en una sola fase.

3. Muestra una perspectiva pr´actica, que sugiere se cumplan ciertas actividades a utilizar durante el proceso para tener mejores resultados.

El RUP es un modelo que cubre cuatro fases diferentes en el proceso de desarrollo de software.[6] Estas fases estan m´as ligadas a asuntos de negocios que se describen a con-tinuaci´on:

3. Construcci´on. Esta fase cubre los procesos de dise˜no, implementaci´on y pruebas, de-sarrollando el software por medio de la integraci´on de cada parte que lo conforma. Al final de esta fase se tendr´a listo el software operando y la documentaci´on final lista para ser entregada a los usuarios.

4. Transici´on.Esta ´ultima fase se encarga de llevar el software de un entorno de desarrollo a uno de producci´on en donde operar´a en un entorno real. Al terminar esta fase se debe de tener un software operando correctamente en su entorno.

M´as espec´ıficamente, el RUP presenta el siguiente flujo de trabajo:[6]

1. Modelado del negocio. En esta parte se presentan los modelos de casos de uso del negocio, es decir, si no se han proporcionado bien los requisitos del sistema por parte del cliente, se procede a modelar las actividades que se llevar´ıan a cabo dentro de la empresa en base a las actuales, lo cual define un amplio panorama que servir´a de base para el desarrollo del software.

2. Requerimientos. Tiene por objetivo definir bien en claro lo que se quiere desarrol-lar. Para eso, tanto el cliente como el analista deben plantear lo que debe de hacer el programa y lo que no.

3. An´alisis. Mientras que los requisitos proporcionan una vista externa desde el punto de vista del usuario, el an´alisis proporciona un panorama desde el punto de vista de los programadores. Se analizan los requisitos anteriormente definidos con el objeto una comprensi´on m´as clara y precisa. Se utilizan modelos como los de componentes, de objetos, arquitect´onicos, de secuencia, etc.

4. Dise˜no. El modelo se encarga de plasmar un modelos f´ısico desde el punto de vista de los programadores que debe ser mantenido durante todo el ciclo de vida del software. Se presentan algunos modelos como los de componentes, paquetes, de clases, etc. 5. Implementaci´on. En esta parte se lleva a cabo la implementaci´on del sistema en

t´erminos de componentes, es decir, ficheros de c´odigo fuente. Se implementan las clases y subsistemas encontrados en el dise˜no.

6. Pruebas. Son un proceso que se llevan a cabo conjuntamente con la implementaci´on. 7. Despliegue.Una vez terminada la implementaci´on se crea un lanzamiento del producto

terminando, con toda la documentaci´on lista para ser entregada al cliente, se distribuye a los usuarios y se instala en el lugar donde residir´a.

8. Configuraci´on y cambios de gesti´on. En esta parte se administran los cambios del sistema, es decir, se planean mejoras a nivel de software.

9. Gesti´on del proyecto. En esta parte se llevan a cabo los cambios gestionados anteri-ormente.

A.2.

Redes.

A.2.1.

El modelo OSI.

El modelo OSI es un modelo que nos sirve para entender y dise˜nar una red de comunicaci´on f´acil de implementar, robusta y capaz de transmitir y recibir informaci´on dentro de la in-teracci´on con otra red, as´ı como el tratamiento de dicha informaci´on. Est´a compuesto por siete niveles, cada nivel se encuentra separado uno de otro pero est´an relacionados. Cada uno define una parte de la comunicaci´on que se lleva a cabo dentro de una red. Si transmitimos un mensaje de un dispositivo a otro, dicho mensaje se transmitir´a a trav´es de varios puntos en la red. Normalmente estos puntos est´an contenidos dentro de los primeros tres niveles del modelo. Pero durante el dise˜no, los dise˜nadores profundizaron en las funcionalidades de uso durante la transmisi´on y agruparon todas ´estas en segmentos o niveles, definiendo familias de funciones agrupadas que se relacionan entre s´ı y diferenci´andose una de otra por medio de este criterio, cre´andose as´ı el modelo que hoy en d´ıa conocemos, y de esta forma nos permite relacionar dos sistemas que de otra forma ser´ıan incompatibles. Cuando se realiza la transmisi´on de un mensaje entre dos m´aquinas a trav´es de una red, el mensaje debe pasar por todos los niveles siendo manipulado por cada uno de ellos, a˜nadi´endole una cabecera o una cola, esto es, datos de control adquiridos al principio o al final de un paquete de datos. Cuando el mensaje llega al nivel uno se transforma al formato en el cual es transmitido y una vez que llega dicho mensaje a la m´aquina destino, ´este es descompuesto por cada nivel, es decir, cada nivel extrae la informaci´on que le es ´util.[11]

Capa F´ısica.

El nivel uno o f´ısico nos proporciona detalles relacionados con la interfaz y el medio de transmisi´on entre dos dispositivos. Define las caracter´ısticas el´ectricas y mec´anicas de la interfaz y el medio, as´ı como el modo y los pasos a seguir por los dispositivos f´ısicos para la transmisi´on de los datos. Entre otras cosas, el nivel f´ısico proporciona caracter´ısticas como un flujo de bits codificado por dicho nivel a partir de tramas procedentes de la capa de enlace de datos, la velocidad de transmisi´on, el modo, ya sea s´ımplex, semi-d´uplex y full-d´uplex, la topolog´ıa f´ısica, etc.[11]

Capa de Enlace de Datos.

Capa de Red.

Este nivel es el encargado de la entrega de paquetes de un enlace a otro, es decir entre dos redes independientes. Esto se logra a trav´es de la provisi´on de direcciones l´ogicas, que son direcciones necesarias cuando un paquete cruza la frontera de la red para que sea dirigido desde el dispositivo trasmisor al receptor, cada uno ubicados en distintas redes. A diferencia del nivel de enlace de datos, que se encarga de vigilar la transmisi´on de paquetes dentro de una red local, el nivel de red se encargar´a de la entrega de ´estos pero entre dos dispositivos que se encuentren dentro de una red local distinta.[11]

Capa de Transporte.

Este nivel es el responsable de la entrega de todos los mensajes de extremo a extremo, es decir, desde el origen a su destino correspondiente. Supervisa que lleguen intactos y en orden, as´ı como el control de errores y el control de flujo de origen a destino. Para mayor seguridad, en este nivel se puede crear una conexi´on entre dos puertos de extremo a extremo. Esta conexi´on se asocia como un ´unico camino l´ogico a dichos mensajes. En la creaci´on de este camino se involucran tres pasos: establecimiento de la conexi´on, transferencia de datos y cierre de la conexi´on.[11]

Capa de Sesi´

on.

La capa de sesi´on o nivel cinco es el encargado de controlar el di´alogo en la red, es decir, establece, mantiene y sincroniza la interacci´on entre sistemas de comunicaci´on. Entre sus responsabilidades est´a la de permitir que dos sistemas establezcan un di´alogo, ya sea en modo semi-d´uplex ´o full-d´uplex; tambi´en define puntos de prueba, por ejemplo, si se transmiten 1000 datos, se insertan puntos de prueba cada 100 datos de forma que se pueda asegurar la transmisi´on cada 100 unidades y en caso de que falle el dato 343 se tenga que retransmitir a partir del dato 301 y no desde el prinicipio.[11]

Capa de Presentaci´

on.

Este nivel se ocupa de la sint´axis y sgnificaci´on de la informaci´on intercambiada entre dos sistemas. Entre estos se intercambia informaci´on en forma de tira de caract´eres, por lo tanto, dicha informaci´on se necesita traducir a flujos de bits antes de transmitirla. Debido a que todos los sistemas usan un sistema de codificaci´on distinto, la capa de presentaci´on debe de tener la capacidad de poder traducir todos los datos de cualquier sistema. Tambi´en debe llevar a cabo procesos de cifrado de la informaci´on, esto es, el emisor transforma los datos originales a otro formato para su transmisi´on y por su parte, el receptor hace el proceso inverso para regresar dichos datos a su estado original.[11]

Capa de Aplicaci´

on.

por ejemplo, el correo electr´onico. Este nivel provee un terminal virtual, que permite la conexi´on a una m´aquina remota.[11]

A.2.2.

Dispositivo de red de la capa de enlace de datos: Switch o

conmutador.

Son dispositivos anal´ogicos de l´ogica interconexi´on de redes de computadores que opera en la capa de enlace de datos del modelo OSI. Su funci´on es interconectar dos o m´as segmentos de red, pasando datos de un segmento a otro de acuerdo con la direcci´on MAC destino de las tramas en la red. Dividen la red en segmentos, creando a la vez dominios de colisi´on. Una colisi´on se produce cuando los equipos conectados en la misma red env´ıan se˜nales a la vez lo que da como resultado un mensaje confuso.[13][12]

Figura A.1: Dos host en una misma red envian una se˜nal al mismo lo cu´al provoca una colisi´on.

Cuando se produce una colisi´on, los paquetes de datos se destruyen, bit por bit. Para evitar este inconveniente, la red debe de disponer de un sistema que pueda manejar la competencia por el medio (contenci´on). La colisi´on producida en un segmento conectado a un switch no afectar´a a los dem´as segmentos conectados al mismo switch. Cada puerto de un switch es uno dominio de colisi´on.

A continuaci´on se muestran tanto las caracter´ısticas como las ventajas de un conmutador.[12]

Caracter´ısticas de un conmutador.

dispos-Puede repartir el ancho de banda de la red de una manera apropiada en cada segmento de red.

Un switch realiza el proceso de inundaci´on.

Si el switch no tiene en su memoria la direcci´on MAC destino de la trama, lo env´ıa en todas los segmentos de la red conectados excepto aquel de donde se recibido la informaci´on a este proceso se le- conoce como inundaci´on.

Toman decisiones bas´andose en las direcciones MAC en comparacion con los hub’s.

Figura A.2: Switch de 24 puertos, por lo tanto tiene 24 dominos de colisi´on.

Ventajas de un conmutador.

La mayoria de los switch trabaja en full-duplex.

Un switch puede contener una gran cantidad de interfaces.

Entre mayor sea el numero de interfaces que posea un switch las conexiones directas entre host y switch ser´an mas f´aciles.

Figura A.3: Conexi´on directa de un switch y cuatro host (acceso dedicado).

Operaci´

on de un switch en modo full-duplex.

El modo de transmisi´on full-duplex es aquel en donde los datos pueden ser transmitidos en ambas direcciones sobre una transportadora de se˜nales al mismo tiempo. Esta transportadora utiliza dos pares de cable de cobre cruzados, un par para transmitir del host al switch y el otro par la transmitir del switch al host.[12]

Figura A.4: Modo de transmisi´on full-duplex (2 sentidos).