Sistema de monitorazión de redes wifi - tic.udc.es · ejemplo intrusos o falsos puntos de acceso....

Departamento de Tecnologías de la Información y la Comunicación

INGENIERÍA TÉNICA EN INFORMÁTICA DE GESTIÓN

Sistema de monitorización de redes Wi-Fi

Autor: Rubén Hortas Astariz

Director: Antonino Santos del Riego

Tutor: Francisco Javier Nóvoa de Manuel

A Coruña, a de de 2013

Miembros del tribunal

Fecha de lectura y defensa

Calificación

1/117

I. I. Agradecimientos Agradecimientos

A mi familia, por su apoyo, paciencia y comprensión. Sobretodo, gracias a mis padres por todos

los esfuerzos realizados para que yo pueda haber llegado hasta aquí.

A mis amigos, en especial:

Al osito marrón y al osito hippie, por esos tiempos en aquel piso informático de compañerismo,

risas, inventos, experimentos y “buenos días en broadcast”.

A Guti, Fernando y Rosa, Marcos y Vane, por todo el apoyo y por todos esos buenos momentos.

A Óskar, por toda su ayuda durante estos años, por esa gran amistad y por formar un gran

equipo, tanto en lo profesional como en lo personal.

A Alejandro “Chucu”, por esa gran amistad y por compartir todo ese conocimiento sobre

python.

A los compañeros de la FIC. Por el compañerismo durante todo el tiempo que pasamos juntos.

A los compañeros de wikifreaks (n1ce, ctRl, Sharek, Grey, ...) Por tantas horas juntos. Sigamos

aprendiendo unos de otros y experimentando entre todos. Algún proyecto será el bueno.

A mis profesores de la facultad, sobretodo, a Nino y Fran por el esfuerzo, la dedicación, la

ayuda y todo el apoyo que han hecho posible este proyecto.

Gracias a todos por el apoyo y la confianza.

II. II. ResumenResumen

El objetivo de este proyecto es realizar, mediante la metodología de proceso unificado de

desarrollo software, un sistema que registre y analice información sobre las redes inalámbricas

Wi-Fi al alcance en cada momento y ubicación, con el fin de detectar posibles riesgos o

amenazas relativas a la seguridad de las mismas.

Durante la recogida de información, el sistema registrará datos sobre las redes Wi-Fi al alcance

y los dispositivos conectados a las mismas.

La información recogida se podrá analizar en tiempo real y/o de forma retrospectiva. A través

de estos análisis se podrán detectar amenazas o comportamientos peligrosos, como por

ejemplo intrusos o falsos puntos de acceso.

El sistema automatizará todas las labores necesarias para el registro y el análisis de la

actividad detectada en las redes LAN inalámbricas, con el fin de simplificar su uso y hacerlo

accesible a cualquier usuario.

III. III. Palabras clavePalabras clave

Seguridad, redes, inalámbricas, Wi-Fi, WIFI, historial, monitorización, python.

ÍndiceÍndice

ÍndiceÍndice

1. Introducción.....................................................................................10

1.1 Organización del proyecto.............................................................................20

1.1.1 Memoria.................................................................................................20

1.1.1 Herramientas.........................................................................................22

1.2 Objetivos del proyecto...................................................................................29

2. Metodología......................................................................................31

2.1 Especificación de requisitos...........................................................................31

2.1.1 Requisitos funcionales............................................................................32

2.1.2 Requisitos no funcionales.......................................................................33

2.2 Análisis de requisitos.....................................................................................34

2.2.1 Casos de uso..........................................................................................34

2.2.2 Diagramas de Casos de uso...................................................................38

2.2.3 Modelo de dominio.................................................................................38

2.2.4 Diagramas de secuencia del sistema (DSS)...........................................46

2.2.5 Arquitectura lógica.................................................................................49

2.2.6 Diagrama de clases global.....................................................................51

2.2.7 Análisis de los subsistemas....................................................................52

3. Funcionalidades................................................................................63

4. Pruebas realizadas............................................................................65

4.1 Pruebas unitarias...........................................................................................65

4.1.1 Test airodump.........................................................................................65

4.1.2 Test OUI..................................................................................................66

4.1.3 Test parse_log........................................................................................66

4.2 Conclusiones.................................................................................................67

4.3 Pruebas de análisis........................................................................................68

4.3.1 Escenario predeterminado.....................................................................68

4.3.2 Resultados..............................................................................................70

4.4 Pruebas de rendimiento.................................................................................72

4.4.1 Resultados..............................................................................................73

4.4.2 Notas......................................................................................................73

5. Planificación y evaluación de costes...................................................74

8/117

6. Conclusiones.....................................................................................76

6.1 Objetivos.......................................................................................................76

6.2 Cualidades del sistema..................................................................................77

7. Líneas futuras...................................................................................78

8. Bibliografía.......................................................................................79

8.1 Monografías...................................................................................................79

8.2 Textos electrónicos........................................................................................80

9. Glosario............................................................................................82

10. Apéndices.......................................................................................86

10.1 Índice de figuras..........................................................................................86

10.2 Índice de tablas...........................................................................................87

10.3 Pruebas unitarias (código fuente y resultados)............................................88

10.3.1 Test airodump.......................................................................................88

10.3.2 Test OUI................................................................................................91

10.3.3 Test parse_log......................................................................................93

10.4 Manual de usuario.....................................................................................108

10.4.1 Dependencias....................................................................................108

10.4.2 Utilizando el sistema..........................................................................108

10.5 Notas sobre la terminología utilizada.........................................................117

9/117

1. Introducción1. Introducción

1. 1. IntroducciónIntroducción

Las redes de área local inalámbricas se basan en un conjunto de conceptos,

estándares y protocolos relativamente nuevos, puesto que se empezaron a

implantar de forma masiva en los años 1990.

Sin embargo, la primera transmisión inalámbrica tuvo lugar en 1870. Un músico y

astrónomo, Sir William Herschel (1738-1822), descubrió que existía la luz infrarroja

y que estaba más allá de la visibilidad del ojo humano. El descubrimiento de la luz

infrarroja abrió el camino a teoría de ondas electromagnéticas, que fue explorada

en profundidad por James Maxwell (1831-1879). La mayoría de los descubrimientos

de Maxwell relacionados con el electromagnetismo estaban basados en las

investigaciones de Michael Faraday (1791-1867) y Andre-Marie Ampere (1775-

1836). Heinrich Hertz (1857-1894), basándose en los descubrimientos hechos por

Maxwell, demostró que las ondas electromagnéticas existían, viajaban a la

velocidad de la luz y que la electricidad podía ser transmitida por ellas. Hertz fue el

primer investigador que creó dispositivos que emitían ondas radioeléctricas y

también dispositivos que permitían detectarlas.

Durante el siglo XX, las comunicaciones inalámbricas se transformaron en digitales

y las soluciones propietarias evolucionaron para transmitir información a través de

protocolos estandarizados. Además, a partir de los años 1980 las redes de área

local se han ido desplegando hasta ser un elemento imprescindible de cualquier

organización o incluso de cualquier hogar.

10/117


La evolución de las redes de área local y de la tecnología de transmisión

inalámbrica, dio lugar a las redes de área local inalámbricas (Wireless LAN o

WLAN1). En el año 1997, IEEE2 definió el primer estándar que hacía referencia a las

WLAN, 802.11, describiendo como enviar una señal sobre la banda ISM3 de 2.4GHz

para transmitir información digital. La mayoría de los protocolos que usamos hoy en

día en las redes LAN4 inalámbricas fueron definidos después de 1997. El campo de

las redes inalámbricas evoluciona cada día, pero su terminología y sus conceptos

fundamentales están bien establecidos.

Protocolos 802.11

La primera versión del protocolo 802.11 fue publicada en 1997. Especifica dos

velocidades de transmisión teóricas de 1 y 2 megabits por segundo (Mbits/s) que se

transmiten por señales infrarrojas. Con el paso de los años, se le han ido añadiendo

correcciones. Cada corrección al estándar contiene, en su nomenclatura, “802.11” y

una letra (por ejemplo 802.11i). El estándar 802.11 ha sido revisado en 2007 para

integrar todas las correcciones publicadas los años anteriores (integrando

802.11a,b,d,e,g,h,i y j). Esta versión acumulativa del estándar es conocida como

802.11-2007. En 2011 surge una nueva revisión (integrando las correcciones

publicadas entre 2007 y 2011, llamadas 802.11k,r,y,w,n,p,z,v,u y s). Esta nueva

versión del estándar es conocida como 802.11-2012. Entre los protocolos de la

rama 802.x destacan por su importancia 802.11b, 802.11g, 802.11a y 802.11n.

1 WLAN: Red inalámbrica de área local. De sus siglas en inglés, Wireless Local Area Network.

2 IEEE: Instituto de Ingenieros Eléctricos y Electrónicos. De sus siglas en inglés, Institute of Electrical

and Electronics Engineers. Asociación técnico profesional mundial dedicada a la estandarización.

3 ISM: Idustrial, Científica y Médica. De sus siglas en inglés, Industrial, Scientific and Medical. Bandas

reservadas internacionalmente para uso no comercial de radiofrecuencia en áreas industriales,

científicas y médicas.

4 LAN: Red local. De sus siglas en inglés, Local Area Network.

11/117


• 802.11b

La revisión 802.11b fue publicada en 1999, corrigiendo varias debilidades del

protocolo 802.11 original, como la falta de interoperabilidad entre equipos de

diferentes marcas. 802.11b describe una velocidad de transmisión entre 5.5y

11 Mbits/s. Debido a la espacio ocupado por la codificación del protocolo

CSMA/CA5, en la práctica, la velocidad máxima de transmisión con este

estándar es de, aproximadamente, 5.9 Mbits/s sobre TCP6 y 7.1 Mbits/s sobre

UDP7. 802.11b fue el primer estándar de la familia 802.11x en alcanzar

amplia aceptación entre los consumidores.

• 802.11a

La revisión 802.11a fue aprobada en 1999. El estándar 802.11a utiliza el

mismo juego de protocolos de base que el estándar original, lo que lo hace

incompatible con 802.11, 802.11b y 802.11g, evitando al mismo tiempo las

interferencias con estos dispositivos, además de evitar las interferencias con

microondas, dispositivos bluetooth8 y teléfonos inalámbricos. 802.11a opera

en la banda de 5 GHz y definió los requisitos para la utilización de un sistema

de multiplexación por división de frecuencia ortogonal (OFDM, orthogonal

frequency-division multiplexing). 802.11a posee una velocidad máxima

teórica de 54 Mbit/s.

• 802.11g

La revisión 802.11g fue publicada en 2003, introduciendo OFMD a la banda

de 2.4Ghz y permitiendo ratios de transmisión efectivos de hasta 54 Mbits/s.

5 CSMA/CA: Acceso Múltiple por Detección de Portadora / Anticolisión. De sus siglas en Inglés: Carrier

Sense Multiple Access/Collision Avoidance. Protocolo para transmisiones en redes 802.11.

6 TCP: Protocolo de Transmisión de Control. De sus siglas en inglés, Transmission Control Protocol. Es

uno de los protocolos fundamentales en internet.

7 UDP: Protocolo de Datagrama de Usuario. De sus siglas en inglés, User Datagram Protocol. Es un

protocolo del nivel de transporte de red.

8 Bluetooth: Especificación industrial para Redes Inalámbricas de Área Personal (WPAN).

12/117


• 802.11n

802.11n es una revisión del estándar 802.11-2007 aprobada en 2009.

802.11n se diseñó teniendo como objetivo incrementar la velocidad más allá

de 54 Mbits/s. 802.11n incorpora tres técnicas nuevas, la mayor parte de las

cuales pueden ser implementadas para mejorar la revisiones 802.11g o

802.11a:

1. Agregación de canales: 801.11n permite agregar varios canales

creando un canal mayor. Mediante esta agregación se puede llegar a

crear un canal con una velocidad de transmisión de 119 Mbits/s.

2. Mecanismos de eficiencia MAC9: Por ejemplo reduciendo a la mitad el

silencio entre dos símbolos en una onda, de 800 nanosegundos a 400

nanosegundos. Este proceso puede incrementar la velocidad un 11%.

3. MIMO (Multiple In Multiple Out o Múltiple Entrada Múltiple Salida): Las

estaciones 802.11n pueden tener varias redes en el mismo canal y

usarlas al mismo tiempo.

Debido a que la información se transmite por el aire, es obvio que las redes

inalámbricas pueden ser más vulnerables que las redes cableadas, puesto que la

señal física que transmite la información es difícil de contener. Esto supone una

gran preocupación a la hora de desplegar una red inalámbrica.

La facilidad para acceder a la señal de transmisión provoca que se puedan llevar a

cabo ataques de acceso, de reconocimiento, de Denegación de Servicio (DoS), de

intermediario (man-in-the middle), etc.

9 MAC: Control de Acceso al Medio. De sus siglas en inglés, Media Access Control. Identificador que

corresponde de forma única a una tarjeta o dispositivo de red.

13/117


Tipos de redes LAN inalámbricas:

Ad-hoc: Cuando dos computadoras se quieren comunicar directamente la una con

la otra, lo hacen creando una red ad-hoc. Estas redes no requieren un dispositivo

central para permitirles comunicarse. Un dispositivo establece un nombre de grupo

y los parámetros de radio, y el otro se conecta. Este despliegue se llama Basic

Service Set (Conjunto de Servicios Básicos o BSS), y define el área en el que un

dispositivo es accesible. Como no se necesita un dispositivo central para

comunicarse, se llama Independent Basic Service Set (Conjunto de Servicios Básicos

Independiente o IBSS).

Modo infraestructura: En las redes inalámbricas, un punto de acceso actúa como

punto de conexión para los clientes. Un punto de acceso sólo es un tipo de estación

inalámbrica a la que se asocian los clientes. El área de cobertura del punto de

acceso se llama Basic Service Area (Área de Servicio Básico o BSA), o celda

inalámbrica.

14/117

Ilustración 1: Red Ad-Hoc


Dependiendo del número de punto de accesos en una red inalámbrica, podemos

distinguir dos tipos:

1. Basic Service Area: Cuando sólo existe un punto de acceso el área de

cobertura se llama Basic Service Area (Área de Servicio Básico o BSA).

2. Extended Service Area: Cuando hay más de un punto de acceso conectado a

un sistema de distribución común, el área de cobertura se llama Extended

Service Area (Área de Servicio Extendido o ESA).

15/117

Ilustración 2: Basic Service Area (BSA)

Ilustración 3: Extended Service Area (ESA)


Tipos de seguridad en la las redes LAN inalámbricas

• Redes abiertas:

Una red abierta no dispone de ningún tipo de cifrado ni control de acceso,

permite conectarse a cualquier dispositivo.

• Redes abiertas, pero con control de acceso (utilización la técnica de “portal

cautivo”): Un portal cautivo utiliza la autenticación basada en un sitio web

seguro para permitir a un dispositivo conectarse a la WLAN.

• Redes con seguridad débil

• Redes con seguridad WEP

Las LAN inalámbricas con seguridad WEP (Wired Equivalent Privacy),

no autentican a los usuarios, simplemente verifican que tienen una

clave.

• Redes con filtrado de direcciones MAC

El filtrado de direcciones MAC (Media Access Control) es un

mecanismo simple de autenticar el dispositivo que se está

conectando. El filtrado MAC define qué direcciones MAC tienen

permiso para acceder a la red. El peligro de utilizar este sistema de

seguridad es que las direcciones MAC pueden ser falsificadas.

16/117


• Redes con seguridad WPA

WPA (Wi-Fi Protected Access) está basado en el borrador de la revisión

802.11i versión 3. Fue presentado en 2003 como reemplazo a WEP. WPA

utiliza Temporal Key Integration Protocol (Protocolo de integración de clave

temporal o TKIP) para cambiar automáticamente las claves. Aunque no es

obligatorio, WPA admite la utilización del esquema de cifrado Advanced

Encryption Standard (AES).

• Redes con seguridad WPA2 o IEEE 802.11i

WPA2 (Wi-Fi Protected Access 2), es el segundo intento de WPA.WPA fue

diseñado basándose en el borrador de la revisión 802.11i, pero fue publicado

en 2003, mientras que 802.11i fue aprobado en 2004. Cuando 802.11i fue

aprobado, se había ampliado su soporte para métodos 802.11x y de cifrado.

En este momento se publica WPA2 para ser compatible con el estándar

802.11i, siendo, por consecuencia, un método más seguro que WPA.

Descripción del protocolo de acceso al medio en redes Wi-Fi

Para que una estación inalámbrica (o dispositivo inalámbrico) pueda conectarse a

una red debe configurarse con el SSID10 correcto. Para que la estación pueda

averiguar los SSIDs disponibles en un momento dado, los puntos de acceso

difunden periódicamente unos mensajes en broadcast11 llamados beacon (balizas),

en los que indican el SSID de la red a la que pertenecen. Como medida de

seguridad, un punto de acceso puede configurarse para que no envíe beacons o

para que los envíe ocultando su SSID. Sin embargo, los SSID no viajan cifrados, por

lo que el SSID puede averiguarse capturando un mensaje de otra estación.

10 SSID: Identificador de Conjunto de Servicios. De sus siglas en inglés, Service Set IDentifier. Nombre

incluido en todos los paquetes de una red inalámbrica para identificarlos como parte de la misma.

11 Broadcast: Forma de transmisión de información donde un nodo emisor envía información a una

multitud de nodos receptores de manera simultánea, sin necesidad de reproducir la misma

transmisión nodo por nodo.

17/117


Además de recibir beacons, las estaciones pueden enviar mensajes probe requests

(solicitudes de sondeo) buscando puntos de acceso. Un punto de acceso está

obligado a responder si el probe request indicaba el SSID del punto de acceso o un

SSID de 0 bytes (SSID broadcast). Tanto los beacon como los probe response

(respuestas a las solicitudes de sondeo) contienen información del punto de acceso

(BSSID, SSID, velocidades de transmisión soportadas, protocolos de cifrado

soportados...). Cuando un punto de acceso recibe una trama del DS12 (Distribution

System o Sistema de Distribución), mira si el destino está en su lista de direcciones

MAC asociadas. Si lo está reenvía la trama, si no lo está la descarta.

Una estación no puede estar asociada a más de un punto de acceso a la vez por

cada interfaz de red que posea. Si una estación se se aleja de un punto de acceso y

se acerca a otro punto de acceso con el mismo SSID (pertenecen al mismo ESS),

primero deberá desasociarse del primer punto de acceso y, después, asociarse al

segundo. La autenticación se realiza antes de asociarse y no se realiza al

reasociarse.

Capturando y analizando paquetes de red, se puede averiguar qué puntos de

acceso hay instalados en una zona y qué dispositivos tienen asociados.

Amenazas en redes LAN inalámbricas

• Redes Ad-hoc:

Un atacante puede crear una red ad-hoc con un cliente legítimo, robar

información, e incluso utilizarla como medio para atacar la red utilizándolo

para acceder a la red cableada segura.

12 Distribution System (DS o Sistema de Distribución): Medio de comunicación entre los puntos

de acceso.

18/117


• Puntos de acceso falsos:

Un punto de acceso falso no es parte de la infraestructura de la red. Podría

ser un punto de acceso traído de casa o un punto de acceso que está en una

red adyacente. Un punto de acceso falso no siempre es malo. Podría ser un

punto de acceso que formase parte del dominio de la red y estuviese

trabajando en modo autónomo. Parte del trabajo de un administrador es

determinar si se supone que el punto de acceso debe estar ahí.

• Clientes falsos:

Si un cliente se conecta a un punto de acceso falso, debería ser considerado

como “cliente falso”. La razón es que los puntos de acceso falsos,

normalmente, son instalados con configuraciones por defecto, esto implica

que cualquier cliente conectado evita cualquier política de seguridad.

• Desvinculación de clientes:

Cuando un cliente se conecta a un punto de acceso, las utilidades del

sistema operativo normalmente permiten al cliente guardar el Service Set

Identifier (SSID). En el futuro, cuando ese SSID es visto de nuevo, el cliente

puede crear una conexión automáticamente. Ha una posibilidad de que el

cliente sea consciente de la conexión. Si el SSID ha sido suplantado, el

cliente podría conectarse a una red potencialmente insegura.

Tipos de ataques a la red

• Ataques de reconocimiento: Un atacante intenta conseguir información sobre

la red.

• Ataques de acceso: Un atacante intenta ganar acceso a los datos,

dispositivos y/o a la red.

19/117


• Ataques de denegación de servicio: Un atacante intenta impedir a los

usuarios legítimos que accedan a los servicios que necesitan.

Aunque hay métodos de mitigación para prevenir estas amenazas y ataques, hay

algunos que no son muy avanzados y están considerados débiles por los estándares

de hoy día. Todo esto, sumado al constante desarrollo y mejora de métodos y

herramientas diseñados para llevar a cabo estas amenazas y ataques, hace de la

monitorización, el registro y el análisis de la información una tarea esencial para

poder reaccionar de forma rápida y eficaz ante los riesgos.

1.1 1.1 Organización del proyectoOrganización del proyecto

1.1.1 1.1.1 MemoriaMemoria

1. Introducción

Se describe la motivación y se profundiza en los objetivos. Se exponen los

fundamentos teóricos en los que se basa el proyecto y se detallan los

conceptos necesarios para dar una visión profunda del entorno. Para

finalizar, se describe en qué consiste y qué hace el proyecto y se justifica la

elección de las herramientas que se han utilizado en el desarrollo de este

proyecto.

2. Metodología

En este capítulo se detallan los aspectos metodológicos relativos al análisis,

diseño y desarrollo basándose en paradigmas de Ingeniería del Software. Se

detalla cómo se hizo el proyecto y los estándares metodológicos que se han

seguido.

20/117


3. Funcionalidades

En este capítulo se explica cómo funciona la aplicación detalladamente a

través de las funcionalidades o prestaciones fundamentales de la

herramienta desarrollada.

4. Pruebas realizadas

En este capítulo se detallan las distintas técnicas de pruebas realizadas para

validar la efectividad de la herramienta desarrollada.

5. Planificación y evaluación de costes

En este capítulo se plasman las distintas fases de elaboración del proyecto,

incluyendo una evaluación de costes.

6. Conclusiones

En este capítulo se revisan cada uno de los objetivos inicialmente planteados

para contrastarlos con lo realizado.

7. Líneas futuras

En este capítulo se mencionan algunas ampliaciones que se podrían

incorporar al proyecto en desarrollos futuros.

8. Bibliografía

En este capítulo se listan los documentos consultados durante la realización

del proyecto.

9. Glosario

Anexo que incluye los términos poco conocidos utilizado durante la

realización del proyecto.

10. Apéndices

Este capítulo incluye diversos índices (figuras, tablas, etc.) de elementos

utilizados en la documentación del proyecto, y un manual de usuario de la

aplicación desarrollada.

Al final del capítulo se incluyen notas sobre la terminología utilizada.

21/117


1.1.1 1.1.1 HerramientasHerramientas

1. Suite Aircrack-ng

La suite Aircrack-ng está compuesta por un conjunto de herramientas para auditar

redes WiFi.

De forma general, podemos dividir en tres categorías las herramientas que incluye

aircrack-ng:

• Recolección de información: airodump-ng

• Ataques sobre la información: aircrack-ng

• Aceleración de la obtención de información: aireplay-ng

Aunque en la suite aircrack-ng se incluyen gran cantidad de herramientas útiles en

estas y otras tareas, airodump-ng, aircrack-ng y aireplay-ng son las tres

herramientas más destacadas y más conocidas.

Para la realización de este proyecto se ha utilizado airodump-ng como herramienta

para la recolección de información de redes WiFi, debido a su amplia difusión y a

algunas características puntuales que presenta. Entre estas características

destacan su flexibilidad de configuración y su capacidad para generar distintos tipos

de ficheros de registro.

2. GNU/Linux

GNU/Linux es uno de los términos empleados para referirse a la combinación del

kernel Linux con el sistema GNU.

Las razones por las que se ha seleccionado GNU/Linux como plataforma para el

desarrollo de este proyecto son:

• Coste: GNU/Linux es un sistema operativo ampliamente extendido y de

distribución gratuita, por tanto accesible a cualquier persona que posea (o

tenga acceso a) un computador.

22/117


Utilizar otros sistemas operativos supondría limitar el número de usuarios

que podrían usar el proyecto. Los sistemas operativos privativos (como

Windows o Mac OS X), requieren el pago de una licencia para obtener el

derecho de uso. Otros sistemas, aún siendo gratuitos, son utilizados por un

número considerablemente menor de personas.

• Uso: A día de hoy, GNU/Linux es el sistema operativo más utilizado para

llevar a cabo la realización de auditorías de seguridad en redes WiFi,

habiendo disponibles específicamente preparadas para este propósito varias

distribuciones13 (Bugtraq, Kali, WiFiSlax, Wifiway, etc.).

• La elección de otro sistema operativo supondría una reducción importante

del número de posibles usuarios de la aplicación, puesto que el proyecto sólo

podría ser utilizado por aquellos usuarios con amplios conocimientos

específicos sobre su sistema operativo. Usuarios con la capacidad de

configurar su sistema operativo para este propósito.

• Soporte de tarjetas inalámbricas: Al ser el sistema más utilizado para la

realización de auditorías de redes inalámbricas, GNU/Linux se ha convertido

en el sistema operativo que proporciona el soporte más amplio a tarjetas de

conexión inalámbrica WiFi.

13 Distribución [GNU/Linux]: Distribución de software basada en el núcleo Linux que incluye

determinados paquetes de software para satisfacer las necesidades de un grupo específico de

usuarios.

23/117


La utilización de otros sistemas operativos supondría una reducción en el

número de usuarios de la aplicación, puesto que, por ejemplo, para

Windows, aircrack-ng (tecnología que usa este proyecto) retiró, oficialmente,

el soporte para Windows en su versión 1.1. Otros sistemas como MAC OS X,

utilizan controladores de software (drivers) cerrados para sus tarjetas

inalámbricas, que no permiten (en un principio) la utilización de esta tarjetas

para el propósito de este proyecto. Otros sistemas operativos, al ser

utilizados por una cantidad menor de personas, presentan el problema de

soportar una cantidad reducida de tarjetas inalámbricas WiFi.

3. Python 2

Python es un lenguaje de programación interpretado cuya filosofía hace hincapié en

una sintaxis muy limpia y que favorece un código fácilmente legible.

Se trata de un lenguaje de programación multiparadigma, ya que soporta

orientación a objetos, programación imperativa y, en menor medida, programación

funcional. Es un lenguaje interpretado, usa tipado dinámico y es multiplataforma.

Python es administrado por la Python Software Foundation14. Posee una licencia de

código abierto, denominada Python Software Foundation License15.

Las principales características por las que se ha elegido Python como el lenguaje de

programación más adecuado para la realización de este proyecto son:

• Costes: Es software de distribución gratuita.

• Código abierto: Es software que podemos leer/examinar, modificar y

distribuir gratuitamente.

14 Python Software Foundation: Organización sin ánimo de lucro que cuenta con los derechos de

propiedad intelectual del lenguaje de programación Python. http://www.python.org/psf/

15 Python Software Foundation License (PSFL): Licencia de software permisiva que cumple los

requisitos OSI para ser declarada lincencia de software libre. http://docs.python.org/2/license.html

24/117

http://docs.python.org/2/license.html

http://www.python.org/psf/


Además de la Python Software Foundation, los usuarios pueden adaptar el

software a sus necesidades, informar y corregir sus errores, lo que resulta en

una evolución, desarrollo e implementación de mejoras mucho más rápidas

que las existentes en el desarrollo de software convencional o cerrado.

• Sintaxis limpia: Python hace uso de una sintaxis de código limpia, clara,

compacta y concisa, lo que favorece una mejor comprensión del código y da

como resultado programas más cortos. Ésto agiliza y simplifica las tareas de

desarrollo y mantenimiento del software.

• Orientación a objetos: La orientación a objetos es un paradigma de

programación que utiliza objetos en sus interacciones, basado en varias

técnicas como abstracción, polimorfismo, acoplamiento y encapsulamiento.

Las principales ventajas de utilizar un lenguaje de programación orientado a

objetos son que se agiliza el desarrollo del software y se simplifican la

reutilización, la ampliación y el mantenimiento del software. Otra ventaja

que proporciona la utilización de este tipo de lenguajes es la fiabilidad del

software resultante. Al dividir el problema en problemas más pequeños, se

simplifican las labores de prueba y detección de errores. Todo esto se

traduce en un incremento de la productividad a la hora de desarrollar y

mantener el software.

• Multiplataforma: En un lenguaje como Python, interpretado (no requiere

compilación), y que favorece y simplifica la ampliación y mantenimiento del

software, la multiplataforma nos ofrece una gran ventaja. Con los

conocimientos y el equipo técnico (hardware) necesarios, se puede adaptar

el proyecto de forma sencilla para hacerlo funcional en otros sistemas

operativos y/o arquitecturas.

• Curva de aprendizaje suave: La curva de aprendizaje describe el éxito

obtenido durante el aprendizaje durante el transcurso del tiempo.

25/117


En el mundo del software esta curva se representa como un diagrama en

que el eje horizontal representa la acumulación de lo aprendido, mientras el

eje vertical representa la acumulación de tiempo empleado.

Una curva de aprendizaje suave se traduce en un aprendizaje fácil y

eficiente.

• Popularidad: Aunque Python es un lenguaje de -relativa- reciente creación

(fue creado por Guido van Rossum en el año 1991), se encuentra en

constante renovación y expansión.

El gran incremento de la popularidad de Python se produjo entre los años

2003 y 2007, llegando a ser uno de los 4 lenguajes de programación de

Google y a convertirse en el lenguaje de programación sobre el que se

construye el total de la infraestructura de Youtube. Estos factores hacen de

Python uno de los lenguajes de programación más populares y demandados

entre los profesionales del sector.

En lo referente a las versiones de Python, se ha escogido la versión 2 (Python 2),

puesto que la versión 3 (Python 3) está actualmente en desarrollo. Esto implica que

la versión 2 tendrá un extenso soporte hasta el final de su vida útil, mientras que la

versión 3 puede presentar carencias significativas y algunos errores que

provocarían un comportamiento inestable del software resultante.

4. wxPython

wxPython es un conjunto de herramientas que permite programar de forma rápida y

sencilla Interfaces Gráficas de Usuario (GUI16) en Python.

Las principales razones por las que se ha escogido wxPython como herramienta

para programar la interfaz son:

16 GUI: De sus siglas en inglés Graphical User Interface. Programa informático que actúa de interfaz de

usuario, utilizando un conjunto de imágenes y objetos gráficos para representar la información y

acciones disponibles en la interfaz.

26/117


• Código abierto: El código abierto mantiene algunas ventajas con respecto

a la accesibilidad y desarrollo del software (que ya han sido comentadas

anteriormente, en el apartado “Python 2”).

wxPython se distribuye bajo una licencia “wxWindows Licence17”, que

consiste, básicamente, en una licencia LGPL18 con la excepción de que las

obras derivadas en formato binario se pueden distribuir como el

desarrollador crea conveniente, satisfaciendo así a desarrolladores que

quieran licenciar sus obras bajo licencias GPL19 (o derivadas) o licencias

privativas.

• Multiplataforma y aspecto nativo: Una vez programada la interfaz, el

mismo código funcionará en distintas plataformas sin necesidad de

modificaciones. Además, la interfaz adoptará un aspecto nativo para cada

plataforma en la que sea usada, mejorando así la experiencia de usuario.

Otra serie de razones que ha llevado a escoger wxPython como herramienta para el

desarrollo de la Interfaz Gráfica de Usuario frente a sus competidores (TkInter,

PyGTK, PYQT) son:

• Popularidad: Posiblemente wxPython sea el conjunto de herramientas más

extendido en uso para el desarrollo de interfaces gráficas de usuario en

Python.

17 wxWindows Licence: Licencia para la distribución de software basada en la licencia LGPL.

http://opensource.org/licenses/wxwindows.php

18 LGPL: De sus siglas en inglés Lesser General Public License (Licencia Pública General Reducida de

GNU). Licencia de software creada por la Free Software Foundation ( http://www.fsf.org/ ) que

pretende garantizar la libertad de compatir y modificar el software cubierto por ella, asegurando que

el software es libre para todos sus usuarios. http://www.gnu.org/licenses/lgpl.html

19 GPL: De sus siglas en inglés General Public License (Licencia Pública General). Licencia de GNU.

Tiene como propósito declarar el software cubierto por esta licencia como software libre y protegerlo

de intentos deapropiación que restrinjan libertades a los usuarios.

http://www.gnu.org/licenses/licenses.es.html#GPL

27/117


http://www.gnu.org/licenses/lgpl.html

http://www.fsf.org/

http://opensource.org/licenses/wxwindows.php


• Herramientas adicionales: wxPython cuenta con una serie herramientas

para diseñar las interfaces gráficas de forma visual, entre las que destacan

wxGlade (http://wxglade.sourceforge.net/) y BOA Constructor (http://boa-

constructor.sourceforge.net/). El uso de estas herramientas agiliza, de forma

sustancial, el diseño y el desarrollo de la interfaz gráfica.

5. Eclipse y PyDev

Eclipse es un entorno de desarrollo implementado inicialmente por IBM20,

compuesto por un conjunto de herramientas de programación (IDE21) de código

abierto.

PyDev es un entorno de desarrollo integrado (IDE) python para Eclipse.

Para la realización del proyecto se ha optado por integrar PyDev en Eclipse por

presentar las ventajas del software libre y reunir en una única aplicación un editor

de código, un compilador y un depurador.

20 IBM: De sus siglas en inglés International Business Machines. Empresa multinacional

estadounidense de tecnología y consultoría.

21 IDE: De sus siglas en inglés Integrated Development Environment. Programa informático compuesto

por un conjunto de herramientas de programación.

28/117

http://boa-constructor.sourceforge.net/

http://boa-constructor.sourceforge.net/

http://wxglade.sourceforge.net/


1.2 1.2 Objetivos del proyectoObjetivos del proyecto

Este proyecto tiene como objetivo el diseño de una herramienta de monitorización

que permita a cualquier persona, independientemente de sus conocimientos

informáticos, descubrir comportamientos peligrosos, amenazas, y riesgos relativos a

la seguridad de las redes Wi-Fi. Por tanto, los principales objetivos del proyecto

serán:

• Automatización

La aplicación se encargará de realizar, de forma automática, todas las

operaciones de configuración de hardware y software necesarias para llevar

a cabo la recogida de información, así como de restablecer el sistema a su

estado original una vez finalizada su ejecución.

• Interfaz intuitiva

Una interfaz intuitiva permitirá al usuario un uso rápido y eficaz del sistema,

así como la toma de decisiones de una forma clara, cómoda y sencilla.

• Registro de datos

El sistema almacenará la información recogida a lo largo de todas sus

sesiones con el fin de poder realizar análisis de forma retrospectiva.

• Análisis

El sistema será capaz de analizar la información recogida tanto de forma

retrospectiva como en tiempo real.

• Monitorización

El sistema será capaz de monitorizar las redes Wi-Fi al alcance y los

dispositivos de conexión inalámbrica que tengan asociados, tanto de forma

global como de forma individualizada.

29/117


• Costes

Con la finalidad de que el sistema pueda ser utilizado por el mayor número

de personas posible, su coste ha de reducirse al máximo. Para ello, se

desarrollará maximizando el uso de

tecnologías gratuitas y de libre distribución.

30/117

2. Metodología2. Metodología

2. 2. MetodologíaMetodología

Para la elaboración de este proyecto se ha optado por utilizar la metodología de

Proceso Unificado de Desarrollo Software.

El Proceso Unificado es un marco de desarrollo de software caracterizado por estar

dirigido por casos de uso, centrado en la arquitectura, enfocado en los riesgos y por

ser iterativo e incremental. El Proceso Unificado no es simplemente un proceso, sino

un marco de trabajo extensible que puede ser adaptado a organizaciones o

proyectos específicos.

Para visualizar, especificar, construir y documentar los artefactos del sistema de

software, se ha optado por el Lenguaje Unificado de Modelado visual (UML22).

2.1 2.1 Especificación de requisitosEspecificación de requisitos

Este punto pretende definir las características y funcionalidades importantes que

deberán ser tenidas en cuenta a la hora de desarrollar el sistema.

22 UML: Lenguaje Unificado de Modelado (de sus siglas en inglés Unified Modeling Languaje). Lenguaje

de modelado de sistemas de software más conocido y utilizado en la actualidad.

31/117


2.1.1 2.1.1 Requisitos funcionalesRequisitos funcionales

2.1.1.1 2.1.1.1 FuncionalidadesFuncionalidades

2.1.1.1.1 2.1.1.1.1 Registro de actividadRegistro de actividad

La aplicación mantendrá un fichero de registro de información en el cual

almacenará datos sobre las redes Wi-Fi dentro de su alcance y los dispositivos

inalámbricos asociados a las mismas. Esta información será registrada en un

formato similar al que presenta el sistema de registro de los sistemas operativos

GNU/Linux (SYSLOG).

Si la aplicación detecta un punto de acceso, registrará la fecha y hora en la que fue

detectado, su BSSID, ESSID, canal de transmisión y sistema de cifrado (si tuviese).

En caso de detectar un dispositivo inalámbrico, la aplicación registrará la fecha y

hora en la que fue detectado, su dirección MAC, y, en caso de encontrase asociado

a algún punto de acceso, el BSSID y ESSID del punto de acceso.

2.1.1.1.2 2.1.1.1.2 Monitorización de redesMonitorización de redes

La aplicación podrá monitorizar una red en concreto, para ver los dispositivos

asociados a las mismas, con el fin de detectar posibles irregularidades. Si la

aplicación se encuentra monitorizando una red Wi-Fi mostrará todos los dispositivos

asociados a la misma, la fecha y hora en que se registró la conexión y el fabricante

del dispositivo.

2.1.1.1.3 2.1.1.1.3 Análisis de registrosAnálisis de registros

La aplicación podrá analizar el fichero de registro de eventos con el fin de detectar

posibles riesgos o amenazas. Los análisis se podrán realizar en tiempo real o en

diferido, y, a través de ellos, la aplicación identificará dos tipos de riesgos para la

seguridad: puntos de acceso falsos y dispositivos inalámbricos que se hayan

conectado a más de una red.

32/117


Una vez detectado algún un riesgo, la aplicación lo clasificará y mostrará

información detallada sobre él. En caso de que el riesgo sea un dispositivo

inalámbrico, se mostrarán su dirección MAC, su fabricante, el BSSID, ESSID la fecha

en la que se registró la conexión y el fabricante de los puntos de acceso a los que

estuvo conectados. Si el riesgo fuese un punto de acceso falso, se mostrarán el

BSSID, ESSID, la fecha y hora en la que se detectó, el canal de transmisión, el tipo

de cifrado utilizados y el fabricante del dispositivo.

2.1.1.1.4 2.1.1.1.4 Guardar registroGuardar registro

En caso de detectar alguna amenaza, la aplicación permitirá al usuario generar y

almacenar un fichero de informe. Éste fichero contendrá la información mostrada

por la aplicación a cerca de las amenazas detectadas.

2.1.1.2 2.1.1.2 SeguridadSeguridad

Debido a las restricciones de los sistemas operativos, para poder utilizar la

aplicación, siempre será necesaria la autenticación del usuario como usuario

“administrador” o “root”.

2.1.2 2.1.2 Requisitos no funcionalesRequisitos no funcionales

2.1.2.1 2.1.2.1 UsabilidadUsabilidad

La interfaz del sistema debe ser de uso intuitivo y sencillo, con el fin de permitir a

cualquier usuario un uso rápido y eficaz.

Todos los textos mostrados por la aplicación deberán mostrarse según el formato de

codificación de caracteres UTF-823, para evitar problemas de codificación en

diferentes plataformas.

23 UTF-8: De sus siglas en inglés 8-bit Unicode Transformation Format. Es un formato de codificación

de caracteres definido como estándar por la RFC 3629.

33/117


2.1.2.2 2.1.2.2 FiabilidadFiabilidad

Debido a que dos de las funciones principales de este proyecto son el registro y

análisis de información, el sistema tendrá que gestionar la información de forma

consistente.

2.1.2.3 2.1.2.3 RendimientoRendimiento

Para minimizar el consumo de recursos mientras se está capturando información, la

aplicación proporcionará una interfaz en modo texto.

Debido a que no podemos prever el tamaño de los ficheros en los que se almacena

la información la aplicación deberá estar optimizada para analizar estos ficheros de

la forma más rápida y eficiente posible. Para ello el diseño del sistema debe

implementar mecanismos que optimicen su respuesta en casos críticos.

2.1.2.4 2.1.2.4 SoporteSoporte

Con la finalidad de reducir los costes en licencias y facilitar el uso a la mayor parte

posible de personas, el sistema maximizará el uso de componentes de libre

distribución y estándares.

2.2 2.2 Análisis de requisitosAnálisis de requisitos

2.2.1 2.2.1 Casos de usoCasos de uso

En el contexto de la ingeniería del software, un caso de uso es una secuencia de

interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un

evento que inicia un actor principal sobre el propio sistema.

Los casos de uso se utilizan para capturar los requisitos funcionales y para definir

los contenidos de las iteraciones.

34/117


2.2.1.1 2.2.1.1 Registrar actividadRegistrar actividad

Descripción: El usuario quiere registrar la información sobre la actividad detectada

en las redes WiFi dentro de su alcance.

Actor principal: Usuario.

Escenario principal de éxito (Flujo básico de eventos)

1. El usuario inicia la aplicación en modo gráfico.

2. El usuario escoge la interfaz de red que utilizará para capturar la información.

3. El sistema registra la actividad detectada en las redes WiFi dentro de su alcance.

Extensiones (Flujos alternativos de eventos)

1a. El sistema no detecta en el equipo ninguna interfaz de red compatible

con aircrack-ng:

1. El sistema señala el error y detiene su ejecución.

1b. El usuario inicia la aplicación en modo texto.

2-3a. El usuario no ha seleccionado ninguna interfaz de red:

1. El sistema señala el error

.

3b. El usuario decide detener el registro de la actividad en las redes WiFi dentro de

su alcance:

1. El sistema detiene el registro de información.

35/117


2.2.1.2 2.2.1.2 Monitorizar redMonitorizar red

Descripción: El usuario quiere monitorizar una red inalámbrica para saber qué

dispositivos tiene asociados.



1. El usuario inicia la monitorización de una red inalámbrica.

2. El usuario selecciona la red inalámbrica que quiere monitorizar.

3. El sistema registra y muestra los dispositivos inalámbricos conectados a la red

inalámbrica monitorizada.


2a. El usuario decide cancelar la monitorización:

1. El sistema cancela la monitorización.

3a. El usuario decide finalizar la monitorización:

1. El sistema detiene la monitorización.

Precondiciones:

• Hay, al menos, una interfaz de red instalada en el sistema compatible con

aircrack-ng.

• La aplicación se está ejecutando en modo gráfico.

36/117


2.2.1.3 2.2.1.3 Analizar registroAnalizar registro

Descripción: El usuario decide analizar el registro de la actividad detectada en las

redes inalámbricas, con el fin de detectar e identificar posibles riesgos o

comportamientos sospechosos.



1. El usuario inicia el análisis de la información recogida por el sistema.

2. El sistema muestra los dispositivos inalámbricos y puntos de acceso

potencialmente peligrosos detectados.


*a. En cualquier momento el sistema falla:

1. El sistema señala el error.

*b. El sistema se encuentra registrando la actividad en las redes inalámbricas

dentro de su alcance, o el usuario decide iniciar este registro:

1. El sistema comienza un análisis en tiempo real de la información recogida.

2a. El usuario decide guardar el registro suministrado por el sistema en un

fichero:

1. El usuario escoge el nombre del fichero.

2. El sistema exporta la información mostrada al fichero elegido por el usuario.

2b. El usuario decide finalizar el análisis:

1. El sistema finaliza el análisis.

37/117


2.2.2 2.2.2 Diagramas de Casos de usoDiagramas de Casos de uso

2.2.2.1 2.2.2.1 UsuarioUsuario

2.2.3 2.2.3 Modelo de dominioModelo de dominio

2.2.3.1 2.2.3.1 Descripción textual de las clases conceptuales del Descripción textual de las clases conceptuales del

modelo de dominiomodelo de dominio

• Conexión: Clase que contiene la información referente a los puntos de

acceso y a los dispositivos inalámbricos conectados a los mismos.

Es necesaria para la creación de objetos de clase “Red inalámbrica” y

“Registro”.

38/117

figura 1: : Diagrama de casos de uso Usuario


• Dispositivo inalámbrico: Clase que contiene la información sobre un

dispositivo inalámbrico en particular. Es utilizada para la creación de objetos

de clase “Conexión”.

• Informe: Esta clase representa al fichero de informe que puede guardar el

usuario después de analizar el registro de datos de la aplicación.

• Interfaz de red: Clase que representa a la tarjeta de red instalada en el

sistema que se utilizará para registrar la información.

• Peligro: Clase que representa un peligro potencial detectado durante el

análisis del fichero de registro de información que guarda la aplicación.

• Punto de acceso: Clase que contiene la información sobre un punto de

acceso en particular. Es necesaria para crear objetos de clase “Conexión”.

• Red inalámbrica: Clase composición. Es necesaria para crear conjuntos de

objetos de clase “Conexión”.

Ejemplos de casos de uso:

• Monitorizar red

• Registrar actividad

• Registro: Clase composición. Es necesaria para crear conjuntos de objetos

de clase “Conexión”. Guarda la información sobre las conexiones registradas

por el sistema.


• Analizar registro

• Guardar Registro


39/117


• Usuario: Esta clase representa a la persona que utiliza la aplicación. Es el

actor principal en todos los casos de uso.



• Monitorizar red

• Analizar registro

2.2.3.2 2.2.3.2 Atributos y relaciones de las clases conceptualesAtributos y relaciones de las clases conceptuales

Clase conceptual Atributos Relaciones

Conexión

hora: Hora a la que se

detectó la conexión.

tipo de dispositivo:

Dispositivo inalámbrico o

Punto de acceso.

tiene [punto de

acceso]: Una conexión

está formada por, al

menos, un punto de

acceso.

tiene [dispositivo

inalámbrico]: Una

conexión puede estar

formada por un dispositivo

inalámbrico asociado a un

punto de acceso.

Red inalámbrica tiene:

Una red inalámbrica está

compuesta por un

conjunto de conexiones.

Registro tiene: Un

registro está compuesto

por un conjunto de

conexiones.

40/117



Dispositivo inalámbrico

mac: Dirección MAC del

dispositivo.

essid: ESSID del punto de

acceso al que estaba

asociado el dispositivo.

bssid: BSSID del punto de

acceso al que estaba

asociado el dispositivo.

Conexión tiene: Una

conexión puede estar

formada por un dispositivo

inalámbrico asociado a un

punto de acceso.

Interfaz de red

nombre: Nombre que da

el sistema operativo a las

interfaces de red

instaladas en el equipo.

Usuario selecciona: El

usuario tiene que

seleccionar una interfaz de

red para poder monitorizar

una red inalámbrica o para

registrar la actividad en

las redes inalámbricas al

alcance.

41/117



Punto de acceso

essid: ESSID del punto de

acceso.

bssid: BSSID del punto de

acceso.

canal: Número de canal

por el que se encontraba

transmitiendo información

el punto de acceso.

cifrado: Cifrado utilizado

por el punto de acceso

para transmitir

información (si lo hubiere).

Conexión tiene: Una

conexión está formada

por, al menos, un punto de

acceso.

Red inalámbrica

tiene [conexión]: Una

red inalámbrica está

compuesta por una o

varias conexiones.

Usuario monitoriza: Un

usuario puede monitorizar

una red inalámbrica o

todas las que tenga a su

alcance.

42/117



Registro

tiene [conexión]: Un

registro está compuesto

por un conjunto de

conexiones.

Usuario analiza: Un

usuario puede analizar el

resgistro con la intención

de detectar dispositivos

inalámbricos o puntos de

acceso potencialmente

peligrosos.

Usuario guarda: Un

usuario puede guardar a

fichero el resultado de un

análisis.

43/117



Usuario

Usuario analiza: Un

usuario puede analizar el

resgistro con la intención

de detectar dispositivos

inalámbricos o puntos de

acceso potencialmente

peligrosos.

Usuario guarda: Un

usuario puede guardar a

fichero el resultado de un

análisis.

Usuario selecciona: El

usuario tiene que

seleccionar una interfaz de

red para poder monitorizar

una red inalámbrica o para

registrar la actividad en

las redes inalámbricas al

alcance.

Usuario monitoriza: Un

usuario puede monitorizar

una red inalámbrica o

todas las que tenga a su

alcance.

44/117


2.2.3.3 2.2.3.3 Gráfico del modelo de dominioGráfico del modelo de dominio

45/117

figura 2: Gráfico del modelo de dominio de la aplicación


2.2.4 2.2.4 Diagramas de secuencia del sistema (DSS)Diagramas de secuencia del sistema (DSS)

2.2.4.1 2.2.4.1 Registrar actividadRegistrar actividad

46/117

figura 3: Diagrama de Secuencia del Sistema Registrar actividad


2.2.4.2 2.2.4.2 Monitorizar redMonitorizar red

47/117

figura 4: Diagrama de Secuencia del Sistema Monitorizar Red


2.2.4.3 2.2.4.3 Analizar registroAnalizar registro

48/117

figura 5: Diagrama de Secuencia del Sistema Analizar Registro


2.2.5 2.2.5 Arquitectura lógicaArquitectura lógica

Esta sección describe como las clases software se organizan a gran escala en

paquetes UML, subsistemas y capas.

49/117

figura 6: Arquitectura lógica


2.2.5.1 2.2.5.1 AirodumpAirodump

Este paquete engloba todas las operaciones relacionadas con airodump-ng, por

ejemplo verificar si está instalado o ejecutarlo.

2.2.5.2 2.2.5.2 CLICLI

Este paquete incluye todas las operaciones necesarias para manejar el sistema a

través de la interfaz de línea de comandos (CLI24). Surge de la necesidad de poder

ejecutar la aplicación en modo texto.

2.2.5.3 2.2.5.3 LogLog

Este paquete representa todas las operaciones de registro, análisis y presentación

de la información tratada por el sistema.

2.2.5.4 2.2.5.4 SistemaSistema

Este paquete representa todos los datos y operaciones que la aplicación necesita

para funcionar correctamente en cada plataforma. Surge como respuesta a la

posibilidad de poder adaptar la aplicación a distintas plataformas y arquitecturas.

24 CLI: Interfaz de Línea de Comandos. De sus siglas en inglés Command Line Interface. Método que

permite a los usuarios dar instrucciones a alguna aplicación informática por medio de una línea de

texto simple.

50/117


2.2.6 2.2.6 Diagrama de clases globalDiagrama de clases global

51/117

figura 7: Diagrama de clases global


2.2.6.1 2.2.6.1 Notas sobre el diagrama de clases globalNotas sobre el diagrama de clases global

El principio del mínimo conocimiento está presente en todo el diseño del sistema,

para la intención de conseguir la máxima cohesión y el mínimo acoplamiento entre

los objetos.

Aunque en Python los atributos y métodos privados se determinan por su nombre

(comienzan por dos guiones bajos '__'), en los diagramas se ha utilizado la notación

tradicional '-' para identificarlos.

2.2.7 2.2.7 Análisis de los subsistemasAnálisis de los subsistemas

A continuación, se describen en detalle cada uno de los subsistemas (o paquetes)

derivados del diagrama de clases.

Estas descripciones consisten en:

• Resumen del subsistema. Explicación de cómo los subsistemas surgen de

forma natural de etapas de desarrollo anteriores.

• Principios y patrones utilizados durante el desarrollo del sistema y

justificación de su uso y elección.

• Diagramas de secuencia para los principales casos de éxito del sistema.

El sistema se ha dividido en los siguientes subsistemas:

• Airodump

• CLI

• GUI

• Log

• Sistema

52/117


2.2.7.1 2.2.7.1 AirodumpAirodump

Este subsistema nace de la necesidad de especificar, de forma sencilla, las

principales operaciones con airodump-ng.

Las clases de este subsistema no tienen relación con las clases conceptuales por

encontrarse fuera del dominio del sistema.

Descripción de las clases definidas en el subsistema:

Airodump: Esta clase engloba todas las operaciones relacionadas con airodump-

ng.

53/117

figura 8: Subsistema Airodump


2.2.7.2 2.2.7.2 CLICLI

Este subsistema engloba todas las operaciones necesarias para manejar el sistema

a través de la interfaz de línea de comandos. Surge de la necesidad de poder

ejecutar la aplicación en modo texto.

54/117

figura 9: Subsistema CLI


Descripción de las clases incluidas en el subsistema:

CLI: Es la clase encargada de comenzar la captura de información y gestiona la

aplicación cuando ésta se lanza en modo texto.

CLI_COLORS: Esta clase se encarga de dar formato a los mensajes de información

que muestra la aplicación.

Las clases de este subsistema no tienen relación con las clases conceptuales.

Diagrama de secuencia Ejecutar airodump

55/117

figura 10: Diagrama de Secuencia Ejecutar airodump


2.2.7.3 2.2.7.3 GUIGUI

Este subsistema representa a la interfaz gráfica, y engloba todas las operaciones

necesarias para su funcionamiento.


Frame_mon_wifi_list: Esta clase representa a la ventana que muestra la lista de

redes disponibles para monitorizar.

Frame_mon_wifi_dev_con: Esta clase representa la ventana que muestra la lista

de dispositivos asociados a una red cuando se está monitorizando.

56/117

figura 11: Subsistema GUI


OUI: Es la clase encargada de buscar y añadir el fabricante de algún dispositivo de

red (ya sea dispositivo inalámbrico o punto de acceso) y añadirlo en las vistas de la

interfaz gráfica.

MainFrame: Esta clase representa a la ventana principal de la aplicación.


encontrase fuera del dominio del sistema.

Diagrama de secuencia Monitorizar red

57/117

figura 12: Diagrama de Secuencia Monitorizar red


2.2.7.4 2.2.7.4 LogLog

Este subsistema agrupa las clases necesarias para mantener el registro de

información de la aplicación.

58/117

figura 13: Subsistema LOG



AP: Esta clase representa a los puntos de acceso y almacena toda la información

referente a ellos.

Device: Esta clase representa a los dispositivos inalámbricos y almacena toda la

información referente a ellos.

Log: Esta clase agrupa las operaciones necesarias para mantener el registro de

datos de la aplicación y para realizar parte de su análisis en tiempo real.

Relación entre las clases de este subsistema y las clases conceptuales:

Clase subsistema Clase conceptual

Log Registro

AP Punto Acceso

Device Dispositivo inalámbrico

59/117


Diagrama de secuencia Analizar registro

60/117

figura 14: Diagrama de Secuencia Analizar registro


2.2.7.5 2.2.7.5 SistemaSistema

Este subsistema representa las clases necesarias para la interacción entre la

aplicación y el sistema operativo.


Environment: Esta clase almacena las operaciones y datos necesarios para

interactuar con el sistema operativo (directorios, comandos, etc.).

Execute_command: Esta clase representa la ejecución de un comando. Es

necesaria para ejecutar un comando en segundo plano (o background).

Restore_sys: Esta clase agrupa las operaciones necesarias para dejar el sistema

operativo en el estado que tenía antes de ejecutar la aplicación, borrar ficheros de

registro temporales, desactivar el modo monitor de la interfaz de red, etc.

61/117

figura 15: Subsistema Sistema



encontrase fuera del modelo de dominio de la aplicación.

Diagrama de secuencia Restaurar Sistema

62/117

figura 16: Diagrama de Secuencia Restaurar sistema

3. Funcionalidades3. Funcionalidades

3. 3. FuncionalidadesFuncionalidades

Entre las funcionalidades más destacadas de este proyecto se encuentran el

registro, el análisis de información y la identificación de riesgos o amenazas

relativas a la seguridad de redes WiFi.

Aunque actualmente se encuentra disponible una gran variedad de aplicaciones

orientadas al registro y análisis de información para redes WiFi, ninguna cubre las

funcionalidades de este proyecto.

En este proyecto se ha desarrollado una aplicación capaz de registrar diversa

información sobre redes WiFi y dispositivos inalámbricos asociados a las mismas. La

aplicación almacena esta información en el directorio de registros del sistema

operativo en un formato similar al que utiliza el sistema operativo GNU/Linux. La

información almacenada se puede analizar en tiempo real o en diferido.

A través de los análisis de la información recogida, la aplicación

puede monitorizar una red WiFi en concreto, o detectar amenazas o

comportamientos inusuales.

Si la aplicación está monitorizando una red WiFi, mostrará todos los dispositivos

inalámbricos conectados a la misma, así como la fechas y horas de la conexiones y

los fabricantes de los dispositivos.

Si la aplicación realiza un análisis (ya sea en tiempo real o en diferido) sobre la

información recogida, identificará dos tipos de riesgos para la seguridad:

dispositivos inalámbricos que se hayan conectado a más de una red y puntos de

acceso falsos.

63/117

3. Funcionalidades3. Funcionalidades

Una vez detectados, la aplicación clasificará los riesgos y mostrará información

detallada sobre cada uno de ellos. Si el riesgo es un dispositivo inalámbrico se

visualizarán: Dirección MAC del dispositivo, fabricante del dispositivo, BSSID y ESSID

de los puntos de acceso a los que estuvo asociado, fechas y horas de las

conexiones y fabricantes de los puntos de acceso. Si el riesgo es un punto de

acceso falso, se visualizarán: BSSID, ESSID, fecha y hora en que se detectó, canal y

cifrado usados para transmitir la información y fabricante del punto de acceso.

Una vez realizado un análisis, en caso de que se haya detectado algún riesgo, la

aplicación permitirá guardar un informe con la información mostrada.

64/117

4. Pruebas realizadas4. Pruebas realizadas

4. 4. Pruebas realizadasPruebas realizadas

Para comprobar el correcto funcionamiento del código del proyecto, se han

realizado pruebas unitarias mediante el conjunto de herramientas PyUnit, se ha

comprobado el resultado de los análisis creando y analizando un escenario

concreto, y se han realizado pruebas de rendimiento para los análisis.

4.1 4.1 Pruebas unitariasPruebas unitarias

En programación, una prueba unitaria es una forma de probar el correcto

funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de

los módulos funcione correctamente por separado. Luego, con las Pruebas de

Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema

en cuestión.

Para ello, se desarrollan casos de prueba para cada función no trivial o método en

el módulo de forma que cada caso sea independiente del resto.

Para facilitar la realización de las pruebas, los ficheros de las pruebas unitarias se

adjuntan al código fuente de la aplicación, en el directorio 'core/'. El nombre de

estos ficheros comienza con la cadena 'test_' seguida del nombre del módulo sobre

el que realizan las pruebas.

4.1.1 4.1.1 Test airodumpTest airodump

Con este test se comprueba el correcto funcionamiento del módulo airodump.py.

– Se comprueba el comportamiento de la aplicación en caso de que aircrack-

ng esté instalado en el sistema.

– Se comprueba el comportamiento de la aplicación en caso de que aircrack-

ng no esté instalado en el sistema.

65/117


4.1.1.1 4.1.1.1 NotasNotas

Al simular el escenario en el que aircrack-ng no está instalado, el mensaje “[ERROR]

aircrack-ng no está instalado” indica que el test ha finalizado

satisfactoriamente. En el caso de que aircrack-ng no estuviese instalado en el

sistema, la aplicación debería mostrar ese mensaje de error. Si ,además, la

aplicación estuviese ejecutándose en modo línea de comandos, ésta debería

detener su ejecución.

4.1.2 4.1.2 Test OUITest OUI

Este test comprueba el correcto funcionamiento del módulo oui.py. Este módulo es

el encargado de asociar direcciones MAC y fabricantes de hardware. Se

comprueban los resultados que devuelve la aplicación al asociar direcciones MAC a

sus fabricantes a través del OUI (almacenado en el fichero 'oui.txt'). Para ello:

• Se seleccionan al azar varias direcciones MAC ya conocidas del fichero

'oui.txt' y se compara la salida.

• Se introduce una dirección MAC inexistente y se compara la salida.

4.1.3 4.1.3 Test parse_logTest parse_log

Este test comprueba el correcto funcionamiento del módulo parse_log.py. Este

módulo es el encargado de comprobar que existe el fichero de registro de

conexiones que guarda la aplicación y de analizar su contenido. Para comprobar que

funciona correctamente, se introducen unos datos simulando lo que podría contener

el registro, los resultados esperados y se ejecuta. Las pruebas que realiza este

módulo se pueden dividir en tres partes:

1. Fichero de registro

– Se comprueba el comportamiento de la aplicación en caso de que exista el

fichero de registro de la aplicación.

66/117


– Se comprueba el comportamiento de la aplicación en caso de que no exista

el fichero de registro de la aplicación.

2. Dispositivos de red

– Se comprueba el comportamiento de la aplicación al encontrar y añadir un

nuevo dispositivo de red en el fichero de registro.

– Se comprueba el comportamiento de la aplicación al añadir más conexiones

a un dispositivo de red ya registrado.

– Se comprueba el comportamiento de la aplicación en caso de añadir un

dispositivo de red ya registrado con una conexión también registrada

anteriormente.

– Se comprueba el comportamiento en el caso de añadir una conexión a un

dispositivo ya registrado anteriormente, pero conectado a un punto de

acceso diferente.

3. Puntos de acceso

– Se comprueba el comportamiento de la aplicación al registrar un nuevo

punto de acceso.

– Se comprueba el comportamiento de la aplicación en el caso de añadir un

punto de acceso ya registrado.

– Se comprueba el comportamiento de la aplicación en el caso de añadir un

falso punto de acceso (o Rogue AP).

4.2 4.2 ConclusionesConclusiones

Todos los test realizados han devuelto resultados satisfactorios. Por tanto, se puede

concluir que todas las partes del software comprobadas funcionan correctamente.

67/117


4.3 4.3 Pruebas de análisisPruebas de análisis

4.3.1 4.3.1 Escenario predeterminadoEscenario predeterminado

Para comprobar los resultados de los análisis, se ha creado el siguiente escenario:

Se ha creado un fichero para el escenario que se llama 'wific_escenario' y se ha

incluido junto al código fuente en el directorio logsTESTS/ .

68/117

figura 17: Escenario de pruebas para análisis


En este escenario se recrea una posible situación real, donde un usuario peligroso

(“Usuario1”, con dirección MAC: 00:00:00:00:00:01) se conecta a varias redes (con

ESSID: “AP1”, “AP2”, “AP3”, “AP4”). Un usuario legítimo (“Usuario2”, con dirección

MAC: 00:00:00:00:00:02) se conecta a una única red (con ESSID “AP4”), y un punto

de acceso falso (ESSID: “AP1”, BSSID: 50:01:BB:00:00:00) suplanta a un punto de

acceso legítimo (ESSID: “AP1”, BSSID: 10:01:CA:00:00:00)

Para poder realizar un análisis de este escenario es necesario colocar el fichero

'wific_escenario' como fichero de registro predeterminado de la aplicación. Esto se

puede hacer de tres formas:

1. Poner el fichero 'wific_escenario' en el directorio de registro de la aplicación

(por ejemplo: '/var/log/wific/' en sistemas operativos GNU/Linux) y

renombrarlo a 'wific.log'

2. Descomentar la línea 525 (#self.this_os.wific_log_file =

'/RUTA/logsTEST/wific_escenario') en el fichero 'wific.py', y modificar

la ruta al fichero 'wific_log'.

3. Descomentar la línea 57 (# f_log = '/RUTA/logsTEST/wific_escenario')

en el fichero parse_log.py (situado dentro del directorio 'core') y modificar la

ruta al fichero 'wific_log'.

Una vez colocado el fichero 'wific_escenario' como fichero de registro de la

aplicación, bastará lanzar la interfaz gráfica de la misma (fichero 'wific.py') como

superusuario o administrador y pulsar el botón “Analizar”

69/117


Los resultados obtenidos se mostrarán automáticamente.

4.3.2 4.3.2 ResultadosResultados

4.3.2.1 4.3.2.1 Punto de acceso falsoPunto de acceso falso

70/117

figura 18: Interfaz gráfica de wiFIC

figura 19: Resultados de análisis - Punto de Acceso falso


4.3.2.2 4.3.2.2 Dispositivo peligrosoDispositivo peligroso

4.3.2.3 4.3.2.3 NotasNotas

En las imágenes no aparecen algunos fabricantes de los dispositivos porque las

direcciones MAC usadas en el ejemplo no se corresponden con ningún fabricante en

la vida real.

4.3.2.4 4.3.2.4 ConclusionesConclusiones

Se detecta como punto de acceso peligroso “AP1”, ya que hay dos puntos de

acceso utilizando el mismo BSSID.

Se detecta como dispositivo (o usuario) peligroso el que tiene la dirección MAC

00:00:00:00:00:01, puesto que se ha conectado a cuatro puntos de acceso

diferentes.

Comparando los resultados obtenidos con el escenario previamente diseñado, se

puede observar que son correctos.

71/117

figura 20: Resultados de test de análisis - Dispositvo Peligroso


4.4 4.4 Pruebas de rendimientoPruebas de rendimiento

Las pruebas de rendimiento se han realizado generando ficheros de registro de

distintos tamaños y midiendo los tiempos de ejecución de los análisis.

Los ficheros para realizar los análisis se han incluido junto al código fuente, en el

directorio 'logsTestsRendimiento/'. Este directorio se encuentra comprimido con el

fin de ahorrar espacio.

El nombre estos ficheros está compuesto por la cadena 'wific_' seguida de el

espacio que ocupan en disco.

Para poder realizar los análisis de rendimiento, es necesario realizar una serie de

cambios en el fichero 'parse_log.py', situado en el directorio 'core/':

1. Descomentar la línea 12 (#import time)

2. Eliminar las líneas 245 y 329 (”””)

3. Modificar la línea 248 (ruta_flogs = 'Ruta/logsTestRendimiento') y

poner la ruta del directorio 'logsTestsRendimiento'

Una vez hechos los cambios, se ejecutará el fichero 'parse_log.py'.

Por ejemplo, en sistemas GNU/Linux: $ python parselog.py

Los tiempos de ejecución para cada fichero se irán mostrando en pantalla a medida

que se realicen los test.

Equipo utilizado

• Procesador: Intel Core2Duo 2.1Ghz

• Memoria RAM: 1 Gb

• Sistema Operativo: GNU/Linux Debian 8.0 “Jessie”

• Python: Python 2.7

72/117


4.4.1 4.4.1 Resultados Resultados

Tamaño de fichero Tiempo

560 KiB 0.05 s

5 MiB 0.38 s

50 MiB 3.85 s

251 MiB 19.59 s

515 MiB 38.84 s

4.4.2 4.4.2 NotasNotas

Los tamaños están expresados con prefijos binarios, es decir, en base 2. Un

mebibyte (MiB) equivale a 2^10 bytes, mientras que 1 megabyte (MB) equivaldría

a 10^6 bytes.

Los tiempos están expresados en segundos.

73/117

5. Planificación y evaluación de costes5. Planificación y evaluación de costes

5. 5. Planificación y evaluación de costesPlanificación y evaluación de costes

Para la realización de este proyecto se ha optado por utilizar la metodología Proceso

Unificado de Desarrollo de Software. El Proceso unificado se divide en cuatro fases:

Inicio, Elaboración, Construcción y Transición. Cada fase se divide en iteraciones, y

cada iteración en disciplinas. Aunque todas las iteraciones suelen incluir trabajo en

casi todas las disciplinas, el grado de ellas varía a lo largo del proyecto. Es por esto

que, para la realización de un diagrama de Gantt que muestre la relación

tiempo/persona de las distintas fases del proyecto de una forma clara y sencilla, se

han aproximado y sumado los tiempos de duración de cada fase.

Además de las fases propias del Proceso Unificado de Desarrollo de Software, se ha

incluido (después de la fase de inicio) una fase de Inmersión en las tecnologías de

desarrollo. El objetivo de esta fase es representar el tiempo necesario para aprender

a utilizar las tecnologías necesarias para la realización del proyecto.

Diagrama de Gantt:

La duración y los costes se han calculado para una persona trabajando ocho horas

al día durante una jornada laboral de Lunes a Viernes.

74/117

figura 21: Diagrama de Gantt

figura 22: Detalle de las fases del diagrama de Gantt

5. Planificación y evaluación de costes5. Planificación y evaluación de costes

La duración total del proyecto consta de 95 días de trabajo. Utilizando un coste

estimado de 65 euros por hora, el coste total del proyecto asciende a 49.400

euros.

75/117

6. Conclusiones6. Conclusiones

6. 6. ConclusionesConclusiones

En el capítulo 1, Introducción, se han planteado una serie de objetivos

que debe cumplir la aplicación. En el apartado 4.1, Especificación suplementaria,

del capítulo 4 (Metodología), se han planteado una serie de cualidades que debe

cumplir la aplicación. En este capítulo se detallan el estado de los objetivos y

cualidades que debe cumplir la aplicación.

6.1 6.1 ObjetivosObjetivos

✔ Automatización: El sistema realiza de forma autónoma y automática todas

las operaciones de hardware y software necesarias para llevar a cabo la

recogida de información y de restablecer el sistema a su estado original una

vez finalizada su ejecución.

✔ Interfaz intuitiva: La interfaz permite al usuario la toma de decisiones de

forma clara y sencilla.

✔ Registro de datos: El sistema registra la información recogida a lo largo de

todas sus sesiones.

✔ Análisis: El sistema es capaz de realizar análisis sobre la información

recogida, tanto en tiempo real como de forma retrospectiva.

✔ Monitorización: El sistema es capaz de monitorizar las redes WiFi al

alcance y los dispositivos inalámbricos que tengan asociados, tanto de forma

global, como de forma individualizada.

✔ Costes: El coste del proyecto se ha reducido al máximo mediante el uso de

tecnologías gratuitas de libre distribución.

76/117

6. Conclusiones6. Conclusiones

6.2 6.2 Cualidades del sistemaCualidades del sistema

✔ Usabilidad: La aplicación tiene una interfaz de uso intuitivo y muestra todos

los textos en formato UTF-8.

✔ Fiabilidad: El sistema gestiona la información de forma consistente.

✔ Rendimiento:

La aplicación proporciona una interfaz en modo texto para minimizar el

consumo de recursos mientras se captura información.

La aplicación implementa mecanismos para optimizar el análisis de ficheros

de registro de gran tamaño de forma rápida y eficiente.

✔ Soporte: Se han reducido al máximo los costes en licencias y con ello se ha

maximizado el número potencial de usuarios utilizando para ello,

únicamente, componentes software estándar y de distribución gratuita.

77/117

7. Líneas futuras7. Líneas futuras

7. 7. Líneas futurasLíneas futuras

A pesar de que la aplicación cumple todos los objetivos planteados, en este

apartado se citan algunas implementaciones que se podrían añadir a la aplicación

en desarrollos futuros:

• Multiplataforma

Desarrollar el soporte para más plataformas y arquitecturas

• Alarmas y filtro de clientes para la monitorización WiFi

Al monitorizar una WiFi se mostrará una alarma cada vez que un dispositivo

se conecte. El usuario podrá agregar un filtro a ciertos dispositivos para que

no se muestre la alarma cuando se conecten.

• Generar gráficos estadísticos

Generar gráficos con las estadísticas del número de clientes conectados a

las redes WiFi.

• Monitorizar varias redes WiFi a la vez.

78/117

8. Bibliografía8. Bibliografía

8. 8. BibliografíaBibliografía

8.1 8.1 MonografíasMonografías

GONZÁLEZ Duque, Raúl. Python para todos.

Henry, Jerome. CCNA Wireless 640-722 IUWNE Quick Reference. Cisco Press, 2012.

James Carroll, Brandon. CCNA Wireless Official Exam Certification Guide. Cisco

Press, 2009.

LARMAN, Craig. Aplying UML and patterns: an introduction to object-oriented

analysis and design and the Unified Process. Segunda edición. Upper Saddle River,

2002.

O'CONNOR, TJ. Violent Python: A cookbook for Hackers, Forensic Analyst,

Penetration Testers and Security Engineers. Primera Edición. 2012.

PILGRIM, Mark. Dive into Python. 2004.

RUIZ, Arkaitz y ORDUÑA, Pablo. Introducción a Python. 2006.

VAN ROSSUM, Guido. Guía de aprendizaje de Python. Release 02. Fred L. Drake Jr.,

2000.

ZAW, Shed A.. Learn Python The Hard Way. Release 02. 2010.

79/117


8.2 8.2 Textos electrónicosTextos electrónicos

BSSID [en línea]. Wikipedia. <http://es.wikipedia.org/wiki/BSSID>.

Dirección MAC [en línea]. Wikipedia. <http://es.wikipedia.org/wiki/Direcci

%C3%B3n_MAC>.

GNU Lesser General Public License [en línea]. Wikipedia.

<https://es.wikipedia.org/wiki/GNU_Lesser_General_Public_License>.

GNU/Linux [en línea]. Wikipedia. <http://es.wikipedia.org/wiki/GNU/Linux

http://docs.python.org/3/faq/general.html#what-is-python>.

GPL [en línea]. Wikipedia. <http://www.gnu.org/licenses/licenses.es.html#GPL>.

IBM [en línea]. Wikipedia. <http://es.wikipedia.org/wiki/IBM>.

IEEE [en línea]. Wikipedia. <http://es.wikipedia.org/wiki/IEEE>.

Interfaz gráfica de usuario [en línea]. Wikipedia.

<http://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario>.

Lenguaje Unificado de Modelado [en línea]. Wikipedia.

<https://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado>.

Línea de comandos [en linea]. Wikipedia. <http://es.wikipedia.org/wiki/L

%C3%ADnea_de_comandos>.

Proceso Unificado [en línea]. Wikipedia.

<http://es.wikipedia.org/wiki/Proceso_Unificado>.

Prueba unitaria [en línea]. Wikipedia .

<http://es.wikipedia.org/wiki/Prueba_unitaria>.

80/117

http://es.wikipedia.org/wiki/Prueba_unitaria

http://es.wikipedia.org/wiki/Proceso_Unificado

http://es.wikipedia.org/wiki/L%C3%ADnea_de_comandos

http://es.wikipedia.org/wiki/L%C3%ADnea_de_comandos

https://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

http://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario

http://es.wikipedia.org/wiki/IEEE

http://es.wikipedia.org/wiki/IBM


http://docs.python.org/3/faq/general.html#what-is-python

http://es.wikipedia.org/wiki/GNU/Linux

https://es.wikipedia.org/wiki/GNU_Lesser_General_Public_License

http://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC

http://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC

http://es.wikipedia.org/wiki/BSSID


Punto de acceso inalámbrico [en línea]. Wikipedia.

<http://es.wikipedia.org/wiki/Punto_de_acceso_inal%C3%A1mbrico>.

PURCELL, Steve. Pyunit – the standard unit testing framework for Python [en

línea].<http://pyunit.sourceforge.net/>.

SSID [en línea]. Wikipedia. <http://es.wikipedia.org/wiki/Wi-Fi>.

81/117

http://es.wikipedia.org/wiki/Wi-Fi



http://pyunit.sourceforge.net/

http://es.wikipedia.org/wiki/Punto_de_acceso_inal%C3%A1mbrico

9. Glosario9. Glosario

9. 9. GlosarioGlosario

Término Definición e información Alias

802.11

Estándar que define el uso de dos

niveles inferiores de la arquitectura

OSI, especificando sus normas de

funcionamiento en una red de área

local inalámbrica (WLAN).

IEEE 802.11

Arquitectura

[hardware]

Diseño conceptual y estructura

operacional fundamental de una

computadora.

BluetoothEspecificación industrial para Redes

Inalámbricas de Área Personal (WPAN).

Broadcast

Forma de transmisión de información

donde un nodo emisor envía

información a una multitud de nodos

receptores de manera simultánea, sin

necesidad de reproducir la misma

transmisión nodo por nodo.

Difusión

BSSID

Nombre de identificación único que

identifica todos los paquetes de una

red inalámbrica de área local (WLAN).

Basic Service Set

Identifier

CLI

Método que permite a las personas dar

instrucciones a algún programa

informático por medio de una línea de

texto simple.

Command Line

Interface

Codificación

[de caracteres]

Método que permite convertir un

caracter de un lenguaje natural en un

símbolo de otro sistema de

representación.

Charset

Encoding.

82/117



Conmutador

Dispositivo digital lógico de

interconexión de redes de

computadoras que opera en la capa de

enlace de datos del modelo OSI.

Switch

CSMA/CA

Carrier Sense Multiple Access/Collision

Avoidance (Acceso Múltiple por

Detección Portadora/Anticolisión).

Protocolo para transmisiones en redes

802.11.

Driver

Programa informático que permite al

sistema operativo interactuar con un

periférico.

Controlador

Controlador software.

IEEE

Institute of Electrical and Electronic

Engineers (Instituto de ingenieros

Eléctricos y Electrónicos). Asociación

técnico profesional dedicada a la

estandarización.

Interfaz de red

Periférico que permite la comunicación

con aparatos electrónicos.

Tarjeta de red

NIC

ISM (banda)

Industrial, Scientific and Medical band

(Banda Industrial, Científica y Médica).

Bandas reservadas internacionalmente

para uso no comercial de

radiofrecuencia en áreas industriales,

científicas y médicas.

LANLocal Area Network (Red de Área

Local).

Red local.

83/117



Licencias

[software]

Contrato entre el autor o titular de los

derechos de explotación/distribución

de un programa informático y el

licenciatario.

Licencia

privativa

[software]

Licencia de software de código cerrado. Licencia de código

cerrado

Licencia propietaria

MAC

Media Access Control (Control de

Acceso al Medio). Identificador de 48

bits que corresponde de forma única a

una tarjeta o dispositivo de red.

Modo texto

Interfaz que se comunica con el

usuario mediante líneas de comandos

(CLI).

Interfaz de línea de

comandos

OUI

Número de 24 bits comprado al IEEE,

que identifica a cada empresa u

organización a nivel mundial y reserva

un bloque en cada posible identificador

derivado (direcciones MAC, direcciones

de grupos, etc.) para el uso exclusivo

del asignado.

Organizationally

Unique Identifier

Punto de acceso

Dispositivo electrónico que permite la

conexión inalámbrica de un equipo

móvil de cómputo (ordenador, tableta,

smartphone) con una red.

PA

AP

WAP

Segundo plano

Proceso que se ejecuta con prioridad

baja y no siempre tiene la CPU de

forma secuencial ejecutando su código.

Background

84/117



Smartphone

Teléfono móvil con capacidades de

almacenamiento y procesamiento de

datos similares a una mini

computadora.

Teléfono inteligente

Software

Equipamiento lógico o soporte lógico

de un sistema informático.

Programa

Aplicación.

SSID

Service Set Identifier (Identificador de

Conjunto de Servicios). Nombre

incluido en todos los paquetes de una

red inalámbrica para identificarlos

como parte de la misma.

Service Set IDentifier

Tableta

Computadora portátil de mayor

tamaño que un smartphone o una PDA,

integrada en una pantalla multitáctil.

Tablet

TCP

Transmission Control Protocol

(Protocolo de Transmisión de Control).

Protocolo fundamental en internet.

UDP

User Datagram Protocol (Protocolo de

Datagrama de Usuario). Protocolo de

nivel de transporte de red.

UTF-8Formato de codificación de caracteres

Unicode e ISO 10646.

UTF8

Wi-FiMecanismo de conexión de dispositivos

electrónicos de forma inalámbrica.

Wifi

WLANWireless Area Network (Red

inalámbrica de área local).

85/117

10. Apéndices10. Apéndices

10. 10. ApéndicesApéndices

10.1 10.1 Índice de figurasÍndice de figuras

Red Ad-Hoc..............................................................................................................14

Basic Service Area...................................................................................................15

Extended Service Area.............................................................................................15

Diagrama de Caso de Uso Usuario...........................................................................38

Gráfico del Modelo de Dominio de la aplicación.......................................................45

Diagrama de Secuencia del Sistema Registrar Actividad.........................................46

Diagrama de Secuencia del Sistema Monitorizar Red..............................................47

Diagrama de Secuencia del Sistema Analizar Registro............................................48

Arquitectura Lógica..................................................................................................49

Diagrama de clases global.......................................................................................51

Subsistema Airodump..............................................................................................53

Subsistema CLI........................................................................................................54

Diagrama de Secuencia Ejecutar airodump.............................................................55

Subsistema GUI........................................................................................................56

Diagrama de Secuencia Monitorizar red...................................................................57

Subsistema LOG.......................................................................................................58

Diagrama de Secuencia Analizar Registro................................................................60

Subsistema Sistema.................................................................................................61

Diagrama de Secuencia Restaurar sistema..............................................................62

Escenario de pruebas para análisis..........................................................................68

Resultados de test de análisis - Interfaz gráfica de wiFIC.........................................70

Resultados de análisis - Punto de Acceso falso........................................................70

Resultados de test de análisis - Dispositivo peligroso..............................................71

Diagrama de Gantt..................................................................................................74

Detalle de las fases del diagrama de Gantt.............................................................74

86/117


10.2 10.2 Índice de tablasÍndice de tablas

Atributos y relaciones de las clases conceptuales....................................................40

Relación entre las clases del subsistema Log...........................................................59

Pruebas de rendimiento...........................................................................................73

Glosario....................................................................................................................82

87/117


10.3 10.3 Pruebas unitarias (código fuente y resultados)Pruebas unitarias (código fuente y resultados)

10.3.1 10.3.1 Test airodumpTest airodump

10.3.1.1 10.3.1.1 Código fuenteCódigo fuente

#!/usr/bin/env python

#_*_ coding:utf-8 _*

'''

@author: Rubén Hortas Astariz

'''

import airodump

import os

import unittest

# Comprobar la función Check_aircrack()

class airodump_instalado(unittest.TestCase):

"""

Simula que aircrack está instalado

"""

fake_aircrack_path = ''

# Textfiuture (Prepara el contexto)

def setUp(self):

print 'Comprobado la función Check_aircrack'

88/117


print 'Simulando que aircrack-ng está instalado'

print 'Preparando el contexto...'

# Preparar directorios falsos para simular que aircrack-ng

# está instalado

self.fake_aircrack_path = os.path.join(os.getcwd(), 'aircrack-

ng')

os.mkdir(self.fake_aircrack_path)

self.paths = []

self.paths.append(os.getcwd())

def test(self): # aircrack-ng instalado

r = airodump.Check_aircrack(self.paths)

self.assertEqual(r, True, msg=None)

def tearDown(self): # deshacer el contexto

os.rmdir(self.fake_aircrack_path)

print

class airodump_no_instalado(unittest.TestCase):

"""

Simula que aircrack-ng *no* está instalado

"""

# Textfiture (Preparar el contexto)

def setUp(self):

print 'Comprobando la función Check_aircrack'

89/117


print 'Simulando que aircrack *no* está instalado'

print 'Preparando el contexto...'

# Preparar directorios falsos para simular que aircrack-ng

# *no* está instalado

self.paths = []

self.paths.append(os.getcwd())

def test(self): # aircrack-ng no instalado

r = airodump.Check_aircrack(self.paths)

self.assertEqual(r, False, msg=None)

print 'El mensaje de error indica que todo ha ido bien'

print

if __name__ == '__main__':

unittest.main()

10.3.1.2 10.3.1.2 ResultadosResultados

$ python test_airodump.py

Comprobado la función Check_aircrack

Simulando que aircrack-ng está instalado

Preparando el contexto...

.Comprobando la función Check_aircrack

Simulando que aircrack *no* está instalado

Preparando el contexto...

[ERROR] aircrack-ng no está instalado.

El mensaje de error indica que todo ha ido bien

90/117


.

----------------------------------------------------------------------

Ran 2 tests in 0.001s

OK

10.3.2 10.3.2 Test OUITest OUI




'''


'''

import unittest

import oui

class check_oui(unittest.TestCase):

def test(self):

#Probar con unas cuantas MAC cogidas al azar de oui.txt

#Los últimos 5 dígitos de la MAC son inventados

#OUI usa los 6 primeros

#00002F TIMEPLEX INC.

manuf = oui.Find_manufacturer('00:00:2F:AA:BB:CC')

91/117


self.assertEqual(manuf, 'TIMEPLEX INC.', msg=None)

#00040F Asus Network Technologies, Inc.

manuf = oui.Find_manufacturer('00:04:0F:AA:BB:CC')

self.assertEqual(manuf, 'Asus Network Technologies, Inc.',

msg=None)

#549B12 Samsung Electronics

manuf = oui.Find_manufacturer('54:9B:12:AA:BB:CC')

self.assertEqual(manuf, 'Samsung Electronics', msg=None)

#7C7BE4 Z'SEDAI KENKYUSHO CORPORATION

manuf = oui.Find_manufacturer('7C:7B:E4:AA:BB:CC')

self.assertEqual(manuf, "Z'SEDAI KENKYUSHO CORPORATION",

msg=None)

#Un dipostivo inventado

manuf = oui.Find_manufacturer('01:02:03:AA:BB:CC')

self.assertEqual(manuf, None, msg=None)

if __name__ == "__main__":

unittest.main()


$ python ./test_oui.py

.

----------------------------------------------------------------------

Ran 1 test in 0.098s

92/117


OK

10.3.3 10.3.3 Test parse_logTest parse_log




'''


'''

import os

import unittest

import parse_log

#from parse_log import Update_dicts_dev

import clases_ap_dev

class check_log_fail(unittest.TestCase):

"""

Comprueba el correcto funcionamiento de Check_file_log()

"""

f_log = 'asdasd.log' # Un fichero que no exista

93/117


def test(self):

print 'Comprobando la función Check_file_log'

r = parse_log.Check_file_log(self.f_log)

self.assertEqual(r, 0, msg=None)

print 'El mensaje de error indica que todo ha ido

correctamente.'

print

class check_add_new_dev(unittest.TestCase):

"""

Comprueba el correcto funcionamiento de Update_dict_devs() al

añadir un

nuevo dispositivo de red.

"""


def setUp(self):

print 'Preparando el contexto para las pruebas de

Update_dict_devs()'

self.dict_devs = {}

self.dict_dang_devs = {}

def test_new_dev(self):

dev_first_seen = '2013-01-01 00:00:00'

dev_mac = '00:00:00:01'

dev_essid = '01:00:00:00'

dev_bssid = 'AP1'

94/117


dev = clases_ap_dev.device(dev_first_seen, dev_mac, dev_essid)

dev.bssid = dev_bssid

conexion = dev.essid + ' (' + dev_bssid + ')'

print

print 'Comprobando al añadir un nuevo dispositivo'

parse_log.Update_dicts_dev(dev, conexion, self.dict_devs,

self.dict_dang_devs)

self.assertEqual(self.dict_devs,

{'00:00:00:01': [['01:00:00:00 (AP1)'],

'2013-01-01 00:00:00']},

msg=None)

self.assertEqual(self.dict_dang_devs, {}, msg=None)

print

class check_add_dev_cons(unittest.TestCase):

"""

Inicialización para los test de añadir más conexiones a un

dispositivo registrado.

"""


def setUp(self):

"""

Añadir un primer registro de un dispositivo

95/117


"""

print 'Preparando el entorno para probar añdir más conexiones

a un' \

+ ' dispositivo de red...'

self.dict_devs = {}


self.dev = None

# Añadir la primera conexión de un dispositivo

dev_first_seen = '2013-01-01 00:00:00'

dev_mac = '00:00:00:01'

dev_essid = '01:00:00:00'

dev_bssid = 'AP1'

self.dev = clases_ap_dev.device(dev_first_seen, dev_mac,

dev_essid)

self.dev.bssid = dev_bssid

conexion = dev_essid + ' (' + dev_bssid + ')'

parse_log.Update_dicts_dev(self.dev, conexion, self.dict_devs,


class check_add_dev_registered_con(check_add_dev_cons):

"""

Comprobar el caso de añadir un dispositivo ya registrado con una

conexión

96/117


ya registrada

"""

def test(self):

print 'Comprobando al añadir un dispositivo ya registrado con'

+ \

' una conexión ya registrada'

#Con cambiar sólo la hora basta, es una conexión al mismo AP

#Para el resto de los datos valen los de self.dev del setUP

new_first_seen = '2013-01-01 00:00:05'

new_dev = clases_ap_dev.device(new_first_seen, self.dev.mac,

self.dev.bssid)

conexion = self.dev.essid + ' (' + self.dev.bssid + ')'

parse_log.Update_dicts_dev(new_dev, conexion, self.dict_devs,


self.assertEqual(self.dict_devs, {'00:00:00:01':

[['01:00:00:00 (AP1)'],

'2013-01-01 00:00:00']},

msg=None)

self.assertEqual(self.dict_dang_devs, {}, msg=None)

print

class check_add_dang_dev(check_add_dev_cons):

"""

97/117


Comprobar el caso de añadir una conexión de un dispositivo ya

registrado a otro AP.

"""

def test(self):

print 'Añadiendo una conexión de un dispositivo ya registrado'

+ \

' a otro AP'

new_first_seen = '2013-01-01 02:0:00'

new_essid = '02:00:00:00'

new_bssid = 'AP2'

new_dev = clases_ap_dev.device(new_first_seen, self.dev.mac,

new_bssid)

conexion = new_essid + ' (' + new_bssid + ')'

parse_log.Update_dicts_dev(new_dev, conexion, self.dict_devs,



{'00:00:00:01': [['01:00:00:00 (AP1)',

'02:00:00:00 (AP2)'],

'2013-01-01 00:00:00']},

msg=None)

self.assertEqual(self.dict_dang_devs,

{'00:00:00:01': ['01:00:00:00 (AP1) - ' + \

'2013-01-01 00:00:00',

'02:00:00:00 (AP2) -' + \

98/117


' 2013-01-01 02:0:00']},

msg=None)

print

class check_add_ap(unittest.TestCase):

"""

Comprobar que se añada un nuevo AP correctamente

"""


def setUp(self):

print 'Preparando el contexto para la prueba de añadir nuevo

ap'

self.dict_aps = {}

self.dict_dang_aps = {}

def test_new_ap(self):

ap_first_seen = '00:00:01'

ap_bssid = 'AP1'

ap_channel = '1'

ap_encryption = 'WPA2'

ap_essid = '01:00:00:00'

ap = clases_ap_dev.ap(ap_first_seen, ap_bssid, ap_channel,

ap_encryption, ap_essid)

parse_log.Update_dicts_ap(ap, self.dict_aps,

self.dict_dang_aps)

99/117


self.assertEqual(self.dict_aps,

{'AP1': [['01:00:00:00'],

'01:00:00:00 - 00:00:01 - Ch. 1 -

WPA2']},

msg=None)

self.assertEqual(self.dict_dang_aps, {}, msg=None)

class check_add_new_ap(unittest.TestCase):

"""

Inicialiación para los test de añadir más APs.

"""

def setUp(self):

print 'Preparando el contexto para los test de añadir más APs'

self.dict_aps = {}


ap_first_seen = '00:00:01'

ap_bssid = 'AP1'

ap_channel = '1'

ap_encryption = 'WPA2'

ap_essid = '01:00:00:00'

self.ap = clases_ap_dev.ap(ap_first_seen, ap_bssid,

ap_channel,

ap_encryption, ap_essid)

100/117


parse_log.Update_dicts_ap(self.ap, self.dict_aps,

self.dict_dang_aps)

class check_add_registered_ap(check_add_new_ap):

"""

Comprobar el caso de añadir un AP ya registrado

"""

def test(self):

print 'Añadiendo un AP ya registrado'

#Añadir el mismo ap con otra hora

new_first_seen = '00:05:00:'

new_ap = clases_ap_dev.ap(new_first_seen, self.ap.bssid,

self.ap._ap__channel,

self.ap._ap__encryption,

self.ap.essid)

parse_log.Update_dicts_ap(new_ap, self.dict_aps,

self.dict_dang_aps)


{'AP1': [['01:00:00:00'],

'01:00:00:00 - 00:00:01 - Ch. 1 -

WPA2']},

msg=None)

self.assertEqual(self.dict_dang_aps, {}, msg=None)

101/117


class check_add_rogue_ap(check_add_new_ap):

"""

Comprobar el caso de añadir un Roque AP (punto de acceso falso)

"""

def test(self):

#Crear un roque AP

rogue_ap_first_seen = '00:00:01'

rogue_ap_bssid = 'AP1' # El mismo BSSID

rogue_ap_channel = '1'

rogue_ap_encryption = 'WPA2'

rogue_ap_essid = '01:02:03:04'

rogue_ap = clases_ap_dev.ap(rogue_ap_first_seen,

rogue_ap_bssid,

rogue_ap_channel,

rogue_ap_encryption,

rogue_ap_essid)

parse_log.Update_dicts_ap(rogue_ap, self.dict_aps,

self.dict_dang_aps)


{'AP1': [['01:00:00:00', '01:02:03:04'],

'01:00:00:00 - 00:00:01 - Ch. 1 -

WPA2']},

msg=None)

self.assertEqual(self.dict_dang_aps,

{'AP1': ['01:00:00:00 - 00:00:01 - Ch. 1 -

WPA2',

102/117


'01:02:03:04 - 00:00:01 - Ch. 1 -

WPA2']},

msg=None)

class check_parse_log(unittest.TestCase):

"""

Comprueba el correcto funcionamiento de Parse_log()

"""


def setUp(self):

print 'Preparando el contexto para las pruebas de Parse_log()'

self.parent_dir = os.path.abspath(os.path.join(os.getcwd(),

os.pardir))

self.f_log = os.path.join(self.parent_dir, 'logsTESTS',

'wific_escenario')

self.pos = [0]

self.dict_devs = {}


self.dict_aps = {}


def test(self):

print 'Comprobando la función Parse_log'

print 'Utilizando el fichero de log: ', self.f_log

parse_log.Parse_log(self.f_log, self.pos, self.dict_devs,

self.dict_dang_devs, self.dict_aps,

self.dict_dang_aps)

103/117


#dict_devs


{'00:00:00:00:00:02': [['02:00:00:00:00:00

(AP2)'],

'2013-01-01

00:00:00'],

'00:00:00:00:00:01': [['01:00:00:00:00:00

(AP1)',

'02:00:00:00:00:00

(AP2)',

'03:00:00:00:00:00

(AP3)',

'04:00:00:00:00:00

(AP4)'],

'2013-01-01

00:00:00']},

msg=None)

#dict_dang_devs

self.assertEqual(self.dict_dang_devs,

{'00:00:00:00:00:01': ['01:00:00:00:00:00

(AP1) -' + \

' 2013-01-01

00:00:00',

'02:00:00:00:00:00

(AP2) -' + \

' 2013-01-02

00:00:00',

'03:00:00:00:00:00

(AP3) -' + \

104/117


' 2013-01-03

00:00:00',

'04:00:00:00:00:00

(AP4) -' + \

' 2013-01-04

00:00:00']},

msg=None)

#dict_aps


{'AP2': [['02:00:00:00:00:00'],

'02:00:00:00:00:00 - 2013-01-01

00:00:00' + \

' - Ch. 5 - WPA'],

'AP3': [['03:00:00:00:00:00'],

'03:00:00:00:00:00 - 2013-01-01

00:00:00' + \

' - Ch. 5 - WEP'],

'AP1': [['01:00:00:00:00:00',

'05:00:00:00:00:00'],

'01:00:00:00:00:00 - 2013-01-01

00:00:10' + \

' - Ch. 5 - WPA2'],

'AP4': [['04:00:00:00:00:00'],

'04:00:00:00:00:00 - 2013-01-01

00:00:00' + \

' - Ch. 5 - WPA2']},

msg=None)

#dict_dang_aps

105/117


self.assertEqual(self.dict_dang_aps,

{'AP1': ['01:00:00:00:00:00 - 2013-01-01

00:00:10' + \

' - Ch. 5 - WPA2',

'05:00:00:00:00:00 - 2013-01-01

01:00:10' + \

' - Ch. 3 - WPA2']})

if __name__ == '__main__':

unittest.main()


$ python ./test_parse_log.py

Preparando el contexto para la prueba de añadir nuevo ap

.Preparando el entorno para probar añdir más conexiones a un

dispositivo de red...

Añadiendo una conexión de un dispositivo ya registrado a otro AP

.Preparando el entorno para probar añdir más conexiones a un

dispositivo de red...

Comprobando al añadir un dispositivo ya registrado con una conexión ya

registrada

.Preparando el contexto para las pruebas de Update_dict_devs()

Comprobando al añadir un nuevo dispositivo

.Preparando el contexto para los test de añadir más APs

Añadiendo un AP ya registrado

.Preparando el contexto para los test de añadir más APs

.Comprobando la función Check_file_log

106/117


[ERROR] El fichero de log de wiFIC no existe

El mensaje de error indica que todo ha ido correctamente.

.Preparando el contexto para las pruebas de Parse_log()

Comprobando la función Parse_log

Utilizando el fichero de log: /home/ruben/***/wific_escenario

.

----------------------------------------------------------------------

Ran 8 tests in 0.020s

OK

10.3.3.3 10.3.3.3 NotasNotas

Por simplicidad se ha suprimido la ruta original al fichero de registro utilizado para

las pruebas.

107/117


10.4 10.4 Manual de usuarioManual de usuario

10.4.1 10.4.1 DependenciasDependencias

Para poder utilizar la aplicación, en el sistema deberán estar instalados los

siguientes paquetes software en sus respectivas versiones:

aircrack-ng >= 1.1

python >= 2.7 < 3

python-wxgtk >= 2.8 <3

10.4.2 10.4.2 Utilizando el sistemaUtilizando el sistema

10.4.2.1 10.4.2.1 Modo textoModo texto

Para minimizar el consumo de recursos en el equipo anfitrión, la aplicación puede

realizar la captura de información en modo texto (o modo consola). Para utilizar

este modo basta con ejecutar el archivo cli.py como usuario administrador o root.

La orden de ejecución del archivo es:

# python cli.py interfaz

* Substituyendo interfaz por el alias de la interfaz de red que se quiere utilizar.

En caso de no detectar ningún error, la aplicación procederá a la recolección de

datos. En caso contrario informará del error.

108/117


La aplicación se podrá detener en cualquier momento utilizando la combinación de

teclas CTRL+C.

10.4.2.2 10.4.2.2 Interfaz gráficaInterfaz gráfica

Para iniciar la aplicación en modo gráfico habrá que ejecutar el archivo wific.py

como usuario administrador o root.

109/117

Ilustración 4: Ejemplo utilizando wlan0 como interfaz de red

Ilustración 5: Interfaz gráfica, ventana principal


1. Botón ON/OFF

Inicia/detiene el análisis de datos de las redes WiFi al alcance.

2. Botón de selección de interfaz de red

Lista desplegable para seleccionar la interfaz de red con la que se realizará la

recogida de los datos de las redes WiFi.

3. Botón de análisis

Inicia/detiene el análisis de datos.

Si la captura de datos está detenida, este botón inicia un análisis de forma

retrospectiva, es decir, la aplicación analiza el fichero con la información recogida

durante sesiones anteriores.

Si la captura de datos está activa, el botón inicia/detiene el análisis de los datos

recogidos en tiempo real.

Según el estado en el que se encuentre la aplicación, el botón mostrará el texto con

la función que realizará, “Analizar” o “Detener Análisis”.

4. Botón de monitorizar WiFi

Este botón sólo está habilitado si el análisis de datos está activo.

Muestra una ventana para seleccionar la red que se quiere monitorizar, y una vez

seleccionada muestra los dispositivos que tiene asociados.

5. Barra de estado

Barra que muestra el estado en el que se encuentra la aplicación.

110/117


10.4.2.2.1 10.4.2.2.1 AnálisisAnálisis

El sistema puede realizar análisis en tiempo real (si está capturando información) o

de forma retrospectiva. Una vez analizando (o realizado el análisis) el sistema

mostrará la información en la ventana de análisis.

6. Lista de selección de elementos

Lista para seleccionar el tipo de dispositivos a analizar. La ventana de peligros (7)

mostrará los elementos peligrosos del tipo seleccionado.

Opciones:

• Todo: Muestra los dispositivos inalámbricos y los puntos de acceso

peligrosos detectados.

• Dispositivos: Muestra únicamente los dispositivos inalámbricos peligrosos

detectados.

Un dispositivo se considera peligroso cuando se ha conectado a varias redes

WiFi.

• Puntos de acceso: Muestra únicamente los puntos de acceso peligrosos

detectados.

Un punto de acceso se considera peligroso cuando existe un mismo ESSID (o

nombre de red) con diferentes direcciones BSSID.

7. Ventana de peligros

111/117

Ilustración 6: Ejemplo de ventana de análisis


Esta ventana muestra los peligros encontrados del tipo escogido en la lista de

selección de elementos (6).

Punto de acceso peligroso

7.1 ESSID (nombre de la red)

7.2 Direcciones BSSID de los puntos de acceso que tienen el mismo ESSID.

7.3 Fecha y hora en la que se detectó el punto de acceso.

7.4 Canal utilizado por el punto de acceso para transmitir información.

7.5 Cifrado utilizado por el punto de acceso.

7.6 Fabricante (o marca) del punto de acceso.

112/117

Ilustración 7: Ejemplo de punto de acceso peligroso


Dispositivo inalámbrico peligroso

7.7 Dirección MAC del dispositivo

7.8 Fabricante (o marca) del dispositivo

7.9 BSSID del punto de acceso al que estaba asociado el dispositivo.

7.10 ESSID del punto de acceso al que estaba asociado el dispositivo.

7.11 Fecha y hora en la que se detectó la conexión.

7.12 Fabricante (o marca) del punto de acceso al que estaba asociado el

dispositivo.

8. Ventana de información de conexiones

Esta ventana muestra la información sobre las conexiones del elemento

seleccionado en la ventana de peligros (7).

La información mostrada en esta ventana se detalla en los apartados 7.1-6 para los

puntos de acceso y 7.7-12 para los dispositivos inalámbricos.

113/117

Ilustración 8: Ejemplo de dispositivo peligroso


9. Botón Guardar

Guarda en un fichero (para el que el usuario escoge la ruta y la extensión) la

información mostrada en la ventana de información de conexiones (8).

10. Botón Cerrar/Detener análisis

Cierra la ventana de análisis.

Si el sistema está realizando un análisis en tiempo real, este botón mostrará el texto

“Detener análisis”, al pulsarlo detendrá el análisis en tiempo real y mostrará el

texto “Cerrar análisis”.

114/117

Ilustración 9: Ejemplo de informe generado


10.4.2.2.2 10.4.2.2.2 Monitorizar una WiFiMonitorizar una WiFi

Si el sistema está capturando información, una vez pulsado el botón “Monitorizar

WiFi” (4), se mostrará una ventana con la lista de redes WiFi al alcance, donde se

podrá seleccionar una para monitorizar.

Una vez seleccionada la WiFi a monitorizar, el sistema mostrará los dispositivos que

la red tiene asociados.

115/117

Ilustración 10: Ejemplo de lista de WiFis

para monitorizar


1. ESSID (dirección) y BSSID (nombre de red) del punto de acceso que crea la

red.

2. Direcciones MAC de los dispositivos asociados.

3. Fecha y hora en la que se conectaron los dispositivos a la red por primera

vez.

4. Fabricante (o marca) del dispositivo inalámbrico asociado a la red.

5. El botón “Cerrar” cancela la monitorización y cierra la ventana.

116/117

Ilustración 11: Ejemplo de dispositivos asociados a una red WiFi


10.5 10.5 Notas sobre la terminología utilizadaNotas sobre la terminología utilizada

Root: Se ha utilizado este término para referirse al usuario administrador en un

sistema operativo GNU/Linux y MAC OS X, en lugar de su traducción “usuario raíz”,

por ser el nombre que tiene el usuario, y para diferenciarlo del usuario

“Administrador” que utiliza el sistema operativo Windows.

WiFi: Se ha utilizado este término en lugar de su traducción “red inalámbrica”

para diferenciar las redes inalámbricas que utilizan la tecnología Wi-Fi de otras

redes inalámbricas implementadas con otras tecnologías (bluetooth, WIMAX etc.)

También se ha optado por estos términos, y por otros como “software” y

“hardware”, por tratarse de términos de uso frecuente y estar completamente

aceptados.

117/117

Sistema de monitorazión de redes wifi - tic.udc.es · ejemplo intrusos o falsos puntos de acceso....

Documents

Transcript of Sistema de monitorazión de redes wifi - tic.udc.es · ejemplo intrusos o falsos puntos de acceso....