Traducido del catalán al español - www.onlinedoctranslator.

com

SNIFFER
PROYECTO FINAL DE CARRERA

FACULTAD DE TELECOMUNICACIONES
DE BARCELONA
SNIFFER

Título: SNIFFER

Volumen: 1/1
Alumno: Joaquim Orra Serra

Director/Ponente: Isaac Gelado Fernández

Departamento: Arquitectura de Computadores
Fecha: 28 de Junio de 2010

1
SNIFFER

DATOS DEL PROYECTO

Título: SNIFFER

Volumen: 1/1
Alumno: Joaquim Orra Serra

Director/Ponente: Isaac Gelado Fernández

Departamento: Arquitectura de Computadores
Fecha: 28 de Junio de 2010

MIEMBROS DEL TRIBUNAL

Presidente: Carlos Villavieja Prados

Vocal: Gregorio Vázquez Grau

Secretario: Isaac Gelado Fernández

CALIFICACIÓN

Calificación numérica:

Calificación descriptiva:

Fecha:

2
SNIFFER

ÍNDICE

1 Introducción................................................. .................................................. ...............6

1.1 La memoria............................................... .................................................. .........6
1.2 El proyecto............................................... .................................................. ...........6
1.3 Historia y precedentes.............................................. ..............................................7
1.4 Utilidad................................................ .................................................. ................7
1.5 Objetivos................................................ .................................................. ............8
2 Estado del arte............................................. .................................................. ..................9
2.1 Introducción a los sniffers.............................................. ...........................................9
2.2 La librería libpcap.............................................. .................................................9
2.3 historia de las capturas de tráfico........................................... ..............................10
2.4 Capturas de tráfico.............................................. .................................................10
2.5 Tecnologías de distribución.............................................. ...................................20
2.5.1 Introducción.............................................. .................................................. 20
2.5.2 Historia.............................................. .................................................. ......21
2.5.3 RPC.............................................. .................................................. ...........21
2.5.4 RMI.............................................. .................................................. ...........23
2.5.5 CURVA.............................................. .................................................. .....24
2.5.6 J2EE.............................................. .................................................. ..........26
2.5.7 Servicios Web............................................. .................................................. 27
2.6 Tecnologías web............................................................... .................................................28
2.6.1 Struts.............................................. .................................................. .........28
2.6.2 JSP .............................................. .................................................... ............ 29
2.6.3 AJAX.............................................. .................................................. ........29
3 Análisis de los requisitos............................................... .................................................. 31
3.1 Requisitos funcionales............................................... ............................................31
3.2 Requisitos no funcionales.............................................. ........................................31
4 Metodología y planificación............................................... .........................................34
4.1 Introducción (Metodologías de ingeniería del software)......................................34
4.2 Tipos de metologías.............................................. ..............................................35
4.2.1 Metodología secuencial............................................. ................................35
4.2.2 Metodología en círculo............................................ ....................................35
4.2.3 Metodología incremental............................................. ..............................36
4.2.4 Metodología ágil............................................. ...........................................36
4.2.5 Metodología basada en prototipos........................................... ...................37
4.3 Descripción metodología escogida.............................................. ........................39
4.4 Planificación temporal (Diagrama de Gonn).......................................... ..............39
4.5 Planificación económica.(Programador analista consultor)..................................43
4.5.1 Coste del hardware............................................ ..........................................43
4.5.2 Coste del software............................................................ ...........................................43
4.5.3 Coste de recursos humanos........................................... ................................44
4.5.4 Coste total............................................. .................................................. .....44
5 Diseño ................................................. .................................................... .................... 45
5.1 Consideraciones de diseño.............................................. ....................................47
5.2 Código heredado ............................................... .................................................... ...... 48
5.3 Cambios en legacy code............................................. .............................................49

3
SNIFFER

5.4 Aplicación web............................................... .................................................. ....50

5.4.1 Partes aprovechamiento de la aplicación de escritorio...................................... ......50
5.4.2 El código de Tomcat........................................... ...........................................51
5.4.2.1 Estructurado.............................................. ...........................................52
5.4.2.2 Interconexión del código............................................ ..........................56
5.4.3 El código del ejb......................................... .................................................. 63
6 Implementación.................................................. .................................................. ........67
6.1 Tecnologías utilizadas............................................... ........................................67
6.1.1 Lenguaje de programación............................................ ...........................67
6.1.2 Implementación de CURVA............................................ ............................67
6.1.3 Frameworks.............................................. .................................................75
6.1.4 Servidores.............................................. .................................................. ....75
6.1.5 XML.............................................................. .................................................. ..........75
6.1.6 Ajax.............................................. .................................................. ...........75
6.1.7 Displaytag.............................................. .................................................. ..75
6.1.8 Entorno integrado............................................. ..............................................76
6.2 Detalles de implementación............................................. ........................................76
6.2.1 Instalar el servidor de capturas........................................ ........................76
6.2.2 Instalar servidor Jboss y Tomcat........................................ ......................79
6.2.2.1 Integración de los servidores............................................ .......................79
6.2.2.2 Lookup de Tomcat en Jboss.......................................... .....................80
6.2.3 Comunicación Jboss con el servidor de capturas...............80
6.2.4 Implementación del EJB.......................................... ...................................80
7 Pruebas de sistema............................................... .................................................. ......83
7.1 Diseño................................................................ .................................................. .............83
7.2 Resultados................................................ .................................................. ...........84
8 Análisis económico................................................................ .................................................. .....89
8.1 Análisis temporal............................................... .................................................. 89
8.2 Análisis económico............................................... .................................................90
9 Conclusiones y trabajo futuro.............................................. ...........................................91

Apéndice1:Posibles errores de la aplicación........................................... .....................................94

Bibliografía................................................. .................................................. .......................100

4
SNIFFER

ÍNDICE DE FIGURAS

Figura 1: Captura de pantalla de Wireshark........................................ .............................................11

Figura 2: Captura de pantalla de IPTraf.................................................... .................................................. .14
Figura 3: Tabla resumen de los diferentes sniffers........................................ ............................................17
Figura 4: Partes de un RPC.......................................... .................................................. ........................22
Figura 5: Partes de un sistema RMI......................................... .................................................. ............24
Figura 6: Principales características de CORBA........................................... ....................................25
Figura 7: Estructura cliente/servidor CORBA.......................................... ...........................................26
Figura 8: Tabla de requisitos funcionales........................................... .................................................. ..32
Figura 9: Tabla de requisitos no funcionales.......................................... ................................................34
Figura 10: Esquema de la Metodología secuencial.......................................... ..................................36
Figura 11: Esquema metodología círculo............................................ .................................................37
Figura 12: Esquema metodología por prototipos.............................................. .......................................39
Figura 13: Planificación temporal.............................................. .................................................. .........43
Figura 14: Tabla de planificación de costes del proyecto..................................................... ................................45
Figura 15: Tabla de planificación de costes totales......................................... .........................................45
Figura 16: Esquema general de la aplicación......................................... ................................................50
Figura 17: Esquema MVC............................................. .................................................. ...................52
Figura 18: Esquema interconexión código con struts........................................... .................................57
Figura 19: Pantalla Inicial............................................. .................................................. ...................58
Figura 20: Llamamiento de capturas............................................ .................................................. .................59
Figura 21: Lista de capturas con DisplayTag.......................................... .........................................60
Figura 22: Recuperación de las capturas........................................... .................................................. .61
Figura 23: Pantalla de capturas............................................ .................................................. .............62
Figura 24: Abrir capturas............................................. .................................................. .....................62
Figura 25: Reconfigurar capturas............................................. .................................................. ........63
Figura 26: Petición de una captura.......................................... .................................................. .............65
Figura 27: Pasos de una Captura.......................................... .................................................. .............66
Figura 28: Características de diferentes implementaciones de CORBA......................................... ....71
Figura 29: Configuración.............................................. .................................................. .....................84
Figura 30: Captura resultante............................................. .................................................. ................84
Figura 31: Configuración ................................................ ... ............................................................. ... .................... 85
Figura 32: Configuración .............................................. .................................................... ..................... 86
Figura 33: Listado de capturas............................................ .................................................. ...............86
Figura 34: Listado de capturas abiertas........................................... .................................................. ....87
Figura 35: Abrir las capturas............................................ .................................................. ................88
Figura 36: Evolución temporal.............................................. .................................................. ..............90
Figura 37: Tabla de costes del proyecto.......................................... .................................................. ....91
Figura 38: Tabla de costes totales del proyecto......................................... ..............................................91

5
SNIFFER

1 Introducción

Durante los siete meses que he estado realizando el Proyecto Final de Carrera, muchas
personas me han preguntado qué proyecto estaba desarrollando. Yo respondía, un
Sniffer. Esta respuesta no satisfacía, por tanto, pensé en otra respuesta. Ésta fue, un
capturador de tráfico de internet. Al ver que esta respuesta tampoco acababa de
satisfacer, y que es un concepto difícil de entender por quienes son ajenos a este mundo,
pensé en algo metafórico conocido por todos.

La respuesta fue contar lo que hace la policía cuando pincha una línea telefónica.
Esa respuesta fue la definitiva.

1.1 La memoria

La memoria del Proyecto Final de Carrera consta de distintos apartados.

En el capítulo dos se explican los distintos tipos de sniffers que existen y, las
diferentes tecnologías de distribución y web que existen. En el capítulo tres se ha
estudiado los diferentes requisitos que debería cumplir la aplicación. El capítulo cuatro
habla de la metodología que he seguido junto con una planificación económica y
tormenta. El quinto y sexto capítulos serían los más densos que se explica el diseño
del Proyecto y su implementación.

Una vez terminada la aplicación es necesario realizar una serie de pruebas para verificar que se
cumplen los requisitos establecidos en el capítulo tres. Estas pruebas y su descripción se
encuentran en el capítulo siete.

El análisis económico, es decir, el coste que tiene el proyecto, lo encontramos en el penúltimo

apartado.

El último capítulo son las conclusiones que se han extraído de la realización del proyecto y
posibles nuevas funcionalidades para incorporar en un futuro.

1.2 El proyecto

El proyecto ha tenido dos partes bastante diferenciadas.

La primera fue documentarme sobre qué es y cómo trabajan los sniffers, instalar,
hacer funcionar, entender la aplicación de escritorio sobre la que desarrollé mi
proyecto. Esta parte fue complicada debido a mi inexperiencia con curva, con sniffers
y con aplicaciones de escritorio.

6
SNIFFER

La segunda fue el desarrollo de una aplicación web que se comunicaba con el servidor de
capturas de la aplicación original. Esta segunda fue bastante complicada ya que la
aplicación tenía que comunicarse con tres elementos imprescindibles; el servidor de
capturas ya comentado y dos servidores de aplicaciones con sus correspondientes
máquinas virtuales.

Estas dos partes han sido asentadas cronológicamente una después de la otra ya que
primero era necesario investigar y profundizar en lo que había hecho y después crear
una versión mejor.

Gracias al proyecto hemos pasado de un sniffer que era una aplicación de escritorio a tener
una aplicación web que integra un sniffer. Veremos cuáles son los cambios que se han
realizado en la aplicación original para adaptarla y también cómo se ha diseñado el entorno
web para albergar un servidor de capturas desarrollado con Curva y C++.

Éste es un proyecto muy interesante para quienes quieran adentrarse en el mundo de los
sniffers.

1.3 Historia y precedentes

La historia del proyecto empezó caro el día que fui a hablar con Isaac Gelado. Yo
quería un proyecto de J2EE puesto que es el lenguaje de programación que utilizo en
el trabajo. Ese día me propuso hacer un proyecto y me dijo que crees si lo quería
llevar a cabo.

Dejé pasar el verano y en septiembre del 2008 volví a su despacho. Me dijo que el
proyecto que me había comentado estaba asignado. Sin embargo, hemos propuesto
otro muy interesante. El proyecto trataba de tomar una aplicación de escritorio y
convertirla en una aplicación web. Además, la aplicación era un Sniffer. La idea me
gustó tanto que me eché de cabeza.

1.4 Utilidad

Sniffer bien del inglés “sniff” que significa olisquear. Es esencialmente un programa que
captura las tramas de la red y que generalmente se utiliza para gestionar redes.

Es común, debido a la topología de red, tener un medio de transmisión compartido por varias
máquinas y dispositivos. Por tanto un ordenador, puede capturar tramas que no están
destinadas a él y de esta manera gestionar una red.

Permite ver y analizar la información real que viaja por la red. Por este motivo, los sniffers
han sido utilizados por muchos hackers para capturar contraseñas y nombres.

7
SNIFFER

de usuario que viajan por la red.

Permite analizar errores en la red y ver por ejemplo por qué un ordenador A no puede
establecer comunicación con un ordenador B.

Así pues, vemos que un sniffer es una herramienta muy potente y eficaz si se quiere entender
cómo funciona una red.

Los sniffers tienen otras utilidades como pueden ser detectar problemas de conectividad
en una red o depurar aplicaciones de red. Permite estudiar las redes descubriendo
puntos críticos como los cuellos de botella y las vulnerabilidades de la red.

Los sniffers también son útiles para detectar intrusos en la red o para investigar a los
posibles hackers de una red. Muchos sniffers dedicados a investigar hackers permiten la
creación de registros de red de modo que los hackers puedan saber que son
investigados.

1.5 Objetivos

El principal objetivo de mi proyecto final de carrera es realizar una aplicación web

eficiente y usable utilizando el servidor de capturas que utilizaba la aplicación de
escritorio que me proporcionó Isaac Gelado utilizando tecnologías “open source”.

El primer objetivo es que la aplicación muestre capturas por pantalla. Dentro de este
apartado podríamos definir objetivos menos importantes pero no menos necesarios.
Guardar las capturas, ver los diferentes sniffers que se encuentran en la red, poder filtrar
capturas por ip, puerto y protocolo, reconfigurar el filtro de capturas son objetivos que se
tendrán que ir alcanzando una vez se haya llevado a cabo el primero objetivo
mencionado anteriormente.

Uno de los objetivos más importantes es que la aplicación sea eficiente y rápida. Que el código de
que la forma sea robusto y las tecnologías utilizadas también. Habrá, por tanto, que razonar muy
bien a la hora de tomar decisiones de diseño de la aplicación.

La aplicación deberá ser vistosa y entendedora por tanto los estilos y las decisiones
estructurales también tendrán que ser meditadas con detenimiento.

8
SNIFFER

2 Estado del arte

2.1 Introducción a los sniffers

Comenzaremos este apartado definiendo qué es un sniffer. Un sniffer, básicamente, es un

programa que captura las tramas de red. Un sniffer puede tener distintas utilidades como
pueden ser analizar y detectar errores o puntos débiles en la red. También puede utilizarse
para la ingeniería inversa de protocolos. Los sniffers también pueden utilizarse para capturar
contraseñas, escuchar chats, interceptar correos electrónicos, etc.

2.2 La librería libpcap

La mayoría de sniffers que corren en sistemas Unix tienen como librería base
"libpcap".

Libpcap es una librería “open source”, la cual ofrece un apio para poder realizar capturas
de tráfico. Incluye un analizador sintáctico para cadenas de filtrado lo que la hace
relativamente fácil de utilizar. Se encuentra disponible para C y C++. Existen sin embargo
“wrappers” que son finas capas que transforman las interfaces de las librerías para que
sean entendibles por otros lenguajes. Por pcap existen wrappers para Java y .NET.

Hay que decir que para windows también existe una versión “winpcap”. Estas librerías
contienen métodos de bajo nivel, que permiten realizar capturas de tráfico a aplicaciones
web o de escritorio. Sin embargo no hay que pensar que libpcap y winpcap son la misma
librería, mientras libpcap accede a un módulo dentro del kernel, winpcap no lo hace ya que
los sistemas windows no implementan este módulo. El filtrado lo realizan dentro de la misma
librería con lo que la hace menos eficiente.

Para utilizar esta librería dentro de cualquier aplicación primero hay que buscar un
dispositivo para empezar la captura, extraer la dirección de red y su mascara, definir el
filtro de las capturas, compilarlo y relacionarlo con la captura y finalmente empezar la
captura. La captura será en modo promiscuo, es decir, que capturará todos los paquetes
de red aunque no pasen por la máquina donde se encuentra instalado el sniffer. Por
tanto, en este caso, será necesario que el usuario ejecute el sniffer como
Administrador(superusuario).

Cabe señalar que libpcap también cuenta con métodos que detectan posibles errores que podrían hacer
inviables las capturas.

9
SNIFFER

2.3 Historia de las capturas de tráfico

Las capturas de tráfico se empezaron a utilizar sobre todo en sistemas UNIX ya que se
comprobó que eran muy eficaces para monitorizar y detectar errores y puntos débiles

en las redes. Para que esta técnica sea eficaz debe realizarse en cualquier
punto de la red, especialmente en zonas donde la red pueda ser vulnerable.

Debido a la importancia de esta técnica, es lógico pensar que el kernel ofrezca

facilidades a las aplicaciones, a nivel de usuario, para poder acceder a estos datos.

En 1980 salió "ICMU/Standford Packet Filter (CSPF)" que ofrecía grandes ventajas. Sin
embargo con la progresiva migración hacia sistemas RISC, este filtro diseñado para
máquinas basadas en pilas de memoria, decayó enormemente. Estas nuevas
arquitecturas hacían un uso exhaustivo de los recursos.

En 1992 aparece BSD “Packet Filter” que constituye una nueva y mejor
implementación de captura de paquetes en el kernel. Este sistema está diseñado
especialmente para máquinas basadas en registros. Además presenta un nuevo
esquema de filtrado que le hace mucho mejor que sus antecesores. De hecho, hoy en
día, una versión de éste es la más utilizada y está presente en el kernel de muchos
sistemas operativos.

Los sistemas operativos basados en microkernels también pueden realizarse capturas.

Aunque no se puede implantar en el kernel un módulo, ya que tampoco existe una
entrada/salida, se puede implementar un sistema aparte en el servicio TCP/IP en
ejecución. De todas formas no hay ningún trabajo al respecto debido a que casi no
existen sistemas operativos de este tipo.

El “BSD Packet sniffer” puede utilizarse directamente oa través de un apio.

Actualmente la única apio que existe para sistemas UNIX es libpcap.

2.4 Capturas de tráfico

En este capítulo explicaré brevemente los distintos sniffers que existen. Todos ellos
permiten examinar datos de una red viva y solucionar problemas en redes de
comunicación.

Wireshark

Antes se conocía con el nombre de Ethereal. Es parecido atcpdump, pero incluye

10
SNIFFER

una interfaz gráfica con la posibilidad de generar gráficas de las capturas, muchas
opciones de organización y un filtrado de información. Es capaz de detectar problemas
en la red.

Los aspectos más importantes son:

● Sostenido bajo la licenciaGPL(General Public License)

● Trabaja con modo promiscuo y con modo no promiscuo.
● Puede leer todos los datos de la red y guardarlos en un archivo.
● Basado en la librería pcap.
● Interfaz muy flexible.
● Gran capacidad de filtrado.
● Admite el formato de archivo tcpdump.
● Se ejecuta en más de 20 plataformas.
● Compatible con más de 480 protocolos.
● Puede leer capturas de pantalla de más de 20 productos.

Para capturar paquetes normalmente se necesitan permisos de ejecución especiales. De

ahí que Wireshark se ejecute con permisos de Superusuario.

La siguiente figura (Figura 1) muestra un ejemplo de los gráficos que genera.

Figura 1: Captura de pantalla de Wireshark

11
SNIFFER

Ettercap

Es un sniffer por redes conmutadas “Open Source”. Soporta direcciones activas y pasivas de
diferentes protocolos (incluso cifrados como SSH y HTTPS). Hace posible la inyección de datos
en una conexión establecida. Es capaz de filtrar manteniendo la conexión gracias a que
puede establecer un Ataque Man-in-the-middle(Spoofing) o envenenamiento de tablas ARP
(arp Spoofing). Este sniffer tiene como librerías base libpcap, libnet, libpthread y Zlib.
También es capaz de detectar un sistema operativo remoto. Ettercap genera un archivo log
donde guarda, en formato binario, las capturas realizadas.

Para la mayoría de sus funcionalidades es necesario instalar el plugin necesario.

Los aspectos más importantes son:

● Inyección de datos a una conexión establecida emulando pedidos o

respuestas mientras la conexión está activa.
● Compatibilidad HTTPS. Es decir, puede interceptar conexiones HTTP
SSL, supuestas seguras, incluso si son a través de un proxy.
● Compatibilidad SSH. Es decir, puede interceptar usuarios y contraseñas
en conexiones SSH.
● Intercepta tráfico remoto a través de un túnel GRE.

TCPDump

Es un sniffer por redes TCP/IP. Monitoriza los paquetes que entran y salen de la
interfaz de red y los presenta en formato legible. Permite utilizar filtros mediante una
expresión de búsqueda, de modo que sólo muestra los paquetes cuya cabecera
coincide con ella. También puede utilizarse para la ingeniería inversa de protocolos de
red. Para capturar todo el tráfico dirigido a la interfaz, debe colocarse en modo
promiscuo. Puede capturar paquetes en redes con enrutamientos no inteligentes
como podría ser un swicth o un router. En redes WI-FI puede capturar todos los
paquetes que lleguen a la antena y sean reconocidos, de cualquier red disponible e
incluso varios canales simultáneos, siempre que sean adyacentes y que la tarjeta no
sea muy selectiva en frecuencia. Utiliza la librería pcap.

Win Sniffer

Como todos los sniffers sirve para administrar redes, pero a diferencia de otros permite
reconstruir el tráfico de la red de forma simple y comprensible mientras otros sniffers
sólo muestran los paquetes capturados. Puede capturar paquetes en modo promiscuo.
Además, puede descodificar FTP, POP3, HTTP, ICQ, SMTP, Telnet, IMAP y contraseñas
NNTP. Tiene un filtro por paquetes muy intuitivo. Tiene la posibilidad de ser

12
SNIFFER

dejado días enteros capturando tráfico ya que las capturas las guarda en logs.

Darkstat

La diferencia de este sniffer en comparación con otros es que una vez hechas las
capturas genera un informe en formato HTML y permite realizar estadísticas de
direcciones que se generan durante la comunicación entre hosts, del tráfico que se
produce y de los diferentes puertos utilizados por los diversos protocolos.

Taffic-Vis

Este sniffer monitoriza tráfico TCP/IP y con esta información genera gráficos con ASCII,
HTML o Postscript. También permite analizar tráfico entre hosts para determinar qué
hosts se están comunicando y el volumen de la comunicación. Utiliza como muchos otros
sniffers la librería libpcap.

Kismet

Este sniffer funciona con cualquier tarjeta de cámara que admita monitoreo sin procesar
y puede capturar tráfico 802.11b, 802.11ay 802.11g. Se diferencia de otros sniffers
inalámbricos por su funcionamiento pasivo. Es decir, que captura tráfico sin enviar
ningún paquete detectable, permiten detectar la presencia de diferentes puntos de
acceso y clientes asociados unos con otros.

Encontramos tres partes diferenciadas:

● Contiene una sonda que puede utilizarse para recoger paquetes.

● Un servidor que se puede utilizar junto con la sonda o consigo
mismo extrapolando la información y organizándola.
● El cliente el que se comunica con el servidor y muestra la información
que previamente ha recogido el servidor.

Hunt

Es otro ejemplo de sniffer que funciona con redes ethernet. Hunt examina la red
por ciertas firmas y diferentes patrones en cuyo tráfico indican un evento concreto
o una condición. Cuando reconoce una firma hunt entra en la sesión y da acceso a
una conexión establecida que puede ser utilizada para explorar la red.

13
SNIFFER

Hunt tiene cuatro rasgos distintivos:

● Le permite especificar qué conexión desea capturar en lugar de

tener que ver todo en un registro.
● Detecta una conexión ya establecida.
● Ofrece spoofing tools.
● Ofrece capturar sesiones activas.

LinSniffer

Es un sniffer muy simple cuyo objetivo principal es capturar nombres de usuario y passwords. De
hecho, la información que muestra es perfecta para ver passwords y nombres de usuario pero no
está preparado para un análisis más detallado.

IPTraf

Es un monitor de red que genera gran variedad de estadísticas como información TCP,
contador UDP, información ICMP y OSPF, estado de los nodos, errores IP, etc.
También contiene filtros para diferentes protocolos para ver tan sólo la información que
nos interesa.

Un ejemplo de la interfaz que tiene IPTraf se puede ver en la siguiente figura

(Figura 2):

Figura 2: Captura de pantalla de IPTraf

14
SNIFFER

Snort

Es un sniffer/logger que sirve para detectar intrusiones y ataques del tipo búfer
overflows, CGI, SMB, escaneo de puertos, etc. Es capaz de enviar alertas en tiempo
real, enviándolas directamente al archivo de Unix syslog o incluso a un sistema
Windows mediante SAMBA. Tiene muchos filtros y ciertos patrones. También dispone
de actualizaciones constantes para hacer frente a ataques, barridos o
vulnerabilidades que se vayan detectando. Podemos ver por consola los paquetes
que se van registrando y guardarlos en logs.

Otros sniffers:

Linux_sniffer:Es similar a LinSniffer. Da una salida un poco

más detallada qué en el caso de Linsniffer y es muy fácil de utilizar.

NFR:Network Flight Recorder es un sniffer comercial para detectar

intrusiones en los sistemas.

QUESO:Sirve para averiguar qué Sistema operativo corre en una

máquina remota, analizando las respuestas TCP.

IPLog:Es un logger de tráfico TCP/IP, UDP e ICMP el que detecta

escaneos y posibles ataques para sistemas Unix.

Cerberus Internet Scanner:CIS es un escaner el que ayuda a los

administradores de red de windows a detectar y corregir agujeros de seguridad. Es capaz de
generar documentos HTML a partir de los resultados del escaneo.

Retina:Es un conocido escaneador de vulnerabilidades de sistema. Incluye

la forma de arreglarlos. Incluye muchas funcionalidades como puedes ser generación de reportes o la
detección de reportes
sistemas operativos remotos.

Vetescan:Es un escaneador de vulnerabilidades que tiene programas para

comprobar y explorar errores de windows y Unix y corregirlos. Tiene la habilidad de saber
qué servicios están corriendo en cada uno de los hosts remotos y generar gráficos de la red.

Cheops:Programa que sirve para mapear redes locales y remotas.

Muestra el Sistema Operativo de las máquinas de la red. Tiene la habilidad de saber qué
servicios están corriendo en cada uno de los hosts remotos y generar gráficos de la red.

15
SNIFFER

Ngrep:Programa sensible a pcap que permite especificar expresiones

regulares extendidas contra la carga de datos de los paquetes. Reconoce TCP, UDP e ICMP
por redes ethernet a través de PPP, SLIP e interfaces nulas.

Sam Sapade:Es un programa online para investigar una dirección IP y

encontrar spammers.

Dsniff:Es un sniffer para buscar paswords y más información de una red

incluyendo sofisticadas técnicas para defender la protección de los switchers de la red.

En la Figura 3 se puede ver una tabla con las principales características de los sniffers:

16
SNIFFER

Figura 3: Tabla resumen de los distintos sniffers

Sniffers LL TXCT PA LLB IDC PE FC DA DSO IG GC GD GG MP

Wireshark GPL Ethernet Más de 480 Libpcap Si Windows Mac Si Si No Si Si Si Si P/NP
Linux
Ettercap OS LAN Muchos Libpcap, No Windows Si Si Si Si Si No No P/NP
libnet, Mac Linux
libpthread
, Zlib
TCPDump OS TCP/IP libpcap No Linux Si Si No No No No No P/NP
Mac
Win Shareware TCP/IP FTP, pop3 winpcap No Windows Si No No Si Si No No P/NP
Sniffer http,icq
smtp,telnet
imap,nntp
Darkstat LGPL TCP/IP http libpcap No Linux Mac No No No Si Si Si Si P/NP
Taffic-Vis BSD TCP/IP ___ libpcap No linux No No No Si Si Si Si P/NP
Kismet GPL LAN 802.11b No Linux Mac No Si No Si Si No Si
802,11a ___ __
802.11g
Hunt GPL ethernet Tcp GlibC No Linux Si Si No Si Si No No
udp __
arp, icmp

17
SNIFFER

Sniffers LL TXCT PA LLB IDC PE FC DA DSO IG GC GD GG MP

LinSniffer GPL Ethernet __ ___ No Linux No Si Si No No No No __

Linux_snif Ethernet __ ___ No Linux No Si Si No No No No __
hacer GPL
NFR OPL LAN __ ___ Si Windows Si Si No Si Si Si Si P/NP
QUESO GPL TCP/IP __ ___ No Linux No No Si No No No No __
IPLog LAN tcp/ip ___ No Linux Si Si No No No No No P/NP
icmp
GPL udp
IPTraf LAN Tcp ncursas No Linux Si No Si Si Si Si No NP
icmp
udp
GPL ospf
Cerberus LAN Tcp No windows No Si No Si Si Si No NP
Internet smtp ___
Scanner ftp
GPL pop3
Retina Shareware LAN ___ ___ No Windows No Si Si Si Si Si Si __
Vetescan LAN ___ ___ No Windows No Si Si No No No No __
GPL linux
Cheops LAN ___ ___ No Windows No Si Si Si Si Si Si __
GPL linux
Ngrep Ethernet Ipv4,icmp libpcap No Linux Si No No Si Si Si No __
BSD tcp,udp Mac,windows

18
SNIFFER

Sniffers LL TXCT PA LLB IDC PE FC DA DSO IG GC GD GG MP

Sam Ethernet __ ___ No All No No No No No No No __

Sapade Free
DSniff Freeware LAN __ ___ No windows Si Si No No Si Si No __
Snort GPL LAN __ ___ No Linux Si Si No N Si Si No __

Licencia: LL
Tipo de redes de las que puede capturar tráfico: TXCT
Protocolos que admite: PA
Librería base: LLB
Inyección datos en la conexión: IDC
Plataforma de ejecución: PE
Filtrar capturas: FC
Detección ataques: DA
Detección sistema operativo: DSO
Interfaz gráfica: IG
Guardar capturas: GC
Generación de documentos: GD
Generación de gráficos: GG Modo
Promiscu/No promiscu: MP

19
SNIFFER

2.5 Tecnologías de distribución

Antes de empezar a explicar las diferentes tecnologías de distribución haremos un breve

comentario sobre lo que significa Sistemas de distribución.

2.5.1 Introducción

Un sistema distribuido se define como: una colección de computadoras separadas

físicamente y conectadas entre sí por medio de una red de comunicaciones distribuida.
Cada máquina tiene sus propios componentes de hardware y software y el usuario no
percibe cuando accede a recursos remotos, a recursos locales oa un grupo de
computadores que utilizan un software para conseguir un objetivo común.

La ventaja de los sistemas distribuidos es que cuando un componente del sistema

se descompone otro componente puede realizar su función. Esto se llama
“Tolerancia a Fallos”.

El tamaño del sistema puede ser muy variado, desde decenas de hosts(red de área local) y
cientos de hosts(red de área metropolitana), hasta millones de hosts (Internet).

Algunas de las características más importantes a las que desea llegar un sistema
distribuido son:

● Para los usuarios es similar al Sistema Centralizado. (Un computador).

● Se ejecuta en múltiples computadores.
● Tiene varias copias del mismo Sistema Operativo o de distintos Sistemas
Operativos que dan los mismos servicios.
● Tiene transparencia. (La utilización de múltiples procesadores y el acceso
remoto es invisible)

Una invocación generalmente consta de los siguientes pasos:

● Encapsulado de los parámetros (Utilizando la funcionalidad de serialización)

● Invocación del método (Siempre lo realiza el cliente). El invocador, por tanto, se
queda normalmente esperando una respuesta.
● Cuando el servidor termina la ejecución serializa el valor de retorno (si
existe) y lo envía al cliente.
● El cliente continúa su ejecución como si la invocación hubiera sido
local.

20
SNIFFER

2.5.2 Historia

La base de aplicaciones distribuidas son los ordenadores y concretamente la

aparición de internet. Su origen lo podemos encontrar en la tesis doctoral de Leonard
Kleinrock, en la que se establecieron los principios de las redes de paquetes y que
sirvió para el desarrollo del ARPNET. Sin embargo fue Bob kahn quien tuvo el papel
más importante en el desarrollo de ARPNET, alrededor de 1969.

De todas formas no fue hasta la aparición de TCP/IP, diseñado por Bob Kahn y Viton
Cerf, y con él la interconexión de redes en 1974 que las redes distribuidas tomaron un
cariz más importante el concepto de redes distribuidas.

En 1983, se define el protocolo TCP/IP como protocolo oficial y surgen las primeras redes
aplicaciones distribuidas.

El modelo dominante en las redes de comunicaciones era, y es, cliente-servidor,

especialmente útil para la comunicación de ordenadores en torno al cual se construye
una entrada y una salida. En 1985 se publicó un artículo de Birrell y Nelson en el que se
decía que a un programa se le permitía llamar a procedimientos ubicados en otras
computadoras. De esta forma el pogramador se preocupa tan sólo de la E/S. Este método
se conoce como (RPC).

Las tecnologías actuales se basan en el middleware. Éste lo podríamos definir como una
capa software entre los procesos de usuario y los del sistema operativo. Por tanto para el
programador queda escondida la complejidad del sistema operativo. Dentro de esta
tecnología encontramos middleware orientado a objetos que ha desarrollado Sun
Microsistems y la middleware orientado a componentes desarrollada por CORBA:OMG.

2.5.3 RPC

RPC proviene del inglés “Remote Procedure Call”. Es un protocolo que permite que un
programa ejecute código en una máquina remota sin preocuparse por la comunicación entre
ellas. RPC fue un gran antes, ya que al usar sockets, el programador tenía que estar atento a
las comunicaciones. Los RPC se utilizan ampliamente en entornos cliente-servidor. Siendo el
cliente quien inicia una petición para que se ejecute cierto código en el servidor.

Existen distintos tipos de RPCs, muchos de ellos estandarizados como puede ser el RPC
de Sun, ONC RPC, el RPC de OSF llamado DCE/RPC y el modelo de Objetos de
Componentes de Microsoft DCOM. Sin embargo ninguno de estos modelos es compatible
entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz IDL que

21
SNIFFER

define los métodos exportados por el servidor.

Hoy en día es muy utilizado el XML como lenguaje para definir IDLs y HTTP como
protocolo de red.

RPC de Sun

Uno de RPC podría ser el RPC de Sun. Éste proporciona un lenguaje de definición de
interfaz llamado XDR(eXternal Data Representation) y un compilador de interfaces
llamado rpcgen. A partir de la interfaz definida con XDR y del compilador rpcgen se
obtienen la mayoría de los componentes de una RPC. Es decir:

● El stub del cliente.

● El programa principal del servidor.
● Los archivos de definición o de cabeceras del stub del cliente y las rutinas de
servicio del servidor.
● Las rutinas de serialización de datos.

Un diagrama del funcionamiento del RPC se puede ver en la Figura 4.

Figura 4: Partes de un RPC

El lenguaje XDR puede utilizarse no sólo para especificar las operaciones que ofrece el
servidor, sino también su identificador o número de servicio y su versión.

22
SNIFFER

Este lenguaje ofrece una notación similar a C. Este RPC puede pasar cualquier
estructura de datos como argumentos o resultados y dispone de unas rutinas
estándar de serialización de datos.

El RPC Sun no ofrece un servicio de binding a nivel de red, sino local. Es decir, que en
cada máquina hay un binder. Debido a esto este RPC no ofrece transparencia total, de
modo que el usuario debe realizar pequeñas modificaciones en las llamadas de su
programa.

2.5.4 RMI

RMI significa Java Remote Method Invocation y es un mecanismo que ofrece Java para
invocar un método de forma remota. Es un simple mecanismo para la comunicación
de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Para la
comunicación entre otras tecnologías podemos utilizar CORBA o SOAP.

RMI se caracteriza por su facilidad de uso. La gran ventaja es que permite referencia a
objetos (no permitido por SOAP), recolección de basura distribuida (Garbage Collector
distribuido) y paso de tipos arbitrarios (funcionalidad que no ofrece CORBA).

Mediante RMI, un programa Java puede exportar un objeto. Esto significa que es
accesible a través de la red, mientras el servidor espera solicitudes a un puerto
TCP. Un cliente, por tanto, puede coger el objeto de la red e invocar sus métodos.
Un esquema de las partes de un sistema RMI lo podemos ver en la Figura 5.

Desde el exterior, el estado de un objeto sólo puede cambiarse a través de la llamada de

ciertos métodos del objeto, definidos como públicos, de ahí que se dice que un objeto es una
entidad encapsulada.

Java tiene dos tipos de objeto: los locales y los remotos.

Un objeto es local si sus métodos se invocaron dentro de su máquina virtual. Es decir,

por el proceso que creó el objeto o por threads del mismo.

Un objeto es remoto si sus métodos pueden invocarse por procesos que se encuentran en
otras máquinas virtuales.

En Java también encontramos dos tipos de interfaces. La local, accesible por procesos
dentro de la misma máquina virtual, y cuya remota recoge la declaración de las
operaciones que forman el servicio. A diferencia de CORBA los objetos que se pasan

23
SNIFFER

sólo son de entrada.

Figura 5: Partes de un sistema RMI

2.5.5 CURVA

CORBA significa Common Object Request Broker Arquitecture y es un modelo de soporte

de programación distribuida. Curva es simplemente un modelo que facilita el desarrollo y
la interoperabilidad de sistemas distribuidos orientados a objetos.

El modelo de gestión de objetos distribuidos de Curva se compone de: (encontramos un

esquema en la Figura 6).

● El modelo de objetos en el que se describe qué es un objeto CORBA.

● El modelo de referencia en el que se explica qué arquitectura se propone para
permitir que los objetos Curva se relacionen.

24
SNIFFER

Figura 6: Principales características de CORBA

Curve es un modelo cliente/servidor orientado a objetos. Un servidor Curva ofrece

servicios a través de un objeto CORBA.

Curva utiliza un lenguaje de definición de interfaces llamado IDL (Interface Definition

Language) y define la interfaz que ofrece el objeto. Esta interfaz contiene el nombre del
servicio y las firmas de cada procedimiento indicando el nombre de la operación, el
conjunto de parámetros de entrada (in), de salida (out) o de entrada/salida, con sus
respectivos tipos y el tipos del resultado de la operación. También se pueden asociar
excepciones de usuario o sistema a las operaciones.

Un objeto Curva se identifica mediante su referencia a objeto. Este identificar será

utilizado por el cliente para comunicarse con el servidor.

La comunicación entre cliente/servidor es síncrona o bloqueante. Sin embargo también se

permite comunicación no bloqueante de dos tipos: asíncrona y en un solo sentido.

Para la transmisión tanto de la petición como de la respuesta interviene la interfaz del ORB.
Éste tiene dos tipos de interfaz: la pública que figura dentro del modelo de la OMG y la
privada que es la que generando los diferentes fabricantes para permitir la conexión entre
los stubs y la ORB.

25
SNIFFER

En la Figura 7 podemos ver la estructura cliente/servidor:

Figura 7: Estructura cliente/servidor CORBA

Curve ofrece un conjunto de objetos llamados instalaciones comunes. Éstos son servicios
útiles para cualquier entorno.

Por último, de la arquitectura CORBA podemos sacar las siguientes conclusiones:

● Permite a los programadores no construir ciertas herramientas necesarias.

● Si el conjunto de servicios y facilidades están disponibles en más entornos, las
aplicaciones pueden moverse de un entorno a otro.
● El cliente conoce cómo llamar operaciones de interfaces estándar sobre
cualquier plataforma. Esto significa que se pueden crear sistemas abiertos.

26
SNIFFER

2.5.6 J2EE

J2EE es una plataforma de programación para desarrollar y ejecutar software de

aplicaciones con lenguaje de programación JAVA con arquitectura de N niveles
distribuida, basado en componentes de software modulares ejecutándose en un
servidor de aplicaciones. Esta plataforma está definida por una especificación, que es
considerada informalmente como un estándar ya que los suministradores deben
cumplir ciertos requisitos de conformidad.

J2EE incluye varias especificaciones de API como podrían ser JDBC, RMI, e-mail, JMS,
Servicios Web o XML. J2EE también configura algunas especificaciones únicas. Algunos
ejemplos podrían ser Enterprise JavaBeans, servlets, portlets, JSP y diversas tecnologías
de servicios web.

Otras ventajas de utilizar J2EE son, por ejemplo, que el servidor de aplicaciones puede
manejar transacciones, la seguridad, la escalabilidad, concurrencia y gestión de los
componentes desplegados, lo que significa que los programadores pueden concentrarse más
con la lógica de negocio en lugar de preocuparse por temas de bajo nivel.

Hay que comentar también que una de las grandes ventajas de J2EE es que se puede empezar a
desarrollar una aplicación sin coste alguno.

2.5.7 Servicios Web

Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar

datos entre distintas aplicaciones. Estas aplicaciones pueden ser desarrolladas con
lenguajes de programación diferentes, y ejecutadas sobre plataformas también distintas.
Un ejemplo podría ser intercambiar datos en redes de ordenadores como internet. Su
interoperabilidad se debe a la utilización de estándares abiertos.

OASIS y W3C se encargan de la arquitectura y reglamentación de los servicios web. Por

otro lado encontramos el organismo WS-I que se encarga de definir de manera más
exhaustiva estos estándares.

Los estándares utilizados son: Web Services Stack, XML, SOAP o XML-RPC, WSDL,
UDDI, WS-Security y OASIS.

En cuanto a las ventajas de utilizar Servicios Web, las más importantes son:

● Aportan interoperabilidad entre las aplicaciones de software

independientemente de sus propiedades y de las plataformas se abre las
que se encuentran instaladas.

27
SNIFFER

● Los servicios web fomentan los estándares y protocolos basados en texto y

de esta forma es más fácil acceder a su contenido y entender su
funcionamiento.
● Puede aprovechar los sistemas de seguridad de cortafuegos sin tener que
cambiar las reglas de filtrado, ya que admiten HTTP abierto.
● Permiten combinar fácilmente servicios y software de distintas compañías para
dar servicios integrados.
● Permiten interoperabilidad entre plataformas de distintos fabricantes.

Sin embargo, los servicios web también tienen algún inconveniente:

● Para realizar transacciones no se pueden comparar en cuanto a su

grado de desarrollo con los estándares abiertos de computación
distribuida como CORBA.
● Su rendimiento es bajo si se compara con RMI o CORBA.
● Puesto que se apoyan con HTTP, pueden esquivar medidas de seguridad
basadas en firewall.

Sin embargo la principal razón para utilizar Servicios web es que se basan con HTTP
sobre TCP en el puerto 80. Como las organizaciones protegen sus redes por medio de
firewalls, cierran casi todos los puertos menos el puerto 80, que es, precisamente, lo que
utilizan los navegadores.

Otra razón por la que se utilizan los servicios web es porque antes de que existiera SOAP, no
había buenas interfaces para acceder a la funcionalidad de otras computadoras en la red.

Otra buena razón es su flexibilidad. Aportan independencia entre la aplicación que utiliza el
servicio Web y el propio servicio. Así los cambios en uno no deben afectar al otro. Esto es
bueno, ya que cada vez más se tiende a construir grandes aplicaciones a partir de
componentes más pequeños.

2.6 Tecnologías web

2.6.1 Struts

Struts es una herramienta de soporte para desarrollar aplicaciones web bajo el patrón MVC
(Modelo Vista Controlador) y bajo la plataforma J2EE. Struts permite reducir el tiempo de
desarrollo de una aplicación.

Una aplicación web no son sólo paginas html. Sino que puede producir respuestas
dinámicas. Una aplicación web puede tener interacción con bases de datos y lógica de

28
SNIFFER

negocio. Por ese motivo se creó el Modelo Vista Controlador. Así pues se complica
bastante el trabajo del programador y por este motivo aparece struts.

Struts contiene en un simple archivo "struts-config.xml" el enrutamiento y mapeo de todas las

acciones de la aplicación.

Struts da al programador tres componentes clave:

● Una “request handler” dada por la acción mapeada en una URI.

● Una “response handler” que traspasa el control a otro recurso que
completa la respuesta.
● Una “tag” librería que ayuda a los programadores a crear de forma
interactiva formularios en JSP.

2.6.2 JSP

JSP es una tecnología que proporciona una forma rápida de crear páginas web con
contenido dinámico. En el fondo una JSP es un archivo de texto que tiene contenido
estático expresado con formato HTML, SVG, XML o WML y elementos JSP con contenido
dinámico.

Una JSP es traducida a un servlet antes de ser ejecutada, procesa una request HTTP y
genera una response al igual que cualquier servlet.

Las JSP conteniendo XML tags, muy útiles para ahorrar tiempo en la programación, y código javascript
para hacer más fácil ciertas partes del código. Sin embargo el javascript cambia según el navegador y
se convierte en una potencial fuente de error en aplicaciones web.

Una JSP toma los tags XML y los transforma en código estático HTML y después es compilada
para transformarla en un servlet, por tanto, es lógico pensar que necesita la Máquina Virtual
de Java para funcionar. También debe decirse que la JSP compilada se guarda en la memoria
del servidor y cuando vuelve a ser llamada el tiempo de ejecución mejora notablemente.

2.6.3 AJAX

AJAX acrónimo de Asynchronous Javascript And XML, es una técnica de

desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications).
AJAX se ejecuta en el cliente, es decir, en el navegador del usuario mientras se
mantiene una comunicación asíncrono con el servidor a segundo plano. La gran
ventaja de AJAX es que permite realizar cambios en las jsp sin necesidad de
recargarla, lo que significa aumentar la interactividad, la velocidad y la utilidad de

29
SNIFFER

las aplicaciones.

Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se piden al
servidor y se cargan en segundo plano sin interferir con la visualización ni el
comportamiento de la JSP. JavaScript es el lenguaje que normalmente se utiliza para
realizar las funciones que realizan los llamamientos de AJAX, mientras que el acceso a los
datos se realiza mediante XMLHttpRequest. Sin embargo, no es necesario que el
contenido esté en formato XML.

Ajax es una técnica válida para muchas plataformas y utilizable por muchos sistemas
operativos y navegadores ya que está basado en estándares abiertos como Javascript y
Document Object Model.

Ajax es una combinación de cuatro tecnologías ya existentes:

● XHTML (o HTML) y hojas de estilos CSS para el diseño que acompaña a la

información.
● Dovument Object Model (DOM) accedido con un lenguaje de scripting por
parte del usuario, especialmente implementaciones ECMAScript como
Javascript y Jscript, para muestra e interactuar dinámicamente con la
información presentada.
● El objeto XMLHttpRequest para intercambiar datos de forma asíncrona con
el servidor web.
● XML es el formato utilizado normalmente por la transferencia de los
datos solicitados al servidor. Aunque cualquier tipo de formato puede
funcionar, incluyendo HTML preformateado, texto plano, JSON e incluso
EBML.

30
SNIFFER

3 Análisis de los requisitos

3.1 Requisitos funcionales

Antes de empezar a nombrar requisitos funcionales haré una breve definición. Un requisito
funcional define el comportamiento interno del software: cálculos, detalles técnicos,
manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de
uso serán llevados a la práctica.

El primer requisito que me gustaría llamar esrealizar capturas.Es el requisito más

importante y para cumplirlo será necesario conectar las tres partes básicas de la aplicación: la
aplicación en sí misma, a la que podríamos llamar capa de presentación, con el ejb, el que
podría ser la capa de negocio de la aplicación, y éste con la capa más interna que
corresponde al servidor de capturas.

Hay 4 requisitos que son: guardar capturas, configurar nuevas capturas, abrir capturas y
borrar capturas. Éstos tendrían todos el mismo grado de importancia.

Guardar Capturas:Deberá existir un botón en la barra del menú superior para realizar esta
acción. Para cumplir este requisito será necesario que la aplicación guarde las capturas que
se encuentran con formato XML. Habrá que utilizar la librería JDOM para tratar las capturas y
transformarlas en un archivo XML, jerárquico.

Configurar nuevas capturas:Deberá existir un botón en la barra del menú superior para
realizar esta acción. Es importante poder volver a configurar una captura en cualquier
momento y no sólo cuando entramos en la aplicación. Habrá que modificar los
parámetros de la request para que el servidor utilice los nuevos valores.

Abrir capturas:Deberá existir un botón en la barra del menú superior para realizar esta
acción. Este requisito es necesario para complementar el requisito de guardar las
capturas. También será necesario utilizar JDOM para tratar las capturas y ponerlas en la
request para que la JSP la pueda entender.

Borrar capturas:Deberá existir un botón en la barra del menú superior para realizar esta
acción. Este requisito es indispensable ya que es necesario limpiar la mesa de capturas
después de varias capturas. Tan sólo es necesario limpiar la request de capturas y así la
librería displaytag no mostrará capturas.

31
SNIFFER

Requisitos Funcionales (Figura 8):

Nombre Requisito Usuario Consecuencia técnica

RC Realizar Capturas Utilización de un ejb3 que se encarga de
pedir y procesar las capturas en el servidor
C++.
GC Guardar capturas Aplicación de Jdom para la creación de archivos
xml. Utilización de formularios HTML para pasar
la información a la action a través de la
“request”.
CNC Configurar nuevas capturas Aplicación de divos ocultos. El que se vuelve
visible cuando pulsamos la acción concreta en el
menú. Utilización formularios HTML para pasar
la información a la action a través de la request

OC Abrir capturas Aplicación de Jdom para la lectura de archivos

xml. Utilización de formularios HTML para
pasar la información a la action a través de la
“request”. Utilización de DisplayTag para
mostrar las capturas.
BC Llamada a la action, sin formulario. Pasando
parámetro por el GET para indicar que debe
Borrar capturas borrar capturas de la sesión.
ASX Acceso a otros sniffers de la Llamamiento al servidor de capturas. Enlace
red linkable a la url en cuestión.

Figura 8: Tabla de requisitos funcionales

32
SNIFFER

3.2 Requisitos no funcionales

Antes de empezar a nombrarrequisitos no funcionalesdaré una breve definición. Un

requisito no funcional es un requisito que especifica criterios que pueden utilizarse para
juzgar la operación de un sistema en lugar de su comportamiento específico.

La aplicación debe serrápidapor tanto deberá utilizarse tecnologías que permitan

este comportamiento como pueden ser ajax para no recargar la página cada vez que
se acceda al servidor. La utilización de un ejb que corra en una máquina virtual
distinta a la de la aplicación en sí misma para repartir carga de trabajo. La aplicación
deberá estar corriendo en un ordenador Linux y con la librería libpcap. La librería
accede al kernel de la máquina y es éste quien realmente realiza las capturas. Esto
hace que la aplicación sea más rápida y eficiente que en sistemas windows. En éste la
captura y el filtrado se realiza desde la librería.

La aceptación también debe tener unaUtilización Intuitivapor tanto será imprescindible la

utilización de unos buenos css y la utilización de “divos” ocultos. Para que los css tengan su
función a la hora de cumplir este requisito, también será imprescindible un establecimiento
de funciones bien definido.

Lógicamente, la aplicación debe quedarbien presentada. Para cumplir con estos

requisitos, deberá definir correctamente la estructura de la página JSP y, como en el
requisito anterior, use un buen css.

La aplicación también tendrá que serefectiva.Para cumplir este requisito será necesario realizar
un buen control de errores y prever posibles errores que se puedan dar en tiempo de ejecución.
También será necesario desarrollar un código limpio, sin ciclos y sin redundancias.

La aplicación deberá estar en un entorno web para cumplir el requisito deno presencia física
. El usuario no tendrá que estar delante de la máquina para realizar capturas. Simplemente es
necesario tener internet para conectarse a la aplicación.

33
SNIFFER

Requisitos no Funcionales (Figura 9):

Nombre Requisito Usuario Consecuencia técnica

R Rapidez Utilización ajax, ejbs, dos JVM
UI Utilización intuitiva Utilización de buenos css y utilización de divs
ocultos. Establecimiento de funciones bien
definidas.

NPF Desarrollo de la aplicación en un

No presencia física entron web.
ABP Utilización de una estructura de la página
JSP bien definida. Utilización de unos bonos
Aplicación bien presentada css.
E Realizar un buen control de errores,
un código limpio, sin ciclos y sin
Eficiencia redundancias.
Figura 9: Tabla de requisitos no funcionales

34
SNIFFER

4 Metodología y planificación

4.1 Introducción (Metodologías de ingeniería del software)

Si hablamos de diferentes metodologías de Software Enginiering encontramos 4 fases

fundamentales en casi todos estos métodos. Éstos son análisis, diseño, implementación y
test. El objetivo de estas metodologías es dirigir sobre lo que debe hacerse y cómo
hacerlo.

La fase de análisis define los requerimientos del sistema. Sin tener en cuenta
cómo serán estos requerimientos llevados a cabo. Básicamente, en esta fase, se
define el problema que se está intentando resolver. El resultado final de esa etapa
es un documento de requerimientos.

La fase de diseño establece la arquitectura de la aplicación. Esta fase comienza con el

documento de requerimientos realizado en la fase anterior y mapea estos requerimientos a
arquitectura y tecnologías a utilizar. Por tanto, en esta fase se realiza un documento
arquitectónico, se desarrolla un plan de implementación, un documento de prioridades
críticas (las cuales son esenciales para el éxito del proyecto), un documento que hable de
cómo debe ser entorno y cómo debe mostrarse al cliente. Por último, también debe tener
plan de test en el que se definen los tests que se tendrán que realizar para garantizar la
calidad del producto.

La fase de implementación es el momento de empezar a desarrollar código y construir los

distintos elementos de la aplicación siguiendo los análisis anteriores. En esta fase es necesario
realizar un listado de errores. Errores críticos para la aplicación, errores no críticos y errores
desconocidos.

La última fase, no por ello menos importante, es la fase de Test. En esta fase
confirmamos la calidad del producto entregado. Hay que tener en cuenta que es mejor
un producto con pocas funcionalidades pero bien probado que uno con muchas
funcionalidades pero fallos que lleven al no cumplimiento de los requisitos establecidos
en la primera fase.

Encontramos diferentes metodologías a la hora de realizar un proyecto, algunas de ellas las

podemos ver en el siguiente apartado.

35
SNIFFER

4.2 Tipo de metologías

4.2.1 Metodología secuencial

En este tipo de metodología, también llamada metodología en cascada, las diferentes

fases del proyecto van una seguida del otro. Así pues, primero encontramos la fase de
análisis, después encontramos la fase de diseño, seguida de la implementación y por
último la fase de test.

Una metodología secuencial suele utilizarse cuando la complejidad del proyecto es baja y los
requerimientos son estáticos. Muchas veces se empieza a picar código sin un buen analisis del
proyecto y después es necesario reescribirlo. Este contratiempo lo podemos evitar utilizando una
metodología secuencial.

Sin embargo hay alguna desventaja cuando utilizamos una metodología secuencial. Hay
que conocer perfectamente las tecnologías aplicables a la aplicación ya una vez realizado
el análisis ya no hay vuelta atrás. De ahí que un posible error en la etapa de
implementación no dejaría rehacer el análisis. Un esquema de esta metodología lo
podemos ver en la Figura 10.

Figura 10: Esquema de la Metodología secuencial

4.2.2 Metodología en círculo

Esta metodología también se conoce como metodología con espiral. Básicamente,

esta metodología fija problemas provenientes de la aplicación de la metodología
secuencial. Esta metodología contiene las 4 fases: análisis, diseño, implementación y

36
SNIFFER

test.

En cada fase se dedica una pequeña porción de tiempo y se va iterando por cada una de
ellas. Así, todas las partes van cambiando a medida que el proyecto va avanzando. Esto
permite que fallos en los requerimientos o fallos frente a las tecnologías a utilizar se
puedan corregir. Cada una de las fases se intercomunica e interactúa con las demás para
mejorar todos los aspectos posibles de la aplicación.

Por otra parte, sin embargo, no hay un límite de iteraciones a realizar sobre las 4 fases y
es posible que cada vez una fase comporte más trabajo a otra. Posiblemente nunca se
llega a una estructura válida del proyecto.

En esta metodología es muy importante el aprendizaje durante el desarrollo, puesto que así
se puede aplicar a la siguiente iteración.

Un esquema de esta metodología lo encontramos representado en la Figura 11.

Figura 11: Esquema metodología círculo

4.2.3 Metodología incremental

Esta metodología es similar a la metodología en círculo. Se va iterando sobre las 4 fases ya

comentadas anteriormente con la diferencia de que en cada iteración se hace un pequeño
incremento en los requisitos que debería cumplir el proyecto.

4.2.4 Metodología ágil

Esta metodología es iterativa. No intenta minimizar los cambios, sino que está

37
SNIFFER

preparada para aceptarlos. Es una metodología, por tanto, adaptativa. Incorpora el

feedback sobre el proceso y prioriza la colaboración con el cliente. Prefieren código
ejecutable antes que una documentación exhaustiva. También se caracteriza por
minimizar el overhead que se produce en las iteraciones.

4.2.5 Metodología basada en prototipos

Es un modelo de desarrollo que pone énfasis en la etapa de Especificación de

requerimientos a través de la construcción de prototipos que se acercan al usuario a la
idea final del sistema, con el objetivo de poder clarificar los requerimientos.

La metodología basada en prototipos consta de diferentes fases:

● Investigación preliminar: En esta fase se determina el problema y su entorno,

la importancia del problema y los posibles afectos sobre el proyecto. En esta
fase también se busca una idea general de la solución.

● Definición de los requerimientos del sistema: El objetivo de esta fase es registrar todos
los requerimientos del usuario. Esta fase es la más importante puesto que se
determinan requisitos mediante la construcción, demostración y retroalimentación del
prototipo.

● Diseño técnico: Esta etapa contiene dos partes muy importantes, por un lado hay que
realizar la documentación del diseño que explica cómo será la estructura del software.
La segunda parte es la producción de todos los requerimientos y asegurar un fácil
mantenimiento del software en el futuro.

● Programación y prueba: es donde se realiza la implementación siguiendo el diseño técnico

y probada para asegurar su buen funcionamiento.

● Operación y mantenimiento: En esta fase se trata de llevar los distintos prototipos

en un ámbito de explotación.

● Análisis grueso y especificaciones: El objetivo de esta fase es desarrollar un diseño

básico para el prototipo inicial.

● Diseño y construcción: El objetivo de esta fase es desarrollar el prototipo

inicial.

● Evaluación: Esta fase contiene dos partes muy importantes. Por un lado, extraer
del usuario los requerimientos adicionales del sistema y verificar que el prototipo
sea correcto con los requerimientos. Si se encuentran errores, el prototipo es

38