estudios de ingenierÍa de ... -...

ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN

PROYECTO DE FIN DE CARRERA

DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA PARA LA DETECCIÓN DE

REDES FAST-FLUX

CURSO: 2009/2010

JOSÉ LUIS GALINDO ZAVALA

ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN

DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA PARA LA DETECCIÓN DE REDES FAST-FLUX

REALIZADO POR: José Luis Galindo Zavala

DIRIGIDO POR: Gabriel Maciá Fernández

DEPARTAMENTO: Teoría de la Señal, Telemática y Comunicaciones

Granada, Junio de 2010

DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA PARA LA DETECCIÓN DE REDES FAST-FLUX

José Luis Galindo Zavala

Palabras clave: seguridad de redes, software, redes de servicio de flujo rápido, dominios de Internet, cibercrimen, sistema de nombres de dominio

Resumen:

En los últimos años, la creciente popularidad y accesibilidad a Internet ha provocado un cambio dramático en la forma de comunicación de nuestra sociedad. La gran variedad de servicios que ofrece Internet, tales como páginas web, correo electrónico, telefonía IP, “chat” o comercio electrónico han supuesto una revolución en el paradigma de las comunicaciones y actualmente Internet continúa su desarrollo a una velocidad vertiginosa.

Sin embargo, para preservar este ritmo de crecimiento, existe un aspecto básico

que no se debe ignorar: la seguridad. Esto es debido a que en Internet han surgido comunidades de usuarios malintencionados que utilizan Internet como plataforma para desarrollar actividades criminales, consiguiendo un alcance global. Estos usuarios son comúnmente conocidos como “hackers”.

Los expertos en seguridad persiguen constantemente los delitos perpetrados en

Internet. Es por ello que los delincuentes se han visto obligados a idear nuevas técnicas, cada día más sofisticadas, que garanticen la continuidad del ejercicio de estas actividades y su anonimato. Una de estas técnicas más recientes es el uso de las llamadas “redes de servicios de flujo rápido” (Fast‐Flux Service Networks, FFSNs). Las FFSNs contribuyen a dificultar considerablemente la detención del delincuente que hace uso de ellas.

En este proyecto se ha diseñado e implementado una plataforma software

destinada a comprobar si un dominio de Internet se corresponde o no con una FFSN. Se trata de una plataforma abierta cuyo propósito es proveer al usuario de un soporte que le permita integrar sus propias herramientas de detección de una forma sencilla. De esta forma, el esquema utilizado puede ser adaptado a los posibles giros inesperados que puedan producirse en la evolución de las FFSNs.

La plataforma ofrece al usuario la capacidad de experimentar con nuevos algoritmos de detección, teniendo que preocuparse exclusivamente del diseño e implementación del algoritmo deseado. Además, ofrece la posibilidad de recopilar automáticamente los nombres de dominio contenidos en diversos formatos, como páginas web, correos electrónicos, etc., que son fuentes principales de direcciones de Internet con contenido malicioso.

Teniendo en cuenta que la recogida de datos necesarios para llevar a cabo la

detección puede durar horas e incluso días, la plataforma diseñada permite la operación sobre varios dominios simultáneamente, aumentando considerablemente su eficiencia en términos de número de dominios analizados por unidad de tiempo.

DESIGN AND IMPLEMENTATION OF A PLATFORM FOR DETECTING FAST-FLUX SERVICE NETWORKS

José Luis Galindo Zavala

Keywords: network security, software, Fast‐Flux Service Networks, Internet domains, cybercrime, Domain Name System

Abstract:

Over the last few years, the increasing popularity and accessibility to the Internet has resulted in a dramatic change in our society’s way of communication. The wide range of services offered by the Internet, such as web pages, e‐mail, VoIP, chat or e‐commerce, have unleashed a revolution in the communications paradigm and the Internet continues evolving at a very high speed.

Nevertheless, in order to maintain this speed of growth, there is an essential

issue which should not ever be ignored: security; mainly due to the emergence of malicious user communities whose members use the Internet as a platform for developing criminal activities with a global impact. These users are commonly known as “hackers”.

Security experts are constantly pursuing computer crime activities perpetrated

in the Internet. This is why hackers have developed new sophisticated techniques to guarantee the survival of these criminal activities and their anonymity. One of the most modern techniques is the used in this context are the “Fast Flux Service Networks” (FFSNs). FFSNs make more difficult to arrest criminals who use them.

In this project, a software platform able to check if an Internet domain belongs

to a FFSN has been designed and implemented. It is an open platform whose purpose is to provide users with a support which lets them integrate their own detection strategies into it in a very simple way, so the system can be adapted to unexpected changes which can come into reality along the FFSN evolution.

The platform offers the users the ability to test new detection algorithms

without worrying about anything but the design and the implementation of the desired algorithm. In addition, it makes it possible to automatically obtain the domain names to be analyzed from emails or web pages, which are the main sources of Internet addresses with malicious contents.

Considering that the collection of the amount of data needed to detect a domain name can take some hours or even days, the designed platform is able to operate on several domain names simultaneously, considerably raising its efficiency in terms of the number of domains analyzed per time unit.

D. Gabriel Maciá Fernández, Profesor del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Escuela Técnica Superior de Ingenierías de Informática y de Telecomunicación de la Universidad de Granada, como director del Proyecto Fin de Carrera de D. José Luis Galindo Zavala

Informa: que el presente trabajo, titulado: “Diseño e implementación de una plataforma para la detección de redes fast‐flux” ha sido realizado y rectado por el mencionado alumno bajo mi dirección, y con esta fecha autorizo a su presentación.

Granada, a 28 de Junio de 2010

Fdo. Gabriel Maciá Fernández

Los abajo firmantes autorizan a que la presente copia de Proyecto Fin de Carrera se ubique en la Biblioteca del Centro y/o departamento para ser libremente consultada por las personas que lo deseen.

Granada, a 28 de Junio de 2010

Fdo. José Luis Galindo Zavala Fdo. Gabriel Maciá Fernández 25340663E

A mis padres y mis hermanos, por su cariño y apoyo incondicionales.

A Cristina, mi novia, por sus palabras de ánimo en los momentos duros y por hacer suyas mis alegrías y mis preocupaciones.

A Antonio, mi hermano, por haber estado siempre a mi lado en los momentos importantes.

A Gabriel, mi tutor, por su constante atención y su gran capacidad para motivar a sus alumnos.

A mis amigos, por su apoyo y por todas las risas y momentos buenos que hemos compartido.

ÍNDICE DE CONTENIDOS

CAPÍTULO 1. INTRODUCCIÓN 13

1.1 FUNDAMENTOS TEÓRICOS 13 1.1.1 El sistema DNS 13 1.1.2 Redes fast‐flux 17 1.1.3 Comentarios finales 29

1.2 OBJETIVOS DEL PROYECTO 29

CAPÍTULO 2. ESTADO DEL ARTE DE LA DETECCIÓN DE REDES FAST‐FLUX 31

2.1 INTRODUCCIÓN 31 2.2 TÉCNICAS DE DETECCIÓN 32

2.2.1 Fórmula de Mannheim 32 2.2.2 Método de Nazario y Holz 35 2.2.3 Método de Melbourne 35

CAPÍTULO 3. ESPECIFICACIÓN Y ANÁLISIS DE REQUISITOS 45

3.1 DEFINICIÓN DE REQUISITOS 45 3.1.1 Requisitos funcionales 45 3.1.2 Requisitos no funcionales 46

3.2 ANÁLISIS 48 3.2.1 Casos de uso 48 3.2.2 Diagramas de secuencia del sistema 53

CAPÍTULO 4. PLANIFICACIÓN Y COSTES 59

4.1 PLANIFICACIÓN 59 4.2 ESTIMACIÓN DE COSTES 61

CAPÍTULO 5. DISEÑO 65

5.1 BOCETOS INTERFAZ GRÁFICA 65 5.2 CASOS DE USO REALES 67

5.2.1 Introducir parámetros 68 5.2.2 Obtener características 68 5.2.3 Detectar 70 5.2.4 Generar informe 71 5.2.5 Otros casos de uso 72

5.3 ARQUITECTURA PROPUESTA 72 5.3.1 Componentes del sistema 72 5.3.2 Diseño de los bloques monitores 78 5.3.3 Estructura de la base de datos 80 5.3.4 Diagrama de clases de diseño 80 5.3.5 Interacciones 94

CAPÍTULO 6. IMPLEMENTACIÓN 101

6.1 ESTRUCTURA DEL CÓDIGO 101 6.1.1 Paquete Detectores 103 6.1.2 Paquete Monitores 104 6.1.3 Paquete DNS 106 6.1.4 Otros Módulos 107

6.2 ARCHIVO DE CONFIGURACIÓN 109 6.3 INTERFAZ GRÁFICA 110 6.4 HERRAMIENTAS EXTERNAS USADAS EN LA IMPLEMENTACIÓN 114

6.4.1 Eclipse 114 6.4.2 Paquete PyDNS 114 6.4.3 Paquete wxPython 115 6.4.4 Módulo KThread.py 115 6.4.5 Librería SQLite3 115 6.4.6 Servidores Team‐Cymru 115

CAPÍTULO 7. EVALUACIÓN 117

7.1 PRUEBAS DE FUNCIONALIDAD 117 7.1.1 Pruebas de extracción de nombres de dominio 117 7.1.2 Pruebas de comportamiento durante el análisis 119 7.1.3 Pruebas de base de datos 121 7.1.4 Pruebas de opciones de configuración 123 7.1.5 Pruebas de integración de módulos 125

7.2 PRUEBAS DE DETECCIÓN 128

CAPÍTULO 8. CONCLUSIONES 131

8.1 RESULTADOS 131 8.2 TRABAJO FUTURO 132

ANEXO I. DIRECTRICES PARA LA IMPLEMENTACIÓN DE NUEVOS MÓDULOS. 135

DISEÑO E IMPLEMENTACIÓN DE MÓDULOS MONITORES 135 DISEÑO E IMPLEMENTACIÓN DE MÓDULOS DETECTORES 136

BIBLIOGRAFÍA 138

GLOSARIO 140

13

CAPÍTULO 1. Introducción

En este capítulo se presentan los conceptos teóricos necesarios para la comprensión de

este proyecto en su totalidad. La intención es que el lector adquiera un conocimiento en profundidad sobre la naturaleza de estas redes, sin el cual no es posible desarrollar metodologías para su detección y erradicación. También se presentan los objetivos del proyecto, en los que se expone qué se pretende construir y por qué.

1.1 Fundamentos teóricos Las redes fast‐flux utilizan técnicas y arquitecturas basadas en la utilización caprichosa

del sistema DNS. Es por esto que es preciso comprender los conceptos básicos de funcionamiento de dicho sistema para profundizar en la arquitectura de las FFSNs. A continuación, se realizará una explicación de los conceptos del sistema DNS que se utilizan en la implementación de las redes FFSN, pasando a continuación a explicar las mismas de forma detallada.

1.1.1 El sistema DNS Como ya se ha comentado, el sistema DNS es clave para el éxito de las FFSNs. Las FFSNs

aprovechan ciertas funcionalidades ofrecidas por este servicio para adquirir robustez, en el sentido de que se hacen muy difíciles de mitigar y de que aseguran que su servicio esté continuamente disponible.

1.1.1.1 ¿Qué es el sistema DNS? El direccionamiento en Internet se basa en el uso de direcciones IP. Sin embargo, para

un usuario, manejar este tipo de direcciones puede ser muy complejo. El sistema de

Diseño e implementación de una plataforma para la detección de redes fast‐flux

14 Introducción

nombres de dominio o sistema DNS es un servicio de Internet cuyo objetivo básico es la traducción de nombres textuales más amigables para los usuarios de Internet a direcciones IP. Estos nombres textuales se denominan nombres de dominio.

El sistema DNS tiene otros propósitos adicionales, como dar soporte a diferentes

servicios en la red (por ejemplo, el correo electrónico), crear subdelegaciones de nombres o llevar a cabo resoluciones inversas, es decir, traducir una dirección IP al nombre textual asociado.

1.1.1.2 Estructura de los nombres de dominio El sistema DNS está constituido por una base de datos distribuida con una estructura

jerárquica en forma de árbol. Una zona es una porción del espacio de nombres DNS sobre la cual ha sido delegada la

responsabilidad administrativa de los dominios que contiene. Cada zona está administrada por una autoridad, que consta de uno o varios servidores de nombres que contienen los datos administrativos de los equipos bajo su responsabilidad. Cada zona puede, además, delegar la responsabilidad en otras subzonas de la misma manera, dando lugar a una estructura jerárquica perfectamente definida.

Como se puede apreciar en la Figura 1.1, los dominios de alto nivel (Top Level Domains,

TLDs) son dominios en el nivel más alto de la jerarquía DNS. Los nombres de los TLD están instalados en la zona raíz del espacio de nombres. Teniendo en cuenta la enorme cantidad de nombres de dominio que existen, la gestión por parte de un TLD de todos los dominios que dependen de él puede llegar a ser muy complicada. Por ello, se definen las zonas.

Figura 1.1

1.1 Fundamentos teóricos

Introducción 15

Un nombre de dominio (Fully Qualified Domain Name, FQDN) es el nombre textual que incluye el nombre del equipo que contiene un recurso específico y la ubicación exacta en el árbol DNS.

La estructura de un nombre de dominio es de la forma

parte_local.dominio_niveln…dominio_nivel2.dominio_nivel1. El orden natural de las direcciones es por tanto de derecha a izquierda, estando la raíz del árbol presente de forma implícita en todas las direcciones. No existe una restricción en cuanto al número de niveles de la dirección.

Ejemplo:

equipo15.r.detectorfastflux.es.

. (final) Raíz del sistema DNS es Dominio de alto nivel (TLD) detectorfastflux Dominio de nivel 2 r Dominio de nivel 3 equipo15 Nombre del equipo No hay que olvidar que el objetivo del sistema DNS es facilitar al usuario el

direccionamiento en Internet. Por tanto, no tendría sentido que el usuario tuviese que recordar siempre un FQDN para acceder a un recurso puesto que estos nombres pueden llegar a ser muy largos. Es por eso que se asignan alias a los dominios, que son nombres más cortos asociados al FQDN. El usuario puede acceder al recurso utilizando este nombre. El servidor de nombres será el encargado de identificar este alias con su FQDN correspondiente.

Es muy importante distinguir entre lo que es un nombre de dominio y lo que es un

localizador uniforme de recursos (Uniform Resource Locator, URL). Una URL es una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos en Internet para su localización o identificación, como por ejemplo documentos textuales, imágenes, videos, presentaciones digitales, etc. El nombre de dominio al que pertenece el

recurso está contenido en el recurso. Por ejemplo, http://maquina.dominio.es/ directorio1/directorio2/recurso es la URL del recurso “recurso” que está contenido en la ruta “/directorio1/directorio2” de la máquina “maquina”, que se encuentra en el dominio cuyo nombre es “dominio.es”.

1.1.1.3 Registros DNS Cada subzona, para la gestión de los equipos bajo su control, almacena la información

correspondiente en un servidor. Esta información está estructurada en forma de registros (Resource Records, RR), que pueden ser de distintos tipos. A continuación se mencionan los más importantes:


16 Introducción

Tipo A: Contiene la dirección IP a la que apunta el nombre de dominio. Tipo NS: Apunta a un servidor de nombres autorizado para un dominio. Contiene el

nombre de dominio de dicho servidor. Este tipo de registro es el que permite la delegación de responsabilidades en zonas.

Tipo CNAME: Se refiere al nombre canónico (Fully Qualified Domain Name, FQDN) de un alias.

Tipo SOA: Contiene la información de cuál o cuáles son los servidores DNS responsables de la zona.

Tipo PTR: Contiene la traducción de dirección IP a nombre de dominio asociado. Tipo MX: Contiene la información referente al servidor de correo electrónico de la

zona.

Cada registro de los mencionados contiene un campo de “tiempo de vida” (Time‐to‐Live, TTL). Todo servidor DNS dispone de una memoria caché. Cuando un servidor de nombres solicita un registro sobre un dominio específico a un servidor autoridad, el primero mantendrá el registro recibido en su caché durante el tiempo especificado en el campo TTL (en segundos). Si durante ese tiempo un cliente solicita esta información, el servidor receptor de la solicitud responderá al cliente con este registro sin tener que volver a pedir la información al servidor autoridad. Esto reduce la carga en la red y la posibilidad de sobrecarga en el servidor autoridad.

Los registros son enviados sobre el protocolo TCP/IP. Cada mensaje DNS consta de una

cabecera y de un cuerpo, conteniendo este último los registros. De la cabecera conviene destacar que contiene una serie de indicadores (flags) que proporcionan información sobre el contenido del mensaje. Entre estos indicadores se encuentra el de “código de respuesta” (reply code), que indica si existe algún error en la respuesta ofrecida por el servidor. Los valores posibles para este indicador son los siguientes:

“No error” (0): El mensaje es correcto. “Format error” (1): El servidor de nombres no pudo interpretar el mensaje de petición. “Server failure” (2): El servidor de nombres no pudo procesar la solicitud debido a un

problema con el servidor de nombres. “Name error” (3): Tiene sentido solamente cuando la respuesta proviene de un

servidor de nombres autoridad del dominio. Este código significa que el dominio referenciado en la solicitud no existe.

“Not Implemented” (4): El servidor de nombres no da soporte a este tipo de solicitud. “Refused” (5): El servidor de nombres rechaza la operación por razones de seguridad.

1.1.1.4 RoundRobin DNS La técnica Round Robin DNS (RRDNS) es empleada por el sistema DNS para propósitos

de balanceo de carga y de tolerancia a fallos. Esta técnica consiste en devolver más de un registro de tipo A cuando un cliente realiza una consulta sobre un nombre de dominio. El servidor permuta el orden de estos registros en cada consulta, provocando así que las


Introducción 17

peticiones se repartan entre los distintos equipos disponibles de una forma equitativa y evitando la sobrecarga en algunos servidores.

La técnica RRDNS se basa en la asignación de TTLs cortos a los registros de tipo A, para

así provocar que los servidores que no son autoridad del dominio se vean obligados a solicitar a la autoridad del mismo los nuevos datos y de esta forma tener mayor control sobre el reparto de carga entre los distintos equipos a los que apunta el nombre de dominio.

1.1.2 Redes fastflux En este apartado se describen en profundidad los conceptos más importantes

relacionados con las redes de servicio de flujo rápido (FFSNs). Su lectura permitirá comprender qué son, para qué se utilizan, las características principales que poseen, los tipos conocidos de redes fast‐flux y las ventajas que aportan a sus usuarios. Finalmente, se aportarán algunos ejemplos clarificadores de este tipo de redes.

1.1.2.1 ¿Qué es una red fastflux? Una red fast‐flux (FFSN) es una red de sistemas informáticos comprometidos (botnet)

cuyas direcciones IP se van turnando en los registros DNS correspondientes a uno o varios dominios utilizados para cometer delitos.

Lo que caracteriza a estas redes es que el conjunto de direcciones IP involucradas no

son el destino final de la petición del contenido (o de cualquier otro servicio). En lugar de eso, los sistemas comprometidos son utilizados como meros redirectores que canalizan peticiones y datos hacia y desde otros servidores (redirección ciega), que son los que sirven el contenido. La redirección hace inútiles los intentos de mitigar los nodos de la FFSN.

Debido a esto, para un FQDN pueden existir cientos o incluso miles de direcciones IP

asignadas que son anunciadas en los servidores DNS rotando rápidamente con un esquema de cola round‐robin. Para que la rotación sea rápida, se asigna un TTL muy bajo a los registros asociados. De esta forma, cada vez que algún explorador se conecta a un sitio web fraudulento y protegido por una red fast‐flux, realmente se comunica con uno de los múltiples ordenadores de la botnet.

Esta arquitectura de continuo cambio hace mucho más difícil la persecución de las

actividades criminales y la desactivación de sus servicios. Además, los atacantes se aseguran de que los sistemas comprometidos tengan el mayor ancho de banda posible y la mayor disponibilidad. Normalmente usan un esquema de distribución de carga. El atacante realiza comprobaciones periódicas, sacando del flujo de direcciones aquellas que no respondan y así la disponibilidad del contenido se mantiene.

Esencialmente, los nombres de dominio y URLs del contenido anunciado ya no están

asociados a un servidor específico, sino que se asocian a muchos nodos que van turnándose,


18 Introducción

que después reenvían el contenido a otro grupo de servidores. Aunque esta técnica ha sido usada alguna vez para operaciones legítimas de servidores web, en este caso es una evidencia de la evolución tecnológica de las redes criminales.

Los servidores principales de la FFSN son el elemento controlador que hay detrás de

estas redes. Es el nodo principal, el cual está escondido tras los nodos infectados, el que envía de vuelta el contenido a la víctima que lo solicitó. La combinación de este hecho con la rápida modificación de las direcciones IP asociadas al dominio provoca que localizar el servidor principal sea prácticamente imposible y éstos operen con éxito durante largos períodos de tiempo. La estructura de una red FFSN se presenta en la Figura 1.2.

1.1.2.2 Aplicaciones Como ya se ha comentado anteriormente, el principal objetivo de las FFSNs es

proporcionar al criminal una forma de ocultación para poder desarrollar su actividad criminal sin ser descubierto.

Existen muchos tipos de estafas en Internet que utilizan redes de tipo fast‐flux para su

ocultación. A continuación se describen algunas de ellas:

- Phishing: El atacante pone en compromiso uno o más sistemas informáticos y establece un sitio web falso o fraudulento. El contenido es anunciado a las víctimas vía email masivo o de forma más dirigida, normalmente a través de otros sistemas comprometidos y botnets. Los sistemas que alojan el contenido malicioso se identifican por su nombre DNS o por su dirección IP incluida en los emails. Este tipo de timo puede dar lugar, por ejemplo, a que la víctima facilite sus datos personales pensando que la página web mostrada es de un sitio web legal.

Figura 1.2


Introducción 19

- Distribución de malware: La palabra “malware” es la abreviatura del término inglés malicious software. Estos programas son muy peligrosos para los sistemas informáticos, puesto que pueden insertar gusanos, spyware o virus en un equipo, intentando alcanzar algún objetivo, como por ejemplo, recoger información sobre el usuario de Internet u obtener información del propio PC del usuario.

- Envío de correo no solicitado (Spam): Se llama spam o correo basura a los mensajes

de correo electrónico no solicitados, no deseados o de remitente desconocido, habitualmente de tipo publicitario, enviados en grandes cantidades (incluso masivas) que perjudican de alguna o varias maneras al receptor. El spam supone actualmente la mayor parte de los mensajes electrónicos intercambiados en Internet, siendo utilizado para anunciar productos y servicios de dudosa calidad. Usualmente, los mensajes indican como remitente del correo una dirección falsa.

- Ataques de denegación de servicio distribuidos (DDoS): Se produce un ataque de

denegación de servicio cuando un recurso o servicio de la red es monopolizado intencionadamente para evitar que otros usuarios puedan acceder a él. Esta definición incluye también los intentos de colapsar el servicio o recurso para denegar el acceso a cualquier usuario. Un ataque de denegación de servicio distribuido (DDoS) puede definirse como un ataque de denegación de servicio con diversos orígenes distribuidos a través de Internet y enfocados al mismo objetivo. El número de fuentes puede ser ilimitado y la distribución de éstas puede ser global. Cualquier equipo conectado a Internet puede ser víctima de un ataque.

1.1.2.3 Tipología de las redes fastflux Existen fundamentalmente dos tipos conocidos de redes fast‐flux: redes de flujo simple

y redes de flujo doble.

Redes de flujo simple En los gráficos de la Figura 1.3 se ilustra el proceso de solicitud por parte de un cliente

de una página web. En la primera situación, en la que se representa el proceso en el caso de una red no fast‐flux, el cliente envía la petición a una de las direcciones IP anunciadas en los

registros del servidor de nombres de la página web www.ejemplo.com. El servidor en cuestión responde al cliente enviándole el contenido de la página web.

En la segunda situación se representa el mismo proceso en el caso de una red fast‐flux.

Al igual que en el esquema anterior, el cliente envía la petición para obtener la página web de flujo.ejemplo.com a una de las IPs anunciadas, pero el host receptor de la petición no responde con la información, sino que reenvía la petición al nodo principal. Es el nodo principal el que responde con el contenido al host y éste la reenvía al cliente. A este host se le denomina “agente flux”.


20 Introducción

Figura 1.3 Los agentes flux son frecuentemente equipos domésticos que han sido infectados con

algún tipo de malware, de forma que cada petición HTTP que reciben es reenviada al nodo especificado en el código malicioso. Las FFSNs de flujo simple cambian los registros DNS de la dirección IP de su nodo agente cada pocos minutos, con lo que cualquier intento de derrotar al nodo intermedio con el objetivo de evitar que se sirva el contenido es inútil, puesto que otro host lo sustituirá inmediatamente y el contenido seguirá siendo servido.

Redes de flujo doble La FFSN de flujo doble es una técnica más compleja que proporciona una capa adicional

de redundancia. Concretamente, tanto los conjuntos de registros DNS tipo A como los de tipo NS de un dominio malicioso experimentan un cambio continuo tipo round‐robin y son anunciados en la FFSN.

La Figura 1.4 muestra la diferencia entre una FFSN de flujo simple y una de flujo doble.

El cliente desea resolver el dominio http://flujo.ejemplo.com. En el caso de la red de flujo simple, el cliente (o más frecuentemente, el servidor de nombres preferido por él) envía una solicitud al servidor de nombres raíz para descubrir qué servidor de nombres es

responsable del TLD .com y recibe una respuesta (omitida en el gráfico). El servidor de nombres indicado no conoce la dirección a la que debe conectar, pero sí cuál es el servidor de nombres encargado de los hosts en el dominio ejemplo.com. Es por ello que el cliente envía un segundo mensaje al servidor indicado, solicitando esta información. El cliente recibe una respuesta. En un tercer paso, el cliente envía una petición al servidor al que hace referencia la última de las respuestas para conocer las posibles direcciones IP a las que


Introducción 21

conectar para obtener el contenido. Este servidor sí tiene los registros de tipo A correspondientes al dominio flujo.ejemplo.com y las da a conocer al cliente, permitiéndole así establecer una conexión directa con una de estas IP. Para una consulta DNS normal, las direcciones IP de respuesta suelen mantenerse constantes a lo largo de un cierto período de tiempo, mientras que para nodos de flujo simple, la respuesta cambia frecuentemente.

En el caso de la red de flujo doble, el proceso comienza de la misma manera: el cliente o

su servidor de nombres preferido envía al servidor raíz una solicitud para conocer qué servidor de nombres se encarga del TLD .com y recibe una respuesta (omitida en el gráfico). El cliente solicita al servidor indicado en la respuesta la identidad del servidor de nombres

responsable del dominio ejemplo.com y recibe dicha información. En el siguiente paso se hace notable la diferencia con el caso de la red de flujo simple: el servidor de nombres indicado es parte de la propia red fast‐flux, lo cual quiere decir que su dirección IP también cambia de forma constante. Cuando el host que hace de servidor autoridad recibe la petición, la reenvía al nodo principal y éste responde con la IP de uno de los agentes flux que está bajo su control. El cliente entonces iniciará comunicación directa con el sistema objetivo, que será un agente que cambia dinámicamente. Esto provoca que la red fast‐flux sea mucho más dinámica y más difícil de vencer, puesto que tampoco se puede adquirir control sobre el servidor autoridad para impedir las operaciones realizadas en el dominio.

Figura 1.4


22 Introducción

1.1.2.4 Características Las FFSNs poseen unas características especiales que las diferencian del resto de redes.

A continuación se describen las características principales de las FFSNs:

Según las propiedades del nombre de dominio

• Edad del dominio Los dominios pertenecientes a redes fast‐flux tienen una edad bastante corta. Esto se

debe a que ante la evidencia de que un dominio pertenece a una red con esquema fast‐flux, la autoridad del dominio invalida el FQDN inmediatamente, ante lo que los delincuentes reaccionan registrando un nuevo dominio para continuar con su actividad. Este hecho provoca que la edad media de los dominios fast‐flux sea mucho menor que la de los dominios benignos.

• Registrador del dominio Suele ocurrir que los nombres de dominio que pertenecen a redes fast‐flux son

registrados dentro de un conjunto limitado de registradores, que con frecuencia están situados en países con pocas restricciones en cuanto a este tema. De esta manera, los delincuentes pueden registrar dominios utilizando tarjetas de crédito falsas sin sufrir las consecuencias de una comprobación de la legitimidad del dominio. Esto imposibilita cualquier intento de encontrar a los responsables reales de este tipo de actividades. Por otra parte, los dominios benignos presentan un conjunto mucho más heterogéneo de registradores, que además no suelen coincidir con aquellos utilizados por las redes fast‐flux.

Según el grado de disponibilidad de la red

• Número de registros tipo A Como se ha mencionado anteriormente, las redes fast‐flux tienen bajo su control una

gran cantidad de agentes flux. Ante una petición, el servidor de nombres autoridad del dominio malicioso devuelve el conjunto de agentes activos, en concreto, los registros de tipo A, cada uno conteniendo la IP de un agente específico. Estos registros son periódicamente actualizados por el nodo principal de la red, para introducir en la red nuevos agentes comprometidos y eliminar los defectuosos. Por tanto, tras cierto período de tiempo, el número de registros DNS de tipo A que se han asociado con un FQDN malicioso es alto. A mayor número de registros de tipo A asociados al mismo FQDN, mayor es el número de agentes potenciales y mayor la probabilidad de que el FQDN pertenezca a una red fast‐flux.


Introducción 23

• TTL de registros DNS Uno de los principales signos de identidad de una red fast flux es la alta frecuencia de

actualización del conjunto de agentes flux activos. El hecho de que los equipos front‐end de la red varíen de forma continua su estado de activo a no activo y viceversa obliga al nodo principal a actualizar el conjunto con la misma continuidad para garantizar la disponibilidad del servicio. Además, debe propagar rápidamente esta información a través de Internet para que sea accesible a las víctimas.

Por ello, para evitar que la información permanezca mucho tiempo en caché,

impidiendo que los servidores DNS tengan la necesidad de pedir la información sobre el nuevo conjunto de activos a la autoridad, se asignan valores pequeños a los campos TTL de los registros DNS. De esta manera se consigue rápidamente poner en conocimiento de los servidores de nombres de las víctimas el conjunto actualizado y se mantiene la disponibilidad del servicio. En resumen, cuanto mayores son los TTLs de los registros DNS para un FQDN, menor es la probabilidad de que se trate de una red fast‐flux. Desgraciadamente, un TTL muy bajo no siempre es signo claro de que sí pertenezca a una red fast‐flux. Algunos servidores de nombres autoridad de dominios benignos asocian un TTL muy corto a sus registros para distintos propósitos.

Según la heterogeneidad de los agentes

• Número de redes distintas Los agentes flux son normalmente equipos comprometidos dispersos por todo el

mundo. Por tanto, es muy probable que la resolución de un FQDN malicioso resulte en una gran cantidad de direcciones IP que corresponden a equipos situados en muchas redes diferentes. Por otra parte, cuando un FQDN benigno implica un alto número de direcciones IP con el propósito de balancear la carga de sus servidores, estos equipos usualmente pertenecen a la misma red puesto que pertenecen a la misma compañía y físicamente están situados muy cerca unos de otros. Con lo cual, cuanto mayor es el número de redes distintas asociadas al mismo FQDN, mayor dispersión existe en la ubicación de los equipos que reciben las peticiones y mayor la probabilidad de que se trate de una red fast‐flux.

• Número de sistemas autónomos distintos Un sistema autónomo (AS) es un grupo de uno o más prefijos IP gestionados por uno o

más operadores de red con una política de enrutamiento común y claramente definida. Cada red en Internet es un sistema autónomo, identificado por un número único en el mundo (ASN).

Distintas redes que se encuentren físicamente cercanas podrían conectar a internet a

través del mismo AS. Atendiendo a esta característica, se puede decir que como la mayoría de los FQDN benignos están mapeados en equipos físicamente próximos, éstos pertenecen


24 Introducción

al mismo sistema autónomo. Sin embargo, como los agentes de una red fast flux están repartidos por muchos países, pertenecen típicamente a sistemas autónomos diferentes. Con lo cual se puede decir que cuanto mayor sea el número de ASNs de los hosts asociados a un dominio, mayor es la probabilidad de que se trate de una red fast‐flux.

• Número de FQDNs resueltos distintos Incluso si un FQDN está asociado a múltiples sistemas dispersos alrededor del mundo y

éstos a su vez son parte de distintas redes y sistemas autónomos, los equipos podrían pertenecer a la misma compañía u organización y por tanto puede que compartan el mismo FQDN. El hecho de que todas las IPs asociadas a un dominio tengan el mismo FQDN es signo de que no se trata de una red fast‐flux. Esto se debe a que los agentes fast‐flux son hosts que pertenecen a distintas organizaciones, y los nombres canónicos asociados a sus direcciones IP están exclusivamente bajo el control de los respectivos propietarios de estas redes. El atacante no puede controlar esta información de ninguna forma.

• Número de nombres de red asignados distintos El nombre de red es un nombre asignado a la red por la autoridad de registro. Múltiples

direcciones de red pueden agruparse de forma lógica bajo el mismo nombre de red. Este caso se da normalmente cuando las distintas direcciones de red están en posesión de la misma compañía u organización. Al igual que en las tres características anteriores, el número de nombres de red distintos es un indicador del grado de dispersión de los equipos asociados con el FQDN sospechoso.

• Número de organizaciones distintas Cada red está asignada a una organización, pero al igual que en el caso de los nombres

de una red, la misma organización puede poseer múltiples redes con uno o múltiples

nombres de red. Como ejemplo, se considera el dominio avast.com analizado en la Tabla 1. Cada red tiene asignado un nombre de red distinto, pero dos de estas redes pertenecen a la misma organización (Soft Layer Technologies Inc.). Claramente, los agentes flux, al estar repartidos aleatoriamente alrededor del mundo, comparten un número limitado de organizaciones.

Nombre de dominio Dirección IP Organización

avast.com 67.228.0.0/16 SoftLayer Tech. avast.com 216.12.192.0/19 Everyone Internet avast.com 74.86.0.0/16 SoftLayer Tech.

Tabla 1

1.1.2.5 Ventajas para el atacante Claramente, las redes fast‐flux ofrecen importantes ventajas a los atacantes que llevan

a cabo estas actividades ilegales. A continuación se detallan algunas de ellas:


Introducción 25

- Simplicidad: Se necesita solamente un servidor suficientemente potente para servir el contenido principal y la información DNS. Las URLs publicadas apuntan a los hosts previamente infectados con los que actúa el usuario, redirigiendo éstos las peticiones al servidor principal, que es el que procesa las peticiones. Esto hace que la infraestructura de reparto del contenido sea mucho más simple de gestionar por parte de los criminales, ya que no es necesario mantener múltiples servidores, sino solamente uno.

- Protección: Los nodos que actúan como redirectores proxy son recursos criminales

desechables que pueden ofrecer una capa de protección ante cualquier investigación o acción legal. Cuando un profesional de seguridad trate de desactivar el sitio web malicioso, solamente será capaz de recuperar una fracción de las direcciones IP involucradas en el reparto del contenido, direcciones que además pueden encontrarse en distintos países, continentes o jurisdicciones, con distintas lenguas y en distintas zonas horarias. Esto complica de una manera extraordinaria cualquier investigación que se trate de llevar a cabo. Además, debido a la característica de redirección de peticiones, no se encontrarán evidencias en el equipo infectado de ninguna actividad criminal y el registrador de tráfico suele estar desactivado, con lo que el rango de pistas disponible es muy limitado.

- Permanencia en el tiempo: Las FFSN aumentan la vida media de operación de los

servidores principales que se esconden tras los agentes flux. Además debido a las múltiples capas de redirección, lleva mucho más tiempo la identificación de estos servidores, particularmente si estos nodos están alojados en territorios con leyes poco estrictas.

1.1.2.6 Ejemplos A continuación se van a exponer varios ejemplos reales extraidos de [1] sobre dominios

asociados a redes fast‐flux, mostrando y analizando los resultados obtenidos en las sucesivas consultas DNS realizadas.

Ejemplo de traceo y detección de una red de flujo simple El dominio que se va a analizar en este ejemplo es divewithsharks.hk. En la Tabla

2 se muestran los resultados devueltos por el servidor DNS tras una petición de datos sobre el dominio.

La respuesta del servidor incluye 5 registros tipo A para el mismo FQDN. El TTL asociado

a los mismos es 1800 segundos (30 minutos), que es un TTL relativamente bajo si se compara con los tiempos de vida mostrados por los registros de dominios benignos. Se puede apreciar también el amplio rango de direcciones IP en el que se mueve el conjunto. Esto indica que los hosts especificados posiblemente no estén localizados en un área geográfica concreta, sino que se encuentran dispersos en distintos terrenos. Se observa además que las direcciones IP pertenecen a hosts de redes dial‐up y de banda ancha, con lo que cabe pensar


26 Introducción

que éstos son equipos domésticos que han sido infectados para formar parte de la red fast‐flux.

La respuesta incluye también 2 registros tipo NS, en los que se especifican los nombres

de los servidores autoridad para el dominio, y 2 registros adicionales tipo A, que contienen datos sobre dichos servidores. Estos servidores vuelven a presentar una clara lejanía física entre ellos, atendiendo a la dirección IP que tienen asignada y a la red a la que pertenece cada uno, con lo que muy posiblemente sean hosts pertenecientes a la propia red fast‐flux. Cabe destacar el alto TTL asignado a los registros de tipo A de los servidores de nombres. Esto hace pensar que la red no es de flujo doble, sino simple.

divewithsharks.hk. 1800 IN A 70.68.187.xxx [xxx.vf.shawcable.net] divewithsharks.hk. 1800 IN A 76.209.81.xxx [SBIS-AS – AT&T Internet Services] divewithsharks.hk. 1800 IN A 85.207.74.xxx [adsl-ustilxxx-74-207-85.bluetone.cz] divewithsharks.hk. 1800 IN A 90.144.43.xxx [d90-144-43-xxx.cust.tele2.fr] divewithsharks.hk. 1800 IN A 142.165.41.xxx [142-165-41-xxx.msjw.hsdb.sasknet.sk.ca] divewithsharks.hk. 1800 IN NS ns1.world-wr.com. divewithsharks.hk. 1800 IN NS ns2.world-wr.com. ns1.world-wr.com. 87169 IN A 66.232.119.xxx [HVC-AS – HIVELOCITY VENTURES CORP] ns2.world-wr.com. 87177 IN A 209.88.199.XXX [vpdn-ds1209-88-199-xxx.alami.net]

Tabla 2 En la Tabla 3 se muestran de nuevo los resultados DNS de una petición realizada 30

minutos más tarde, momento en el que los registros anteriores han caducado. El servidor vuelve a responder con 5 registros de tipo A para el dominio bajo sospecha, pero esta vez dos de las direcciones han cambiado (marcadas en negrita) y vuelven a no asemejarse a las del resto del conjunto. Este es otro indicio de que se trata de una red fast‐flux, tal y como se ha mencionado en los apartados anteriores. Además, estas direcciones pertenecen de nuevo a redes dial‐up y de banda ancha.

Las redes de flujo simple parecen aplicar algún tipo de lógica en la decisión de cuáles de

sus direcciones IP disponibles serán anunciadas en el próximo conjunto de respuestas. Esta lógica podría basarse en la monitorización de la calidad de la conexión actual y quizás en algún algoritmo de balanceo de carga. Las nuevas direcciones IP de los agentes flux se insertan en la red fast‐flux para reemplazar a los nodos con bajo rendimiento.

divewithsharks.hk. 1800 IN A 24.85.102.xxx [xxx.vs.shawcable.net] divewithsharks.hk. 1800 IN A 69.47.177.xxx [d47-69-xxx-177.try.wideopenwest.com] divewithsharks.hk. 1800 IN A 70.68.187.xxx [xxx.vf.shawcable.net] divewithsharks.hk. 1800 IN A 90.144.43.xxx [d90-144-43-xxx.cust.tele2.fr] divewithsharks.hk. 1800 IN A 142.165.41.xxx [142-165-41-xxx.msjw.hsdb.sasknet.sk.ca] divewithsharks.hk. 1800 IN NS ns1.world-wr.com. divewithsharks.hk. 1800 IN NS ns2.world-wr.com. ns1.world-wr.com. 85248 IN A 66.232.119.xxx [HVC-AS – HIVELOCITY VENTURES CORP] ns2.world-wr.com. 82991 IN A 209.88.199.XXX [vpdn-ds1209-88-199-xxx.alami.net]

Tabla 3


Introducción 27

Se vuelve a realizar otra consulta sobre el dominio 30 minutos más tarde, obteniendo la información de la Tabla 4. Se observan ahora 4 nuevas direcciones IP y una dirección IP que apareció en la primera de las respuestas mostradas en la Tabla 2 (la segunda de la tabla). Este hecho pone de manifiesto el mecanismo round‐robin usado en las redes fast‐flux. Como se ha visto en el ejemplo, los registros A para el dominio están en continuo cambio. Cada uno de estos sistemas representa un host comprometido actuando como un redirector hacia el nodo principal. Los expertos no conocen el destino final del sitio web en cuestión a no ser que tengan acceso a uno de estos nodos redirectores, lo cual hace que éste sea un entorno mucho más dinámico y robusto para los criminales.

divewithsharks.hk. 1800 IN A 68.150.25.xxx [xxx.ed.shawcable.net] divewithsharks.hk. 1800 IN A 76.209.81.xxx [SBIS-AS – AT&T Internet Services] divewithsharks.hk. 1800 IN A 172.189.83.xxx [xxx.ipt.aol.com] divewithsharks.hk. 1800 IN A 200.115.195.xxx [pcxxx.telecentro.com.ar] divewithsharks.hk. 1800 IN A 213.85.179.xxx [CNT Autonomous System] divewithsharks.hk. 1800 IN NS ns1.world-wr.com. divewithsharks.hk. 1800 IN NS ns2.world-wr.com. ns1.world-wr.com. 83466 IN A 66.232.119.xxx [HVC-AS – HIVELOCITY VENTURES CORP] ns2.world-wr.com. 81189 IN A 209.88.199.XXX [vpdn-ds1209-88-199-xxx.alami.net]

Tabla 4

Ejemplo de traceo y detección de una red de flujo doble El dominio que se va a analizar en este ejemplo es login.mylspacee.com. Este

sitio falso se asemeja mucho en contenido al sitio web real MySpace, pero en lugar de serlo, busca las credenciales de autenticación de usuario de cualquiera que caiga en la trampa de ingresar en el sitio falso. Esta situación es el típico caso de phishing.

En la Tabla 5 se muestran los resultados devueltos por el servidor DNS tras una petición

de datos sobre el dominio.

login.mylspacee.com 177 IN A 66.299.133.xxx [c-66-229-133-xxx.hsd1.f1.comcast.net] login.mylspacee.com 177 IN A 67.10.117.xxx [cpe-67-10-177-xxx.gt.res.rr.com] login.mylspacee.com 177 IN A 70.244.2.xxx [adsl-70-244-2-xxx.dsl.hrlntx.swbell.net] login.mylspacee.com 177 IN A 74.67.113.xxx [cpe-74-67-113-xxx.stny.res.rr.com] login.mylspacee.com 177 IN A 74.137.49.xxx [74-137-49-xxx.stny.res.rr.com] mylspacee.com 108877 IN NS ns3.myheroisyourslove.hk mylspacee.com 108877 IN NS ns4.myheroisyourslove.hk mylspacee.com 108877 IN NS ns5.myheroisyourslove.hk mylspacee.com 108877 IN NS ns1.myheroisyourslove.hk mylspacee.com 108877 IN NS ns2.myheroisyourslove.hk ns1.myheroisyourslove.hk 854 IN A 70.227.218.xxx [ppp-70-227-218-xxx.dsl.sfldmi.ameritech.net] ns2.myheroisyourslove.hk 854 IN A 70.136.16.xxx [adsl-70-136-16-xxx.dsl.bumttx.sbcglobal.net] ns3.myheroisyourslove.hk 854 IN A 68.59.76.xxx [c-68-59-76-xxx.hsd1.al.comcast.net] ns4.myheroisyourslove.hk 854 IN A 70.126.19.xxx [xxx-19.126-70.tampabay.res.rr.com] ns5.myheroisyourslove.hk 854 IN A 70.121.157.xxx [xxx.157.121.70.cfl.res.rr.com]

Tabla 5


28 Introducción

El servidor ha devuelto un conjunto de 5 registros tipo A, indicando las direcciones IP a las que apunta el nombre de dominio en cuestión. Estos registros tienen un TTL muy bajo, distintos rangos IP y pertenecen a redes distintas, características principales de las redes fast‐flux.

En la respuesta también se incluyen 5 registros de tipo NS, que contienen los nombres

de los servidores autoridad para el dominio y un conjunto de 5 registros adicionales de tipo A indicando las direcciones IP de los servidores de nombres contenidos en los registros NS. Los tiempos de vida correspondientes a los registros NS son muy altos, ya que los nombres de estos servidores son estáticos; sin embargo, si se atiende a las direcciones IP asociadas a ellos, éstas poseen unos valores del campo TTL muy bajos, lo cual hace pensar que interesa que el registro caduque pronto para obtener un nuevo conjunto de direcciones en un tiempo mínimo.

Unos 4 minutos más tarde, se vuelve a solicitar información para el mismo dominio,

obteniendo los datos contenidos en la Tabla 6.

login.mylspacee.com 161 IN A 74.131.218.xxx [74-131-218-xxx.dhcp.insightbb.com] login.mylspacee.com 161 IN A 24.174.195.xxx [cpe-24-174-195-xxx.elp.res.rr.com] login.mylspacee.com 161 IN A 65.65.182.xxx [adsl-65-65-182-xxx.dsl-hstntx.swbell.net] login.mylspacee.com 161 IN A 69.215.174.xxx [ppp-69-215-174-xxx.dsl.ipltin.ameritech.net] login.mylspacee.com 161 IN A 71.135.180.xxx [adsl-71-135-180-xxx.dsl.pltn13.pacbell.net] mylspacee.com 108642 IN NS ns3.myheroisyourslove.hk mylspacee.com 108642 IN NS ns4.myheroisyourslove.hk mylspacee.com 108642 IN NS ns5.myheroisyourslove.hk mylspacee.com 108642 IN NS ns1.myheroisyourslove.hk mylspacee.com 108642 IN NS ns2.myheroisyourslove.hk ns1.myheroisyourslove.hk 608 IN A 70.227.218.xxx [ppp-70-227-218-xxx.dsl.sfldmi.ameritech.net] ns2.myheroisyourslove.hk 608 IN A 70.136.16.xxx [adsl-70-136-16-xxx.dsl.bumttx.sbcglobal.net] ns3.myheroisyourslove.hk 608 IN A 68.59.76.xxx [c-68-59-76-xxx.hsd1.al.comcast.net] ns4.myheroisyourslove.hk 608 IN A 70.126.19.xxx [xxx-19.126-70.tampabay.res.rr.com] ns5.myheroisyourslove.hk 608 IN A 70.121.157.xxx [xxx.157.121.70.cfl.res.rr.com]

Tabla 6 Todas las direcciones IP asociadas al dominio han cambiado, volviendo a presentar de

nuevo TTLs muy bajos, distintos rangos de direcciones y redes asociadas diferentes. Nótese que los registros de tipo NS y los registros adicionales de tipo A no han presentado cambio alguno hasta este momento.

Comprobando nuevamente 90 minutos después, se obtienen los datos de la Tabla 7. Se

observa que los registros NS se mantienen, pero no los registros tipo A adicionales que indican las IPs de los servidores de nombres, con lo que posiblemente se trate de una red fast‐flux de flujo doble.

Las nuevas IPs se refieren a redes dial‐up y de banda ancha, lo cual indica que éstos son

hosts comprometidos usados por un atacante con propósitos criminales.

1.2 Objetivos del proyecto

Introducción 29

ns1.myheroisyourslove.hk 3596 IN A 75.67.15.xxx [c-75-67-15-xxx.hsdl.ma.comcast.net] ns2.myheroisyourslove.hk 3596 IN A 75.22.239.xxx [adsl-75-22-239-xxx.dsl.chcgil.sbcglobal.net]ns3.myheroisyourslove.hk 3596 IN A 75.33.248.xxx [adsl-75-33-248-xxx.dsl.chcgil.sbcglobal.net]ns4.myheroisyourslove.hk 180 IN A 69.238.210.xxx [ppp-69-238-210-xxx.dsl.irvnca.pacbell.net] ns5.myheroisyourslove.hk 3596 IN A 70.64.222.xxx [xxx.mj.shawcable.net]

Tabla 7 El flujo doble se produce cuando tanto las direcciones IP de los servidores de nombre

contenidos en los registros NS (servidores autoridad del dominio) como los registros A (sistemas que sirven el contenido) cambian regularmente, haciendo la red fast‐flux mucho más dinámica. Para que las técnicas de flujo doble funcionen correctamente, el registrador del dominio debe otorgar al administrador del dominio el privilegio de poder cambiar frecuentemente esta información, lo cual no es muy frecuente en la gestión normal de dominios.

1.1.3 Comentarios finales Las FFSN son difíciles de neutralizar. Cuando un atacante se oculta tras una FFSN, es

prácticamente imposible localizarle debido a la redirección ciega y a la dispersión geográfica de los equipos infectados.

La más directa para su neutralización es notificar al registrador del dominio para que

elimine de sus registros las IPs de los servidores de nombres que alojan el dominio y prohíba la actualización de los datos del dominio para que no pueda cambiar el nombre y continuar su actividad. Sin embargo, esto exige tener métodos fiables de detección que permitan afirmar que un dominio constituye una red FFSN. Es necesario por tanto desarrollar técnicas eficientes de detección para poder detectarlas cuanto antes y así poder proceder a su desactivación.

1.2 Objetivos del proyecto El objetivo de este proyecto es la creación de una plataforma software que sirva como

herramienta para la investigación y el desarrollo de nuevos algoritmos y sistemas de detección de redes fast‐flux.

La idea es componer un sistema que permita determinar la probabilidad de que

nombres de dominio especificados por el usuario pertenezcan a una FFSN, solicitando en un primer paso datos referentes a dicho dominio (monitorización) para obtener a continuación dicha probabilidad mediante la utilización de algún método concreto (detección).

Las propiedades de las redes fast‐flux experimentan cambios con el tiempo, ya que los

administradores de estas redes se ven obligados a readaptar sus características para evitar ser detectadas por parte de los expertos en seguridad.


30 Introducción

En la actualidad, existen algunos estudios sobre la detección de redes fast‐flux y también sistemas diseñados para ello, pero estos programas presentan diseños y arquitecturas construidas específicamente para cada método de detección, lo que no permite la incorporación de nuevas funcionalidades, con lo que se exponen a quedar obsoletos.

El software descrito introduce como novedad la posibilidad de incorporación de nuevas

funcionalidades relacionadas con la monitorización y detección de redes fast‐flux que permitan el avance en la investigación de nuevas técnicas para luchar contra este tipo de redes de una forma dinámica, a través de la actualización de su estructura por parte de los profesionales.

La herramienta ha sido diseñada como una plataforma sólida sobre la que se pueden

integrar módulos de monitorización y detección de este tipo de redes de una forma dinámica y extremadamente simple, permitiendo además la independencia absoluta entre estos módulos, lo cual aporta a esta plataforma una flexibilidad considerable.

Además de monitorización y detección, el software dispone de una herramienta

destinada a la búsqueda automatizada de URLs incluidas en archivos de distintos tipos para analizarlas, dando la opción al usuario de poder, por ejemplo, buscar todas las direcciones contenidas en un conjunto de múltiples emails o páginas web sin tener que introducir una a una.

Hay que destacar finalmente que la pretensión de este proyecto no es dar una solución

o método específico para la detección de redes fast‐flux, sino aportar una base firme a aquel usuario que quiera desarrollar trabajos y realizar estudios relacionados con ello, haciendo que su única tarea sea la programación de algoritmos de detección y de obtención de datos sobre un nombre de dominio.

31

CAPÍTULO 2. Estado del arte de la detección de redes fastflux

Este capítulo está dedicado a la exposición de la situación actual en lo que a detección

de redes fast‐flux se refiere. En concreto, se van a exponer varias técnicas de detección que ya están siendo utilizadas en aplicaciones reales. Esto permitirá comprender los requerimientos comunes que debe poseer una aplicación o plataforma para la detección de este tipo de redes.

2.1 Introducción Como se ha comentado en el Apartado 1.1.3, la neutralización de una red fast‐flux es

complicada debido a la dispersión geográfica de los hosts infectados que actúan como redirectores y a la robustez y anonimato proporcionados por la técnica utilizada. Sin embargo, se pueden llevar a cabo labores de detección de nombres de dominio asociados a estas redes y hacer que los administradores de los servidores DNS involucrados eliminen y prohíban el acceso a los registros correspondientes.

Recientemente se han publicado diversos estudios sobre este asunto, todos con un

denominador común: la detección se realiza de forma pasiva. Esto quiere decir que en ningún caso se realizan ataques sobre la red para determinar su naturaleza, sino que todo se hace en base a peticiones de información accesible para cualquier usuario de Internet. Se trata de reconocer en estos datos las características de las redes fast‐flux, expuestas en el Apartado 1.1.2.4. El problema está en que algunas de estas características son comunes a otro tipo de redes legales: las redes de distribución de contenido (Content Delivery Networks, CDNs).


32 Estado del arte de la detección de redes fast‐flux

Las CDNs implementan su servicio aprovechando las funcionalidades que ofrece el sistema DNS. El nombre de dominio de la entidad que quiere alojar el contenido en una red de este tipo apunta al servidor de nombres de la CDN. Mediante el uso de técnicas sofisticadas, la CDN calcula el servidor más cercano que sirve este contenido (en términos de topología de red y de características del enlace) y devuelve la dirección IP de este servidor a la que el cliente se conecta.

Las CDNs, al igual que las FFSNs, devuelven múltiples registros de tipo A pertenecientes

a la misma red. Además hacen uso de TTLs bajos para permitir una rápida reacción a los cambios que se pudieran producir en las características del enlace. Por ello hay que diseñar las técnicas de detección con sumo cuidado para evitar errores en la identificación. Algunas de las técnicas más destacadas en la actualidad se describen a continuación.

2.2 Técnicas de detección En este apartado se van a exponer 3 técnicas diseñadas para la detección de redes fast‐

flux por distintos autores.

2.2.1 Fórmula de Mannheim La primera de las técnicas que se van a describir [2] establece que la forma de distinguir

una red fast‐flux es a través de una función que dependa de los siguientes parámetros:

• Número de registros tipo A (nA)

• Número de sistemas autónomos (nASN)

• Número de registros tipo NS (nNS)

Existen diversas posibilidades para definir esta función. Se establece una primera aproximación, llamada “fluxiness” de un dominio:

(1)

donde nSingle es el número de registros tipo A devueltos en una sola petición. Así, si =1,

es decir, si nA = nSingle, los registros de tipo A no cambian a lo largo del tiempo y la red no tiene las características propias de una FFSN. Sin embargo, si >1, los registros tipo A devueltos por el servidor han cambiado entre solicitudes al servidor DNS y por tanto presenta síntomas propios de una FFSN. Es evidente que cuanto mayor sea este parámetro, mayor es la probabilidad de que el dominio no pertenezca a una red legítima.

Hay que destacar que el parámetro considera de forma implícita el parámetro nASN, ya

que conforme crece el número de registros A también lo hace potencialmente el número de sistemas autónomos que contienen estas IPs.

2.2 Técnicas de detección

Estado del arte de la detección de redes fast‐flux 33

Según este estudio, se puede obtener una métrica general para la detección de dominios fast‐flux uniendo los parámetros observados en vectores “x” de la forma (nA,nASN,nNS). El espacio vectorial resultante permite la definición de una función lineal de decisión F:

0

0

(2)

donde w es un vector de pesos y b un término de desplazamiento. La superficie de decisión que representa F es el hiperplano 0. Un hiperplano separa el espacio vectorial en 2 partes. En este caso, los dominios fast‐flux se encontrarán representados en una de las partes y los que no lo son en la otra parte.

Dado un conjunto de dominios previamente clasificados como fast‐flux o benignos,

existen muchos valores numéricos de w y b válidos para discriminar correctamente ambas clases, pero estos valores no siempre son adecuados para generalizar más allá de este conjunto. Una técnica muy utilizada para obtener una generalización con mínimo error es la determinación del hiperplano óptimo, que separa ambas clases con un margen máximo. En el caso de la función de decisión F, puede calcularse un hiperplano óptimo usando la técnica de la programación lineal, la cual no vamos a tratar en este proyecto.

La función de decisión F se puede plantear también como una medida de puntuación f

para la detección de dominios fast‐flux denominada “puntuación flux” (o flux‐score) que viene dada por:

· · ·

(3)

Una puntuación flux f(x) > b indica que el dominio pertenece a una FFSN, mientras que puntuaciones más bajas corresponden a dominios benignos. Además, la puntuación flux proporciona un ranking de dominios, de forma que aquellos que tienen una puntuación más alta reflejan un alto grado de características fast‐flux, que implícitamente se corresponde con una mayor distancia al hiperplano óptimo trazado por F.

Para la validación de la función f(x), el autor ha hecho uso de medidas empíricas sobre

un conjunto de 128 dominios identificados previamente como fast‐flux y 5803 dominios identificados como benignos. Estas mediciones se han repetido varias veces dejando transcurrir entre ellas un tiempo TTL+1 para evitar obtener los datos guardados en la caché del servidor de nombres.

Con el propósito de calcular el vector de pesos w y el desplazamiento b

correspondientes al hiperplano óptimo, se utiliza el método de la validación cruzada en 10 partes.

El método de la validación cruzada es una herramienta muy útil en estadística. Cuando

se obtiene un modelo estadístico a partir de los elementos de una población, se sabe cómo se adapta el modelo a esta población, pero no cómo se adapta a cualquier elemento que no



pertenezca al conjunto inicial. Este método permite predecir el comportamiento del modelo frente a nuevos casos no incluidos en el conjunto analizado.

La validación cruzada clásica divide la población inicial en dos subconjuntos: el de

entrenamiento y el de validación. El análisis que determinará la función de aproximación se realiza sobre el subconjunto de entrenamiento. La función es validada introduciendo en ella los elementos del subconjunto de validación, con lo que viendo cómo se ajusta el modelo planteado a este subconjunto se tiene una idea de cómo se ajustará a cualquier resultado que no haya intervenido en el análisis.

En el caso que se está tratando, se utiliza la validación cruzada en 10 partes. Consiste en

la división de la población inicial en 10 subgrupos. En total se realizan 10 análisis distintos, utilizando dos subgrupos consecutivos distintos cada vez: el primero juega el papel de subconjunto de entrenamiento y el segundo el de subconjunto de validación. Los resultados obtenidos en cada uno de los análisis son promediados para obtener una estimación lo más justa posible.

Al aplicar a la población inicial la operación descrita, se obtiene la función f(x) óptima,

llamada también fórmula de Mannheim:

1.32 · 18.54 · 0 ·

(4)

y el valor de b es: b=142.38. Se comprueba que este modelo logra una precisión media de detección del 99.98% con

una desviación estándar del 0.05%, con lo que apenas existe error. Cabe destacar que el peso que corresponde a nNS es 0 y no contribuye a la detección de

FFSNs. A pesar de que la puntuación flux se construye a partir de tan solo 2 parámetros, evadir la detección es difícil ya que los parámetros nA y nASN reflejan propiedades esenciales de la estructura distribuida de una FFSN.

Los parámetros que se han calculado anteriormente no deben ser estáticos, sino

dinámicos, ya que los cibercriminales podrían aplicar pequeños “trucos” para obtener una puntuación flux más baja y así no ser clasificados como FFSN. El ajuste automático de niveles es un problema que está aún por resolver.

Se pueden considerar otros parámetros como refuerzo de la detección, tales como el

número de nombres de dominios obtenidos al llevar a cabo una resolución inversa de una dirección IP, las variaciones temporales de los registros tipo A y tipo NS o los campos TTL de los registros.



2.2.2 Método de Nazario y Holz Un estudio posterior [3] basado en el anterior consiste en la asignación a cada dominio

de una puntuación. Se atribuye un punto al dominio por cada condición presentada de entre las siguientes:

• Que el TTL asignado a los registros A sea menor que 900 segundos (15 minutos).

• Que existan más de 5 direcciones IP únicas asignadas al dominio en una sola petición.

• Que la distancia media entre direcciones IP sea mayor que 65535 (es decir, que difieran en uno de los dos primeros octetos).

• Que existan más de 8 direcciones IP distintas en el conjunto total obtenido y que la distancia media entre ellas sea de más de 65535 direcciones.

• Que el conjunto de registros tipo A resultante muestre más de 2 ASNs distintos asignados.

• Que entre las direcciones IP asignadas a los registros NS exista una separación mínima de 65535 direcciones.

• Que existan más de 3 registros NS asignados al nombre de dominio.

• Que el conjunto de registros tipo NS resultante muestre más de 2 ASNs distintos asignados.

• Que el valor mínimo del campo “Retry”, incluido en la respuesta a la petición de tipo SOA, sea 900 segundos.

Si el dominio cumple 5 o más de estas características (es decir, si tiene 5 puntos o más), el dominio es considerado fast‐flux.

En el diseño de esta técnica se asume que cualquier red fast‐flux diseñada para ser

robusta y permanecer activa durante mucho tiempo establece un TTL muy bajo para los registros tipo A de sus sistemas comprometidos. Se supone también que los ordenadores que la componen están dispersos a través de Internet puesto que el hacker no tiene el control sobre qué ordenadores son infectados.

El método expuesto ha sido diseñado para conseguir un compromiso entre la precisión

en la detección de un dominio fast‐flux real y la sensibilidad que se necesita para evitar identificar incorrectamente redes absolutamente legítimas que presenten características comunes con las redes fast‐flux.

2.2.3 Método de Melbourne Por último, se presenta un modelo analítico para la detección de redes fast‐flux [4]. Una

de las novedades introducidas por este estudio es que no se centra en la obtención de un algoritmo de detección, sino en la forma de aumentar la velocidad de la misma.

Se considera un dominio fast‐flux con H host infectados, de forma que si se observan h

de estos equipos, se clasificará el dominio como tal.



Cada petición DNS que se realiza devuelve un conjunto de direcciones IP de entre las H direcciones pertenecientes a la red. Al ser una selección aleatoria, las direcciones IP devueltas a veces se habrán repetido con anterioridad y a veces no. Se nombra Xh,H a la variable aleatoria que denota el número de peticiones que se llevan a cabo hasta observar los h hosts necesarios para la identificación. El objetivo es determinar el valor esperado de esta variable, es decir, E(Xh,H).

En el proceso de identificación de IPs que pertenecen a un dominio se puede considerar

la existencia de dos fases. Durante la primera fase o fase de descubrimiento, se produce un muestreo aleatorio de un grupo estático de direcciones IP. Durante la segunda fase o fase estable, el muestreo se hace sobre el mismo grupo al que se van añadiendo nuevas IPs de forma gradual.

La Figura 2.1 muestra el número de IPs identificadas en 480 peticiones DNS para el

dominio fast‐flux www.dominioff1.tk. Las peticiones DNS fueron enviadas cada 10 minutos. Como se muestra en la gráfica, los resultados de las primeras 20 peticiones constituyen la fase de descubrimiento, donde se obtuvieron en total 115 IPs únicas uniendo todas las IPs que se recibían en grupos de 14 en cada respuesta del servidor.

Durante la fase estable, se puede apreciar que el crecimiento del número de IPs es

mucho menor, aunque sigue existiendo un aumento debido a la incorporación de nuevos hosts a la estructura de la red.

Dado que durante la fase de descubrimiento se pueden identificar los h hosts para

etiquetar la red como fast‐flux, ésta se puede modelar como un problema de muestreo aleatorio. El modelado que se trata de resolver es un claro ejemplo del problema llamado comúnmente en estadística “El coleccionista de boletos”, que trata de calcular el número esperado de muestras necesarias (con reemplazamiento) de un conjunto de H objetos para que cada muestra salga al menos una vez.

Figura 2.1 (obtenida de [4])



Figura 2.2 (obtenida de [4]) Se puede demotrar que si Yi,H es la variable aleatoria que representa el número de

muestras tomadas para pasar de ver i‐1 objetos a ver i objetos de los H elementos, entonces:

, 1

(5)

Entonces, el número esperado de muestras para obtener todos los elementos del conjunto (H) es:

, , , , ·1

(6)

Y el número esperado de muestras para obtener h elementos distintos es:

, , , , · ·

(7)

Si la observación está basada en un solo servidor DNS y suponemos que las peticiones se realizan a una tasa media de p peticiones por unidad de tiempo, entonces el tiempo esperado para detectar un número suficiente de direcciones IP únicas para poder considerar el dominio como fast‐flux es:

·

(8)

siendo O(f) una función que expresa la tasa de crecimiento de la función f. Se considera la gráfica de la Figura 2.2. En ella se muestran los resultados obtenidos

para 3 dominios fast‐flux reales y también dos curvas teóricas: un modelo lineal semejante al expuesto en el apartado anterior y el modelo analítico que se ha deducido en este estudio, suponiendo una tasa de p=14 peticiones por unidad de tiempo y un conjunto de H=115 direcciones IP. Se puede apreciar que la curva para los dominios fast‐flux reales se



encuentran entre el modelo lineal y el modelo analítico, debido a que la fase de descubrimiento es mezcla de la técnica round‐robin y de muestreo aleatorio. El modelo analítico impone un límite superior al número de peticiones requeridas.

Se demuestra que se puede reducir el tiempo de detección del dominio combinando los

resultados de distintos servidores DNS. Si hay m servidores DNS y se envían a cada uno p peticiones por unidad de tiempo, entonces poniendo en común los resultados se obtiene que el tiempo requerido para la detección es:

·· (9)

• Correlación de resultados de dominios fast‐flux

La velocidad de detección está limitada por la frecuencia con la cual un servidor DNS ve nuevas direcciones IP asignadas al dominio sospechoso. Para poner de manifiesto las limitaciones de realizar la detección dirigiendo peticiones a un solo servidor, el estudio propone 2 aproximaciones de correlación para la detección de dominios fast‐flux, en términos de:

o Correlación de resultados de distintos servidores DNS. o Correlación de resultados de distintos dominios sospechosos.

En cada caso se consideran datos empíricos de dominios fast‐flux reales de phishing para validar los modelos.

Correlación de resultados de distintos servidores DNS Las razones de ser de esta aproximación son las siguientes:

• Si distintos servidores ven resultados distintos para la misma petición, entonces existe un beneficio al combinar los resultados correspondientes.

• Existe un aumento lineal potencial en la velocidad de detección cuando se incrementa el número de servidores DNS que participan en la monitorización.

Se considera la Figura 2.3. En ella se recogen los resultados obtenidos sobre un dominio

www.dominioff3.eu procedentes de un servidor DNS situado en Brasil (a la izquierda) y de otro situado en Suiza (a la derecha). Ambos conjuntos de datos se obtuvieron de manera simultánea. En este escenario cada servidor trabaja de forma independiente para detectar el dominio fast‐flux.

Ambos servidores DNS tienen un comportamiento muy parecido en cuando al número

de direcciones IP únicas identificadas en la fase de descubrimiento. Como se puede ver en la gráfica de la izquierda, el servidor DNS de Brasil informó de 14 direcciones IP únicas asignadas al dominio en la primera solicitud y un total de 117 direcciones IP únicas tras 20 solicitudes. El servidor DNS de Suiza presenta un comportamiento similar.



Figura 2.3 (obtenida de [4]) Si se pudieran combinar los resultados de ambos servidores DNS, intuitivamente se

dispondría de más direcciones IP asociadas al dominio en menos tiempo, y consecuentemente aumentaría la velocidad de detección. Sin embargo, este aumento de velocidad presenta una fuerte dependencia con el grado de independencia o de decorrelación entre ambos conjuntos de resultados.

Las Tablas 8 y 9 muestran los resultados de una sola petición DNS de muestra para el

dominio www.dominioff3.eu enviada simultáneamente a los dos servidores DNS.

dominioff3.eu 600 IN A 001.181.31.106 dominioff3.eu 600 IN A 001.181.31.106 dominioff3.eu 600 IN A 002.8.35.209 dominioff3.eu 600 IN A 001.208.14.142 dominioff3.eu 600 IN A 003.184.35.240 dominioff3.eu 600 IN A 001.210.33.238 dominioff3.eu 600 IN A 004.94.99.152 dominioff3.eu 600 IN A 001.76.83.55 dominioff3.eu 600 IN A 007.137.128.99 dominioff3.eu 600 IN A 002.158.225.101dominioff3.eu 600 IN A 010.178.217.58 dominioff3.eu 600 IN A 003.184.35.240 dominioff3.eu 600 IN A 012.69.170.118 dominioff3.eu 600 IN A 010.178.217.58 dominioff3.eu 600 IN A 012.98.71.156 dominioff3.eu 600 IN A 011.191.248.113dominioff3.eu 600 IN A 013.147.2.253 dominioff3.eu 600 IN A 012.183.220.208dominioff3.eu 600 IN A 017.102.47.94 dominioff3.eu 600 IN A 012.69.170.118 dominioff3.eu 600 IN A 018.100.69.190 dominioff3.eu 600 IN A 012.98.71.156 dominioff3.eu 600 IN A 020.130.9.214 dominioff3.eu 600 IN A 015.109.227.159dominioff3.eu 600 IN A 024.46.80.193 dominioff3.eu 600 IN A 017.102.47.94 dominioff3.eu 600 IN A 025.131.109.236 dominioff3.eu 600 IN A 028.183.196.29

Tabla 8 Tabla 9 La Tabla 8 corresponde a los resultados devueltos por el servidor de Brasil y la Tabla 9 al

servidor de Suiza. Las direcciones marcadas en negrita son las comunes a ambos conjuntos. Al unir ambos conjuntos se obtienen más IPs asociadas que considerando cada respuesta por separado.

En base a este ejemplo, se formaliza el esquema de correlación. Sea

| 1,2, … , un conjunto de servidores DNS pertenecientes a distintos dominios de red e ISPs. Cada servidor DNS di responde peticiones sobre un dominio sospechoso a una



tasa media de p peticiones por unidad de tiempo. Estos servidores DNS correlan sus resultados para buscar evidencias de que el dominio sea fast‐flux.

Los datos compartidos por los servidores DNS pueden ser de distinta índole. En este

caso sin embargo, para simplificar el análisis, se utiliza un esquema basado exclusivamente en los registros tipo A asociados al dominio.

Sea PLi (Proxy List) el conjunto de direcciones IP únicas recogidas por el servidor DNS di:

1,2, … , ;

(10)

siendo sij la IP única número j registrada por el servidor di. Se considera el caso en el que todos los servidores DNS participantes correlan sus listas

obtenidas para el dominio f después de cada petición. Se denota la lista conjunta resultante del dominio f después de t peticiones como CPL (Combined Proxy List), es decir:

…

(11)

Por lo tanto, el número de direcciones IP únicas identificadas tras t peticiones es:

| |

(12)

Para la evaluación del modelo planteado, en el estudio se lleva a cabo la monitorización de varios dominios fast‐flux durante 2 semanas en Agosto de 2008. Las peticiones se realizaban con una frecuencia de 1 cada 10 minutos y se enviaban hacia 7 servidores DNS simultáneamente, situados en distintas zonas geográficas.

En la Figura 2.4 se muestran los conjuntos PLi y CPL para www.dominioff2.eu. Se comprueba que individualmente se obtienen unas 100 direcciones IP únicas después

de 17 peticiones al mismo servidor DNS. Este número se ve reducido a solo 9 peticiones si se combinan los resultados, lo cual denota un aumento considerable en la velocidad de detección de la red.

Correlación de resultados de distintos dominios sospechosos Se ha comprobado empíricamente que, en ocasiones, múltiples dominios fast‐flux

hacen uso del mismo conjunto de IPs. En la mayoría de los casos esto es debido a que el dominio está establecido sobre una botnet alquilada, compartiendo los equipos infectados con otros dominios establecidos también sobre la misma.

En la Figura 2.5 se muestran los resultados de la observación de 2 dominios etiquetados

como fast‐flux desde el mismo servidor DNS.




Figura 2.5 (obtenida de [4]) Como se puede observar, ambos dominios presentan comportamientos similares en las

primeras 480 peticiones. Se comprobó que existían una gran cantidad de elementos comunes en ambos conjuntos. Las Tablas 10 y 11 ponen de manifiesto este hecho:

dominioff1.tk 600 IN A 002.57.70.209 dominioff1.tk 600 IN A 002.57.70.209 dominioff1.tk 600 IN A 004.209.243.172 dominioff1.tk 600 IN A 003.184.35.240 dominioff1.tk 600 IN A 005.209.75.40 dominioff1.tk 600 IN A 004.209.243.172 dominioff1.tk 600 IN A 007.223.178.4 dominioff1.tk 600 IN A 005.209.75.40 dominioff1.tk 600 IN A 009.80.11.108 dominioff1.tk 600 IN A 007.223.178.4 dominioff1.tk 600 IN A 011.181.105.112 dominioff1.tk 600 IN A 008.240.173.146 dominioff1.tk 600 IN A 012.183.220.208 dominioff1.tk 600 IN A 009.80.11.108 dominioff1.tk 600 IN A 012.251.254.179 dominioff1.tk 600 IN A 011.8.98.176 dominioff1.tk 600 IN A 012.69.170.118 dominioff1.tk 600 IN A 012.251.254.179 dominioff1.tk 600 IN A 015.108.209.42 dominioff1.tk 600 IN A 015.108.209.42 dominioff1.tk 600 IN A 015.109.227.159 dominioff1.tk 600 IN A 015.109.227.159 dominioff1.tk 600 IN A 017.102.44.173 dominioff1.tk 600 IN A 017.102.44.173 dominioff1.tk 600 IN A 019.235.222.87 dominioff1.tk 600 IN A 019.235.222.87 dominioff1.tk 600 IN A 026.255.101.5 dominioff1.tk 600 IN A 026.255.101.5

Tabla 10

Tabla 11



En estas tablas se ha representado la respuesta recibida a una de las solicitudes para cada dominio consultado. Se observa que 11 de las 14 respuestas recibidas son comunes.

A partir de esto, se puede construir un modelo de detección basado en un solo servidor

DNS. La motivación para la construcción del modelo es el hecho de que la velocidad de identificación aumenta si una IP pertenece a varios dominios sospechosos simultáneamente.

Sea el conjunto de dominios fast‐flux | 1,2, … , monitorizados por un solo

servidor DNS. Se procede a realizar peticiones sobre los dominios fi a una tasa de p peticiones por unidad de tiempo y se correlan los resultados tras cada respuesta. En este modelo vuelve a proponerse la correlación de los registros de tipo A.

Se nombra el conjunto de IPs observadas por el servidor DNS para el dominio fi como

PLi, donde: 1,2, … , ;

(13)

donde sij es la IP número j asociada al dominio fi. Entonces, la lista conjunta de proxies es:

…

(14)

Con lo cual, el número de direcciones IP identificadas tras t solicitudes es:

| |

(15)

Para la evaluación del modelo, se consideran dos ejemplos: en el primero de ellos, se analiza el efecto que se produce al correlar los resultados obtenidos de 3 dominios fast‐flux y en el segundo el efecto al correlar los datos de 17 dominios fast‐flux diferentes. En ambos casos solamente se considera la fase de descubrimiento (20 peticiones en este caso).

En el caso de la correlación de los 3 dominios, se obtiene la Figura 2.6. En ella se

representa tanto los resultados individuales como los de la correlación de los 3 dominios fast‐flux diferentes en términos del número de peticiones requerido para identificar un número dado de direcciones IP únicas. Tal y como se muestra, las curvas correspondientes a los resultados tomados para cada dominio por separado tienen un comportamiento similar. Sin embargo, los resultados del esquema de correlación superan claramente los resultados anteriores, con aproximadamente un 30% menos de solicitudes necesitadas para identificar el mismo número de hosts.

En la Figura 2.7 se representan los resultados de la correlación de 17 dominios fast‐flux

distintos. En este caso, se detectan muchas más direcciones IP que las obtenidas de cualquier dominio por separado.



A pesar de que en este capítulo se han explicado varias técnicas de detección fast‐flux, hay que aclarar que el objetivo del proyecto no es obtener ninguna técnica novedosa de detección, sino la programación de una plataforma que permita integrar.


Figura 2.7 (obtenida de[4])

45

CAPÍTULO 3. Especificación y análisis de requisitos

En este capítulo se explican cuáles son aquellos requisitos y restricciones referentes al

sistema que se han tenido en cuenta a la hora de diseñar e implementar la aplicación. Se presenta adicionalmente un análisis del problema, donde se describen a muy alto nivel las funcionalidades que se asignan al sistema para cumplir los requisitos definidos.

3.1 Definición de requisitos Los requisitos del sistema son el conjunto de exigencias que el cliente manifiesta que

tiene con respecto a la aplicación. Los requisitos han sido divididos en dos categorías: requisitos funcionales y no funcionales.

3.1.1 Requisitos funcionales Un requisito funcional es una característica requerida del sistema que expresa una

capacidad de acción del mismo, una funcionalidad de la aplicación. Los requisitos funcionales de este proyecto se enumeran a continuación:

• La aplicación debe recibir como entrada un conjunto de nombres de dominio. Este conjunto tendrá varias fuentes posibles. El programa debe ser capaz de extraer todos los nombres de dominio contenidos en estas fuentes para ser analizados. Estas fuentes son las siguientes:

o Una línea de texto escrita por el usuario, para analizar cualquier dominio que el usuario desee.


46 Especificación y análisis de requisitos

o Un archivo de texto (extensión txt), lo que permitiría al usuario ir almacenando nombres de dominio en el archivo para analizar todos en una misma sesión sin tener que introducir uno a uno por teclado.

o Uno o varios emails (extensión eml), pensado para el análisis de correos de spam, que son los principales portadores de nombres de dominio pertenecientes a FFSNs.

o Una o varias páginas web (extensión mht), las cuales pueden estar incluidas en emails o no.

• El usuario podrá elegir:

o El volumen de datos que se desea manejar, a través de la especificación de un tiempo máximo para la recogida de datos para cada conjunto de dominios. Es evidente que cuanto mayor sea el tiempo marcado, mayor será la cantidad de datos obtenidos sobre el dominio que permitirán realizar el proceso de detección.

o El tiempo máximo que puede durar la detección de un dominio, permitiendo al sistema detener las operaciones activas en caso de bloqueo.

o El número de dominios a monitorizar a la vez, dando al usuario la posibilidad de solicitar datos de tantos dominios simultáneamente como desee.

o El número de dominios a detectar a la vez, dando al usuario la posibilidad de llevar a cabo la detección de tantos dominios simultáneamente como desee.

o El servidor DNS al que se desea dirigir las consultas sobre los dominios para obtener los datos correspondientes.

• La aplicación deberá hacer uso de una base de datos para almacenar tanto los datos obtenidos sobre cada dominio como las probabilidades devueltas por las operaciones de detección ejecutadas. La razón por la que se prefiere una base de datos a un archivo es que la base de datos tiene una capacidad de gestión mucho mayor que el archivo y el acceso a los datos se realizará de modo más simple.

• Para permitir al usuario el acceso a los resultados obtenidos, la aplicación presentará al usuario cuando éste lo solicite un informe sobre el dominio que escoja de entre los dominios previamente detectados y almacenados en la base de datos, presentándole al menos los siguientes datos:

o Nombre del dominio o Fecha y hora de inicio del análisis o Fecha y hora de fin del análisis o Datos recogidos sobre el dominio o Probabilidad determinada por el detector/detectores

3.1.2 Requisitos no funcionales Los requisitos no funcionales son aquellos que no especifican funcionalidades del

sistema, sino condiciones que la aplicación debe cumplir y que deben ser tenidas en cuenta durante las fases de diseño e implementación de la misma.

3.1 Definición de requisitos

Especificación y análisis de requisitos 47

Los requisitos no funcionales de este proyecto son los siguientes:

• El lenguaje de programación utilizado debe ser Python. El lenguaje Python es un lenguaje orientado a objetos. Las razones por las que se ha elegido este lenguaje son las siguientes:

o Su sintaxis es muy legible y clara, permitiendo a cualquier desarrollador entender el código escrito sin muchas dificultades.

o Tiene una alta modularidad, con estructuras jerárquicas, lo que supone una organización del código muy eficiente.

o Presenta la posibilidad de incorporar al lenguaje módulos escritos en C, C++ y Java de una forma sencilla, dando al usuario una alta flexibilidad en la implementación de nuevos módulos para la plataforma.

o Posee librerías estándar para el manejo y operación de datos de muy alto nivel, permitiendo la programación de operaciones complejas utilizando un número menor de líneas de código que en el caso de otros lenguajes.

• El software debe tener la capacidad de analizar un mínimo de 10 dominios simultáneamente, haciendo que el tiempo de monitorización de un conjunto de dominios pueda ser menor que si los dominios se monitorizan de forma secuencial.

• El usuario debe tener la capacidad de detener la ejecución del análisis de los dominios en cualquier momento.

• Como mínimo, la plataforma inicial debe ser capaz de monitorizar los registros tipo A, las direcciones IP correspondientes a los registros NS de un dominio y los TTLs asociados a ambos tipos de registros. Estos tres parámetros, como se ha visto anteriormente, juegan un papel muy importante en las operaciones de detección de FFSNs.

• El programa debe estar diseñado para poder acoplar a él nuevas funcionalidades de monitorización y detección de una forma sencilla y cómoda. En la documentación se debe incluir una guía para el desarrollador de este tipo de módulos, exponiendo los pasos a seguir en la implementación e incorporación al sistema de los mismos.

• Las operaciones de monitorización y detección de dominios deben ser transparentes al usuario, indicando en cada momento la fase en la que se encuentra el análisis de cada uno. Tareas como las peticiones realizadas al servidor DNS, la actualización de la base de datos o la ejecución del algoritmo de detección serán llevadas a cabo sin la intervención del usuario.

• La interfaz de usuario debe ser lo más simple y sencilla posible, aportando facilidad de uso a la aplicación.



3.2 Análisis En este apartado se realiza un análisis de la aplicación a diseñar e implementar,

utilizando como base los requisitos expuestos en el Apartado 3.1. Se trata de una descripción a muy alto nivel de las operaciones básicas del sistema y de las entidades externas que intervienen en las funcionalidades que el sistema presenta. Para ello, se van a presentar casos de uso, diagramas de secuencia del sistema y contratos de operaciones, que son herramientas del lenguaje estándar UML [5] para este tipo de análisis.

3.2.1 Casos de uso Un caso de uso es una descripción de la secuencia de interacciones que se producen

entre uno o varios “actores” (agentes externos al sistema) y el sistema cuando el actor llama al sistema para llevar a cabo una tarea específica. Mediante ellos se capturan los requisitos de la aplicación para hacerlos presentes a lo largo de todo el proceso de desarrollo.

3.2.1.1 Escenario El diagrama de casos de uso siguiendo la notación UML es el de la Figura 3.1. En este

escenario se muestra de forma muy general cómo funciona este software, especificando qué actores intervienen en qué operaciones. Los actores ejecutan los casos de uso, representados dentro del rectángulo central y rodeados por elipses, de forma secuencial o concurrente, para cumplir los objetivos de la aplicación.

Figura 3.1

3.2 Análisis


Identificación de actores Los actores que intervienen en el sistema son los siguientes:

Usuario: Es la persona que utiliza la aplicación. Servidor de información: Es un servidor que ha sido especificado por el usuario para

obtener datos correspondientes a los dominios. Base de datos: Es el soporte en el que se van a almacenar tanto los datos recibidos

sobre los dominios como los resultados de la detección.

3.2.1.2 Detalle de los casos de uso Para obtener un nivel más alto de detalle, a continuación se presentan los casos de uso

en formato expandido, explicando paso a paso cada interacción entre usuarios y sistema:

Introducir parámetros Actores: Usuario. Propósito: Permitir al usuario introducir un nombre de dominio o conjunto de ellos

para su posterior análisis. Referencias: Requisitos funcionales 1 y 2. Curso típico de eventos:

Acción del actor Respuesta del sistema 1. Inicia el programa.

2. Presenta las opciones disponibles. 3. Selecciona analizar dominios y la

fuente de los dominios: o Si se elige introducir las URLs por

teclado, ver sección Dominios por teclado.

o Si se elige como fuente un archivo de texto, ver sección Dominios por archivo.

o Si se elige como fuente un conjunto de emails o páginas web, ver sección Dominios por emails o webs.

4. Filtra las URLs extraídas, obteniendo nombres de dominio.

5. Pide al usuario que escriba el tiempo máximo de análisis, el número máximo



de dominios simultáneos y el servidor de nombres preferido.

6. Introduce los datos pedidos. 7. Procesa los datos. 8. Pasa al caso de uso 2.

• Sección Dominios por teclado:

Acción del actor Respuesta del sistema 1. Presenta un cuadro de texto.

2. Introduce las URLs en el cuadro de texto.

3. Extrae las URLs del texto escrito.

• Sección Dominios por archivo:


2. Introduce la ruta del archivo de texto. 3. Abre el archivo especificado. 4. Extrae las URLs contenidas en el

archivo.

• Sección Dominios por emails o webs:


2. Introduce la ruta del directorio de emails y páginas web.

3. Abre los emails y las páginas web. 4. Extrae las URLs contenidas en cada

archivo.

Cursos alternativos:

• Línea 4, sección Principal: No se han extraido URLs. Se cancela la operación.

• Línea 4, sección Dominios por archivo: El archivo especificado no existe o no se puede abrir. Se notifica al usuario y se cancela la operación.

• Línea 3, sección Dominios por emails: El directorio especificado no existe o no se puede abrir. Se notifica al usuario y se cancela la operación.

Obtener características Actores: Servidor de información (actor 1) y base de datos (actor 2).

3.2 Análisis


Propósito: Obtener información sobre los dominios especificados. Referencias: Requisito funcional 3 y no funcional 4. Curso típico de eventos:

Acción del actor 1 Respuesta del sistema Acción del actor 2 1. Escoge un nombre de

dominio de la lista.

2. Envía a la base de datos una petición de lectura sobre los datos del dominio.

3. Responde al sistema: o Si contiene los datos,

ver sección Sí contiene.

o Si no contiene los datos, continuar en esta sección.

4. Envía al servidor un mensaje de petición de información.

5. Responde a la petición realizada.

6. Extrae la información del mensaje de respuesta.

7. o Si no ha transcurrido

el tiempo máximo de análisis: tras un tiempo dado, se vuelve al paso 4.

o Si ha transcurrido el tiempo máximo de análisis: ver sección Tiempo cumplido.

• Sección Sí contiene:

Acción del actor 2 Respuesta del sistema 1. Devuelve los datos sobre el dominio al

sistema.

2. Finaliza el análisis del dominio.



• Sección Tiempo cumplido:

Acción del actor 2 Respuesta del sistema 1. Envía los datos recogidos a la base de

datos. 2. Almacena los datos.

3. Pasa al caso de uso 3.


• Línea 6, sección Principal: El servidor DNS no responde. Se notifica al usuario y se cancela la operación.

• Línea 7, sección Principal: El mensaje de respuesta contiene un código de error. Se cancela la operación.

Comentarios: El curso de eventos principal se llevará a cabo para cada uno de los parámetros a monitorizar de cada uno de los dominios de la lista de forma independiente, ejecutándose simultáneamente para tantos dominios como el usuario haya especificado. Esto se explicará con más detalle en la sección 3.2.2.2.

Detectar Actores: Base de datos. Propósito: Determinar si la URL analizada pertenece o no a una red fast‐flux. Referencias: Requisito funcional 3. Curso típico de eventos:

Acción del actor Respuesta del sistema 1. Pide a la base de datos la información

recogida sobre el dominio. 2. Devuelve los datos recogidos sobre el

dominio.

3. Ejecuta el algoritmo de detección. 4. Envía a la base de datos el resultado

del algoritmo. 5. Almacena el resultado del algoritmo.


• Línea 3: No existen datos suficientes para la ejecución del algoritmo. El sistema finaliza.

3.2 Análisis


Comentarios: Este caso de uso se ejecutará para cada detector incluido en la aplicación de cada nombre de dominio, tantos de forma simultánea como lo haya indicado el usuario.

Generar informe Actores: Usuario (actor 1) y Base de datos (actor 2). Propósito: Mostrar un informe sobre cualquier dominio con los datos de

monitorización y detección correspondientes. Referencias: Requisito funcional 4. Curso típico de eventos:

Acción del actor 1 Respuesta del sistema Acción del actor 2 1. Selecciona consultar

dominios

2. Envía una consulta a la base de datos para conocer los nombres de dominio registrados.

3. Devuelve una lista con los nombres de dominio registrados

4. Muestra la lista al usuario

5. Escoge un nombre de la lista

6. Envía una petición a la base de datos sobre el dominio escogido

7. Devuelve los datos correspondientes al dominio

8. Presenta al usuario un informe conteniendo todos los datos del dominio.

3.2.2 Diagramas de secuencia del sistema La idea de este apartado es dar un paso más en la especificación del sistema. Para ello,

se va a hacer uso de una nueva herramienta: los diagramas de secuencia.



Un diagrama de secuencia del sistema es un gráfico que muestra, para un escenario particular de un caso de uso, los eventos que generan actores externos, su orden y los eventos entre sistemas. Todos los sistemas son tratados como cajas negras; el énfasis de los diagramas está en los eventos que cruzan la frontera del sistema, desde los actores al sistema.

A continuación se muestran los diagramas de secuencia del sistema, uno por cada caso

de uso definido.

3.2.2.1 Introducir parámetros Las operaciones que intervienen en este caso de uso son las siguientes (Figura 3.2):

analizarDominios(): El usuario da la orden al sistema de que desea iniciar un análisis de nombres de dominio.

introducirDominios(fuente): El usuario especifica al sistema dónde se encuentran los

elementos a analizar. El parámetro fuente puede ser una línea de texto escrita por el usuario, la ruta de un archivo de texto o la ruta de un directorio de emails o de páginas web.

extraerDominios(): El sistema extrae los nombres de dominio contenidos en la fuente

especificada por el usuario. introducirParametros(parámetros): El usuario especifica cuáles son los parámetros del

análisis en cuestión. El parámetro parámetros es un conjunto de números que especifican el número máximo permitido de dominios a monitorizar simultáneamente, el tiempo máximo permitido de monitorización por dominio, el número máximo permitido de dominios a detectar simultáneamente y el tiempo máximo permitido de detección por dominio.

Figura 3.2

3.2 Análisis


3.2.2.2 Obtener características Las operaciones que intervienen en este caso de uso son las siguientes (Figura 3.3):

getDatos(dominio): El sistema envía una solicitud a la base de datos para comprobar si el dominio ha sido analizado anteriormente. Se seguirá adelante si el dominio no se ha analizado antes.

getInfo(dominio): El sistema solicita información sobre el dominio al servidor de

información. Se sigue adelante una vez obtenida la respuesta. procesarRespuesta(): El sistema procesa el mensaje de respuesta, almacenando

solamente los datos importantes, incluyendo el campo TTL del registro devuelto en el caso del servidor DNS.

almacenarDatos(datos): El sistema envía los datos recogidos (parámetro datos) a la

base de datos para que los almacene.

El proceso completo se repite para cada nombre de dominio de la lista extraída en el caso de uso anterior. En la Figura 3.3 representa el caso particular de que el servidor de información sea un servidor DNS.

Figura 3.3



Las operaciones getInfo y procesarRespuesta se ejecutan cada x segundos para cada registro pedido de cada dominio, siendo x el valor de TTL del último registro obtenido asociado al dominio. Si tras recibir una respuesta se enviara una petición sobre el mismo registro antes de que pasen TTL segundos, se recibiría el mismo registro por estar éste almacenado en caché.

Ejemplo: Se desea analizar los dominios dominio1.com y dominio2.es simultáneamente,

recogiendo para cada uno de ellos los registros tipo A y tipo NS correspondientes. A cada parámetro de cada dominio le corresponde un mensaje de solicitud, que es el

que se envía al servidor DNS para pedirle la información correspondiente. Se envía el primero de los mensajes para cada parámetro (en total 4 parámetros, dos para cada dominio, con lo que se envían 4 mensajes). En la primera iteración (instante t0) se envían todos a la vez, obteniendo la siguiente respuesta:

Direcciones tipo A

TTL Registros tipo A

Direcciones tipo NS

TTL Registros tipo NS

dominio1.com IP1 IP2 IP3

300 300 300

IP4 IP5

1500 1500

dominio2.es IP6 IP7 IP8

500 500 500

IP9 IP10

900 900

Cada registro se volverá a pedir una vez transcurrido el tiempo indicado en el campo

TTL del registro en cuestión desde el instante t0. Pasados 300 segundos desde t0 (instante t1), se envía de nuevo un mensaje al servidor,

esta vez solamente de tipo A sobre el dominio dominio1.com, obteniendo:

Direcciones tipo A TTL Registros tipo A

dominio1.com IP11 IP12 IP13

400 400 400

Este registro no se volverá a solicitar hasta que no hayan pasado 400 segundos desde el

instante t1. Pasados 500 segundos desde t0 (instante t2), se pide de nuevo la información de tipo A

sobre el dominio dominio2.es, obteniendo:

Direcciones tipo A TTL Registros tipo A

dominio2.es IP14 IP15 IP16

1100 1100 1100

3.2 Análisis


Este registro no se volverá a solicitar hasta que no hayan pasado 1100 segundos desde el momento t2.

Esto ocurrirá una y otra vez para cada registro hasta que haya transcurrido el tiempo

máximo de monitorización marcado por el usuario a partir de t0.

3.2.2.3 Detectar Las operaciones que intervienen en este caso de uso son las siguientes (Figura 3.4):

getDatos(dominio): El sistema solicita a la base de datos que le entregue los datos necesarios correspondientes al dominio que se pretende detectar (parámetro dominio). La base de datos devuelve los datos al sistema.

algoritmoDeteccion(datos): El sistema ejecuta el algoritmo de detección utilizando los

datos recogidos en la operación anterior (parámetro datos). almacenarResultado(resultado): El sistema envía los resultados de la detección

(parámetro resultado) a la base de datos para que los almacene donde corresponda.

3.2.2.4 Generar informes Las operaciones que intervienen en este caso de uso son las siguientes (Figura 3.5):

obtenerInforme(): El usuario solicita al sistema que le muestre un informe. getNombresDominio(): El sistema solicita a la base de datos una lista con todos los

nombres de dominio que han sido analizados hasta el momento y que se encuentran registrados. La base de datos responde con la lista de nombres y el sistema la muestra al usuario.

seleccionar(dominio): El usuario selecciona un dominio (parámetro dominio) de la lista

devuelta en la operación anterior. getDatos(dominio): El sistema solicita a la base de datos todos los datos disponibles

sobre el dominio (parámetro dominio). elaborarInforme(datosDominio): El sistema elabora un informe con los datos del

dominio (parámetro datosDominio) y lo muestra al usuario.



Figura 3.4

Figura 3.5

59

CAPÍTULO 4. Planificación y costes

En este capítulo se va a exponer la planificación establecida para el desarrollo de este

proyecto y los costes asociados a su elaboración.

4.1 Planificación Previamente al comienzo del desarrollo de este proyecto, se ha elaborado una

planificación detallada de todo el proceso dividida en paquetes de trabajo. Cada paquete de trabajo tiene un período de tiempo asignado para su ejecución, concluyendo con la entrega de un documento en el que se hace una exposición del trabajo llevado a cabo y de los resultados obtenidos a lo largo del desarrollo de dicha fase.

Los paquetes de trabajo de este proyecto son los siguientes:

Estudio inicial: En esta fase se ha realizado un estudio en profundidad de los distintos aspectos del problema que se pretenden resolver y de las tecnologías que forman parte del entorno del problema y de su posible solución. Concretamente, se ha profundizado en el modo de operación de las redes fast‐flux, el protocolo DNS y mejores prácticas en la detección. Esta fase no tiene asociado ningún entregable.

Análisis: En esta fase se analiza cuáles son los objetivos que debe cumplir el proyecto.

Atendiendo a los requisitos que debe cumplir la aplicación, se definen los actores y los casos de uso del sistema. El entregable asociado a esta fase es un documento en el que se describen los casos de uso detalladamente, incluyendo los diagramas de secuencia del sistema, que describen a alto nivel la interacción del usuario con el sistema.

Diseño: En esta fase se idea el diseño de la aplicación a implementar. Para ello, se

tienen en cuenta todos los datos obtenidos en el análisis. Se comienza diseñando la


60 Planificación y costes

estructura de la aplicación a nivel de bloques, que son en un principio “cajas negras” que cumplen una misión e intercambian información entre ellas, para acabar con la elaboración del diagrama de clases de diseño incluyendo detalles de los objetos que contribuyen al funcionamiento del sistema. Esta fase concluye con la entrega de un documento resumen en el que se exponen todos los detalles del diseño.

Implementación: En esta fase se implementa el sistema diseñado. La fase comienza

con el aprendizaje del lenguaje de programación con el que se va a implementar la aplicación. Una vez adquiridos los conocimientos básicos del lenguaje, se procede a escribir el código del programa. Esta fase concluye con la entrega del código elaborado.

Evaluación: En esta fase se elabora un protocolo de pruebas, que determina las

pruebas a las que se va a someter al sistema para comprobar su correcto funcionamiento. Esta fase concluye con la entrega de un documento resumen en el que se exponen las pruebas realizadas, los resultados esperados y los resultados obtenidos.

Documentación: En esta fase se elabora la memoria del proyecto, en la que se

presentan todos los aspectos relacionados con el desarrollo del proyecto desde que se propone hasta que finaliza. Concluye con la entrega de dicha memoria.

Divulgación: A lo largo de esta fase se va a preparar una presentación de unos 30

minutos aproximadamente en la que se describen de forma resumida los aspectos más importantes de la elaboración de este proyecto. Se elaboran transparencias para apoyar la exposición. La fase y el desarrollo de este proyecto concluyen con la exposición del resultado.

Los paquetes de trabajo se cumplen de manera secuencial, iniciándose la ejecución de

cada uno tras la finalización del paquete anterior. Los períodos de tiempo dedicados a cada uno de los paquetes de trabajo descritos y su

duración son las expuestas en el diagrama de Gantt de la Figura 4.1. En la planificación, se han establecido sábados y domingos como días no laborables y como período de vacaciones desde el 19/12/2009 al 10/01/2010, que es el tiempo entre el final de la fase de diseño y el inicio de la fase de implementación. Durante el período que va del 15/10/2009 al 15/04/2010 se establece un tiempo diario de trabajo de 4 horas, mientras que para el período que va del 16/04/2010 al 12/07/2010 se establecen 8 horas de trabajo diario.

4.2 Estimación de costes

Planificación y costes 61

Figura 4.1

4.2 Estimación de costes En este apartado se presenta un presupuesto aproximado en el que se estima qué

recursos humanos y materiales son necesarios para el desarrollo de este proyecto y su coste asociado.

Los recursos materiales necesarios para el desarrollo del proyecto son escasos. Tan solo

es necesario un PC con Windows XP como sistema operativo y con las aplicaciones utilizadas en el desarrollo del proyecto instaladas. De todo el software utilizado, el único cuya licencia tiene un coste asociado es el sistema operativo. El resto de las herramientas utilizadas tienen licencia totalmente gratuita. En la Tabla 13 se presenta un presupuesto detallado de los recursos materiales.

Recurso Precio Ordenador PC 400 €

Licencia del sistema operativo Windows XP 90€ Licencia de las herramientas y aplicaciones utilizadas 0 €

TOTAL 490€

Además de los recursos materiales, en los costes asociados a cualquier proyecto

también hay que tener en cuenta los recursos humanos necesarios para el desarrollo del mismo. Para determinar el esfuerzo que requiere el desarrollo de este proyecto, se hace una estimación en base al “modelo constructivo de costes” (COnstructive COst MOdel, COCOMO).



El modelo COCOMO es un modelo matemático de base empírica utilizado para la estimación de costes de software. Este modelo es ampliamente utilizado en la estimación de costes de proyectos software. De los submodelos existentes del modelo COCOMO, se opta por el modelo de estimación básico, indicado para proyectos pequeños y medianos. A su vez, existen varios modos del modelo COCOMO que representan el tipo de proyecto. De entre los existentes, se escoge el modo orgánico, que está indicado para el software desarrollado por “un pequeño grupo de programadores experimentados en un entorno familiar. El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio)” [6].

La ecuación de estimación del esfuerzo de desarrollo tiene la forma:

· ·

(15)

donde:

• ai es un coeficiente COCOMO que para el modelo básico orgánico tiene un valor de 2.4.

• S es el número de miles de líneas de líneas de código fuente estimados para la aplicación, que para esta aplicación se estima que es 1.5.

• bi es un coeficiente COCOMO que para el modelo básico orgánico tiene un valor de 1.05.

• m(X) es un coeficiente multiplicador que depende de 15 atributos y que para el modelo básico orgánico tiene un valor de 1.

• Km es el esfuerzo medido en personas/mes.

Para la estimación del tiempo de desarrollo, el modo orgánico del modelo COCOMO básico se basa en la siguiente fórmula:

2.5 · .

(16)

donde td es el tiempo de desarrollo en meses. Por lo tanto, considerando estos datos y la fórmula del modelo (15), se estima que el

proyecto desarrollado requerirá un esfuerzo humano de:

2.4 · 1.5 . 3,7 personas/mes

(17)

y que el tiempo de desarrollo será:

2.5 · 3.7 . 4,1 meses (18)

Para la realización de este proyecto, se ha necesitado el trabajo de tan solo 2 personas.

Con el propósito de dar un valor económico al trabajo realizado, se estima que el trabajo llevado a cabo por cada miembro del grupo tiene un coste de 15 €/hora. Por lo tanto, si se

4.2 Estimación de costes

Planificación y costes 63

tienen en cuenta que en el número de horas comentado en el Apartado 4.1 está incluido el trabajo de ambos miembros del equipo, el precio total de los recursos humanos es de: 1010 horas x 15€/hora = 15150 €.

Además de los recursos mencionados hasta ahora, es importante también tener en

cuenta el coste del material fungible, es decir, de la impresión y encuadernación de este documento, que está en torno a los 200 €.

En conclusión el coste total de desarrollo de este proyecto es de 15850 € y el tiempo

total invertido es de 9 meses (1010 horas).

65

CAPÍTULO 5. Diseño

Tras haber descrito qué se va a hacer en este proyecto, en este capítulo se va a describir

cómo hacerlo, utilizando como base el análisis llevado a cabo en el Apartado 3.2. Se van a abordar los aspectos más importantes del diseño de la aplicación.

Primeramente, se presenta una aproximación a lo que será la interfaz gráfica de la

aplicación, mostrando los bocetos de las ventanas que se mostrarán. A continuación, se describen casos de uso reales, identificando las asociaciones correspondientes con la interfaz gráfica. Por último, se expone la arquitectura propuesta para el sistema y se profundizará en su estructura.

5.1 Bocetos interfaz gráfica En este apartado se muestran los bocetos de las ventanas diseñadas para la interacción

con el usuario, a los cuales se hará referencia en el Apartado 5.2. En concreto, se muestran los siguientes bocetos:

• Ventana principal (Figura 5.1)

• Ventana de introducción de parámetros (Figura 5.2)

• Ventana de estado de análisis (Figura 5.3)

• Ventana de informe de dominio (Figura 5.4)

• Ventana de error (Figura 5.5)


66 Diseño

Análisis Opciones BD

Iniciar Detener

Línea Archivo Emails o webs

Consultar Borrar

IMAGEN DE FONDO

Figura 5.1

Fuente LÍNEA DE TEXTO PARA ESCRIBIR FUENTE

Número de

dominios a monitorizar

Número de dominios a detectar

Tiempo máximo de

monitorización

Tiempo máximo de detección

NÚMERO NÚMERO NÚMERO NÚMERO

BOTÓN OK

Figura 5.2

DOMINIO ESTADO DEL ANÁLISIS Dominio 1 Dominio 2 Dominio 3 Dominio 4 … … … … … … … … Dominio n

Estado dominio 1 Estado dominio 2 Estado dominio 3 Estado dominio 4 Estado dominio n

Figura 5.3

5.2 Casos de uso reales

Diseño 67

DATO VALORDato 1 Dato2 Dato 3 … … … Dato n

Valor dato 1 Valor dato 2 Valor dato 3 … … … Valor dato n

Figura 5.4

MENSAJE DE ERROR

ICONO ERROR

BOTÓN OK

Figura 5.5

5.2 Casos de uso reales Un caso de uso real describe el diseño real del caso de uso según una tecnología

concreta de entrada y de salida y su implementación. En este apartado se van a describir los casos de uso reales, asociando cada caso a una o

varias ventanas de la interfaz gráfica esbozadas en el Apartado 5.1. Además de los casos de uso vistos hasta el momento, se van a incluir dos nuevos casos

de uso que no han sido descritos hasta ahora por no tener demasiada relevancia en la descripción de las operaciones básicas del programa. Estos casos de uso son Detener análisis y Borrar base de datos.

Para la descripción de los casos de uso reales, se expondrán solamente el curso típico

de eventos y los cursos alternativos, obviando el resto de elementos que los componen por ser iguales a los expuestos en el Apartado 3.2.1.2.


68 Diseño

5.2.1 Introducir parámetros Curso típico de eventos:

Acción del actor Respuesta del sistema 1. Inicia el programa.

2. Muestra la ventana principal (Figura 5.1).

3. En la ventana mostrada, hace click sobre la opción “Análisis” “Iniciar” y selecciona una de las opciones del submenú que aparece (“Línea”, “Archivo”, “Emails o webs”).

4. Muestra la ventana de introducción de datos (Figura 5.2).

5. Introduce en la ventana mostrada los nombres de dominio o la ruta de la fuente en la línea de texto (según la opción escogida en el paso 3), introduce en las casillas correspondientes los parámetros deseados para el análisis y pulsa “OK”.

6. Procesa los datos introducidos por el usuario, extrae los dominios de la fuente, inicia el análisis y destruye la ventana de introducción de datos.

7. Muestra la ventana de estado del análisis (Figura 5.3), escribiendo la palabra “Esperando monitorización” en el estado del análisis de todos los dominios de la lista.

8. Pasa al caso de uso 2.


• Línea 6: No se han extraido URLs. Se cancela la operación.

• Línea 6: El archivo o la ruta especificada no existe o no se puede abrir. El sistema muestra al usuario una ventana de error (Figura 5.5) con el mensaje de error que corresponda en cada caso. Tras pulsar OK el usuario, el sistema destruye la ventana de error y sigue operando normalmente.

5.2.2 Obtener características Curso típico de eventos:

Acción del actor 1 Respuesta del sistema Acción del actor 2 1. Escoge un nombre de


Diseño 69

dominio de la lista. 2. Envía a la base de datos

SQLite una sentencia Select del lenguaje SQL para obtener datos sobre el dominio.

3. Responde al sistema: o Si contiene los datos,

ver sección Sí contiene.

o Si no contiene los datos, continuar en esta sección.

4. Cambia el estado del análisis del dominio a “Monitorizando”.

5. Envía al servidor DNS sobre el protocolo TCP/IP un mensaje de petición de información.

6. Responde a la petición, que contendrá un conjunto de registros y un código de respuesta (reply code).

7. Extrae el reply code, el valor del registro y su TTL

asociado en caso de que el registro esté presente en el mensaje.

8. o Si el reply code muestra

que hay error: ver sección Error en la respuesta.

o Si no ha transcurrido el tiempo máximo de análisis: tras el tiempo indicado en el campo TTL de la respuesta, se vuelve al paso 5.

o Si ha transcurrido el tiempo máximo de análisis: ver sección Tiempo cumplido.

• Sección Sí contiene:

Acción del actor 2 Respuesta del sistema 1. Devuelve una lista con los datos sobre

el dominio al sistema.


70 Diseño

2. Cambia el estado del análisis del dominio a “Finalizado (analizado previamente)”.

• Sección Error en la respuesta:

Acción del actor 2 Respuesta del sistema 1. Cambia el estado del análisis del

dominio a “Escribiendo BD”. 2. Envía a la base de datos una sentencia

SQL con el comando Insert y los datos recogidos (si los hay), incluyendo el reply code, para que sean almacenados.

3. Almacena los datos. 4. Finaliza el análisis del dominio.

• Sección Tiempo cumplido:

Acción del actor 2 Respuesta del sistema 1. Cambia el estado del análisis del

dominio a “Escribiendo BD”. 2. Envía a la base de datos una sentencia

SQL con el comando Insert y los datos recogidos.

3. Almacena los datos. 4. Pasa al caso de uso 3.


• Línea 6, sección Principal: El servidor no responde. Se realizan 3 intentos y si sigue sin responder, se registra en la BD y finaliza el análisis del dominio.

5.2.3 Detectar Curso típico de eventos:

Acción del actor Respuesta del sistema 1. Cambia el estado del análisis del

dominio a “Detectando”. 2. Envía a la base de datos una sentencia

Select para recuperar los datos de las columnas de interés para la detección.

3. Devuelve una lista con los datos recogidos sobre el dominio.

4. Ejecuta el algoritmo de detección.


Diseño 71

5. Cambia el estado del análisis del dominio a “Actualizando BD”.

6. Envía a la base de datos una sentencia Update para incluir el resultado en la fila correspondiente.

7. Almacena el resultado del algoritmo. 8. Cambia el estado del análisis del

dominio a “Finalizado”.


• Línea 4: No existen datos suficientes para la ejecución del algoritmo. Se escribe una línea vacía en la probabilidad calculada en la BD y el análisis finaliza.

5.2.4 Generar informe Curso típico de eventos:

Acción del actor 1 Respuesta del sistema Acción del actor 2 1. En la ventana principal,

hace click sobre la opción “Opciones BD”

“Consultar”.

2. Envía una sentencia Select a la base de datos pidiendo todos los nombres de dominio registrados.

3. Devuelve la lista con los nombres de dominio.

4. Muestra la ventana de estado del análisis (Figura 5.3) conteniendo los dominios y con el estado “Finalizado (analizado previamente)”.

5. Hace doble click sobre un nombre de la lista.

6. Envía una sentencia Select a la base de datos pidiendo los datos sobre el nombre de dominio elegido.

7. Devuelve los datos correspondientes al dominio elegido.


72 Diseño

8. Muestra la ventana de informe sobre un dominio (Figura 5.4) conteniendo los datos sobre el dominio elegido.

5.2.5 Otros casos de uso A continuación se describen dos nuevos casos de uso: Detener análisis y Borrar base de

datos. Ambos casos se van a describir muy brevemente.

Detener análisis: La idea de este caso de uso es detener todas las operaciones de análisis activas. El usuario selecciona en la ventana principal (Figura 5.1) la opción “Análisis” “Detener”. El sistema detiene todas las operaciones de análisis que se estén llevando a cabo en ese momento.

Borrar base de datos: La idea de este caso de uso es eliminar las tablas de la base de

datos. El usuario selecciona en la ventana principal (Figura 5.1) la opción “Opciones BD” “Borrar”. El sistema envía una sentencia SQL con el comando Delete para eliminar la tabla o tablas que contiene.

5.3 Arquitectura propuesta En este apartado se presentan todos los detalles del diseño de la aplicación, partiendo

de una visión muy general del mismo hasta llegar a los aspectos más específicos del diseño del software.

Se comienza describiendo el sistema a nivel de componentes de alto nivel y se dan los

detalles sobre la estructura de la base de datos. A continuación, se da un paso más en la definición del sistema, describiendo la aplicación en términos de definiciones de objetos e interacciones entre ellos y con los actores, que dan lugar a la ejecución de las operaciones. Por último, se introduce un nuevo elemento en el sistema para aportar flexibilidad al mismo: el archivo de configuración.

5.3.1 Componentes del sistema El gráfico de la Figura 5.6 proporciona una idea general de la estructura del sistema. En

él se muestran los bloques que lo componen y el intercambio de información que se produce entre estos elementos y de ellos con los actores del sistema. A cada actor se le asocia un bloque que juega el papel de interfaz entre éste y el sistema.

5.3 Arquitectura propuesta

Diseño 73

Figura 5.6

Bloque interfaz de usuario Es el responsable de la comunicación del usuario con el sistema. Cuando el usuario

solicita iniciar un análisis e introduce los datos a través de sus ventanas, traslada al bloque de búsqueda la fuente que el usuario ha especificado, es decir, la referencia al texto o los archivos de los que se quieren extraer las URLs, y al bloque de control los parámetros del análisis, como pueden ser el tiempo máximo de análisis o el número de dominios a analizar simultáneamente. Por otra parte, si el usuario solicita ver el informe de algún dominio, será el encargado de entrar en contacto con el bloque interfaz BD para obtener los datos necesarios y mostrarlos al usuario.

Bloque de búsqueda Este bloque tendrá que hacer un procesado de la información contenida en la fuente

dependiendo de su tipología, con el fin de extraer los dominios contenidos en dicha fuente antes de pasarlos a la fase de análisis. El conjunto de dominios extraídos es trasladado al bloque de control. Conviene recordar que la fuente puede ser una línea de texto, un archivo de extensión txt o un directorio de emails o de páginas web.

Bloque de control Es el bloque central del programa. Es el encargado de coordinar, sincronizar y

temporizar todas las operaciones del sistema correspondientes a la recopilación de datos de los dominios (monitorización) y al análisis de dichos datos (detección). Desde este bloque se pasarán a los bloques monitores y a los bloques detectores los nombres de dominio a analizar y el tiempo máximo permitido para cada operación de monitorización. Además recibirá de


74 Diseño

sendos bloques datos y resultados, los cuales deberán ser comunicados al bloque de interfaz BD para su almacenamiento. También se harán llamadas a este último para comprobar si los dominios bajo sospecha han sido analizados previamente. A lo largo de todo el análisis, el bloque de control mantendrá informado al bloque interfaz de usuario sobre los datos del estado del mismo.

Bloques monitores Gestionan las peticiones de información que se llevan a cabo en la monitorización de un

dominio. Cada bloque monitor está destinado a la obtención de un tipo concreto de información. Durante el tiempo marcado por el bloque de control, cada uno de ellos se encargará de enviar mensajes al servidor de información cuando sea conveniente. En cada una de estos mensajes se incluirán algunos parámetros, como pueden ser el dominio sobre el que se solicita la información o el tipo de información que se desea consultar. Estos bloques son además responsables de la extracción de información de las respuestas que le sean transmitidas.

Los resultados obtenidos tras haber transcurrido el tiempo máximo permitido son

enviados al bloque de control. La razón por la que los datos no son enviados por los monitores directamente a la base de datos es para evitar que la base de datos reciba varias peticiones simultáneas de escritura, ya que puede dar lugar a errores.

Bloques detectores Analizan los datos recogidos por los bloques monitores para determinar la probabilidad

de que el dominio (previamente monitorizado) sea parte de una red fast‐flux. Para obtener dichos datos, cada bloque deberá dirigir, antes de iniciar la detección, una petición al bloque interfaz BD pidiendo la información registrada que sea necesaria para la detección sobre el dominio recibido del bloque de control. Una vez recibidos estos datos y determinada la probabilidad, envía los resultados obtenidos al bloque de control.

La razón por la que cada detector solicita los datos que necesita a la base de datos sin

apoyo del bloque de control es evitar que la operación de éste último se vea retrasada debido al tiempo que puede ocupar la lectura de datos. Además, como las operaciones de lectura no son tan delicadas como las de escritura, no hay ningún inconveniente en que la base de datos reciba varias peticiones de lectura simultáneamente.

Bloque interfaz base de datos Permite a los elementos del sistema interactuar con la base de datos. Se encarga de

traducir las órdenes enviadas por los distintos bloques del sistema a sentencias SQL que pueden ser interpretadas por el sistema de gestión de la base de datos y de adaptar los datos recibidos de ella para que puedan ser utilizados por estos bloques. Recibe peticiones


Diseño 75

de la interfaz de usuario cuando el usuario solicita un informe sobre algún dominio, de los bloques detectores cuando realizan la detección de un dominio y del bloque de control para que escriba los datos y resultados obtenidos en el análisis y para comprobar si un dominio ha sido analizado previamente o no.

5.3.1.1 Operaciones de los componentes Una vez presentados los bloques que componen el sistema, se va a presentar una

descripción de las operaciones que cada uno de ellos realiza.

Bloque interfaz de usuario Mostrar ventanas: El medio de comunicación entre el usuario y el sistema son las

ventanas. Mediante las ventanas, el sistema solicita al usuario la introducción de órdenes y de datos, le presenta resultados o le comunica posibles errores que pueden producirse durante la ejecución.

Interpretar órdenes del usuario: Es importante que cuando el usuario envía una orden

al sistema, éste sepa interpretarla correctamente para enviarla al bloque encargado de cumplirla. La interfaz de usuario es la encargada de traducir estas órdenes, como puede ser hacer click con el ratón sobre una opción del programa.

Leer datos introducidos por el usuario: Cuando el sistema muestra una ventana

solicitando datos al usuario y éste los introduce, la interfaz de usuario debe ser capaz de recoger estos datos y de convertirlos a tipos de datos propios del lenguaje de programación para poder operar con ellos.

Generar informes de resultados: La interfaz de usuario se encarga de mostrar al

usuario el informe del dominio que solicite, llevando a cabo las acciones oportunas para obtener los datos correspondientes al dominio que el usuario elige.

Bloque de búsqueda Abrir archivos: Cuando el bloque de búsqueda recibe la fuente que el usuario ha

elegido para obtener los nombres de dominio, el bloque de búsqueda debe tener la capacidad de abrir los archivos correspondientes en modo de lectura para poder procesarlos y cumplir su misión.

Procesar textos: El bloque de búsqueda debe procesar los textos contenidos en los

elementos de la fuente para poder así recopilar las URLs contenidas en ella. El tipo de procesamiento que se realiza depende del tipo de fuente elegida por el usuario, estableciendo en cada caso cómo identificar las URLs.


76 Diseño

Filtrar URLs: Como se ha comentado anteriormente, hay que distinguir entre una URL y un nombre de dominio (véase sección 1.1.1.2). El bloque de búsqueda no sólo tiene que recopilar las URLs contenidas en la fuente, sino que también debe extraer de cada URL el nombre de dominio correspondiente, que son los elementos a los que hay que someter a análisis.

Cerrar archivos: Una vez procesado el texto, el bloque debe liberar los recursos

utilizados para la lectura de los archivos correspondientes a la fuente.

Bloque de control Comprobar dominios: Tras recibir la lista de dominios del bloque de búsqueda, se debe

comprobar qué dominios de la lista han sido monitorizados previamente y cuáles no para así analizar solamente los dominios nuevos. Para ello se solicitan datos de la base de datos. Tanto la petición de datos como la clasificación corresponden al bloque de control.

Iniciar monitorización: El bloque de control tiene la responsabilidad de iniciar la

monitorización de cada dominio conforme sea posible. Cada vez que se desea iniciar la monitorización de un dominio, el bloque de control envía a cada bloque monitor del sistema el nombre de dominio y el tiempo máximo de operación.

Iniciar detección: Una vez ha terminado la monitorización de un dominio, el bloque de

control tiene que iniciar la detección de dicho dominio conforme sea posible. Cada vez que se desea iniciar la detección de un dominio, el bloque envía a cada bloque detector del sistema el nombre de dominio.

Detener operaciones: Si recibe la orden de detener el análisis o si se ha producido

algún error y un proceso de monitorización o de detección no ha terminado tras haber transcurrido el tiempo máximo de operación marcado, el bloque de control debe tener el privilegio de provocar la detención de cualquier operación de análisis activa.

Controlar estado del análisis: Con la intención de informar al usuario sobre la fase del

análisis en la que se encuentran los dominios de la lista, el bloque de control debe mantener y modificar un registro de cuál es el estado para cada nombre de dominio.

Gestionar datos y resultados: Cada vez que finaliza una operación de monitorización o

de detección, el bloque de control se encarga de recoger los datos y resultados obtenidos para pasarlos al bloque de interfaz BD, ordenando su almacenamiento en la BD.


Diseño 77

Bloques monitores Solicitar información: Los bloques monitores deben tener la capacidad de enviar

mensajes al servidor de información para pedir unos datos concretos sobre un dominio y de recibir la respuesta asociada a la petición.

Procesar respuesta: Las respuestas recibidas por un bloque monitor son mensajes completos, que incluyen una cabecera y un cuerpo con información útil. Cada uno de estos bloques deberá extraer del mensaje de respuesta los parámetros que sean necesarios, desechando el resto.

Controlar tiempo entre solicitudes: La información recibida del servidor de

información puede ser redundante si no se espera un tiempo determinado entre el envío de un mensaje de petición y del siguiente. Es por ello que el módulo monitor debe ser capaz de marcar el intervalo de tiempo entre peticiones.

Controlar tiempo de ejecución: Si ha transcurrido el tiempo máximo marcado por el

usuario, el bloque monitor debe detenerse sin necesidad de recibir ninguna orden del bloque de control. Esta es la razón por la que el tiempo máximo permitido es parámetro para los bloques monitores.

Bloques detectores Solicitar parámetros detección: Para poder ejecutar el algoritmo de detección, cada

bloque detector necesita datos sobre los dominios a detectar. De todos los datos obtenidos para un dominio, el bloque detector solamente solicita aquellos datos que el algoritmo implementado vaya a necesitar.

Detectar: Como ya se ha comentado, consiste en determinar la probabilidad de que el

dominio pertenezca a una red fast‐flux. Para obtener esta probabilidad, cada bloque detector implementará un algoritmo diferente.

Bloque interfaz base de datos Conectar y desconectar: Previamente a las operaciones sobre la base de datos, se

debe realizar una conexión a la misma para iniciar una sesión, comprobando que no existen errores físicos. En el caso del sistema diseñado, el inicio de sesión no se utiliza para autentificar al usuario puesto que el acceso no es restringido por contraseña. Para liberar recursos, se debe cerrar la sesión una vez se ha terminado de operar sobre ella.

Escribir datos: Para poder introducir registros en la base de datos, el bloque debe

enviar sentencias SQL al sistema de gestión de la base de datos, indicando qué datos se desean incluir y su ubicación.


78 Diseño

Leer datos: Para poder leer registros de la base de datos, el bloque debe enviar sentencias SQL al sistema de gestión de la base de datos indicando qué datos se desean leer y su ubicación.

Actualizar datos: Para poder actualizar registros en la base de datos, el bloque debe

enviar sentencias SQL al sistema de gestión de la base de datos indicando qué columnas de qué registros se desea actualizar.

Ejecutar operaciones de gestión: El sistema no solamente realiza operaciones sobre los

datos contenidos en las tablas, sino que también tiene que tener autoridad para gestionar el contenido mediante operaciones como crear una tabla, eliminarla o añadirle nuevas columnas.

5.3.2 Diseño de los bloques monitores Para los bloques monitores, se ha optado por un diseño que divide las funciones de la

monitorización en dos subbloques: el de procesamiento y el de interfaz con el servidor. Este diseño es el que se muestra en la Figura 5.7.

El subbloque de procesamiento está dedicado a la temporización del envío de

peticiones y al procesamiento de las respuestas obtenidas del servidor para la extracción de la información que convenga.

El subbloque de interfaz con el servidor incluye todas aquellas funciones relacionadas

con la creación de mensajes, su envío y la recepción de respuestas por parte del servidor al que se intenta acceder para obtener la información sobre el dominio.

Cuando el subbloque de procesamiento determina que debe realizarse una petición de

información sobre un dominio, envía al subbloque de interfaz con el servidor la información que desea obtener. Basándose en esta información, el subbloque de interfaz con el servidor construye el mensaje a enviar al servidor para obtener la información deseada. Tras enviar el mensaje, el servidor de información devuelve un mensaje de respuesta que debe ser recibido por el subbloque de interfaz con el servidor y procesado a continuación por el subbloque de procesamiento.

Como ejemplo, se considera el caso de la monitorización de registros DNS asociados a

un dominio. Cada bloque monitor se encarga de obtener un tipo de registro DNS concreto sobre los dominios y durante el tiempo que el bloque de control les pasa como parámetro. El subbloque de procesamiento realizará llamadas al subbloque de interfaz DNS cuando sea conveniente. En cada una de estas llamadas se incluirá el dominio sobre el que se solicita la información y el tipo de RR que se desea consultar.

El subbloque de interfaz DNS es el responsable de la comunicación de los bloques

monitores con el servidor DNS. En cada llamada por parte del subbloque de procesamiento,


Diseño 79

este bloque crea el mensaje correspondiente para obtener el registro del nombre de dominio y tipo recibidos como parámetros en la llamada y lo envía al servidor DNS. Una vez que este subbloque recibe la respuesta, la comunica al subbloque de procesamiento correspondiente para que éste procese la información recibida.

Hay que tener en cuenta que cuando se solicita un registro al servidor DNS, éste no

siempre devuelve el registro que se espera conseguir. En ese caso, el bloque dedicado a monitorizar un tipo de RR concreto debe ser capaz de utilizar el registro devuelto para tratar de conseguir el registro buscado.

Por ejemplo: se considera el caso de un bloque monitor que monitoriza los registros de

tipo A. Al solicitar al servidor DNS los registros tipo A correspondientes a un nombre de dominio, no recibe los registros solicitados, sino el registro CNAME, que contiene el nombre canónico del dominio sobre el que se pedía información. El subbloque de interfaz con el servidor DNS debe entonces volver a solicitar la información del registro tipo A, pero esta vez sustituyendo el nombre de dominio inicial por el nombre canónico extraído del registro CNAME. Es posible que de esta forma el servidor DNS devuelva los registros que se buscan.

Las respuestas recibidas por el subbloque de procesamiento son mensajes completos,

que incluyen cabecera y ninguno, uno o varios registros. Cada uno de estos subbloques deberá extraer del mensaje de respuesta los parámetros que sean necesarios, desechando el resto.

Para evitar recibir registros que se encuentren en la caché del servidor DNS, cada

bloque debe solicitar la información DNS dejando transcurrir el tiempo indicado en el TTL de la última respuesta recibida, tal y como se explicó en el Apartado 3.2.2.2.

Figura 5.7


80 Diseño

5.3.3 Estructura de la base de datos La estructura de la base de datos es muy simple: se utiliza una sola tabla, llamada

“fastflux”. Dispone por defecto de la columna nombre, de tipo texto, que es la que registra los nombres de dominio que se someten a análisis, e inicio, también de tipo texto, que registra la fecha de inicio de análisis de cada dominio.

El resto de columnas son dependientes de los bloques monitores y detectores

implementados en el sistema. Cada monitor y detector declarará en su implementación los nombres y tipos de las columnas que necesita incluir a la tabla definida para que se puedan registrar los datos que suministra. Es en la iniciación del objeto de Control cuando se añaden dichas columnas en el caso de que no se encuentren presentes en la tabla.

La base de datos es un archivo en el caso de esta aplicación. Para operar con ella, el

sistema debe conocer cuál es la ruta de este archivo. Esta ruta se registra, junto a otros datos, en un archivo de configuración (véase Apartado 0).

5.3.4 Diagrama de clases de diseño Una vez descritos los bloques fundamentales que componen el sistema y las

operaciones que realizan, en este apartado se presenta el diagrama de clases de diseño. Un diagrama de clases de diseño es un gráfico del lenguaje UML en el que se

representan las clases que intervienen en la aplicación, especificando los atributos y métodos de cada una de ellas y representando las relaciones establecidas entre ellas.

Las clases son declaraciones o abstracciones de objetos, lo que significa que una clase

es la definición de un objeto. Es contenedor de uno o más datos (atributos) junto a las operaciones de manipulación de dichos datos (métodos). Los atributos son características de los objetos, es decir, variables que registran los valores que definen al objeto. Los métodos son las operaciones que pueden realizarse sobre el objeto.

El diagrama de clases de diseño ha sido dividido en 2 partes. En la primera (Figura 5.8)

se presentan las clases del núcleo del sistema, entiendo por núcleo el conjunto de todos los bloques del sistema excluyendo el de la interfaz gráfica. En la segunda (Figura 5.9) se presentan las clases que componen la interfaz gráfica y las relaciones con el núcleo del sistema.

A continuación se procede a describir los atributos y métodos de todas las clases de

ambos diagramas, excepto de las clases de elementos gráficos (wx) ya que no han sido implementadas en este proyecto. Se comienza describiendo las clases correspondientes al núcleo del sistema y después se describen las correspondientes a la interfaz de usuario.


Diseño 81

Figura 5.8


82 Diseño

Figura 5.9

Clase Rastreador La clase Rastreador define objetos cuyos métodos están destinados a la extracción de

nombres de dominio de la fuente especificada por el usuario.

• Atributos

o tipo: Especifica el tipo de fuente, que puede ser línea, archivo o emails o webs.

o fuente: Si la fuente es línea, contiene el texto introducido por teclado; si es archivo, contiene la ruta completa del archivo; si es emails o webs, contiene la ruta del directorio que contiene los emails y las páginas web.

o dominios: Lista que almacena los nombres de dominio encontrados en la fuente.

o error: Almacena el string de error en caso de que exista devuelto por el sistema al producirse.

• Métodos

o procesarDominios: Es el método común a los 3 valores posibles del dato tipo. Recibe como parámetro la lista de URLs encontradas en la fuente y extrae los nombres de dominio contenidos en ella.


Diseño 83

o desglosar: Se utiliza solamente en el caso de que la fuente de dominios sea un directorio de emails y/o de páginas web. Recibe como entrada un correo y proporciona como salida dos listas: la primera contiene una lista de las distintas partes del correo o de la página en cuestión y la segunda el tipo asociado a cada parte de la primera.

o rastrear: Busca todas las URLs contenidas en la fuente. Las acciones necesarias para hacerlo serán distintas en función del tipo de fuente.

Clase BD La clase BD implementa objetos destinados a la utilización y gestión de la base de

datos.

• Atributos

o archivo: Es la ruta completa del archivo en el que está contenida la base de datos.

o con: Es el objeto asociado a la conexión a la base de datos.

o cursor: Es un objeto cursor de la base de datos. Un cursor es una estructura de control utilizada para el recorrido y procesamiento de los registros del resultado de una consulta a la base de datos.

• Métodos

o conectar: Se utiliza para iniciar una sesión con la base de datos incluida en el archivo especificado en el atributo archivo.

o anadirColumnas: Se utiliza para añadir nuevas columnas a la tabla de la base de

datos. Recibe como parámetro los nombres de las columnas con sus tipos asociados.

o crearTabla: Crea una nueva tabla en la base de datos.

o desconectar: Cierra la sesión con la base de datos.

o insertarDatos: El objetivo de este método es la creación de un nuevo registro en la tabla de la base de datos. Recibe como parámetros las columnas de la tabla y los datos que se quieren incluir en dichas columnas del registro.

o actualizarDatos: Este método se utiliza sobre registros de la base de datos que han

sido creados con anterioridad, para poder modificar datos o escribir datos nuevos en columnas vacías de un registro.


84 Diseño

o leerDatos: Ofrece la posibilidad de obtener registros de la base de datos. Recibe como parámetros las columnas que se quieren obtener y el criterio que cumplen los registros a recuperar.

o obtenerNombresColumnas: Este método devuelve una lista que contiene los

nombres de todas las columnas correspondientes a la tabla de la base de datos.

o borrarBD: Este método elimina los registros de la tabla de la base de datos.

Clase Temporizador La clase temporizador implementa objetos para la temporización de operaciones.

• Atributos

o tiempomax: Almacena el tiempo en segundos durante el cual el temporizador estará activo.

o inicio: Tiempo en el que se inicia el temporizador expresado en segundos desde el

origen de tiempos “Unix Epoch” (00:00:00 del 1 de Enero de 1970).

o fin: Tiempo en el que finaliza el temporizador expresado en segundos desde el origen de tiempos “Unix Epoch”.

• Métodos

o activar: En el momento en que se llama a este método, se marcan los valores de inicio y fin del temporizador.

o restante: Devuelve el tiempo que hay desde el momento en el que se llama al

método hasta el fin marcado para el temporizador.

o transcurrido: Devuelve el tiempo que ha transcurrido desde el inicio marcado para el temporizador hasta el momento en que se ha producido la llamada al método.

o dormir: Es el método utilizado para hacer que la hebra de ejecución que utilice el

objeto entre en estado de reposo durante el tiempo pasado como parámetro.

Clase KThread La clase KThread hereda de la clase Thread del módulo threading. Implementa hebras

de ejecución que pueden ser detenidas en cualquier momento de su ejecución mediante una


Diseño 85

llamada a uno de sus métodos. De esta clase, al no haber sido implementada dentro de este proyecto, se comentan solamente los atributos y métodos más importantes.

• Atributos

o killed: Indica si la hebra debe finalizar su ejecución o no.

• Métodos

o start: Es el método que inicia la ejecución de la hebra.

o kill: Es el método que detiene la ejecución de la hebra.

Clase Control La clase Control es la clase con más relevancia de este proyecto. Hereda de la clase

KThread. Implementa objetos que se encargan del control de las instancias de monitorización (monitores) y de las instancias de detección (detectores). Estos objetos se implementan como hebras de la clase KThread para poder interrumpir un análisis cuando el usuario lo desee.

• Atributos

o monitoresmax: Número máximo de dominios que se permite monitorizar simultáneamente.

o detectoresmax: Número máximo de dominios que se permite detectar

simultáneamente.

o montiempomax: Tiempo máximo que se permite para la monitorización de un dominio.

o dettiempomax: Tiempo máximo que se permite para la detección de un dominio.

o dominios: Lista que contiene los nombres de dominio a analizar.

o estado: Diccionario que contiene el estado del análisis para cada dominio.

o colamon: Objeto de la clase Python Queue. Es una cola que contiene los nombres de

dominio que esperan a ser monitorizados.

o coladet: Objeto de la clase Python Queue. Es una cola que contiene los nombres de dominio que esperan a ser detectados.


86 Diseño

o monitores: Atributo que contiene la lista de objetos monitores activos en cada momento y el tiempo restante permitido para cada uno de ellos.

o detectores: Atributo que contiene la lista de objetos detectores activos en cada

momento y el tiempo restante permitido para cada uno de ellos.

o objetoBD: Objeto para poder actuar sobre la base de datos.

• Métodos

o run: Es el método que se ejecuta cuando se invoca el método start de la clase KThread sobre la hebra de control. Lleva a cabo todas las operaciones de control sobre las instancias de monitorización (monitores) y las de detección (detectores). Estas operaciones se explicarán con detalle en el Apartado 5.3.5. Previamente a estas operaciones de control, si es necesario, se añaden nuevas columnas a la tabla de la BD o se crea la tabla de nuevo en el caso de que ésta no exista porque se haya borrado.

o introducirDominios: Método para añadir dominios a la lista de dominios para analizar.

o setMonitoresMax: Método de la clase para establecer el valor del atributo

monitoresmax.

o setDetectoresMax: Método de la clase para establecer el valor del atributo detectoresmax.

o setMonTiempoMax: Método de la clase para establecer el valor del atributo

montiempomax.

o setDetTiempoMax: Método de la clase para establecer el valor del atributo dettiempomax.

o introducirMonitores: Este método permite iniciar la monitorización de un dominio.

Inicia una instancia de cada objeto monitor definido en el sistema para cada nombre de dominio de la lista e introduce dichos objetos en la lista monitores junto a un contador descendente, que al llegar a 0 indicará que se ha cumplido el tiempo máximo para el monitor al que está asociado. Recibe como parámetros el dominio a monitorizar y el valor inicial de los contadores.

o extraerMonitores: Este método elimina de la lista monitores las instancias de las

clases de monitorización que han finalizado su operación. Recibe como parámetro las posiciones a eliminar.


Diseño 87

o introducirDetectores: Este método permite iniciar la detección de un dominio. Inicia una instancia de cada detector para cada nombre de dominio de la lista e introduce dichas instancias en la lista detectores junto a un contador descendente, que al llegar a 0 indicará que se ha cumplido el tiempo máximo para el detector al que está asociado. Recibe como parámetros el dominio a detectar y el valor inicial de los contadores.

o extraerDetectores: Este método elimina de la lista detectores las instancias de las

clases de detección que han finalizado su operación. Recibe como parámetro las posiciones a eliminar.

o actualizarTemporizadores: Este método decrementa el contador descendente

correspondiente a cada monitor y cada detector. En el caso de que al hacerlo alguno de los contadores haya llegado a 0, se procede a la detención de la operación del monitor o del detector al que está asociado el contador.

o suicidio: Es el método para interrumpir la ejecución de todas las instancias de monitorización y de detección activas y del propio objeto de control.

Clase Monitor La clase Monitor hereda de la clase KThread y a su vez es clase base de las clases que

implementan hebras destinadas a la monitorización de un dominio (monitores).Los monitores son iniciados y controlados por un objeto de la clase Control.

• Atributos

o nombredominio: Es el nombre de dominio que se monitoriza.

o temporizador: Objeto de la clase Temporizador. Marca el tiempo máximo de ejecución del monitor.

o fechainicio: Fecha y hora en la que la monitorización del dominio es iniciada.

o datos: Almacena los datos obtenidos de la monitorización.

• Métodos

o run: Método ejecutado por la hebra cuando se invoca al método start de la clase KThread sobre ella. Incluirá simplemente una llamada al método monitorizar.

o monitorizar: Método abstracto. Está destinado a la implementación de las tareas de monitorización de cada módulo monitor que hereda de la clase.


88 Diseño

Clase MonitorA La clase MonitorA hereda de la clase Monitor, con lo que son hebras controladas por un

objeto de la clase Control. Implementa los objetos monitores para los registros DNS de tipo A de los nombres de dominio a analizar. Los parámetros que recoge son necesarios para el algoritmo de detección de los dos detectores implementados en este proyecto.

• Atributos Esta clase contiene los mismos atributos de la clase Monitor, ya que hereda de ella.

• Métodos

o monitorizar: Se encarga de obtener la información de los registros A. Utiliza un objeto de la clase ConsultaDNSTipoA para pedir estos registros del dominio contenido en el atributo nombredominio. Este método controla el tiempo entre peticiones. Una vez se cumple el temporizador, almacena en el atributo datos el número de direcciones IP únicas encontradas en los registros devueltos y el TTL medio de éstos.

Clase MonitorNS La clase MonitorNS hereda de la clase Monitor, con lo que son hebras controladas por

un objeto de la clase Control. Implementa los objetos monitores para los registros DNS de tipo NS de los nombres de dominio a analizar. Los parámetros que recoge son necesarios para el algoritmo del detector exponencial que ha sido implementado en este proyecto.


• Métodos

o monitorizar: Se encarga de obtener la información referente a los registros NS del dominio contenido en nombredominio. Este método controla el tiempo entre peticiones, las cuales se traducen en llamadas al método solicitudNS de la clase. Una vez se cumple el temporizador, almacena en el atributo datos el número de direcciones IP únicas encontradas en los registros devueltos y el TTL medio de éstos.

o solicitudNS: Ordena el envío de peticiones DNS para obtener los registros de tipo A

asociados a los servidores de nombres autoridad del dominio pasado como


Diseño 89

parámetro. Deberá implementarse de forma que se obtenga la información buscada aunque el servidor DNS responda con registros que no son los que se han pedido.

Clase MonitorASN La clase MonitorASN hereda de la clase Monitor, con lo que son hebras controladas por

un objeto de la clase Control. Implementa los objetos monitores para los números de sistema autónomo (ASN) de las direcciones IP devueltas en los registros DNS tipo A. El número de ASNs únicos es uno de los parámetros necesarios para detectar un dominio aplicando la fórmula de Mannheim, la cual utiliza uno de los detectores incluidos en este proyecto.


• Métodos

o monitorizar: Este método realiza peticiones de los registros DNS de tipo A de la misma forma que los objetos de la clase MonitorA, con la diferencia de que para cada IP devuelta en estos registros se realiza una petición para obtener el ASN asociado a la dirección IP. Una vez se cumple el temporizador, almacena en el atributo datos el número de ASNs únicos obtenidos para el dominio.

Clase ConsultaDNSTipoA La clase ConsultaDNSTipoA implementa objetos destinados exclusivamente a realizar

consultas de registros de tipo A sobre nombres de dominio. Esta clase recibe llamadas de las clases MonitorA, MonitorNS y MonitorASN, sirviéndoles como herramienta para comunicarse con el servidor DNS y obtener así la información que buscan.

• Atributos Esta clase no tiene atributos.

• Métodos

o solicitudA: Ordena el envío de peticiones DNS para obtener los registros de tipo A asociados al nombre pasado como parámetro. Deberá implementarse de forma que se obtenga la información buscada aunque el servidor DNS responda con registros que no son los deseados.


90 Diseño

Clase Detector La clase Detector hereda de la clase KThread y a su vez es clase base de las clases que

implementan hebras destinadas a la detección de un dominio (detectores).Los detectores son iniciados y controlados por un objeto de la clase Control.

• Atributos

o nombredominio: Es el nombre de dominio que se detecta.

o datos: Almacena los resultados obtenidos de la detección.

o listaparametros: Es una lista con los nombres de las columnas de la base de datos que contienen los datos necesarios para la detección.

o parametros: Lista de valores de los parámetros para la detección.

o objetoBD: Objeto para poder actuar sobre la base de datos.

• Métodos

o run: Método ejecutado por la hebra cuando se invoca al método start de la clase KThread sobre ella. Incluirá una llamada al método obtenerParametros para obtener los parámetros necesarios en la detección y otra al método detectar para ejecutar el algoritmo de detección que corresponda.

o detectar: Método abstracto. Está destinado a la implementación del algoritmo de

detección de cada módulo detector que hereda de la clase.

o obtenerParametros: Accede a la base de datos para obtener los parámetros necesarios para la detección. Los parámetros leídos dependerán del valor del atributo listaparametros.

Clase DetectorExponencial La clase DetectorExponencial hereda de la clase Detector, con lo que son hebras

controladas por un objeto de la clase Control. Implementa un detector cuyo algoritmo es de forma exponencial.

• Atributos Esta clase contiene los atributos de la clase Monitor, ya que hereda de ella.


Diseño 91

• Métodos

detectar: Implementa el algoritmo de detección exponencial. La fórmula utilizada para la detección es:

1·

·

(19)

Esta fórmula ha sido obtenida a partir de los datos dados en [7], obtenidos sobre un conjunto de 215 dominios fast‐flux en 3 horas de análisis. El primer término será mayor cuanto mayor sea el número de registros tipo A asociados al dominio. El segundo término será más alto cuando menor sea el TTL medio asociado a los registros de tipo A.

Clase DetectorMannheim La clase DetectorMannheim hereda de la clase Detector, con lo que son hebras

controladas por un objeto de la clase Control. Implementa un detector utilizando la fórmula de Mannheim (Ecuación 4).

• Atributos Esta clase contiene los atributos de la clase Monitor, ya que hereda de ella.

• Métodos

o detectar: Implementa la fórmula de Mannheim.

Clase MainWindow La clase MainWindow hereda de wx.Frame. Es la clase que define el objeto de la

ventana principal de la aplicación (véase Figura 5.1).

• Atributos

o objetoControl: Es el objeto de la clase Control que va a sincronizar las operaciones de monitorización y detección.

o objetoBD: Objeto de la clase BD para el acceso y gestión de la base de datos.


92 Diseño

• Métodos

o rellenar: Es el método que introduce los elementos gráficos en el frame y a continuación lo muestra.

o onLinea: Se ejecuta cuando el usuario elige la opción “Análisis Iniciar Línea”. Provoca la aparición de una ventana de la clase DominioWindow.

o onTxt: Se ejecuta cuando el usuario elige la opción “Análisis Iniciar Archivo”. Provoca la aparición de una ventana de la clase DominioWindow.

o onEmails: Se ejecuta cuando el usuario elige la opción “Análisis Iniciar Emails”. Provoca la aparición de una ventana de la clase DominioWindow.

o onDetener: Se ejecuta cuando el usuario elige la opción “Análisis Detener”. Ejecuta el método suicidio() sobre la hebra de control activa.

o onConsultar: Se ejecuta cuando el usuario elige la opción “Opciones BD Consultar”. Se encarga de mostrar al usuario los nombres de dominio registrados en la base de datos y de mostrarle el informe del dominio que elija.

o onReiniciar: Se ejecuta cuando el usuario elige la opción “Opciones BD Reiniciar”. Realiza una llamada al método borrarBD() sobre el atributo objetoBD para eliminar la tabla de la base de datos.

o iniciarControl: Recibe como entrada los parámetros del análisis y los dominios a analizar. Inicia la ejecución de la hebra de control objetoControl con los parámetros especificados.

Clase DominioWindow La clase DominioWindow hereda de wx.Frame. Es la clase que define el objeto de la

ventana de introducción de parámetros de la aplicación (véase Figura 5.2).

• Atributos

o parent: Objeto de la clase MainWindow. Es utilizado para poder realizar operaciones sobre sus atributos y métodos.

o tipo: Registra el tipo de fuente elegida para la búsqueda de dominios. Puede tomar los valores “Linea”, “Txt” o “Emails”.

o color: Almacena el color de la ventana.


Diseño 93

• Métodos

o rellenar: Es el método que introduce los elementos gráficos en el frame y a continuación lo muestra. Si el tipo de fuente es “Txt” o “Emails”, la ventana contendrá un botón “Examinar” además de los elementos del boceto 5.2. Además, cada tipo de fuente tendrá asociado un color distinto de ventana.

o onOk: Se ejecuta cuando el usuario pulsa el botón “OK”. Procesa los datos introducidos en la ventana. Con estos datos, ordena la obtención de nombres de dominio, el inicio de una hebra de control y la creación de una ventana de estado de análisis.

o onCancel: Se ejecuta cuando el usuario pulsa el botón “Cancelar”. Simplemente cierra la ventana que implementa.

o onExaminar: Se ejecuta cuando el usuario pulsa el botón “Examinar” en el caso de que el tipo sea “Txt” o “Emails”. Al hacer click, se abrirá un diálogo estándar para la elección del archivo o directorio de la fuente.

Clase AnalizandoWindow La clase AnalizandoWindow hereda de wx.Frame. Es la clase que define el objeto de la

ventana de estado de análisis de la aplicación (véase Figura 5.3).

• Atributos

o parent: Objeto de la clase MainWindow. Es utilizado para poder realizar operaciones sobre sus atributos y métodos.

o lista: Objeto de la clase wx.ListCtrl. Es un elemento gráfico que introduce en el frame una lista de elementos con varias filas y columnas.

o dominios: Lista de los nombres de dominio presentes en la sesión de análisis activa.

o timer: Objeto de la clase wx.Timer. Implementa temporizadores que al cumplirse ejecutan una acción concreta y se reinician automáticamente.

• Métodos

o onItem: Se ejecuta al hacer doble click sobre alguno de los nombres de dominio mostrados. Muestra un informe del dominio elegido en una ventana de la clase InformeWindow.


94 Diseño

o onTimer: Se ejecuta cuando se cumple el temporizador timer. Refresca los contenidos de la ventana.

o actualizar: Actualiza los atributos dominios y lista.

Clase InformeWindow La clase InformeWindow hereda de wx.Frame. Es la clase que define el objeto de la

ventana de informe sobre un dominio (véase Figura 5.4).

• Atributos

o columnas: Lista que contiene los nombres de los parámetros que se muestran.

o datos: Lista que contiene los valores de los parámetros que se muestran.

o lista: Es un elemento gráfico que introduce en el frame una lista de elementos con varias filas y columnas.

• Métodos

o rellenar: Es el método que introduce los elementos gráficos en el frame y a continuación lo muestra.

Clase ErrorDialog La clase ErrorWindow define el objeto de la ventana de error (véase Figura 5.5).

• Atributos

o dlg: Objeto de la clase wx.MessageDialog, que implementa ventanas con mensajes de error.

5.3.5 Interacciones En el Apartado 5.3.4 se han expuesto cuáles son las clases que componen el sistema,

detallando cuáles son sus atributos y métodos. En este apartado se presenta cómo interactúan los distintos objetos definidos en estas clases para hacer que la aplicación lleve a cabo su cometido utilizando diagramas de secuencia.


Diseño 95

En la Figura 5.10 se detallan las relaciones mantenidas entre objetos previas al inicio de un análisis sobre una lista de dominios.

La operación comienza cuando el usuario hace click sobre una de las opciones de

análisis disponibles, produciéndose una llamada al método onDominio(), onTxt() u onEmails() de la clase MainWindow. En ese momento, el objeto de la clase MainWindow mostrará una ventana de introducción de parámetros (objeto DominioWindow). Cuando el usuario introduce los parámetros y pulsa el botón OK, realiza una llamada al método onOK() del objeto DominioWindow, iniciando éste la búsqueda de nombres de dominio en la fuente llamando al método rastrear() del objeto Rastreador. Una vez se han obtenido la lista con los dominios, el objeto DominioWindow ejecuta el método iniciarControl con los parámetros elegidos por el usuario. En esta llamada, la instancia de MainWindow ejecutará los métodos set del objeto de control creado para establecer los parámetros del análisis (omitidos en el gráfico) y a continuación ejecuta el método start para iniciar el análisis. Tras esto, el mismo objeto de MainWindow mostrará una ventana de análisis (instancia de AnalizandoWindow) donde se podrá seguir el estado del proceso y consultar los resultados.

Para la explicación de cómo se lleva a cabo el análisis no se va a utilizar un diagrama de

secuencia, puesto que en este proceso se realizan operaciones sobre varias instancias de diversas clases de forma concurrente y las llamadas en los diagramas de secuencia se colocan en orden cronológico.

La estructura y el proceso seguidos por el módulo de control para analizar una lista de

dominios son los que se pueden observar en la Figura 5.11. En el gráfico, se ha llamado controlador al conjunto de acciones llevadas a cabo por el objeto de control para guiar el análisis. Es el motor del proceso seguido por la aplicación desde que se dispone de la lista de nombres de dominio hasta que se registran los resultados de la detección de estos dominios en la base de datos. En la implementación, se corresponde con las acciones llevadas a cabo por el método run() del objeto de control.

Figura 5.10


96 Diseño

Figura 5.11 Antes de iniciar el análisis, el controlador compara la lista de dominios para analizar con

la lista de dominios registrados hasta el momento en la base de datos, dejando fuera del análisis los dominios que se encuentren en ambas listas para evitar repeticiones innecesarias. Estos dominios aparecerán en la ventana de estado de análisis con el estado “Finalizado (analizado previamente)”.

Los pasos seguidos por la hebra de control en su ejecución son los siguientes:

Paso 1: Lo primero que hace el objeto de control es introducir en la cola colamon todos los nombres de dominio de la lista de dominios a analizar junto al tiempo máximo de monitorización permitido para cada uno.

Paso 2: Se inicia la monitorización de tantos dominios incluidos en la cola colamon

como indique el atributo monitoresmax del objeto de control, creando para cada uno de ellos una instancia de cada clase de monitorización del sistema y llamando al método start() sobre cada una de ellas para que las hebras de ejecución comiencen a operar. Cada hebra monitor en funcionamiento se incluye en la lista monitores junto al tiempo máximo de monitorización permitido.

Paso 3: El controlador comprueba cada cierto tiempo si alguno de los conjuntos de

monitores activos para cada dominio ha finalizado su ejecución o si ha superado el tiempo permitido. En cualquier caso, el controlador recoge los datos obtenidos por los elementos del conjunto o conjuntos en cuestión, elimina de la lista monitores todos los monitores asociados e inicia la monitorización de nuevos dominios de la lista de la misma forma que en el paso anterior, tantos como se hayan eliminado en la comprobación.


Diseño 97

Paso 4: El controlador pasa al objeto de la clase BD los datos obtenidos de los monitores que han acabado para que los incluya en un nuevo registro, llamando al método introducirDatos() del objeto BD.

Paso 5: El controlador introduce en la cola de detectores (atributo coladet) los

nombres de dominio ya monitorizados junto al tiempo máximo de detección especificado en dettiempomax.

Paso 6: El controlador inicia la detección de tantos dominios de la cola coladet como

especifique el atributo detectoresmax, creando para cada uno de ellos una instancia de cada clase de detección del sistema y llamando al método start() sobre cada una de ellas para que las hebras de ejecución comiencen a operar. Cada hebra detector en funcionamiento se incluye en la lista detectores junto al tiempo máximo de detección permitido por dominio (dettiempomax).

Paso 7: El controlador comprueba cada cierto tiempo si alguno de los conjuntos de

detectores activos para cada dominio ha finalizado su ejecución o si ha superado el tiempo permitido. En cualquier caso, el controlador recoge los datos obtenidos por los elementos del conjunto o conjuntos en cuestión, elimina de la lista detectores todos los detectores asociados e inicia la detección de nuevos dominios de la cola coladet de la misma forma que en el paso anterior, tantos como se hayan eliminado en la última comprobación.

Paso 8: El controlador pasa al objeto de la clase BD los datos obtenidos de los

detectores que han acabado para que los incluya en el registro del dominio correspondiente, mediante una llamada al método actualizarDatos() del objeto BD.

La ejecución de la hebra de control finaliza cuando el último dominio de la lista de

dominios inicial es analizado o cuando el usuario solicita detener el análisis, en cuyo caso el módulo de control detendrá todas las instancias de monitorización y detección activas y finalizará su ejecución. Este proceso se representa en la Figura 5.12.

La acción para reiniciar la base de datos es la de la Figura 5.13. Cuando el usuario hace

click sobre la operación de reinicio de la base de datos, invoca el método onBorrar() de la clase MainWindow. Esta llamada incluye otra llamada al método borrarBD() del objeto BD, que elimina todos los registros de la tabla de la BD.

La operación de consulta de la base de datos conlleva las interacciones representadas

en la Figura 5.14. Cuando el usuario hace click sobre la opción de consulta de base de datos, realiza una llamada al método onConsultar() de la clase MainWindow. Es entonces cuando el objeto de MainWindow inicia una sesión con la base de datos mediante una llamada a conectar del objeto BD, llama al método leerDatos() con los parámetros necesarios para obtener solamente los datos incluidos en la columna de nombres de dominio y desconecta invocando desconectar().


98 Diseño

A continuación, el objeto MainWindow inicia un objeto de control pasando como parámetro el conjunto de nombres de dominio devuelto por la base de datos. El resto de parámetros pueden tomar cualquier valor, puesto que no se va a iniciar ningún monitor ni detector por estar presentes todos los dominios en la base de datos. Se inicia también una instancia de la clase AnalizandoWindow, en la que se mostrarán todos los nombres de dominio con el estado “Finalizado (analizado previamente)”, por lo que la hebra de control finaliza su ejecución.

Cuando el usuario hace doble click sobre alguno de los dominios invoca el método

onItem() y el objeto de AnalizandoWindow procede a conectar a la base de datos (método conectar()), leer los datos del registro asociado al nombre elegido (método leerDatos(parámetros)) y cerrar la sesión con la base de datos (método desconectar()). Obtenidos los datos, se muestra al usuario un objeto de la clase InformeWindow que incluye los datos del dominio elegido.

Figura 5.12

Figura 5.13


Diseño 99

Figura 5.14


100 Diseño

101

CAPÍTULO 6. Implementación

El objetivo de este proyecto no es solamente diseñar la aplicación, sino también

implementarla. En este capítulo se exponen los conceptos y detalles fundamentales relacionados con la implementación de la aplicación.

El lenguaje de programación utilizado para la implementación del sistema es Python,

del cual se comentan algunos aspectos en el primer apartado. A continuación se expone la forma en la que el código está estructurado. Por último, se describen las herramientas externas complementarias utilizadas en esta fase.

6.1 Estructura del código El lenguaje Python es un lenguaje orientado a objetos que proporciona al programador

formas de estructuración del código con el propósito de facilitar el mantenimiento y la lectura de programas demasiado largos. Estas estructuras son los módulos y los paquetes.

Los módulos son entidades de organización y división lógica del código.

Específicamente, un módulo es un fichero que contiene definiciones y sentencias de Python. El nombre del fichero es el nombre del módulo con el sufijo .py. Las definiciones de un módulo se pueden importar a otros módulos utilizando la sentencia import.

Los paquetes son entidades destinadas a la organización de módulos. Específicamente,

un paquete es un directorio que contiene módulos Python. Los paquetes almacenan módulos con características comunes a determinar por el programador, además del módulo __init__.py.

Los módulos __init__.py son necesarios para que Python trate los directorios como

contenedores de paquetes. Se hace así para evitar que los directorios con nombres comunes


102 Implementación

oculten accidentalmente módulos válidos que aparezcan más tarde en el camino de búsqueda del intérprete. En el caso más sencillo, __init__.py puede ser un fichero vacío, pero también puede ejecutar código de inicialización del paquete o actualizar la variable __all__.

La variable __all__ es una lista que recoge los módulos a importar de un paquete

cuando se ejecuta la sentencia from paquete import *, donde paquete es el nombre del paquete que se desea importar.

El código de la aplicación está organizado de la forma expuesta en la Figura 6.1. En los

subapartados que siguen se describe qué contiene cada módulo del programa.

Programa/

Detectores/ __init__.py Detector.py DetectorExponencial.py DetectorMannheim.py

Monitores/

__init__.py Monitor.py MonitorA.py MonitorASN.py MonitorNS.py

DNS/

__init__.py Base.py Class.py ConsultaDNSTipoA.py Lazy.py Lib.py OpCode.py Status.py Type.py Win32dns.py

BD.py Control.py GUI.py KThread.py Rastreador.py Temporizador.py

Figura 6.1

6.1 Estructura del código

Implementación 103

6.1.1 Paquete Detectores El módulo __init__.py contiene el código necesario para que los módulos de detección

referenciados en el archivo de configuración sean importados al sistema y automáticamente tenidos en cuenta por la hebra de control en el proceso de detección de los dominios. Para ello, abre el archivo de configuración, lee la parte correspondiente a los detectores y almacena los nombres en la variable __all__ del paquete. De esta forma, cuando se ejecute la sentencia from Detectores import * en el módulo de control, todos los módulos nombrados en la lista __all__ pasarán automáticamente a formar parte del sistema.

El módulo Detector.py incluye la definición de la clase Detector, que es la clase de la

que heredan todos los módulos de detección del sistema. Su método run() consiste en una llamada al método obtenerParametros() y otra al método detectar(). El método detectar() contiene únicamente la sentencia pass, lo que quiere decir que el método no hace nada. Así, son los módulos que heredan de la clase los que deben redefinir este método implementando el algoritmo de detección deseado. Las clases KThread y BD son importadas para su uso en la clase que define.

El módulo DetectorExponencial.py incluye la definición de la clase DetectorExponencial.

Tiene una constante columnas en la que se registran los nombres y tipos de las columnas a incluir en la base de datos para registrar los datos que proporciona, en este caso:

• fin_exp, de tipo text, que registra la fecha y hora en las que finaliza la ejecución del algoritmo exponencial para cada dominio.

• probabilidad_exp, de tipo float, que registra las probabilidades obtenidas al ejecutar el algoritmo de detección exponencial.

Las clases Detector, datetime (librería de Python relacionada con los datos de fecha y hora) y math (librería de Python de operaciones matemáticas) son importadas para su correcta implementación.

El módulo DetectorMannheim.py incluye la definición de la clase DetectorMannheim.

Tiene una constante columnas en la que se registran los nombres y tipos de las columnas a incluir en la base de datos para registrar los datos que proporciona, en este caso:

• fin_mann, de tipo text, que registra la fecha y hora en las que finaliza la ejecución del algoritmo de Mannheim para cada dominio

• probabilidad_mann de tipo text, que determina si el dominio pertenece o no a una red fast‐flux como resultado de la ejecución del algoritmo de Mannheim.

Las clases Detector, datetime y math son importadas para su correcta implementación.


104 Implementación

6.1.2 Paquete Monitores El módulo __init__.py contiene el código necesario para que los módulos de

monitorización referenciados en el archivo de configuración sean importados al sistema y automáticamente tenidos en cuenta por la hebra de control en el proceso de monitorización de los dominios. Para ello, abre el archivo de configuración, lee la parte correspondiente a los monitores y almacena los nombres en la variable __all__ del paquete. De esta forma, cuando se ejecute la sentencia from Monitores import * en el módulo de control, todos los módulos nombrados en la lista __all__ pasarán automáticamente a formar parte del sistema. Además, incluye también una sentencia para fijar, como servidor DNS al que se dirigen las peticiones, el servidor especificado en el archivo de configuración o, en su defecto, del servidor DNS primario de la red. Para esta última acción es necesario importar los módulos Base y Win32dns del paquete DNS.

El módulo Monitor.py incluye la definición de la clase Monitor, que es la clase de la que

heredan todos los módulos de monitorización del sistema. El método monitorizar() contiene únicamente la sentencia pass, lo que quiere decir que el método no hace nada. Así, son los módulos que heredan de la clase los que deben redefinir este método implementando el proceso de monitorización deseado. Las módulos KThread, Temporizador y datetime son necesarios para la implementación del módulo.

El módulo MonitorA.py incluye la definición de la clase MonitorA. Tiene una constante

columnas en la que se registran los nombres y tipos de las columnas a incluir en la base de datos, en este caso:

• num_peticiones_a, de tipo int, que registra el número de peticiones de tipo A realizadas al servidor DNS para un dominio.

• ip_a, de tipo int, que registra el número de direcciones IP únicas anunciadas en el servidor para un dominio.

• ttl_a, de tipo float, que registra el TTL medio de las respuestas recibidas para un dominio.

• status_a, de tipo text, que registra el código de respuesta contenido en los mensajes de respuesta del servidor para cada dominio.

El tiempo entre peticiones al servidor DNS viene marcado por el valor del campo TTL de los registros. De esta forma, el objeto MonitorA almacena en una lista no sólo las IPs devueltas por el servidor, sino también los valores de los TTL. En cada iteración, el objeto comprueba cuál es el mínimo y la hebra entra en reposo durante ese tiempo, ya que hasta que no caduque algún registro en caché no se devuelve nueva información.

Por ejemplo, si en la respuesta a una petición se reciben 5 registros tipo A con valores

de TTL 1800, 1800, 537, 433 y 900 respectivamente, la hebra monitor almacena estos números en una lista, busca el mínimo de ellos con la función min(lista),obteniendo el 433 y entra en reposo durante 433 segundos, despertando cada 2 segundos para comprobar si ha


Implementación 105

recibido la orden de finalizar su ejecución por parte de la hebra de Control. A continuación, la lista se reinicia y se vuelve a realizar otra petición.

Las líneas de código de este proceso están incluidas en un bucle infinito, del que

solamente se saldrá en el caso de que haya transcurrido el tiempo máximo marcado para el monitor. Esta comprobación se hace con el método restante() del objeto Temporizador.

Los módulos Monitor y ConsultaDNSTipoA son importados para poder llevar a cabo la

implementación del módulo. El módulo MonitorASN.py incluye la definición de la clase MonitorASN. Tiene una

constante columnas en la que se registran los nombres y tipos de las columnas a incluir en la base de datos, en este caso:

• num_peticiones_asn, de tipo int, que registra el número de peticiones de tipo TXT realizadas al servidor DNS para un dominio.

• num_respuestas_asn, de tipo int, que registra el número de respuestas recibidas por parte del servidor DNS.

• asn, de tipo int, que registra el número de ASNs únicos asociados a las IPs de los registros de tipo A.

Para obtener los ASNs, el objeto MonitorASN envía para cada IP una petición de tipo TXT al servidor DNS. Estas peticiones tipo TXT se traducen en peticiones a un servicio proporcionado por Team Cymru [8] usando una zona DNS establecida especialmente para este uso. Las respuestas a estas peticiones contienen, entre otros datos, el ASN asociado a la IP por la que se pregunta.

Para que las peticiones enviadas produzcan peticiones a los servidores de Team Cymru,

se añade a la IP de la que se solicita información el sufijo “.origin.asn.cymru.com”. De esta forma, el servidor DNS redirige la petición al servicio mencionado.

La temporización de operaciones de monitorización es exactamente la misma que para

el caso de los objetos MonitorA. Los módulos Monitor, ConsultaDNSTipoA y Base son importados para poder llevar a cabo la implementación del módulo.

El módulo MonitorNS.py incluye la definición de la clase MonitorNS. Tiene una

constante columnas en la que se registran los nombres y tipos de las columnas a incluir en la base de datos, en este caso:

• num_peticiones_ns, de tipo int, que registra el número de peticiones de tipo NS realizadas al servidor DNS para un dominio.

• ip_ns, de tipo int, que registra el número de direcciones IP únicas de los servidores de nombres de un dominio.

• ttl_ns, de tipo float, que registra el TTL medio de las respuestas recibidas para un dominio.


106 Implementación

• status_ns, de tipo text, que registra el código de respuesta contenido en los mensajes de respuesta del servidor para cada dominio.

El método de la clase, solicitudNS, utiliza un objeto de la clase ConsultaDNSTipoA para pedir la información de tipo A asociada a los servidores de nombres que están incluidos en los registros NS de cada respuesta. En el caso de recibir un registro de tipo SOA, se llama recursivamente al método para obtener los servidores de nombres asociados a la autoridad.

La temporización de operaciones de monitorización es exactamente la misma que para

el caso de los objetos MonitorA. Los módulos Monitor, ConsultaDNSTipoA y Base son importados para poder llevar a cabo la implementación del módulo.

6.1.3 Paquete DNS El paquete DNS no ha sido implementado en este proyecto, sino que es una

herramienta externa al sistema. Es un paquete que contiene módulos cuyo código está destinado a la interacción con servidores DNS.

De entre todos los módulos incluidos en el paquete, en el sistema implementado

solamente se ha hecho uso de los módulos Base y Win32dns. Además, se ha incluido en él el módulo ConsultaDNSTipoA, el cual sí ha sido diseñado e implementado en este proyecto. Estos son los 3 módulos que se van a describir a continuación.

El módulo Base.py contiene la definición de la clase DnsRequest, que implementa los

objetos para la creación, envío y recepción de mensajes del servidor DNS. En la inicialización del objeto se crea el mensaje de solicitud con el dominio sobre el que se solicita información y con el tipo de información que se solicita según los parámetros utilizados. Al llamar a su método req() sobre el objeto, se envía el mensaje al servidor DNS y se devuelve la respuesta dividida en 4 diccionarios, cada uno correspondiente a una parte distinta de la respuesta: cabecera, respuestas, autoridad y datos adicionales.

Tiene además una constante defaults, que es un dato de tipo diccionario con los

parámetros del envío de los mensajes. Contiene, entre otros, la dirección del servidor al que se dirigen las peticiones o el tipo de solicitud que se realiza. Estos son los parámetros que se van a ajustar para que cada monitor acceda a los datos que le corresponden.

El módulo Win32dns.py contiene la función RegistryResolve(), utilizada para obtener

automáticamente cuáles son las direcciones IP de los servidores de nombres asociados al proveedor que ofrece la conexión a Internet. La llamada a esta función se hace en el módulo __init__ del paquete Monitores. Una vez obtenidas estas direcciones, almacena una de ellas en el apartado correspondiente de la constante defaults del módulo Base para que sea la dirección utilizada en el envío de mensajes DNS.

El módulo ConsultaDNSTipoA.py incluye la definición de la clase ConsultaDNSTipoA.

Para implementar su método solicitudA de forma que se puedan obtener los registros de


Implementación 107

tipo A aunque los registros que devuelve el servidor sean de otro tipo, se hace uso de la recursividad. De esta forma, si al realizar una petición de tipo A sobre un nombre de dominio, el servidor responde con un registro de tipo CNAME, el método vuelve a ser llamado, esta vez preguntando por los registros de tipo A asociados al nombre canónico incluido en CNAME.

6.1.4 Otros Módulos Los módulos que se describen a continuación no están incluidos en ningún paquete

Python. El módulo BD.py incluye la definición de la clase BD. En la inicialización de esta clase se

lee la ruta de la base de datos indicada en el archivo de configuración para trabajar sobre ella.

El módulo Control.py incluye la definición de la clase Control. Como esta clase es la que

controla todas las operaciones de análisis, debe conocer con qué módulos de monitorización y detección debe contar para operar. Estos módulos son los que están incluidos en el archivo de configuración, con lo que para que puedan ser incluidos en la aplicación bastará con que se importen los módulos incluidos en las variables __all__ de los paquetes Monitores y Detectores con las sentencias mencionadas al principio del Apartado 6.1.

Cuando una hebra de control es iniciada, obtiene los nombres de los dominios

registrados en la base de datos y se incluyen en la lista nombres. Cada vez que se incluya un nombre en un proceso de análisis, se incluirá también en esta lista. De esta forma, la hebra de control es capaz de filtrar los dominios para que no existan repeticiones, comprobando simplemente si el dominio a analizar se encuentra o no en esta lista.

A continuación, el objeto de control ejecuta un bucle infinito, del que solamente se

saldrá en el caso de que todos los dominios hayan sido analizados o de que el usuario ordene su detención. Las acciones de este bucle infinito son las siguientes:

1. Se comprueba si hay nuevos nombres de dominio para ser analizados. Si el

dominio ya existe en la lista nombres, se actualiza su estado a “Finalizado (analizado previamente)”. En caso contrario, se añade el nombre a la lista nombres, se introduce en la cola de monitorización colamon y se actualiza su estado a “Esperando monitorización”.

2. Se recorre la lista de monitores activos (monitores) en grupos de n, siendo n el número de tipos de monitor definidos en el sistema. Si para alguno de los dominios todos sus hebras monitor han terminado su ejecución (comprobado utilizando el método isAlive() sobre cada hebra), entonces se insertan los datos recogidos en la monitorización en la base de datos, se introduce el nombre de dominio en la cola de detección, se actualiza su estado a “Esperando detección”


108 Implementación

y se añade su posición en monitores a la lista borrar, que en principio se encuentra vacía.

3. Se borran de la lista monitores el conjunto de monitores que han acabado, cuyas posiciones vienen marcadas por la lista borrar.

4. Se reinicia el vector borrar.

5. Se repiten los pasos 2, 3 y 4 sobre la lista de detectores activos (detectores).

6. Se rellenan las listas monitores y detectores con nuevas hebras de monitorización y detección para dominios contenidos en las colas colamon y coladet, marcando su estado como “Monitorizando” y “Detectando” respectivamente, hasta alcanzar en cada lista el máximo permitido por los atributos monitoresmax y detectoresmax.

7. Si no existen elementos en la lista monitores ni detectores, esto significará que el análisis de todos los dominios ha finalizado y la hebra sale del bucle. En caso contrario, la hebra de control entrará en estado de reposo durante un segundo, actualizará los contadores asociados a cada monitor y detector y volverá al inicio del bucle.

Los pasos descritos son los que sigue el objeto de control para cumplir su función de

controlar las operaciones de monitorización y detección. El módulo Temporizador.py incluye la definición de la clase Temporizador. Para

implementar los métodos de la clase, importa el módulo time de Python, que está asociada a operaciones de fecha y hora.

El módulo KThread.py incluye la definición de la clase KThread. La implementación de la

clase no se ha llevado a cabo en este proyecto. Para más detalles, véase Apartado 6.4.4. El módulo GUI.py incluye la definición de las clases que componen la interfaz gráfica

implementadas en este proyecto, que son MainWindow, DominioWindow, AnalizandoWindow, InformeWindow y ErrorDialog. No hay nada destacable sobre la implementación de estas clases.

El módulo incluye también la definición de la función main(), que marca el punto de

inicio del sistema. En él lo único que se hace es crear la ventana principal, es decir, un objeto de la clase MainWindow para que el usuario pueda empezar a usar el sistema.

El módulo Rastreador.py incluye la definición de la clase Rastreador. Para obtener los

dominios de la fuente, se implementa el método rastrear(). Este método, como ya se comentó en la descripción de la arquitectura del sistema, actúa de distinta forma para los distintos tipos de fuente:

6.2 Archivo de configuración

Implementación 109

• Si el tipo es Línea, se considerará que todo el contenido de la línea de texto fuente son URLs y que están separadas por el carácter “,”. Con lo cual, para obtenerlas basta con aplicar el método split de la clase string sobre la línea de texto para obtener una lista que contenga una URL en cada una de sus posiciones.

• Si el tipo es Txt, se considerará de nuevo que todo el contenido del archivo fuente son URLs y que hay una por cada línea del archivo. Por tanto, para obtenerlas basta con abrir el archivo y leer todas las líneas del archivo con el método readlines(), que devuelve una lista con una línea del archivo en cada posición.

• Si el tipo es Emails o webs, lo primero que se hace es abrir cada archivo contenido en el directorio marcado en la fuente, y llamar al método message_from_file(archivo) de la clase email sobre cada uno, que devuelve un objeto de la clase email con el contenido del archivo. A continuación se invoca al método desglosar para obtener las listas de contenido y de tipo asociado a cada parte del email o de la página web. El método desglosar es recursivo para poder separar el contenido de los correos y páginas multiparte. Obtenidas las listas, ya se pueden obtener las URLs contenidas en el email o en la web, para lo cual:

o Si el tipo asociado a una parte del contenido es “text/plain”, se buscarán las URLs buscando la secuencia “http://” y “www.” en el texto.

o Si el tipo asociado a una parte del contenido es “text/html”, se utiliza una clase auxiliar llamada buscadirecciones, que hereda de la clase HTMLParser, diseñada para procesar textos HTML y extraer de ellos la información que convenga. El objeto de la clase buscadirecciones extrae el contenido del campo href contenido en las etiquetas a del texto HTML, que es la secuencia que contiene los hipervínculos en un correo electrónico.

Tras obtener las URLs en una lista, se le aplica a dicha lista el método procesardominios() para extraer de cada URL el nombre de dominio. La forma de hacerlo es eliminar de cada URL el prefijo http:// o https:// y la parte local, que corresponde a todo el texto desde la primera aparición del carácter “/” hasta el final de la URL, quedando así una lista conteniendo solamente los nombres de dominio.

6.2 Archivo de configuración El sistema ha sido diseñado e implementado para permitir al desarrollador incluir de

una forma sencilla módulos de monitorización y detección al sistema. Este objetivo se consigue gracias al uso de un archivo de configuración, el cual es leído y procesado por el sistema antes de ofrecer al usuario las opciones disponibles.


110 Implementación

Monitor1 Monitor2 […] MonitorN ‐‐‐ Detector1 Detector2 […] DetectorN ‐‐‐ Ruta BD ‐‐‐ Dirección IP servidor DNS

Figura 6.2 Para acoplar un nuevo módulo a la aplicación, el desarrollador tendrá simplemente que

escribir el nombre del mismo en el archivo de configuración respetando el formato de este archivo, mostrado en la Figura 6.2. Hecho esto, el módulo definido entrará directamente a formar parte de la aplicación al igual que el resto de monitores y detectores definidos.

Con el propósito de dotar a la aplicación de una mayor flexibilidad, el archivo de

configuración incluirá también la ruta del archivo que contiene la base de datos con la que se va a trabajar, además del servidor DNS al que se van a dirigir las peticiones.

Si la dirección IP del servidor DNS en el archivo de configuración es “0.0.0.0”, entonces

se ignorará y se utilizará la dirección IP del primer servidor de nombres de la red sobre la que se esté trabajando en el momento de iniciar el programa.

El sistema trabajará sobre los datos que contiene el archivo de configuración al inicio de

la ejecución de la aplicación, con lo que cualquier cambio de configuración no se hará efectivo hasta que el usuario no reinicie el programa.

6.3 Interfaz gráfica En este apartado se va a presentar la implementación de la interfaz gráfica, mostrando

capturas de pantalla de cada ventana implementada y explicando detalladamente cómo interactúan el usuario y el sistema.

Al iniciar la ejecución de la aplicación, el sistema muestra la ventana principal (Figura 6.3). En la barra de menú de esta pantalla se encuentran las opciones Detectar (para operaciones de monitorización y detección de dominios) y Opciones BD (para operaciones sobre la base de datos).

Al pulsar sobre Detectar se despliega un menú con las opciones Iniciar y Detener. A su

vez, al colocar la flecha del ratón sobre la opción Iniciar se despliega un segundo menú cuyas

6.3 Interfaz gráfica

Implementación 111

opciones (Línea, Archivo y Emails o webs) permiten al usuario escoger el tipo de fuente de los nombres de dominio para iniciar un nuevo análisis. La opción Detener permitirá al usuario detener la ejecución del análisis en curso si lo hubiese.

Al pulsar sobre Opciones BD se despliega un menú con las opciones Consultar y Borrar.

La opción Borrar elimina todos los registros de la base de datos. La opción Consultar muestra al usuario una ventana de estado del análisis (Figura 6.8) donde se presentan todos los dominios registrados en la base de datos, con el estado “Finalizado (analizado previamente)”. El usuario podrá consultar los datos sobre el dominio que desee haciendo doble click sobre el dominio correspondiente de la lista. El sistema responde mostrando una ventana de informe del dominio (Figura 6.9) mostrando en la primera columna las etiquetas de los datos y resultados obtenidos para el dominio y en la segunda columna los valores que toman estos datos para el dominio escogido.

La barra de estado mostrará en cada momento una breve descripción de la opción

sobre la que se encuentre situada la flecha del ratón. Cuando el usuario decide ejecutar el análisis de nombres de dominio, elige una de las

tres opciones dentro del submenú de Iniciar. En función del tipo de fuente escogido, se presentará una ventana u otra. Así, para las opciones Línea, Archivo y Emails o webs se presentan las ventanas de las Figuras 6.4, 6.5 y 6.6 respectivamente.

Se supone el caso en el que un usuario elige la opción Emails o webs dentro de la

opción Iniciar para analizar los nombres de dominio contenidos en emails y páginas web. Aparecerá por tanto la ventana de la Figura 6.6. Utilizando los selectores numéricos, el usuario escoge los parámetros de análisis que desee, siendo Monitores y Detectores el número de dominios a monitorizar y a detectar simultáneamente y Tmax monitor y Tmax detector el tiempo máximo permitido de monitorización y detección para cada dominio. Para elegir la fuente, el usuario puede escribir directamente la ruta en el cuadro de texto o pulsar el botón Examinar marcado en la figura para elegirlo utilizando un diálogo estándar de elección de archivo que el sistema muestra al pulsar sobre el botón. Hecho esto, se pulsa el botón Aceptar para iniciar el proceso de análisis o Cancelar para cerrar la ventana.

Al pulsar Aceptar, si la ruta no es correcta o el archivo no se puede leer, el sistema

muestra una ventana de error (Figura 6.7) indicando el error que se ha producido. Si no se ha producido ningún error, muestra una ventana de estado de análisis (Figura 6.8) que contiene solamente una “lista de control”, que es un elemento gráfico de la librería wxPython (véase apartado 6.4.3) que permite mostrar una lista de elementos fácilmente manejable y con la posibilidad de actualización de los datos que contiene. La lista consta de dos columnas. En la columna de la izquierda se muestran los nombres de dominio que el sistema ha localizado en la fuente especificada, mientras que en la segunda se muestra el estado en el que se encuentra el proceso de análisis para cada dominio particular. Al igual que en el caso de consulta de la base de datos, el usuario puede en cualquier momento hacer doble click sobre los dominios mostrados para consultar los datos y resultados obtenidos. El sistema mostrará una ventana de informe del dominio (Figura 6.9).


112 Implementación

Figura 6.3

Figura 6.4

Figura 6.5

6.3 Interfaz gráfica

Implementación 113

Figura 6.6

Figura 6.7

Figura 6.8


114 Implementación

Figura 6.9

6.4 Herramientas externas usadas en la implementación En este apartado se describen algunas herramientas utilizadas en el proceso de

implementación y que han sido fundamentales para la consecución de los objetivos del proyecto.

6.4.1 Eclipse Eclipse [9] es un entorno de desarrollo de código abierto multiplataforma. Ha sido el

entorno utilizado para la implementación del sistema, ya que la licencia de uso es gratuita y además dispone de un editor de texto con resaltado de sintaxis, muy útil para la programación.

En principio, Eclipse no está adaptado para la programación en Python, pero gracias al

plug‐in gratuito PyDev [10], se puede programar en este lenguaje sobre la plataforma.

6.4.2 Paquete PyDNS El paquete PyDNS [11] es un paquete que contiene módulos implementados para la

interacción con servidores DNS utilizando Python. Al ser de código abierto, es una herramienta gratuita y además su código se puede leer y modificar si es necesario. Es el

6.4 Herramientas externas usadas en la implementación

Implementación 115

paquete DNS del sistema descrito en el Apartado 6.1.3. Ha sido desarrollado por el equipo de SourceForge.net.

6.4.3 Paquete wxPython El paquete wxPython [12] es una herramienta para la creación de interfaces gráficas de

usuario (Graphical User Interface, GUI) con el lenguaje Python. Permite al programador crear programas con interfaces de usurio robustas y muy funcionales de una forma simple. Está implementada como un módulo de extensión para Python.

Esta herramienta es de código abierto, con lo que es gratuita y que el código se puede

modificar si es conveniente. Es además una herramienta portable, que funciona sobre sistemas Windows de 32 bits, la mayoría de sistemas Unix y Macintosh OS X. Requiere instalación. El paquete ha sido desarrollado por SourceForge.net.

6.4.4 Módulo KThread.py El módulo KTHread.py permite detener la ejecución de hebras. La clase KThread juega

el papel de la clase threading.Thread. Añade el método kill() que es el que detiene las hebras.

La clase KThread funciona introduciendo una traza en la hebra. La traza comprueba tras

la ejecución de cada una de sus instrucciones si debe detener su ejecución. Por lo tanto, es posible detener cualquier hebra activa.

6.4.5 Librería SQLite3 La librería SQLite3 es un módulo Python que contiene funciones para operar con bases

de datos SQLite. Proporciona una interfaz SQL compatible con la especificación DB‐API 2.0. Este módulo está incluido en el intérprete de Python desde su versión 2.5.

6.4.6 Servidores TeamCymru Los servidores Team Cymru [8] son los servidores a los que hay que dirigir las peticiones

de tipo TXT para obtener el ASN asociado a una dirección IP. La información que facilita se basa en las listas de los registradores de dominios ARIN, RIPE, AFRINIC, APNIC y LACNIC. Existen otros protocolos para el acceso a sus bases de datos, como son Whois, HTTP o Secure HTTP.


116 Implementación

117

CAPÍTULO 7. Evaluación

Una vez acabada la fase de implementación, hay que someter a la aplicación a una serie

de pruebas para comprobar que funciona correctamente y para detectar posibles errores que se puedan producir durante su ejecución. En este capítulo se realiza una descripción de este conjunto de pruebas, describiendo en qué consiste cada una, el objetivo que cumple, el resultado esperado antes de la prueba y el resultado obtenido al realizarla. También se va a llevar a cabo un análisis de un conjunto de dominios utilizando servidores DNS distintos para analizar cómo depende el comportamiento del detector del servidor al que se dirigen las peticiones.

7.1 Pruebas de funcionalidad A continuación se exponen las pruebas relacionadas con el correcto funcionamiento del

sistema durante su ejecución.

7.1.1 Pruebas de extracción de nombres de dominio

• Prueba A: Se introducen varias URLs separadas por el carácter “,” en la ventana de introducción de parámetros correspondiente al tipo de fuente “Linea” y se pulsa el botón “Aceptar” para iniciar el análisis. La cadena de texto introducida es: “http://www.probando1.com/directorioA/directorioB/archivo, www.probando2.es/directorioC, http://probando3.ru/directorioD, probando4.hk”.

o Objetivo: Comprobar que se extraen correctamente los nombres de dominio de distintas URLs a partir de una línea de texto.


118 Evaluación

o Resultado esperado: El sistema abre una ventana de estado del análisis en la que se muestran como nombres de dominio www.probando1.com, www.probando2.es, probando3.ru y probando4.hk.

o Resultado obtenido: El sistema muestra la ventana de la Figura 7.1. La captura de pantalla ha sido tomada al finalizar el análisis. Como se puede apreciar, los nombres de dominio han sido correctamente extraídos. El resultado de la prueba es el que se esperaba obtener.

• Prueba B: Se introduce la ruta de un archivo de texto en la ventana de introducción de parámetros correspondiente al tipo de fuente “Archivo” y se pulsa el botón “Aceptar” para iniciar el análisis. El contenido del archivo de texto es el siguiente:

http://www.probando1.com/directorioA/directorioB/archivo www.probando2.es/directorioC http://probando3.ru/directorioD probando4.hk

o Objetivo: Comprobar que se extraen correctamente los nombres de dominio de distintas URLs a partir de un archivo de texto.

o Resultado esperado: El sistema abre una ventana de estado del análisis en la que se muestran como nombres de dominio www.probando1.com, www.probando2.es, probando3.ru y probando4.hk.

o Resultado obtenido: El sistema muestra la ventana de la Figura 7.2. La captura de pantalla ha sido tomada al finalizar el análisis. Como se puede apreciar, los nombres de dominio han sido correctamente extraídos. El resultado de la prueba es el que se esperaba obtener.

• Prueba C: Se introduce la ruta de un directorio en la ventana de introducción de parámetros correspondiente al tipo de fuente “Emails o webs” y se pulsa el botón “Aceptar” para iniciar el análisis. El contenido del directorio son 2 archivos de

extensión .mht (web1.mht y web2.mht) que contienen las páginas web

http://www.ugr.es y http://tstc.ugr.es respectivamente, y 3

archivos de extensión .eml (email1.eml, email2.eml y email3.eml), que contienen correos de tipo texto plano, texto html y multiparte respectivamente.

o Objetivo: Comprobar que se extraen correctamente los nombres de dominio de las URLs contenidas en un conjunto de emails con contenidos de texto plano y texto HTML y de páginas web.

o Resultado esperado: El sistema abre una ventana de estado del análisis en la que se muestran como nombres de dominio todos los que están contenidos en los archivos del directorio.

7.1 Pruebas de funcionalidad

Evaluación 119

Figura 7.1. Resultado obtenido tras la ejecución de la prueba A

Figura 7.2. Resultado obtenido tras la ejecución de la prueba B.

WEB 1 WEB2 EMAIL1 EMAIL2 EMAIL3

Figura 7.3. Resultado obtenido tras la ejecución de la prueba C.

o Resultado obtenido: El sistema muestra la ventana de la Figura 7.3. La captura de pantalla ha sido tomada al finalizar el análisis. Se puede comprobar que los nombres contenidos en los archivos son todos los que aparecen en la tabla. El resultado de la prueba es el que se esperaba obtener.

7.1.2 Pruebas de comportamiento durante el análisis

• Prueba D: Existiendo un análisis activo, se introducen varias URLs separadas por el carácter “,” en la ventana de introducción de parámetros correspondiente al tipo de fuente “Linea” y se pulsa el botón “Aceptar”. La cadena de texto introducida es: “probando5.com, probando6.es, probando7.ru, probando8.hk”.


120 Evaluación

o Objetivo: Comprobar que se añaden correctamente nombres de dominio a la lista de dominios de un análisis iniciado previamente.

o Resultado esperado: El sistema añade a la ventana de estado del análisis activo los dominios probando5.com, probando6.es, probando7.ru y probando8.hk.

o Resultado obtenido: El análisis activo es el que se muestra en la Figura 7.4. Tras añadir los nuevos dominios, la ventana de estado de análisis es la de la Figura 7.5. Como se puede apreciar, los dominios han sido añadidos correctamente y algunos de ellos han iniciado su proceso de análisis. El resultado de la prueba es el que se esperaba obtener.

• Prueba E: Se introduce la ruta de un archivo de texto no existente en la ventana de introducción de parámetros correspondiente al tipo de fuente “Archivo” y se pulsa el botón “Aceptar” para iniciar el análisis.

o Objetivo: Comprobar que el sistema muestra correctamente un mensaje de error.

o Resultado esperado: El sistema muestra un diálogo de error con el mensaje “Error al abrir el archivo. Compruebe que la ruta especificada es correcta.”.

o Resultado obtenido: El sistema muestra la ventana de la Figura 7.6. El resultado de la prueba es el que se esperaba obtener.

• Prueba F: Existiendo un análisis activo, se elige la opción “Detener” para interrumpir las operaciones de monitorización y detección activas y tras enviar la orden, se comprueba el estado de las hebras. Para hacer la comprobación, se introduce una traza en el código de la aplicación.

o Objetivo: Comprobar que todas las hebras de monitorización y detección activas se detienen inmediatamente cuando el usuario da la orden al sistema.

o Resultado esperado: Tras pulsar “Detener” existiendo un análisis activo, todos los dominios no finalizados deben presentar el estado “Interrumpido” y todos los monitores y detectores deben estar inactivos. También debe estar inactiva la hebra de control.

o Resultado obtenido: El análisis activo es el que se muestra en la Figura 7.7. Tras pulsar “Detener” y esperar unos segundos, la ventana de análisis queda como se muestra en la Figura 7.8. La traza introducida en el código muestra que no existe ninguna hebra de monitorización ni de detección activa y que la hebra de control también ha finalizado su ejecución. El resultado de la prueba es el que se esperaba obtener.


Evaluación 121

Figura 7.4. Estado del sistema previo a la ejecución de la prueba D.

Figura 7.5. Resultado obtenido tras la ejecución de la prueba D.

Figura 7.6. Resultado obtenido tras la ejecución de la prueba E.

Figura 7.7. Estado del sistema previo a la ejecución de la prueba F.

Figura 7.8 Resultado obtenido tras la ejecución de la prueba F.

7.1.3 Pruebas de base de datos

• Prueba G: Tras haber ejecutado uno o varios análisis, se elige la opción “Consultar” del menú “Opciones BD” de la ventana principal. A continuación se hace doble click sobre uno de los dominios de la ventana de análisis mostrada.

o Objetivo: Comprobar que la operaciones de consulta de la base de datos funcionan correctamente.


122 Evaluación

o Resultado esperado: El sistema debe mostrar una ventana de estado de análisis conteniendo todos los nombres de dominio analizados hasta ese momento con el estado “Finalizado (analizado previamente)”. Al hacer doble click sobre el dominio, se debe mostrar correctamente el informe de análisis asociado.

o Resultado obtenido: La ventana mostrada por el sistema es la ventana de análisis de la Figura 7.9. Al hacer doble click sobre el dominio www.universia.es, el sistema muestra la ventana de informe de dominio mostrada en la Figura 7.10. El resultado de la prueba es el que se esperaba obtener.

• Prueba H: Se elige la opción “Borrar” del menú “Opciones BD” de la ventana principal. A continuación, se elige la opción “Consultar” del mismo menú.

o Objetivo: Comprobar que la operación de borrado de la base de datos funciona correctamente.

o Resultado esperado: Tras elegir la opción “Borrar” y pulsar la opción “Consultar”, debe aparecer una ventana de estado de análisis sin ningún nombre de dominio contenido en ella.

o Resultado obtenido: La ventana mostrada por el sistema es la de la Figura 7.11, que es una ventana de análisis vacía. El resultado de la prueba es el que se esperaba obtener.

Figura 7.9. Resultado obtenido tras la ejecución de la prueba G (1).


Evaluación 123

Figura 7.10. Resultado obtenido tras la ejecución de la prueba G (2).

Figura 7.11. Resultado obtenido tras la ejecución de la prueba H.

7.1.4 Pruebas de opciones de configuración

• Prueba I: En el archivo de configuración, se modifica la línea correspondiente al servidor DNS escribiendo “DNS 0.0.0.0”. A continuación, se inicia el análisis del

dominio www.ugr.es. Una vez finalizado el análisis, se vuelve a modificar la línea, escribiendo “DNS 8.8.8.8” (8.8.8.8 es un servidor DNS público) y se vuelve a ejecutar el análisis para el dominio prueba1.com. En ambos análisis, se comprueba el destino de los mensajes enviados por parte del sistema con la aplicación Wireshark.

o Objetivo: Comprobar que el establecimiento del servidor DNS al que se dirigen las peticiones se realiza correctamente.

o Resultado esperado: En el caso del primer análisis, se espera que la dirección de destino de los mensajes enviados sea la dirección IP del servidor DNS primario de la red del ISP que sirve el acceso a Internet (en este caso, 192.168.1.1). En el caso del segundo análisis, se espera que la dirección destino sea 8.8.8.8.


124 Evaluación

o Resultado obtenido: Se inicia el primer análisis con la monitorización de Wireshark iniciada. Se comprueba que las peticiones realizadas por el sistema están dirigidas a la IP 192.68.1.1 (Figura 7.12). Se inicia el segundo análisis. Se comprueba que las peticiones realizadas por el sistema están dirigidas a la IP 8.8.8.8 (Figura 7.13). El resultado de la prueba es el que se esperaba obtener.

• Prueba J: Se crea el directorio “C:\Prueba”. En el archivo de configuración, se modifica la línea correspondiente a la base de datos escribiendo “C:\Prueba\bdprueba”. A continuación, se inicia el análisis del dominio prueba1.com. Una vez finalizado, se accede al directorio “C:\Prueba”.

o Objetivo: Comprobar el correcto funcionamiento de la elección del archivo base de datos.

o Resultado esperado: Tras el análisis, debe aparecer en el directorio un archivo llamado “bdprueba” que será la base de datos elegida. Las primeras palabras del contenido del archivo serán “SQLite format”.

o Resultado obtenido: En el directorio “C:\Prueba” aparece el archivo “bdprueba” (Figura 7.14). Al abrirlo con un editor de textos, se comprueba que es una base de datos SQLite (Figura 7.15). El resultado de la prueba es el que se esperaba obtener.

Figura 7.12. Resultado obtenido tras la ejecución de la prueba I (1).

Figura 7.13. Resultado obtenido tras la ejecución de la prueba I (2).


Evaluación 125

Figura 7.14. Resultado obtenido tras la ejecución de la prueba J (1).

Figura 7.15. Resultado obtenido tras la ejecución de la prueba J (2).

7.1.5 Pruebas de integración de módulos

• Prueba K: Se escribe el código de un módulo monitor de prueba que cumpla los requisitos de implementación correspondientes (véase Anexo I). El código del monitor es el de la Figura 7.16. Se incluye su nombre en el archivo de configuración precedido de la palabra “MONITOR”. Se inicia el programa y se realiza el análisis sobre el dominio www.ugr.es. Los datos que incluye en la base de datos son los siguientes:

MONITOR_PRUEBA_DATO1 = 3 MONITOR_PRUEBA_DATO2 = 2.0 MONITOR_PRUEBA_DATO3 = ’Prueba de integracion’

o Objetivo: Comprobar que la integración en la plataforma de un módulo monitor se produce de forma correcta.

o Resultado esperado: Al finalizar el análisis, debe aparecer en las ventanas de informe de dominio los nombres de las columnas incluidos en el dato columnas del módulo monitor con sus valores asociados.


126 Evaluación

o Resultado obtenido: El análisis finaliza con normalidad. Se hace doble click sobre el nombre de dominio para mostrar el informe asociado, que es el de la Figura 7.17. Se comprueba que el módulo ha sido tenido en cuenta para la monitorización al igual que el resto de monitores y que los datos obtenidos son los que deben ser.

• Prueba L: Se escribe el código de un módulo detector de prueba que cumpla los requisitos de implementación correspondientes (véase Anexo I). El código del dectector es el de la Figura 7.18. Se incluye su nombre en el archivo de configuración precedido de la palabra “DETECTOR”. Se inicia el programa y se realiza el análisis

sobre el dominio www.ugr.es. Los resultados que obtiene e incluye en la base de datos son los siguientes:

DETECTOR_PRUEBA_VALOR1= = MONITOR_PRUEBA_DATO1 * MONITOR_PRUEBA_DATO2 DETECTOR_PRUEBA_VALOR2=MONITOR_PRUEBA_DATO3

o Objetivo: Comprobar que la integración en la plataforma de un módulo detector se produce de forma correcta.

o Resultado esperado: Al finalizar el análisis, debe aparecer en las ventanas de informe de dominio los nombres de las columnas incluidos en el dato columnas del módulo detector con sus valores asociados.

o Resultado obtenido: El análisis finaliza con normalidad. Se hace doble click sobre el nombre de dominio para mostrar el informe asociado, que es el de la Figura 7.19. Se comprueba que el módulo ha sido tenido en cuenta para la detección al igual que el resto de detectores y que los resultados proporcionados son los que deben ser.

import Monitor columnas=('MONITOR_PRUEBA_DATO1 int','MONITOR_PRUEBA_DATO2 float', 'MONITOR_PRUEBA_DATO3 text') class MonitorPrueba(Monitor.Monitor): def __init__(self,nombredominio,tiempomax): Monitor.Monitor.__init__(self,nombredominio,tiempomax) self.datos['MONITOR_PRUEBA_DATO1']=int() self.datos['MONITOR_PRUEBA_DATO2']=float() self.datos['MONITOR_PRUEBA_DATO3']='' def monitorizar(self): self.datos['MONITOR_PRUEBA_DATO1']=3 self.datos['MONITOR_PRUEBA_DATO2']=2.0

self.datos['MONITOR_PRUEBA_DATO3']='Prueba de integración'

Figura 7.16. Código del monitor de la prueba K.


Evaluación 127

Figura 7.17. Resultado obtenido tras la ejecución de la prueba K

import Detector columnas=('DETECTOR_PRUEBA_VALOR1 float','DETECTOR_PRUEBA_VALOR2 text') class DetectorPrueba(Detector.Detector): def __init__(self,nombredominio,tiempomax): Detector.Detector.__init__(self,nombredominio,tiempomax) self.listaparametros=('MONITOR_PRUEBA_DATO1', 'MONITOR_PRUEBA_DATO2', 'MONITOR_PRUEBA_DATO3') self.datos['DETECTOR_PRUEBA_VALOR1']=float() self.datos['DETECTOR_PRUEBA_VALOR2']='' def detectar(self): dato1=self.parametros[self.listaparametros[0]] dato2=self.parametros[self.listaparametros[1]] dato3=self.parametros[self.listaparametros[2]] self.datos['DETECTOR_PRUEBA_VALOR1']=dato1*dato2

self.datos['DETECTOR_PRUEBA_VALOR2']=dato3

Figura 7.18. Código del detector de la prueba L.


128 Evaluación

Figura 7.19 Resultado obtenido tras la ejecución de la prueba L

7.2 Pruebas de detección

• Prueba M: Se analiza un directorio que contiene 796 correos de spam con un tiempo permitido de análisis para cada dominio de 2 horas. Las peticiones de información se dirigen al servidor DNS primario del ISP Jazztel (87.216.1.65).

o Objetivo: Analizar un conjunto de dominios para comprobar si existen dominios fast‐flux en el conjunto y hacer una valoración subjetiva de la efectividad de los monitores y detectores implementados.

o Resultado esperado: En ningún caso los análisis llevados a cabo deben superar el tiempo máximo especificado por el usuario. Al depender todos los resultados obtenidos de las respuestas devueltas por los servidores a los que se solicita la información, no se tienen expectativas sobre ellos.

o Resultado obtenido: Se han extraído en total 133 nombres de dominio únicos de todo el conjunto de correo basura. El tiempo de análisis no ha superado en ningún caso las 2 horas de ejecución marcadas. El número de registros de tipo A únicos encontrados para cada dominio no supera en ningún caso la cantidad de 2 y los valores de TTL medio son relativamente altos, por lo que no se ha localizado ninguna red fast‐flux entre los dominios del conjunto de prueba.

7.2 Pruebas de detección

Evaluación 129

Existen casos en los que el número de ASNs obtenidos para un dominio tienen valor 0 a pesar de existir una dirección IP asignada al mismo. Esto es debido a que la obtención de este parámetro se realiza en base a peticiones de registros TXT realizadas al servidor DNS de Team‐Cymru (véase Apartado 6.4.6). Este servidor tiene los datos correspondientes a solamente varios organismos registradores de dominios, por lo que no se recibirá respuesta sobre las direcciones IP no contenidas en estas listas.

• Prueba N: Se analiza el dominio www.ya.com dos veces. En la primera de ellas, las peticiones van dirigidas al servidor DNS primario del ISP Jazztel (87.216.1.65) y en la segunda al servidor DNS público OpenDNS (208.67.222.222). Se comparan las respuestas obtenidas en cada caso.

o Objetivo: Comprobar si existe dependencia de los datos obtenidos sobre un dominio con el servidor DNS al que se solicita la información.

o Resultado esperado: Se espera que no exista dependencia de los datos obtenidos con el servidor DNS objetivo.

o Resultado obtenido: El informe obtenido en el primer caso es el de la Figura 7.20 y en el segundo caso el de la Figura 7.21. Como se puede comprobar, todos los datos monitorizados tienen los mismos valores excepto dos de ellos: el TTL medio tanto de las peticiones de tipo A como de las peticiones de tipo NS. Para entender por qué esta diferencia, se procede a registrar en un vector cuáles son los valores TTL de los registros devueltos por ambos servidores. Concretamente, se van a realizar hasta 6 peticiones de tipo A a cada uno de los servidores para ese dominio esperando un intervalo de tiempo de 10 segundos antes de enviar la siguiente. Los TTL obtenidos son los siguientes: TTL para los RR procedentes de Jazztel: [134,124,114,104,94,84] TTL para los RR procedentes de OpenDNS: [124,161,156,109,145,99]

Como se puede apreciar, en el caso de Jazztel los resultados devueltos son coherentes, ya que cada 10 segundos el TTL se decrementa en 10 unidades. Sin embargo, en el caso del segundo análisis, esto no ocurre así. Esto es debido a que en el segundo caso la IP a la que se dirigen las peticiones no apunta a una sola máquina, sino a varias que tienen la misma IP de cara al exterior. Entre la interfaz a la que se ha enviado el mensaje y las máquinas del servidor existe un distribuidor que desvía las peticiones a la máquina que considere conveniente. Esta estructura se conoce como servidor balanceado y se establece con propósitos de distribución de carga. Los TTL de los registros devueltos en el análisis 2 no siguen el mismo orden lógico que en el caso del análisis 1 porque las respuestas no provienen siempre de la misma máquina en un mismo análisis. De este hecho se deduce que cuando los parámetros TTL de los registros obtenidos intervienen en la detección, las peticiones deben ser dirigidas a servidores no balanceados para evitar obtener datos no válidos para la detección.


130 Evaluación

Figura 7.20

Figura 7.21

131

CAPÍTULO 8. Conclusiones

En este capítulo se exponen las principales conclusiones que se han obtenido como

resultado de este proyecto y se describen las líneas de trabajo que se abren en base a este proyecto.

8.1 Resultados La aplicación resultante del desarrollo de este proyecto cumple totalmente con los

requisitos funcionales y no funcionales definidos para la aplicación. Son de destacar los siguientes hechos acerca de los resultados:

• Funcionalidad: el sistema cumple sus objetivos relacionados con este aspecto, ya que:

o Permite analizar nombres de dominio, recogiendo datos sobre cada uno y determinando si pertenecen o no a una red fast‐flux.

o Los nombres de dominio a analizar pueden ser extraídos de archivos de distintos tipos, incluyendo correos electrónicos, proporcionando la posibilidad de analizar correo basura que es fuente importante de direcciones con contenido malicioso.

o El análisis se realiza en base a los parámetros especificados por el usuario, incluyendo el número de dominios a analizar simultáneamente o el tiempo máximo de análisis de cada uno.

o Los datos resultantes del análisis se almacenan en una base de datos a la que se puede acceder en cualquier momento, permitiendo la posibilidad de consultar los datos y resultados del análisis de cualquier nombre de dominio registrado.


132 Conclusiones

• Flexibilidad: El sistema resultante es una plataforma flexible respecto a los siguientes aspectos:

o Permite la integración de nuevos módulos de monitorización que recojan nuevos tipos de datos sobre los dominios que se analizan para poder contar con nuevos parámetros de detección.

o Permite la integración de nuevos módulos de detección que apliquen nuevos algoritmos de detección.

o Permite la elección de la ruta de la base de datos para almacenar los resultados, de forma que al inicio de la aplicación el usuario determina con qué base de datos desea trabajar.

o Permite la elección del servidor DNS al que se desea dirigir las peticiones enviadas por los monitores encargados de obtener registros DNS.

• Facilidad de uso: Se ha comprobado que la aplicación es fácil de manejar y su interfaz de usuario es sencilla. Además, tanto la integración de nuevos módulos como la elección del servidor DNS o de la base de datos a usar se reducen a la edición de una línea de texto de un archivo de configuración cuyo formato es simple.

8.2 Trabajo futuro

• Creación de nuevos módulos de monitorización y detección: Como ya se ha comentado anteriormente, una de las características más importantes de este proyecto es que se pueden incorporar nuevos módulos de recogida de datos y de detección que permiten adaptar la plataforma a las posibles mejoras que puedan experimentar las redes fast‐flux en un futuro. De esta forma, la aplicación puede actualizarse y así se evita que quede obsoleta.

• Extracción de nombres de dominio de nuevos tipos de fuentes: La aplicación permite la extracción de nombres de dominio contenidos en una línea de texto, un archivo de texto y en un conjunto de emails o de páginas web. Sin embargo, pueden existir otras fuentes de nombres de dominio distintas de las mencionadas. Se puede escribir el código que permita utilizar también estas fuentes para la obtención de dominios.

• Monitorización DNS mejorada: La aplicación no permite que las peticiones DNS se dirijan a más de un servidor en una misma sesión de análisis. Además, algunos de los datos recogidos, como en el caso del ASN, no siempre se obtienen debido a las limitaciones de los servidores a los que se solicita la información. Una de las posibles mejoras que pueden introducirse al sistema es la implementación de una

8.2 Trabajo futuro

Conclusiones 133

monitorización DNS que supere estas dificultades, cuya solución no está incluida en el alcance de este proyecto.

• Interfaz con otro tipo de servidores para obtener más variedad de datos: A pesar de que los datos recogidos por los monitores implementados en este proyecto son solicitados a servidores DNS, se podrían solicitar datos útiles para la detección a otro tipo de servidores, como por ejemplo a servidores WHOIS, que contienen información administrativa sobre los nombres de dominio. Para ello, habría que implementar monitores con la interfaz correspondiente que les permitiera comunicarse con estos servidores.


134 Conclusiones

135

Anexo I. Directrices para la implementación de nuevos módulos.

Este anexo contiene un conjunto de normas que el usuario debe cumplir en la

implementación de módulos de monitorización y de detección y la bibliografía utilizada en el proceso de desarrollo de este proyecto.

La plataforma de detección de redes fast‐flux ha sido implementada para permitir al

usuario de la aplicación integrar nuevos monitores y detectores de forma que puedan adaptarse a los cambios que se producir en las formas de operación de estas redes. Estos módulos monitores y detectores deben cumplir una serie de normas respecto a su diseño e implementación para que la aplicación sea capaz de operar con ellos sin que se produzcan errores. En este apartado se exponen cuáles son las condiciones que se deben cumplir.

Diseño e implementación de módulos monitores Las condiciones que debe cumplir un módulo monitor para poder ser integrado en la

aplicación son las siguientes:

• El módulo debe estar localizado en el directorio Monitores que a su vez está dentro de la carpeta en la que se encuentra el código de la aplicación.

• Para que la aplicación reconozca la existencia del módulo, se debe incluir una nueva línea en el archivo de configuración (archivo FastFlux\src\config.conf), en la que la primera palabra sea “MONITOR” seguido de un espacio y la segunda palabra sea el nombre del módulo monitor (sin incluir la extensión .py).

• Para que la aplicación reserve al monitor una o varias columnas en la base de datos en las que registrar los datos que recoja, el código del monitor debe incluir una

136

constante columnas, tipo tupla de Python, que debe contener datos de tipo string con el formato ‘nombre_columna [espacio] tipo_dato’, siendo

nombre_columna el nombre de la columna que se desea añadir a la base de datos

y tipo_dato el tipo de dato que va a registrarse en dicha columna. Los valores soportados para tipo_dato son:

o null: Su valor es siempre “null”. Representa un dato vacío. o integer: El valor es un entero con signo, almacenado en 1,2,3,4,6 u 8 bits

dependiendo de la magnitud del valor. o real: El valor es un número en coma flotante, almacenado como un número de 8

bytes en el formato especificado por IEEE. o text: El valor es una cadena de texto, almacenado usando la codificación de la base

de datos (UTF‐8, UTF‐16BE o UTF‐16LE). o blob: El valor es cualquier tipo de dato distinto de los anteriores. Permite datos de

cualquier longitud.

• La clase que implementa el objeto monitor debe llamarse exactamente igual que el módulo que la contiene y además debe heredar de la clase Monitor contenida en el módulo Monitor del paquete Monitores.

• El método de inicialización del objeto monitor (método __init__) debe ejecutar como primera instrucción una llamada al método __init__ de la clase Monitor de la que hereda, pasando como parámetros el nombre del dominio a monitorizar y el tiempo máximo permitido por cada dominio para el monitor.

• La clase que implementa el objeto monitor debe redefinir el método monitorizar de la clase Monitor con argumento el propio objeto, implementando el proceso de monitorización.

• Para que el objeto de control pueda almacenar en la base de datos los valores recogidos por el monitor, al acabar la ejecución del método monitorizar el dato miembro datos, de tipo diccionario y heredado de la clase Monitor, debe contener como palabras clave los nombres de las columnas (nombre_columna de la lista columnas) y como valores asociados a dichas palabras clave los valores a almacenar en cada columna, que deben ser del tipo establecido (tipo_dato de la lista columnas).

Diseño e implementación de módulos detectores Las condiciones que debe cumplir un módulo detector para poder ser integrado en la

aplicación son las siguientes:

• El módulo debe estar localizado en el directorio Detectores que a su vez está dentro de la carpeta en la que se encuentra el código de la aplicación.

137

• Para que la aplicación reconozca la existencia del módulo, se debe incluir una nueva línea en el archivo de configuración (archivo FastFlux\src\config.conf), en la que la primera palabra sea “DETECTOR” seguido de un espacio y la segunda

palabra sea el nombre del módulo detector (sin incluir la extensión .py).

• Para que la aplicación reserve al detector una o varias columnas en la base de datos en las que registrar los resultados que obtiene, el código del detector debe incluir una constante columnas con el mismo formato que en el caso de los monitores, explicado en el apartado anterior.

• La clase que implementa el objeto detector debe llamarse exactamente igual que el módulo que la contiene y además debe heredar de la clase Detector contenida en el módulo Detector del paquete Detectores.

• El método de inicialización del objeto monitor (método __init__) debe ejecutar como primera instrucción una llamada al método __init__ de la clase Detector de la que hereda, pasando como parámetro el nombre del dominio a detectar. Además, debe también incluir en su atributo listaparametros, de tipo lista Python y heredado de la clase Detector, los nombres de las columnas de la base de datos que contienen los parámetros necesarios para la detección.

• La clase que implementa el objeto detector debe redefinir el método detectar de la clase Detector con argumento el propio objeto, implementando el algoritmo de detección. Los datos que se necesitan para su ejecución están contenidos en el atributo parametros, de tipo diccionario y heredado de la clase Detector, cuyas palabras clave son los nombres de las columnas especificados en la constante columnas del detector.

• Para que el objeto de control pueda almacenar en la base de datos los resultados obtenidos por el detector, al acabar la ejecución del método detectar el dato miembro datos, de tipo diccionario y heredado de la clase Detector, debe contener como palabras clave los nombres de las columnas (nombre_columna de la lista columnas) y como valores asociados a dichas palabras clave los valores a almacenar en cada columna, que deben ser del tipo establecido (tipo_dato de la lista columnas).

138

Bibliografía

[1] The Honeynet Project. Know Your Enemy: Fast‐Flux Service Networks. [En línea] Julio de 2007. http://www.honeynet.org/papers/ff/.

[2] Holz, Thorsten, et al. Measuring and Detecting Fast‐Flux Service Networks. s.l. : Symposium on Network and Distributed System Security, 2008.

[3] Nazario, Jose y Holz, Thorsten. As the Net Churns: Fast‐Flux Botnet Observations. 2008.

[4] Zhou, Chenfeng Vincent, Leckie, Christopher y Karunasekera, Shanika. Collaborative Detection of Fast Flux Phishing Domains. 1, Febrero de 2009, Journal of Networks, Vol. 4.

[5] Ferré Grau, Xavier y Sánchez Segura, María Isabel. Desarrollo Orientado a Objetos con UML. Universidad Politécnica de Madrid.

[6] Dolado Cosín, José Javier (Universidad del País Vasco). El modelo COCOMO. [En línea] http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm.

[7] Passerini, Emanuele, y otros. FluXOR: Detecting and Monitoring Fast‐Flux Service Networks. In Proceedings of the 5th international Conference on Detection of intrusions and Malware, and Vulnerability Assessment (Paris, France, July 10 ‐ 11, 2008). D. Zamboni, Ed. Lecture Notes In Computer Science, vol. 5137. Springer‐Verlag, Berlin, Heidelberg, 186‐206.

[8] Team Cymru ‐ IP to ASN Mapping. [En línea] http://www.team‐cymru.org/Services/ip‐to‐asn.html.

[9] Eclipse Foundation. Eclipse. [En línea] http://www.eclipse.org.

[10] Aptana. Pydev. [En línea] http://pydev.org.

[11]. SourceForge.net. PyDNS: DNS module for Python. [En línea] http://pydns.sourceforge.net.

139

[12] SourceForge.net. wxPython. [En línea] http://www.wxpython.org.

[13] Mockapetris, Paul. RFC 1035 ‐ Domain Names ‐ Implementation and Specification. s.l. : Network Working Group, 1987.

[14] Python Software Foundation. Python Programming Language ‐‐‐ Official Site. [En línea] http://www.python.org/.

[15] García Teodoro, Pedro, Díaz Verdejo, Jesús Esteban y López Soler, Juan Manuel. Transmisión de Datos y Redes de Computadores. Ed. PEARSON, Prentice Hall, 2003.

140

Glosario

A Address. Tipo dirección de registro DNS.

AfriNIC Africa Network Information Center.

Registrador de dominios de Internet en la región de África.

APNIC Asia‐Pacific Network Information Center. Registrador de dominios en Internet en la región de Asia‐Pacífico.

ARIN American Registry for Internet Numbers. Registrador de dominios en Internet en la región de América.

AS Autonomous System. Conjunto de redes administrado por una sola entidad con política común de enrutamiento.

ASN Autonomous System Number. Identificador del sistema autónomo.

BD Base de Datos.

CDN Content Distribution Network. Red de distribución de contenido.

CNAME Canonical Name. Tipo nombre canónico de registro DNS.

COCOMO COnstructive COst MOdel. Modelo de estimación de costes de proyectos software.

141

DDoS Distributed Denial of Service. Ataque de denegación de servicio con varios orígenes.

DNS Domain Name System. Sistema de nombres de dominio.

EML Extensión de los archivos de tipo correo electrónico.

HTM Extensión de los archivos de tipo página web.

HTTP HyperText Transfer Protocol. Lenguaje utilizado para la creación de páginas web.

FFSN Fast‐Flux Service Network. Red de servicios de flujo rápido.

FQDN Fully Qualified Domain Name. Nombre de dominio con la situación exacta en el árbol DNS.

GUI Graphical User Interface. Interfaz gráfica de usuario.

IEEE Institute of Electrical and Electronics Engineers. Organismo mundial de estandarización.

IP Internet Protocol. Protocolo de direccionamiento en Internet.

ISP Internet Service Protocol. Proveedor de servicios de Internet.

LACNIC The Latin American and Caribean Internet Addresses Registry. Registrador de dominios de Internet en la región de América Latina y Caribe.

MX Mail eXchange. Tipo correo electrónico de registro DNS.

NS Name Server. Tipo servidor de nombres de registro DNS.

PTR PoinTeR. Tipo indicador de registro DNS.

RIPE Réseaux IP Européens. Registrador de dominios en Internet en la región de Europa.

RR Resource Record. Registro DNS.

RRDNS Round‐Robin DNS. Técnica usada por los

142

servidores DNS para balanceo de carga.

SOA Start Of Authority. Tipo comienzo de autoridad de registro DNS.

SQL Structured Query Language. Lenguaje estándar para manipular información de una base de datos.

SQLite Sistema de gestión de base de datos relacional.

TCP/IP Transfer Control Protocol/Internet Protocol. Sistema de protocolos de comunicación usados en Internet.

TLD Top Level Domain. Dominio de primer nivel en la jerarquía DNS.

TTL Time‐To‐Live. Número que indica el tiempo de validez en segundos de un registro DNS.

TXT (1) TeXT. Tipo texto de registro DNS. (2) Extensión de archivo de tipo texto.

UML Universal Modeling Language. Lenguaje estándar y universal de modelado de software.

URL Uniform Resource Locator. Dirección completa de un recurso en Internet.

UTF Unicode Transformation Format. Formato de codificación de caracteres.

estudios de ingenierÍa de ... -...

Documents