Mejoras implementadas en el sistemabibing.us.es/proyectos/abreproy/12106/descargar... · tos de la...

Capıtulo 3

Mejoras implementadas en el

sistema

En este capıtulo se trata de explicar las distintas funcionalidades anadi-

das al proyecto inicial, para ası resolver los problemas encontrados, superar

las limitaciones y poder poner en funcionamiento el sistema de practicas.

Se explicaran las mejoras introducidas, se mostraran las modificaciones

de los archivos para incluir las mejoras en el codigo y se describira como

poner estas en funcionamiento.

Para introducir estas mejoras, se ha cambiado el aspecto de la aplicacion

web, se ha modificado el menu de navegacion de la aplicacion original para

anadir las nuevas funcionalidades del sistema. Tendra el siguiente menu de

navegacion:

Figura 3.1: Menu de navegacion

Reinicio: Con esta opcion se devuelve el sistema de practicas a su

estado inicial, se aplican las configuraciones por defecto de los elemen-

17

18 CAPITULO 3. MEJORAS IMPLEMENTADAS EN EL SISTEMA

tos de la red y se borran todos los archivos que se hayan subidos a los

PCs.

Configuracion: En este menu desplegable se encuentran los distintos

formularios para “Administrar” las configuraciones, se podra renom-

brar o borrar una configuracion guardada. En este apartado tambien

se puede “Cargar” una configuracion que un usuario tenga almacenada

y “Guardar” una nueva configuracion.

Ademas se han anadido las opciones para interactuar con los conmu-

tadores.

A traves del formulario “Show” se puede mostrar la configuracion del

conmutador que se desee, con la opcion “Configure” se configura el

conmutador lınea a lınea y con “Descargar archivo” se descargara el

ultimo archivo de configuracion del conmutador que haya sido guar-

dado.

Red: Este apartado permite al usuario interactuar con la red de PCs,

obtener las configuraciones de las interfaces de red, las tablas de rutas

y comprobar conectividad entre dos PCs mediante el comando “Ping”.

Ademas este menu incluye el formulario para la captura de trafico en

la red. Podemos iniciar, detener y obtener la captura de la red, para

posteriormente descargarla en el PC del usuario.

Archivos: En este menu se encuentran todas las tareas necesarias para

el intercambio de archivos entre los PCs de la red, esto esta pensado

para el intercambio de trafico. Se pueden ver los archivos contenidos

en los PCs, subir o borrar archivos y transferir los archivos entre los

PCs mediante el protocolo TFTP y el comando WGET del protocolo

HTTP.

Para esto cada PC de la subred puede actuar como servidor o como

cliente, dependiendo de si es el emisor o el receptor del archivo.

3.1. AMPLIACION DE LOS TURNOS 19

Cerrar: Haciendo clic en este campo se cierra la aplicacion web, de-

volviendo el sistema a su estado por defecto y borrando los archivos

almacenados en los distintos PCs de las subredes.

Para introducir este nuevo menu y estos formularios se han modificado

el archivo aplicacion.php del directorio raız y el script interfaz.js, incluido

en la carpeta /js/ anadiendoles las funciones necesarias para las tareas.

Las modificaciones de estos archivos seran incluidas en el apendice.

3.1. Ampliacion de los turnos

El sistema anterior solo permitıa al administrador habilitar turnos de

practicas de Lunes a Viernes. Si bien esto no era un problema, sı que se ha

modificado, ya que uno de los motivos de idear este sistema de practicas

era que los alumnos tuvieran la libertad de hacer las mismas los dıas que

quisieran. Se ha anadido el Sabado y el Domingo a los dıas accesibles, para

que el administrador decida si quiere dar acceso a los alumnos a la aplicacion

dichos dıas.

Para realizar este cambio se han tenido que editar varios archivos del

proyecto anterior, en concreto algunos archivos de la carpeta /include/ y

que eran exclusivos de la parte de administracion del sistema.

En los archivos /include/admin reservas.php, /include/admin turnos.php,

/include/admin usuarios.php y / include/turnos.php se han anadido los dıas

Sabado y Domingo.

1 $d ias = array (1 => ’ Lunes ’ , ’ Martes ’ , ’ Mierco les ’ , ’ Jueves ’ , ’ Viernes ’ , ’ Sabado ’ ,

’Domingo ’ ) ;

Tambien habrıa que hacer la validacion de los dıas anadidos, en el archivo

/admin/administar.php en lugar de validar entre 1 y 5, habrıa que validar

entre 1 y 7.


3.2. Interaccion con los conmutadores

Con esta modificacion se pretende tener mas control sobre los conmuta-

dores, permitir al usuario ver “lo que esta pasando” al momento, no sera ne-

cesario tener que descargar el fichero de configuracion para conocer el estado

del conmutador. Ademas se permite configurar los conmutadores de una ma-

nera mas intuitiva.

3.2.1. Comando de informacion: SHOW

Saber utilizar e interpretar los comandos show permite el rapido diagnosti-

co de fallos, el alumno debe entender y asimilar las salidas de cada uno de

los comandos shows mas importantes, estos le daran la respuesta a mas de

un problema.

Los comandos show permitidos estan limitados por el propio formulario

de la aplicacion web, para evitar que los alumnos puedan ver la informacion

que el administrador del sistema considere privada. Esto es realizado con el

campo option de PHP.

El administrador siempre podra anadir o eliminar los comandos que

desee. Solo tiene que modificar estas opciones en el archivo de la pagina

web de la aplicacion de practicas en el directorio raız, /aplicacion.php.

Las opciones disponibles son:

show arp: Muestra la tabla ARP del conmutador.

show config: Muestra la configuracion de inicio del conmutador.

show gvrp: Muestra la configuracion de GVRP.

show history: Muestra los comandos introducidos anteriormente.

show interfaces: Muestra la configuracion de los puertos y la infor-

macion del estado de las interfaces.

3.2. INTERACCION CON LOS CONMUTADORES 21

show ip: Muestra la configuracion IP del dispositivo.

show logging: Muestra el registro de eventos.

show mac-address: Muestra las direcciones MAC que el conmutador

ha aprendido.

show management: Muestra las direcciones disponibles para la ges-

tion del conmutador y el tiempo que se usa el dispositivo como servidor.

show monitor: Muestra la monitorizacion del estado de la red del

conmutador y la configuracion, si el monitoreo de la red esta habilitado.

show name: Muestra los nombres asignados a los puertos.

show qos: Muestra diversas configuraciones de QoS (Quality of Ser-

vice) (Calidad de Servicio)

show running-config: Muestra el contenido del archivo de configu-

racion activo.

show spanning-tree: Muestra la informacion del spanning-tree 1

show static-mac: Muestra las direcciones MAC estaticas de todas

las VLANS.

show system-information: Muestra la informacion de la configura-

cion global y los parametros de operacion del sistema.

show time: Muestra la fecha y la hora actual.

1Spanning Tree Protocol (SmmTPr o STP) es un protocolo de red de nivel 2 dela capa OSI (nivel de enlace de datos). Esta basado en un algoritmo disenado por RadiaPerlman mientras trabajaba para DEC. Su funcion es la de gestionar la presencia debucles en topologıas de red debido a la existencia de enlaces redundantes (necesarios enmuchos casos para garantizar la disponibilidad de las conexiones). El protocolo permitea los dispositivos de interconexion activar o desactivar automaticamente los enlaces deconexion, de forma que se garantice la eliminacion de bucles. STP es transparente a lasestaciones de usuario.


show trunks: Muestra los canales y los puertos que le pertenecen.

show vlans: Muestra informacion del estado de todas las VLANS2.

Despues de estas opciones se debe introducir un campo de texto en el

que se anaden los siguientes parametros de la orden, si se deja el campo en

blanco muestra una vision general del comando seleccionado, a medida que

se introducen parametros se tiene una vision mas especıfica.

Una de las grandes mejoras es la posibilidad de introducir el caracter ‘?’

en los argumentos, esto es equivalente a pulsar el tabulador en el conmuta-

dor, lo que hace que se muestren las distintas opciones que se pueden poner

como parametros del comando elegido. Con esto se puede buscar lo que se

quiera mostrar sin necesidad de conocer todos los comandos y parametros.

Para implementar esta opcion, se han introducido varios cambios en

los archivos del nucleo de la aplicacion (archivos incluidos en la carpeta

/admin/). En el fichero aplicacion.php, en el que se encuentran las acciones

que se realizan al usar un campo del formulario, se ha anadido en el switch

principal la opcion “show”, aquı se comprueba si el conmutador, la accion a

realizar y sus parametros son correctos. Tambien se ha anadido la funcion

show($accion) en la clase conmutador del archivo red.php, para procesar la

orden a realizar, mandarla al conmutador mediante la clase PHPTelnet y

posteriormente procesar la respuesta para devolverla a la aplicacion y se

muestre el resultado por pantalla.

Para esto se ha tenido que modificar la clase PHPTelnet escrita por An-

tone Roundy, para permitir mandar el caracter tabulador cuando el usuario

introduce la ‘?’ como argumento. Posteriormente, se envıan varios backspa-

ces para que se puedan seguir enviando ordenes sin tener que reiniciar la

aplicacion. Ası pues, se han anadido las funciones DoCommand2() y Do-

Command3(), para enviar el tabulador y los backspaces.

2VLAN (acronimo de virtual LAN, red de area local virtual) es un metodo de crearredes logicamente independientes dentro de una misma red fısica.


3.2.2. Comando de configuracion: CONFIGURE

Como se ha comentado, con esta mejora se pretende poder configurar

los conmutadores de una manera mas intuitiva, los conmutadores podran

ser configurados lınea a lınea y el sistema ira dando la respuesta a cada

orden introducida, corrigiendo posibles fallos de una manera mas comoda.

Con el comando configure se puede realizar esta tarea de forma sencilla.

Saber utilizar este comando con las ordenes adecuadas hace posible que se

puedan configurar los conmutadores rapidamente.

Al igual que en el caso del show, los comandos configure permitidos

estan limitados por la propia aplicacion web, para evitar que los alumnos

configuren parametros de los conmutadores que el administrador no desee.

Estos comandos de configuracion permitidos, tambien podran ser modifica-

dos, habrıa que anadir o eliminar las opciones en el formulario correspon-

diente a la configuracion de los conmutadores.

Los comandos disponibles para el configure son:

hostame: Especifica el nombre del conmutador para fines administra-

tivos.

interface: Introduce el nivel de configuracion de la interfaz o ejecuta

un comando para ese nivel.

ip: Configura varios parametros IP del conmutador.

mac-age-time: Configura el tiempo de duracion de la tabla de direc-

ciones MAC.

mirror-port: Define el puerto espejo para fines de diagnostico.

qos: Configura la calidad del servicio (QoS) del dispositivo.

primary-vlan: Establece la VLAN que va a ser utilizada como pri-

maria.


ping: Envıa solicitudes ping a un dispositivo de la red.

spanning-tree: Establece los parametros de operacion del conmuta-

dor en una topologıa spanning-tree.

trunks: Anade o elimina un puerto del conmutador del tunel.

vlan: Anade, elimina o edita una VLAN, o introduce una VLAN en

el contexto.

Despues de elegir el comando de configuracion, se introducen los valo-

res de estos comandos. Los valores de algunas opciones son comprobados

mediante la funcion de validacion utilizada en el proyecto anterior, para no

permitir el uso de valores correspondientes a la red de administracion. Es-

ta funcion de validacion ha tenido que ser modificada para que, ademas de

permitir validar la configuracion introducida con un fichero de texto, verifi-

que la lınea de configuracion introducida en el formulario. Se ha anadido en

el codigo de la funcion esConmutador($input, $idred, $idconmutador, $con-

fig), usada para esta validacion, del archivo func comunes.php, la siguiente

estructura:

1 i f ( $ input == ‘ archivo ’ ) {

2 // Conf igurac ion completa en un arch ivo de con f i gu ra c i on

3 $texto = Archivo : : l e e r ( $ con f i g ) ;

4 } e l s e {

5 // Conf igurac ion in t roduc ida l i n e a a l i n e a en e l f o rmu la r i o

6 $texto = $con f i g ;

7 }

Como con la orden show, con estos comandos tambien se puede intro-

ducir el caracter ‘?’ como argumento, para poder ver las diversas opciones

de configuracion del comando seleccionado. El caracter puede ser introduci-

do en la profundidad del argumento de configuracion que se desee, ya que

algunas ordenes de configuracion pueden llegar a ser muy largas.

Para llevar a cabo esta tarea se han realizado los mismos cambios que

para el comando show. Se ha modificado el fichero del nucleo de la aplica-


cion, aplicacion.php, para anadir la opcion “configure” en el switch, aquı se

comprueba si el conmutador y la accion a realizar son correctas. Tambien se

ha anadido la funcion configure($accion) en la clase conmutador del archivo

red.php, para procesar la orden a realizar, mandarla al conmutador mediante

la clase PHPTelnet y posteriormente procesar la respuesta para devolverla

a la aplicacion y mostrar el resultado por pantalla. En PHPTelnet se usan

las mismas clases que se han comentado con anterioridad.

Ademas de estos cambios, se ha tenido que cambiar la forma en la que se

guardaban las configuraciones de los conmutadores. Antes cuando se querıa

obtener el archivo de configuracion de un conmutador, la aplicacion no se

conectaba al propio conmutador, sino que obtenıa el fichero de configuracion

que el usuario habıa subido, o el archivo de configuracion por defecto, ya

que era la unica forma de poder configurarlo. Como ahora sı que se puede

configurar el conmutador sin la necesidad de subir un archivo de configura-

cion, aunque esta opcion sigue siendo valida, surge la necesidad de obtener

la configuracion actual de cada conmutador cada vez que se quiera guardar

una configuracion.

Para esta tarea se crea la funcion ObtConfig() en la clase conmutador

del archivo red.php, esta funcion obtendra la configuracion del conmuta-

dor que se desee mediante la orden copy running-config tftp, aplicara el

filtrado de la parte de la red de administracion con la funcion filtrarArchi-

vo($completo, $admin) y guardara la configuracion en el servidor web. Una

vez guardada la configuracion puede ser descargada con la opcion “Descar-

gar Archivo”, incluida en el menu “Configuracion” del menu de navegacion

de la aplicacion web. Para la descarga del archivo se hace uso del codigo

conm config.php del proyecto anterior, el cual no ha sido modificado.

En la funcion filtrarArchivo($completo, $admin) se compara el archivo

de la configuracion completa de un conmutador, obtenida con ObtConfig(),

con un archivo de filtrado creado para esta tarea, en el que se encuentran


las lıneas de configuracion especıficas de la red de administracion de ese

conmutador, ambos almacenados en arrays. Las diferencias entre los dos

archivos son almacenadas en otro array que posteriormente se escribe en un

archivo para ser almacenado en el servidor web.

El archivo de filtrado de un conmutador esta almacenado en la carpe-

ta /home/labredes/configuraciones/administracion/, con el nombre

conmxyfiltro.txt (conmutador y de la subred x ) y tiene el siguiente aspecto

1 ; J9085A Conf igurat ion Editor ; Created on r e l e a s e #R. 1 1 . 2 5

2

3 max−vlans 64

4 snmp−s e r v e r community ” pub l i c ” Unre s t r i c t ed

5 vlan 200

6 name ”ADMIN”

7 f o rb i d 1−24

8 untagged 25−28

9 ip address 192 . 168 . 200 . 201 255 . 255 . 255 . 0

10 e x i t

11 management−vlan 200

12 spanning−t r e e

13 spanning−t r e e 25 bpdu− f i l t e r




17 password manager

Los codigos de las funciones anteriormente mencionadas podran consul-

tarse en el apendice.

3.3. Informacion de los PCs de las subredes

Aunque se pueda obtener la configuracion principal de los PCs de las

subredes seleccionandolos en el esquema, se ha introducido un simple formu-

lario, tanto para obtener toda la configuracion de la interfaz de red utilizada

para la red de usuario, como para mostrar la tabla de rutas de cada uno

de los PCs. Accediendo a “Muestra Configuracion” o a “Muestra Tabla de

Rutas”, en el menu “Red” del menu de navegacion, y seleccionando el PC

que se desee, se obtiene la informacion pedida.

Para hacer estas tareas, en el lado del servidor web se han llevado a cabo

3.3. INFORMACION DE LOS PCS DE LAS SUBREDES 27

las siguientes modificaciones:

Se han anadido los formularios correspondientes a la pagina web. Mo-

dificando los archivos aplicacion.php, del directorio raız, e interfaz.js,

del directorio /js/

Se han anadido dos nuevas opciones al switch del nucleo de la apli-

cacion web. Estas son “ifconfig” y “route”. Aquı se verifica el PC de

destino y se manda la orden a la clase PC del archivo red.php, y una

vez que se obtiene la respuesta, esta es enviada a la aplicacion para

mostrar el resultado.

En la clase PC del archivo red.php se anaden dos funciones practica-

mente identicas, “ifconfig” y “route”, estas se encargaran de crear y

de enviar el mensaje XML-RPC correspondiente. Una vez mandado el

mensaje al PC de la subred de practicas, se espera la respuesta de este

para procesarla segun corresponda.

En el lado del PC de la subred, que sera el servidor XML-RPC que recibe

las ordenes, se han tenido que definir dos nuevas funciones, en el modulo de

acciones, para procesar los mensajes.

Para mostrar la configuracion, de la interfaz de la red de usuario, de los

PCs se anade:

1 de f i f c o n f i g ( s e l f ) :

2 ”””

3 Rea l i za una consu l ta de in formac ion

4 ”””

5 comando = ’ i f c o n f i g eth0 ’

6 sa l i da , s a l i d a e r r = commonfunc . invoca ( comando )

7

8 return sa l i da , s a l i d a e r r

Para mostrar la tabla de rutas se anade:

1 de f route ( s e l f ) :

2 ”””


3 Rea l i za una consu l ta de l a tab la de rutas

4 ”””

5 comando = ’ route ’


7


3.4. Operaciones con archivos

Con esta mejora se pretende poder realizar algunas tareas para compro-

bar el funcionamiento de las subredes, ademas de estudiar distintos proto-

colos de transferencia de ficheros entre PCs, como son TFTP y HTTP,

usando, para este ultimo, la orden WGET.

Se podran subir ficheros a cada uno de los ordenadores de la subred y se

podran comprobar esos ficheros, borrarlos y transferirlos a los demas orde-

nadores. Todas estas opciones las podemos encontrar en el menu “Archivos”

del menu de navegacion de la aplicacion web.

Para el manejo de los archivos en los PCs de las subredes se han crea-

do varias carpetas en dichos PCs. En la carpeta /var/www/uploads/

se almacenaran los ficheros que se suban al ordenador, los archivos de es-

ta carpeta seran los archivos de origen para la transferencia de ficheros y

seran transferidos a las carpetas /home/labredes/downloads/wget/ y

/home/labredes/downloads/tftp/ de los PCs destino segun sean trans-

ferencias con WGET o TFTP, respectivamente.

3.4.1. Listado de archivos

Con esta opcion se pueden listar los archivos, con sus respectivos ta-

manos, que se encuentran en los ordenadores de las subredes, inicialmente

estos estan vacıos ya que la aplicacion borra automaticamente los archivos

cada vez que se inicia o finaliza la sesion, ademas estos archivos tambien

pueden ser borrados gracias a otra funcion de la aplicacion.

3.4. OPERACIONES CON ARCHIVOS 29

Para poder ver el listado de los archivos se debe seleccionar en el for-

mulario el PC que deseemos y elegir el rol para el cual queremos ver los

archivos. Los distintos roles que existen son:

Servidor: Eligiendo este rol se accederıa a la carpeta /var/www/u-

ploads/, donde se encuentran almacenados los ficheros subidos al PC

desde la aplicacion web.

Cliente TFTP: Con este rol se tendrıa acceso a los archivos de la car-

peta /home/labredes/downloads/tftp/, donde son enviados los

ficheros que se transfieren por TFTP desde el ordenador origen.

Cliente WGET: Con esta opcion se listarıan los archivos de la car-

peta /home/labredes/downloads/wget/, donde se encuentran los

archivos transferidos mediante el comando WGET.

Para anadir esta funcion se han llevado a cabo cambios tanto en el ser-

vidor web, como en las funciones de cada servidor XML-RPC de los PCs de

las subredes.

En el codigo de la aplicacion web, archivos incluidos en la carpeta /ad-

min/, ademas de anadir el formulario correspondiente, se ha creado un

nuevo caso en el bucle switch del archivo aplicacion.php, llamado “ls”, que

se encarga de procesar la informacion del formulario, y, en el archivo red.php,

se ha definido la funcion ls($rol) para crear y enviar el mensaje XML-RPC,

posteriormente se recibe la respuesta del servidor XML-RPC y se procesa

de forma adecuada con estas mismas funciones.

En el lado de los PCs de las subredes se ha anadido la funcion para pro-

cesar el mensaje XML-RPC procedente del PC de administracion y generar

la respuesta adecuada.

1 de f l s ( s e l f , r o l ) :

2 ”””

3 Rea l i za una v i s u a l i z a c i o n de arch ivo s


4 ”””

5 i f r o l == ’ Servidor ’ :

6 comando = ’ l s −s −h / var /www/ uploads ’

7 e l i f r o l == ’ C l i en t e WGET’ :

8 comando = ’ l s −s −h /home/ lab r ede s /downloads/wget ’

9 e l s e :

10 comando = ’ l s −s −h /home/ lab r ede s /downloads/ t f tp ’

11



La funcion invoca(comando), del archivo commonfunc, es la que se usa

normalmente para las operaciones en el servidor XML-RPC, esta funcion

ejecuta los comandos en el shell del sistema y devuelve los resultados, fue

creada por Silvio Fernandez para el manejo de PCs en el CDC y es usada

tambien en el proyecto anterior.

3.4.2. Borrado de archivos

El formulario creado para el borrado de archivos es identico al del listado

de archivos, se debe seleccionar el PC del que se quierenn borrar los archivos

y el rol que se quiere utilizar, al dar la orden se borran todos los archivos

contenidos en la carpeta del rol especificado en el PC seleccionado. Se han

tenido que modificar, como se hace cada vez que se crea un nuevo formula-

rio, los archivos de codigos aplicacion.php, del directorio raız, e interfaz.js,

incluido en la carpeta /js/.

Los cambios realizados en los archivos de codigo son los mismos que

para el caso anterior, lo unico que se modifica es el nombre de la funcion, la

opcion del switch se llama “borrar” y la nueva funcion en el archivo red.php

se denomina borrar($rol).

En el lado del PC de la subred, el servidor XML-RPC, se crea una funcion

para procesar el mensaje y realizar la tarea de borrado, posteriormente se

hace un listado de archivos para comprobar que la accion se ha realizado

correctamente.

1 de f borrar ( s e l f , r o l ) :


2 ”””

3 Rea l i za una v i s u a l i z a c i o n de arch ivo s

4 ”””

5 i f r o l == ’ Servidor ’ :

6 comando = ’rm −r / var /www/ uploads /∗ ’

7 comando2 = ’ l s −s −h / var /www/ uploads ’

8 e l i f r o l == ’ C l i en t e WGET’ :

9 comando = ’rm −r /home/ lab r ede s /downloads/wget /∗ ’

10 comando2 = ’ l s −s −h /home/ lab r ede s /downloads/wget ’

11 e l s e :

12 comando = ’rm −r /home/ lab r ede s /downloads/ t f t p /∗ ’

13 comando2 = ’ l s −s −h /home/ lab r ede s /downloads/ t f tp ’

14


16 sa l i da , s a l i d a e r r = commonfunc . invoca ( comando2 )

17


3.4.3. Subida de archivos

La subida de archivos a los PCs se realiza en dos pasos, primero se sube

el archivo al servidor web y posteriormente, se codifica para ser enviado y

almacenado en el PC destino.

3.4.3.1. Subida al servidor web

Como en las modificaciones anteriores, se ha tenido que crear el formula-

rio correspondiente para realizar esta tarea, anadiendo y modificando codigo

en los archivos aplicacion.php e interfaz.js para que sean mostrados en la

pagina web.

En el archivo del nucleo de la aplicacion aplicacion.php, en la carpeta

/admin/, se anade un nuevo caso al bucle switch, llamado “subir” en el

cual se hace una validacion del formulario, para comprobar si el PC que

recibira el archivo es correcto. Aunque, en un principio, la aplicacion no es-

tablece lımites en los ficheros que se suben, se podrıa modificar facilmente

el codigo para comprobar si el fichero sobrepasa un tamano especificado o

si tiene una extension adecuada. De todas maneras, en la propia configu-

racion del servidor web, se ha limitado la subida de archivos a un tamano


no mayor de 50M. Para modificar esta limitacion hay que editar los fiche-

ros /etc/php5/apache2/php.ini y /etc/php5/cli/php.ini y cambiar

los tamanos en las lıneas

1 pos t max s i z e=50M

1 upload max s ize=50M

Para que el cambio surta efecto, hay que reiniciar el servidor web

sudo service apache2 restart

Una vez realizada la validacion, se procede a guardar el archivo en el

servidor web, para ello se ha creado la carpeta /home/labredes/upload-

s/, aquı se almacenan los archivos antes de ser enviados al PC de la subred,

estos archivos se quedaran almacenados en el servidor para que el adminis-

trador pueda comprobar los archivos que se han subido, para que no haya

problemas de almacenamiento, se aconseja que sean revisados y eliminados

cada cierto tiempo. Para almacenar estos archivos se usa la funcion alma-

cenar($archivo, $destino) de la clase archivo del fichero func comunes.php,

funcion creada y utilizada en el proyecto anterior.

Si todo ha ido bien, el archivo es enviado al PC de la subred mediante

XML-RPC, para ello se codifica el fichero en base643 para que pueda ser

transferido en el mensaje, para realizar esta codificacion se deben hacer

varias operaciones con el archivo, usando las funciones fopen(), fread() y

fclose()

3Base 64 es un sistema de numeracion posicional que usa 64 como base. Es la mayorpotencia de dos que puede ser representada usando unicamente los caracteres imprimiblesde ASCII. Esto ha propiciado su uso para codificacion de correos electronicos, PGP y otrasaplicaciones. Todas las variantes famosas que se conocen con el nombre de Base64 usanel rango de caracteres A-Z, a-z y 0-9 en este orden para los primeros 62 dıgitos, pero lossımbolos escogidos para los ultimos dos dıgitos varıan considerablemente de unas a otras.Otros metodos de codificacion como UUEncode y las ultimas versiones de binhex usan unconjunto diferente de 64 caracteres para representar 6 dıgitos binarios, pero estos nuncason llamados Base64.


1 $ge s to r = fopen ( $ruta , ” r ”) ;

2 $contenido = f read ( $gestor , f i l e s i z e ( $ruta ) ) ;

3 f c l o s e ( $ge s to r ) ;

Tras realizar esta tarea, el fichero se codifica y se llama a la funcion en-

viar($ficheroxml, $nombre), de la clase PC del fichero red.php, que sera la

encargada de enviar el fichero codificado, el sistema permanecera a la es-

pera de la respuesta por parte del servidor XML-RPC. Una vez recibida la

respuesta se mostrara el resultado.

Esta operacion de subida puede tardar un poco de tiempo en realizarse,

dependera del tamano del archivo a subir. Tambien hay que tener en cuenta

que las operaciones con ficheros pueden dar algunos problemas, si algunas

de las funciones de operaciones con ficheros falla, el sistema mostrara un

error de subida y la operacion debe hacerse otra vez desde el principio.

3.4.3.2. Subida al PC de la subred

Como se ha comentado el fichero se codifica y se envıa al PC de la subred

como parte de un mensaje XML-RPC. En este PC, el archivo sera guarda-

do en la carpeta /var/www/uploads/, para que pueda ser transferido a

otros PCs de la subred mediante los dos metodos de transferencia que des-

pues seran comentados. El fichero permanecera en esta carpeta hasta que el

usuario decida borrar los archivos almacenados en el PC con rol de servidor,

reinicie o cierre la aplicacion, momento en el que se borran automaticamente

todos los archivos almacenados en el PC.

Para la recepcion del mensaje XML-RPC se ha creado una nueva funcion

en el modulo del servidor XML-RPC, esta nueva funcion es

1 de f c rea ( s e l f , f i cheroxml , nombre ) :

2 ”””

3 Rea l i za c r eac i on arch ivo s

4 ”””

5 nombre = s t r ( nombre )

6 f i c h e r o = ’/ var /www/ uploads/ %s ’ %(nombre )

7 sa l i da , s a l i d a e r r = commonfunc . c r e a f i c h e r o ( f i cheroxml , f i c h e r o )



Aquı se pasa la ruta donde se almacenara el fichero, junto con el propio

fichero codificado en base64, a la funcion crea fichero(ficheroxml, fichero)

del archivo commonfunc, que ha sido modificado para anadir esta funcion.

No se hace uso de la funcion invoca(comando), usada en los casos anteriores,

ya que, ademas de introducir comandos en el shell del sistema, se necesitan

otras operaciones.

1 de f c r e a f i c h e r o ( f i che roxml , f i c h e r o ) :

2 s a l i d a = [ ]

3 s a l i d a e r r = [ ]

4 t ry :

5 f i c h=open ( f i ch e r o , ’w’ )

6 f i c h . wr i t e ( base64 . b64decode ( f i che roxml ) )

7 f i c h . c l o s e ( )

8

9 r e su l t ado = s t r ( ’ Fichero subido ’ )

10 s a l i d a . append ( r e su l t ado )

11

12 except Exception , why :

13 s a l i d a e r r = [ s t r ( Exception ) , s t r (why) ]


Usando las mismas funciones de operaciones con archivos, tambien dispo-

nibles en Python, conseguimos decodificar y almacenar el fichero en la ruta

adecuada, dando el mensaje ‘Fichero subido’, si todo ha ido correctamente,

o lanzando una excepcion en caso de error.

3.4.4. Transferencia de archivos

El principal objetivo para el que se ha hecho esta modificacion es para

que el alumno pueda ver como interaccionan dos PCs de la subred, los

protocolos implicados en las transferencias y otras caracterısticas del trafico

en las redes.

Para realizar esta tarea se barajaron varias opciones, primero se penso en

usar generadores de trafico:

Generador de trafico IPERF: Permite medir el ancho de banda entre


dos ordenadores en red, genera flujo de datos TCP y UDP y mide el

rendimiento de la red. Permite al usuario modificar ciertos parametros

del generador de trafico, como el tamano de datagramas UDP, o el

tiempo de la conexion.

Generador de trafico UPDCAST: Permite el envıo de datos UDP de

forma simultanea a muchos destinos en la red.

Estos generadores de trafico, al igual que otros, se descartaron ya que

para su uso requerıan la ejecucion de comandos tanto en el servidor de

trafico como en el cliente, y con el sistema implementado se tenıan que

hacer cambios muy grandes en la estructura.

Otra de las opciones fue la de usar protocolos en tiempo real (RTP),

pero requerıa un tiempo de aprendizaje del protocolo por parte del alumno.

Ademas estas opciones anteriormente mencionadas no dejan de ser algo

abstractas, no hay manera visual de comprobar si el trafico llega correcta-

mente al PC destino, ası que se llego a la conclusion que la mejor manera de

generar trafico entre los PCs era la de transferir archivos entre los ordena-

dores. Con este sistema el alumno puede comprobar si el archivo que se ha

enviado esta en el PC destino, puede enviar archivos de distintos tamanos y

no tiene que preocuparse de configurar los parametros de la conexion.

Para esta solucion tambien se tuvieron en cuenta varias opciones para la

transferencia de archivos; finalmente se opto por el protocolo de transferencia

TFTP, que usa UDP, y la herramienta WGET del protocolo HTTP, que

utiliza TCP. Ası se tienen dos protocolos de transporte distintos.

Para analizar los protocolos implicados en la transferencia, el alumno

podra capturar el trafico de la red con una nueva herramienta de la aplicacion

web que sera explicada posteriormente.


3.4.4.1. Transferencia WGET

WGET es una herramienta libre que permite la descarga de contenidos

desde servidores web de una forma simple. Su nombre deriva de World Wide

Web (www), y de obtener (en ingles “get”), esto quiere decir: obtener desde

la WWW.

Actualmente soporta descargas mediante los protocolos HTTP, HTTPS

y FTP.

Caracterısticas:

Robustez: WGET ha sido disenado para la robustez en conexiones

de red lentas o inestables. Si una descarga no se completa debido a

un problema en la red, WGET automaticamente tratara de seguir

descargado desde donde acabo, y repetir el proceso hasta que el archivo

completo haya sido recuperado.

Descarga recursiva: WGET opcionalmente puede trabajar como

una arana web extrayendo recursos enlaces de las paginas web HTML

y descargarlas en la secuencia, repitiendo el proceso recursivamente

hasta que todas las paginas hayan sido descargadas o hasta que haya

sido alcanzada una profundidad de repeticion maxima especificada por

el usuario. Las paginas web descargadas son guardadas en una estruc-

tura de directorio que se parece a un servidor remoto. Esta descarga

recursiva permite hacer una copia exacta de cualquier sistema de ar-

chivos parcial o completamente de un sitio web vıa HTTP. Los enlaces

de sitios web HTML descargados pueden ser ajustados para indicar el

punto o zona de descarga.

Portabilidad: Escrito en una forma que permita la portabilidad, en

lenguaje de programacion C y con la menor cantidad posible de biblio-

tecas de terceros, WGET requiere no mucho mas que un compilador de

C y una interfaz tipo de BSD para usar la red con TCP/IP. Disenado


como un programa Unix para invocarse desde una lınea de comandos,

el programa ha sido portado a numerosos sistemas y ambientes tipo

Unix, tales como Cygwin y Mac OS X, ası como tambien a sistemas

Microsoft Windows.

Otras caracterısticas:

WGET soporta descargas a traves de proxies, los cuales son amplia-

mente desplegados para proporcionar acceso web dentro de cortafuegos

de empresas y al cache para rapidamente entregar contenido de acceso

frecuente.

Hace uso de conexiones persistentes de HTTP donde estan disponibles.

Compatible con IPv6 en sistemas que incluyan las interfaces apropia-

das.

Puede usarse SSL/TLS para el cifrado de las descargas usando la bi-

blioteca OpenSSL.

Puede descargar archivos mas grandes a 2 gigabytes en sistemas de 32

bits que incluyan las interfaces apropiadas.

La velocidad de descarga puede ser limitada para evitar consumir todo

el ancho de banda disponible.

Como se puede ver, es un metodo muy simple para la tarea de transfe-

rencia de ficheros entre PCs, por ello ha sido el metodo elegido para trabajar

sobre TCP.

Para hacer uso de esta herramienta, una de las condiciones es que exista

un servidor web de donde obtener los ficheros, por ello se tiene que instalar

un servidor web en cada PC de la subred.


sudo apt -get install apache2

sudo apt -get install apache2 -mpm -prefork

Una vez instalado el servidor web, se debe crear la carpeta donde se en-

contraran los ficheros que seran trasferidos al cliente, en esta carpeta tambien

se almacenaran los ficheros que se transferiran mediante TFTP.

sudo mkdir /vaar/www/uploads/

En el lado del cliente no es necesario instalar nada, solo se necesita crear

la carpeta donde se almacenaran los ficheros transferidos mediante WGET

y cambiar sus permisos.

sudo mkdir /home/labredes/downloads/wget

sudo chmod 777 /home/labredes/downloads/wget

Ahora, desde el cliente o PC destino del archivo, se teclearıa el comando

para obtener el archivo

wget -N -P /home/labredes/downloads/wget/ http://‘‘ direccion del

servidor ’’/uploads/‘‘nombre del archivo ’’

Con la opcion -N, si en nuestro equipo existe ya un archivo igual al que

se quiere descargar, solicita al servidor la fecha de la ultima modificacion

del archivo solicitado (last-modified date) y solo si es mas reciente del que

se posee se descarga.

La opcion -P permite especificar donde se almacenaran los archivos des-

cargados, si la carpeta no existe WGET la creara.

Con esta orden tambien se obtienen las estadısticas de la transferencia,

no es necesario anadir ninguna opcion mas.

Si todo ha ido bien, el archivo es almacenado en el cliente WGET, si

ha habido algun problema, la herramienta informa del error.

Para poner en funcionamiento esta mejora en la aplicacion, se han llevado


a cabo las siguientes tareas:

Se han modificado los archivos de la pagina web para poder mostrar

el formulario de la transferencia WGET, estos archivos son aplica-

cion.php e interfaz.js.

En el formulario se tiene que escoger el PC que actuara como destino,

se debe introducir la direccion IP del PC que actuara como servidor

y se tiene que poner el nombre del archivo a transferir, hay que tener

en cuenta que el nombre debe coincidir exactamente con el nombre

del archivo almacenado, para ello se recomienda hacer uso de la he-

rramienta de listado de archivos, con el rol servidor, que fue explicada

anteriormente.

Como en las anteriores modificaciones se han tenido que editar los

archivos del nucleo de la aplicacion, aplicacion.php y red.php de la

carpeta /admin/.

En el archivo aplicacion.php, se anade un nuevo caso en el switch,

llamado “wget”. Aquı se validan los parametros introducidos en el for-

mulario y si no hay problemas con la direccion del servidor, ni con el

PC de destino, se procede a llamar la funcion wget($servidor, $archi-

vo), de la clase PC del archivo red.php. Esta funcion ha sido anadida

al codigo y su tarea es crear el mensaje XML-RPC, donde se introduce

el nombre del archivo y la direccion del servidor al PC que se haya in-

dicado como destino (cliente WGET), y esperar la respuesta de este,

para procesarla y mostrar el resultado por la consola de la aplicacion.

Se han tenido que modificar los archivos configeth.py y commonfunc.py

de los servidores XML-RPC, para poder procesar correctamente el

mensaje XML-RPC proveniente de la aplicacion.

En el fichero configeth.py se ha creado una nueva funcion, wget(self,

servidor, archivo), que se encarga de recibir el mensaje, de crear el


comando WGET adecuado, de llamar a la funcion que realiza la tarea

y genera la respuesta, commonfunc.wget(comando,archivo), y de enviar

la respuesta a la aplicacion.

1 de f wget ( s e l f , s e rv idor , arch ivo ) :

2 ”””

3 Hace t r a n s f e r e n c i a wget

4 ”””

5 comando = ’ wget −N −P /home/ lab r ede s /downloads/wget/ http : // ’ + s t r (

s e r v i d o r ) + ’/ uploads / ’ + s t r ( arch ivo )

6 sa l i da , s a l i d a e r r = commonfunc . wget ( comando , arch ivo )

7


La funcion wget(comando,archivo) del archivo commonfunc.py, se en-

carga de ejecutar el comando en un nuevo subproceso y de almacenar

la salida de este subproceso.

1 de f wget ( comando , arch ivo ) :

2 s a l i d a = [ ]

3 s a l i d a e r r = [ ]

4

5 try :

6 p = subprocess . Popen ( comando , stdout=subprocess . PIPE , s t d e r r=subprocess

. PIPE , s h e l l=True )

7 # La s a l i d a de l wget es por s tder r , pero l a guardamos en l a s a l i d a

normal

8 i f p . s t d e r r :

9 f o r l i n e in p . s t d e r r :

10 l i n e = l i n e . s p l i t ( ’\n ’ ) [ 0 ]

11 s a l i d a . append ( l i n e )

12 e l s e :

13 s a l i d a . append ( ’NONE’ )



16


La salida de este subproceso, sea buena o erronea, se da por la salida

de error estandar, por ello esta salida es guardada y mandada como

respuesta en la salida normal, para que la aplicacion pueda procesarla

correctamente.

Todo el codigo para poner en funcionamiento esta herramienta en la

aplicacion sera mostrado en el apendice.


3.4.4.2. Transferencia TFTP

TFTP son las siglas de Trivial file transfer Protocol (Protocolo de trans-

ferencia de archivos trivial). Es un protocolo de transferencia muy simple

semejante a una version basica de FTP. TFTP a menudo se utiliza para

transferir pequenos archivos entre ordenadores en una red.

Algunos detalles del TFTP:

Utiliza UDP (en el puerto 69) como protocolo de transporte (a dife-

rencia de FTP que utiliza los puertos 20 y 21 TCP).

No puede listar el contenido de los directorios.

No existen mecanismos de autenticacion o cifrado.

Se utiliza para leer o escribir archivos de un servidor remoto.

Soporta tres modos diferentes de transferencia, ‘netascii’, ‘octet’y ‘mail’,

de los que los dos primeros corresponden a los modos ‘ascii’ e ‘ima-

gen’(binario) del protocolo FTP.

Ya que TFTP utiliza UDP, no hay una definicion formal de sesion,

cliente y servidor, aunque se considera servidor a aquel que abre el puerto

69 en modo UDP, y cliente a quien se conecta.

Sin embargo, cada archivo transferido vıa TFTP constituye un inter-

cambio independiente de paquetes, y existe una relacion cliente-servidor in-

formal entre la maquina que inicia la comunicacion y la que responde.

La maquina A, que inicia la comunicacion, envıa un paquete RRQ

(read request/peticion de lectura) o WRQ (write request/peticion de

escritura) a la maquina B, conteniendo el nombre del archivo y el modo

de transferencia.


B responde con un paquete ACK (acknowledgement/confirmacion),

que tambien sirve para informar a A del puerto de la maquina B al

que tendra que enviar los paquetes restantes.

La maquina origen envıa paquetes de datos numerados a la maquina

destino, todos excepto el ultimo conteniendo 512 bytes de datos. La

maquina destino responde con paquetes ACK numerados para todos

los paquetes de datos.

El paquete de datos final debe contener menos de 512 bytes de datos

para indicar que es el ultimo. Si el tamano del archivo transferido es

un multiplo exacto de 512 bytes, el origen envıa un paquete final que

contiene 0 bytes de datos.

Por todas estas caracterısticas, ha sido el metodo elegido para trabajar

sobre UDP.

Para hacer uso de este protocolo, se han tenido que instalar en cada PC

de las subredes tanto el servidor como el cliente TFPT.

Instalacion y configuracion del servidor:

Para la instalacion del servidor se ejecuta el siguiente comando en

consola:

sudo apt -get install tftpd -hpa

Una vez instalado se tiene que editar el archivo de configuracion

sudo nano /etc/default/tftpd -hpa

El archivo de configuracion tendra el siguiente aspecto:

TFTP_USERNAME=‘‘tftp ’’

TFTP_DIRECTORY =‘‘/var/www/uploads/’’

TFTP_ADDRESS = ‘‘0.0.0.0:69 ’’


TFTP_OPTIONS=‘‘--secure ’’

RUN_DAEMON=‘‘yes ’’

OPTIONS=‘‘-l -s /var/www/uploads/’’

La carpeta /var/www/uploads/ es donde se almacenaran los fiche-

ros que se suban a los PCs y que seran transferidos desde el PC servidor

a los clientes TFTP. Esta carpeta fue creada al instalar el servidor

web en los PCs para la transferencia mediante WGET. Si no es ası,

debe ser creada de la misma manera

sudo mkdir /var/www/uploads/

Instalacion y configuracion del cliente:

Para la instalacion del cliente TFTP se tiene que introducir la siguien-

te orden:

sudo apt -get install tftp -hpa

Posteriormente, se crea la carpeta, donde se almacenaran los archivos

recibidos mediante TFTP, y se cambian sus permisos

sudo mkdir /home/labredes/downloads/tftp

sudo chmod 777 /home/labredes/downloads/tftp

Ya estan configurados los PCs para el intercambio de archivos mediante

TFTP, como solo se podra obtener el archivo desde el servidor al cliente

TFTP, solo se usaras la orden get.

Desde el cliente se teclea

tftp -v ‘‘direccion del servidor ’’

tftp > get ‘‘nombre del archivo ’’

tftp > quit


Con la opcion -v se muestran las estadısticas de la transferencia.

Como en el caso del WGET, existen muchos modos y opciones para la

trasnferencia de archivos mediante TFTP, pero para nuestro sistema solo

se usaran las ordenes anteriores.

Con esto ya se tiene almacenado el archivo en el cliente TFTP, siempre

que no se produzca un error.

Para poner en funcionamiento este sistema de transferencia se llevan a

cabo las mismas tareas que en el caso de la transferencia WGET.

Creacion de un nuevo formulario para la transferencia TFTP, con las

mismas opciones que para WGET.

Modificacion de los archivos del nucleo de la aplicacion, en este caso la

opcion del switch es “tftp” y la funcion se llamara tftp($servidor, $ar-

chivo), para validar el formulario, crear el mensaje XML-RPC, man-

darlo y recibir la respuesta.

La mayor variacion con respecto al metodo de transferencia WGET

se observa en el codigo del servidor XML-RPC.

En la funcion tftp(self, servidor, archivo), del modulo configeth.py,

encargada de recibir el mensaje XML-RPC y devolver la respuesta,

no se genera ningun comando, si no que se llama directamente a la

funcion cliente tftp(servidor, archivo), del archivo commonfunc.py, con

la direccion del servidor y el nombre del archivo.

1 de f t f t p ( s e l f , s e rv idor , a rch ivo ) :

2 ”””

3 Hace un get de t f t p a l s e r v i d o r

4 ”””

5 # Aqui se almacenan l a s descargas desde e l s e r v i d o r

6 sa l i da , s a l i d a e r r = commonfunc . c l i e n t e t f t p ( s e rv idor , a rch ivo )

7


Una vez en esta funcion, se procede a hacer la tarea de transferencia


1 de f c l i e n t e t f t p ( s e rv idor , a rch ivo ) :

2 s a l i d a = [ ]

3 s a l i d a e r r = [ ]

4 t ry :

5 comando = ’ t f t p −v ’ + s t r ( s e r v i d o r )

6 p = subprocess . Popen ( comando , s td in=subprocess . PIPE , stdout=subprocess .

PIPE , s t d e r r=subprocess . PIPE , s h e l l=True )

7 comando = ’ get ’ + s t r ( arch ivo )

8 comando stdout = p . communicate ( input=comando ) [ 0 ]

9

10 i f comando stdout :

11 comando stdout = comando stdout . r ep l a c e ( ’ t f tp ’ , ’ ’ )

12 s a l i d a . append ( comando stdout )

13 e l s e :

14 s a l i d a . append ( ’NONE’ )

15

16 whi le ( os . path . e x i s t s (’/ %s ’ %(s t r ( arch ivo ) ) )==False ) :

17 time . s l e e p (1)

18

19 comando = ’mv / %s /home/ lab r ede s /downloads/ t f t p/ %s ’ %(s t r ( arch ivo ) , s t r

( arch ivo ) )

20 sa l ida2 , s a l i d a e r r = invoca ( comando )

21

22 whi le ( os . path . e x i s t s ( ’/home/ lab r ede s /downloads/ t f t p/ %s ’ %(s t r ( arch ivo ) )

)==False ) :

23 time . s l e e p (1)

24

25 i f comando stdout . count (” Error code 1”) :

26 comando = ’rm −r /home/ lab r ede s /downloads/ t f t p/ %s ’ %(s t r ( arch ivo ) )

27

28 sa l ida2 , s a l i d a e r r = invoca ( comando )




En esta funcion se crea un proceso TFTP para conectarse a la di-

reccion del servidor, posteriormente se solicita el archivo especificado

y se guardan las estadısticas de la transferencia. Como el archivo se

guarda por defecto en la carpeta raız, hay que mover dicho archivo a la

carpeta que se ha creado para las descargas TFTP, /home/labre-

des/downloads/tftp/. Si todo va bien se devuelve la respuesta al

modulo tftp de configeth.py para que la mande a la aplicacion, si hay

un error se tiene que borrar el archivo creado en /home/labredes/-

downloads/tftp/, ya que este estara vacıo, y mandar el mensaje de

error.


3.5. Capturas de trafico

Un analizador de trafico en red es una herramienta para desarrollar y

depurar protocolos y aplicaciones de red. Permite al ordenador capturar

diversas tramas de red para analizarlas, ya sea en tiempo real o despues

de haberlas capturado. Por analizar se entiende que el programa puede re-

conocer que la trama capturada pertenece a un protocolo concreto (TCP,

ICMP...) y mostrar al usuario la informacion decodificada. De esta forma, el

usuario puede ver todo aquello que en un momento concreto esta circulando

por la red que se esta analizando. Estos analizadores son muy utiles para

experimentar o comprobar como funcionan ciertos protocolos de red, si bien

su estudio puede resultar poco ameno, sobre todo si se limita a la estructura

y funcionalidad de las unidades de datos que intercambian. Tambien, gra-

cias a estos analizadores, se puede ver la relacion que hay entre diferentes

protocolos, para ası, comprender mejor su funcionamiento.

Existen muchos analizadores de trafico en red, quizas el mas conocido

pueda ser Wireshark, pero para nuestro sistema utilizaremos TCPDump,

ya que no tiene interfaz de usuario, y para iniciarlo de forma remota es mucho

mas sencillo mediante la lınea de comandos.

Para utilizar TCPDump en los PCs de las subredes, este debe ser ins-

talado en cada equipo

sudo apt -get install tcpdump

Posteriormente se creara una carpeta donde seran almacenadas la cap-

tura que haga cada usuario

sudo mkdir /home/labredes/capturas

sudo chmod 777 /home/labredes/capturas

TCPDump puede ser ejecutado con multiples opciones, pero para esta

aplicacion web, unicamente se necesita que se inicie la captura, escribiendo

3.5. CAPTURAS DE TRAFICO 47

la salida en un archivo, y posteriormente finalizar dicha captura.

tcpdump -i eth0 -w /home/labredes/capturas/‘‘nombre_captura ’’.pcap

Con la opcion -i eth0, solo se captura el trafico por la interfaz eth0, la

interfaz de usuario, que es la que se utiliza para conectar las subredes de

practicas, dejando fuera la red de administracion.

Con la opcion -w se guarda la captura en el fichero indicado.

Para finalizar la captura se debe obtener el numero del subproceso aso-

ciado a TCPDump y posteriormente finalizarlo.

sudo ps aux

sudo kill ‘‘subproceso tcpdump ’’

Una vez se tiene la captura, se puede visualizar con el mismo TCP-

Dump

tcpdump -r ‘‘nombre de la captura ’’.pcap

O se puede abrir dicha captura con otro analizador de trafico, como

Wireshark, que tiene interfaz grafica y es mas comodo para el analisis.

3.5.1. Inclusion de esta tarea en el sistema

Como en todas las modificaciones anteriores, para esta tarea se han te-

nido que anadir distintas funciones a los codigos de la aplicacion.

En el servidor web:

Se ha anadido el formulario para la realizacion de la captura, modi-

ficando los archivos aplicacion.php e interfaz.js. Con dicho formulario

se puede iniciar, finalizar u obtener una captura en el PC seleccionado.

Se ha tenido que crear el archivo des cap.php mediante el cual se des-

carga la captura desde el servidor web al PC del usuario.


Las capturas descargadas al servidor web, desde los PCs de las subre-

des se almacenan en la carpeta /home/labredes/capturas/ con el

nombre del usuario que la realiza.

En el nucleo de la aplicacion web se han modificado los archivos apli-

cacion.php y red.php de la carpeta /admin/. En aplicacion.php se ha

anadido el caso “captura” donde se valida el formulario, se llama a la

funcion captura($accion, $usuario) de la clase PC del archivo red.php,

creada para esta tarea, y, una vez realizada la tarea, se procesa la

respuesta del servidor XML-RPC. Para procesar esta respuesta se ha

generado un nuevo array llamado stdfich, por donde se recibira el fi-

chero de la captura, codificado en base64, en el caso de que la accion a

realizar sea la de descargar la captura, que posteriormente sera deco-

dificado y guardado en la carpeta /home/labredes/capturas/ con

el nombre del usuario que realiza la captura.

En la funcion captura($accion, $usuario) de la clase PC del archivo

red.php, se crea el mensaje XML-RPC con la accion a realizar, iniciar,

finalizar u obtener la captura, mas el nombre de la captura, y se envıa al

PC de la subred correspondiente. Posteriormente se recibe la respuesta

y se devuelve para que sea procesada.

En los PCs de las subredes

Se ha tenido que definir una nueva funcion, captura(self, accion, usua-

rio), en el archivo configeth.py para procesar el mensaje XML-RPC de

la captura

1 de f captura ( s e l f , accion , usuar io ) :

2 ”””

3 Hace una captura de t r a f i c o

4 ”””

5 # I n i c i a r una captura

6 i f acc ion == ’ I n i c i a r ’ :

7 nombre = s t r ( usuar io )

8 comando = ’ tcpdump − i eth0 −w /home/ lab r ede s / capturas/ %s . pcap &’ %(

nombre )

3.5. CAPTURAS DE TRAFICO 49

9 sa l i da , s a l i d a e r r = commonfunc . captura ( comando )


11

12 # F i n a l i z a r una captura

13 e l i f acc ion == ’ F ina l i z a r ’ :

14 sa l i da , s a l i d a e r r = commonfunc . captura2 ( )


16

17 # Obtener l a captura de l PC de l a subred

18 e l s e :

19 sa l i da , s a l i d a e r r , f i che roxml = commonfunc . captura3 ( usuar io )

20 return sa l i da , s a l i d a e r r , f i che roxml

Se puede observar que dependiendo de la accion que se vaya a reali-

zar, se llama a una funcion distinta del archivo commonfunc.py. Estas

funciones son captura(comando), captura2() y captura3(usuario). Una

vez realizada la tarea de estas funciones se devuelve la respuesta a la

aplicacion.

En captura(comando), se comprueba si hay alguna captura iniciada

por el mismo usuario, de no ser ası se inicia un nuevo subproceso

TCPdump para comenzar la captura, si ya hay una captura iniciada

se avisa al usuario con un mensaje.

En captura2(), siempre que la captura este iniciada, se obtiene el nom-

bre del subproceso TCPdump y se finaliza, dando ası por concluida

la captura.

En captura3(usuario), si existe una captura del usuario y esta esta fi-

nalizada, se codifica en base64 el fichero de la captura y se manda a

la aplicacion web. Una vez mandada, la captura se borra del PC de la

subred.

Ademas de borrarse cuando es enviada, las capturas se borran al ini-

ciar, finalizar o reiniciar la aplicacion. Hay que tener en cuenta, que

cada usuario no puede hacer mas de una captura de forma simultanea,

y esta siempre se almacena con el mismo nombre, ası que un mismo

usuario solo tiene acceso a la ultima captura realizada.


3.6. Resumen de las mejoras implementadas

1. Se ha anadido el Sabado y el Domingo a los dıas disponibles para reali-

zar las practicas, el administrador es el que decidira si quiere habilitar

turnos en estos dıas

2. Gracias al comando configure se podran configurar los conmutadores

lınea a lınea y mediante el comando show se podra consultar en todo

momento el estado de los conmutadores.

Ademas el uso del caracter ‘?’ como argumento de los comandos, tanto

para show como para configure, permite conocer los posibles valores

que siguen a ese comando.

3. Se puede conocer tanto la informacion de las configuraciones de red

como las tablas de rutas de cada uno de los equipos de la red.

4. Se pueden realizar operaciones con archivos en la subred de practicas,

se pueden subir archivos a los equipos, ver los archivos almacenados y

borrarlos.

Ademas se pueden intercambiar los archivos entre los equipos mediante

los protocolos HTTP (sobre TCP) y TFTP (sobre UDP).

5. Para analizar el trafico generado entre los equipos se permite la reali-

zacion de capturas de ese trafico.

Mejoras implementadas en el sistemabibing.us.es/proyectos/abreproy/12106/descargar... · tos de la...

Documents

Transcript of Mejoras implementadas en el sistemabibing.us.es/proyectos/abreproy/12106/descargar... · tos de la...