Sistema de monitorazión de redes wifi

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. 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. Resumen
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. Palabras clave
Seguridad, redes, inalámbricas, Wi-Fi, WIFI, historial, monitorización, python.
Í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ón
1. Introducció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 (17751836). 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
1. Introducción
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
1. Introducción
•
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
1. Introducción
•
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
1. Introducción
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).
Ilustración 1: Red Ad-Hoc
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
1. Introducción
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).
Ilustración 2: Basic Service Area (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).
Ilustración 3: Extended Service Area (ESA)
15/117
1. Introducción
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
1. Introducción
•
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
1. Introducción
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
1. Introducción
•
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
1. Introducción
•
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 Organización del proyecto
1.1.1 Memoria
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
1. Introducción
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. Introducción
1.1.1 Herramientas
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
1. Introducción
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
1. Introducción
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
1. Introducción
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
1. Introducción
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
1. Introducción
•
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
1. Introducción
•
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://boaconstructor.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
1. Introducción
1.2 Objetivos 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
1. Introducción
•
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ía
2. Metodologí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 Especificació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. Metodología
2.1.1 Requisitos funcionales
2.1.1.1 Funcionalidades
2.1.1.1.1 Registro 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 Monitorizació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 Aná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
2. Metodología
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 Guardar 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 Seguridad
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 Requisitos no funcionales
2.1.2.1 Usabilidad
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. Metodología
2.1.2.2 Fiabilidad
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 Rendimiento
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 Soporte
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 Análisis de requisitos
2.2.1 Casos 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. Metodología
2.2.1.1 Registrar 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. Metodología
2.2.1.2 Monitorizar red
Descripción: El usuario quiere monitorizar una red inalámbrica para saber qué
dispositivos tiene asociados.
Actor principal: Usuario.
Escenario principal de éxito (Flujo básico de eventos)
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.
Extensiones (Flujos alternativos de eventos)
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. Metodología
2.2.1.3 Analizar 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.
Actor principal: Usuario.
Escenario principal de éxito (Flujo básico de eventos)
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.
Extensiones (Flujos alternativos de eventos)
*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. Metodología
2.2.2 Diagramas de Casos de uso
2.2.2.1 Usuario
figura 1: : Diagrama de casos de uso Usuario
2.2.3 Modelo de dominio
2.2.3.1 Descripción textual de las clases conceptuales del
modelo 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
2. Metodología
•
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.
Ejemplos de casos de uso:
•
Analizar registro
•
Guardar Registro
•
Registrar actividad
39/117
2. Metodología
•
Usuario: Esta clase representa a la persona que utiliza la aplicación. Es el
actor principal en todos los casos de uso.
Ejemplos de casos de uso:
•
Registrar actividad
•
Monitorizar red
•
Analizar registro
2.2.3.2 Atributos y relaciones de las clases conceptuales
Clase conceptual
Atributos
Relaciones
hora: Hora a la que se
tiene [punto de
detectó la conexión.
acceso]: Una conexión
está formada por, al
tipo de dispositivo:
Dispositivo inalámbrico o
menos, un punto de
acceso.
Punto de acceso.
tiene [dispositivo
inalámbrico]: Una
conexión puede estar
formada por un dispositivo
Conexión
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
2. Metodología
Clase conceptual
Atributos
Relaciones
mac: Dirección MAC del
Conexión tiene: Una
dispositivo.
conexión puede estar
formada por un dispositivo
essid: ESSID del punto de
Dispositivo inalámbrico
acceso al que estaba
inalámbrico asociado a un
punto de acceso.
asociado el dispositivo.
bssid: BSSID del punto de
acceso al que estaba
asociado el dispositivo.
Interfaz de red
nombre: Nombre que da
Usuario selecciona: El
el sistema operativo a las
usuario tiene que
interfaces de red
seleccionar una interfaz de
instaladas en el equipo.
red para poder monitorizar
una red inalámbrica o para
registrar la actividad en
las redes inalámbricas al
alcance.
41/117
2. Metodología
Clase conceptual
Atributos
Relaciones
essid: ESSID del punto de
Conexión tiene: Una
acceso.
conexión está formada
por, al menos, un punto de
bssid: BSSID del punto de
acceso.
acceso.
canal: Número de canal
Punto de acceso
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).
tiene [conexión]: Una
red inalámbrica está
compuesta por una o
varias conexiones.
Red inalámbrica
Usuario monitoriza: Un
usuario puede monitorizar
una red inalámbrica o
todas las que tenga a su
alcance.
42/117
2. Metodología
Clase conceptual
Atributos
Relaciones
tiene [conexión]: Un
registro está compuesto
por un conjunto de
conexiones.
Usuario analiza: Un
usuario puede analizar el
resgistro con la intención
Registro
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
2. Metodología
Clase conceptual
Atributos
Relaciones
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
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. Metodología
2.2.3.3 Gráfico del modelo de dominio
figura 2: Gráfico del modelo de dominio de la aplicación
45/117
2. Metodología
2.2.4 Diagramas de secuencia del sistema (DSS)
2.2.4.1 Registrar actividad
figura 3: Diagrama de Secuencia del Sistema Registrar actividad
46/117
2. Metodología
2.2.4.2 Monitorizar red
figura 4: Diagrama de Secuencia del Sistema Monitorizar Red
47/117
2. Metodología
2.2.4.3 Analizar registro
figura 5: Diagrama de Secuencia del Sistema Analizar Registro
48/117
2. Metodología
2.2.5 Arquitectura lógica
Esta sección describe como las clases software se organizan a gran escala en
paquetes UML, subsistemas y capas.
figura 6: Arquitectura lógica
49/117
2. Metodología
2.2.5.1 Airodump
Este paquete engloba todas las operaciones relacionadas con airodump-ng, por
ejemplo verificar si está instalado o ejecutarlo.
2.2.5.2 CLI
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 Log
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 Sistema
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. Metodología
2.2.6 Diagrama de clases global
figura 7: Diagrama de clases global
51/117
2. Metodología
2.2.6.1 Notas 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 Aná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. Metodología
2.2.7.1 Airodump
figura 8: Subsistema Airodump
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 airodumpng.
53/117
2. Metodología
2.2.7.2 CLI
figura 9: Subsistema CLI
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
2. Metodología
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
figura 10: Diagrama de Secuencia Ejecutar airodump
55/117
2. Metodología
2.2.7.3 GUI
figura 11: Subsistema GUI
Este subsistema representa a la interfaz gráfica, y engloba todas las operaciones
necesarias para su funcionamiento.
Descripción de las clases incluidas en el subsistema:
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
2. Metodología
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.
Las clases de este subsistema no tienen relación con las clases conceptuales por
encontrase fuera del dominio del sistema.
Diagrama de secuencia Monitorizar red
figura 12: Diagrama de Secuencia Monitorizar red
57/117
2. Metodología
2.2.7.4 Log
Este subsistema agrupa las clases necesarias para mantener el registro de
información de la aplicación.
figura 13: Subsistema LOG
58/117
2. Metodología
Descripción de las clases incluidas en el subsistema:
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
2. Metodología
Diagrama de secuencia Analizar registro
figura 14: Diagrama de Secuencia Analizar registro
60/117
2. Metodología
2.2.7.5 Sistema
figura 15: Subsistema Sistema
Este subsistema representa las clases necesarias para la interacción entre la
aplicación y el sistema operativo.
Descripción de las clases incluidas en el subsistema:
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
2. Metodología
Las clases de este subsistema no tienen relación con las clases conceptuales por
encontrase fuera del modelo de dominio de la aplicación.
Diagrama de secuencia Restaurar Sistema
figura 16: Diagrama de Secuencia Restaurar sistema
62/117
3. Funcionalidades
3. Funcionalidades
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. 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 realizadas
4. Pruebas 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 Pruebas 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 Test 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 aircrackng esté instalado en el sistema.
–
Se comprueba el comportamiento de la aplicación en caso de que aircrackng no esté instalado en el sistema.
65/117
4. Pruebas realizadas
4.1.1.1 Notas
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 Test 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 Test 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
4. Pruebas realizadas
–
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 Conclusiones
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. Pruebas realizadas
4.3 Pruebas de análisis
4.3.1 Escenario predeterminado
Para comprobar los resultados de los análisis, se ha creado el siguiente escenario:
figura 17: Escenario de pruebas para análisis
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
4. Pruebas realizadas
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
4. Pruebas realizadas
figura 18: Interfaz gráfica de wiFIC
Los resultados obtenidos se mostrarán automáticamente.
4.3.2 Resultados
4.3.2.1 Punto de acceso falso
figura 19: Resultados de análisis - Punto de Acceso falso
70/117
4. Pruebas realizadas
4.3.2.2 Dispositivo peligroso
figura 20: Resultados de test de análisis - Dispositvo Peligroso
4.3.2.3 Notas
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 Conclusiones
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
4. Pruebas realizadas
4.4 Pruebas 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. Pruebas realizadas
4.4.1 Resultados
Tamaño de fichero
560
Tiempo
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 Notas
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 costes
5. Planificació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:
figura 21: Diagrama de Gantt
figura 22: Detalle de las fases del 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
5. 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. Conclusiones
6. Conclusiones
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 Objetivos
✔
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. Conclusiones
6.2 Cualidades 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 futuras
7. Lí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ía
8. Bibliografía
8.1 Monografí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. Bibliografía
8.2 Textos 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
8. Bibliografía
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
9. Glosario
9. Glosario
Término
Definición e información
Alias
Estándar que define el uso de dos
IEEE 802.11
niveles inferiores de la arquitectura
802.11
OSI, especificando sus normas de
funcionamiento en una red de área
local inalámbrica (WLAN).
Arquitectura
[hardware]
Bluetooth
Diseño conceptual y estructura
operacional fundamental de una
computadora.
Especificación industrial para Redes
Inalámbricas de Área Personal (WPAN).
Forma de transmisión de información Difusión
donde
Broadcast
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.
BSSID
Nombre de identificación único que
Basic Service Set
identifica todos los paquetes de una
Identifier
red inalámbrica de área local (WLAN).
Método que permite a las personas dar Command Line
CLI
instrucciones a algún programa
Interface
informático por medio de una línea de
texto simple.
Método que permite convertir un
Codificación
Charset
caracter de un lenguaje natural en un
[de caracteres] símbolo de otro sistema de
Encoding.
representación.
82/117
9. Glosario
Término
Definición e información
Dispositivo digital lógico de
Conmutador
Alias
Switch
interconexión de redes de
computadoras que opera en la capa de
enlace de datos del modelo OSI.
Carrier Sense Multiple Access/Collision
Avoidance (Acceso Múltiple por
CSMA/CA
Detección Portadora/Anticolisión).
Protocolo para transmisiones en redes
802.11.
Programa informático que permite al
Driver
Controlador
sistema operativo interactuar con un
periférico.
Controlador software.
Institute of Electrical and Electronic
Engineers (Instituto de ingenieros
IEEE
Eléctricos y Electrónicos). Asociación
técnico profesional dedicada a la
estandarización.
Periférico que permite la comunicación Tarjeta de red
Interfaz de red
con aparatos electrónicos.
NIC
Industrial, Scientific and Medical band
(Banda Industrial, Científica y Médica).
ISM (banda)
Bandas reservadas internacionalmente
para uso no comercial de
radiofrecuencia en áreas industriales,
científicas y médicas.
LAN
Local Area Network (Red de Área
Red local.
Local).
83/117
9. Glosario
Término
Definición e información
Alias
Contrato entre el autor o titular de los
Licencias
[software]
derechos de explotación/distribución
de un programa informático y el
licenciatario.
Licencia
Licencia de software de código cerrado. Licencia de código
cerrado
privativa
[software]
Licencia propietaria
Media Access Control (Control de
MAC
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
Interfaz de línea de
usuario mediante líneas de comandos
comandos
(CLI).
Número de 24 bits comprado al IEEE,
Organizationally
que identifica a cada empresa u
Unique Identifier
organización a nivel mundial y reserva
OUI
un bloque en cada posible identificador
derivado (direcciones MAC, direcciones
de grupos, etc.) para el uso exclusivo
del asignado.
Dispositivo electrónico que permite la
PA
conexión inalámbrica de un equipo
Punto de acceso
móvil de cómputo (ordenador, tableta,
AP
smartphone) con una red.
WAP
Proceso que se ejecuta con prioridad
Segundo plano
Background
baja y no siempre tiene la CPU de
forma secuencial ejecutando su código.
84/117
9. Glosario
Término
Definición e información
Teléfono móvil con capacidades de
Smartphone
Alias
Teléfono inteligente
almacenamiento y procesamiento de
datos similares a una mini
computadora.
Equipamiento lógico o soporte lógico
Software
Programa
de un sistema informático.
Aplicación.
Service Set Identifier (Identificador de
Service Set IDentifier
Conjunto de Servicios). Nombre
SSID
incluido en todos los paquetes de una
red inalámbrica para identificarlos
como parte de la misma.
Computadora portátil de mayor
Tableta
Tablet
tamaño que un smartphone o una PDA,
integrada en una pantalla multitáctil.
Transmission Control Protocol
TCP
(Protocolo de Transmisión de Control).
Protocolo fundamental en internet.
User Datagram Protocol (Protocolo de
UDP
Datagrama de Usuario). Protocolo de
nivel de transporte de red.
UTF-8
Wi-Fi
WLAN
Formato de codificación de caracteres
UTF8
Unicode e ISO 10646.
Mecanismo de conexión de dispositivos Wifi
electrónicos de forma inalámbrica.
Wireless Area Network (Red
inalámbrica de área local).
85/117
10. Apéndices
10. Apéndices
10.1 Í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. Apéndices
10.2 Í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. Apéndices
10.3 Pruebas unitarias (código fuente y resultados)
10.3.1 Test airodump
10.3.1.1 Có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
10. Apéndices
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(), 'aircrackng')
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
10. Apéndices
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 Resultados
$ 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
10. Apéndices
.
---------------------------------------------------------------------Ran 2 tests in 0.001s
OK
10.3.2 Test OUI
10.3.2.1 Código fuente
#!/usr/bin/env python
#_*_ coding:utf-8 _*
'''
@author: Rubén Hortas Astariz
'''
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
10. Apéndices
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()
10.3.2.2 Resultados
$ python ./test_oui.py
.
---------------------------------------------------------------------Ran 1 test in 0.098s
92/117
10. Apéndices
OK
10.3.3 Test parse_log
10.3.3.1 Código fuente
#!/usr/bin/env python
#_*_ coding:utf-8 _*
'''
@author: Rubén Hortas Astariz
'''
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
10. Apéndices
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.
"""
# Textfiture (Preparar el contexto)
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
10. Apéndices
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.
"""
# Textfiture (Preparar el contexto)
def setUp(self):
"""
Añadir un primer registro de un dispositivo
95/117
10. Apéndices
"""
print 'Preparando el entorno para probar añdir más conexiones
a un' \
+ ' dispositivo de red...'
self.dict_devs = {}
self.dict_dang_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,
self.dict_dang_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
10. Apéndices
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.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_dang_dev(check_add_dev_cons):
"""
97/117
10. Apéndices
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,
self.dict_dang_devs)
self.assertEqual(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
10. Apéndices
' 2013-01-01 02:0:00']},
msg=None)
print
class check_add_ap(unittest.TestCase):
"""
Comprobar que se añada un nuevo AP correctamente
"""
# Textfiture (Preparar el contexto)
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
10. Apéndices
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 = {}
self.dict_dang_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
10. Apéndices
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)
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)
101/117
10. Apéndices
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)
self.assertEqual(self.dict_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
10. Apéndices
'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()
"""
# Textfiture (Preparar el contexto)
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_dang_devs = {}
self.dict_aps = {}
self.dict_dang_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
10. Apéndices
#dict_devs
self.assertEqual(self.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
10. Apéndices
' 2013-01-03
00:00:00',
'04:00:00:00:00:00
(AP4) -' + \
' 2013-01-04
00:00:00']},
msg=None)
#dict_aps
self.assertEqual(self.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
10. Apéndices
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()
10.3.3.2 Resultados
$ 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
10. Apéndices
[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 Notas
Por simplicidad se ha suprimido la ruta original al fichero de registro utilizado para
las pruebas.
107/117
10. Apéndices
10.4 Manual de usuario
10.4.1 Dependencias
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 Utilizando el sistema
10.4.2.1 Modo 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
10. Apéndices
Ilustración 4: Ejemplo utilizando wlan0 como interfaz de red
La aplicación se podrá detener en cualquier momento utilizando la combinación de
teclas CTRL+C.
10.4.2.2 Interfaz gráfica
Ilustración 5: Interfaz gráfica, ventana principal
Para iniciar la aplicación en modo gráfico habrá que ejecutar el archivo wific.py
como usuario administrador o root.
109/117
10. Apéndices
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. Apéndices
10.4.2.2.1 Aná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.
Ilustración 6: Ejemplo de 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
10. Apéndices
Esta ventana muestra los peligros encontrados del tipo escogido en la lista de
selección de elementos (6).
Punto de acceso peligroso
Ilustración 7: Ejemplo de 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
10. Apéndices
Dispositivo inalámbrico peligroso
Ilustración 8: Ejemplo de dispositivo 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
10. Apéndices
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).
Ilustración 9: Ejemplo de informe generado
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
10. Apéndices
10.4.2.2.2 Monitorizar 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.
Ilustración 10: Ejemplo de lista de WiFis
para monitorizar
Una vez seleccionada la WiFi a monitorizar, el sistema mostrará los dispositivos que
la red tiene asociados.
115/117
10. Apéndices
Ilustración 11: Ejemplo de dispositivos asociados a una red WiFi
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
10. Apéndices
10.5 Notas 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